On Mon, Dec 8, 2008 at 10:41 AM, Ramkumar R <[email protected]> wrote:
> 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 > I've just been looking at the work that's been going on with MTOM so far. I've corrected a few things in the MTOM unit test [1] that I believe is being constructed to motivate development. Primarily the client now calls the service and I've added requires="MTOM". Looking at the code I think there are some more things that need to be done. The main thing that we need to look at is the Axiom objects that we use to represent datatypes that hold binary data. Looking at the Axis2 documentation for MTOM support [2] it seems that they reply on using OMText elements (which are configured to be optimizable) to identify which elements should be passed in separate MIME attachments. At the moment I think we just pass parameters as OMElements. These get passed OK in as much as the data is base64 encoded in line but this may not be the required effect. If for example we are passing a large image we probably just want that passed as is without the extra overhead of base64 encoding. So I suspect this will involve a little databinding configuration and some new transformers to spot binary types and create OMText elements in the right places. I haven't thought through the details here just yet so any thoughts welcome. Regards Simon [1] http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/modules/binding-ws-axis2/src/test/java/org/apache/tuscany/sca/binding/ws/axis2/itests/mtom/ [2] http://ws.apache.org/axis2/1_0/mtom-guide.html
