Section 4.3. SOAP Attachments


4.3. SOAP Attachments

In many use cases, applications need to send large amounts of binary data in a SOAP message. Binary data usually means nontextual information such as audio, images, or executables. Using the standardized serializations for SOAP, only characters that XML allows are permitted. Therefore, the only possible solution is to transform the binary data into characters using the Base64 content encoding scheme specified in the IETF RFC 2045. This solution has two major problems:

  • Encoding and decoding between binary and characters take a long time.

  • The message size increases substantially when the binary data is encoded as characters.

The result is degraded performance, particularly over low-bandwidth network links or when SOAP nodes have minimal processing power.

A solution to this problem is provided by two additional SOAP specifications: the SOAP Message Transmission Optimization Mechanism (MTOM) and the XML-binary Optimized Packaging (XOP). MTOM provides a way to identify any element information item in the SOAP message Infoset as a candidate for optimization. XOP specifies a way to serialize the various optimized elements and package them in the message to be transmitted.

To illustrate the use of MTOM, consider the following SOAP message Infoset:

 <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header>   ::: </env:Header>  <env:Body>   <m:myLogo xmlns:m="http://example.org/logo">HNoem0KA893nbnmsWNms9HWMOmeoNSA PSAAQbAQSbgUbA0WbAEZbAYbbAodbA8fbAAQkAQSkAgUkA0WkAEZkAYbkAodkA8fkAAgtAQitAgkt A0mtAEptAYrtAottA8vtAAg2AQi2Agk2A0m2AEp2nmsndkNSK678nnmsjkanwbrhjkreHJKDL8LKj                ::: qG4dSiwpp2eK4LZLr6tuqTWump4H4xSz6G1dioPCqT5eWq5EtdUdJSSoYLAMjqasWYLZYmTOrz+o 7aJOt+aM9rWrxut4DAArILM9t0kShRgCFJaUk+uvAgshVRaPlXebGyv67APwKb9qw/r0di/a6Cxn lELvZYABAsD==</m:myLogo>     :::    <p:myPhoto xmlns:p="http://example.org/photos">HlkR4kTYMCgoAQMAAAA AA8///ru6q/8zPzMzM/7v/CLsw6pne+4jPCIgACHcwFWYhBFUQBEQABDM AEBAsAAAAAAjAIKAAUw/gRRCFlmnopqrFHJvvNyyLw2Ji56789+/ADKcHia3OiMpSEoEobgKHDnS               ::: w83hCNkr0gECT1bgEaJigpDmwFEvYOkDCgYQLMus1QDgFUYOoGGN+gtPdYYgOMDZLhwyA+BHyDMR qweAJoAgAcYHvzTQktoAsODhl4LYBIDMevgtHPUDiAmg5gSQTUB8ETxO1HKAJRj4OI70AMeKgriF LOECAAwO=</p:myPhoto> </env:Body> </env:Envelope> 

In the message env:Body, two elements contain Base64 encoding of binary data. Element m:myLogo and p:myPhoto contain my logo and photograph, respectively. If these binary elements are small, it's all right to include them in the SOAP message. However, if the binary data is large (such as a set of medical images), it is necessary to find an alternative way of sending them via SOAP.

The SOAP processing model requires that a SOAP receiver reconstruct identically the Infoset that the SOAP sender generates. MTOM assumes that the receiving application requires the binary data and not the Base64 representation that is reflected in the Infoset. Therefore, MTOM provides an optimization feature that can bypass the Base64 encoding and decoding of binary data implied by the binary representation within an Infoset. To implement a SOAP feature, it's necessary to provide a protocol binding. MTOM provides an enhancement to the SOAP HTTP binding to transfer the optimized serialization. This enhancement is XOP.

The following example shows a SOAP message that is serialized using XOP.

 MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=example-boundary;   type=application/xop+xml;   start="<myInfo.xml@myCompany.example.org>"; startinfo="application/soap+xml;action=\"http://myCompany.example.org/Action\"" Content-Description: Optimized SOAP message example example-boundary Content-Type: application/xop+xml; charset=UTF-8 type="application/soap+xml;action=\"http://myCompany.example.org/Action\"" Content-Transfer-Encoding: 8bit Content-ID: myInfo.xml@myCompany.example.org> <?xml version="1.0"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"      xmlns:xmlmime="http://www.w3.org/2004/06/xmlmime">  <env:Body>   <m:myLogo xmlns:m="http://example.org/logo"      xmlmime:contentType="ímage/jpg"><xop:Include xmlns:xop="http://www.w3.org/2003/12/xop/include"       href="cid:logo.gif@myCompany.example.org"/>   </m:myLogo>      :::   <p:myPhoto xmlns:p="http://example.org/photos"       xmlmime:contentType="image/jpg"><xop:Include xmlns:xop="http://www.w3.org/2003/12/xop/include"           href="cid:johnPhoto.jpg@myCompany.example.org"/>   </p:myPhoto>  </env:Body> </env:Envelope> example-boundary Content-Type: image/jpg Content-Transfer-Encoding: binary Content-ID: <logo.gif@myCompany.example.org> ::: the binary data ::: example-boundary Content-Type: image/jpg Content-Transfer-Encoding: binary Content-ID: <johnPhoto.jpeg@myCompany.example.org> ::: the binary data ::: example-boundary 

The MIME multipart/related package includes a compound document broken into related parts. The root part of the document contains the original SOAP message with one major difference. The Base64 encoded data is replaced by an xop:Include element that points to other parts of the MIME package that include the raw binary octets. It does this by referencing the content-id of the MIME part with the binary data. This mechanism allows the costly encoding and decoding between binary and Base64 to be eliminated.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net