What types of applications can you build with J2EE technologies?
The J2EE platform can be used to build enterprise applications (from Java 2 Enterprise Edition). Enterprise applications are inherently distributed.

In terms of the Java platform, this means that the components of the applications run on different JVMs that may be distributed across various machines on a network. Since the common mechanism for communicating between processes running on different JVMs in Java is Remote Method Invocation (RMI), this means RMI is the preferred communication protocol for distributed communication in a J2EE application. Since J2EE supports the Web paradigm, however, communication between the presentation layer of the application and the business-tier components commonly uses HTTP as the communication protocol. The J2EE platform is designed to provide server-side as well as client-side environments for developing multitier enterprise applications.

Do all applications built on J2EE require a Web interface?
This is a common misconception. Since J2EE defines the servlet and JSP APIs for Web-based access, some people think that J2EE is meant only for applications with a Web-based front end. It's not true that J2EE applications can be accessed only via a browser. J2EE applications support a variety of clients, including wireless and small devices, rich Java clients, and non-Java clients.

The confusion arises from the fact that thin Web clients are an increasingly popular way of building application front ends. That's why JSPs and servlets have gained popularity in Java. As a result, Java-based J2EE applications are often exclusively associated with Web applications.

Do all J2EE applications require EJBs?
The short answer is no; not all J2EE applications require EJB development. That said, EJBs are the crux of J2EE. The J2EE application platform is built around the concept of EJB-based business objects. In any distributed programming platform, the middle-tier business components are built on a common software object component model. COM is the component model for Windows-based applications. EJB is the object model for J2EE applications.

Essentially J2EE applications require application containers. In last month's FAQs (JDJ, Vol. 6, issue 8), the different containers supported by the J2EE platform - Web containers and EJB containers - were discussed. A Web-based distributed application that leverages J2EE technologies to the fullest will make use of both containers: the presentation components run in the Web Container and the business components executed on the EJB Container. All the business components are built as EJBs. The client accesses the application via servlets or JSPs. The information can be exchanged in the form of XML/HTML.

However, this is not the only application scenario. Remember that J2EE defines other APIs besides the servlet, JSP, and EJB APIs. The ones under the spotlight for non-EJB applications are RMI, JDBC, and JNDI. Application components can use RMI to communicate between distributed Java objects (which don't have to be EJBs). JDBC can be used directly from either servlets/JSPs or a Java client to access back-end data sources, and JNDI can be used for binding to remote objects via a directory service.

A typical Web-centric application can be built using just servlets/JSP pages and JDBC for database connectivity - with EJBs completely out of the picture. This still falls under the category of a three-tier distributed application (with the business logic housed in the servlets layer. Remember that JSPs essentially equate to servlets at runtime). The access to the data source can also be decoupled from the servlet layer by moving the data access logic to another Java object. This Java object can reside on a separate machine from the servlet and the communication can be facilitated via RMI.

In short, J2EE can be leveraged to build non-EJB applications in many ways. The true benefits of J2EE, however, are reaped when you design your business-logic layer on EJBs. J2EE application servers provide the environment for designing and executing EJB components, and only when you leverage the component model supported by J2EE will you benefit from the development environment that it offers. Without EJB, you'll end up doing a lot of the work made obsolete by the emergence of J2EE application servers as the "OS of the enterprise."