The Java 2 Platform, Enterprise Edition

J2EE is a platform specification and branding initiative undertaken by Sun to provide a unified framework for developing and deploying component-based, server-centric, and multi- tier enterprise applications. Even though its specification is in constant and disciplined evolution through the Java Community Process, its mission is to support the ever-increasing complexities of today's and tomorrow's rigorous business application requirements. J2EE was officially released in late 1999, and it is still undergoing changes with each new release. The current release of J2EE is 1.3.

J2EE derives its benefits through a standards-based and proven architecture approach that is defined from the following elements of its specification:

• J2EE Platform ” A standard platform for hosting J2EE applications, which is specified as a set of required Java Technology Components and Service APIs .

• J2EE Application Programming Model ” A standard programming model for developing multi-tier applications.

• J2EE Compatibility Test Suite ” A suite of more than 15,000 demanding compatibility tests for validating the J2EE compliance of J2EE product providers, such as application development tools and application servers.

• J2EE Reference Implementation ” A reference implementation of the J2EE platform for demonstrating its capabilities and proofing its operational definitions.

Caution

J2EE is sometimes interpreted as being a specification as well as an application that can be leveraged to build robust and scalable server-centric business applications using the Java language. This is a misconception ; J2EE is purely a specification. However, J2EE can be downloaded from the Sun Web site with the infamous Pet Store example, which showcases best practices on how to use the technology toward an e-commerce application.

The following sections provide an overview of the elements of the J2EE specification that were discussed in this section. You will learn the benefits of the J2EE Platform and how you can derive a scalable, interoperable, and robust application from its specification elements.

The J2EE Platform ”Technology Component and Service APIs

If you are new to the J2EE platform, at the top of your agenda should be an easy comprehension of what it is. As stated earlier in this chapter, the J2EE Platform is a specification. You can also view it as a philosophy for developing scalable, robust, and interoperable business applications through the employment of Java Technology Components and Service APIs . What it is not is a shrink-wrapped application that you can use or customize immediately.

In order to understand the J2EE platform, you do need to understand the definitions of the following terms and review how they relate to each other as shown in Figure 1.2.

Figure 1.2. You should understand the technology components and service APIs that constitute the J2EE platform.

• Java Technology Component APIs ” Through the employment of the J2EE technology components, eSystems are developed as a suite of loosely coupled distributed components, which exist and are managed in the context of containers within a Java Web or J2EE Application Server. These containers provide deployment and runtime support for Java client applications, Web components (servlets and Java Server Pages), and server components (EJBs). They also provide a federated view of the services provided by the underlying application server for these components.

• Java Service APIs ” eSystems will always require one or more server-side services. The role of the J2EE Service APIs is to provide a common programming interface layer on top of multi-vendor, heterogeneous infrastructure services such as security, transaction management, messaging, email, and database access. Through this level of abstraction, the development team can focus on developing the core business functionality instead of building the infrastructure for that functionality. The following sections describe the Java technology component and service APIs that a J2EE 1.3 platform must support.

Java Servlet Technology 2.3

Java Servlets are platform-independent Java classes that are compiled to platform-neutral bytecode which can be loaded dynamically into and run by Java-enabled Web servers. They are regarded as Web Components, because their role is to generate dynamic content to Web clients via a request/response paradigm implemented by a Web container.

Servlets are similar to CGI but much easier to write, since servlets use Java classes and streams. They are also faster to execute because servlets are compiled to Java bytecode, and at runtime the servlet instance is kept in memory.

JavaServer Pages Technology 1.2

JavaServer Pages are considered Web components because their role is to generate dynamic content for Web-based applications. A JavaServer page is a text-based, presentation-oriented mechanism to develop servlets, as they also define how to process an incoming client request as well as generate a dynamic response. Like Servlets, JavaServer pages exist in the context of a Web container. They are compiled into Servlets by a J2EE-compliant application server, such as WebLogic Server, and hence are treated the same as Servlets at runtime.

To enable this operation, a JavaServer page is composed of static template data such as HTML, DHTML, XHTML, and XML. When combined with a JavaBeans class and tag libraries, JavaServer pages give you an easy way to keep content and display logic separate. The advantage of separating content and display logic allows content, graphics specialists, and Java developers to focus on their domains of expertise without having to be proficient in both content presentation and presentation logic.

Enterprise JavaBeans Technology 2.0

The J2EE specifications define a model for developing and deploying server-side Java components, and are therefore considered Server components . Enterprise JavaBeans (EJBs) are the foundation of the J2EE platform for addressing multi-tiered and distributed application architectures. The role of EJB components is to encapsulate business logic. There are three types of EJBs:

• Session beans ” Model coarse grained business services. There are two types of session beans: stateless and stateful . For stateless session beans, once the client communication ceases, the session beans are recycled back to the ready pool and prepared to serve new client requests. For example, "calculate product price" can be modeled as a stateless session bean. Stateless session beans do not maintain state between different client requests . On the contrary, stateful session beans model the interactions with the clients, hence maintaining the state for their corresponding client. For example, a Travel Agent client request can be modeled as a stateful session bean.

• Entity beans ” Enable persistent data communication with a client and a database. If the client terminates or if the server shuts down, the J2EE application server will ensure that the entity bean data is safely captured for recovery at a later point in time.

• Message-driven beans ” Enable asynchronous communication sessions with the Java Message Service (JMS) listener to allow for application interoperability and scalability.

EJBs exist and execute within an EJB container in the context of a J2EE-compliant application server, such as BEA WebLogic Server 7.0. It is the role of the J2EE application server to provide a scalable, high-performance, and stable runtime environment for EJB components, as well as manage and recycle the resources required by EJBs during their execution, such as security, memory, CPU utilization, network sessions, database sessions, and threads. For this reason, the application developer does not have to worry about coding for infrastructure services such as database access, transaction support, security, caching, and concurrency.

Tip

Since EJBs are the most resource- intensive technology that implement business logic in the J2EE specification, you will need a high-end application server that implements an efficient resource recycling mechanism in the EJB container, such as the WebLogic Server 7.0.

JDBC 2.0 API

The JDBC specification is essentially a bridge to invoke SQL commands from the Java programming language methods to a relational database management system (RDBMS). For example, you can use the JDBC API to access a RDBMS from a Servlet, JavaServer page, Session bean and Entity bean.

JDBC is modeled on the Open Database Connectivity (ODBC) specification and is therefore fairly simple and well established. Just like ODBC drivers, JDBC accomplishes database connections by using a driver mechanism that translates JDBC calls to native database calls. The JDBC API is composed of two parts : an application-level interface used by J2EE components to access a database, and a service provider interface to attach a JDBC driver to the J2EE platform.

There are four types of JDBC drivers that you can use:

1. Type 1 is a JDBC-ODBC bridge, which comes with the J2EE Java Development Kit (JDK). The ODBC driver is required to be installed on the connecting client machine.

2. Type 2 drivers convert the JDBC calls that a client application invokes into the native calls of a native driver currently installed on the client machine. Hence, this type of JDBC driver requires the native database driver from the database vendor to be installed on the client machine as well.

3. Type 3 drivers make no use of native drivers on the client machine and hence are portable across platforms that support a Java Virtual Machine, enabling all communications with an RDBMS to be channeled thorough it.

4. Type 4 drivers are written in 100% pure Java and communicate directly with an RDBMS using proprietary network protocols. Unlike Type 1 and Type 2 drivers, Type 4 drivers do not require any pre-configuration of the client machines.

For these reasons, it is important that you select the appropriate JDBC driver suited for your application environment.

Java Message Service 1.0

The JMS API is the J2EE messaging standard that supports the asynchronous exchange of messages between J2EE components. The distributed communication between J2EE components is loosely coupled, since sender and receiver components do not need to be aware of each other and hence can operate independently.

The JMS API supports two messaging models:

• Point to point , which is based on message queues. In this model, a message producer sends a message to a specific queue. A message consumer can attach itself to a queue to listen for its incoming messages. When a message arrives on the queue, the consumer takes it off and responds to it. However, message consumers do have the capability to filter messages to specify the exact message types they are waiting for.

• Publish and subscribe is a model where message producers send messages to a topic queue. All registered message consumers for that topic queue are then able to retrieve these messages.

Java Transaction API 1.0

The Java Transaction API (JTA) forms the basis of managing the transaction-consistency and integrity of distributed transactions, primarily on behalf of JMS, EJBs and JDBC 2.0. JTA is a high-level API that consists of two parts:

1. A Transaction Interface that enables transaction demarcation . This allows transactions derived from distributed components to be bound by a global transaction. This is purely a means of creating one logical unit of work from groups of transactions.

2. XA Resource Interface is based upon the X/Open/XA interface that enables the handling of distributed transactions requiring a Two Phase Commit.

To learn more about the JTA and the XA Standard, see "XA-Compliant Resources," p. 539 .

Typically, you will not need to be concerned about programming explicit transactions with JTA, since that work is done through the JDBC and EJB APIs handled by the container and configured by the application deployment descriptor.

JavaMail Technology 1.2

Email is an integral part of every corporate workplace, and when business applications have to reach the masses of an organization, you can be assured some form of integration with an email system will be required. The JavaMail API, in conjunction with a JavaMail service provider, allows email capabilities from the J2EE platform.

JavaBeans Activation Framework 1.0

The JavaBeans Activation Framework is a requirement to support the JavaMail API, since its services determine and perform operations on email messages.

J2EE Java Connector Architecture API 1.0

The Java Connector Architecture (JCA) is one of the first attempts by the Java Community Process to establish standards in the application integration arena, establishing an awaited addition to the J2EE set of specifications. JCA is focused on the design of adapter software used to connect J2EE applications to heterogeneous, non-Java information systems (EIS), legacy databases, and software packages, such as SAP R/3, CICS, PeopleSoft, JD Edwards, and Baan.

The connector architecture enables an EIS vendor to provide one standard resource adapter that can be plugged in to any J2EE application server that supports JCA. This resource adapter is basically a J2EE component that implements the JCA for a specific EIS, and is deployed to an application server as a Resource Adapter Archive (RAR file) or within the context of an Enterprise Application Archive (EAR file).

A resource adapter implements two types of contracts that enable access to its EIS from within the application server, as illustrated in Figure 1.3.

Figure 1.3. Access an EIS through a Resource Adapter and its Contracts.

The Application Contract defines the API that enables J2EE application components (Servlets, JavaServer Pages, and EJBs) to access and transact with the EIS. Since the resource adapter exists in the context of an application server, services required to facilitate communication between the J2EE components and the EIS, such as transaction integrity, security, and connection pooling, are leveraged fully from the application server. To enable the use of these application server services, the JCA defines the following types of System-Level contracts:

• The Transaction Management Contract enables the transaction managers within the application servers to communicate with the resource manager within the resource adapter to ensure transaction integrity.

• The Connection Management Contract enables the application server to pool connections to the target EIS, hence providing a scalability solution to the number of connections requiring access to the EIS.

• The Security Contract provides a secure mechanism for the J2EE components to access the EIS, as well as providing security to protect the EIS itself from unauthorized access to restricted information.

Note

The System-Level contract only exists between the application server and the resource adapter and is transparent to the J2EE components accessing the EIS.

Currently and for the short- term future, the resource adapter will be specific to its EIS, requiring J2EE application server vendors to collaborate with EIS vendors in the development of specific resource adapters to keep all system-level mechanisms ”transactions, security, and connection management ”transparent from the J2EE components. However, the objective is that one day the application adapters will become commodities like database drivers, allowing application integration vendors to focus on providing scalable and reliable integration solutions rather than locking customers into proprietary application adapters.

Note

The JCA 1.0 specification is a significant extension to J2EE, yet it falls short of meeting all the requirements of application integration projects. For this reason, J2EE integration with non-Java enterprise information management systems will continue to depend partially on proprietary solutions. The WebLogic Integration 2.0 product, which is part of the WebLogic Platform, does provide extensive support for integration with non-Java systems beyond the JCA 1.0 specification. To ensure a non-proprietary solution to integration requirements, BEA is playing a leading role in driving the new JCA 1.5 specification.

Java Naming and Directory Services API

The JNDI API is the standard Java API for naming and directory access. The role that JNDI plays in the J2EE architecture is in minimizing dependencies between clients and services.

Since the components of a J2EE application run separately and often in disparate environments, there needs to be a means for client and application server tier code to look up and reference other code and resources. Client and application code use the JNDI to look up user -defined objects, such as Enterprise Beans, and environment entries, such as the location of the JDBC DataSource objects for looking up resources in the data tier.

Tip

JNDI promotes location transparency of client services, and hence the ability to make server-side changes to those services without cascading those changes to any dependencies, such as EJBs, Servlets, and JavaServer Pages, using those services.

Java API for XML 1.1

eXtensible Markup Language (XML) is a meta language defined by the World Wide Web Consortium (W3C) for representing, through a set of rules, guidelines, and conventions, a text-based cross-platform data format. Through these standards, XML allows applications to transfer both page content and information on how the content is structured.

Note

XML is similar to HTML in that it uses tag and attribute constructs in its definition of the data in a file. However, HTML specifies the definition of each tag and attribute, as well as their presentation attributes in a browser. XML, on the other hand, only uses tags to structure the data and does not define any of the presentation semantics of that document. The structure of the data contained within an XML document is described in a Document Type Definition (DTD) or XML Schema. Applications that support XML can communicate and exchange data without any prior knowledge of each other, as long as they share or are capable of interpreting the DTD or the XML schema.

There is a very strong relationship between Java and XML to build interoperable and cross-platform applications. Java enables you to construct portable applications across multiple hardware platforms, while XML enables the data to be portable across many applications, regardless of their implementation technology.

To address the increasing use of XML as a mechanism to exchange and process data between applications, the Java API for XML Processing (JAXP) has been introduced into the J2EE specification to support Java applications that need to process XML data. The JAXP API enables Java-based applications and components to process and transform XML data completely independent of a particular XML parsing (processing) technique. For example, standards-based XML parsers such as the Simple API for XML Parsing (SAX), Document Object Model (DOM), and XML Stylesheet Language Transformations (XSLT) are all supported by the JAXP API. The advantages of such an approach allows you to have the flexibility to swap out or select the XML parsing technique that best meets your XML processing requirements without any modifications to the Java application code.

For detailed information on XML standards, please refer to the World Wide Web Consortium Web site (www.w3.org/XML).

For a detailed discussion on how XML data is processed within the context of the WebLogic Server 7.0, see Chapter 29.

Java Authentication and Authorization Service 1.0

JAAS extends the security architecture of the Java 2 Platform (Standard and Enterprise Edition) by providing the following easy-to-use mechanisms:

• An authentication mechanism for users to determine who is currently executing the Java code without depending on the underlying authentication system. Through the use of JAAS, an authentication system can be swapped without any ramifications to the Java application code.

• An authorization mechanism for users to ensure they have the access control rights required to do perform their operations, through an extension to the security policies that govern what access rights are granted to the executing code at runtime.

J2EE Application Programming Model

In today's aggressive economy, organizations are slowly realizing the Time-To-Share paradigm where sharing data, information, and knowledge is imperative to succeed and gain that extra competitive edge. They are building complex business applications, which, perhaps not today but in the future, may need to communicate between each other in a transactional manner. It is also true that most business application development efforts are not all development, but also entail a high degree of integration plumbing work to interface legacy enterprise information systems (EIS) that are deemed as being important to the value of the business application. How is this going to be possible if the applications are built using different technologies and on multiple operating system platforms?

The solution is that organizations need to wake up to Java and the J2EE platform for developing all their enterprise server-centric applications. The J2EE Application Programming Model offers a component-based and multi-tiered approach to the design, development, assembly, and deployment of enterprise applications. This model not only reduces the application development cost, but also enables a fast track for the design, development, and deployment of application logic. The following sections will expand on the benefits of the J2EE Application Programming Model.

The Benefits of J2EE Components

J2EE components are pre-built pieces of Java application logic code that can be assembled with other components to form a complete J2EE application. J2EE components exist in the context of a container environment, which can be implemented on an application client, Web server, or Application server. The role of the container is to provide a runtime environment for the component, providing services required for its execution. J2EE application servers and containers will be discussed later in this chapter.

The J2EE Application Programming Model defines four types of J2EE components as follows :

• Application clients are Java GUI programs that execute on a desktop computer and can fully interact with all the facilities of a J2EE Web or application server.

• Applets are GUI components that can execute in a Web browser or a variety of other applications or devices that support the Applet container, which is composed of the applet programming model, the Java 2 Platform Standard Edition, and JNDI.

• Web components exist in the context of a Web Container within a J2EE-compliant Web server. Web components are comprised of servlets, JavaServer Pages, Web filters, and Web event listeners.

• Server Components exist in the context of an EJB Container within a J2EE-compliant application server. Enterprise JavaBeans are the only server components currently within the J2EE specification.

Many people confuse Java objects with J2EE components. Even though they may share the same language, they are constructed quite differently to promote reuse as follows:

• Java objects offer reuse through inheritance.

• J2EE components offer reuse through encapsulation.

Embracing J2EE component-based development offers the following benefits:

• Higher productivity through the reuse of components, which are pre-built and pre- tested .

• Rapid development, since components can be assembled very quickly and deployed to form an application.

• Better testing methods, and hence high-quality deployed applications, since application developers can concentrate on testing their components before they are deployed for integration testing.

• Easier maintenance, since components are relatively standalone pieces of Java code.

The J2EE specification relies upon the application server (WebLogic Server) to provide the required infrastructure support (security, transaction, persistency, high availability, and high scalability) allowing the developer to focus on the implementation of the business solution.

Multi-Tiered Architecture

The J2EE platform uses a multi-tiered distributed application model where

• An application's logic is divided into Web (servlets or JavaServer Pages) or Server (EJB) components, according to the functionality desired.

• The residency of the application components depends on which tier in the multi-tiered J2EE environment the application component belongs in.

The tiers of a multi-tiered J2EE environment are defined as follows:

1. Client Tier

   The client tier's role is to present information and collect input from the end user through an interface display such as an Internet browser, PDA, or cellular phone displays. J2EE technology supports multiple client presentation technologies, including Hypertext Markup Language (HTML) clients, Java applets, Extensible Markup Language (XML) documents, and Java technology-based standalone clients.

   However, for simple interfaces and Internet applications, the Web browser is regarded as the Web client of choice, primarily because of its widespread adoption, inherent multi-platform support, and above all, a built-in Java virtual machine to run Java components.

2. Web Tier

   This tier's role is to accept user input from HTML, applet, and XML clients in order to generate the appropriate response to the J2EE client. The Web tier exists on a Java-compliant Web Server, and is implemented using servlet or JSP J2EE technology components.

3. Business tier

   The role of the business tier is to implement presentation or business logic through the employment of Enterprise JavaBean (EJB) J2EE technology components. EJBs exist in the context of an EJB container, a runtime environment within J2EE-compliant application servers such as WebLogic Server 7.0. The role of the container environment is to manage the services the EJB may require: for example, security, state, and transaction management.

4. Enterprise Information System (EIS) Tier

   The Web and Business tiers interact with other enterprise information systems such as databases, mainframes, or other legacy systems in order to Create, Read, Update, or Delete (CRUD) data or information. J2EE applications communicate to the systems that form the EIS tier through the JDBC, JNDI, JMS, and JavaIDL J2EE service APIs.

The J2EE application programming model depicts four distinct application tiers. In practice, however, you will find that most J2EE applications are implemented using a three-tiered model based on the locations of the J2EE application components since the Web and Business tiers are sometimes collectively referred to as the Application Server Tier , as illustrated in Figure 1.4.

Figure 1.4. The J2EE three-tier architecture.

J2EE Compatibility Test Suite

There are hundreds of J2EE product providers that produce Web and application servers, platform APIs, and development tools. The J2EE Compatibility Test Suite (CTS) helps J2EE product providers validate that their products meet the requirements of the J2EE platform specifications.

The J2EE Compatibility Test Suite is a standard set of more than 15,000 test cases derived from the J2EE specification requirements. The products that pass the CTS are considered J2EE compliant and may display the Java Compatibility Logo. The Java Compatibility Logo is an extremely useful aid for selecting J2EE products you may need in the application development process.

Note

For more information on the J2EE Compatibility Test Suite, please visit the SUN CTS Web site at http://java.sun.com/j2ee/compatibility.html.

J2EE Reference Implementation (RI)

The primary role of the J2EE RI is to demonstrate the operational definition of the J2EE platform by passing the J2EE CTS without any errors, hence proving the J2EE specifications can indeed be implemented.

For this reason, the J2EE RI is considered a controlled benchmark for

• J2EE application developers to test the portability of their J2EE applications.

• Application server vendors to test the implementation of their Web and EJB containers and J2EE service APIs.