Re: choreography protocol

Sanjiva Weerawarana wrote:

>"Assaf Arkin" <arkin@intalio.com> writes:
>  
>
>>WSDL 1.2 has in-out and request-response. The distinction is that for 
>>request-response the response would be sent on the same channel as the 
>>request. There is no such constraint for in-out. So if you are using the 
>>in-out operation with some layer that supports reliable messaging or 
>>coordination you would in fact have signals travelling back and forth.
>>    
>>
>
>Just to be clear - these patterns are not agreed to in the WG yet.
>This is still work in progress.
>  
>
Damn, we already started building an implementation around this! Just 
kidding ;-)

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

Received on Sunday, 22 June 2003 00:10:57 UTC