| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
The J2EE platform represents a single standard for implementing and deploying enterprise applications. The J2EE platform has been designed through an open process, engaging a range of enterprise computing vendors, to ensure that it meets the widest possible range of enterprise application requirements. As a result, the J2EE platform addresses the core issues that impede organizations' efforts to maintain a competitive pace in the information economy.
The J2EE platform is designed to provide server-side and client-side support for developing enterprise, multitier applications. Such applications are typically configured as a client tier to provide the user interface, one or more middle-tier modules that provide client services and business logic for an application, and backend enterprise information systems providing data management. Figure 1.1 illustrates the various components and services that make up a typical J2EE environment.
1.2.1.1 Multitier Model
As illustrated, the J2EE platform provides a multitier distributed application model. This means that the various parts of an application can run on different devices. The J2EE architecture defines a client tier, a middle tier (consisting of one or more subtiers), and a backend tier providing services of existing information systems. The client tier supports a variety of client types, both outside and inside of corporate firewalls. The middle tier supports client services through Web containers in the Web tier and supports business logic component services through Enterprise JavaBeansTM (EJBTM) containers in the EJB tier. The enterprise information system (EIS) tier supports access to existing information systems by means of standard APIs.
1.2.1.2 Container-Based Component Management
Central to the J2EE component-based development model is the notion of containers. Containers are standardized runtime environments that provide specific component services. Components can expect these services to be available on any J2EE platform from any vendor. For example, all J2EE Web containers provide runtime support for responding to client requests, performing request time processing (such as invoking JSP or servlet behavior), and returning results to the client. All EJB containers provide automated support for transaction and life cycle management of EJB components, as well as bean lookup and other services. Containers also provide standardized access to enterprise information systems; for example, providing RDBMS access through the JDBC API.
In addition, containers provide a mechanism for selecting application behaviors at assembly or deployment time. Through the use of deployment descriptors (text files that specify component behavior in terms of well-defined XML tags), components can be configured to a specific container's environment when deployed, rather than in component code. Features that can be configured at deployment time include security checks, transaction control, and other management responsibilities.
While the J2EE specification defines the component containers that must be supported, it doesn't specify or restrict the configuration of these containers. Thus, both container types can run on a single platform, Web containers can live on one platform and EJB containers on another, or a J2EE platform can be made up of multiple containers on multiple platforms.
1.2.1.3 Support for Client Components
The J2EE client tier provides support for a variety of client types, both within the enterprise firewall and outside. Clients can be offered through Web browsers by using plain HTML pages, dynamic HTML generated with JavaServer PagesTM (JSPTM) technology, or Java applets. Clients can also be offered as stand-alone Java language applications. J2EE clients are assumed to access the middle tier primarily using Web standards, namely HTTP, HTML, and XML.
To support more complex user interactions, it may be necessary to provide functionality directly in the client tier. This functionality is typically implemented as JavaBeansTM components that interact with the service in the middle tier via servlets. Client-tier JavaBeans components would typically be provided by the service as an applet that is downloaded automatically into a user's browser. To eliminate problems caused by old or non-standard versions of the Java virtual machine in a user's browser, the J2EE application model provides special support for automatically downloading and installing the Java Plug-in.
Client-tier beans can also be contained in a stand-alone application client written in the Java programming language. In this case, the enterprise would typically make operating system specific installation programs for the client available for users to download via their browsers. Users execute the installation file and are then ready to access the service. Since Java technology programs are portable across all environments, the service need only maintain a single version of the client program. Although the client program itself is portable, installation of the Java technology client typically requires OS-specific code. There are several commercial tools that automate the generation of these OS-specific installation programs.
If desired, non-Java clients such as Visual Basic programs can present J2EE services to users. Since the service is presented by servlets in the middle tier to first-tier clients using the standard HTTP protocol, it is easy to access it from practically any program running on any operating system.
1.2.1.4 Support for Business Logic Components
In the J2EE platform, middle-tier business logic is implemented in the middle tier as Enterprise JavaBeans components (also referred to as enterprise beans). Enterprise beans allow the component or application developer to concentrate on the business logic while the complexities of delivering a reliable, scalable service are handled by the EJB server.
The J2EE platform and EJB architecture have complementary goals. The EJB component model is the backbone of the J2EE programming model. The J2EE platform complements the EJB specification by:
1.2.1.5 Support for the J2EE Standard
The J2EE standard is defined through a set of related specifications, key among these the J2EE specification, the EJB specification, the Servlet specification, and the JSP specification. Together, these specifications define the architecture described in this discussion. In addition to the specifications, several other offerings are available to support the J2EE standard, including the J2EE Compatibility Test Suite and the J2EE SDK.
The J2EE Compatibility Test Suite (CTS) helps maximize the portability of applications by validating the specification compliance of a J2EE platform product. This test suite begins where the basic Java Conformance Kit (JCK) leaves off. The CTS tests conformance to the Java standard extension API's not covered by the JCK. In addition, it tests a J2EE platform's ability to run standard end-to-end applications.
The J2EE SDK is intended to achieve several goals. First, it provides an operational definition of the J2EE platform, used by vendors as the "gold standard" to determine what their product must do under a particular set of application circumstances. It can be used by developers to verify the portability of an application. And it is used as the standard platform for running the J2EE Compatibility Test Suite.
Another important role for the J2EE SDK is to provide the developer community with a freely available implementation of the J2EE platform to help expedite adoption of the J2EE standard. Although it is not a commercial product and its licensing terms prohibit its commercial use, the J2EE SDK is freely available in binary form to use in developing application demos and prototypes. The J2EE SDK is also available in source form.
One more word on J2EE standards and portability. The J2EE specifications have, by design, set the platform-compatibility-bar at a level that's relatively easy to clear. Owing to the collaborative way in which the platform specifications have been developed, it was deemed important to give platform vendors plenty of opportunity to supply implementations of the J2EE platform. Obvious and unreasonable implementation hurdles were avoided. For example, there are no restrictions on vendors adding value to J2EE products by supporting services not defined in the specifications.
It should therefore not be surprising that J2EE component portability is primarily a function of the dependency a component has on the underlying container. Components using a vendor-specific feature, that falls outside of the J2EE requirements, may have limitations in the area of portability. The J2EE specifications do however spell out a base set of capabilities that a component can count on. Hence, there is a minimum cross-container portability that an application should be able to achieve. Needless to say, an application developer expecting to deploy on a specific vendor implementation of the J2EE platform, should be able to do so across a wide range of operating systems and hardware architectures.
With a set of features designed specifically to expedite the process of distributed application development, the J2EE platform offers several benefits:
1.2.2.1 Simplified Architecture and Development
The J2EE platform supports a simplified, component-based development model. Because it's based on the Java programming language and the Java 2 Platform, Standard Edition (J2SETM platform), this model offers Write Once, Run Anywhere portability, supported by any server product that conforms to the J2EE standard.
The component-based J2EE development model can enhance application development productivity in a number of ways.
Maps easily to application functionality: Component-based application models map easily and flexibly to the functionality desired from an application. As the examples presented throughout this book illustrate, the J2EE platform provides a variety of ways to configure the architecture of an application, depending on such things as client types required, level of access required to data sources, and other considerations. Component-based design also simplifies application maintenance, since components can be updated and replaced independently--new functionality can be shimmed into existing applications simply by updating selected components.
Enables assembly- and deploy-time behaviors: Components can expect the availability of standard services in the runtime environment, and can be dynamically connected to other components providing well-defined interfaces. As a result, many application behaviors can be configured at the time of application assembly or deployment, without any recoding required. Component developers can communicate their requirements to application deployers through specific settings. Tools can automate this process to further expedite development.
Supports division of labor: Components help divide the labor of application development among specific skill sets, enabling each member of a development team to focus on his or her ability. Thus, JSP templates can be created by graphic designers, their behavior by Java programming language coders, business logic by domain experts, and application assembly and deployment by the appropriate team members. This division of labor also helps expedite application maintenance. For example, the user interface is the most dynamic part of many applications, particularly on the Web. With the J2EE platform, graphic designers can tweak the look and feel of JSP-based user interface components without the need for programmer intervention.
A number of generic roles are discussed in the J2EE specifications, including Application Component Provider, Application Assembler, and Application Deployer. On some development teams, one or two people may perform all these roles, while on others, these tasks may be further subdivided into more specific skill sets (such as user interface designers, programmers, and so on).
1.2.2.2 Scales Easily
J2EE containers provide a mechanism that supports simplified scaling of distributed applications, without requiring any effort on the part of the application development team.
Because J2EE containers provide components with transaction support, database connections, life cycle management, and other features that influence performance, they can be designed to provide scalability in these areas. For example, by providing database connection pooling, containers can ensure that clients will have access to data quickly.
Because the J2EE specifications allow server providers freedom to configure containers to run on multiple systems, Web containers can be implemented to perform automatic load balancing as the demand for a particular application fluctuates.
1.2.2.3 Integrating Existing Enterprise Information Systems
The J2EE platform, together with the J2SE platform, includes a number of industry standard APIs for access to existing enterprise information systems. Basic access to these systems is provided by the following APIs:
- JDBCTM is the API for accessing relational data from Java.
- The Java Transaction API (JTA) is the API for managing and coordinating transactions across heterogeneous enterprise information systems.
- The Java Naming and Directory InterfaceTM (JNDI) is the API for accessing information in enterprise name and directory services.
- The Java Message Service (JMS) is the API for sending and receiving messages via enterprise messaging systems like IBM MQ Series and TIBCO Rendezvous.
- JavaMailTM is the API for sending and receiving email.
- Java IDL is the API for calling CORBA services.
In addition, specialized access to enterprise resource planning and mainframe systems such as IBM's CICS and IMS will be provided in future versions of J2EE through the Connector architecture. Since each of these systems is highly complex and specialized, they each require unique tools and support to ensure utmost simplicity to application developers. As J2EE evolves, enterprise beans will be able to combine the use of connector access objects and service APIs with middle-tier business logic to accomplish their business functions.
1.2.2.4 Choice of Servers, Tools, and Components
The J2EE standard and J2EE brand are central to creating a marketplace for servers, tools, and components. The J2EE brand on a server product ensures the kind of ubiquity that's fundamental to the goals of the J2EE platform. In addition, J2EE standards ensure a lively marketplace for tools and components.
A range of server choices: Application development organizations can expect J2EE branded platforms from a variety of vendors, providing a range of choices in hardware platforms, operating systems, and server configurations. This ensures that businesses get a choice of servers appropriate to the strategic purpose of the applications they need.
Designed for tool support: Both EJB and JSP components are designed to be manipulated by graphical development tools, and to allow automating many of the application development tasks traditionally requiring the ability to write and debug code. Both J2EE server providers and third-party tool developers can develop tools that conform to J2EE standards and support various application development tasks and styles. Application developers get a choice of tools to manipulate and assemble components, and individual team members may choose tools that suit their specific requirements best.
A marketplace for components: Component-based design ensures that many types of behavior can be standardized, packaged, and reused by any J2EE application. Component vendors will provide a variety of off-the-shelf component solutions, including accounting beans, user interface templates, and even vertical market functionality of interest in specific industries. Application architects get a choice of standardized components to handle common or specialized tasks.
The J2EE standard and associated branding programming ensure that solutions are compatible. By setting the stage for freedom of choice, J2EE makes it possible to develop with confidence that the value of your investment will be protected.
1.2.2.5 Simplified, Unified Security Model
The J2EE security model is designed to support single signon access to application services. Component developers can specify the security requirements of a component at the method level, to ensure that only users with appropriate permissions can access specific data operations. While the EJB and Java Servlet APIs both provide mechanisms for building security checks into code, the basic mechanism for matching users with roles (groups of users having specific permissions) is performed entirely at application deployment time. This provides both greater flexibility and better security control.