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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
