This chapter is from the book
This chapter is from the book
This chapter is from the book
Web Services for J2EE
At the time of writing, Web Services are not an integral part of J2EE. However, the overall intention and roadmap has been laid out. This section examines how Web Services fit with the J2EE model and how they can be used with J2EE components.
J2EE Web Service Architecture
J2EE will 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.
){kind=link}
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.
Figure 20.2 Overall J2EE Web Service architecture.
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
There are a number of JSRs that are in progress in the Java Community Process (JCP) to define Web Service APIs for Java. These include the following:
JSR101, Java APIs for XML-based 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 SOAP/WSDL.
JSR067, Java APIs for XML Messaging (JAXM), defines APIs for creating 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), 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.
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 of these APIs are intended for inclusion in J2EE 1.4 (as defined in JSR151). In the interim, they will be delivered as part of the JAX Pack, along with other Java APIs for the manipulation of XML. The first JAX Pack was delivered in Fall 2001.
){kind=link}
Figure 20.3 J2EE Web Service APIs.
Until the finalization and release of J2EE 1.4, there are various 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 is tracking the JAX-RPC JSR 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.
IBM provide their Web Services Toolkit (WSTK) through their Alphaworks developer site. The WSTK provides a set of tools and APIs on which to build Web Services. The WSTK integrates with the Apache Tomcat servlet engine and IBM's WebSphere application server. IBM's Web Service Toolkit can be found at http://alphaworks.ibm.com/tech/webservicestoolkit.
As the various JSRs reach maturity, they will be obliged to release a reference implementation (RI) of their functionality. These various RIs are available for individual download from Sun and are also bundled as part of the JAX Pack, also available from Sun. You can download the latest versions of these implementations from http://java.sun.com/webservices.
Some Web Service functionality is available in shipping J2EE application servers. An example of this is the BEA WebLogic server 6.1 that provided Web Service functionality that pre-dates the final outcomes of any of the related JSRs. Due to the nature of the JCP, most vendors are able to track the progress of the JSRs and deliver functionality early to their customers.
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.
NOTE
At the time of writing, the Web Service standards and their Java APIs were still works in progress. Hence, the primary vehicle used in subsequent sections for creating and using RPC-style Web Services is Apache's Axis toolkit. This shows many indications that it is tracking the JAX-RPC JSR and so should have similar features and tools to the eventual reference implementation.
Integrating Web Services with Existing J2EE Components
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. 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.
){kind=link}
Figure 20.4 Web Services are just another channel through which to access business functionality.
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 helper classes (even servlets/JSPs that they use) as part of your Web Service implementation. If you already have servlets or JSPs that generate XML, you might be able to migrate them to meet your Web Service needs or transform the generated XML as part of the solution.