Re: [docsoapxdk-developers] Problems with PASWA ... and an alternative

Treating all parts uniformly no matter what the location of the part is the way to go. Location is just a performance/practical detail that should make little difference to application logic. For example, performance might be better if you do not put many large parts in the header/body and instead make them attachments. Also for example, practically, it is not reasonable to encode binary data in some way to carry it in the SOAP body or header instead of as an attchment.  DocSOAP solves another issue you did not mention. If references in one part to another is by part names, these are logical references and these references still hold when all the parts have been extracted from the message and stored seperately in a database. This is an important point. However, obviously, we cannot force applications to do this because we have no idea where and how they got the XML parts in the first place.   regardsjay kasi. 

"Burdett, David" <david.burdett@commerceone.com> wrote:I've been following the recent thread reviewing the Proposed Infoset Addendum to SOAP Messages with interest particularly the differences between:a) Treating attachments as if they were part of the XML Infoset (which PASWA proposes), vsb) Treating attachments as first class citizens in their own right. I can see benefits in both approaches in that efficiently putting a large "blob" in an attachment in a way that is transparent to the application can make the application processing simpler. Alternatively, the idea of an attachment where the application is aware that is an attachment as a separate item is equally valid, for example an application that is processing an order that just happens to have terms and conditions attached to it as a PDF. I also have one concern (and also a question) over the way PASWA works as described below ... USING CID: IN XBINC:INCLUDEThere's a catch 22 here as:1. You can only create the XML wh!
 en you know the cid values to put in the XML2. You only know the cid values when you marshall XML into the SOAP Message, but 3. You can't marshall the SOAP message until you have created the XML.  I know that you can get around this problem IF the generation of the XML and the SOAP Message is done by the same software at the same time. Although this will often be both possible and desirable it is, I think, something that will often not be possible to do. Here's some use cases that explain why. They all assume an XML document that uses an xbinc:include element that references an attachment, e.g an XML order that references a PDF document as described above:1. The order and its attachment, is generated by an ERP system and passed to a SOAP processor for forwarding to the supplier. The SOAP processor puts the XML document into the SOAP body The problem is the ERP system does not know anything about the SOAP Message and therefore can't set the href in the xbinc:include. So, the!
  SOAP processor must alter the XML to include it instead. This means t
hat the SOAP processor can no longer be a general purpose processor as it must be payload aware.2. This is a variation of 1 where the ERP system digitally signs the XML it is generating. This means that the SOAP processor can't even alter the original XML without breaking the signature. The only solution is for the ERP system to tell the SOAP Processor the cid values to use somehow. However the ERP system may not have the functionality that allows this.3. The order and its attachments are sent to its destination. The destination then archives the payload and attachments discarding the original SOAP envelope. Some time later the payload is removed from the archive and forwarded in another SOAP message together with the attachments. The problem is how does the SOAP processor that is doing the forwarding know what to use for the content ids in the MIME message. The point is that I don't think that a tight coupling between the XML and the SOAP message will often work or be pract!
 ical. HOW DOES PASWA WORK WITH WSDLThis is really more of a question than a concern in that PASWA ignores the idea of Message Parts that is one of the fundamental concepts behind WSDL. What is not clear to me is how you would decide to use separate message parts rather than the transparent message parts that PASWA seems to suggest. AN ALTERNATIVE APROACH?Finally, Commerce One, has developed a soap header spec and an open source, royalty free implementation (called DocSOAP) that uses a Manifest element that is an extension of the ideas on a Manifest from ebXML Messaging. It covers much (but not all) of the same ground covered by PASWA whilst solving (we think) the problems with the use of content id described above as well as tying it in more closely to WSDL. The key difference between the SOAP Manifest and PASWA is that the XML document references the WSDL partname for an attachment and then the Manifest element in the SOAP header ties the partname to the content id of the !
 actual part which can be in the SOAP Body, in an attachment or even ex
ternally to the message on the web. This means that the content ids can be changed at any time and only the manifest element needs to change. Anyway, the Manifest spec is available at:http://www.commerceone.com/developers/docs/ws-soapmanifestv1_0.pdf ... and the open source, royalty free implementation (which also includes a full featured XML parser and Bean generator) is available at:http://www.commerceone.com/developers/docsoapxdk/ Thoughts and comments welcome. David Burdett Director, Product Management, Web Services
Commerce One
4440 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com