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