Re: Signaling MEPs

I'm not sure if I understand you position entirely but I *think* we  
both agree that to communicate successfully the endpoints need to:

(i) use either the same binding or compatible bindings
(ii) use either the same MEP or compatible MEPs

As you say, the binding and MEP can be determined entirely statically  
or more or less dynamically. I can't really tell from your reply  
below whether you think we need a standard mechanism for signaling  
the MEP and/or binding or not ?

Thanks,
Marc.

On Mar 27, 2006, at 9:21 PM, noah_mendelsohn@us.ibm.com wrote:

>
> 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
> --------------------------------------
>
>
>
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

Received on Wednesday, 29 March 2006 16:16:46 UTC