RE: Draft decision tree / summary

I'd like to add in my original propose as the simple "one-way", and I
just did a proposal for simplifying meps/bindings so there is no "soap
meps".

Dave

> -----Original Message-----
> From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-
> request@w3.org] On Behalf Of Glen Daniels
> Sent: Wednesday, July 06, 2005 12:54 PM
> To: public-ws-async-tf@w3.org
> Subject: 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 20:08:02 UTC