Re: Signaling MEPs

Marc Hadley writes:

> I *think* we both agree that...

Indeed we do :-).

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

I think not.  I think that multiple MEPs per binding should be allowed but 
not common.  In the one case we've seen a need for them so far, there was 
a natural way to signal the choice (the HTTP method.)  I suspect we 
shouldn't standardize anything more until the need arises.  I could be 
convinced otherwise, just trying to keep it simple.

What seems more urgent, but also probably not worth standardizing until we 
better know what we're doing, is to signal in bindings such as HTTP the 
particular version of the binding supported.  We already have the original 
vs. MTOM-aware versions, and soon we'll have the optional response 
versions.  We are limping by signalling the former with the media-type, 
and for now I guess we'll live with the fact that early implementations of 
the HTTP binding may grumble when receiving a 202 and no envelope.  I 
don't think we're at the point where some generalized signalling mechanism 
or HTTP-binding-level mustUnderstand is needed, but we don't seem to have 
a robust way of evolving the binding over time.  With luck, we won't need 
to.  Anyway, it's an issue to keep in mind. 

Thanks!

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








Marc Hadley <Marc.Hadley@Sun.COM>
Sent by: Marc.Hadley@Sun.COM
03/29/2006 11:16 AM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     Mark Baker <distobj@acm.org>, "Xml-Dist-App@W3. Org" 
<xml-dist-app@w3.org>
        Subject:        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 Tuesday, 4 April 2006 20:50:51 UTC