- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 15 Jun 2005 16:00:39 -0700
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- CC: David Hull <dmh@tibco.com>, public-ws-async-tf@w3.org
Marc Hadley wrote: > On Jun 15, 2005, at 3:01 PM, Anish Karmarkar wrote: > >> >> In the case where wsdl:required="true" on a wsaw:ResponseBinding, it >> would not make sense to have more than one wsaw:ResponseBinding. In >> fact it would be an error to have two wsaw:ResponseBinding with >> wsdl:require='true' on both. >> >> >>> Does that make sense? >>> Or (re-reading) did you mean that wsdl:required would mean that >>> anonymous responses aren't allowed? >>> >> >> Yes, that's what I meant. >> > That sounds a little odd since anon replies can still come back before > [reply endpoint] takes effect (mU faults e.g.) ... > The mU fault issue is a general issue when using async over HTTP (or any protocol with a back-channel). As Hugo has mentioned on the ws-addr list, this is a problem whenever a [fault endpoint] is specified. But the usecase I want to support is not about faults. I want the ability to static specify in WSDL that the service will send the response (not faults) message asynchronously and therefore the invoker of the service must specify the [reply endpoint]. Make sense? > Even if we get round that problem it seems odd to only be able to > demand use of one particular transport rather than just being able to > say "must be async". > Why? The service may only support one transport (HTTP) and wants to indicate that the [reply to] endpoint (sent in the request message) must be a HTTP url/binding. But it is certainly a valid usecase to say "must be async" without demanding the use of one particular transport. -Anish ... <snip/>
Received on Wednesday, 15 June 2005 23:00:52 UTC