SOA support in J2EE

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:

• Java 2 Platform Enterprise Edition Specification This important specification establishes the distributed J2EE component architecture and provides foundation standards that J2EE product vendors are required to fulfill in order to claim J2EE compliance.
• Java API for XML-based RPC (JAX-RPC) This document defines the JAX-RPC environment and associated core APIs. It also establishes the Service Endpoint Model used to realize the JAX-RPC Service Endpoint, one of the primary types of J2EE Web services (explained later).
• Web Services for J2EE The specification that defines the vanilla J2EE service architecture and clearly lays out what parts of the service environment can be built by the developer, implemented in a vendor-specific manner, and which parts must be delivered according to J2EE standards.

The latter specification establishes the important Port Component Model introduced later in the Service providers section.

Architecture components

J2EE solutions inherently are distributed and therefore componentized. The following types of components can be used to build J2EE Web applications:

• Java Server Pages (JSPs) Dynamically generated Web pages hosted by the Web server. JSPs exist as text files comprised of code interspersed with HTML.
• Struts An extension to J2EE that allows for the development of Web applications with sophisticated user-interfaces and navigation.
• Java Servlets These components also reside on the Web server and are used to process HTTP request and response exchanges. Unlike JSPs, servlets are compiled programs.
• Enterprise JavaBeans (EJBs) The business components that perform the bulk of the processing within enterprise solution environments. They are deployed on dedicated application servers and can therefore leverage middleware features, such as transaction support.

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.

Runtime environments

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.

• EJB container This container is designed specifically to host EJB components, and it provides a series of enterprise-level services that can be used collectively by EJBs participating in the distributed execution of a business task. Examples of these services include transaction management, concurrency management, operation-level security, and object pooling.
• Web container A Web container can be considered an extension to a Web server and is used to host Java Web applications consisting of JSP or Java servlet components. Web containers provide runtime services geared toward the processing of JSP requests and servlet instances.

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.

Note

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).

 

Programming languages

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.

Note

Examples of currently available development tools are Rational Application Developer from IBM, Java Studio from Sun Microsystems, and JDeveloper from Oracle.

 

APIs

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.

• Java API for XML Processing (JAXP) This API is used to process XML document content using a number of available parsers. Both Document Object Model (DOM) and Simple API for XML (SAX) compliant models are supported, as well as the ability to transform and validate XML documents using XSLT stylesheets and XSD schemas. Example packages include:

  ~	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.

• Java API for XML-based RPC (JAX-RPC) The most established and popular SOAP processing API, supporting both RPC-literal and document-literal request-response exchanges and one-way transmissions. Example packages that support this API include:

  ~	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.

• Java API for XML Registries (JAXR) An API that offers a standard interface for accessing business and service registries. Originally developed for ebXML directories, JAXR now includes support for UDDI.

  ~	javax.xml.registryA series of registry access functions that support the JAXR API.
  ~	javax.xml.registry.infomodelClasses that represent objects within a registry.

• Java API for XML Messaging (JAXM) An asynchronous, document-style SOAP messaging API that can be used for one-way and broadcast message transmissions (but can still facilitate synchronous exchanges as well).
• SOAP with Attachments API for Java (SAAJ) Provides an API specifically for managing SOAP messages requiring attachments. The SAAJ API is an implementation of the SOAP with Attachments (SwA) specification.
• Java Architecture for XML Binding API (JAXB) This API provides a means of generating Java classes from XSD schemas and further abstracting XML-level development.
• Java Message Service API (JMS) A Java-centric messaging protocol used for traditional messaging middleware solutions and providing reliable delivery features not found in typical HTTP communication.

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.

Service providers

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:

• JAX-RPC Service Endpoint When building Web services for use within a Web container, a JAX-RPC Service Endpoint is developed that frequently is implemented as a servlet by the underlying Web container logic. Servlets are a common incarnation of Web services within J2EE and most suitable for services not requiring the features of the EJB container.
• EJB Service Endpoint The alternative is to expose an EJB as a Web service through an EJB Service Endpoint. This approach is appropriate when wanting to encapsulate existing legacy logic or when runtime features only available within an EJB container are required. To build an EJB Service Endpoint requires that the underlying EJB component be a specific type of EJB called a Stateless Session Bean.

Regardless of vendor platform, both types of J2EE Web services are dependent on the JAX-RPC runtime and associated APIs.

Note

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:

• Service Endpoint Interface (SEI) A Java-based interpretation of the WSDL definition that is required to follow the JAX-RPC WSDL-to-Java mapping rules to ensure consistent representation.
• Service Implementation Bean A class that is built by a developer to house the custom business logic of a Web service. The Service Implementation Bean can be implemented as an EJB Endpoint (Stateless Session Bean) or a JAX-RPC Endpoint (servlet). For an EJB Endpoint, it is referred to as an EJB Service Implementation Bean and therefore resides in the EJB container. For the JAX-RPC Endpoint, it is called a JAX-RPC Service Implementation Bean and is deployed in the Web container.

Figure 18.15 illustrates how the J2EE components fit into our familiar service provider model.

Figure 18.15. A typical J2EE service provider.

 

Service requestors

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:

• Generated stub The generated stub (or just "stub") is the most common form of service client. It is auto-generated by the JAX-RPC compiler (at design time) by consuming the service provider WSDL, and producing a Java-equivalent proxy component. Specifically, the compiler creates a Java remote interface for every WSDL portType which exposes methods that mirror WSDL operations. It further creates a stub based on the WSDL port and binding constructs. The result is a proxy component that can be invoked as any other Java component. JAX-RPC takes care of translating communication between the proxy and the requesting business logic component into SOAP messages transmitted to and received from the service provider represented by the WSDL.
• Dynamic proxy and dynamic invocation interface Two variations of the generated stub are also supported. The dynamic proxy is similar in concept, except that the actual stub is not created until its methods are invoked at runtime. Secondly, the dynamic invocation interface bypasses the need for a physical stub altogether and allows for fully dynamic interaction between a Java component and a WSDL definition at runtime.

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.

 

Service agents

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).

Platform extensions

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.

• IBM Emerging Technologies Toolkit A collection of extensions that provide prototype implementations of a number of fundamental WS-* extensions, including WS-Addressing, WS-ReliableMessaging, WS-MetadataExchange, and WS-Resource Framework.
• Java Web Services Developer Pack A toolkit that includes both WS-* support as well as the introduction of new Java APIs. Examples of the types of extensions provided include WS-Security (along with XML-Signature), and WS-I Attachments.

Note

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.

Case Study

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:

• Qualify as vendors for other online client solutions.
• Reengineer the architecture hosting the services so that it can become fully SOA-compliant.

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.

Service encapsulation

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.

Loose coupling

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.

Messaging

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.

Autonomy

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.

Reusability

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.

Statelessness

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).

Discoverability

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.

Note

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.

Intrinsically interoperable

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.

Note

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.

 

Promotes federation

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).

Note

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.

 

Architecturally composable

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.

Extensibility

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.

Logic-level abstraction

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

• The J2EE platform is comprised of many APIs (JAXP, JAX-RPC, JAXR, etc.), supports the creation of two primary types of service providers (JAX-RPC Service Endpoints, EJB Service Endpoints) and the generation of three types of service requestor proxies (generated stub, dynamic proxy, and dynamic invocation interface).
• J2EE provides native support for the creation of primitive SOAs.
• Of the four primitive service-orientation principles not automatically realized through first-generation Web services technologies, all can be fulfilled with proper design and the use of appropriate J2EE APIs.
• Some contemporary SOA characteristics are supported by native J2EE platform features, while others require the involvement of vendor-specific products and extensions. The fact that J2EE supports the development of WS-I Basic Profile compliant services promotes several key contemporary SOA characteristics, such as intrinsic interoperability, federation, open standards, and vendor diversity.
• Much like the Web services specification landscape, the J2EE platform consists of a series of technologies that are based on open standards. This allows vendors to build proprietary tools and server platforms around a standardized foundation. It also establishes a marketplace allowing organizations to pick and choose J2EE products.