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.

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).

Figure 20.5
A Java-based SOAP router.

---

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.

The JAX-RPC API

JAX-RPC defines a set of classes, interfaces, principles, and mechanisms for making SOAP-based RPC calls. The main parts are

• Type conversion between Java types and XML types—For simple types, such as strings and primitive types, very little work is required. More effort is required from either the tools or the developer when mapping more complex types between Java and XML.

• Mapping between SOAP operations defined in WSDL and Java remote method calls—Essentially, WSDL interfaces are represented in Java by Remote interfaces.

• The server environment and how calls are received and directed—The receiving Java class has access to particular information about the SOAP call provided through a service context. The lifecycle of a servlet-based service is defined.

• A client- and server-side SOAP message handler mechanism similar in concept to servlet filters.

• Client programming model describing the relationship between interfaces and stubs, and how these are obtained in different environments such as J2SE and J2EE.

The essential principle is that JAX-RPC tries to make the development of SOAP-based clients and servers fairly simple and intuitive for Java developers. To start your journey through Web Services, the first example is a simple, servlet-based JAX-RPC service and a standalone client for it.

This chapteris fromTeach Yourself J2EE in 21 Days, second edition, byMartin Bond et. al.(Sams, 2004, ISBN: 0-672-32558-6). Check it out at your favorite bookstore today. Buy this book now.