Constituents of a JAX-RPC Server and Client Figure 11.2 shows the physical implementation of a JAX-RPC-based system. 
A JAX-RPC-based system has the following constituents: 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. | 
Print 
E-Mail 
Add Note 
Add Bookmark
