Web Services for J2EE

With the advent of J2EE 1.4, Web Services are now an integral part of J2EE. This section examines at a high level how Web Services fit with the J2EE model and how they can be used with J2EE components.

J2EE Web Service Architecture

J2EE can can be both a provider and consumer of Web Services. Figure 20.2 shows the overall architecture, with business logic being provided by EJBs (although other classes could be used). The functionality offered by the business components will be described by a WSDL document (or similar), and this can then be used to build clients that use this functionality.

SOAP RPC calls will be handled by a router component based around a servlet. This will dispatch calls to the associated EJB or other component. The router that handles document-centric SOAP messages will also be servlet based. In either case, the precise nature of the servlet will depend on the type of underlying transport over which the messages are sent.

The J2EE business components may themselves use other Web Services to help them deliver business functionality. In this case, the components will take advantage of the client-side Web Service APIs to call out to these Web Services.

The Web Service runtime will consist of a variety of filters, providers, and helpers that will be used in combination with the routing servlets and basic, low-level APIs. These helpers will deliver additional value on top of the basic APIs, such as ebXML quality of service guarantees.

Tools and Technologies

A number of JSRs in the Java Community Process (JCP) have defined the Web Service APIs and architecture used by J2EE. These include the following:

• JSR101, the Java APIs for XML-based RPC (JAX-RPC)— JAX-RPC provides APIs for invoking RPC-based Web Services over SOAP. It defines how interactions should take place and provides the basis for automated tools to produce stubs and skeletons. It also specifies type mapping and marshalling requirements between Java and XML Schema types.

• JSR067, the Java APIs for XML Messaging (JAXM), and the SOAP with Attachments API for Java (SAAJ)— These APIs are used to create document-centric SOAP messages that can be exchanged either synchronously or asynchronously. Vendors can provide messaging profiles on top of this that offer value-added services, such as ebXML.

• JSR093, the Java API for XML Registries (JAXR)— JAXR defines a two-tier API for accessing registry information stored in XML format. This is targeted at Web Service-related registries, such as UDDI registries and ebXML registry/repositories, as well as other generic XML registries.

• JSR109, Implementing Enterprise Web Services— JSR109 does not define any Java APIs. Instead, it defines how J2EE implementations should work with JAX-RPC, SAAJ, JAXM, and JAXR. This includes everything from the schema for XML-based configuration files to the overall programming model envisioned.

All these JSRs have now reached their first release, but work is still ongoing to extend and maintain the capabilities defined in them. The contents and status of these JSRs are available through the JCP Web site at http://www.jcp.org/.

The role that each of these APIs plays in the J2EE Web Service architecture is shown in Figure 20.3. All these APIs are included in J2EE 1.4 (as defined in JSR151) and form part of the J2EE Reference Implementation (RI).

As well as implementations of J2EE 1.4, there are various other sources of Java-based Web Service functionality:

• The Apache Software Foundation provides the Axis toolkit for the creation and use of SOAP-based Web Services that can be deployed in most servlet containers. Axis implements the JAX-RPC and SAAJ APIs and continues to track updates to the associated JSRs as well as the progress of SOAP 1.2. The predecessor to Axis was Apache's SOAP toolkit 2.2. The Axis toolkit can be found at http://xml.apache.org/axis.

• For several years, IBM has delivered its its Web Services Toolkit (WSTK) through their Alphaworks developer site. This toolkit has subsequently evolved into the Emerging Technologies Toolkit (ETTK). The ETTK provides a set of tools and APIs on which to build Web Services. The ETTK conforms to the relevant JSRs but also acts as a platform for early delivery of new Web Service APIs such as security and routing. The ETTK integrates with the Apache Tomcat servlet engine and IBM's WebSphere application server. IBM's ETTK and can be found at http://www.alphaworks.ibm.com/tech/ettk.

• The reference implementations of the individual APIs are available as part of the Java Web Services Developer Pack (JWSDP), along with other Java APIs for the manipulation of XML. The JWSDP can be found at http://java.sun.com/webservices.

If you want to investigate or use Web Service functionality in your applications, the appropriate choice will depend on the style and robustness you require.

Integrating Web Services with J2EE

Most development projects involve using or adapting existing functionality. Projects based on Web Services will be no different. In fact, a project can be specifically focused at exposing existing functionality to clients in the form of Web Services. So, how do you expose existing J2EE functionality as Web Services?

For a traditional J2EE application, business logic is contained in EJBs or plain old Java objects (POJOs). This functionality is usually made available to client applications through servlets and JSPs. If the clients are Web browsers, these Web components will generate and consume HTML. Similarly, if the clients are mobile applications, the Web components may generate and consume Wireless Markup Language (WML). However, these WML Web components share the same business logic—they just provide a different front end or channel for it. Web Service clients are no different in that respect from HTML or WML clients. The SOAP router servlet, together with helper classes, acts as a server-side wrapper for the business logic, delivering it to Web Service clients. This situation is shown in Figure 20.4.

The other type of J2EE component in which application logic can be held is a servlet or JSP. You may ask how you would wrap this functionality for use as a Web Service. Well, the issue here is that many of the Web components in question are already acting as channels to some form of client (as shown in Figure 20.4). Consequently, wrapping them makes no sense. What you should do is create a replacement for such a Web component that is targeted at Web Service clients rather than Web browsers. If your Web components are well designed, you should be able to reuse the JavaBeans, servlet filters, and POJO helper classes as part of your Web Service implementation.