- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Tue, 4 Feb 2003 19:19:48 -0000
- To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>, David Orchard <dorchard@bea.com>
- Cc: "'Jean-Jacques Moreau'" <jean-jacques.moreau@crf.canon.fr>, xml-dist-app@w3.org
<delurk> I resisted the strong temptation to post earlier on this thread but I have been overcome by weakness :-) I had been going to take a very layerist stance about PDUs, SDUs and PCI (protocol control information - or headers in the venacular) and then say something very similar to Noah's second paragraph below - ie. the message is all the information (state) transferred between SOAP nodes (above the binding layer). FWIW I think your two proposals (Noah and Gudge)are very similar. Both 'hypothesis' an abstraction that carries all the message information (Headers, Body, Attachments, feature properties....) and (I think) presume that that is the information that is transferred between nodes by a binding - granted, some of the information is in some sense control information that may affect the operation of some feature within the binding and may not infact be transferred (or deduced at the receiving end). The difference between the proposals, as I preceive it from Noah's description, is that Gudge's proposal hypothesises a concrete XML Infoset (and presumable a corresponding XML serialisation) for representing that abstraction - presumably with an accompanying XMLSchema and narrative for describing the semantics of that XML SOAP Message meta language. That feels like a large piece of work, particularly for a tool whose purpose (I assume) would be to aid in the precise specification of the behaviour SOAP modules (if that is what they are still called) and bindings. It would also be possible to structure and implementation around such a representation and I would be intrigued to know how well it performed. I think Gudge's idea is interesting... but I don't know if it is necessary for the success of the venture. It would enable very precise definition of the transformations that modules and bindings perform on the abstraction of a message... Best regards Stuart </delurk> > -----Original Message----- > From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] > Sent: Tuesday, February 04, 2003 4:13 PM > To: David Orchard > Cc: 'Jean-Jacques Moreau'; xml-dist-app@w3.org > Subject: RE: What is a SOAP Message > > > > No, I think this still misses the distinction. Specifically, the data > that moves from point to point in SOAP is, in general, more than what is > within the scope of the application/soap+xml content type. It includes a > potentially unbounded set of feature-specific data that is represented > outside of that media type. One simple example is the so-called Web > Method (GET/PUT/POST), which the HTTP binding represents in the obvious > http-specific manner, but other bindings (MQSeries, perhaps?) will > represent using some other transport-specific means. > > I find the term "SOAP Message" to be about right for the collection of > state >that is modelled by SOAP above the binding-specific layer< and that > moves from one node to another per the SOAP architecture. I think that is > distinct from the envelope, which is indeed the part of the (transmission > unit formerly known as message) that is indeed in media type application/soap+xml. > > Using my terminology, my impression of the options wrt the issue that > Gudge has raised can be explained as: > > * Traditional (Noah): The "message" consists of all the SOAP-modeled > data, including not just the envelope but potentially other properties > defined by features. One such feature is the attachment feature, which > defines properties for the parts [1]. The representation of such > properties is at the discretion of the feature and the protocol binding. > For example, DIME provides a concrete implementation of the attachment > feature. In general, parts (other than the envelope itself) are modeled > as being external to the envelope. > > * Infoset-based (Gudge): There are two infosets for each message related > by a binding-specific transform (not necessarily an XSLT transform.) By > definition, one of these includes in its XML Infoset some reprsentation of > every piece of data that would have been in the "message", as I have > defined it above. For example, a part which would otherwise be binary > might be modeled in characters using a schema type of hexBinary. This > first infoset provides unity for the processing model, but is often too > verbose for efficient processing in memory or on the wire. The > responsibility of the binding is to transmit this infoset, but it is given > hints about problematic content such as that which is of hexBinary type. > The binding can use such hints to provide optimized representations on the > wire (carrying the binary as true binary). A transform can be used to > create a second SOAP envelope which has the binary information replaced > with pointers to the protocol-specific serialization (this is the second > infoset listed above). The binding can, if desired, transmit this second > infoset in the same manner as a traditional SOAP implementation would > transmit the envelope. Presumably, not just the wire representation but > also the in-memory representations of large binary objects can be > optimized. > > Gudge: is this explanation correct? I still have many doubts about this > proposal, but I think it's always healthy if one person can explain > another's proposal. Thanks. > > [1] http://www.w3.org/TR/2002/WD-soap12-af-20020814/ > > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------ > > > > > > > > "David Orchard" <dorchard@bea.com> > 02/04/2003 10:18 AM > > > To: "'Jean-Jacques Moreau'" > <jean-jacques.moreau@crf.canon.fr>, > <noah_mendelsohn@us.ibm.com> > cc: <xml-dist-app@w3.org> > Subject: RE: What is a SOAP Message > > > Maybe a good word for the bag of bits that some are calling a message > would > be better served being called a representation? This would > show a clean > relationship between the web and web services at the > messaging level. The > TAG's work [1] isn't very far along, but it shows a start. > > And if we don't a call a "message" a representation, then we probably > ought > to provide some explanation on how a message and a > representation relate. > It might be as simple as "A SOAP Message is defined as a > representation > that > contains a SOAP envelope, binding specific additional data, > and has the > application/soap+xml content type". > > Cheers, > Dave > > http://www.w3.org/TR/webarch/#representations > > > -----Original Message----- > > From: xml-dist-app-request@w3.org > > [mailto:xml-dist-app-request@w3.org]On > > Behalf Of Jean-Jacques Moreau > > Sent: Tuesday, February 04, 2003 12:30 AM > > To: noah_mendelsohn@us.ibm.com > > Cc: xml-dist-app@w3.org > > Subject: Re: What is a SOAP Message > > > > > > > > I also make the same distinction between messages and envelopes. > > I have seen the confusion made in other groups as well. So, > > > > +1 to your suggested clarification. > > > > Jean-Jacques. > > > > noah_mendelsohn@us.ibm.com wrote: > > > During today's AFTF telcon we got into a discussion as to > > exactly what a > > > SOAP Message is. Gudge pointed out that in several places > > in part 1 it > > > says or strongly implies that a SOAP Message >is< an XML > > Envelope Infoset. > > > I had always assumed we were clear that the "term message" > > refers not just > > > to the envelope, but to a set of information which includes > > at minimum the > > > envelope, but often other information as well (e.g., the > destination > > > address, WebMethod, and Action tend to be sent out of band > > in SOAP http). > > > [...] > > > > > > I think it's useful and appropriate to separate the term > > "message" from > > > "envelope". [...] I think we should consider clarifying our > > terminology. > > > > > >
Received on Tuesday, 4 February 2003 14:20:09 UTC