Using Alternative SOAP Encodings

Of course some applications already deal with XML natively, and there are currently XML-based vocabularies in use today supporting a plethora of B2B applications. SOAP-based messaging can take advantage of the pre-existence of schemas to craft message exchanges that compliment existing systems using so-called document-style SOAP.

The way in which alternative SOAP encodings are handled is straightforward. Instead of encoding header or body content according to the SOAP Data Model, we simply encode according to the rules and constraints of our data model and schema. In essence, we can just slide our own XML documents into a SOAP message, providing we remember to specify the encodingStyle attribute (and of course ensuring that the intended recipients of the message can understand it). This style of SOAP encoding is known as literal style and naturally suits the interchange of business-level documents based on their existing schemas.

This is a definite boon to SOAP use and by our estimation, the future dominant paradigm for SOAP use. Its plus points include not only the ability to re-use existing schemas, but by dint of the fact that we are now dealing with message exchanges and not remote procedure calls, we are encouraged to design Web service interactions with much coarser granularity. In essence, we are changing from a fine-grained model that RPC encourages (you send a little bit of data, get a little bit back and make further calls until your business is completed), to a much coarser-grained model where you send all the data necessary to get some business process done at the recipient end, and expect that the recipient may take some time before he gets back to you with a complete answer.

One particularly apt view of the fine- versus coarse-grained view of Web services interactions is that of a phone call versus a facsimile transmission.[4] Where we interact with a business over the phone there is a great deal of back-and-forth between ourselves and the agent of the business to whom we are talking. We both have to establish contexts and roles for each other, and then enter into a socially and linguistically complex conversation to get business transacted. Small units of data are exchanged like "color" and "amount" that are meaningless without the context, and if the call is lost we have to start over. This is fine-grained interaction.

While we would not seek to undermine the value of good old human-to-human communication, sometimes we just don't have time for this. It's even worse for our computing systems to have to communicate this way since they don't get any of the social pleasures of talking to each other. A better solution is often to obtain a catalog or brochure for the business that we want to trade with. When we have the catalog, we can spend time pouring over the contents to see what goods or services we require. Once we are certain of what we want, we can just fill in and fax the order form to the company and soon our products arrive via postal mail.

This system is eminently preferable for business processes based on Web services. For a start, complex and meaningful data was exchanged that does not rely on context. A catalog and an order form are descriptive enough to be universally understood and the frequency of data exchange was low, which presents less opportunity for things to go astray. This system is also loosely coupled when the systems are not directly communicating (which only happens twice: once for catalog delivery and once while the order is being faxed). They are not affected by one another and do not tie up one another's resources quite the contrary to the telephone-based system.

[4] See "The 7 Principles of Web Services Business Process Management" at

Of course, we don't necessarily get something for nothing. The price that we must pay as developers is that we must write the code to deal with the encoding schemes we choose. In the SOAP RPC domain where the encoding is fixed and the serialization from application-level data structure to XML is governed by the SOAP Data Model, toolkits could take care of much of this work. Unfortunately, when we are working with our own schemas, we cannot expect SOAP toolkits to be able to second-guess its semantics and, thus, we have to develop our own handler code to deal with it, as shown in Figure 3-21.

Figure 3-21. Document-oriented SOAP processing.


The user-defined handler in Figure 3-21 is one of potentially many handlers deployed onto the SOAP server to provide the functionality to deal with SOAP messages encoded with arbitrary schemas. Where the SOAP RPC handler simply dispatches the contents of the SOAP RPC messages it receives to appropriate method calls, there are no such constraints on a Web service which uses document-style SOAP. One valid method would be to simply pick out the important values from the incoming document and use them to call a method, just like the SOAP RPC handler. However, as more enterprises become focused on XML as a standard means for transporting data within the enterprise boundary, it is more likely that the contents of the SOAP body will flow directly onto the intranet. Once delivered to the intranet, the messages may be transformed into proprietary XML formats for inclusion with in-house applications, or may be used to trigger business processes without the need to perform the kind of marshalling/unmarshalling required for SOAP RPC.

Note that irrespective of whether the application payload in SOAP messages is SOAP-encoded, or encoded according to a third-party schema, the way that header blocks are used to convey out-of-band information to support advanced Web services protocols is unaffected. Headers are an orthogonal issue to the application-level content.

Developing Enterprise Web Services. An Architect's Guide
Developing Enterprise Web Services: An Architects Guide: An Architects Guide
ISBN: 0131401602
EAN: 2147483647
Year: 2003
Pages: 141 © 2008-2017.
If you may any questions please contact us: