axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: [Axis2] Axiom MTOM output optimization
Date Sat, 25 Mar 2006 03:57:17 GMT
Perhaps I'm missing something here, but I thought one of the major 
benefits of Axis2 was supposed to be performance improvements from not 
building a DOM-style tree for all the data. If this tree has to be built 
for all output that seems to be throwing away any real potential for 
performance gains over Axis (especially since AXIOM is actually a much 
heavier model than most DOM implementations).

  - Dennis

Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting -
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117

Thilina Gunarathne wrote:

>>"this assumes that
>>transport takes the decision of whether to optimize or not by looking at
>>whether the MTOM optimize is enabled & also looking at the OM tree
>>whether it has any optimizable content". This doesn't seem a very useful
>>approach, if I'm understanding it correctly, since it seems to assume
>>that a full OM tree will be constructed for any output (including the
>>MTOM-optimizable portions, apparently).
>Yes.. This assumes the full OM tree is constructed.. We are mainly
>talking about the programatically created OM tree. But the constructed
>OM tree will not do any kind of serializations to the Binary parts..As
>an example, if we have created a OMText using a FileDataHandler, the
>data handler will get serialized only when the OM is serialized to the
>1 . In Axis2 we have a engine level switch to enable/disable MTOM in
>the out flow.
>2 . Irrespective of the above switch the envelope will get serialized
>without MTOM if the envelope do not contain any optimizable parts. (An
>optimizable part is an OMText containing binary data which has
>optimized property set to true.) We are serializing the envelope as
>MTOM optimised only if there are optimizable contents.
>We have to decide the serialization depending on the above two
>properties. We need to be aware of the type of serialization before
>going ahead with the serialization. That's why we are checking these
>two properties at the transport level. Other reason is certain
>transports (text based once such as SMTP) do not support MTOM.
>>My plans for handling this in JibxSoap revolve around passing a blob of
>>data (either byte[] or InputStream) with associated identifier to the
>>transport code if optimization is enabled. This means the serialization
>>interface is more than just an OutputStream (or an XMLStreamWriter), but
>>the payoff is that attachment data doesn't have to go through any kind
>>of intermediate serialization.
>We do had a similar kind of architecture for MTOM sometime ago when we
>used OMBlob. Later we chose the OMText to manipulate Binary data
>inorder to achieve consistancy in the OM tree's in both client and
>server sides irrespective of optimized or not. This proved to be very
>usefull and consistant when we started doing secure MTOM.
>>In the case of a file containing the
>>attachment data, for instance, a FileInputStream can be passed directly
>>to the transport as the source of data for a particular attachment.
>IMHO this is same to passing the OMText with DataHandler and the
>identifier (content-id).
>"May the SourcE be with u"

View raw message