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
