The Java 2 Platform Enterprise Edition (J2EE) is one of the two primary platforms currently being used to develop enterprise solutions using Web services. This section briefly introduces parts of the J2EE platform relevant to SOA. We then proceed to revisit the service-orientation principles and primary primitive and contemporary SOA characteristics established earlier in this book to discuss how these potentially can be realized using the previously explained parts of J2EE.
It is important to note that this section does not provide an in-depth explanation of the J2EE platform, nor do we get into how to program Web services using Java. There are already many comprehensive books that cover this vast subject area (see www.serviceoriented.ws for recommended reading). The purpose of this section is simply to continue our exploration of SOA realization. In doing so, we highlight some of the main areas of interest within the J2EE platform.
18.2.1. Platform overview
The Java 2 Platform is a development and runtime environment based on the Java programming language. It is a standardized platform that is supported by many vendors that provide development tools, server runtimes, and middleware products for the creation and deployment of Java solutions.
The Java 2 Platform is divided into three major development and runtime platforms, each addressing a different type of solution. The Java 2 Platform Standard Edition (J2SE) is designed to support the creation of desktop applications, while the Micro Edition (J2ME) is geared toward applications that run on mobile devices. The Java 2 Platform Enterprise Edition (J2EE) is built to support large-scale, distributed solutions. J2EE has been in existence for over five years and has been used extensively to build traditional n-tier applications with and without Web technologies.
The J2EE development platform consists of numerous composable pieces that can be assembled into full-fledged Web solutions. Let's take a look at some of the technologies more relevant to Web services.
Figure 18.13 does not illustrate the relationship between J2EE platform components. It only shows the underlying layers provided by the J2EE platform that support a J2EE service-oriented solution.
Figure 18.13. Relevant layers of the J2EE platform as they relate to SOA.
The Servlets + EJBs and Web + EJB Container layers (as well as the JAX-RPC Runtime) relate to the Web and Component Technology layers established earlier in the SOA platform basics section. They do not map cleanly to these layers because to what extent component and Web technology is incorporated is largely dependent on how a vendor chooses to implement this part of a J2EE architecture.
The components shown in Figure 18.13 inter-relate with other parts of the overall J2EE environment (as shown in Figure 18.14) to provide a platform capable of realizing SOA.
Figure 18.14. How parts of the J2EE platform inter-relate.
Before we discuss each of these components individually, let's begin with an overview of some key J2EE specifications. There are many J2EE standards published by Sun Microsystems that establish the parts of the J2EE architecture to which vendors that implement and build products around this environment must conform. Three of the more significant specifications that pertain to SOA are listed here:
The latter specification establishes the important Port Component Model introduced later in the Service providers section.
J2EE solutions inherently are distributed and therefore componentized. The following types of components can be used to build J2EE Web applications:
While the first two components are of more relevance to establishing the presentation layer of a service-oriented solution, the latter two commonly are used to realize Web services.
The J2EE environment relies on a foundation Java runtime to process the core Java parts of any J2EE solution. In support of Web services, J2EE provides additional runtime layers that, in turn, supply additional Web services specific APIs (explained later). Most notable is the JAX-RPC runtime, which establishes fundamental services, including support for SOAP communication and WSDL processing.
Additionally, implementations of J2EE supply two types of component containers that provide hosting environments geared toward Web services-centric applications that are generally EJB or servlet-based.
As explained in the Service providers section, EJB and Web containers can host EJB-based or servlet-based J2EE Web services. Web service execution on both containers is supported by JAX-RPC runtime services. However, it is the vendor-specific container logic that generally determines the shape and form of the system-level message processing logic provided in support of Web services.
J2EE vendors provide containers as part of their server products. A container then establishes the runtime that hosts an instance of the vendor's server software. Examples of currently available containers are Sun ONE (Open Network Environment) Application Server, IBM WebSphere, and Oracle Application Server Containers for J2EE (OC4J).
As its name implies, the Java 2 Platform Enterprise Edition is centered around the Java programming language. Different vendors offer proprietary development products that provide an environment in which the standard Java language can be used to build Web services.
Examples of currently available development tools are Rational Application Developer from IBM, Java Studio from Sun Microsystems, and JDeveloper from Oracle.
J2EE contains several APIs for programming functions in support of Web services. The classes that support these APIs are organized into a series of packages. Here are some of the APIs relevant to building SOA.
javax.xml.parsersA package containing classes for different vendor-specific DOM and SAX parsers.
org.w3c.dom and org.xml.saxThese packages expose the industry standard DOM and SAX document models.
javax.xml.transformA package providing classes that expose XSLT transformation functions.
javax.xml.rpc and javax.xml.rpc.serverThese packages contain a series of core functions for the JAX-RPC API.
javax.xml.rpc.handler and javax.xml.rpc.handler.soapAPI functions for runtime message handlers are provided by these collections of classes. (Handlers are discussed shortly in the Service agents section.)
javax.xml.soap and javax.xml.rpc.soapAPI functions for processing SOAP message content and bindings.
javax.xml.registryA series of registry access functions that support the JAXR API.
javax.xml.registry.infomodelClasses that represent objects within a registry.
Of these APIs, the two most commonly used for SOA are JAX-RPC to govern SOAP messaging and JAXP for XML document processing. The two other packages relevant to building the business logic for J2EE Web services are javax.ejb and javax.servlet, which provide fundamental APIs for the development of EJBs and servlets.
Note that we do not discuss these APIs any further. They are mentioned here only to demonstrate the grouping of API functions in J2EE packages.
As previously mentioned, J2EE Web services are typically implemented as servlets or EJB components. Each option is suitable to meet different requirements but also results in different deployment configurations, as explained here:
Regardless of vendor platform, both types of J2EE Web services are dependent on the JAX-RPC runtime and associated APIs.
A frequent point of confusion is the naming of the JAX-RPC Service Endpoint and the JAX-RPC runtime. Many initially assume that the JAX-RPC runtime is associated only with the JAX-RPC Service Endpoint and the Web container. However, because JAX-RPC establishes a standardized service processing layer that spans both Web and EJB containers, its runtime applies to both JAX-RPC Service Endpoints and EJB Service Endpoints.
Also a key part of either service architecture is an underlying model that defines its implementation, called the Port Component Model. As described in the Web Services for J2EE specification, it establishes a series of components that comprise the implementation of a J2EE service provider, including:
Figure 18.15 illustrates how the J2EE components fit into our familiar service provider model.
Figure 18.15. A typical J2EE service provider.
The JAX-RPC API also can be used to develop service requestors. It provides the ability to create three types of client proxies, as explained here:
The latter options are more suited for environments in which service interfaces are more likely to change or for which component interaction needs to be dynamically determined. For example, because a generated stub produces a static proxy interface, it can be rendered useless when the corresponding WSDL definition changes. Dynamic proxy generation avoids this situation.
Figure 18.16 explains how J2EE technologies work together within the service requestor model.
Figure 18.16. A typical J2EE service requestor.
Vendor implementations of J2EE platforms often employ numerous service agents to perform a variety of runtime filtering, processing, and routing tasks. A common example is the use of service agents to process SOAP headers.
To support SOAP header processing, the JAX-RPC API allows for the creation of specialized service agents called handlers (Figure 18.17)runtime filters that exist as extensions to the J2EE container environments. Handlers can process SOAP header blocks for messages sent by J2EE service requestors or for messages received by EJB Endpoints and JAX-RPC Service Endpoints.
Figure 18.17. J2EE handlers as service agents.
Multiple handlers can be used to process different header blocks in the same SOAP message. In this case the handlers are chained in a predetermined sequence (appropriately called a handler chain).
Different vendors that implement and build around the J2EE platform offer various platform extensions in the form of SDKs that extend their development tool offering. The technologies supported by these toolkits, when sufficiently mature, can further support contemporary SOA. Following are two examples of currently available platform extensions.
The WS-Resource Framework consists of a collection of specifications (WS-ResourceProperties, WS-ResourceLifetime, WS-BaseFaults, and WS-Service-Group) that establish a means of managing state information associated with Web services. For more information, visit www.specifications.ws.
As explained throughout earlier chapters, RailCo originally delivered a set of Web services so that it could register as an online vendor for TLS's B2B solution. A recent change in strategy prompted RailCo to broaden the scope and potential of their Web services so that they could achieve the following two goals:
The initial Web services-based application was developed using the .NET framework. At first RailCo planned to replace this solution with a set of redesigned .NET services. However, a recent corporate reorganization trimmed its IT budget to such an extent that it was not able to renew the contracts of the four consultant project team that delivered the original .NET solution.
To continue with its plan, RailCo had to draw upon in-house resources. The small group of Java programmers responsible for maintaining the Java-based accounting system were identified as potential candidates for the job. Because they had not yet worked with any of the Web services-related APIs, they needed to undergo training to get up to speed on JAX-RPC and JAXP.
Though this delayed the original plan, an SOA eventually was realized, hosting the new Invoice Processing and Order Fulfillment applications, built as J2EE solutions consisting of a set of JAX-RPC Service Endpoints.
18.2.2. Primitive SOA support
The J2EE platform provides a development and runtime environment through which all primitive SOA characteristics can be realized, as follows.
The distributed nature of the J2EE platform allows for the creation of independent units of processing logic through Enterprise Java Beans or servlets. EJBs or servlets can contain small or large amounts of application logic and can be composed so that individual units comprise the processing requirements of a specific business task or an entire solution.
Both EJBs and servlets can be encapsulated using Web services. This turns them into EJB and JAX-RPC Service Endpoints, respectively. The underlying business logic of an endpoint can further compose and interact with non-endpoint EJB and servlet components. As a result, well-defined services can be created in support of SOA.
The use of interfaces within the J2EE platform allows for the abstraction of metadata from a component's actual logic. When complemented with an open or proprietary messaging technology, loose coupling can be realized. EJB and JAX-RPC Endpoints further establish a standard WSDL definition, supported by J2EE HTTP and SOAP runtime services. Therefore, loose coupling is a characteristic that can be achieved in support of SOA.
Prior to the acceptance of Web services, the J2EE platform supported messaging via the JMS standard, allowing for the exchange of messages between both servlets and EJB components. With the arrival of Web services support, the JAX-RPC API provides the means of enabling SOAP messaging over HTTP.
Also worth noting is the availability of the SOAP over JMS extension, which supports the delivery of SOAP messages via the JMS protocol as an alternative to HTTP. The primary benefit here is that this approach to data exchange leverages the reliability features provided by the JMS framework. Within SOA this extension can be used by the business logic of a Web service, allowing SOAP messages to be passed through from the message process logic (which generally will rely on HTTP as the transport protocol). Either way, the J2EE platform provides the required messaging support for primitive SOA.
18.2.3. Support for service-orientation principles
We've established that the J2EE platform supports and implements the first-generation Web services technology set. It is now time to revisit the four principles of service-orientation not automatically provided by Web services and briefly discuss how each can be realized through J2EE.
For a service to be fully autonomous, it must be able to independently govern the processing of its underlying application logic. A high level of autonomy is more easily achieved when building Web services that do not need to encapsulate legacy logic. JAX-RPC Service Endpoints exist as standalone servlets deployed within the Web container and are generally built in support of newer SOA environments.
It may therefore be easier for JAX-RPC Service Endpoints to retain complete autonomy, especially when they are only required to execute a small amount of business logic. EJB Service Endpoints are required to exist as Stateless Session Beans, which supports autonomy within the immediate endpoint logic. However, because EJB Service Endpoints are more likely to represent existing legacy logic (or a combination of new and legacy EJB components), retaining a high level of autonomy can be challenging.
The advent of Enterprise Java Beans during the rise of distributed solutions over the past decade established a componentized application design model that, along with the Java programming language, natively supports object-orientation. As a result, reusability is achievable on a component level. Because service-orientation encourages services to be reusable and because a service can encapsulate one or more new or existing EJB components, reusability on a service level comes down to the design of a service's business logic and endpoint.
JAX-RPC Service Endpoints can be designed to exist as stateless servlets, but the JAX-RPC API does provide the means for the servlet to manage state information through the use of the HTTPSession object. It is therefore up to the service designer to ensure that statelessness is maximized and session information is only persisted in this manner when absolutely necessary.
As previously mentioned, one of the requirements for adapting an EJB component into an EJB Service Endpoint is that it be completely stateless. In the J2EE world, this means that it must be designed as a Stateless Session Bean, a type of EJB that does not manage state but that may still defer state management to other types of EJB components (such as Stateful Session Beans or Entity Beans).
As with reuse, service discoverability requires deliberate design. To make a service discoverable, the emphasis is on the endpoint design, in that it must be as descriptive as possible.
Service discovery as part of a J2EE SOA is directly supported through JAXR, an API that provides a programmatic interface to XML-based registries, including UDDI repositories. The JAXR library consists of two separate APIs for publishing and issuing searches against registries.
Note that even if JAXR is used to represent a UDDI registry, it does so by exposing an interface that differs from the standard UDDI API. (For example, a UDDI Business-Entity is a JAXR Organization, and a UDDI BusinessService is a JAXR Service.)
18.2.4. Contemporary SOA support
Extending an SOA beyond the primitive boundary requires a combination of design and available technology in support of the design. Because WS-* extensions have not yet been standardized by the vendor-neutral J2EE platform, they require the help of vendor-specific tools and features.
We now take another look at some of the characteristics we associated with contemporary SOA in Chapter 9. How J2EE standards either automatically support these characteristics or how they can be fulfilled through deliberate application of J2EE technologies is explained.
Based on open standards
The Web services subset of the J2EE platform supports industry standard Web services specifications, including WSDL, SOAP, and UDDI. As explained later in the Intrinsically interoperable section, support for the WS-I Basic Profile also has been provided. Further, the API specifications that comprise the J2EE platform are themselves open standards, which further promotes vendor diversity, as described in the next section.
It should also be mentioned that some J2EE vendors have provided significant contributions to the actual creation of Web services specifications.
Supports vendor diversity
Adherence to the vanilla J2EE API standards has allowed for a diverse vendor marketplace to emerge. Java application logic can be developed with one tool and then ported over to another. Similarly, Java components can be designed for deployment mobility across different J2EE server products.
Further, by designing services to be WS-I Basic Profile compliant, vendor diversity beyond J2EE platforms is supported. For example, an organization that has built an SOA based on J2EE technology may choose to build another using the .NET framework. Both environments can interoperate if their respective services conform to the same open standards. This also represents vendor diversity.
Interoperability is, to a large extent, a quality deliberately designed into a Web service. Aside from service interface design characteristics, conformance to industry-standard Web services specifications is critical to achieving interoperable SOAs, especially when interoperability is required across enterprise domains.
As of version 1.1, the JAX-RPC API is fully capable of creating WS-I Basic Profile-compliant Web services. This furthers the vision of producing services that are intrinsically interoperable. Care must be taken, though, to prevent the use of handlers from performing runtime processing actions that could jeopardize this compliance.
IBM's Rational Application Developer provides built-in support for building WS-I compliant Web services. Further, the Wscompile tool, which is part of the J2EE SDK from Sun Microsystems, allows for the auto-generation of WS-I Basic Profile compliant WSDL definitions.
Strategically positioned services coupled with adapters that expose legacy application logic can establish a degree of federation. Building an integration architecture with custom business services and legacy wrapper services can be achieved using basic J2EE APIs and features. Supplementing such an architecture with an orchestration server (and an accompanying orchestration service layer) further increases the potential of unifying and standardizing integrated logic. (This is discussed in the Supports service-oriented business modeling section as well.)
Also worth taking into consideration is the J2EE Connector Architecture (JCA), a structured, adapter-centric integration architecture through which resource adapters are used to bridge gaps between J2EE platforms and other environments. As with JMS, JCA is traditionally centered around the use of proprietary messaging protocols and platform-specific adapters. Recently, however, support for asynchronous and SOAP messaging has been introduced. Further, service adapters have been made available to tie JCA environments into service-oriented solutions.
Numerous integration server platforms also are available to support and implement the overall concept of enterprise-wide federation. Depending on the nature of the integration architecture, service-oriented integration environments are built around orchestration servers or enterprise service bus offerings (or both).
The Sun ONE Connector Builder product is an example of a vendor implementation of JCA that supports the creation of a SOAP messaging layer. Also a number of J2EE vendors provide orchestration servers with native WS-BPEL support, including IBM's WebSphere Business Integration Server Foundation product and Oracle's BPEL Process Manager.
Given the modular nature of supporting API packages and classes and the choice of service-specific containers, the J2EE platform is intrinsically composable. This allows solution designers to use only the parts of the platform required for a particular application. For example, a Web services solution that only consists of JAX-RPC Service Endpoints will likely not have a need for the JMS class packagesora J2EE SOA that does not require a service registry will not implement any part of the JAXR API.
With regards to taking advantage of the composable contemporary SOA landscape, the J2EE platform, in its current incarnation, does not yet provide native support for WS-* specifications. Instead, extensions are supplied by product vendors that implement and build upon J2EE standards. The extent to which the WS-* features of an SOA based on the J2EE platform can be composed is therefore currently dependent upon the vendor-specific platform used.
As with any service-oriented solution, those based on the J2EE platform can be designed with services that support the notion of future extensibility. This comes down to fundamental design characteristics that impose conventions and structure on the service interface level.
Because J2EE environments are implemented by different vendors, extensibility can sometimes lead to the use of proprietary extensions. While still achieving extensibility within the vendor environment, this can limit the portability and openness of Java solutions.
Supports service-oriented business modeling
Beyond consistent and standardized design approaches to building service layers along the lines of the application, entity, and task-centric services we've established in previous chapters, there is no inherent support for service-oriented business modeling within J2EE.
This is primarily because the concept of orchestration is not a native part of the J2EE platform. Instead, orchestration services and design tools are provided by vendors to supplement the J2EE Web services development and runtime environment. Service-oriented business modeling and the service layers we've discussed in this book can therefore be created with the right vendor tools.
JAX-RPC Service Endpoints and EJB Service Endpoints can be designed into service layers that abstract application-specific or reusable logic. Further, entire J2EE solutions can be exposed through these types of services, when appropriate.
Depending on the vendor server platform used, some limitations may be encountered when building service compositions that require message-level security measures. These limitations may inhibit the extent of feasible logic-level abstraction.
Organizational agility and enterprise-wide loose coupling
In past chapters we explored the enablement of enterprise-wide agility through the implementation of abstraction via service sub-layers. As discussed in the previous section, the creation of these service layers is possible with the help of a vendor-specific orchestration server. Although the orchestration offering is proprietary, the fact that other Web services are J2EE standardized further promotes an aspect of agility realized through the vendor diverse nature of the J2EE marketplace.
For example, if a vendor server platform is not satisfying current business needs and requires replacement, application, entity-centric, and task-centric services likely will be sufficiently mobile so that they can be used in the replacement environment. The orchestration logic may or may not be portable, depending on whether a common orchestration language, such as WS-BPEL, was used to express the process logic.
To attain a state where business and technology domains of an enterprise are loosely coupled and achieve full, two-way agility, requires the fulfillment of a number of contemporary SOA characteristics identified in this book. The J2EE platform provides a foundation upon which to build a standardized and extensible SOA. Enterprise features offered by vendor platforms need to be incorporated to add layers on top of this foundation necessary to driving service-orientation across the enterprise.
SUMMARY OF KEY POINTS
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion