[long] OSGi overview (was Re: Geronimo/Equinox integration status?)

[toby cabot <to...@caboteria.org>]

Jacek,

Thanks for the info.

On Wed, Jul 05, 2006 at 10:06:46PM +0200, Jacek Laskowski wrote:
> On 7/5/06, toby cabot <to...@caboteria.org> wrote:
> >What's the status of the Geronimo/Equinox (OSGi server) integration?
> 
> Dunno, but great you've asked as it was one of the questions during
> the Apache Geronimo panel at TSSJS in Barcelona, which James S.
> answered positively, i.e. there's a fit for it in Geronimo and it
> should or will be soon available. I think Dain mentioned it a couple
> of times (it was something about classloading architecture or alike).

That's great to hear.  I'd be willing to help out.

> I wonder how it's different from what we've got now? How does it
> compare to XBean if at all? A short introduction would be of help.

I'm far from an OSGi expert, but let me take a swing.  Either I'll be
correct or someone will correct me, and either way we'll learn
something.  OSGi [1] is both an organization and a specification.  The
spec [2], currently at release 4 and weighing in at >260 pages,
describes what they call a "service platform" [3] which really amounts
to an application server.  It's somewhat analogous to GBeans in that
it specifies the interface between application components and the
server that runs them.  It's much smaller and less featureful than
J2EE, having been originally intended (and still used often) for
embedded systems.  The spec has been around for quite some time but
seems to be gaining a lot more mindshare recently.  Probably a big
part of that is due to the Eclipse project using OSGi technology
inside their IDE.

The basic OSGi software package is called a "bundle".  A bundle is
basically a jar file + metadata.  The metadata indicates which
"services" a bundle exports and which it depends on; this allows a
server to do automatic dependency resolution, so if you ask it to
download a particular bundle from a remote bundle server it can first
download and start all of the dependencies automatically.  There's
also a JNDI-ish "registry" within an OSGi server that allows bundles
to find services and bind to them at run-time.

So I guess you can say that a bundle is somewhere between a GBean and
a Configuration, but closer a GBean plus some additional packaging.
Within Eclipse, the things that Eclipse calls "plugins" are basically
OSGi bundles with some additional Eclipse metadata.

>From my admittedly naive perspective, I don't see huge differences
between bundles and GBeans, but I wouldn't be surprised if they were
there.  So far I've seen two integration approaches mentioned -
OSGi-centric and Geronimo-centric.  The OSGi-centric approach [4]
involves taking the various Geronimo services, repackaging them as
bundles, and running them in an OSGi server.  The Geronimo-centric
approach [5] involves building a GBean wrapper around bundles and
services, so the GBean server can manage them.  In either case I think
that having the ability to run J2EE apps *and* OSGi bundles is very
powerful.

My interest in OSGi technology stems from the fact that my employer
uses Geronimo currently but is planning to also support OSGi, so my
best-case scenario is a nice integration between the two technologies.

Thanks,
Toby

[1] http://www.osgi.org
[2] Specs are "by-request" at http://www.osgi.org/osgi_technology/download_specs.asp?section=2
[3] http://www.osgi.org/osgi_technology/index.asp?section=2
[4] http://www.mail-archive.com/dev@geronimo.apache.org/msg10923.html
[5] http://www.mail-archive.com/dev@geronimo.apache.org/msg10822.html

Re: OSGi overview (was Re: Geronimo/Equinox integration status?)

[toby cabot <to...@caboteria.org>]

Hi Jacek,

On Fri, Jul 07, 2006 at 10:22:34PM +0200, Jacek Laskowski wrote:
> Would you point out another short introductory material about it or
> just suggest I'll simply take a look at the spec to get the gist of
> it?

The spec is big, too big for my bleary eyes to read on-screen, and yet
I feel guilty printing it out.  I'd start at this web page [1], and
then if you're still curious try this 17pp whitepaper [2], only then
the full spec.

Looking at it from a different persective, there's a brief tutorial
showing how to write a simple bundle [3], provided by the Oscar OSGi
folks.  Part of it uses their "Gravity" framework and as such isn't
strictly OSGi, but it looks as if they've left that part 'till the
end.

Toby

[1] http://osgi.org/osgi_technology/index.asp?section=2
[2] http://osgi.org/documents/osgi_technology/osgi-sp-overview.pdf
[3] http://oscar-osgi.sourceforge.net/tutorial/

Re: [long] OSGi overview (was Re: Geronimo/Equinox integration status?)

[Jacek Laskowski <ja...@laskowski.net.pl>]

Hi Toby,

Thanks for the gentle introduction to OSGi. It's the shortest yet very
informative description of OSGi I could read and really enjoyed it.
Much appreciated.

Would you point out another short introductory material about it or
just suggest I'll simply take a look at the spec to get the gist of
it?

Jacek

On 7/7/06, toby cabot <to...@caboteria.org> wrote:
> Jacek,
>
> Thanks for the info.
>
> On Wed, Jul 05, 2006 at 10:06:46PM +0200, Jacek Laskowski wrote:
> > On 7/5/06, toby cabot <to...@caboteria.org> wrote:
> > >What's the status of the Geronimo/Equinox (OSGi server) integration?
> >
> > Dunno, but great you've asked as it was one of the questions during
> > the Apache Geronimo panel at TSSJS in Barcelona, which James S.
> > answered positively, i.e. there's a fit for it in Geronimo and it
> > should or will be soon available. I think Dain mentioned it a couple
> > of times (it was something about classloading architecture or alike).
>
> That's great to hear.  I'd be willing to help out.
>
> > I wonder how it's different from what we've got now? How does it
> > compare to XBean if at all? A short introduction would be of help.
>
> I'm far from an OSGi expert, but let me take a swing.  Either I'll be
> correct or someone will correct me, and either way we'll learn
> something.  OSGi [1] is both an organization and a specification.  The
> spec [2], currently at release 4 and weighing in at >260 pages,
> describes what they call a "service platform" [3] which really amounts
> to an application server.  It's somewhat analogous to GBeans in that
> it specifies the interface between application components and the
> server that runs them.  It's much smaller and less featureful than
> J2EE, having been originally intended (and still used often) for
> embedded systems.  The spec has been around for quite some time but
> seems to be gaining a lot more mindshare recently.  Probably a big
> part of that is due to the Eclipse project using OSGi technology
> inside their IDE.
>
> The basic OSGi software package is called a "bundle".  A bundle is
> basically a jar file + metadata.  The metadata indicates which
> "services" a bundle exports and which it depends on; this allows a
> server to do automatic dependency resolution, so if you ask it to
> download a particular bundle from a remote bundle server it can first
> download and start all of the dependencies automatically.  There's
> also a JNDI-ish "registry" within an OSGi server that allows bundles
> to find services and bind to them at run-time.
>
> So I guess you can say that a bundle is somewhere between a GBean and
> a Configuration, but closer a GBean plus some additional packaging.
> Within Eclipse, the things that Eclipse calls "plugins" are basically
> OSGi bundles with some additional Eclipse metadata.
>
> From my admittedly naive perspective, I don't see huge differences
> between bundles and GBeans, but I wouldn't be surprised if they were
> there.  So far I've seen two integration approaches mentioned -
> OSGi-centric and Geronimo-centric.  The OSGi-centric approach [4]
> involves taking the various Geronimo services, repackaging them as
> bundles, and running them in an OSGi server.  The Geronimo-centric
> approach [5] involves building a GBean wrapper around bundles and
> services, so the GBean server can manage them.  In either case I think
> that having the ability to run J2EE apps *and* OSGi bundles is very
> powerful.
>
> My interest in OSGi technology stems from the fact that my employer
> uses Geronimo currently but is planning to also support OSGi, so my
> best-case scenario is a nice integration between the two technologies.
>
> Thanks,
> Toby
>
> [1] http://www.osgi.org
> [2] Specs are "by-request" at http://www.osgi.org/osgi_technology/download_specs.asp?section=2
> [3] http://www.osgi.org/osgi_technology/index.asp?section=2
> [4] http://www.mail-archive.com/dev@geronimo.apache.org/msg10923.html
> [5] http://www.mail-archive.com/dev@geronimo.apache.org/msg10822.html
>


-- 
Jacek Laskowski
http://www.laskowski.net.pl