SwA uses "cid" references with "Href" attributes in elements to refer to mime parts. MTOM/XOP does the same... For an SwA only endpoint <xop:include.../> element is just an element with a "href" attribute which contains an "cid" reference to a mime part.. So a SwA endpoint will treat it as a normal SwA message....
yes.. I understand... There can be much several complication when doing this.. Like the "type" parameter you mentioned. But I don't think any SwA endpoint is programmed to reject a message with that "type" parameter.... Since this "application/xop+xml" was introduced long after the SwA implementations came to existance..... Lets hope for the Best... Anyway MTOM/XOP is the future for sending binary Attachments with SOAP... > understand how its accomplished unless there is some negotiation going on > between client and server. For instance, how can a SwA server > implementation (such as Axis 1.2) understand what to do with XOP elements > embedded in the MIME attachments unless a client like Axis2 .9 is smart > enough to realize that the server implementation doesn't support MTOM/XOP > and changes the wire format to SwA internally so that the SwA server > implementation can understand. People have to wait for some time till Axis2 gets it's ws-policy implementation up, to expect Axis2 to be this Smart ;-) ~Thilina > > Thanks for any additional insight. > > ________________________________ > From: Thilina Gunarathne [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 26, 2005 9:20 PM > To: [email protected] > Subject: Re: [Axis2] Fwd: mtom vs. swa > > > > What we meant by wire format is the packaging and arrangement of MIME parts > in the message.. SwA uses Content-ID's & Elements with "href" attributes to > identify MIME parts (Of course SwA supports Content-Location which is not > mentioned in MTOM/XOP)... MTOM does the same (With addition of XOP element > )... > > I will not accept the statement about Axis 1.2 would fails unless somebody > proves it using Axis2... Couple of guys tested Axis2 .9 with Axis1.2 and I > heard them saying it worked...... > > ~Thilina > > On 7/27/05, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > > Forwarding with Axis2 Prefix. > > > > > > ---------- Forwarded message ---------- > > From: Tony Dean < [EMAIL PROTECTED]> > > Date: Jul 27, 2005 4:25 AM > > Subject: mtom vs. swa > > To: [email protected] > > > > In the Axis2 documentation, I read a blurp about the definition of MTOM. > I will include it here: > > > > MTOM (SOAP Message Transmission Optimization Mechanism) < > http://www.w3.org/TR/2004/PR-soap12-mtom-20041116/> is a > elegent solution for the above problems created by merging the above two > techniques. MTOM is actually a "by reference" method. Wire format of a MTOM > optimised message is same as the Soap with Attachments message , which also > makes it backward compatible with SwA endpoints. Most notable feature of > MTOM is the use of XOP:Include element which is declared in XML Binary > Optimized Packaging (XOP) < > http://www.w3.org/TR/2004/PR-xop10-20041116/> > specification to refer to the binary attachments of the message.With the use > of this exclusive element the attached binary content logically become > inline(by value) with the SOAP document even though actually it is attached > seperately. This merges the two realms by making it possible to work only > with one data model. With this the it becomes trivial to idetify the data by > looking at XML making reliance on DTDs obsolute. With this > > the technologies which works based XML component of the data can work with > one data model. > > > > I do not understand how you can say "Wire format of a MTOM optimised > message is same as the Soap with Attachments message , which also makes it > backward compatible with SwA endpoints." They are not the same as far as I > can tell. An Indigo (WSE 3.0) client sending MTOM/XOP mime attachment > content would cause an Axis 1.2 server to choke because it would not > understand type="application/xop+xml". It would only be able to process SwA > attachment content. Right? I'm I missing something here. > > > > Thanks in advance for clearing this statement up. > > > > -Confused. > > > > Tony Dean > > SAS Institute Inc. > > 919.531.6704 > > [EMAIL PROTECTED] > > > > SAS... The Power to Know > > http://www.sas.com > > > > > > > > -- > > "May the SourcE be with u" > > http://www.bloglines.com/blog/thilina > > > > -- > "May the SourcE be with u" > http://www.bloglines.com/blog/thilina -- "May the SourcE be with u" http://www.bloglines.com/blog/thilina
