Hi Simon, My comments inline.....
On Thu, Jan 29, 2009 at 6:29 PM, Simon Laws <[email protected]>wrote: > Hi Ram > > On Thu, Jan 29, 2009 at 11:26 AM, Ramkumar R <[email protected]>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
