Differences between revisions 9 and 10
Revision 9 as of 2005-03-23 11:52:20
Size: 5494
Revision 10 as of 2009-09-20 22:48:18
Size: 5510
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
'''MTOM''' ([http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/ SOAP Message Transmission Optimization Mechanism]) describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message by selectively encoding portions of the message. '''MTOM''' ([[http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/|SOAP Message Transmission Optimization Mechanism]]) describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message by selectively encoding portions of the message.
Line 14: Line 14:
[http://www.cse.mrt.ac.lk/~gunarnkt/MTOM/img1/mtom1.jpg] [[http://www.cse.mrt.ac.lk/~gunarnkt/MTOM/img1/mtom1.jpg]]
Line 32: Line 32:
[http://www.cse.mrt.ac.lk/~gunarnkt/MTOM/img1/mtom2.jpg] [[http://www.cse.mrt.ac.lk/~gunarnkt/MTOM/img1/mtom2.jpg]]
Line 48: Line 48:
[http://www.cse.mrt.ac.lk/~gunarnkt/MTOM/img1/mtom3.jpg] [[http://www.cse.mrt.ac.lk/~gunarnkt/MTOM/img1/mtom3.jpg]]
Line 76: Line 76:
    * [http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/ SOAP Message Transmission Optimization Mechanism]     * [[http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/|SOAP Message Transmission Optimization Mechanism]]
Line 78: Line 78:
    * [http://www.w3.org/TR/2005/REC-xop10-20050125/ XML-binary Optimized Packaging]     * [[http://www.w3.org/TR/2005/REC-xop10-20050125/|XML-binary Optimized Packaging]]
Line 80: Line 80:
    * [http://www.java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/activation/ Java Activation Framework]     * [[http://www.java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/activation/|Java Activation Framework]]
Line 82: Line 82:
    * [http://java.sun.com/products/javamail/ Java Mail API]     * [[http://java.sun.com/products/javamail/|Java Mail API]]

1.Implementation of MTOM for AXIOM

MTOM (SOAP Message Transmission Optimization Mechanism) describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message by selectively encoding portions of the message. This implementation focuses on implementing MTOM on top of AXIOM.

1.1. Architecture

1.1.1. De-Serializer


  1. Transport module has the responsibility of identifying MTOM messages. Depending on the message type (MTOM or pure SOAP) transport has to choose the appropriate builder (MTOMStAXSOAPBuilder or StAXSOAPModelBuilder). Identifying of MTOM messages can be done by looking at the “Content-Type” and “type” headers of the message.
    • Content-Type: Multipart/Related;boundary=MIME_boundary;


  2. MTOMStAXSOAPBuilder assumes that the Input Stream provided to it contains an MTOM encoded MIME message. It passes the Input stream to MTOMHelper.
  3. MTOMHelper extracts the root mime part (which contains the XOP soap message) from the InputStream. Then it instantiate an XMLStreamReader using the SOAP message inside that root mime part and return it to the MTOMStAXSOAPModelBuilder.

  4. MTOMStAXSOAPModelBuilder deferred builds the AXIOM using that parser. When it comes across an xop:include element with the below mentioned namespace it creates an OMBlob node instead of an OMElement node.
  5. This OMBlob nodes keeps the “CID” value read from xop:include element and a reference to the MTOMHelper in it.


1.1.2. OMBlob

OMBlob reads the MIME part referenced by it only when a request (When somebody invokes getDataHandler() method of OMBlob) comes for the actual binary data referenced by it. At that point OMBlob uses its MTOMHelper reference to access the MIME message and “CID” to identify the part. MTOMHelper first check whether it has already parsed the corresponding MIME part. If not it parses MIME parts one by one till it meets the correct MIME part. MTOMHelper achieves deferred parsing of the MIME message.

The binary data coming as base 64 encoded strings will remain as OMText nodes. OMText node contains an getDataHandler() method which can be used to extract the binary data from OMText, when the user is aware (by looking at the WSDL) that the OMText contains base 64 encoded binary. Also the binary attachments which are not qualified to be optimized should remain as base 64 encoded strings inside OMText nodes, to preserve the infoset in both ends.

1.1.3. Serializer

MTOMXMLStreamWriter should to be used when the message needs to be optimized using MTOM. This will ensure that OMBlobs in the AXIOM will be attached to the message by MTOM optimizing. This MTOMXMLStreamReader buffers the output stream taken from the internally initialized XMLStreamWriter.

The “complete()” method of the MTOMXMLStreamWriter has to be called only after serializing the whole document. Only at this point the MTOMXMLStreamWriter starts creating the MIME message.


  1. AXIOM with OMBlobs which needs to be optimized should be serialized with MTOMStAXWriter.
  2. MTOMStAXWriter generates a content id (CID) for the OMBlob & stores that CID & OMBlob reference pair in a HashMap.

  3. Creates an XOP:include element with the correct namespace and uses the above generated content id as the value for the “href” attribute. OutputStream from the StAXWriter has been buffered.

  4. MTOMStAXWriter starts creating the MIME message only after the complete() method is called by the user and assumes that the whole AXIOM has been serialized.
  5. Buffered output (SOAP Message) from the StAXWriter is used to create the root MIME part.
  6. Creates MIME parts for all the value pairs in the HashMap mentioned in 2. CID is used for the CID of the mime part while the content in the OMBlob is used as the content.

Content in the OMBlob will be serialized as base64encoded strings when plain XMLStreamWriter is used to serialize an AXIOM containing OMBlobs. This can be used when the whole message is not qualified for MTOM optimization.

2. To Do

Have to look at following specifications.

3. References

Axis2/MTOM (last edited 2009-09-20 22:48:18 by localhost)