|
|
As Figure 10.1 shows, the service model for JAX-RPC is similar to other RPC models, such as RMI-IIOP and CORBA. The model has several components.
The layers shown in Figure 10.1 correspond to the Open System Interconnection (OSI) networking model, which has these characteristics:
The physical layer conveys the bitstream through the network.
The data link layer encodes and decodes data packets into bits.
The network layer provides switching, routing, packet sequencing, addressing, and forwarding between virtual circuits, to transmit data from node to node.
The transport layer provides transparent transfer of data between hosts and is responsible for end-to-end error recovery and flow control. Clearly, the HTTP binding for SOAP lacks some of this, whereas other bindings, such as POP-SMTP, IMAP, and JMS do not.
The session layer establishes, coordinates, and terminates connections, exchanges, and dialogs between the applications.
The presentation layer, also known as the syntax layer, provides independence from differences in data representation by translating from application to network format, and vice versa. The presentation layer works to transform data into the form the application layer can accept.
The application layer is the actual application and end-user processes, where business functionality is addressed.
Although JAX-RPC relies on complex protocols, the API hides this complexity from the application developer. On the server side, the developer specifies the remotely accessible procedures by defining methods in a Java service definition interface and writing one or more Java classes that implement those methods. JAX-RPC exposes these objects as a service endpoint and generates the relevant ties. The client never directly communicates with the service implementation. The client uses a stub or other mechanisms to communicate with the endpoint (covered later in this chapter), and the endpoint uses the tie. The client then invokes the service, passing in relevant parameters, and the service returns the results to the client.
Before we dive into the internals of this model, we will take a look at the data types and see how the marshalling and unmarshalling occurs. We will then see how to use that in developing JAX-RPC services.
|
|
