Re: Protocol Bindings

Stuart Williams writes:

>> One of the largest areas for differences in 
>> behaviours between underlying protocols is 
>> the message exchange patterns that each 
>> naturally supports.

+1

>> 1) The interface provides a framework such 
>> that a binding can declare what
>> functionality it supports.
>> [...]
>> 2) The alternate view is that bindings raise 
>> (or reduce) the native functionality of an 
>> underlying protocol to meet some common 
>> level of functionality across all supported 
>> protocols.

+1 on this analysis:  exactly the right way to look at it I think.

+0.9 on the conclusions:   Basically, I agree with (1), but I would put it 
this way:

The message patterns supported over a given (binding to) a transport 
should not be limited to those obviously inherent in the transport.  If I 
want to write bindings that do request/response over UDP, so be it (though 
I'm not really arguing for SOAP over UDP).  On the other hand, it should 
not be the case that every binding/transport combination needs to support 
every wild message pattern that someone, somewhere needs.   A TIBCO bus 
binding might do multicast.  That doesn't necessarily mean that any SMTP 
binding or HTTP binding must support multicast too. 

So in the end, I think (a) messag patterns should be named, and should 
each have precise specifications (b) our spec should provide one way and 
request response, with users able to create names and specifications for 
their own patterns such as conversation, multicast, etc.  (c) bindings 
should indeed advertise (whether dynamically at runtime, statically in 
their specifications, or through some other means) the set of named 
message patterns they support, and should be free to choose to support 
patterns that do or don't  naturally reflect and exploit the underlying 
characteristics of the transport vs. augmenting it (multicast over SMTP).  
Of course, we as a community will do well to focus on a small set of 
message patterns, such as request response, that are designed to 
comfortably expose and leverage the natural capabilities of important 
protocols/transports such as HTTP, BEEP., etc.  One-way, request-response, 
perhaps conversation, perhaps muticast,  maybe windowed streams someday, 
seem like likely early candidates for someone to tackle.   Also, I think 
that flow of fault messages needs to be precisely defined for each 
pattern.  If two out of four multicast receivers fault,  what does the 
originator get?  The binding should tell you.

I expect that applications will negotiate for bindings that support the 
patterns and other semantics they need, while maintaining some isolation 
from underlying details.  My application may want to write the same code 
for request/response, regardless of whether over HTTP or SMTP.

I'm off on vacation for two weeks, so won't be reading or responding to 
futher traffic until I'm back.  Best of luck on moving this all ahead. 

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Thursday, 5 July 2001 13:11:12 UTC