Re: Stranger in a Strange Land

+1, exactly, there is much more to it than an envelope, 
processing model, header blocks, mustUnderstand, binding 
framework, faults, etc.

Jean-Jacques.

Christopher B Ferris wrote:
> Well, in a sense, these things *are* SOAP. SOAP
> defines an extensibility model that allows for
> metadata to be attached to the message as header
> blocks, it then defines a processing model for
> the message that specifies the rules by which a
> SOAP processor must abide (e.g. that it operates
> in one or more defined roles. It provides the
> mustUnderstand attribute that a SOAP node uses
> to communicate (in a standard way) whether the
> metadata carried in a header must be understood
> and processed by a receiving node operating in
> the role that is either implied or specified
> (using the role attribute (actor in SOAP1.1))
> This allows the extensibility model to be
> consistently applied, which is an important
> point to achieving extensibility.
> 
> The binding framework comes into play in the
> process of serializing the XML Infoset of the
> SOAP message and binding it to the underlying
> transport/transfer layer. It provides for some
> of the features to be bound either at the SOAP
> level (as SOAP header blocks that must be
> processed by the SOAP processor layer of
> software) or at the protocol level, to take
> direct advantage of the protocol implementation
> of the feature, etc. An example here might be
> the use of headers such as those specified by
> WS-ReliableMessaging to effect a SOAP level
> implementation, or direct use of WebSphere MQ to
> effect the same level of quality of service
> required, etc.
> 
> I could go deeper, but the fact remains that
> SOAP is much more than *just* an envelope.
> 
> I believe that the SOAP1.2 specifications and
> the SOAP1.2 primer are the best sources of
> understanding of the SOAP protocol. While I
> don't imagine or expect that the casual
> developer need necessarily read and completely
> comprehend these specs, I do think that those of
> us who are crafting the WSA *should* do so.
> 
> Whether we like it or not, SOAP and WSDL are the
> technologies that the W3C has chosen to noodle
> on in our sister WGs. IMO, the WSA should, nay
> MUST, recognize this fact and IMO focus its
> attentions on defining an architecture that has
> these technologies in its realization. Our job
> should be to ensure that the specifications
> being developed in our sister WGs, and to the
> extent that we can influence, those being
> developed elsewhere, satisfy the constraints
> that we define so that the properties we seek
> are realized. Additionally, we should be seeking
> to understand and call out areas of conflict,
> gap or whatever between these other
> specifications so that they can work towards
> resolving those issues.
> 
> Cheers,
> 
> Christopher Ferris

Received on Thursday, 17 April 2003 11:31:59 UTC