Working with JAX-RPC
In This Chapter
JAX-RPC Working Mechanism
Constituents of a JAX-RPC Server and Client
The javax.xml.rpc Package
The xrpcc Tool
The Types Supported by JAX-RPC
The CarPartRequest Web Service
The CarPartRequestClient Application
RPC stands for remote procedure calls. RPC is used for making procedure or function calls and receiving the responses, both over the network. During the days of procedural languages, this was the de facto method by which distributed applications communicated with each other. This often involved fairly complex socket programming to exchange data between the two remote applications.
However, the growth of object-oriented programming saw a steady decline in the use of procedural languages for business applications. It became evident that using object-oriented paradigms could result in a better return on investment (in terms of scalability, development time, and so on). So, the world of business applications moved from procedural languages to object-oriented languages, such as Java. However, this led a new level of complexity in communication between distributed applications. Methods in object-oriented languages could not only return and take as parameters simple data types, but also complex objects such as vectors. With increasing complexity, it became increasingly difficult to use RPC to represent complex objects. Another complexity stemmed from the fact that more often than not, the distributed applications are on heterogeneous systems. This means that the data exchanged between two applications written in different languages must be coded so that it can be used by these applications.
These complexities led to the gradual decline of RPC for low-level socket communications and the development of a plethora of alternative techniques. In the Java world, the primary new approach is Remote Method Invocation (RMI). Although useful in its own way, RMI has its own set of issues.
RMI is very resource-intensive because it needs to use quite a few classes. Also, JRMP, the backbone of RMI, is poor on performance. Of course, you could go ahead and write your own remote protocol, but that is not necessarily the easiest of programming tasks. Additionally, as clients make RMI calls, sockets need to be opened and maintainedthis also adds to the overhead. RMI also requires that the objects that can be called be bound to a server such as LDAP, an RMI registry, or a JNDI service. RMI is Java-only. This leads to the issue that the communicating parties have to be on Java to use RMIs, which is very difficult to ensure in a heterogeneous environment like the Internet. Finally, RMI-based applications require a lot of coding effort because there are quite a number of interfaces and classes that need to be implemented. So, while RMI solved the problem of how to exchange objects, it still had its complexities in terms of performance and simplicity of use.
But how did RPC come back in fashion? The proliferation of the Internet and the emergence of XML gave rise to the possibility of using XML as an RPC mechanism. The fall of RPC was primarily for two reasons: the necessity of using socket programming to provide a transport mechanism for data, and the difficulty in representing complex objects. The ubiquity of the Internet meant that almost every imaginable system had support for HTTP, so it could be used as the transport mechanism of choice. The rise of XML ensured that it was possible to textually describe objects in a standard way that could be understood by all systems, regardless of the environments and languages. The XML-based SOAP specification provides the necessary standard mechanism by which to use RPC. In this chapter, you will learn about the JAX-RPC mechanism of using XML-RPC, as well as how to use APIs defined in the JAX-RPC specification to create a Web service and a client.
JAX-RPC Working Mechanism
JAX-RPC uses SOAP and HTTP to do RPCs over the network. The SOAP specification defines the necessary structure, encoding rules, a convention for doing RPCs, and its corresponding responses. The RPCs and responses are transmitted over the network using HTTP as the primary transport mechanism.
From an application developer's point of view, an RPC-based system has two aspects: the server side (the Web service) and the client side. The Web service exposes the procedures that can be executed, and the client does the actual RPC over the network.
As discussed in earlier chapters, a Web service environment is based on open standards such as SOAP, HTTP, and WSDL. It is therefore possible that a Web service or a client wasn't developed using the Java platform. However, JAXR-RPC provides the mechanism that enables a non-Java client to connect to a Web service developed using Java platform, and vice versa. This chapter will focus on the development of a Web service and a client using JAX-RPC.
Communication exchange between a JAX-RPC client program and a Web service.
Before we discuss the communication exchange process, you need to understand what stubs and ties are. Stubs are local objects that represent the remote procedures. Ties are classes that reside on the server and enable communication with the client.
It is assumed that the client is aware of the Web service and the remote procedure that it can execute on the Web service. This is what happens:
The client calls the method on the stub that represents the remote procedure.
The stub executes the necessary routines on the JAX-RPC runtime system.
The runtime system converts this method call into a SOAP message and transmits the message to the server as an HTTP request.
The server, upon receipt of the SOAP message, invokes the methods on the JAX-RPC runtime. The JAX-RPC runtime converts the SOAP request into a method call.
The JAX-RPC runtime then calls the method on the tie object.
Finally, the tie object calls the method on the implementation of the Web service.
The response to the RPC call is sent in a SOAP response message as an HTTP response.
Now let's look at the physical implementation of a JAX-RPC-based server and client.
Constituents of a JAX-RPC Server and Client
Figure 11.2 shows the physical implementation of a JAX-RPC-based system.
Physical implementation of a JAX-RPC-based system.
A JAX-RPC-based system has the following constituents:
The Web service
The container in which the Web service is located
The WSDL file
The client application
The JAX-RPC runtime classes
The Web service is represented by two files: the service definition interface, and the corresponding implementation class. The service definition interface and the implementation class are collectively known as the service endpoint. An application developer has to write the interface and the implementation class constituting the service endpoint. As you will see later, the service definition interface extends the Remote interface of the rmi package and declares the methods that can be executed remotely.
The service endpoint is deployed in a container-based JAX-RPC runtime system. Typically, this is either a servlet or a stateless session bean deployed on an EJB container. In this chapter, we will use the Tomcat Web server and a servlet as the container for the service endpoint.
The ties are lower-level classes that are used by the server to communicate with the client. These are created by a tool called xrpcc.bat (or xrpcc.sh, if you are a Unix user).
The xrpcc tool also creates the WSDL file. A WSDL file is an XML document that describes the remote procedure call in a platform-independent way. This file enables the Web service to be accessible by clients, even if they are not on the Java platform. As an application developer, you need to run the xrpcc tool to generate the ties and the WSDL document. The WSDL document defines the parameters that a method can take, as well as the method's return value, which is expressed as an XML schema definition (XSD) data type. The JAX-RPC mechanism provides a direct mapping of these XSD data types to Java language types. For example, if a procedure returns a String value, then the WSDL document will describe the return type as xsd:string. Similarly, if a WSDL document declares that a method can take an xsd:dateTime type as parameter, then the JAX-RPC mechanism maps that to the Calendar data type in the Web service. As a developer, you won't need to worry about these mappings, because they are handled automatically by the xrpcc tool.
The client application is the application that makes the remote procedure call on the Web service. As an application developer, you need to create the application program.
The stubs are the local objects that represent the remote service. You can create the stubs by using the xrpcc tool.
In some scenarios, it's possible that the client is not aware of the signature of the remote procedure or the name of the service until runtime. To handle such cases, the client can use the dynamic invocation interface (DII). A client that uses the dynamic invocation interface does not use static stubs. A client that uses the DII is also more complex to code and implement than clients that use static stubs.
The JAX-RPC runtime classes are provided with the reference implementation.
Now let's look at the packages that make up the JAX-RPC environment.
The JAX-RPC specification defines the following packages:
Of all these packages, the one that you need to be concerned about as an application developer is the javax.xml.rpc package. It contains the interfaces that you will be using while developing the clients that use JAX-RPC mechanisms to perform remote procedure calls.
The classes of the other packages are used by the JAX-RPC runtime, or by xrpcc to generate stubs, ties, and the WSDL document.
The javax.xml.rpc Package
The javax.xml.rpc package contains the three interfaces, two classes, and two exceptions that you will use for developing JAX-RPC-based clients.
The javax.xml.rpc Interfaces
The interfaces in the javax.xml.rpc package are as follows:
CallThe Call interface is used by a client that uses the DII to call a remote procedure. The Call interface provides a number of methods with which a client can access the remote procedures.
ServiceThe Service interface is essentially used as a factory to create instances of the Call interface.
StubThe Stub interface is the base interface for the stub classes. Instances of the stub classes represent the procedures at the server. A client calls the method on a stub, and it is up to the stub to take up the remote procedure call from then on.
The javax.xml.rpc Classes
The classes in the javax.xml.rpc package are as follows:
ServiceFactoryThe ServiceFactory is an abstract factory class that enables you to create instances of the Service interface.
NamespaceConstantsThe NamespaceConstants class contains the constants that are used in JAX-RPC for namespace prefixes and URIs. For example, the NSPREFIX_SCHEMA_XSD represents the namespace prefix for the XML schema XSD.
ParameterModeThe ParameterMode class is an enumeration for parameter mode. It defines three constants that determine whether the parameter is of IN, OUT, or INOUT type. This class is used in the addParmeter(..) methods of the Call interface to determine the type of parameter that is being added.
The javax.xml.rpc Exceptions
The exceptions in the javax.xml.rpc package are as follows:
JAXRPCExceptionThe JAXRPCException is thrown when the JAX-RPC runtime fails to operate as expected.
ServiceExceptionThe ServiceException is thrown when the methods of the Service interface or the ServiceFactory class fail to execute as expected.
Now let's take a detailed look at the xrpcc tool.