OSGi for the Enterprise – update

One of the great things about co-chairing the OSGi EEG is getting to work with guys like Adrian Colyer, who was interviewed on InfoQ recently about Spring-OSGi. This is a very interesting interview, especially if you are, like me, interested in understanding the proposed Spring-OSGi marriage better.
Adrian is a great guy and really sharp, and he is also a great contributor to the EEG – and he is by no means alone in that category by the way. We are really lucky to have a great EG, and fortunate to have Adrian’s help editing the Spring-OSGi Request for Proposal (RFP).
I do have a small issue with Adrian’s portrayal of Spring and OSGi, however, and I would guess he’s probably familiar with it from some of the things I’ve said during the meetings. Basically Adrian makes it sound like Spring and OSGi can (or will) do everything anyone needs.
As my colleague David Bosschaert says, this is a bit like saying you can do everything in Java, since it basically amounts to being about to develop a new application to do anything you want in any given programming language. Sure, the combination of Spring and OSGi is very powerful, and great stuff, but I hope it’s clear by now that we are all living in a heterogeneous world, and one in which interworking is essential.
Spring and OSGi is an important part, but just one part of the overall picture. One of the really big benefits of OSGi is that it’s capable of supporting multiple programming models.
I am sure that Adrian did not intend to imply otherwise, but I just wanted to highlight it, in no small part because the RFP I’m editing includes the requirements for interworking with existing and non-OSGi systems (which may of course also be non-Spring systems).
If you want to find out more about OSGi overall check the Website and consider attending the upcoming OSGi Community Event in Munich. Hope to see you there!
The next EEG meeting actually takes place the day after the community event (June 28), where I hope my co-chair Tim Diekmann and I will be able to send off for approval the majority of the RFPs we’ve all been working on.
In OSGi the Expert Groups first create requirements documents, then move to the design phase, then to the specification phase, and finally to the reference implementation and conformance test kit phase. So I am hoping we can close out the requirements phase soon, and start on the really fun design discussions!
We have recieved about 15 RFPs so far (some have been combined), including the Spring-OSGi RFP that Adrian edited and the external systems RFP David and I edited, and RFPs for mapping various parts of JEE to OSGi (such as naming, database access, RMI, etc.), SCA to OSGi mapping (mostly to be done by the SCA community we hope), a distributed registry, database access, how to run system developed components (i.e. parts of JEE) alongside application developed components. marshaling and classloading, Web application support for the enterprise, management, and “universal” or multilanguage OSGi.
Stay tuned!

Advertisements

One response to “OSGi for the Enterprise – update

  1. OSGi takes on Server Side Java and SOA.

    You could say those behind Java server-side strategies were ‘asking for it’, and developers along with companies using server-side Java were begging for it! A coherent strategy for making sense and working out the hundreds of fragmented — and on…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s