tried to send you the reference to one very usable site but got message:
Sorry, your post contained a reference to a company or website that publishes real test questions - a practice we do not approve of here at JavaRanch. We have banned all discussion of the websites which do this, because even the knowledge of the names of such websites seems to encourage others to use the website to cheat. If you were attempting to discuss this website for any other reason, we apologize for the inconvenience.
If you need it, give me email, I will send you. As for me, this resource is too nice and that is the reason it is banned.
This document is the work of the W3C XML Protocol Working Group (WG). The Attachment Feature document has been superceded by the SOAP Message Transmission Optimization Mechanism document which describes attachment related features along with some implementation details. The XMLP WG does not intend to do any further work on the Attachment Feature document.
Basically forget that the SOAP 1.2 Attachment Feature ever existed - MTOM is the Attachment Specification of choice for SOAP 1.2 (which isn't that widely used).
but I think that this is somewhat misleading as this probably means that a SwA API will let you get at the attachment content but that you still have to do all the MTOM/XOP related processing yourself to restore the original content.
Joined: Jan 13, 2009
Thanks, Peer. It looks like MTOM it is then. This is good because Glassfish (which I am using) supports MTOM. Now I just have to get an example working.
Your help is greatly appreciated!
Joined: Aug 19, 2005
Ravi Danum wrote:It looks like MTOM it is then.
Just as long as your prospective consumers support it. Just because your implementation environment supports it doesn't automatically imply that your consumers will be able to use it. While MTOM is an open standard, use of MTOM in your web service contract does impose a certain amount of (negative) contract-to-technology coupling on your consumer because MTOM isn't universally supported by all SOAP client stacks (none of the attachment technologies are). The same is true for SOAP 1.2 - SOAP 1.1 seems to be the one that is predominantly used and some development environments don't seem to be in any hurry to move to the "next generation" of SOAP (possibly because they are taking the "wait-and-see" approach to determine whether SOAP adoption has peaked).
Joined: Jan 13, 2009
Thanks, Peer. This is a good point to keep in mind.