On 8/15/12 10:57 PM, "Alex Huang" <alex.hu...@citrix.com> wrote:
> > >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> Sent: Wednesday, August 15, 2012 9:53 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: Re: [Discuss] CloudStack architecture to a loosely-coupled >> component oriented distributed architecture >> >> On Thu, Aug 16, 2012 at 12:24 AM, Kelven Yang <kelven.y...@citrix.com> >> wrote: >> >>The only hesitation that I have is around ease of installation /> >> >>configuration. CloudStack is great at this today (one of the reasons >> >>that my company gravitated to it), and I don't want to lose that >> >>value. I don't think this is a blocker to distributing the system at >> >>all, but it will be a critical design and implementation detail to >> >>consider. >> > >> > Yes, we should not sacrifice too much to lose the ease of >> > installation, one of the most attractive property of CloudStack. the >> > problem may be improved by having component-provisioning service in >> > CloudStack core component that helps installation and auto >> > configuration of other components >> >> Agreed. I just wanted to be sure we were thinking about it! >> >> >>How do you see this matching up with Murali's Event notification >> >>framework proposal? It seems to me, that switching to a distributed >> >>model requires a shift in his thinking on the actual event framework >> >>itself. >> > >> > Murali's event notification assumes reliable event service requires by >> > the semantics from business logic. It basically converts synchronized >> > listener callback pattern into a disconnected implementation fashion. >> > >> > The messaging event I mentioned in the proposal has more semantics >> > towards signaling process, it does not have a strong semantics to >> > require a reliable event notification mechanism. >> > >> >> I think I follow you, but my point is that I like Murali's proposal >>quite a bit. >> Except in this context it needs to change to account for the proposed >> distribution of processes that may contain potential event sources and >> listeners. Isn't this an opportunity to use a common messaging >>approach, >> expecting syntactic differences between the use cases? I think the >>goals of >> the two proposals are complementary. >> Elements of the proposed implementation approaches are what need to be >> adjusted. > >I don't think Murali and Kelven's proposals are related. Murali's is a >notification system so that someone who doesn't even want to know about >cloudstack's code can still interface with cloudstack and react to entity >changes. Kelven's defines the ipc mechanism used by cloudstack >components. I think it's best for these two to grow separately. Now >it's possible that the underlying mechanism to implement these two ends >up to be the same thing but at least their semantics should be different. > >--Alex > As alex pointed, there are some differences between the two. I know that in our current code base we use a lot of in-process listener-callback pattern to encapsulate isolated logic in different modules for better modularization. Inside the same component, this pattern applies perfectly. However, when we come to a distributed world, unless the logic semantic implies that this can be decoupled in disconnected fashion, we should not use the listener-callback patter across components, it assumes strong coupling, if the business logic requires such strong semantics, it should go through in orchestration process so that the flow state can be managed in terms of component failures. Kelven >
