Re: Summary of decision tree for Addr/Desc groups

(I started filling this before our meeting so I thought I'll send
it out anyway ..)

Excellent questions, here are answers from my point of view ..

> * The SOAP layer
> 
> Q. It seems a new SOAP MEP (one-way) is very likely needed.  Alternately
> it *might* be possible to simply alter the request-response MEP in order
> to support the possibility of a "null" response envelope.  Does this
> work need to happen?
>  Q. Who should do this work?
>   a. XMLP group
>   b. WSDL group
>   c. Addr group

I don't think that its only XMLP who can define such extensions. 
However, it would appear to have more "credibility" if it came
from the XMPL group. If they are not able to the I'd prefer if WSDL
did it or if not WS-Addr.

FYI I raised this back in July 2004:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0326.html

> Q. Regardless of its technical feasibility, it's pretty clear that no
> one yet implements a "polling" style callback using HTTP as described by
> Marc in [2].  Do we want to try to encourage this pattern?  If so:
>   Q. Where should the work be done to describe it?
>    a. Errata to SOAP spec
>    b. Separate note
>   Q. how do we indicate in the WSDL that this is available/used?
>   Q. Does this change the SOAP MEP, or is it still a SOAP req/resp?

I'd say its the cheapest way to do async with HTTP and hence should
be promoted. In fact if you're coming from a disconnected device
(cell phone say) that's pretty much the only way. Not sure what JSR
172 does for this ..

I don't think these are *errata* against SOAP 1.2. These are *extensions*
and as such don't have to be done by XMLP. As I said above XMLP doing
it is best due to the implied "credibility". So best is separate note
from XMLP or WSDL or WS-Addr, in that order.

IMO this is a different HTTP binding of the SOAP req-resp MEP. So
the impact on WSDL is that the HTTP binding of the SOAP binding
will have a different URI.
 
> Q. Assuming both of the above affect the SOAP 1.2 spec(s), can the
> changes be published as "errata" so as not to cause a full release cycle
> of the spec(s)?

They don't "affect" the spec; they add to it. So its not errata but
a note.
 
> * The WSDL layer
> 
> The essential question at the WSDL layer is "what, if anything, do we
> need to change in WSDL (both 2.0 and 1.1) to enable the important
> use-cases that fall under the general heading of 'async'".  This breaks
> down into two categories - actual changes to WSDL core, and extensions.
> Clearly WSDL core changes (for 2.0 at least) need to happen under the
> auspices of the WSDL group.  Extensions could be built either by the
> WSDL group or the Addressing group (and "who does the work" is therefore
> an implicit secondary question to each of the ones in this section).
> 
> So here are some questions (these do not necessarily presuppose
> solutions):
> 
> Q. Do we want to enable/support the case where a single WSDL
> operation/MEP (request/response, say) can bind to multiple SOAP MEPs?
> (i.e. the seemingly-common use case where the request comes in on one
> HTTP interaction with a <replyTo>, and the response goes out in another
> transport interaction (either HTTP or otherwise))

I still haven't seen the need for a single WSDL MEP to go to multiple
SOAP MEPs. What I see are needs to bind a WSDL MEP to a different
SOAP/HTTP protocol binding than the default SOAP/HTTP binding defined
by XMLP.
 
>  Q. Do we want to enable/support the above with multiple transports?
> (req is HTTP, resp is SMTP)

+1.
 
>  Q. Do we feel the pattern/transports for the above need to be locked
> down in the WSDL (i.e. all binding details except the actual address(es)
> are specified), or do we want to enable/support "floating" bindings (for
> which runtime EPRs may change the transport/binding details)?

+1 for "floating" bindings. IMO that's the reality scenario ..

> Q. Whether or not we choose to move forward with asynchronously binding
> single WSDL operations/MEPs, should we consider some form of
> standardized extension in order to indicate a correlation between
> multiple WSDL operations?  This would enable, for instance, a WSDL
> in-only operation to be treated as a request, and a separate out-only
> operation to be treated (somehow) as a correlated response.

No standard for correlating across multiple operations .. that's 
what BPEL level is for.

> Q. Assuming we do NOT want to move forward with any of the above work,
> does anything in WSDL as it stands prevent/hinder others (or our future
> selves) from using extensions to WSDL 1.1 / 2.0 to achieve these cases?

I think we do need to do some work so this question is N/A.

> * The WS-Addressing layer
> 
> Nothing obvious came up which involved changes to the WS-Addressing core
> beyond the work that the WS-Addressing group might take on as a result
> of the stuff above.  So this layer simply contains the question:
> 
> Q. Does anything need to be done to the WSAddr spec(s) to enable this
> stuff?

I don't think so.

Sanjiva.

Received on Thursday, 3 March 2005 19:42:37 UTC