On 20/08/12 11:23 PM, "Kelven Yang" <[email protected]> wrote:
>Murali, > >The key point is the shifting to event-driven programming model itself at >orchestration layer, the underlying facility is currently not at critical >path, we will need to do a messaging arbitration here so that we can >plugin a suitable MQ selection in a fairly easy step. One thing I'm sure >is that we won't use two separated MQ solutions in one system. Agree. Underlaying messaging infrastructure is not much of concern, but my point was we need to have message abstraction (be it for IPC, event notifications) requirements so that we know what to expect from middleware when we need to choose. > >We also need to think twice of tight-coupled listener pattern across >components, if listeners from different components are implicitly required >to participate application level transaction across components, it should >better be done through an orchestration process. > >Kelven > IMO, I think we need to move away from listener-callback paradigm in distributed environment. Good thing is its not used much and is not required for event notification framework as well. Its good if we have request-response messaging pattern. I am thinking aloud, in enterprise environments it can enable 3rd party components to integrate workflows in orchestrations in a loosely coupled manner. For e.g. On Vm starting event message, external workflow software can provision resources like IP, name, user creds etc provide a response which can be used to provision the Vm with provided details.
