Re: multiple MEPs per binding

Shouldn't we then provide a way to specify what binding/MEP is being 
used at the protocol level. I.e., a HTTP header

-Anish
--

Christopher B Ferris wrote:
> 
> 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 Saturday, 4 March 2006 13:37:43 UTC