"daniel.brum(a)jboss.com" wrote : anonymous wrote : Is this done sequentially or concurrently? Do you wait for the receivables to ack before sending to the payroll? If the answer is yes, then there's not really a problem AFAICT. If the answer is no, then we're talking about "asynchronous" interactions and, assuming the sender wants some kind of ack from each, the underlying infrastructure will need to be able to tally responses with "rendezvous" requests from the client, in just the same way it would for any "asynchronous" interaction. | | I would say that this is actually not a part of routing, but in fact a BPM process that keeps track of all the routings required for a particular message that comes in. The routing should be fire and forget, and it should be the job of an encompassing business process definition that knows if all parties required have been notified or not. If not, maybe it takes an action to have the message routed again, or if it's an optional recipient (say a statistical analysis system) that can live without the data being there for a real-time process, then it let's the logic continue, etc. | | I don't think we should be coupling the routing system to the systems receiving those routed data sets. I think the example given certainly falls into a traditional BPM scenario. There may be some cross-over between BPM and CBR examples. Enabling users to do the same thing in different ways isn't necessarily a bad thing. I don't think there was/is the intention to tie our CBR implementation to a specific set of use cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980810#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...