On 8/20/12 9:33 PM, "Murali Reddy" <[email protected]> wrote:
>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. This is exactly what I meant. >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. > Agree. >
