Download (direct link):
The goal of the RPC style of SOAP messaging is to make calling a procedure on a remote computer similar to calling a procedure on the local system. The intention of RPC technology is to make calling this remote procedure (located someplace on the network) as transparent as possible to the programmer. One nice feature about the RPC style of communication is that programmers don't need to worry about encoding and decoding parameters because these parameters are marshaled and unmarshaled automatically. There are drawbacks, though, to this RPC architecture. First, both client and server must be simultaneously running in order for the RPC call to succeed. This makes sense in the context of executing procedures, but it is not flexible for more general distributed computing. Next, this RPC structure is not robust to changes in the API for the data being passed back and forth — that is, changes in the data passed are likely to break the interface. The RPC scheme of sending SOAP messages is familiar to most programmers, and it has some advantages but many limitations.
In contrast is the message-oriented style of passing SOAP messages. In this paradigm, messages are passed between processes. This is accomplished by APIs such as send_message() or get_message(). One advantage of this message-oriented scheme is that the client and server don't need to be running at the same time. The client can send the server a message that is queued until the server is up. When the server receives the queued message from the client, it processes it and sends the reply to the client. Again, this message can be queued until the client is available to receive the message. The message style of communication allows direct (such as in RPC) and queued structure, which gives this style of using SOAP more flexibility than the RPC structure. This message structure is a looser coupling between client and server as they exchange data between themselves because the program itself must encode and decode the data, which allows more flexibility in processing this data. Changes in the order or type of data passed are less likely to break a well-designed message-based soap service. This message-passing architecture is more flexible, but it is more complex for the programmer to use than the RPC paradigm.
The preceding discussion illustrates the flexibility of SOAP because it can be utilized in many different ways. SOAP supports both synchronous (RPC and direct messaging) and asynchronous (queued messages)
234 Chapter 12
communications between users. The application of the end-2-end argument illustrates why letting applications decide what paradigm of distributed processing (RPC or messages) is more appropriate than forcing the application into a predefined model. The ideas behind SOAP have existed in previous distributed computation environments, but for the first time, the major players have agreed to use SOAP to enable communication between distributed computer systems. SOAP has a good chance of success because it's flexible and extendable and, perhaps most importantly, because there is agreement among the biggest vendors that SOAP is the standard to define messaging between systems.
WSDL — Web Service Description Language
We know how soap services communicate with XML-encoded data within SOAP envelopes, but how do these clients know how to use these soap services? That is the job of WSDL. WSDL is just another Interface Definition Language (IDL), with one big difference from the IDLs of CORBA, DCOM, and others — everybody agrees that WSDL is the standard to describe soap services. As expected, WSDL is defined with XML. WSDL describes everything needed to use the soap service, as well as what to expect back from the service. This includes information such as what protocol is used to transport the SOAP message (HTTP, SMTP, or FTP), how the data passed between client and server is structured, what it means, and the URI by which the service is accessed. Soap services can exist without a WSDL description, but without this description, clients can't figure out in an unambiguous manner how to access the desired soap service.
Describing the interface to a particular soap service is important to its successful adoption. The details of how this is specified are not important, but understanding the type of information required to use the soap service successfully is. Following is a list of some important information that needs to be documented:
¦ For each message between the client and the server, the structure of the data must be described. This function associates a data type with each item of data passed in a message between client and server.
The types element is used for this function.
¦ Each message passed between the client and the server must be specified. This function names each message that has a types definition. The message element is used for this function.
Web Applications and Services 235
¦ For each soap service, the interaction between the client and the server needs defining. Does the service expect a request-response, or is the interaction different? The portType element explains details of this interaction between client and server.