Re: Update on Axis2 MTOM support in Tuscany

[Ramkumar R <ra...@gmail.com>]

Hi Simon,

Looking more closely at the Axis2 documentation for MTOM support [1] and
with some research in this area... here are few findings

1. Looks like its not mandatory to use AXIOM Object Model (OMElement /
OMText) to hold binary data always, its may be useful when we need pass an
optimized content. For optimum efficiency of MTOM, a user is advised to send
smaller binary attachments using base64encoding (non-optimized) and larger
attachments as optimized content.

2. You can define a service method parameter as binary element in your WSDL
using the schema type="xsd:base64Binary". Having an element with the type
"xsd:base64Binary" is enough for the Axis2 code generators to identify
possible MTOM attachments, and to generate code accordingly.

3. As per JAXB 2.0 specs, java classes like java.awt.Image,
javax.activation.DataHandler and javax.xml.transform.Source can be mapped to
""xsd:base64Binary".

Hope the above points answers some of the questions raised in this thread
earlier.

Also from Tuscany point of view using OMElement as the binary datatype for
attachments had an issue (TUSCANY-2664) earlier. Similarly I see the same
issue while using java.awt.Image and javax.xml.transform.Source as datatype
for attachments for binding.ws. I have also updated TUSCANY-2664 with this
information.

[1] http://ws.apache.org/axis2/1_4/mtom-guide.html<http://ws.apache.org/axis2/1_0/mtom-guide.html>


On Thu, Dec 18, 2008 at 12:05 AM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Mon, Dec 8, 2008 at 10:41 AM, Ramkumar R <ra...@gmail.com> 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 <en...@gmail.com>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: dev@tuscany.apache.org
>>> 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/tuscany-dev@ws.apache.org/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
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: Update on Axis2 MTOM support in Tuscany

[Ramkumar R <ra...@gmail.com>]

Hi Simon,

My comments inline.....

On Thu, Jan 29, 2009 at 6:29 PM, Simon Laws <si...@googlemail.com>wrote:

> Hi Ram
>
> On Thu, Jan 29, 2009 at 11:26 AM, Ramkumar R <ra...@gmail.com>wrote:
>
>> Hi Simon,
>>
>> Looking more closely at the Axis2 documentation for MTOM support [1] and
>> with some research in this area... here are few findings
>>
>> 1. Looks like its not mandatory to use AXIOM Object Model (OMElement /
>> OMText) to hold binary data always, its may be useful when we need pass an
>> optimized content. For optimum efficiency of MTOM, a user is advised to send
>> smaller binary attachments using base64encoding (non-optimized) and larger
>> attachments as optimized content.
>>
>
> When you say " when we need pass an optimized content" what are you getting
> at? By optimized here do you mean using MTOM? Does this mean it should be
> used to send content that is to be optimized when the data is not one of the
> formats you list below. For example, what happens if I have byte[] that I
> want to flow via MTOM.
>

Ok for using MTOM, the content need not be necessarily optimized always. But
if the user like to get an optimized performance from MTOM then you will
need to optimize your content as well.
And yeah, when ever the user is trying to send a data that is not mapped to
base64encoding by default (as per JAXB 2.0 specs), then its a good option to
go for a optimized content by using AXIOM Object Model (OMElement / OMText)
to hold the data.

Also just using AXIOM Object Model (OMElement / OMText) does not mean the
content is optimized, to optimize the content you need to set the property
doOptimize as true/false as shown below.

//create an OMText node with the DataHandler and set optimized to true
OMText textData = *fac.createOMText(dataHandler, true);*

//User can set optimized to false by using the following
textData.doOptimize(false);



>
>
>
>>
>> 2. You can define a service method parameter as binary element in your
>> WSDL using the schema type="xsd:base64Binary". Having an element with the
>> type "xsd:base64Binary" is enough for the Axis2 code generators to identify
>> possible MTOM attachments, and to generate code accordingly.
>
>
> OK, I need to remind myself what the databinding framework does under
> covers in this situation.
>
>>
>>
>> 3. As per JAXB 2.0 specs, java classes like java.awt.Image,
>> javax.activation.DataHandler and javax.xml.transform.Source can be mapped to
>> ""xsd:base64Binary".
>
>
> Do you happen to know if our WSDLgen works correctly in this respect. I
> don't remember if there are tests for this sort of thing so I'll have to go
> and look.
>

In Tuscany, we need to improve the WSDLgen to map the datatype as per JAXB
2.0 specs, currently we have an issue in identifying the data type for WSDL
as we treat
all the data type other than basic data types like (string, int) as
xsd:anyType. This issue was raised as TUSCANY-2754 sometime back.


>
>
>>
>> Hope the above points answers some of the questions raised in this thread
>> earlier.
>>
>> Also from Tuscany point of view using OMElement as the binary datatype for
>> attachments had an issue (TUSCANY-2664) earlier. Similarly I see the same
>> issue while using java.awt.Image and javax.xml.transform.Source as datatype
>> for attachments for binding.ws. I have also updated TUSCANY-2664 with
>> this information.
>>
>> [1] http://ws.apache.org/axis2/1_4/mtom-guide.html<http://ws.apache.org/axis2/1_0/mtom-guide.html>
>
>
> Thanks for the update Ram. We need to run these to ground.
>
> ...snip
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: Update on Axis2 MTOM support in Tuscany

[Simon Laws <si...@googlemail.com>]

Hi Ram

On Thu, Jan 29, 2009 at 11:26 AM, Ramkumar R <ra...@gmail.com> wrote:

> Hi Simon,
>
> Looking more closely at the Axis2 documentation for MTOM support [1] and
> with some research in this area... here are few findings
>
> 1. Looks like its not mandatory to use AXIOM Object Model (OMElement /
> OMText) to hold binary data always, its may be useful when we need pass an
> optimized content. For optimum efficiency of MTOM, a user is advised to send
> smaller binary attachments using base64encoding (non-optimized) and larger
> attachments as optimized content.
>

When you say " when we need pass an optimized content" what are you getting
at? By optimized here do you mean using MTOM? Does this mean it should be
used to send content that is to be optimized when the data is not one of the
formats you list below. For example, what happens if I have byte[] that I
want to flow via MTOM.


>
> 2. You can define a service method parameter as binary element in your WSDL
> using the schema type="xsd:base64Binary". Having an element with the type
> "xsd:base64Binary" is enough for the Axis2 code generators to identify
> possible MTOM attachments, and to generate code accordingly.


OK, I need to remind myself what the databinding framework does under covers
in this situation.

>
>
> 3. As per JAXB 2.0 specs, java classes like java.awt.Image,
> javax.activation.DataHandler and javax.xml.transform.Source can be mapped to
> ""xsd:base64Binary".


Do you happen to know if our WSDLgen works correctly in this respect. I
don't remember if there are tests for this sort of thing so I'll have to go
and look.

>
>
> Hope the above points answers some of the questions raised in this thread
> earlier.
>
> Also from Tuscany point of view using OMElement as the binary datatype for
> attachments had an issue (TUSCANY-2664) earlier. Similarly I see the same
> issue while using java.awt.Image and javax.xml.transform.Source as datatype
> for attachments for binding.ws. I have also updated TUSCANY-2664 with this
> information.
>
> [1] http://ws.apache.org/axis2/1_4/mtom-guide.html<http://ws.apache.org/axis2/1_0/mtom-guide.html>


Thanks for the update Ram. We need to run these to ground.

...snip