Creating a Web Service with JAX-RPC
As discussed earlier, the JAX-RPC specification defines how Web Service clients written in Java can make RPC-style calls on Web Services and how Web Services can be written in Java to receive such calls. The Implementing Enterprise Web Services specification defined in JSR109 describes how such Web Services and Web Service clients can be used as part of a J2EE application. Although it is possible to use other transport mechanisms and interaction styles, the main focus of JAX-RPC is for making synchronous calls on top of the SOAP transport. Hence, the remainder of today will focus on building clients and servers that take part in this type of exchange.
RPC-Oriented Web Services
Remote Procedure Calls (RPCs) made over Web-based protocols are essentially no different from those made over other protocols, such as IIOP, DCOM, or JRMP. The calls are usually synchronous (in other words, the client waits for the method to return before continuing). Zero or more parameters of varying types are passed into the call to provide information to process, and zero or more return values are generated to deliver the outputs of the remote method to the client. The remote method calls are delivered to some form of dispatcher at the remote server that determines which method should be called and arranges for the smooth flow of parameters and return values.
For RPC-style operation, SOAP implementations conform to the preceding description. The difference with SOAP (and other Web-based RPC mechanisms, such as XML-RPC) is that it uses standard, general-purpose transports, such as HTTP, together with a text-based method call description in XML. All the parameters and return values are encoded in XML as part of the SOAP body, while information about the service and method to call are provided in the transport header and possibly the SOAP header. When sent over HTTP, the SOAP header and body are wrapped in another XML document—the SOAP envelope—and this envelope forms the body of an HTTP POST request.
An HTTP-based SOAP message will be delivered to a SOAP router that takes the form of an HTTP servlet (for a Java implementation). The SOAP router will examine the HTTP and SOAP header information and decide how it should forward the message body. This will involve instantiating or calling a particular component or class that will receive the message. The SOAP router, or its helper classes, will also perform the conversion of the XML-based parameters into Java objects and primitives that can be passed as part of the service invocation. Figure 20.5 shows the operation of such a SOAP router. Note that the description of the Web Service is used by both the client and server to help determine the correct mapping between Java and XML for method calls and parameter types.
Figure 20.5. A Java-based SOAP router.
This is all good, but why go to this effort? Why not use an existing RPC mechanism, such as RMI, or just use HTTP itself?
The justification for not using RMI or CORBA to integrate applications relates to commonality and security. There are at least three different distributed object protocols (CORBA, RMI, and DCOM), each of which has its adherents. The use of HTTP and XML provides a common protocol that is not tied to any vendor. Also, the traditional RPC protocols listed have great difficulty in penetrating most firewalls (not surprising, given their capability to invoke random functionality). However, HTTP (and SMTP) has general right of access through most firewalls, which makes it easier to integrate applications across organizational boundaries (after the security questions are sorted out).
CAUTION
From a developer's perspective, one of SOAP's greatest assets is its capability to penetrate firewalls. However, from an administrator's point of view, this presents the same types of problem as traditional RPC, namely the capability to target a random function call at an exposed server. Although the principle of SOAP is only a small step up from the invocation of server-side functionality such as CGI, great care should be taken to ensure adequate security when exposing Web Services. The overall security story for Web Services is still a work in progress.
Although raw HTTP is a good transport, it was created to exchange simple HTML messages. This does not provide the sophistication required for a distributed invocation environment. The use of a defined XML message format brings structure to this environment and allows for the interoperability of Web Service clients and servers from different vendors—something that escaped CORBA until comparatively recently.
So, Web Service protocols have some large advantages over traditional RPC protocols. However, you need to be careful about where you apply Web Service protocols. Such protocols are primarily intended for the integration of coarse-grained components or application functionality. As mentioned earlier, this might be exposed at the same system boundary as an HTML interface on the same functionality. Internally, the system might use RMI CORBA or DCOM to distribute functionality across several tiers. This is fine; there is no need to replace all distribution mechanisms with Web Service protocols. Web Service interfaces should usually be exposed only at the system boundary, not within the system itself.
Now that you understand the architecture and motivation for RPC-style Web Services, you can create a Java-based Web Service client and server.