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