Aaron is chairman of Mantis Development Corporation, and teaches computer graphics and Internet/web application development at Boston College. He is also author of J2EE 1.4 Essentials (http://www.wiley.com/compbooks/walsh/). Aaron can be contacted at firstname.lastname@example.org.
After nearly two years of development, Version 1.4 of Sun's Java 2 Platform Enterprise Edition (J2EE) is poised for release. Currently available in public draft form, the final J2EE 1.4 specification is expected to emerge from the open Java Community Process (JCP; http://www.jcp.org/) in the summer of 2003, with commercial product implementations to follow. J2EE has evolved considerably since it was first introduced in 1999 as a platform for developing and deploying distributed, multitiered enterprise applications. J2EE 1.4 ushers in a range of features that build upon the 1.3 release, with support for web services leading the way.
J2EE 1.4 Web Services
J2EE 1.4 boasts a number of new capabilities, as well as significant enhancements to core J2EE technologies such as servlets, JavaServer Pages (JSPs), and Enterprise JavaBeans (EJBs, or simply "beans"). The most exciting news for many existing and potential J2EE developers, however, is the platform's support for standard XML-based web services. Support for web services is such an important addition to J2EE that Sun considers the J2EE platform to be the foundation technology upon which its web services strategy is built.
As a platform for building and deploying applications that are distributed across networks, J2EE 1.4 supports a number of key Internet and web standards including TCP/IP, HTTP 1.1, SSL 3.0, and TLS 1.0. To enable you to create and consume web services, J2EE also provides built-in support for XML 1.0, SOAP 1.1, and WSDL 1.1. When J2EE 1.4 ships, it will also support the WS-I Basic Profile currently under development by the Web Services Interoperability Organization (WS-I; http://www.wsi .org/). Although J2EE 1.4 was initially scheduled to be released in early 2003, its development schedule was extended so that it could support the forthcoming WS-I Basic Profile. WS-I Basic Profile provides implementation guidelines on how to develop interoperable web services using a core suite of web services specifications (SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, and XML Schema) and also addresses how to describe, discover, transmit, and secure such services.
You can tap into J2EE's web services capabilities using the XML APIs in Table 1. These APIs hide the complexity of XML and web services behind familiar Java object programming techniques, freeing you to focus on high-level application issues rather than low-level plumbing. In other words, you don't have to know a lot about XML and web services to use them, thanks to the APIs and corresponding functionality provided transparently by J2EE.
Whereas the Java APIs for XML provide numerous Java classes that can be used to implement and consume web services, the J2EE 1.4 specification also defines exactly how this is to be done. Specifically, J2EE 1.4 relies on the related Web Services 1.1 spec to define how JAX-RPC may be used to create and deploy J2EE web services clients and endpoints. Although Web Services 1.1 requires only JAX-RPC (the minimal XML API required for J2EE web services), most developers will take advantage of the other XML APIs, too.
Table 2 lists the J2EE 1.4 containers required to provide an implementation of the XML APIs and Web Services 1.1 functionality. Only the client-side applet container has the option of not supporting them, whereas the client-side application container and the server-side web and EJB containers are all required to provide an implementation of the XML APIs and Web Services 1.1 specification. This, in turn, lets you create and use web services directly at the client tier (via application clients), web tier (via servlets), and EJB tier (via stateless session beans). Applet-based clients can also take advantage of web services indirectly by receiving the results of web service interactions that have been preprocessed on the server.
Binding to Web Service Endpoints
With J2EE 1.4, you have a standardized mechanism for exposing servlets and stateless session beans as interoperable web services. Such components are considered web service endpoints (also known as "ports"), and can optionally be described using WSDL and published to XML registries (UDDI and ebXML registries, for example) where they may be discovered and used by web service clients. After discovering a web service it wishes to use, a client can then bind to it, after which the client can make remote procedure calls on the service to invoke the various methods it offers. Alternately, the client may send the web service an XML document to be processed (J2EE supports both RPC and document-oriented web services, from which synchronous and asynchronous architectures are possible). Figure 1 illustrates this basic three-step process and how the JAXR and JAX-RPC APIs play a role in publishing, discovering, and binding to web services.
In some cases, it may be preferable for services and clients to bind directly to one another without using a registry. This may be done simply to avoid the overhead associated with registries, for instance, in which case, the client needs to know the location of the service (for example, the URL where it resides) to bind to it directly. In other cases, the registry may not be necessary because the client and web service are both part of the same J2EE application. In other words, J2EE applications can use web services internally and not make them available to external clients.
External clients can be created using any programming language or platform that supports the same web services technologies used by J2EE 1.4. As you might expect, J2EE applications can, in turn, use web services published by other providers irrespective of how they are implemented (as long as the service conforms to the same core technologies). Indeed, XML-based web services may eventually build a solid bridge between J2EE, .NET, and other distributed application platforms.
Processing and Transforming XML with JAXP
Although you access the web services features of J2EE 1.4 primarily through the JAX-RPC, JAXR, and SAAJ APIs, JAXP provides fundamental XML processing capabilities for these APIs and the entire platform. JAXP forms the core of the platform's XML APIs, and provides the underlying foundation for JAX-RPC, JAXR, and SAAJ. Whereas JAX-RPC, JAXR, and SAAJ use JAXP behind the scenes, you can use JAXP explicitly to parse or transform XML documents as needed.
JAXP provides the ability to parse XML documents using the platform's built-in Simple API for XML Parsing (SAX) and Document Object Model (DOM) parsers. You can also plug in an alternate parser implementation if the default SAX and DOM parsers provided by the API aren't sufficient. In addition to SAX and DOM parsing, the JAXP API also supports transformations using the XML Stylesheet Language Transformations (XSLT) standard, giving J2EE applications the ability to convert XML documents into other XML documents or into other formats.
The essential JAXP API is made up of the following packages, each of which contains Java classes that provide a specific aspect of JAXP functionality:
- javax.xml.parsers contains classes used to parse XML documents using SAX and DOM parsers (this package is supported by the related org.xml.sax and org.w3c.dom packages).
- org.xml.sax contains classes that support event-driven parsing of XML documents using the SAX 2.0 Standard.
- org.w3c.dom contains classes that support processing of XML documents using the DOM Level 2 Core Standard.
- javax.xml.transform contains classes used to transform XML documents using the XSLT 1.0 Standard.
- javax.xml.namespace contains the QName (qualified name) class that supports the W3C XML Namespaces 1.0 Recommendation and XML Schema Recommendation (Parts 1 and 2).
As with all Java APIs for XML, the classes that make up JAXP are specifically designed to shield you from low-level infrastructure and format issues; you don't have to be an XML or XSLT expert (or even that familiar with these technologies) to process XML documents. Instead, JAXP gives you the ability to parse and transform XML documents using Java instead of requiring you to work directly with XML or XSTL code.
Implementing Clients and Endpoints with JAX-RPC
The JAX-RPC API provides the core web services capabilities of J2EE 1.4. Using JAX-RPC you can create and send SOAP messages to remote web service endpoints, and also process SOAP messages that are returned from the service in reply. JAX-RPC works with the Web Services 1.1 specification to define a service-oriented architecture (SOA) for J2EE. With JAX-RPC, you can implement web service endpoints as well as clients that consume internal and/or external web services. JAX-RPC provides an API for making remote procedure calls using SOAP 1.1 transported over HTTP 1.1 (or HTTPS), and also provides the ability to describe web services using WSDL 1.1 so that they can be subsequently published to an XML registry using the JAXR API.
The javax.xml.rpc package defines the main JAX-RPC API and contains the core classes used to implement web service endpoints and clients. The ServiceFactory class creates instances of the Service interface that is used to implement endpoints, while the Call and Stub interfaces are used to implement clients. This package also defines the JAXRPCException and ServiceException exceptions thrown by many JAX-RPC methods. In addition to the main javax.xml.rpc package, many of the classes, interfaces, and exceptions that comprise JAX-RPC are organized into subpackages such as the following:
- javax.xml.rpc.server defines APIs used to implement servlet endpoints. The ServiceLifecycle interface in this package defines the lifecycle for servlet endpoints and the ServletEndpointContext interface defines the endpoint context provided by the servlet container's underlying JAX-RPC run time.
- javax.xml.rpc.soap contains the SOAPFaultException exception class that represents a SOAP fault in JAX-RPC.
- javax.xml.rpc.encoding contains interfaces and classes that support the JAX-RPC type-mapping framework.
- javax.xml.rpc.handler defines SOAP message handler APIs. Message handlers implement the Handler interface to obtain access to the SOAP message from the SOAPMessageContext interface that is defined by the javax.xml.rpc.handler.soap package. The javax.xml.rpc.handler.soap package, in turn, defines the SOAPMessageContext interface that extends javax.xml.rpc.handler.MessageContext to provide access to the SOAP message used in RPC requests and responses.
- javax.xml.rpc.holders contains "holder" classes that support Java mappings to WSDL operations. The Holder interface enables mappings to preserve WSDL signature and parameter passing semantics.
Although JAX-RPC intentionally shields you from low-level SOAP and WSDL operations, many commercial J2EE 1.4 products will further reduce (or even eliminate) the amount of coding necessary to develop and deploy web services. Sufficiently advanced J2EE authoring tools can, for example, automatically generate endpoint interfaces and WSDL descriptions for servlets and EJBs. They can also automate the process of publishing endpoints to registries. Of course, if you prefer to work directly with code, you can do so using less-advanced authoring tools or by working in a code view provided by visual authoring tools.
Using SOAP Messages with SAAJ
JAX-RPC makes the process of creating, sending, and receiving SOAP messages simple, if not transparent. At times, however, more direct control over the process may be desired. SAAJ gives you the ability to manually create SOAP messages and send them to remote web service endpoints. In addition, SAAJ lets you manually process SOAP responses received in reply to messages sent by your applications. Although you may not need to use SAAJ directly as a required part of J2EE 1.4, SAAJ is always available if you need it. In fact, SAAJ is actually at work behind the scenes whenever you use JAX-RPC (the low-level SAAJ API supports the higher level JAX-RPC API). The SAAJ 1.1 API supported by J2EE 1.4 is based on the W3C's SOAP 1.1 Recommendation and SOAP Messages with Attachments specifications.
The classes, interfaces, and exceptions that SAAJ is comprised of are contained in the javax.xml.soap package, and may be called upon at any time to create a SOAP message and build the message contents (message header, body, and attachments). SAAJ can be used to add parts to a SOAP message, including attachments of any content type (including XML fragments that SAAJ can also create). The API can also be used to access or modify parts of an existing message, including SOAP fault information. Finally, SAAJ can also be used to send SOAP messages to an endpoint over a point-to-point connection or send SOAP response messages in reply to requests previously received by a remote web service.
Accessing Web Services Registries with JAXR
JAXR enables J2EE applications to access various types of XML registries through a uniform, Java-based interface. Using JAXR, you can publish J2EE web service endpoints to business-oriented registries such as those provided by UDDI, ebXML, eCo Framework, ISO 11179 Information Model, and more. JAXR also gives J2EE applications the ability to search such registries for web services that the application can use.
The JAXR 1.0 API is organized into two packages. The javax.xml.registry package contains high-level classes, interfaces, and exceptions used by JAXR clients (programs that use JAXR to access registries through a so-called "JAXR provider"), and the javax.xml.registry.infomodel package contains interfaces that define the JAXR information model. The JAXR information model defines the types of objects that may reside in a registry and how these objects relate to one another. The JAXR information model effectively defines a Java binding to common registry operations supported by ebXML and UDDI.
Although JAXR can be used directly by Java programmers, forthcoming J2EE 1.4 authoring tools are likely to automate the process of publishing J2EE web service endpoints to popular registries. Similar to the way such tools could generate JAX-RPC code in response to point-and-click interaction with the user, it doesn't take much imagination to envision products that generate JAXR code in response to options configured through a visual interface. Sun's J2EE 1.4 Software Development Toolkit (J2EE 1.4 SDK) gives you some idea of how authoring tools can take advantage of the platform's highly "toolable" architecture as the next section explains.
Getting Started with J2EE 1.4
With the final J2EE 1.4 spec scheduled to ship in a few months, you can get started with the platform today using Sun's J2EE 1.4 SDK (http://java.sun.com/j2ee/). Designed to showcase the J2EE 1.4 platform, Sun's J2EE 1.4 SDK provides the tools and run-time environment (including a web and EJB server) necessary to build and deploy web services immediately. Although the SDK remains under development, it gives you early access to the J2EE 1.4 platform free of charge. The SDK tools aren't quite as polished as commercial products tend to be, but do provide working examples of how such tools can automate the process of creating and deploying J2EE web services.
Once you've installed the J2EE 1.4 SDK, take a look at Sun's Java Adventure Builder. The Adventure Builder is a complete sample J2EE 1.4 application that illustrates how to implement web services. As a web site travel application that supports online shopping, end users of this application can use a standard web browser to shop for and customize travel and vacation packages. Freely available through Sun's Enterprise BluePrints program (http://java.sun.com/blueprints/enterprise/), the Adventure Builder comes complete with code and documentation and is an excellent companion to the J2EE 1.4 SDK.