2.2. J2EE Platform Architecture and Technologies

The technologies that make up the Java 2 Platform, Enterprise Edition, have been evolving since the introduction of the Java programming language more than five years ago. Many of them, such as Java Servlets, JDBC, and JavaIDL (providing application interoperability using the CORBA-standard Interface Definition Language), were introduced to simplify the development of the types of applications described in the previous section.

The basic value the J2EE platform adds to the mix is that it combines these technologies into a single, unified standard for building applications in a variety of configurations to suit these needs. Unlike the scenarios described above, which often require applications to be assembled using diverse programming models, APIs, and developer skill sets, the J2EE platform provides a unified programming model and a standard set of APIs. This means greater responsiveness when increasing the capacity of an application: the volume of hits it can handle, the number of transactions it can perform. In addition, with vendor-lock broken by J2EE, the underlying hardware and server software can be upgraded or replaced with minimal effect on the design or configuration of the application.

In addition, the architecture of the J2EE platform simplifies the development of applications by introducing the concept of redeployable components throughout the layers of multitier applications. The support for this architecture is implemented as two fundamental parts: components and containers. These are covered in detail in the next section, followed by a look at the standardized services provided to components by their containers.

2.2.1. Components and Containers

Components represent units of development and deployment, designed to be simpler to build than other models. They provide standardized functionality, have well-defined application interfaces, and can easily be developed and deployed for specific business purposes. Containers that support the components represent reliable, standardized services and a consistent environment from one product vendor to another. Containers are the mechanism by which J2EE supports the “Write Once, Run Anywhere” promise of the Java programming language. Containers provide automatic support for certain aspects of application behavior, such as Hypertext Transfer Protocol (HTTP) interaction, transaction management, and security. They also offer a set of standardized services that components can use to perform useful work.

The concept of components and containers is fundamental to the benefits of the J2EE standard. By enabling developers to focus on creating components to encapsulate application specifics, such as graphic look and feel, navigation, and business logic, the J2EE architecture reduces the amount of coding and debugging required to develop fully functional applications. By providing a model in which applications can be assembled from standardized components, J2EE improves the productivity of organizations and allows organizations to buy standardized behaviors off the shelf—expertise becomes a commodity in the J2EE marketplace. Vertical market components for doing inventory management, checkout services, or medical-records tracking are among the possibilities. Such commoditization means greater productivity, faster time to market, more reliability, and simplified application development. The expertise required to assemble fully functional J2EE applications isn't as skills-intensive as developing the underlying technologies supported by the J2EE platform. Organizations can focus on recruiting and training developers based on their understanding of the business needs of the organization, not just on their ability to solve arcane technical problems.

2.2.2. Containers

J2EE containers support the component-based application programming model in two major ways. First, they automate much of the standard functionality that requires programming expertise in other models, such as transaction management and security. And they provide standardized APIs in the Java programming language for other features of value to components, such as messaging (Java Message Service) and database access (JDBC). These container features unify the J2EE programming model, simplify application development, and support portability of both individual components and full-scale applications.

Because they're based on the Java 2 Platform, Standard Edition, containers provide standard features of the Java runtime environment automatically, including cross-platform development support and memory management to simplify debugging. In addition, the J2EE platform and component specifications define features and enhancements to containers that include security management, transaction management, lifecycle management, and other features.

Containers provide a working environment for their components. They provide a way for services to be “injected” into the operations of the components, without the component developer needing to write specific code. This is especially important in distributed application development, where the complexity of providing such services may be daunting.

One example of container intervention in a component is container-managed transactions in Enterprise JavaBeans. Container-managed transactions let multiple EJBs automatically work together in the same transaction, without the developer of each component needing to know or program any of the transaction details. This facilitates assembling applications from preprogrammed components. For example, when a store-front e-commerce application requires customer checkout operations to update customer and inventory records, an EJB representing a customer can be included in a transaction with inventory EJBs. This can work automatically, even with components developed at various times by different organizations, and even with components purchased from third-party vendors. This simplifies assembling complex J2EE applications from easy-to-develop and readily available components.

As another example of standardized service access, all J2EE components can use security mechanisms built into the platform. Containers can control access to components through these mechanisms, checking a client's access attributes for individual methods or whole interfaces. In addition, security attributes of components can be specified at deployment time, to ensure that the security model of the application maps to the security environment of the deploying organization.

Because J2EE containers were designed with input from a variety of enterprise platform partners, they can easily be implemented on top of existing information systems, and can interact effectively with services provided by those systems. This enables organizations to begin adopting J2EE-related technologies as needed, without having to completely redeploy all existing enterprise applications and data resources.

2.2.3. Java Servlet Technology

Java Servlet technology provides a basic mechanism for generating dynamic Web content. Think of them as Java applets for servers. Servlets were developed as an improvement over CGI scripts, which are generally platform-specific, and are limited in their ability to support rich interaction. Because servlets are based on the Java programming language, they offer several benefits over CGI, including portability, flexibility, and programming ease. In addition, they provide better performance because they are persistent—a servlet needs to be loaded into memory and initialized just once. It's then available to serve any user request. (In contrast, CGI scripts are loaded each time the server receives a user request; this consumes both memory and processor cycles, thus affecting scalability).

Like all J2EE components, servlets run in a container implemented by the J2EE platform provider. The container manages a servlet's interaction with its client and provides a rich environment for the servlet to use to access various services based on Java technology. A servlet container implements all of the Java 2 Platform, Standard Edition APIs. This makes a variety of technologies based on the Java programming language available to servlets, including JDBC, Java Naming and Directory Interface, RMI, JavaBeans, and others. The container can also implement features that allow servlets to share information about a particular client and session, overcoming the obstacles generally presented by the stateless HTTP protocol.

The flexibility of servlets is enabled through the servlet API, which implements a mechanism for more complex interaction with the requesting client than can CGI. Various servlet methods provide information to the servlet and allow it to respond. Because of the object-oriented programming model, items key to servlet behaviors are provided as objects with a well-defined API.

In a typical interaction (see Figure 2.5), the client, normally a Web browser, makes a request to a Web server via HTTP or HTTPS. When the Web server processes the request, it hands it off to the servlet container, which hands the request off to the appropriate servlet. The servlet is given a request object, which provides it with rich information about the request, including who called it, which HTML form parameters were sent with the request, and other information about the HTTP request. The servlet can send data back to the client via a response object. At any time during the processing of a request, the servlet can use a context object to log events, obtain Uniform Resource Locator references to resources, and set and store attributes that other servlets in the context can use. Similarly, a servlet may access a session object that provides it with information about client state.

In addition to defining servlets and their containers, the servlet specification defines the concept of a Web application. A Web application is a collection of servlets, JavaServer Pages, HTML pages, and supporting content, such as images, all intended to be deployed together to provide a complete, interactive experience on an intranet or the Internet. These resources are packaged together in a Web application archive (war) file that can easily be deployed on a Web application container—any Web server that supports the Java Servlets specification. For scalability, Web applications can be distributed across multiple Web application containers. Other features that Web application containers support include deploy-time security configuration, which enables an organization to enforce the access rules of the Web components and applications it deploys.

2.2.4. JavaServer Pages

JavaServer Pages technology builds on Java Servlet technology to simplify the development of dynamic Web content. JSP supports a page-based metaphor that conveniently separates dynamic and static Web content; the JSP page defines a static HTML template, with embedded calls to code written in the Java programming language to fill in dynamic portions of the page.

JSP pages contain four kinds of elements, each with a specific role in the presentation of dynamic content.

The combination of these four elements makes it easy to generate Web pages for client browsers. Because JSP is based on servlets, users benefit from the application support and other features built into Web application containers. These include portability, access to common services, the ability to maintain state and client-access information via common APIs, and other servlet benefits.

The advantage of the JSP model is that Web designers need not be familiar with the Java programming language to create sophisticated JSP pages. JSP is designed to enable Web authoring tools to automatically generate tags, scripting elements, and other HTML, and to enable the incorporation of dynamic elements by means of familiar drag-and-drop authoring techniques. Programmers can focus on providing JavaBeans and custom tags for use by the Web designer; organizations can even acquire custom behaviors from third-party developers.

This supports one of the higher goals of J2EE, separating the skill sets required to develop and assemble complex applications into more logical roles. Using J2EE technology and tools, Web-page designers and content providers can focus on presenting the best look and feel possible, without programming, while application programmers can develop complex behind-the-scenes behavior, without having to be user-interface experts.

2.2.5. Enterprise JavaBeans

In addition to servlets and JSP components for providing a rich user experience, the J2EE platform includes the Enterprise JavaBean component model for transaction-processing support. EJB provides a standard component architecture for building distributed, object-oriented business applications. Like the servlets and JSP component models, the EJB model is powerful because it provides separation of concerns.

• EJBs allow a programmer to focus on business logic without having to manage the details of transaction processing, security, load balancing, connection pooling, and other performance concerns in an application server system. These details are automatically handled by the EJB container implemented by the J2EE product provider. The EJB specification is designed to make it easy for container providers to build on legacy systems by “wrapping and embracing” existing technologies.

• The Enterprise JavaBean specification clearly defines the lifecycle of an enterprise bean, from development to deployment to runtime, and clearly divides the responsibility for relieving most concerns about such issues. By interceding between clients and components at the method-call level, containers can manage transactions that propagate across calls and components, and even across containers running on different servers and different machines. This mechanism simplifies development of both components and clients.

• EJBs can be implemented by trusted programmers who encode business logic, guaranteeing the integrity of corporate data. Then different user interfaces can be built on top. EJBs are client-neutral—a single EJB may be accessed from a Web client through JSPs or servlets, or it may be invoked directly by a Java application client in a standard two-tier model. Component developers are free to focus on business logic, since containers provide services automatically by interceding in component method calls. A simple set of callback interfaces are all a developer needs to implement to participate in container-provided services.

• EJBs allow business logic to be developed without regard to the details of a particular installation. A separate deployment descriptor is used to customize EJBs at the time they are assembled and deployed. Deployment descriptors are XML-based text files whose elements declaratively describe how transactions, security, and other installation specifics are to be handled in an EJB-based application. A variety of Enterprise JavaBean attributes, including the default component transaction type, can be specified at either development or deployment time and enforced through mechanisms built into the container architecture.

Like other J2EE components, EJBs support the “Write Once, Run Anywhere” paradigm of the Java programming language. An enterprise bean can be developed once, then deployed on multiple platforms, without source-code changes or recompiling. This allows application developers and deployers to purchase third-party components that perform common tasks, and to focus specifically on the custom behaviors required by their organization. In addition, the EJB architecture is designed to enable tools for the rapid development and deployment of enterprise beans. This helps further increase application development productivity, and ensures that appropriate skill sets can be applied to each application development task.

A client's view of an Enterprise JavaBean remains the same regardless of the container it is deployed in. Any container in which an Enterprise JavaBean is deployed presents the same interfaces to the client. This extends to containers from various vendors, running against different servers and databases, on diverse systems on a network. This client transparency ensures wide scalability for multitier applications.

The client view of an EJB is provided through two interfaces—the home interface and the remote interface. These interfaces are provided by classes constructed by the container when a bean is deployed, based on information provided by the bean. As shown in Figure 2.6, the home interface (cart home) provides methods for creating a bean instance, while the remote (cart) interface provides the business logic methods for the component. By implementing these interfaces, the container can intercede in client operations on a bean and offers the client a simplified view of the component (see Figure 2.6).

To the client, there appears to be direct interaction with an Enterprise JavaBean through the home and remote interfaces. However, the architecture of Enterprise JavaBeans is designed to enable clients and components to exist in different runtimes on various systems on a network. The container intercedes between client and component, completely concealing both the bean instance and its own actions from the client.

Container intervention enables transaction management, security constraints, container-managed persistence, and other important features of the EJB component model. The Enterprise JavaBeans architecture provides automatic support for distributed transactions in component-based applications. Such distributed transactions can atomically update data in multiple databases, possibly even distributed across multiple sites. The EJB model shifts the complexities of managing these transactions from the application developer to the container provider.

A container supports a variety of transaction properties for beans. Beans can be invoked entirely outside the context of a transaction. They can be required to initiate a transaction when they are called. They can be allowed to participate in an existing transaction when they are called by another bean. In addition to container-managed transactions, an Enterprise JavaBean can participate in client-managed transactions, or it can manage its own transactions using the Java Transaction API (JTA).

The EJB component model supports three types of beans: session beans, entity beans, and message-driven beans. Each is designed for specific, well-defined roles, so developers can easily pick the appropriate bean type for each specific architectural requirement.

Session Beans

Session beans represent behaviors associated with client sessions. They're generally implemented to perform a sequence of tasks within the context of a transaction. A session bean is a logical extension of the client program, running processes on the client's behalf remotely on the server.

Session beans are intended to be short-lived, as their name suggests, existing for the duration of a single interaction, or session, with a user. Session beans can provide simple, almost CGI-like behaviors. Stateless session beans are ideal for this role, since they retain no state between calls and are intended simply to perform one task at a time. They're also amorphous, in that any instance of a stateless bean can be used by any client at any time, at the container's discretion. They are the lightest weight and easiest to manage of the various Enterprise JavaBean configurations.

In contrast, stateful session beans can be used to track session data, such as maintaining running information on page hits. The information tracked by a session bean need not be directly represented in a database, although the bean may make JDBC calls to fetch and store data. Stateful session beans maintain state within and between transactions. Each stateful session bean is associated with a specific client. Containers can automatically save and retrieve a bean's state in the process of managing instance pools of stateful session beans.

The session-bean developer defines the home and remote interfaces that represent the client view of the bean. Tools for a container get information from the Enterprise JavaBean at deployment time by introspecting its classes and interfaces. They use this information to dynamically generate classes implementing the home and remote interfaces of the bean.

Entity Beans

Entity beans are intended to represent persistent objects, such as a record or a set of related records in a database. Entity beans could be developed to represent business records, such as a customer (name, address, phone) or purchase order (customer, items purchased, purchase price). Entity-bean methods provide operations for acting on the data represented by the bean.

The entity bean provides a mechanism for multiple users of an application to have shared transactional access to data. Because of their transactional, data-specific nature, entity beans are designed to be persistent and robust—a bean and any references to it are required by the EJB specification to survive the crash of an EJB container. This is enabled by ensuring that the state of each entity bean is transactionally stored in the database.

The entity-bean developer defines the home and remote interfaces that represent the client view of the bean (without actually implementing any code for these interfaces). The developer also defines finder methods to provide a way to access an entity bean by its contents. Finder methods are designed to be introspected and displayed by development and deployment tools. This enables a user to graphically manipulate entity beans in the process of developing applications.

As with session beans, the deployment tools provided by the container vendor generate additional classes for an entity bean at deployment time to implement the home and remote interfaces. These classes enable the container to intercede in all client calls on the same entity bean. They can be implemented to mix in container-specific code for performing customized operations and functionality. In addition to these custom classes, each container provides a class to provide meta data to the client. Finally, where specified by a particular bean, a container manages persistence of selected fields of the entity bean.

In container-managed persistence, entity bean data is automatically maintained by the container using a mechanism of its choosing. For example, a container implemented on top of an relational database management system may manage persistence by storing each bean's data as a row in a table. Or the container may use Java language serialization for persistence. When a bean chooses to have its persistence container managed, it specifies which of its fields are to be retained. In bean-managed persistence, the bean is entirely responsible for storing and retrieving its instance data. The EntityBean interface provides methods for the container to notify an instance when it needs to store or retrieve its data.

An entity bean can be created in two ways: by direct action of the client in which a create method is called on the bean's home interface, or by some other action that adds data to the database that the bean type represents. In fact, in an environment with legacy data, entity objects may “exist” before an Enterprise JavaBean is even deployed.

A client can get a reference to an existing entity bean in several ways. The client can receive the bean as a parameter in a method call. It can look the bean up through a finder method of the home interface. And it can obtain the bean as a handle, a runtime-specific identifier generated for a bean automatically by the container.

Message-Driven Beans

Message-driven beans—new in the EJB 2.0 standard and to be offered with J2EE 1.3 compatible products—provide a mechanism for constructing loosely coupled applications that can communicate indirectly using the queuing and subscription models supported by JMS. Message-driven beans provide a new and more flexible way to support some application configurations.

2.2.6. J2EE Standardized Services

The containers supporting the J2EE components provide a number of standardized services, specific to the needs of distributed, enterprise applications. These include:

• Communication services, including RMI-IIOP, Java IDL, the Java Message Service, and JavaMail.

• Enterprise services, including JDBC for database access, JTA for the Java transaction API, JNDI for Java naming and directory services, and the new connector API for encapsulating existing enterprise components as EJB.

• Internet services, including support for HTTP, Transport Control Protocol/Internet Protocol, Secure Socket Layer, and Extensible Markup Language via a variety of APIs.

Communications Services

To better support distributed applications with containers running on multiple machines, as well as to enable enterprise applications to communicate with one another more effectively, J2EE supports several standard communication technologies. These include RMI-IIOP, JavaIDL, JMS, and JavaMail as a means to communicate on a network, sending messages or invoking services.

The Object Management Group (OMG) has defined the Common Object Request Broker Architecture (CORBA) to allow object interfaces to be defined and invoked in a variety of programming languages and environments on a network. CORBA objects are defined using OMG's Interface Definition Language (IDL). OMG has standardized JavaIDL, allowing objects written in the Java programming language to participate in a distributed CORBA environment.

JavaIDL is now required as part of both the J2SE and J2EE environments. It allows objects written in the Java programming language to invoke other CORBA objects written in other languages, and vice versa, via OMG's Internet Inter-ORB Protocol. The use of JavaIDL requires that an IDL definition be compiled into Java programming language stubs and skeletons to support Java technology clients and servers.

RMI-IIOP is a simpler alternative to JavaIDL. It allows interfaces to be defined in the Java programming language instead of in IDL. The remote interface can be converted to IDL and implemented or invoked in another language, since RMI-IIOP uses the same on-the-wire protocol as JavaIDL (IIOP). RMI-IIOP thus provides interoperability with CORBA objects implemented in any programming language. J2EE allows Enterprise JavaBeans to be invoked via RMI-IIOP.

In contrast to JavaIDL and RMI-IIOP, the Java Message Service (JMS) provides an API for asynchronous messaging. Rather than invoke a service and wait for a response, a JMS message is queued for delivery, and control returns to the invoker. In addition to supporting specific message queues—for example, for a specific EJB, JMS supports publish-and-subscribe messaging in which any number of clients can subscribe to (request messages on) well-known topics in a hierarchy of topics, and any number of clients can publish to (send messages to subscribers of) a specific topic. JMS supports reliable, guaranteed delivery of messages. JMS support is optional in J2EE 1.2 and required in J2EE 1.3.

The JavaMail API supports a different kind of asynchronous messaging: electronic mail. The JavaMail implementation supports widely used Internet mail protocols, allowing J2EE components to send mail to users—for example, to confirm an on-line order. JavaMail abstract classes may be subclassed to support new protocols and functionality.

Enterprise Services

For access to database management systems and other existing enterprise computing resources, J2EE provides support for JDBC, JTA, JNDI, and connectors.

JDBC provides J2EE's database connectivity. Standard Query Language (SQL) commands or queries can be issued to a relational database, and the results returned to any Java application. The JDBC API supports stored procedures, transactions, connections, and user authentication. JDBC drivers may support connection pooling, distributed transactions, and caching of rows from the database.

JTA is the transaction API for J2EE. It provides the transactional integrity support used by EJB containers. It can also be used directly by Enterprise JavaBeans that choose to implement bean-managed transactions. JTA allows transactions to be started and completed, or aborted and rolled back. JTA also allows coordinated distributed transactions across multiple resources, such as two or more separate database management systems. When EJBs use container-managed transactions, the bean programmer does not have to make JTA calls; they are made automatically via the container.

JNDI provides access to a naming environment. It provides methods for performing directory operations, such as associating attributes with objects and searching for objects using their attributes.

JNDI is used for a variety of purposes. JDBC data sources and JTA transaction objects can be stored in a JNDI naming environment. A container provides an environment to its components via a JNDI naming context. JNDI can be used by components in a distributed application to locate one another and initiate communications. Existing corporate directory services can be accessed via JNDI.

The J2EE connectors architecture defines a standard mechanism for connecting J2EE components to enterprise resource planning systems, mainframe transaction processing systems, and database systems. Connector support is required in the 1.3 release of J2EE, but most earlier J2EE implementations provide some kind of connector functionality.

Connectors are intended to solve the problem of integrating m EJB container implementations with n enterprise information system products without building m x n separate bridges. The connector architecture assists with integration of security and transaction contexts and the flow of control between the two systems. Connectors provide a “wrap-and-embrace” solution to extend your legacy business logic and transaction processing systems with a flexible J2EE layer.

Internet Services

For access to Internet services, J2EE supports the HTTP, TCP/IP, and SSL protocols.

• TCP/IP (Transport Control Protocol over Internet Protocol) provides a mechanism to establish connections and reliably deliver streams of data between Internet hosts.

• HTTP (HyperText Transfer Protocol) is the basis of Internet browsers and Web servers. A client makes an HTTP request to a server, and HTML hypertext is returned via HTTP.

• SSL (Secure Socket Layer) provides a secure mechanism for clients to access hosts on the Internet, without someone eavesdropping or tampering with the messages.

In addition, new eXtensible Markup Language (XML) functionality is supported in J2EE 1.3. XML provides tagged data similar to HTML, but the tags describe the data rather than the way the data is displayed. XML can be used to transfer formatted data between applications or servers on the Internet—for example, for supporting transactions between businesses (B2B). Support for parsing XML and representing XML as objects is implemented and is being standardized at the time of this writing.