On 8/20/12 9:49 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote:
> > >On 8/20/12 9:33 PM, "Murali Reddy" <murali.re...@citrix.com> wrote: > >>On 20/08/12 11:23 PM, "Kelven Yang" <kelven.y...@citrix.com> 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. I just started to work on this. I'm evaluating and testing out the messaging choice (ZeroMQ/ActiveMQ) in javelin branch. Here is some of requirements I'm considering Event notification for orchestration signaling process RPC over message queue Above two use the queue facility as a unicast and multicast capable transport, reliable delivery is not mandatory, and persistency is also not mandatory, but responding time should be in range of orchestration needs. I original thought to use blind-multicast to auto-scale the event processing components, however, this approach needs assistant from a distributed lock facility like ZooKeeper, now I'm also thinking to build on top of a load balancing feature in the signaling process by using multicast/unicast service provided from the messaging facility, basically, event signaling process has a destination resolution phase before final delivery and load balancing can be handled in the signaling phase without a need for locking facility. (Maybe too complex and wild idea? This is trying to reduce the setup complexity of the Cloud as a whole) Persist queue events This usually requires persistence and reliable queue service. Suitable for workflow integration with external system (Murali's proposal) >> >>> >>>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. > > >> >
