You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2006/03/23 11:22:08 UTC
[Axis2] Axiom MTOM output optimization
Looking at the code in OMOutputImpl it's not clear to me how the MTOM
handling is supposed to work. The JavaDocs say "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).
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. 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.
I know we've discussed this a bit in the past - anyone have any updates
or planned improvements in the current Axis2 approach?
- Dennis
--
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
Re: [Axis2] Axiom MTOM output optimization
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
Thilina Gunarathne wrote:
>Hi,
>
>
>>"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
>OutputStream.
>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).
>
>HTH.
>
>~Thilina
>
>--
>"May the SourcE be with u"
>http://webservices.apache.org/~thilina/
>http://thilinag.blogspot.com/
>http://www.bloglines.com/blog/Thilina
>
>
>
Re: [Axis2] Axiom MTOM output optimization
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi,
> "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
OutputStream.
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).
HTH.
~Thilina
--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
http://www.bloglines.com/blog/Thilina