- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Mon, 23 Jun 2003 09:39:37 +0600
- To: <public-ws-chor@w3.org>
"Ugo Corda" <UCorda@SeeBeyond.com> writes: > Yes, relying on the WSDL binding works when you can express that > binding in your spec. But what if you are writing a spec (e.g. a > choreography spec) that prefers to leave WSDL bindings unspecified > but still wants to talk about request/response on the same channel > vs. on different channels? WSDL right now does not specify any way > to express that. To me that's a programming model choice of the service invoker and something that does not concern the service developer/describer: they simply indicate the message pattern. > It looks like BPEL got around this problem by saying that a > request/response on the same channel maps to a WSDL request/response > MEP, while a request/response on different channels maps to two > separate one-way MEPs (where the response one usually gets labeled > "callback" as an additional syntactic sugar). BPEL's solution does not assume that an <invoke> of a request- response operation is such that both messages go on the same channel. Its simply a blocking invocation .. waiting for a response. Yes, the use of one-way MEPs is the way to get async usage of a request-response pattern in BPEL right now. However, IMO that's not quite right .. I would've preferred to have a <send> primitive which could be coupled with a <receive> to allow a BPEL author to use request-response operations with an asynchronous model. Sanjiva.
Received on Sunday, 22 June 2003 23:39:33 UTC