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="/>
</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="/>
</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. |
لطفا منتظر باشید ...
