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:

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

o Java Server Pages (JSPs) Dynamically generated Web pages hosted by

the Web server. JSPs exist as text files comprised of code interspersed
with HTML.
o Struts An extension to J2EE that allows for the development of Web
applications with sophisticated user-interfaces and navigation.
o 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.
o 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.

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

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

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

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

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

o 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.
o 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:

o 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.
o 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:

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

o 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.
o 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 t
online vendor for TLS's B2B solution. A recent change in strategy prompted RailCo to broaden
of their Web services so that they could achieve the following two goals:

o Qualify as vendors for other online client solutions.

o Reengineer the architecture hosting the services so that it can become fully SOA-compli

The initial Web services-based application was developed using the .NET framework. At first R
this solution with a set of redesigned .NET services. However, a recent corporate reorganizatio
to such an extent that it was not able to renew the contracts of the four consultant project team
original .NET solution.

To continue with its plan, RailCo had to draw upon in-house resources. The small group of Jav
responsible for maintaining the Java-based accounting system were identified as potential can
Because they had not yet worked with any of the Web services-related APIs, they needed to u
to speed on JAX-RPC and JAXP.

Though this delayed the original plan, an SOA eventually was realized, hosting the new Invoice
Fulfillment applications, built as J2EE solutions consisting of a set of JAX-RPC Service Endpoi
 

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

o 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).
o J2EE provides native support for the creation of primitive SOAs.
o 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.
o 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.
o 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
 SUMMARY OF KEY POINTS
organizations to pick and choose J2EE products.