RE: Possible approaches and existing options for going forward

Comments inline, and some general comments here.

 

I like this approach of listing all the solutions/proposals, but I found
this more than a little muddled.  You missed a big item, which is a
solution to straight-up one-way.  I've proposed an MEP and a Binding to
do that [DO SOAP MEP].  I think the [DO SOAP MEP] should actually be
characterized less personally and more technically as [one-way SOAP MEP
and SOAP HTTP Binding].

 

You've listed pros and cons after the multi-protocol section, is that
just for multi-protocol or for all of async?  You say "if we proceed
with a) we are done with wsdl 1.1 and wsdl 2.0" but I don't see that at
all.

 

One of the reasons I really like the one-way soap http binding is:

1. It can be used for a WSDL one-way MEP.

2. It can be used twice for a WSDL req-resp that is mapped to two soap
one-way meps and both bindings are http.

3. It can be used once for a WSDL req-resp that is mapped to two soap
one-way meps and one of the bindings is http.

 

I don't think these re-usability advantages of the one-way mep are
summarized very well in your paper.

 

I also think there are some potential advantages of introducing BOTH a
one-way and a multipleconnection Binding as you propose, but there is a
cost as well.  In particular, WSDL 2.0 and WS-A could say "the wsdl mep
and the soap mep ALWAYS directly map appropriately, ie WSDL in-only is
SOAP in-only MEP".  Then, WS-A could say that when a soap
request-response mep is over 2 http connections (like where ReplyTo  or
FaultTo contain http: and non-anonymous addresses) then the
multiconnection Binding is in use.  But this does have a big problem of
how to represent multi-protocol bindings.

 

I see the solution for one-way, same protocol async as a trade-off
between:

Option #1: One way MEP and One-way SOAP Binding: Minimal new bindings
and meps and solves multi-protocol bindings, potentially complicates
WSDL 2.0 and WS-A as 1 wsdl mep could be 2 soap meps.

Option #2: One way MEP, One-way SOAP Binding, and multipleConnection
Binding: Additional binding, potentially simplifies WSDL 2.0 and WS-A as
1 wsdl mep MUST only be 1 soap mep.  Doesn't solve multi-protocol
bindings problem.

 

Another way of looking at it: do you want to do more work in writing
bindings or more work in WSDL 2.0/WS-A.  

 

I'll note that the "multi-protocol" async has not been addressed at all
by the multipleConnection binding authors.  To use a soap
request-response MEP that used a single bindings, we would actually need
a "meta-binding" where each of the discrete bindings is filled in by a
concrete one-way binding.   Glen has hinted at this for at least a year,
but hasn't proposed anything as of yet.

 

OR we could be in the worst place possible: wsdl in-out over 2 http
connections means 1 soap mep and 1 new soap binding, and wsdl in-out
over 2 protocols means 2 soap meps and 2 new soap bindings.  That means
we don't gain the advantages for WSDL of wsdl in-out = soap req-resp,
and there's one new soap mep and at least 2 new soap bindings.

 

Let me say this more strongly: Mapping a single wsdl mep to multiple
SOAP MEPs allows all the scenarios we want - one-way, in-out over 2 http
connections, in-out over multiple protocols.  It suffers from the
problem that there isn't the simplification of 1 wsdl mep = 1 soap mep.

 

I've separately directly addressed the mutlipleConnection Binding, which
I think - and the author(s) admit - needs a lot more work.

 

Cheers,

Dave

 

  _____  

From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: Thursday, May 26, 2005 9:35 AM
To: public-ws-async-tf@w3.org
Subject: 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. 

DBO> I agree the minutes do not capture any consensus.  I do recall
specifically calling the question of "Do we have consensus that shall be
possible to map 1 WSDL in-out MEP to 2 SOAP MEPs".  However, if it's not
minuted and nobody else recalls such a historic consensus, then we can
realistically only proceed as you suggest.

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...

DBO>Agreed.  Perhaps the proposed MEP is actually in-optional-fault, but
I'm comfortable removing the response if necessary.  

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. 

DBO>What's [1]?  Is this [HTTP Extensions]?

(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]. 

DBO> Couldn't this just be the WS-A WSDL extension usingAddressing?  I
imagine the ws-a extension saying something akin to "If you have a WSDL
req-resp then the presence or absence of ReplyTo and FaultTo will
determine how many and which MEPs and Bindings are in effect."  Then
something like David Hull's decision tree.

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. 

DBO> for multi-transports with the wsa extension in play, why can't the
extension just say something akin to "If you have a WSDL req-resp then
the presence or absence of ReplyTo and FaultTo will determine how many
and which MEPs and Bindings are in effect".  Etc.  

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
<http://lists.w3.org/Archives/Public/public-ws-async-tf/2005May/0033.htm
l>  
[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
<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
<http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0024.htm
l>