J2EE Overview - pearsoncmg.comptgmedia.pearsoncmg.com/images/032118579X/sample... · 26 Chapter 3 • J2EE Overview All J2EE technologies are built upon the Java 2 Standard Edition

25

C

H A P T E R

3

J2EE Overview

Over the years, the Java technology platform has grown out of its original applet client/serverorigins into a robust server-side development platform. Initial platform packages introducedbuilt-in threading support and provided abstractions to I/O and networking protocols; newer ver-sions of the Java Software Development Kit (SDK) continued to enhance these abstractions andintroduce newer framework offerings.

The momentum of producing technology frameworks supporting enterprise server-baseddevelopment has continued, and has been formalized into the J2EE platform offering. The moti-vation of this offering is to provide developers with a set of technologies that support the deliv-ery of robust enterprise-scale software systems. IT professionals are presented with an ever-changing business and technology landscape. Technology professionals must balance thedemands for new automation requirements against the existence of existing line of businessapplications; simply using the technology du jour perpetuates the problem of integrating existinglegacy systems. The goal of the J2EE platform is to offer a consistent and reliable way in whichthese demands can be met with applications that possess the following characteristics:

•

High Availability

—Support and exist in a 24/7 global business environment.•

Secure

—Ensure user privacy and confidence in business function and transactions.•

Reliable and Scalable

—Support high volumes of business transactions accurately andin a timely manner.

This chapter offers an overview of the J2EE architecture, a brief discussion of the specifi-cation’s component design and the solutions they provide, and describes which J2EE technolo-gies this book will focus on.

First, some background.

chapter 3.fm Page 25 Thursday, November 13, 2003 11:39 AM

26 Chapter 3 • J2EE Overview

All J2EE technologies are built upon the Java 2 Standard Edition (J2SE). It includes basicplatform classes, such as the Collections framework, along with more specific packages such asJDBC and other technologies that support client/server-oriented applications that users interactwith through a GUI interface (e.g., drag-and-drop and assistive technologies). Note that platformtechnologies are not limited to framework implementations. They also include development andruntime support tools such as the Java Platform Debugger Architecture (JPDA).

Technologies specific to developing robust, scalable, multitiered server-based enterpriseapplications are provided within the J2EE platform offering. While still supporting client/server-based architectures, J2EE platform technologies provide support for distributed computing,message-oriented middleware, and dynamic Web page development. This chapter and most ofthis book will deal specifically with some of these technologies. In particular, WebSphere 5.0(the focus of this book) implements the J2EE 1.3 platform specification. A list of the technolo-gies from J2EE 1.3 (along with the supported levels) is shown in Table 3.1.

Table 3.1

J2EE technologies.

Supported Technology Level required by J2EE 1.3

Java IDL (Interface Definition Language) API (Provided by J2SE 1.3)

JDBC Core API 2.0 (Provided by J2SE 1.3)

RMI-IIOP API (Provided by J2SE 1.3)

JNDI API (Provided by J2SE 1.3)

JDBC Extensions 2.0

EJB (Enterprise Java Beans) 2.0

Servlet API 2.3

JSP (JavaServer Pages) 1.3

JMS (Java Message Service) 1.0

JTA (Java Transaction API) 1.0

JavaMail 1.3

Java Activation Framework (JAF) 1.0

JAXP (Java API for XML Parsing) 1.1

Java 2 Connector Architecture (J2C) 1.0

JAAS (Java Authentication and Authorization Service)

1.0


27

In addition to the required technologies for J2EE 1.3, WebSphere Application Server 5.0implements a number of J2EE-compatible technologies in advance of support of J2EE 1.4. Inparticular, WebSphere also supports technologies which will be required in J2EE 1.4 (Table 3.2).

3.0.1 J2EE Component Design

One of the most appealing features of object technology is its ability to combine function anddata into a single element, also referred to as an object. Arguably, a single object implementationcould be classified as a component, but components offer more functionality than providingaccess to data and performing functions against this data. Flexibility is achieved with designsthat can consist of multiple classes related through composition and inheritance. The word com-ponent implies that they are a part of something whole, indicating that components require somekind of reference problem space where they can be applied. The J2EE specification provides thisframe of reference for components that can be used, extended and combined by developers todeliver robust enterprise applications.

J2EE components defined for the platforms exploit the OO nature of Java by applyingdesign patterns that provide both white and black box extensibility and configuration options.The platform components use inheritance and composition throughout their design, providing away for custom configuration by developers. Also, defining components in an abstract way canallow systems built using those components to work regardless of how each vendor implementseach concrete component implementation.

Studying these design techniques employed in the platform implementations can helpmake your own designs more elegant. These object design techniques are nothing new and havebeen applied throughout the years in other OO languages. Two design themes that take differentapproaches in supporting component configuration are discussed in the following sections.

3.0.2 Configurable Implementations

A specific design technique often used in the J2EE platform is the notion of describing com-pletely abstract designs (through the use of interfaces) that allow the entire implementation to beconfigurable. This means that developers are aware of, and have visibility to, a set of interfacetypes without regard to how they are implemented; implementation is the vendor’s responsibil-ity. This allows developers to choose the best available solutions. Figure 3.1 shows the dual rela-tionship interfaces create between developers and vendors.

Table 3.2

J2EE 1.4 technologies implementedby WebSphere 5.0.

J2EE 1.4 Technology

JAX-RPC (Java API for XML-based RPC)

SAAJ (SOAP with Attachments API for Java)

JMX (Java Management Extensions)



3.0.3 Configurable Algorithms

Not all technology implementations are exclusively interfaces. Most have a combination of gen-eralized class definitions that interact with interface types. Consider the servlet package; it pro-vides a

javax.servlet.GenericServlet

implementation that is defined abstractly along withproviding a servlet interface type. While this may seem redundant, designers of the servlet APIhave provided a way for developers to take advantage of an abstract configurable algorithm, andhave provided an abstract configurable implementation that can serve as the basis of a concreteimplementation. (For more on this dual nature, see the discussion comparing abstract classes andinterfaces.)

A

BSTRACT

C

LASSES

OR

I

NTERFACES

?

Inheritance is a feature of the OO paradigm that captures the imagination of developers when they first encounter this technology. The ability to define and classify hierarchies of data structures and create state and behavior that is extended for specific functionalities provides an excellent way to deliver solutions that can be extended in a white box manner.

White box-based designs utilize inheritance by implementing a base class that is extended by developers, and the appropriate elements are overridden with the desired functionality. Java provides language constructs that help communicate what can and cannot be overridden at construction time. Methods and class definitions can be defined as abstract, requiring developers to supply concrete implementations. Access modifiers such as final and private can be utilized to prohibit methods from being overridden. Combining these elements effectively can yield what is referred to as a configurable algorithm. The base class implements generalized methods that perform a set of algorithmic steps. Within this scope of base methods calls, abstract methods appear that are overridden, fulfilling a given method’s implementation.

Using inheritance exclusively can result in deep hierarchies that may lead to coupled implementations, usually the result of an abstract design that requires a large number of abstract methods to be implemented. Java interfaces provide an alternative abstract mechanism that allows for a more independent implementation without regard to an existing hierarchy.

Inheritance is useful for designs that have algorithms or behavior that can be generalized and utilized by extending classes. Designs that require most or all of its implementation to be defined by extending classes can be

Figure 3.1

Relationship between developers and vendors.

Technology Interfaces

Vendors DevelopersImplement Reference


29

communicated using interface definitions. Implementers are given complete freedom in how the interface methods carry out their operations. However, interfaces enforce a more rigid contract, and changing an interface design can make a larger impact on existing implementations. Therefore, an effective way to evolve a design, in lieu of booking a lot of initial design time, is to initially utilize inheritances and let an abstract design evolve. Once the required signatures have been discovered, and it turns out that a configurable implementation is necessary, interface(s) can be produced.

Configurable implementations utilizing interfaces are the underpinnings of providing vendor-independent J2EE technology designs.

Interfaces and effective abstractions are the means by which J2EE components achievevendor neutrality. The J2EE specifications simply define the APIs, types, life cycles, and interac-tions of objects within the technology frameworks. Vendors can then apply their efforts towardthe agreed-upon contracts and specifications. Developers write to these specifications. You mayask: “Won’t that create a dependency on these contracts, and if they change,won’t my code beaffected?” The short answer is yes, you are dependent upon versions of these contracts, butengaging them in a consistent way and knowing that they are community supported should helpminimize this concern.

In addition to describing WebSphere Application Servers as a J2EE implementation prod-uct, this book will provide patterns and approaches for neutralizing this dependency.

3.0.4 Who Defines These Specifications?

Another key advantage of Java and the J2EE standard is the way in which component solutionsare identified and defined. Early on, Sun promoted the openness of the Java language, initiallyby giving it away.

Advancement of Java technology and the formulation of the J2EE specification have beencarried out by the JCP (Java Community Process). Community is the operative word; any inter-ested individual or organization can participate. For individuals participation is free; organiza-tions pay nominal dues. Delegates from the membership propose, review, and accept technologyspecification proposals. While not an open source initiative, but under a community license thatstill allows Sun to be steward of the language, the JCP encourages community participation.

Ideas are proposed through the creation of a Java Specification Request (JSR). Membersevaluate and vote on the JSR for merit. Once accepted the JSR becomes an official technologycomponent and goes through the design and development process by a committee made up JCPmembers—usually a cross section of well-known vendor members.

The advantage of community participation is the proliferation of new frameworks/com-ponents that are derived and designed from a wide point of view, arguably larger than propri-etary-based technology that may be more influenced by market pressures. These marketpressures still exist in the JCP environment, but the checks and balances of the membership canmake them have less influence over the manner in which the problem is solved.



Of course, there is a down side to this approach. Whereas a company can be very nimblein getting a solution out the door by using a custom-built design, standardized solutions mustreceive approval and validation from the community which can take time.

3.1 Why J2EE?

Reuse is an adjective that can beckon the attention of developers, managers, and bean counters.It promises savings in the form of shorter development efforts and higher quality. Unfortunately,reuse has been oversimplified, and overhyped, resulting in a minimized impact. For instance,some reuse (of the base class libraries) occurs just through using Java as a programming envi-ronment. If you add J2EE components, more reuse occurs. Of course, this is not the businessdomain type of reusability that would allow us to snap together applications as in the proverbialIC chip analogy made by Brad Cox. Nevertheless, Java’s OO nature and the standards of J2EEare a progression toward achieving high degrees of reuse.

J2EE-based technologies provide what can be classified as horizontal technology reuse(Figure 3.2). Contracts, primarily in the form of Java interfaces, allow developers to use vendor-supplied technology solutions with a high degree of transparency. Imagine if the JDBC specifica-tion did not exist and developers had to write directly to vendor-supplied APIs; of course, then-

Figure 3.2

Horizontal technologies.

Accounts Receivable

Framework

Invoicing

Framework Printing

Framework

Controller Servlet Framework

Persistence Framework


J2EE Architecture 31

good OO developers would build designs that would decouple and wrapper vendor-specific APIswith a neutralized access API. Even though SQL is also a standard, each new target SQL-baseddata source would require a modification to this neutral API.

Fortunately, the JDBC specification allows the burden of access APIs to be moved to ven-dors. Developers simply acknowledge the specified contracts and generalized implementationsand use them in applications to execute SQL against any vendor honoring the JDBC specifica-tion, which most, if not all, do.

Other horizontal technologies are vendor neutralized in a similar approach, allowingdevelopers to concentrate on application-specific logic by using standards-compliant solutions.This frees developers from worrying about having to produce or refactor a horizontal implemen-tation. Instead, the best vendor-supplied solutions can be engaged, resulting in shorter deliverytimes of applications that are robust and scalable.

3.2 J2EE Architecture

Planes, trains, and automobiles are all assembled using well-accepted blueprints and parts sup-plied by countless vendors. One way that this is carried out is through industry-accepted blue-prints that define specifications for construction and how they are to be used. Under this samepremise, the J2EE specification defines these interfaces, their life cycles, and interactions theymust carry out. The specification also describes roles that can be held by resources involved inthe development and deployment of server-based applications.

The J2EE specification introduces an architectural concept of a container. Containers aredefined to house J2EE components within a layer boundary. Containers manage component rela-tionships within tiers and resolve dependencies of components between these tiers. Figure 3.3illustrates the J2EE containers and their associated component dependencies.

To understand where these components exist within the topology of an application, con-sider 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; providesa mechanism for distribution of business objects and for transactional support ofcomplex business interactions.

•

Information Systems Back End

—A database, messaging system, or EIS that providesdata and functions to the system.

Applications may utilize all or, at a minimum, the client and Web tiers; within each tierJ2EE technologies will be engaged to perform application functions. Some will occupy an obvi-ous 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’seasy 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. Thisreflects the foundation for all containers. Other technologies shown may or may not appearwithin a container definition because they are determined by application requirements. The fol-lowing 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 resolu-tion, and result set processing can be carried out using the specification interfaces. Although inmost 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.

Figure 3.3

Container diagram.

1. The JDBC design is slanted toward row-based result sets, therefore the majority of JDBC support comes from relational database vendors.

J2SE

Web Container

JSP Servlet

JAX,RPC

SAAJ

Mgmt

JMX

JavaMall

JTA

Connecto

rsJM

S

Web S

rcvsJA

CC

JAX

R

Web Container

J2SE

EJB Container

EJB

JAX,RPC

SAAJ

Mgmt

JMX

JavaMall

JTA

Connecto

rsJM

S

Web S

rcvsJA

CC

JAX

R

EJB Container

iiop

http

iiop

ClientContainer

J2SE

Application ClientContainer

JAX,RPC

SAAJ

Mgmt

JMX

Web S

rcvs

JAC

C

JAX

RJ2SE

Applet Container

Applet Application


J2EE Architecture 33

3.2.2 Servlet/JSP

Servlet technology is the mechanism used to create dynamic Web pages, in the same spirit thatearly Common Gateway Interface (CGI) technology was used to provide a personalized interac-tion with a Web site. Servlet technology allows browser resident clients to interact with applica-tion logic residing on the middle tier using request and response mechanisms of the HTTPprotocol.

JSP technology is built upon servlet technology. Its purpose is to help blend HTML-basedpage definition and dynamic-based Java expressions into a single HTML-like documentresource.

3.2.3 EJB

EJBs support the ability to create distributed components that can exist across Java applicationprocess boundaries and server topologies. More than simply providing access to distributedobjects, the specification supports transactions with two-phase commit support, security, anddata source access.

EJB technology is utilized to help support scalable application architecture by makingenterprise 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 support-ing large-scale, transaction-based applications.

3.2.4 Connector

EJB technology provides a distributed transaction-based environment for external resources. Inmany, but not all, cases these sources are relational based. The connector specification providesa mechanism for EJB technology to interact with other, non-relational resources in an imple-mentation-independent manner.

3.2.5 JMS

JMS provides vendor-neutral point-to-point and publish/subscribe messaging solutions. TheJMS service provider will provide an implementation based upon the JMS APIs. JMS is the pri-mary mechanism in J2EE for allowing asynchronous communication between components. Itcan be used to provide asynchronous update of components running in networked client contain-ers, 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 frame-work is provided with J2EE in binary form. Also included is a set of APIs that support POP3 andSMTP mail protocols. While we will cover the other core J2EE APIs in this book, we will notcover 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 genericAPI that allows applications, applications servers, and resource managers to participate in defin-ing 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-pointSimple Object Access Protocol (SOAP)-based Web service functions. Developers can utilizeJava-based classes to define Web services and clients that exercise Web-services, effectivelyshielding the developer from the complexity of interacting with the SOAP protocol. As withSAAJ 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 for-matting of XML messages in conformance with the SOAP specifications. This should not beconfused with JAX-RPC, which also supports SOAP, but provides Web services support formessage composition and support for SAAJ, which allows the attachment of MIME-encodedbinary documents to SOAP messages. SAAJ is a required part of the JAX-RPC API, so we willdiscuss it only within the context of JAX-RPC.

3.2.10 JMX

Java Management Extension (JMX) allows a generalized way that distributed and Web-basedapplications can provide monitoring and instrumentation services, independent of the vendorapplication server. We won’t discuss programming to this API in WebSphere, but we will discusshow it is used in WebSphere administration.

3.3 J2EE Platform Roles

Besides defining a standard blueprint for vendor neutral enterprise computing components, theJ2EE specification identifies roles that participate in producing, creating, and supporting infor-mation systems built upon the J2EE platform. These roles as defined in the J2EE 1.3 specifica-tion are described in the sections which follow.

3.3.1 J2EE Product Provider

The role is responsible for providing the J2EE containers that house the specification compo-nents. In addition, they are required to provide deployment and management tools used to man-age J2EE applications deployed to the product. IBM plays the role of a product provider with itsWebSphere application server product.

3.3.2 Application Component Provider

This role identifies the provider of components such as enterprise bean developers, and HTMLdocument designers, and programmers that create components used to produce J2EE applica-tions. This book exists primarily to educate developers who will fill this role.


J2EE Versions and Evolution 35

3.3.3 Application Assembler

The act of using J2EE components to construct an application is the role defined by the specifi-cation—an application developer. Assembly implies that components are created and definedwithin an Enterprise Archive (EAR) file for deployment to containers. We will discuss integrat-ing J2EE components and packaging them as EAR files for deployment.

3.3.4 Deployer

The deployer is responsible for deploying enterprise Java components into an operating environ-ment that has a J2EE server supplied by a product provider. Deployment is typically made up ofthree steps: (1) installation, which involves moving the application (.ear) to the server environ-ment; (2) configuration of any external dependencies required by the resource; (3) Execution ofthe installed application.

While our primary focus is application development, and not deployment, we will discussareas where the two roles meet.

3.3.5 System Administrator

This role is not new to the J2EE landscape. Administrators are responsible for configuring andmonitoring the operating environments where J2EE servers exist, tasks are accomplished byusing the appropriate tools from the J2EE product provider. We will not examine this role in ourbook. For more information on performing system administration with the WebSphere family ofproducts, see [Francis] or the WebSphere Application Server InfoCenter.

3.3.6 Tool Provider

Tool providers furnish tools that help with the construction, deployment, and management ofJ2EE components. Tools can be targeted to all platform roles defined by the specification. Thisbook describes WebSphere Application Developer, used to develop components, making IBM atool provider.

Currently, the specification does not require or provide a mechanism by which these toolsare standardized. However, the specification has referenced a possibility of this being so in thefuture.

3.4 J2EE Versions and Evolution

Java’s momentum has moved it from a niche programming language into a mainstream languagethat is robust enough for a spectrum of applications from scientific to business. Java’s object-based environment allows the fundamental language to remain relatively stable with extensionscoming in platform technologies, such as those defined in J2EE. Developers and vendors fulfill-ing these technology specifications with best-of-breed implementations have arguably formed aso-called critical mass. There is no reason why this momentum should not continue; new ver-sions of current technologies along with new technologies will continue to augment the J2EEtechnology platform. Already, a single J2EE version increment from 1.3 to 1.4 has introducedWeb services technology and XML support.



What does this mean to the Java developer? One point of view is that change in designsand APIs leads to a maintenance nightmare. Another, more optimistic view, is that smaller devel-opment cycles will result in more stable and robust software. Developers can protect themselvesfrom API creep through consistency, generalization, and the application of design patterns. Thisbook will not only describe how these technologies are used, specifically with IBM WebSphere,but will provide patterns that can be used to implement these technologies in a malleable way.

3.5 A J2EE Perspective

It is not enough to download the J2EE platform components and start writing enterprise applica-tions with just any tool. Choosing the right development environment and application serverdetermines whether complexity will be shielded and managed, or be an ever-present struggleduring the development process. Realizing the full potential of J2EE technologies requires morethan just a tool—it requires a pattern-based approach that engages tool-produced artifacts.

Many choices are available to the developer who wants to use J2EE technology. Some arefree, others are vendor-supported. Obviously if you are reading this you are interested in theIBM WebSphere suite of products. The remaining chapters capture and describe the completecycle from development to deployment utilizing the WebSphere Studio Application Developerproduct and its integrated tooling support. Besides providing a complete tutorial on how to uti-lize these tools and the application server, we will describe design approaches and patterns thatcan help make your development and deployment process, as well as the resulting software, flex-ible to better meet changing business needs.

As we discussed in Chapter 1, we see the idea of layered application architecture as beingcritical to J2EE, and to understanding the architecture of the WebSphere product family. Figure3.4 illustrates how the different technologies we’ve just covered fit into that layered architecture.

At the top of our architecture is the presentation layer. We’ll discuss providing presenta-tion layers based on HTML using Java servlets, JSP, and eXtensible Stylesheet Language Trans-formations (XSLT). XSLT, not a J2EE technology, is a mechanism for transforming XMLdocuments into HTML (commonly used along with servlets and JSP). We will also considerWeb services in this layer, even though they are considered to be a program-to-program commu-nication mechanism. We’ll also examine how to test servlet-based applications using the open-source HTTPUnit tool.

Next comes the controller/mediator layer, which captures the notion of application flowand adapts the domain model layer to the presentation layer. We’ll examine several ways ofimplementing controller logic, including implementing it with servlets, using the Struts open-source application framework, and even using message-driven beans (which are EJBs calledthrough JMS) as application controllers for asynchronous logic flows.

In the domain layer, we’ll examine how to implement domain logic using Java Beans (or,more correctly, Plain Old Java Classes) and EJBs. We’ll also show you how to test your domainlogic using the open-source JUnit toolkit. To support the persistence of objects in the domain


A J2EE Perspective 37

layer, we’ll examine the mapping layer in depth, discovering how to use mapper objects, bean-managed persistence (BMP) and container-managed persistence (CMP) entity EJBs.

In addition to showing you how to test with JUnit, we’ll show you how to use the Web-Sphere Studio Universal Test Client. Finally, we’ll examine the two most common sources ofdata for J2EE programs, JMS and JDBC.

While the book will proceed roughly in the order we’ve outlined, it won’t cover the layersin strict order because not every system uses every technology we’ve described. Instead, you canrely on the application architecture graphic (Figure 3.4), which will appear at the beginning ofevery chapter starting in Chapter 5, to help you understand where the technologies fit into theoverall J2EE architecture.

Figure 3.4

Layered J2EE application architecture.

Servlet Container EJB Container

Presentation

Logging ExceptionHandling

Application Services

Properties

JavaApplication

HTML

JSP

XSLT

WebServices

HTTPUnit

Servlets

Struts

JavaBeans

Msg-DrivenBeans

Cactus

Controller/Mediator Domain Data Mapping

JavaBeans

SessionEJBs

JUnit

Data Source

MapperObjects

CMPEJBs

BMPEJBs

WASUTC

JDBC

JMS



3.6 Summary

This chapter described Java’s evolution from an initial way of delivering client/server type appli-cations via the Web, to a robust OO platform that can support large-scale multiuser enterpriseapplications. With the addition of J2EE-based technologies, which are supported by the Javacommunity at large, Java technology is a viable choice for developing applications of varyingdeployment topologies, platforms requirements, and business requirements.


Documents

J2EE Overview - pearsoncmg.comptgmedia.pearsoncmg.com/images/032118579X/sample... · 26 Chapter 3 • J2EE Overview All J2EE technologies are built upon the Java 2 Standard Edition