Draft decision tree / summary

Async-ers:

Here is a draft of what I'd like us to send to the various WGs.  Sorry I

didn't get this out earlier, comments/edits appreciated.

--Glen

----------------------------------------------------------

WS-Community:

This message is an attempt to coalesce the current thinking of the Async

task force into a (relatively) crisp matrix of questions/issues which
can be 
discussed and acted upon by the larger community.

BACKGROUND
----------

The Async task force was spawned in order to investigate the cross-group
issues between WS-Addressing, WSDL, and XMLP regarding the enabling of
asynchronous scenarios using WS-Addressing (since these types of
scenarios are one of the "raisons d'etre" of addressing).

Over the past few months we have come to consensus on some particular
scenarios [1] we'd like to support, and the *wire level* messages which
move between communicating parties in order to enact these scenarios.
The problem is now how to communicate in the various specs the rules and
guidelines by which someone unfamiliar with the deep context we (as WG
members) have with web services might implement software which in fact
reliably produces these wire messages.

THE PROPOSALS
-------------

We have several concrete proposals on the table, which are referenced in
the endnotes below.  They vary in a number of directions, which are
captured in the large in the questions below.

THE QUESTIONS
-------------

(some are simply questions, others have commentary)

Q: What about one-way scenarios? (the easy one first)

We have already requested the Web Services Coordination Group to
shephard 
a SOAP one-way MEP into existence.  We do not yet know exactly how this
work 
will be accomplished (in particular the question below regarding a new
HTTP 
binding versus errata on the old one is relevant here).  Note that it is
possible
that some of the proposals will affect or obviate this work.

Q: What is the relationship between SOAP MEPs and WSDL MEPs? (right on
to 
the tough one... this is a really central issue)

The group has not come to a solid consensus on this as yet.

- In the OSI proposal [OSI], we have a single SOAP MEP being "stretched"
across multiple transport connections.

- In one of DO's proposals [DO1] we have a single SOAP MEP being
"stretched"
even across multiple protocols.

- In DH's proposal [DH] a SOAP MEP is much more closely bound to an
underlying protocol MEP.

The choices come down to three:
1) SOAP MEPs can be abolished - WSDL MEPs are the only "spec'ed" MEPs
   necessary, and SOAP bindings may simply offer (well-named)
   mechanisms to send, receive, and potentially correlate messages.

2) SOAP MEPs are "closer" to underlying protocol MEPs.  They still
   exist, but they are simply used to abstract the features of the 
   underlying protocol.  If you take this tack, then WSDL MEPs can
   be composed of potentially several underlying SOAP MEPs.

3) SOAP MEPs are "closer" to WSDL (application) MEPs.  In other words,
   a single WSDL MEP should bind to a single SOAP MEP, and you let
   the SOAP binding do the work of potentially composing together
   multiple underlying protocol interactions to achieve asynchrony.

Choice 1 is a somewhat different way to think about SOAP bindings,
leaving the "heavy lifting" to the layer above (WS-Addressing/WSDL).

Choice 2 doesn't require changes to the SOAP binding framework,
but does require WS-Addressing to specify how WSDL MEPs can compose
SOAP MEPs.

Choice 3 puts more work in the hands of the SOAP binding, which
would then require some ability to "understand" WS-Addressing
constructs (in order to have the binding "switch" from doing a
"simple" MEP as per today's HTTP req/resp to doing a more complex
one involving multiple connections based on the presence of a
WSA header).

Q: Do we modify the existing HTTP binding in order to allow the new
behavior 
(errata), or do we create a new binding with its own URI?

Q: Does the WSDL <wsa:UsingAddressing/> markup mandate the new features
in 
the HTTP binding itself, or should some other markup be created to do
the job?

Q: What level of expressiveness do we need in the WSDL markup for
expressing 
what's offered/allowed?

This question really comes down to some sub-questions such as "do we
want
to support a concept like "ResponseBinding" as per [DH]/[MH]?" and "do
we
want to be able to indicate support for asynchrony on a per-operation
basis?".

Q: Is the low-level "ack" which indicates the successful processing of
at 
least the <ReplyTo>/<FaultTo> headers a SOAP message (abstractly at
least), or something else?

Q: Finally, a big underlying question here is "how much of this work
must be complete in order for WS-Addressing to declare success?"

Thanks,
--Glen

Scenarios/wire level messages
[1] http://www.pacificspirit.com/Authoring/async/async-scenarios.html

David Hull'S proposal
[DH]
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/0031.html

Oracle/SAP/IBM proposal (OSI)
[OSI]
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005May/0033.html

Dave Orchard's "recursive bindings" proposal
[DO1]
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/0008.html

Marc Hadley's proposal
[MH]
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/0029.html

Received on Wednesday, 6 July 2005 19:53:41 UTC