Hi Raymond, Sorry for the late response, I have been little busy with other things that's going on. Talking about the MTOM support.....
Yes you are right, MTOM is a specification that focuses on solving the "Attachments" problem in SOAP messages. When a Web services users may want to transmit binary attachments of various sorts like images, drawings, XML docs, etc., together with a SOAP message, then MTOM optimization can be used in those cases where the attached binary content logically becomes inline (by value) with the SOAP document even though it is actually attached separately. Axis2 recommends to use AXIOM as the Object Model to hold binary data. As it has this ability as OMText can hold raw binary content in the form of javax.activation.DataHandler. OMText has been chosen for this purpose with two reasons. One is that XOP (MTOM) is capable of optimizing only base64-encoded Infoset data that is in the canonical lexical form of XML Schema base64Binary datatype. Other one is to preserve the infoset in both the sender and receiver. (To store the binary content in the same kind of object regardless of whether it is optimized or not). >From Tuscany point of view: 1. As per the recommendation, we have a difficulty in using OMElement as the binary datatype for attachments, this issue is raised as TUSCANY-2664. (TUSCANY-2664) Databinding issue when axis2 service uses OMElement as parameter types 2. We know that MTOM is only capable of optimizing base64-encoded data types, but in Tuscany we have an issue in identifying the data type from WSDL as we treat all the data type other than defaults like (string, int) as xsd:anyType. This issue is raised as TUSCANY-2754. (TUSCANY-2574) Validating WSDL against the Service Interface I beleive we need to address these issues, for a better MTOM support. Thanks. On Fri, Nov 14, 2008 at 10:00 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > By reading the test case, it seems that we can pass the binary data over WS > using javax.activation.DataHandler as the java data type. MTOM can be used > to control how the binary data is serialized in the payload. Can you > confirm? > > Do we support other binary data types such as java.awt.Image? > > Thanks, > Raymond > > From: Ramkumar R > Sent: Wednesday, November 05, 2008 11:50 PM > To: [email protected] > Subject: Update on Axis2 MTOM support in Tuscany > > > > Support for Axis2 MTOM is now enabled with fixes available from > TUSCANY-2611 following the check-in made using TUSCANY-2207 (we does not > seem to working). > > As discussed in thread... > http://www.mail-archive.com/[EMAIL PROTECTED]/msg26726.html > > <binding.ws requires="MTOM"/> > > can be used to enable the MTOM optimization on the client/server side. > > Enabling MTOM Optimization on the Client Side: > To enable MTOM optimization on the client side <binding.wsrequires="MTOM"/> > should be used with the reference bindings. By enabling > this feature, any SOAP envelope, regardless of whether it contains > optimizable content or not, will be serialized as an MTOM optimized MIME > message. > > Enabling MTOM Optimization on the Server Side: > The Axis 2 server automatically identifies incoming MTOM optimized messages > based on the content-type and de-serializes them accordingly. The user can > enable MTOM on the server side for outgoing messages. To enable MTOM > optimization on the server side <binding.ws requires="MTOM"/> should be > used with the service bindings. > > A junit test is available as part of binding-ws-axis2 module to demostrate > the same. [ > http://svn.apache.org/repos/asf/tuscany/java/sca/modules/binding-ws-axis2/src/test/java/org/apache/tuscany/sca/binding/ws/axis2/itests/mtom/ > ] > > NOTE: Any change in behaviour is not noticed through the testcase as change > is only noticed in the SOAP Envelope messages when MTOM is enabled. What you > can notice is that the MTOMStAXSOAPModelBuilder is used instead > StAXSOAPModelBuilder as the builder for SOAP messages for the > content-type:application/xop+xml. > > -- > Thanks & Regards, > Ramkumar Ramalingam > -- Thanks & Regards, Ramkumar Ramalingam
