incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Zhang <Frank.Zh...@citrix.com>
Subject RE: Proposal to use OSGi for component modularity
Date Thu, 31 May 2012 20:40:14 GMT
That's what my thought too

> -----Original Message-----
> From: nour.mohammad@gmail.com [mailto:nour.mohammad@gmail.com]
> On Behalf Of Mohammad Nour El-Din
> Sent: Thursday, May 31, 2012 11:36 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Proposal to use OSGi for component modularity
> 
> Hi...
> 
> On Thu, May 31, 2012 at 8:11 PM, Frank Zhang <Frank.Zhang@citrix.com>
> wrote:
> 
> > Thanks for explanation. These concerns may be too technical not
> > relating much to architecture requirement that Alex mentioned.
> > I raised them here because I could not figure out them in my one week
> > OSGI journey.  I admit that I might not spend enough time, but I feel
> > one week is enough to get an idea of if the technology suits my
> > requirement. I looked into Felix and Spring DM (which turns out to be
> > Eclipse Virgo), Felix is quick to ramp up while Spring DM has better
> > document. I know the best way to understand OSGI is reading its spec,
> > but the 1500 pages specification is daunting.
> >
> > "Do you need modularity in your application?" I believe everybody will
> > answer yes. "Do you need OSGI?" I think the answer is "depends".
> >  The requirement is quite simple 1. No runtime update 2. Version
> > control is not urgent.  Then I am thinking why I have to overcome
> > steep learning curve for my simple requirement, there are lots of ways to
> go.
> >
> > And achieving modularity does not relate much to using whatever tool
> > or framework, as long as the application itself is designed in modularity way.
> > For instance, to join OSGI family, properly organizing MANIFEST.MF and
> > recompiling would be good enough.
> >
> 
> I am the last one to claim knowledge about OSGi, so pardon me if I look like
> bluffing here :).
> 
> But from what you said Frank, and what others proposed, I think you don't
> need that kind of modularity facilitated by OSGi or like technologies, I believe
> all what we need then is:
> 
> 1- Good design
> 2- Good documentation about adding new modules/components
> 3- Managing modules/components dependencies using maven for example
> 4- Good code organization to reflect this modularity on code level in the repo
> 
> Which this something we already do at Hippo, my employer, so in our case
> each component is managed in its own SVN repo and  we control which
> versions of which components to package using release poms
> 
> And with some provisioning like ACE can deliver to us we can automate that,
> or even add drivers or provisioners, IDK what they are called, to ACE to
> facilitate deploying diff modules based on that structure
> 
> Or you can use OSGi as a base technology but AFAIK you don't need to use
> everything it provides, which has the advantage that in the future we can
> leverage these features if required
> 
> 
> >
> > > -----Original Message-----
> > > From: Chris Custine [mailto:chris.custine@gmail.com]
> > > Sent: Wednesday, May 30, 2012 11:17 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Proposal to use OSGi for component modularity
> > >
> > > On Wednesday, May 30, 2012 at 12:32 PM, Frank Zhang wrote:
> > > > I have some different thoughts here
> > > >
> > > > > On Tuesday, May 29, 2012 at 10:29 PM, Alex Huang wrote:
> > > > >
> > > > > > CloudStack is built as a product with modularity enforced by
> > > > > > interfaces. It
> > > > > had its own component management via ComponentLocator. While
> > > > > that framework made it easy for a small group of developers to
> > > > > work together, it has outlived its usefulness. Now that we are
> > > > > expecting more developers to join Apache CloudStack, we're
> > > > > looking for the next component framework to scale code
> > > > > development. This framework
> > > needs to manage the following:
> > > > > > - life cycles of the components
> > > > > > - enforce boundaries between components
> > > > > > - easily allow components to be upgraded/downgraded
> > > > > > - database upgrades for the component
> > > > > >
> > > > > > The most successful of such an application is Eclipse, which
> > > > > > uses framework
> > > > > defined by OSGi. We're planning to use that for our component
> > > framework.
> > > > > >
> > > > > > I like to gather opinions about
> > > > > >
> > > > > > 1. Whether to use OSGi or there should be other frameworks to
> > > consider?
> > > > > Personally, I would absolutely love to see osgi explored. We
> > > > > have been using osgi with great success for ServiceMix for
> > > > > several years and have learned volumes about the ins and outs.
> > > > > For a controlled server environment like Cloudstack, I think it
> > > > > would be ideal. There are some learning curves, and some extra
> > > > > work involved, but the
> > rewards
> > > are plenty.
> > > > >
> > > >
> > > >
> > > > First I don't think CloudStack needs to update or remove bundle on
> > > > the
> > fly.
> > > > This feature looks ideal, but considering a cluster management
> > > > nodes, for example four running mgmt nodes, how to propagate
> > > > bundle upgrade on one mgmt node to others? And how to guarantee
> > > > all bundles get working only after all mgmt nodes gets upgraded? I
> > > > don't know if OSGI
> > is
> > > capable of this problem.
> > > > To me runtime upgrade introduces much complexity, at least to
> > CloudStack.
> > > >
> > > >
> > >
> > > Many ways to solve these issues if needed, but if you don't envision
> > applying
> > > runtime updates why be concerned about it?  In either case, this
> > > type of thing is addressed in the osgi spec, specifically parts
> > > regarding service references, bundle lifecycle, and maybe startlevel.
> > >
> > > >
> > > > Second I think the bundle boundary of OSGI is too tiny. I may be
> > > > wrong here, as I am not OSGI expert. I was thinking it is a good
> > > > idea to treat every interface as a service? For example, logging,
> > > > I hope the logging package used by every bundles is linked in it,
> > > > instead of packaging it as a logging bundle. CloudStack should
> > > > focus on its own bundle, like network bundle, storage bundle. As
> > > > CloudStack is a integration project it uses a lot of thirdparty
> > > > libraries, spending
> > too much
> > > time in repackaging libraries I thought should be my linkage
> > > dependency
> > to
> > > OSGI service distracts us from main business.
> > > > I know there are some projects repackaging common java libraries,
> > > > I just simply suspect if it is the best practice for plugin system.
> > > >
> > > >
> > >
> > > As time goes on, more and more projects are packaging jar files as
> > > osgi bundles anyway (things are much better than they were 3 years ago).
> > > However, there are quite a few resources for libraries that are not
> > natively
> > > packaged as osgi such as the servicemix bundle packages
> > > (http://repo1.maven.org/maven2/org/apache/servicemix/bundles/) and
> > > the Springsource enterprise bundle repository
> > > (http://ebr.springsource.com/repository/app/), if all else fails,
> > > there
> > are
> > > some fairly consistent methods for converting jars to bundles using
> > maven.
> > >
> > > >
> > > > And about extender. Now CloudStack itself is responsible for
> > > > loading
> > all
> > > components and starting them.
> > > > As I know in OSGI this is work of extender, does it mean we have
> > > > to write our extender? I know we can use dependency in MANIFEST
> > > > file, but I don't know how it guarantees loading order. To me
> > > > using scattering
> > files
> > > to describe inter-dependency to guarantee loading order makes people
> > > hard to know the exact loading sequence.
> > > > And what I dislike MANIFEST file most is you have to recompile
> > > > every
> > time
> > > you change it.
> > > >
> > > >
> > >
> > > If I understand your concerns correctly, osgi exists as a solution
> > > to
> > these
> > > problems, not to create them.  I think that is why Alex raised the
> > possibility of
> > > using osgi in place of a project specific component model, to lower
> > > the
> > bar
> > > for those wishing to contribute and to expand the community to the
> > > many projects (both inside and outside Apache) using osgi as a
> > > standard component model.  I'm not sure it is worth diving into each
> > > one of your technical issues individually, but I will be happy to do
> > > so if it adds
> > to the
> > > discussion.  Instead, I recommend looking at some of the projects I
> > > mentioned previously for some great examples of osgi adding value
> > > and solving complex issues.  Osgi gives you a standard component
> > > model and related services that are influenced by a diverse range of
> > > requirements,
> > how
> > > and the extent to which you make use of it to assemble your systems
> > > is completely up to you.
> > >
> > > >
> > > > >
> > > > > > 2. If OSGi, whether to use Equinox or Apache Felix?
> > > > >
> > > > > I am biased having been involved with Felix and Karaf for many
> > > > > years, but I would encourage you to look at Karaf and Felix as a
> > > > > base for the container (eplained more below). You will get
> > > > > assistance from within the Apache community by way of Karaf,
> > > > > Felix, and several other projects that also use these frameworks
> > > > > (Geronimo, Camel, Sling, probably many others now) and those
> > > > > projects will mutually benefit from input and contributions via
> Cloudstack.
> > > > >
> > > >
> > > >
> > > > Does Apache have any OSGI runtime to ease developing? I am not
> > > > sure if I use correct notion. I mean something like Eclipse Virgo
> > > > that builds
> > on OSGI
> > > engine.
> > > >
> > > >
> > >
> > > Apache Karaf is a convenient packaging of value added bundles,
> > > services,
> > etc
> > > that sits on top of Apache Felix (OSGi framework implementation) or
> > Equinox.
> > > I think Karaf is what you are looking for.
> > >
> > > >
> > > > >
> > > > > > 3. The tool to help integrate the OSGi framework into tomcat
> > > > > > (Sling?)
> > > > >
> > > > > I recommend considering an inversion of this and instead look at
> > > > > hosting your web server inside the osgi container (or something
> > > > > along these lines). In this way, agents and servers could be
> > > > > modularized similarly. You can certainly use an osgi framework
> > > > > to provide modularity embedded in a standalone java app or
> > > > > Tomcat, but I think you will find a lot of rewards in
> > > > > bootstrapping your jvm
> > with osgi as
> > > a container (see Karaf, ServiceMix et al).
> > > > >
> > > >
> > > >
> > > > I agree. Making CloudStack standalone allows us to integrate with
> > > > other web server like Jetty. However, I know Eclipse Virgo builds
> > > > a Tomcat in its OSGI runtime. However it's based on Spring that
> > > > doesn't
> > fit in
> > > current CloudStack.
> > > >
> > > >
> > >
> > > In Karaf, you can install the Jetty bundle (it is a native osgi
> > > bundle)
> > and deploy
> > > war files that have access to osgi services and bundles.  Karaf also
> > includes
> > > spring dm support (spring osgi extensions) as well as the osgi
> > > blueprint
> > spec,
> > > which is a spec for xml based dependency injection specific to osgi.
> >  The point
> > > of all of this is that you can have all of these coexist at the same
> > time because
> > > they are abstracted by the osgi component model.
> > >
> > > The main point I want to make is that the issues you raise here are
> > > implementation details that will affect you no matter what component
> > > model you choose.  Your choice of component model should be based on
> > > your current and future needs.  Alex has stated the requirements in
> > > the initial email and there are many of us working on other Apache
> > > projects
> > with
> > > the same needs, also using osgi.  As Alex mentioned in his email,
> > adopting a
> > > standard component model such as osgi will help you scale project
> > > development, as well as the community.
> > > >
> > > > >
> > > > > > 4. Anything we can use to upgrade/downgrade database versions?
> > > > >
> > > > > Not exactly sure what you are asking here, but if you mean DB
> > > > > migration, I can;t think of anything osgi related that applies
> > > > > here so I think you will have to roll your own solution.
> > > > >
> > > > > >
> > > > > > Please let me know your feedbacks.
> > > > > >
> > > > > > --Alex
> >
> >
> 
> 
> --
> 
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein

Mime
View raw message