This chapter is from the book
This chapter is from the book
This chapter is from the book
3.2 J2EE Architecture
Planes, trains, and automobiles are all assembled using well-accepted blueprints and parts supplied by countless vendors. One way that this is carried out is through industry-accepted blueprints that define specifications for construction and how they are to be used. Under this same premise, the J2EE specification defines these interfaces, their life cycles, and interactions they must carry out. The specification also describes roles that can be held by resources involved in the development and deployment of server-based applications.
The J2EE specification introduces an architectural concept of a container. Containers are defined to house J2EE components within a layer boundary. Containers manage component relationships within tiers and resolve dependencies of components between these tiers. Figure 3.3 illustrates the J2EE containers and their associated component dependencies.
)
Figure 3.3. Container diagram.
To understand where these components exist within the topology of an application, consider that a given application can be partitioned as follows:
-
Client Container— User interface implementation resident on a client workstation.
-
Web Container— Server-based user-interface implementation accessed via HTTP.
-
EJB Container— Captures and defines enterprise business data and function; provides a mechanism for distribution of business objects and for transactional support of complex business interactions.
-
Information Systems Back End— A database, messaging system, or EIS that provides data and functions to the system.
Applications may utilize all or, at a minimum, the client and Web tiers; within each tier J2EE technologies will be engaged to perform application functions. Some will occupy an obvious tier, as is the case with the JSP/Servlet technologies. Obviously, these belong in the Web tier. Other technologies play a supporting role and may appear in any or all tiers. For instance, it's easy to see the requirement of interprocess messaging (JMS) appearing in all of the client, Web, and EJB tiers.
Notice the presence of J2SE in every container definition diagrammed in Figure 3.3. This reflects the foundation for all containers. Other technologies shown may or may not appear within a container definition because they are determined by application requirements. The following sections describe components defined within container boundaries.
3.2.1 JDBC
Potentially the catalyst technology for Java, JDBC allows developers to interact with vendor-enforced JDBC data sources using generic interfaces. Statement execution, connection resolution, and result set processing can be carried out using the specification interfaces. Although in most cases the data source is relational-based, the specification interfaces does not require this.1 This allows developers to execute SQL in a vendor neutral fashion.
3.2.2 Servlet/JSP
Servlet technology is the mechanism used to create dynamic Web pages, in the same spirit that early Common Gateway Interface (CGI) technology was used to provide a personalized interaction with a Web site. Servlet technology allows browser resident clients to interact with application logic residing on the middle tier using request and response mechanisms of the HTTP protocol.
JSP technology is built upon servlet technology. Its purpose is to help blend HTML-based page definition and dynamic-based Java expressions into a single HTML-like document resource.
3.2.3 EJB
EJBs support the ability to create distributed components that can exist across Java application process boundaries and server topologies. More than simply providing access to distributed objects, the specification supports transactions with two-phase commit support, security, and data source access.
EJB technology is utilized to help support scalable application architecture by making enterprise business logic and data available and accessible to Web container function. EJBs' ability to support transactions across server boundaries in a distributed fashion is key to supporting large-scale, transaction-based applications.
3.2.4 Connector
EJB technology provides a distributed transaction-based environment for external resources. In many, but not all, cases these sources are relational based. The connector specification provides a mechanism for EJB technology to interact with other, non-relational resources in an implementation-independent manner.
3.2.5 JMS
JMS provides vendor-neutral point-to-point and publish/subscribe messaging solutions. The JMS service provider will provide an implementation based upon the JMS APIs. JMS is the primary mechanism in J2EE for allowing asynchronous communication between components. It can be used to provide asynchronous update of components running in networked client containers, or it can be used to allow asynchronous communication with back-end EISs.
3.2.6 Java Mail
This technology is a framework that implements an interface to an e-mail system. The framework is provided with J2EE in binary form. Also included is a set of APIs that support POP3 and SMTP mail protocols. While we will cover the other core J2EE APIs in this book, we will not cover Java Mail in any depth because, in truth, this API is rarely used.
3.2.7 JTA
Transaction support is abstracted using Java Transaction API (JTA). This API provides a generic API that allows applications, applications servers, and resource managers to participate in defining and executing heterogeneous transaction boundaries.
3.2.8 JAX-RPC
Java API for XML-based RPC (JAX-RPC) allows Java developers to create client and end-point Simple Object Access Protocol (SOAP)-based Web service functions. Developers can utilize Java-based classes to define Web services and clients that exercise Web-services, effectively shielding the developer from the complexity of interacting with the SOAP protocol. As with SAAJ and JMX, JAX-RPC is a required part of the J2EE 1.4 platform.
3.2.9 SAAJ
This technology (SOAP with Attachments API for Java) provides a Java API that allows the formatting of XML messages in conformance with the SOAP specifications. This should not be confused with JAX-RPC, which also supports SOAP, but provides Web services support for message composition and support for SAAJ, which allows the attachment of MIME-encoded binary documents to SOAP messages. SAAJ is a required part of the JAX-RPC API, so we will discuss it only within the context of JAX-RPC.
3.2.10 JMX
Java Management Extension (JMX) allows a generalized way that distributed and Web-based applications can provide monitoring and instrumentation services, independent of the vendor application server. We won't discuss programming to this API in WebSphere, but we will discuss how it is used in WebSphere administration.