cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <mn...@apache.org>
Subject Re: Proposal to use OSGi for component modularity
Date Thu, 31 May 2012 18:36:29 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message