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.
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.
|