SCDJWS Study Guide: Web Service in General
Web Services Interaction Models
Web Service interaction models specify how the clients invoke and use the web services. Web Services offers two types of interaction models: RPC-Style Web Services and Document-Style Web Services. It's just that there are two ways to structure a SOAP message. In the early versions of SOAP (before it was publicly published), SOAP was designed to support only RPC style. By the time the SOAP 1.0 spec was published, it was expanded to support both RPCs and unstructured messages (document). When using Document style, you can structure the contents of the SOAP Body any way you like. When using RPC style, the contents of the SOAP Body must conform to a structure that indicates the method name and contains a set of parameters. The response message has a similar structure containing the return value and any output parameters. Your parameters can be as complex as you like, so there's really not a huge amount of difference in what you can pass.
The Simple Object Access Protocol (SOAP) offers two messaging styles: RPC (Remote Procedure Call) and document style. One is for creating tightly coupled, inter-object style interfaces for Web services components; the other is for developing loosely coupled, application-to-application and system-to-system interfaces.
What is the Remote Procedure Call(RPC)?
The Remote Procedure Call is a type of protocol that allows
an application running in one execution thread
on a system to call a procedure belonging to another application
different execution thread on the same or a different system.
The RPC is an easy and popular paradigm for implementing the
client-server model of distibute computing. The RPC model is a
well-tested, indstry-wide framework for distributing applicatiom. The RPC
(the collection of procedures used by the client side and provided by
the server side) are based on a request-response
model where one program calls, or
service of, another across a tightly coupled interface. The
client program sends a
message to the server to excute a certain procedure with appropriate
arguments and the server returns a message containing the results of
the program executed. Both clients and servers believe they are
called by, a locally running procedure. The RPC framework hides the
of moving data between the client and server.
RPC-Style Web Services
procedure call (RPC)-Style Web Services are tightly coupled and
interface-driven, which means that the business methods of the
implementation determine how the Web Service works. The clients invoke
Service by sending parameter values to the Web Service, and receiving
from the Web Service. RPC-style Web Services are tightly coupled
sending parameters and return values are as described in web service's
RPC-style Web services are typically characterized as synchronous, which means that the client sends the request and waits for the response till the request is processed completely before it continues with the remainder of its application. It is typically used for the process-oriented rather than data-oriented.
The client send SOAP request to a Web service, the SOAP request
contains the name of
be executed in the Web service and parameters that the method will need
when it is executed. The Web
Service converts this request to appropriate objects and executes the
sends the response as SOAP message to client. At the client side, this
is used to form appropriate objects and return the required information
to the client.
The following sample is the SOAP Body of RPC-style Web Service, which invokes GetStockQuote method with input parameter "ORCL".
RPC-style messaging's strength is as a bridging component technology. It is a good option for creating new components and for creating interfaces between Web services and existing components - you simply wrap existing components with RPC-style Web services interfaces. RPC-style messaging is also an excellent component standard in situations where you are using multiple technologies, such as J2EE and .NET, and want to develop sharable components.
RPC-style messaging weaknesses include:
- Strong coupling : A remote procedure call is meant to be relatively static and any changes, such as the number, order, or data types of the parameters, to the interface would break the contract between the client and the server.
- Synchronicity : Most programming languages assume synchronous method calls: the calling program normally waits for the called program to execute and return any results before continuing. Web services are asynchronous by nature and, in comparison to technologies such as DCOM and CORBA, long running. You may want to take advantage of Web services' asynchronous nature to avoid the user having to wait for calls to complete by developing asynchronous RPC calls, but that adds another level of complexity to your application. Some tools hide this complexity using callbacks, or other techniques, to enable processing overlap between the request and the response. Check to see if the tools you're using let you choose between synchronous and asynchronous RPC calls.
- Marshaling and serialization overhead : Marshaling and serializing XML is more expensive than marshaling and serializing a binary data stream. With XML, at least one side of the interface, and possibly both, involves some parsing in order to move data between internal variables and the XML document. There is also the cost of moving encoded text, which can be larger in size than its binary equivalent, across the interface.
The coupling and synchronicity issues are common to RPC-based component technologies. So they are really not discriminators when making comparisons between these technologies. The marshaling and serialization overhead is greater for RPC-style messaging and places this messaging style at a relative disadvantage. However, with today's high-speed processors and networks, performance is generally not an issue.
For Web services, SOAP defines the wiring between the calling and called procedures. At the SOAP level, the RPC interface appears as a series of highly structured XML messages moving between the client and the server where the Body of each SOAP message contains an XML representation of the call or return stack.
The steps of typical RPC-Style Web service message exchange process:
- The process begins with the client calling a method implemented as a remote procedure. The client actually calls a proxy stub that acts as a surrogate for the real procedure. The proxy stub presents the same external interface to the caller as would the real procedure, but instead of implementing the procedure's functionality, implements the processes necessary for preparing and transporting data across the interface.
- The proxy stub gathers the parameters it receives through its parameter list into a standard form, in this case, into a SOAP message, through a process called marshaling.
- The proxy stub encodes the parameters as appropriate during the marshaling process to ensure the recipient can correctly interpret their values. Encoding may be as simple as identifying the correct structure and data type as attributes on the XML tag enclosing the parameter's value or as complex as converting the content to a standard format such as Base64. The final product of the marshaling process is a SOAP message representation of the call stack.
- The proxy stub serializes the SOAP message across the transport layer to the server. Serialization involves converting the SOAP message into a TCP/IP buffer stream and transporting that buffer stream between the client and the server.
The server goes through the reverse process to extract the information it needs. A listener service on the server deserializes the transport stream and calls a proxy stub on the server that unmarshals the parameters, decodes and binds them to internal variables and data structures, and invokes the called procedure. The listener process may be, for example, a J2EE servlet, JSP (JavaServer Page), or Microsoft ASP (Active Server Page). The client and server reverse roles and the inverse process occurs to return the server's response to the client.
Document-Style Web Service
Document-Style (Message-Style) Web services are loosely coupled and document-driven. Message-style Web services are characterized as asynchronous with the potential for highly complex document structures. They are frequently used for data-oriented programming rather than process-oriented programming.
The client sends the parameter to the Web Service as a XML document fragment, instead of discrete set of parameter values to the Web Service. Message-Style Web service typically require transformation and routing based on content and are frequently part of longer running sequences. The input XML document can also be described in WSDL. The Web Service processes the document, executes the operation based on the payload and constructs & sends the response to the client as an XML document.
RPC-style Web Service, Document-style Web Service does not follow
semantics. The Web Service receives entire document, processes it
or may not return a response message. The SOAP Body of a document style
one or more XML documents, within its body. The protocol places no
on how that document needs to be structured, which is totally handled
application level. Document-style Web Service follows asynchronous
There is no direct mapping between the server objects (parameters, method calls etc) and the values in XML documents. The application has to take care of mapping the XML data values.
is an example SOAP body for Document-Style Web Service:
The parameters of the methods which are to be exposed by the document style Web Service should be of type XMLelement only. The return type of the method can be either an XML element or void.
NOTE: Document-Style web servives can use both one-way (non-blocking) calls and two-way (request-response) calls, but preferrable choice will be one-way calls.
The bigger difference in Web Service is how you encode the message. In most circumstances, you use literal encoding with Document style and SOAP encoding with RPC style. Literal encoding means that the Body contents conform to a specific XML Schema. SOAP encoding uses a set of rules based on the XML Schema datatypes to encode the data, but the message doesn't conform to a particular schema. SOAP encoding is particularly useful is you're passing cyclic object graphs. For example, if you have an element which is referenced repeatedly within the object graph, when using SOAP encoding, you would specify the element once and then reference the element as needed. When using literal encoding, you would have to repeat this element each time it's referenced. So obviously it sounds like a good idea to use SOAP encoding -- but, if you do, then you can't validate the message with an XML Schema, and you can't transform the message using XSLT.
messaging's strengths are in situations where an XML document is part
data being passed across the interface, where you want to leverage the
power of XML and XSL, and in instances where you want to minimize
between services forming an interface, such as in
and system-to-system interfaces.
Document-style messaging weaknesses include:
- No standard service identification mechanism : With document-style messaging, the client and server must agree on a service identification mechanism: a way for a document's recipient to determine which service( s) need to process that document. SOAP header entries offer one option; you can include information in the document's header that helps identify the service(s) needed. WS-Routing makes just such a proposal. Another option is to name elements in the <Body> of the message for the services that need to process the payload the elements contain. You might ask how that differs from schema-based RPC-style messaging. You would be right in assuming there is little or no difference except possibly in terms of the number of "calls" that can be made per message. A third option is to perform either structure or content analysis as part of a service selection process in order to identify the services needed to process the document.
- Marshaling and serialization overhead : Document-style messaging suffers from the same drawbacks as RPC-style messaging in this area. However, the problem may be more severe with document-style messaging. Document-style messaging incurs overhead in three areas: in using DOM, or another technique, to build XML documents; in using DOM, or SAX, to parse those documents in order to extract data values; and in mapping between extracted data values and internal program variables. Tools generating equivalent RPC-style interfaces optimize these transformations. You may have trouble achieving the same level of efficiency in your applications using standard tools.
There are two compelling reasons to use document-style messaging. One is to gain the independence it provides. Its strength lies in decoupling interfaces between services to the point that they can change completely independently of one another. The other is that document-style messaging puts the full power of XML for structuring and encoding information at your disposal. The latter is one reason many consider document-style superior to RPC-style messaging.
The difference between RPC-Style and Document-Style is primarily in the control you have over the marshaling process. With RPC-style messaging, standards govern that process. With document-style messaging, you make the decisions: you convert data from internal variables into XML; you place the XML into the Body element of the encapsulating SOAP document; you determine the schema(s), if any, for validating the document's structure; and you determine the encoding scheme, if any, for interpreting data item values. The SOAP document simply becomes a wrapper containing whatever content you decide.
The steps of typical
document-style message exchange
- The SOAP client create an XML document fragment based on the request parameters. The XML document may contain the namespace references that other applications can use for validating the encapsulated document's format and content.
- The SOAP client inserts the XML document fragment into the Body of a SOAP message.
- The SOAP client sends the SOAP message to the SOAP web service server across HTTP/HTTPS.
- The SOAP service extracts the XML document from the Body of the request SOAP message.
- The SOAP service binds the information it needs from the XML document to its own internal variables and executes the operation.
- The SOAP service create an XML document fragment based on the response values. The XML document may contain the namespace references that other applications can use for validating the encapsulated document's format and content.
- The SOAP service inserts the response XML document into the Body of a SOAP message.
- The SOAP service sends the SOAP message to the SOAP client in HTTP/HTTPS.
- The SOAP client extract
the response value from the XML document that is in the Body of a
response SOAP message.
RPC-style messaging maps to the object-oriented, component-technology space. It is an alternative to other component technologies such as DCOM and CORBA where component models are built around programmable interfaces and languages such as Java and C#. RPC-style messaging's strength in this space lies in its platform independence. It offers a standards-based, platform-independent component technology, implemented over standard Internet protocols. One of the benefits of this style's XML layer is that clients and servers can use different programming languages, or technologies, to implement their respective side of the interface, which means one side can choose one set of technologies, such as J2EE's JAX-RPC, while the other chooses a completely different set, such as .NET's C#. RPC-style messaging's standards heritage can be an important consideration in hybrid environments (one using multiple technologies such as J2EE and .NET) and can provide a transition path between different technologies.
Document-style messaging is clearly an option in any situation where an XML document is one of the interface parameters. It is ideal for passing complex business documents, such as invoices, receipts, customer orders, or shipping manifests. Document-tyle messaging uses an XML document and a stylesheet to specify the content and structure of the information exchanged across the interface, making it an obvious choice in situations where a document's workflow involves a series of services where each service processes a subset of the information within the document. Each service can use an XSLT to validate, extract, and transform only the elements it needs from the larger XML document; with the exception of those elements, the service is insensitive to changes in other parts of the document. The XSLT insulates the service from changes in the number, order, or type of data elements being exchanged. As long as the service creating the document maintains backwards compatibility, it can add or rearrange the elements it places into a document without affecting other services. Those services can simply ignore any additional data. Document-style messaging is also agnostic on the synchronicity of the interface; it works equally well for both synchronous and asynchronous interfaces.