RE: choreography protocol

> >My personal feeling is that its better to just have request-response
> >and not say at the abstract level whether or not the response is on
> >the same channel or not. That's a binding characteristic - the 
> >abstraction is that there's a request and there will be a response.
> >Take an SMTP binding - every response would be on a separate channel
> >vs. and HTTP binding where the response can be on the same channel.
> >  
> >
> I agree.
> 
> I think it should be a matter of protocol selection, and we actually 
> took the liberty in trying to do that with WSDL 1.1 and it 
> seems to work 
> pretty well. With one caveat.
> 
> If you have some process that tends to use other services, as 
> defined by 
> their interface, that insist on such high latency request/response 
> cycles, then obviously you can't invoke that process using 
> HTTP and wait 
> for a response in the same connection. So there needs to be 
> some way to 
> mark the interface as using one means of communication vs another, so 
> you can tell how it affects all other involved parties.
> 
> Perhaps using F&P?
> 
> arkin
> 
> >Sanjiva.

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. 

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).

Ugo

Received on Sunday, 22 June 2003 13:28:45 UTC