Possible approaches and existing options for going forward

Per yesterday's concall, I took the action item to write up about the
existing set of proposals and gaps with respect to directions we can
take. I also checked the minutes of the concalls in May. The last time
we talked about how mappings between WSDL MEPs and SOAP MEPs occurs is
on [IRC LOG] As all of you can see yourselves, I point out that we did
NOT have any consensus on how to solve WSDL MEP to SOAP MEP issue
contrary to what has been advocated in the concall. As a result, I will
leave this as an "option" as one of the options that we can explore in
this landscape below. 

Async scenerios are only enabled as a result of WS-Addressing, either by
using WSDL MEP mapping changes to SOAP MEPs or protocol extensions. We
have several options, concrete proposals and gaps in the following
areas. I put all the links to proposals. Apologies if I missed anything,
please reply back and add them. 

-- A new binding or binding extension is to support async SOAP 1.1/HTTP
binding. See proposal in [HTTP Extensions]. How it can be used in
conjunction with WSDL 1.1 is described in the same proposal [HTTP
Extensions]. 
-- For SOAP 1.2, a new Input MEP is needed. David Orchard proposes a new
SOAP MEP [DO SOAP MEP]. This MEP also enables WSDL 2.0 in xx MEPs to be
represented without changing WSDL 2.0 design. It addresses LC issues [
WSDL LC 79], WSDL LC 102 ] I observe that since David allows a SOAP body
in HTTP response (Section 3.5.2.2. Receiving Table last row) which may
not be desirable for true one-way MEPs. I am not sure whether we have
decided whether we will need a tighter SOAP MEP based on this proposal
for true SOAP one-way which disallows any SOAP response. This may
require some more tweaking...
For representing WSDL 2.0 in-out MEP, we have three separate approaches:

(a) Leave the current WSDL 2.0 design intact. Provide a new SOAP
1.2/HTTP binding for SOAP request-response MEP. See a proposal [1] for
this approach. 
(b) Alter the current WSDL 2.0 design. For each WSDL operation and WSDL
MEP, the binding will have to list multiple SOAP MEPs that correspond to
the WSDL MEP. No detailed proposal unless I missed a detailed WSDL 2.0
design that has been presented. For WSDL in-out MEP, the WSDL binding
for SOAP will use two of the David's new SOAP MEP for representing
asynchronous request response. 
(c) Leave the current WSDL 2.0 design intact. Use WSDL extensions to
designate multiple SOAP MEPs for each WSDL MEP. Still we do not have
complete proposal for such an extension although it is mentioned but not
fully scoped in the [IRC LOG]. 
Async request response over multiple transports. (Essentially [WSDL LC
101]) 
-- Proposal (a) does not provide a solution, but considers this problem
out of scope. Defers to a higher level specification that combines two
WSDL one-way operations to compose an async request response over
multiple transports (WS-MD, BPEL, ...). 
-- Proposal (b) or (c) may provide a solution to this problem, but will
require additional changes to WSDL 2.0 to indicate the binding for each
SOAP MEP. Currently the binding governs the entire operation. Kevin
looked at this a while back and explored some approaches how the change
may be [Kevin]. We do not have a solid proposal yet from the async task
force how this would be. 
Pros and Cons: 
We have proposals for SOAP 1.1/HTTP, SOAP one-way MEP and binding for
HTTP for SOAP 1.2 which we can further refine. If we proceed with
Proposal (a), we don't change WSDL 2.0 design. We are done with WSDL 1.1
and WSDL 2.0. 
If we proceed with Proposal (b), we still need to spec out WSDL 2.0
changes in detail and how WSDL MEP to SOAP MEP mapping will be. Proposal
(c) is less distruptive than (b) because it does not change WSDL but
defers to extensions. 
I personally would at least like to be done with WSDL 1.1 and HTTP 1.1.
>From SAP's perspective, we have a concrete proposal on the table which
does not change WSDL in anyway. 
In order to proceed with Proposals b-c more work/proposals need to be
made in order to make recommendations to the WSDL wg about some of the
LC issues. One approach may be to think aysnc over multiple transports
(SOAP HTTP in/SOAP SMTP out) out of scope for WSDL and defer it to an
extension. This is to say that HTTP binding extensions within the scope
of WS-Addressing and WSDL will be necessary anyway to support
WS-Addressing with WSDL. 
--umit 
[HTTP Extensions]
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005May/0033.html

[DO SOAP MEP]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/att-015
9/WS-Addressing-SOAP-Adjuncts.html#soapreqinhttp
<http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/att-01
59/WS-Addressing-SOAP-Adjuncts.html>  
[IRC LOG] http://www.w3.org/2005/05/18-ws-async-irc 
[WSDL LC 79] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC79
<http://www.w3.org/2002/ws/desc/4/lc-issues/>  
[WSDL LC 101] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC101
<http://www.w3.org/2002/ws/desc/4/lc-issues/>  
[WSDL LC 102] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC102
<http://www.w3.org/2002/ws/desc/4/lc-issues/>  
[Kevin]
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0024.html