Re: Signaling MEPs

I've been mulling this distinction over off and on for a while, and I
think the real object of interest is a binding of a MEP to a protocol. 
How these are distributed across SOAP bindings seems less important.

For example, the current HTTP binding defines two such beasts (r-r to
HTTP, SOAP response to HTTP).  If someone happened to define a separate
binding that defined only f-a-f over HTTP -- something I agree is not a
good idea -- we'd need to know whether that binding was in effect, say
by looking at a WSDL.  If the binding isn't in effect, we don't have to
worry about that MEP on the wire, but if we don't know whether it is,
then we potentially do have to look out.

Suppose on the other hand we amended the current binding (or supplanted
it) so that SOAP/HTTP supported 3 MEPs (r-r, response and f-a-f). 
Again, I don't think this would be a good idea, but if it happened you
still have your choice of just saying "this endpoint uses HTTP" in the
description and trying to figure out what's going on on the wire, or
saying in your description "this endpoint uses HTTP and you can only use
r-r or response" (which is what we currently say more or less by default).

To take a less moot example, XMPP could be handled one of two ways,
either with a single SOAP/XMPP binding that defines r-r for <iq/> and
f-a-f for <message/>, or by defining two bindings, one for each case. 
Which way makes sense is a matter of whatever makes the description
easier.  There are still two cases, namely "static binding" where you
can tell in advance what will happen on the wire, and "dynamic binding",
where you have to decide when the messages are actually sent.

Supporting the dynamic case is probably useful for two reasons: First it
allows for things to work even without a complete static description,
and second, it can help detect errors when a static description doesn't
match what's going on on the wire.  Whether to favor tight checking or
flexibility seems like a tradeoff to be made by implementors and
deployers, not a decision for us to make once and for all.  Only
defining MEPs that can be distinguished on the wire seems like best
practice for supporting this kind of tradeoff.

Marc Hadley wrote:

> Just for clarification, is it your position that each underlying 
> protocol should only have one binding (which might support multiple 
> MEPs but that would be an exception) ?
>
> 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 suspect the mechanism for signaling 
> either would be similar.
>
> Marc.
>
> On Mar 15, 2006, at 6:05 PM, noah_mendelsohn@us.ibm.com wrote:
>
>>
>> As I said at the F2F, my view is that supporting multiple MEPs per 
>> binding
>> should be allowed, but should be viewed as somewhat exceptional.   In
>> the
>> particular case of HTTP, I think there was value in the tradeoff we
>> adopted primarily because:
>>
>> * Separating Request/Response from Response-only has value because 
>> we can
>> easily imagine other bindings that might want to support one  without
>> the
>> other.  By separating the two, we make it possible to indicate that
>> request/response applications may work quite compatibly over the  two or
>> more bindings, while GET applications might work over only HTTP 
>> (though,
>> of course, there could be other bindings that would support GET too).
>>
>> * There was a natural and appropriate signaling mechanism in HTTP.
>>
>> So, I think we should allow other bindings to support multiple MEPs 
>> when
>> it's a natural thing to do.  I don't think it should be encouraged as
>> common practice, and in particular I don't think we should be  trying to
>> invent general mechanisms for signaling the MEP to use.
>>
>> Right now, I'm not aware of a need to support additional bindings  in
>> HTTP,
>> since I believe that the one-way FAF MEP we are contemplating would  not
>> appropriately be supported on HTTP in any case.
>>
>> --------------------------------------
>> Noah Mendelsohn
>> IBM Corporation
>> One Rogers Street
>> Cambridge, MA 02142
>> 1-617-693-4036
>> --------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>> Marc Hadley <Marc.Hadley@Sun.COM>
>> Sent by: xml-dist-app-request@w3.org
>> 03/15/2006 02:57 PM
>>
>>         To:     Mark Baker <distobj@acm.org>
>>         cc:     "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>, (bcc: 
>> Noah
>> Mendelsohn/Cambridge/IBM)
>>         Subject:        Re: Signaling MEPs
>>
>>
>> On Mar 15, 2006, at 1:00 PM, Mark Baker wrote:
>>
>>>
>>> I think either of those options are problematic because each would be
>>> ignored when encountered by existing agents.
>>>
>> True enough, whatever we did would only be advisory since there's no
>> mU-type functionality in either of the mechanisms I suggested.
>>
>> Doug Davis contacted me privately and suggested that we could also
>> consider doing something inside the envelope which is an option I
>> didn't mention. One thing that springs to mind is use of a
>> wsa:ReplyTo with a "none" [address].
>>
>>> In general, deploying MEPs which aren't compatible extensions of
>>> existing MEPs is problematic because of this extensibility problem.
>>> Had SOAP 1.2 used RFC 2774 as SOAP 1.1 did, this wouldn't be as  big an
>>> issue.
>>>
>> Agreed, though for the case of one-way there is some evidence that
>> implementations are already doing the right thing based on WSDL
>> information and the WS-I basic profile so its possible that we'd be
>> merely formalizing something that is already happening rather than
>> adding a new capability.
>>
>>> And regarding the oneway example, can I ask why it's necessary to
>>> indicate the oneway-ness of an interaction in the request message?
>>> Any other motivating examples for this practice?
>>>
>> That's not entirely clear to me either (I just took the action to
>> start the conversation). One thing mentioned was to allow a receiver
>> to distinguish between request-response, request-optional-response
>> and one-way to enable it to follow the MEP contract accordingly.
>>
>> Marc.
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> Business Alliances, CTO Office, Sun Microsystems.
>>
>>
>>
>>
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>
>

Received on Thursday, 16 March 2006 17:38:59 UTC