Re: Signaling MEPs

Marc Hadley writes:

> Just for clarification, is it your position that each 
> underlying protocol should only have one binding 

No.  I've always assumed that in principle lots of bindings could exploit 
the same transports, somewhat as multiple different filesystems can be 
implemented on the same model hard drives.  In both cases, there are 
downsides to a having a proliferation of conventions for using the 
underlying facility, but it's certainly to be allowed.  Also, in both 
cases, one binding might be written to partially interoperate with 
another.  For example, HTTP binding #2 might either recognize when it's 
talking to binding #1 and do something useful, or the two might otherwise 
share some capabilities.  I think one can view the MTOM-aware and 
non-MTOM-aware flavors of the HTTP binding as being in this space.

> (which might support multiple MEPs 

I think any binding can in principle support more than one MEP.

> but that would be an exception) ?

Yes, I think it's somewhat tricky and to be avoided when there's no good 
need.  I think support for multiple MEPs will come up a lot with protocols 
that are themselves flexible.  My guess is that BEEP could be used in a 
variety of idioms, for example.

> I ask because if there are multiple bindings per underlying 
> protocol then rather than signal the MEP in use one might 
> instead need to to signal the binding in use. 

I think this is really a matter of how the specifications are organized. I 
view MEPs as somewhat like Java interfaces.  They are ways of documenting 
situations in which multiple bindings have shared capabilities that are so 
similar that applications may be able to use them compatibly.  So, if two 
bindings support request/response, and one of them also supports one-way, 
then applications that need r/r can use both nearly interchangeably, and 
applications that need one-way can use only the latter.  By contrast, a 
binding is a unit of specification for a body of deployed code.  If I tell 
you "I'm supporting HTTP binding XYZ, then that's committing me not just 
to whatever MEPs, but to specific bits on the wire over HTTP, and to 
conforming to the entire specification for the binding (except insofar as 
the binding itself provides for optionality).

So, I think bindings and MEPs are setting off to solve different problems. 
 Saying in a binding spec:  "this binding mandatorily supports MEP1 and 
MEP2" means that you can't claim to conform to the binding unless you do 
both.  That's important, because someone who specifies a requirement for 
the binding can count on them both being there, and can count on the right 
bits being on the wire.

> I suspect the mechanism for signaling either would be similar.

As I say, I think they are aiming to solve different problems, with MEPs 
being essentially interface abstractions on the bindings.  I think I 
prefer to view it as:  the two endpoints need to agree on a binding (or on 
interoperable use of two different bindings) before they can even start to 
understand the bits they are exchanging.  In some cases, such agreement 
will be obtained completely statically.  For example, we may just know 
that over XMPP we use some particular binding, and then we don't check 
dynamically.  Conversely, multiple bindings can be written so that their 
initial exchanges are distinguishable, in which case the agreement on 
bindings can be negotiated dynamically.

My view is that once you have agreed on the binding, the binding spec 
tells you whether there is a choice of MEP, and if so how it is conveyed. 
Insofar as the step above (agreeing on binding) and this step (agreeing on 
MEP) may both be dynamic, then they both depend on information transferred 
with the messages.  In that sense I agree that they are similar.

I hope this makes sense.  There may be other useful or coherent ways of 
slicing the story, but the above is what I've assumed since we first wrote 
the SOAP Rec.  Thanks!

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Tuesday, 28 March 2006 02:21:39 UTC