Re: Issue 59 alternate proposal

I thought we had reached at least a rough consensus on:

    * Use 202 as an HTTP response if nothing else is coming back.
    * We need some kind of one-way SOAP MEP
    * We should add a "response bindings" markup to usingAddressing to
      indicate the ways that an endpoint can send back (async) responses.

I'm a little concerned to read that we've really only agreed on one of
these three.

Yalcinalp, Umit wrote:

>
>  
>
>>-----Original Message-----
>>From: David Orchard [mailto:dorchard@bea.com] 
>>Sent: Tuesday, Nov 01, 2005 10:06 PM
>>To: Yalcinalp, Umit; Marc Hadley; public-ws-addressing@w3.org
>>Subject: RE: Issue 59 alternate proposal
>>
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: public-ws-addressing-request@w3.org
>>>      
>>>
>>[mailto:public-ws-addressing-
>>    
>>
>>>request@w3.org] On Behalf Of Yalcinalp, Umit
>>>      
>>>
>><snip/> 
>>    
>>
>>>Our proposal specifically defined how the request-response would use
>>>      
>>>
>>two
>>    
>>
>>>distinct HTTP connections, 202, etc.  
>>>      
>>>
>><snip/>
>>
>>I think it's standard practice to call how a request response uses a
>>protocol including the protocol status codes a "binding".
>>
>>My concern with doing away with MEPs completely is exactly 
>>shown by this
>>proposal.  
>>
>>Without any kind of protocol/lower level MEP, it is impossible to talk
>>about what happens with request response without talking about a
>>particular binding, in your case SOAP HTTP.  In a binding 
>>extension that
>>controls interaction patterns like usingAddressing, you end 
>>up either a)
>>not talking about meps/bindings/protocols at all, which is very
>>unusable, or b) talking about a specific binding/protocol, which is
>>highly undesirable from a re-use, layering, modularity, and
>>"well-factoring" perspective.  Well factored and modularized design of
>>specs is one of the tenets of the Web Services architecture, 
>>or at least
>>so it's been said.
>>    
>>
>
>Dear Dave, 
>
>I am assuming that you have concerns with both proposals as they both
>bypass the MEPs in a way.
>
>I completely agree with you in sentiment and goals. Ideally, we could
>have accomplished this within the parameters that you suggested.
>However, I am just trying to be practical and wearing my product hat on.
>
>
>We have SOAP 1.1/HTTP and SOAP 1.2/HTTP. Both of them are in scope, both
>are in practice ( AFAIK people are starting to release implementations
>on the latter). We have a limited time to deliver something useful that
>people can interoperate on. 
>
>We can not define MEPs for SOAP 1.1/HTTP. 
>
>The ongoing discussions at the Async TF has demonstrated to me that
>there is not really a consensus about how to layer WSDL MEPS and SOAP
>MEPS and the relationship between them. Among many choices we have
>discussed, 1-m mappings, getting rid of MEPs altogether, etc. Here we
>are. 
> 
>Either WS-Addressing wg redisgns WSDL 1.1 and WSDL 2.0 and how this is
>done for all possible binding, etc.  or we solve the problem with what
>we have agreed with.
>
>We spent many months in async tf. We had very good discussion,
>discovered many issues. AFAIK, We did NOT reach consensus. 
>
>I neither view our proposal as an example of the best possible
>architecture there is nor will get into a debate of
>"my-architecture-is-better-than-yours" since it does not apply ;-) but
>the reality is I personally am looking for is concrete simple rules to
>point developers to that reflects what they got consensus on: On the
>wire messages for async with SOAP/HTTP. It is a simple concrete way to
>solve the problem reflecting the only consensus point we had without
>rearchitecting the whole stack. 
>
>Hope the intention is clear. 
>
>
>  
>
>>Cheers,
>>Dave  
>>    
>>
>
>The clock is ticking, 
>
>--umit
>
>  
>
>
>
>  
>