Re: multiple MEPs per binding

Chris:  I agree with a lot of what you've written, though not quite all. 
Points of agreement:

* mustUnderstand processing may result in a fault before you are in a 
position to get any reliable information from the headers.  Though you 
didn't quite say it this way, I think we are both agreeing that therefore 
the headers cannot in general be used to select between MEPs, at least not 
between MEPs that would affect the routing of such faults.  I think this 
is an important point that's easily forgotten, and the reminder was very 
helpful to me during the call (and perhaps to others too).

* Always, or almost always, if a binding supports more than one MEP, then 
the one in use will have to be discoverable from information in the 
non-envelope part of the transmission.  (There might be exceptions in the 
case of two MEPs that were so similar that the distinction was only 
pertinent after processing was done, e.g. if they happened to share rules 
for request fault routing.)

* While we don't quite agree that supporting multiple MEPs is in all cases 
impractical, I agreed in the meeting that it's only occasionally workable. 
 In particular, I agree that the proposed one-way FAF MEP would not 
coexist with the others already supported by HTTP, even if it could be 
well implemented on HTTP in principle (I believe it can't anyway, so 
coexistence isn't the first problem with it.)

Chris Ferris wrote:

> In the case of the SOAP Response MEP, the fact that you use a 
> different HTTP method (GET), and you serialize the request such that
> there is no SOAP envelope infoset in the entity body I think makes it 
> a different binding. 

Here's where I think I have a significant disagreement.  My understanding, 
and certainly my intention when we voted to create the formal concept of a 
"binding", is that it is ultimately a specification and a point of 
conformance.  While it would be coherent to write two different HTTP 
bindings, one for R-O-R and one for Response-only, that's not what we did. 
 Accordingly, IMO, a conforming implementation of our binding MUST support 
both, and therefore must support both GET and POST.  Now, in practice, 
I've always taken the position that people shouldn't have to write code 
that will never be invoked.  If you really know that you're deploying 
resources that will only be accessible in one style or the other, or if 
you're writing a client where you're really sure that none of the 
endpoints you'd access would support GET anyway, then there's a case to be 
made for skipping the implementation of the code you'd never use.  That 
said, if a given piece of code is advertised as supporting the current 
HTTP SOAP 1.2 binding then I believe it should support both.  As 
importantly, if another specification were to mandate use of our HTTP 
binding, it would be reasonable for that specification to presume the 
availability of both MEPs and both WebMethods.  That's a useful 
characteristic of the specification, albeit one that most current 
implementations have made difficult to exploit :-(.

> In the case where one defines a binding and says that it supports a 
> given MEP, I don't believe that you can simply overlay another MEP 
> if it requires that the rules for the binding be changed to accomodate 
it. 

I agree that this is only occasionally possible.  In general, one can't 
compose arbitrary MEPs in the same binding.  I do think one can get value 
out of supporting more than one MEP in the more rare occasions where you 
can indeed support the two correctly.  Also, I think you only get value 
out of doing this in cases where you expect that yet another binding might 
support one but not the other.  For example, we could imagine that our 
HTTP binding supports R-O-R and ReqOnly, as it does today, and XMPP might 
support just R-O-R.  Now you've correctly modeled for applications that 
the two are quite interchangeable for R-O-R, but you have not obligated 
XMLP to support Response-only.

> when you are using this MEP, do this with the underlying 
> transport/transfer and when you use this other MEP, do something 
> different; something that will inform the binding at the other end 
> that you are using a different MEP. 

I would expect that in a language like Java, you would have very roughly:

interface Request-Optional-Response {
        void sendRequest(URI u, msg m);
        msg waitAndReceiveResponse();
}

interface Response-Only {
        msg = getRepresentationEnvelope(URI u);
}

class HTTPBindingImplementat implements Request-Optional-Response, 
Response-only {

        sendRequest(URI u, msg m) {
                hMsg = new OutboundHTTPMessage();
                // this line shows where the switch is set
                hMsg.Metbod = "POST";
                ...
        }
        ..
        getRepresentationEnvelope(URI u) {
                hMsg = new OutboundHTTPMessage();
                // this line shows where the switch is set
                hMsg.Metbod = "GET";
                ...
        }


}

class XMLPP BindingImplementat implements Request-Optional-Response {

        sendRequest(URI u, msg m) {
                xMsg = new OutboundXMPPMessage();
                ...No need to set switch here, because only one MEP 
supported
        {
}

The above is rough pseudocode, but I think it makes clear that it's the 
binding implementation that realizes the MEP, and that leaves markers in 
the transport-level message if MEP control is needed.

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








Christopher B Ferris <chrisfer@us.ibm.com>
Sent by: xml-dist-app-request@w3.org
03/04/2006 08:07 AM
 
        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        multiple MEPs per binding



Noah wrote in IRC: 

[07:02] noah: I'm afraid I disagree with Chris on the multiple 
MEPs/binding.  I think they're in the spirit of Java interfaces.  Saying 
that one binding can do multiple MEPs and keep them straight, lets you 
capture the mix n match between capabilities shared and not shared by 
different transports 

With all due respect to Noah's point, I'm not sure that I agree. 

Now, I will concede up-front that Noah may well have thought this through 
more thoroughly than I, and he may have 
concrete examples of cases where it is not necessarily the case that the 
problems and distinctions I cite below would 
be evident were one to overlay two or more MEPs over a single binding. I 
am certainly open to hearing more 
of what Noah has to say on the matter. 

I will also concede that I may be making too-fine a distinction here. 

Consider the SOAP Response, Request-Response and (the as-yet undefined) 
One-way MEPs. 
One might claim that a SOAP/HTTP can theoretically support them all. 
However, I  would argue that this may not be 
the case. 

Consider that R-O-R says that if a fault is generated, send it on the 
response channel corresponding to that on which 
the message that generated the fault was received. Thus, even if there 
were a WSA response endpoint(s) which 
explicitly said: send the response and/or faults over here instead of on 
the response channel, because a SOAP 
mU (or VersionMismatch) fault MUST be generated before any other 
processing of the message is performed, 
and because the SOAP processor MUST NOT perform any other processing on 
that message (other than that 
necessary to deliver the fault), there is ALWAYS the chance that there 
will be a SOAP envelope transmitted on 
the response channel of an HTTP request. One cannot assume that the SOAP 
processor, written to the SOAP1.2 
spec will ever even consider the WSA header blocks as being more than 
QNames to check against a table 
of supported QNames for the role that the node operates under. 

If you had a one-way MEP that said: you send a SOAP message and get no 
SOAP response (let's leave FAF out of it 
for the time being) and claimed that HTTP supported this MEP, then unless 
you have included some explicit 
hint at the HTTP level (not the SOAP level) that said: under no 
circumstances can you include a SOAP 
envelope in the HTTP response, that the sending endpoint MUST, regardless 
of what MEP were in play, 
be prepared to receive a SOAP envelope in the HTTP response. 

In the case of the SOAP Response MEP, the fact that you use a different 
HTTP method (GET), and you 
serialize the request such that there is no SOAP envelope infoset in the 
entity body I think makes it 
a different binding. The rules are different for this MEP than for R-O-R. 

Hence, if you were to try to layer multiple interfaces ala Java over the 
binding, unless you actually change 
the binding (and by that, I mean that you do something different at the 
binding layer for one MEP 
that you don't do for another) then you  may be in for a nasty surprise. 

In the case where one defines a binding and says that it supports a given 
MEP, I don't believe that 
you can simply overlay another MEP if it requires that the rules for the 
binding be changed to 
accomodate it. 

I would argue that by doing something different in the binding, outside 
the SOAP envelope, that in fact, you 
have a different binding. The fact that the protocol used was the same is 
not material. The fact that 
the rules used to serialize the message for that binding are different for 
the two MEPs, I believe, makes 
it a different binding. 

Now, I will agree that you can certainly layer an interface over the API 
that implements the underlying 
transport (HTTP) but IMO, what you have to have is something specific that 
says: when you are 
using this MEP, do this with the underlying transport/transfer and when 
you use this other MEP, do something 
different; something that will inform the binding at the other end that 
you are using a different MEP. 

Could that be captured in the binding? Yes, I suppose, especially in the 
case where the binding is 
initially defined such that it supports a set of MEPs. However, I don't 
think that it is safe to assume that 
you can do this as a general rule of thumb. 

Cheers, 

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Received on Monday, 6 March 2006 13:47:27 UTC