Draft decision tree / summary 2

 
Take 2.  Reformat a bit, add DaveO's other proposals, add a bit
more exposition.

--G

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

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.

* DaveO's one-way proposal [DO2] is one attempt at this

* DaveH's proposal [DH] in fact obviates the need for this work
  to be done immediately - since the basic problem everyone's
  trying to solve is one-way-over-HTTP, utilizing the underlying
  request-response MEP to carry a WSDL in-only operation does the
  job.  We would still need a SOAP one-way for bindings such as
  UDP or email at some point, however.

* DaveO's recursive proposal [DO1] also deals with this
    [ed note: does it??]

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

DaveO's "oneway" proposal [DO2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/att-015
9/WS-Addressing-SOAP-Adjuncts.html

DaveO's proposal for non-SOAP-specific MEPs [DO3]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0010.ht
ml

Received on Wednesday, 13 July 2005 19:59:08 UTC