W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2003

RE: choreography protocol

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Fri, 20 Jun 2003 17:06:04 -0400
To: "'Assaf Arkin'" <arkin@intalio.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>
Cc: "'Ugo Corda'" <UCorda@SeeBeyond.com>, <public-ws-chor@w3.org>
Message-ID: <003a01c3376f$c5d5b340$2278050a@JJD>


>>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.
>>
[JJ] Ok, but I still think that something has to be part of ws-chor and
it does not require us to boil the ocean. I tend to think in terms of
requirements first, and level of effort second, that's usually a better
approach to build a functional system. It is not because something takes
to long that we should not do it and conversely not because that
something does not take any time that we should do it.
 
>>We can boil the ocean and attempt to describe what these signals
should
>>look like, or we can just bank on the existence of other
specifications
>>that already address these out-of-bands messages (e.g. WS-TX, WS-RM 1
>>and 2).
>>
>>>You may not want to have the process engine really being involved in
>>>managing these signals. For instance if you implement a 2 signal
>>>protocol like BPSS (message structure valid, message processed), the
>>>message structure validation should be done by the service interface
and
>>>not below by the process engine for instance. The same could be true
for
>>>the "message processed" signal, you could have the application
sending
>>>it to the service interface via a call back. That would offload the
>>>process engine. This is more questionable as you could say that the
>>>application should really not know anything about the outside world,
or
>>>"message processed" could mean that 3 applications get to see the
>>>message, in which case the process engine is certainly much better
>>>position to compute and return that signal.
>>>
>>>
>>What does it mean 'request processed' but 'I'll send you a response
>>later on'?
[JJ] This is a very common think that can happen where for instance,
before an AckPo can be sent, someone has to look at it. As you can
imagine, none of this is going to happen synchronously. However, you
want to make sure that the state of the choreography is aligned in both
parties by exchanging a message that says that the order is being
processed.
Received on Friday, 20 June 2003 17:06:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:21 GMT