J2EE Platform

Enterprise applications responsible for supporting business-critical operations are very different from a typical program developed with J2SE. Besides providing the business functionality, these applications are expected to satisfy a number of nonfunctional requirements: be up and running day and night (i.e., be highly available), must support multiple users at the same time, be able to handle more work with additional hardware and with reasonable response time (i.e., be load-balanced and scalable), be able to interact with other existing or newly developed systems, be manageable, be secure, and so on. The size and complexity of these applications imply that it should be possible to use standard services for common requirements and pre-built components for well-defined business functionality.

J2EE Platform addresses these requirements by identifying certain architectural patterns and supporting these with appropriate APIs, frameworks and runtime environment. Figure 2-2 shows the various J2EE technologies.

Let us take a brief look at some of these technologies.

• The Java Connector Architecture is the primary mechanism for a Java program to access nonJava enterprise applications such as ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) and other legacy applications through Resource Adapters. These Resource Adapters are developed as per the Connector SPI (Service Provider Interface) and hence are portable to different J2EE environments.

• JTA (Java Transaction API) is the API for managing and coordinating transactions across heterogeneous systems.

• JMS (Java Message Service) is the API for exchanging messages through enterprise messaging systems. JMS supports both queue-based point-to-point communication and topic-based publisher-subscriber communication.

• JavaMail is the API for e-mail messaging. A related API is JAF (Java Activation Framework). Together, they allow processing of MIME (Multipurpose Internet Mail Extension) data.

• Servlets and JSPs (Java ServerPages) define the component architecture for Web applications. A Web application exposes its functionality via a Web browser, accepting HTTP/S requests and responding with HTML documents. Servlets and JSPs execute within a specialized container known as a Web container.

• EJBs (Enterprise JavaBeans) define the component architecture for transactional back-end applications. EJBs execute within a container known as an EJB container.

• SAAJ (SOAP with Attachment API for Java) and JAX-RPC define the API to access Web services from a Java client and develop Servlet based Web services. Web services for J2EE provides the specification for deploying Web services in a J2EE container. Normally, a J2EE container would mean either a J2EE compliant Web container or EJB container, but could also mean a container supporting both Web Applications and EJBs.

• JAXR (Java API for XML Registries) is the API for accessing UDDI and ebXML repositories.

These technologies are the building blocks for enterprise applications and support a variety of architectural patterns.

Web-Centric Architecture

In this architectural pattern, human users interact with the application via a Web browser. The application's primary responsibility is to accept user requests as HTTP GET or HTTP POST messages generated by the browser and serve HTML pages, most often generated dynamically by accessing data from various data sources and applying program logic contained within the application. Besides delivering generated HTML pages, the application could also deliver one or more applets within the Java Plug-In of the browser, off loading some of the processing to the client machine.

Here is a list of issues to be addressed in this kind of architecture:

User authentication and authorization: Most of the applications would require a user to login and allow only authorized operations.

Session Management: The application needs to maintain state information associated with each active session with a browser.

Separation of program logic with presentation details: In complex Web applications, programmers develop the business logic whereas the display pages are developed by artists. In such cases, separation of program logic and presentation elements helps in program evolution and maintenance.

Scalability and Load Balancing: It should be possible to support more users by adding more computing power.

J2EE addresses these requirements with Servlet, JSP, JAAS and Web container technologies. Servlets and the Web container handle the server side HTTP/S processing and map HTTP messages to Java objects, providing a framework for message driven programs. The application code is responsible for supplying the program logic, accessing data sources and interacting with other programs to generate the HTML document to be sent to the client. JSP adds to this framework by supporting page-oriented development, whereby HTML page structure is specified in JSP files and embedded tags access data and execute program logic. Under the hood, the JSP files are translated to Servlet code and eventually compiled into byte code by the Web container. A web application deployment descriptor, essentially an XML file to be loaded by the Web container, maps the user accessible URLs to Servlet classes and JSP files. You can also specify the security properties in the deployment descriptor. We will get into these details in the Web Application Security chapter.

Though the primary client of a Servlet/JSP based web application is a web browser, it is perfectly okay for the client to be a standalone Java program or a Java Web Start program. Also, it is perfectly valid for a servlet to be a Web service, accepting SOAP messages within HTTP POST data.

EJB Centric Architecture

EJBs are software components, much like Servlets and JSPs, that implement server side business functionality. The important difference is that EJBs are invoked through RMI, RMI-IIOP and JMS messages, serve mainly Java clients, and live within an EJB container. Also, an EJB method can be transactional. What it means is that an EJB method invocation could participate in a transaction started by its client. All access to transactional resources such as relational databases and other resource managers within this method automatically become part of the client-initiated transaction. As you may be aware, the following is true for operations within a transaction: either all of them succeed or all of them fail. Besides transactions, the EJB container offers persistence and security services. We talk more about EJBs and their security in Chapter 10, EJB Security.

Multi-Tier Architecture

Complex applications with multiple objectives must follow multi-tier architecture with each tier providing functionality appropriate to its type. For example, an e-commerce application could expose its customer interface via a Web browser, served by a Web tier and more powerful administration and customer support interface via a Java Web Start client. Both the Web tier and the Java Web Start client could access EJBs in the EJB-tier for business logic and data operations. The EJBs themselves could interact with other enterprise applications through JMS or resource adapters.