XML and Java: Developing Web Applications, Second Edition

13.5 Enterprise Web Services

How can we incorporate Web services into EAI? JSR 109 addresses enterprise Web services and attempts to develop a specification for a Web services container that sits on top of J2EE platforms.^[9] A core construct is the Service-Enabled EAR, which is an extension of the J2EE Enterprise Application Archive (EAR) for Web services. The Service-Enabled EAR includes a brand-new deployment descriptor called webservice.xml in addition to Java classes for implementing Web services. Listing 13.27 shows an example for a stock quote service. The webservice.xml deployment descriptor basically includes the source for generating WSDL documents and implementation-specific information. As for this particular example, the message and operation sections for a WSDL document are generated by looking up the specified Java class with Java reflection, and the binding and service sections are also generated to include in the WSDL document. The Web services container is responsible for creating such WSDL documents from Service-Enabled EAR files and is even responsible for publishing the WSDL documents to UDDI registries. On the other hand, a requestor finds the WSDL document via a UDDI registry, generates a client stub, and invokes the service with the JAX-RPC runtime.

^[9] The discussion here is based on a Java community draft specification and thus may be obsolete when a draft is released.

Listing 13.27 The deployment descriptor webservice.xml

<?xml version="1.0" encoding="UTF-8"?>
<Web-Services>
  <WSDL>
    <portType>
      <implementation-link>
        examples.stockservice.jar#stockquote
      </implementation-link>
      <binding>
        <soap><transport>http</transport></soap>
      </binding>
    </portType>
  </WSDL>
</Web-Services>

One of the important goals of JSR 109 is to integrate SOAP-based RPC and RMI seamlessly, as shown in Figure 13.14. Assume that a service is implemented as an Enterprise JavaBeans (EJB) component. The easiest way to access the service is to use RMI/IIOP stub code generated by the EJB platform. On the other hand, you can publish a WSDL document via a Web services container so that a requestor can generate client stub code梐 JAX-RPC stub. At runtime, the requestor application invokes the stub code to perform SOAP-RPC (typically over HTTP) by the JAX-RPC runtime. Once the server receives the SOAP-RPC message, the JAX-RPC runtime decodes the message to invoke the service EJB via RMI/IIOP. Note that the stub code for both RMI/IIOP and JAX-RPC has an identical API, so the requestor application does not have to be concerned with the difference between them. In other words, the actual means for remote invocation can be determined at runtime.

JSR 109 indicates an important change to the Web services definition. In this chapter and the previous one, we have had the following definition in mind (see Section 12.1.1).

Web services are applications that can be accessed via standard technologies such as XML and HTTP.

However, JSR 109 defines Web services this way.

A Web service is implemented by a J2EE-compliant component that implements an interface that is describable by WSDL and supported by JAX-RPC.

The key difference here is, the former emphasizes XML messaging, such as SOAP, and the latter emphasizes WSDL. From another perspective, the former addresses B2B collaboration on the Internet, and the latter addresses enterprise application integration within an intranet in addition to the Internet. For now, although we do not know which definition will be broadly accepted, major software vendors, such as Sun and IBM, seem to be moving toward the latter.