RE: Protocol Bindings

> >> There should be no additional
> >> semantics defined by the binding because the places where we add 
> >> semantics is either as SOAP extensions or as underlying protocols.
> >
> >That may be a point of difference.
> 
> But what should the mechanisms be for defining semantics as part of the
> binding? Unless we define a separate processing model for the binding, a
> separate mechanism for identifying features, a separate mechanism for
> defining faults, etc. then there is no framework within which I can
> define such semantics.

I think I agree - but let me try to explain where I'm coming from.

Thinking in terms of a single hop between neighbouring SOAP processors on a
message path we potentially have variety of underlying protocols with
different properties and message delivery semantics. In some cases we will
want to augment the natural capabilities of an underlying protocol, for
example, to impose message ordering on the message stream so that messages
are delivered to the receiving SOAP processor in the order in which they
were sent (eg. UDP and SMTP may re-order messages). Clearly, a way to do
this is to add elements to the message header that, say, add a sequence
count to the message and employ some algorithm at the receiver to re-order
mis-sequenced messages. Such header blocks might carry an actor attribute of
".../next" and might be mark mustUnderstand

Now, *a* way of modeling this process is to view it as like a 'nestable
binding'. Conceptually, as the outbound message passes through this binding
it inserts a sequence count element into the message header. On the inbound
side (conceputally) the message passes through the peer 'nested binding'
component which checks the element (if present) and removes it, applies
whatever algorithmics necessary to re-order the message (eg. if there seems
to be a gap, buffer and wait a reasonable period for preceding messages to
arrive) and then deliver it upward into the core SOAP processor.

Such a 'nested binding' alters the message delivery semantics perceived by
the SOAP core.

I think that you might be inclined to say... well that's not a binding at
all really... its some modular functionality added to SOAP. Indeed a slight
variation on this is that a SOAP extension might define a re-sequencing
module and which defines some resequencing actor name to use instead of
".../next" and which does something functionally very similar. Of course, if
message order is important to the application entity using SOAP, then
resequencing needs to get that sorted out ahead of processing the other
substantive parts of the message.

> What I am proposing is to say the following: Look, in SOAP we define a
> protocol framework that is especially targeted the XML community. It
> defines a processing model, an extensibility model and all that good
> stuff needed for building distributed applications. 

Fine... although I would note that the language is now of a framework.

> However, we all know
> that SOAP and XML are not alone in the world - there are plenty of
> existing protocols and infrastructure around. In order to allow SOAP
> based applications to take advantage of such services and features, we
> allow SOAP to be bound to various other protocols in as straightforward
> a way as possible.

So how do we expose the richness of these underlying protocols os that SOAP
can use them if our pivotal abstraction is that of the transmission of
unsequenced and independent messages?

> This gives us what we want in that it allows SOAP applications to use a
> variety of underlying protocols without us having to define a new
> complex "binding language" that can support extensibility etc.
> 
> >> Semantics defined by the binding is not defined as part of underlying 
> >> protocols and not defined within the extensibility mechanism of SOAP.
> 
> >> In other words we have no good way to talk about it in terms of 
> >> processing model, extensibility model etc.
> 
> Henrik
> 

Stuart

Received on Monday, 9 July 2001 11:03:46 UTC