Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of darren@godaddy.com designates
 208.109.78.206 as permitted sender)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
User-Agent: Workspace Webmail 5.6.24
Message-Id: 
 <20120820095931.d3d18d9a633cb81ed61112bf108fc615.d0f0ad64d1.wbe@email00.secureserver.net>
From: "Darren Shepherd" <darren@godaddy.com>
To: cloudstack-dev@incubator.apache.org
Subject: RE: [Discuss] CloudStack architecture to a loosely-coupled component
 oriented distributed architecture
Date: Mon, 20 Aug 2012 09:59:31 -0700
Mime-Version: 1.0

=0A=0A=0A=0A=0A> -------- Original Message --------=0A> Subject: Re: [Discu=
ss] CloudStack architecture to a loosely-coupled=0A> component oriented dis=
tributed architecture=0A> From: Chip Childers <chip.childers@sungard.com>=
=0A> Date: Mon, August 20, 2012 6:55 am=0A> To: cloudstack-dev@incubator.ap=
ache.org=0A> =0A> =0A> On Mon, Aug 20, 2012 at 9:53 AM, Alex Huang <Alex.Hu=
ang@citrix.com> wrote:=0A> >>=0A> >> http://www.cloudscaling.com/blog/cloud=
-computing/simplicity-scales-an-=0A> >> alternative-approach-to-openstack-n=
ova-rpc-messaging/=0A> >>=0A> >> Zeromq seems good.=0A> >> >=0A> >=0A> > I =
like 0mq as well but it's LGPL.  I've been reading up on the whole apache c=
ompatibility license thing and there doesn't seem to be a way around it.  I=
t has to be optional component.=0A> >=0A> > So I believe this is crucial.  =
The underlying messaging infrastructure should be switchable then people ca=
n use whatever they want, including 0mq.  So to discuss what the underlying=
 mechanism is right now is beside the point.  First Murali and Kelven needs=
 to develop their respective abstraction layer.=0A> >=0A> > --Alex=0A> >=0A=
> =0A> +1 - We can get to the "out of the box" messaging system selection=
=0A> after understanding the abstractions and logical relationships (if=0A>=
 there are any in the end).=0A=0AI agree its important to have a messaging =
abstraction layer up front. =0AThe specific implementation can be decided l=
ater and should be pluggable=0A(I too would like 0mq, that darn LGPL).  Wha=
t most people over look with=0Amessaging is it not really important what MQ=
 implementation you use=0A(that can easily be changed), but instead HOW you=
 use it.  The how is=0Awhat ends up causing problems if not thought through=
 properly.  For=0Aexample, if you do a simple event driven system and then =
your billing=0Asystem works off of those events, you've just put yourself i=
nto a=0Amessaging pattern that requires persistent and transactional messag=
ing=0A(which is more complex to scale).  So, just food for thought.=0A=0ADa=
rren