I came back last Thursday evening from the OSGi Enterprise Expert Group meeting hosted by IBM in Boca Raton for the IONA (internal) services summit, where I had the privilege of assisting in the award to Adrian Trenaman of his promotion to Distinguished Consultant. It was quite a moment for the IONA services team and for Ade as well I think.
Yes, we really met in the Ozzie Osborne Conference Room – but it’s not named after “Ozzy”
And then on to the annual sales kickoff, where I gave a presentation about big picture industry trends (largely based on what I learned at HPTS), where we fit, and how we’re going to incorporate innovation into our product planning process. Fittingly, Ade is a part of the new technical vision team we started last August for that purpose. So he was a significant part of both events. Well done, Ade! (see also his interesting discussion last year with Ted Neward at the Server Side on contract-first)
Anyway getting back to the meeting, a lot of the discussion concerned the metadata design for the distributed OSGi proposal. Among the major requirements for enterprise OSGi is distribution – meaning the ability of an OSGi service running in one JVM to invoke a service running in a JVM in another address space, as well as the ability for an OSGi service to invoke a service running in another distributed computing environment and vice versa (i.e. accept a service invocation from another distributed computing environment).
We had agreed at an earlier meeting to try to reuse as much metadata from SCA as possible, given that SCA had already solved many of the same problems. However there are also significant differences between SCA and OSGi, especially in terms of the development environment and the differing assumptions around dynamic vs. static wiring. It should be possible in OSGi for example to have a client invoke a service that is dynamically provisioned. And finally, the design center of SCA is assembling services and attaching policies to them in a way that should be language and runtime independent. OSGi’s design center is around solving specific deployment, modularity, and dynamic lifecycle issues with binary Java files.
One of the larger context debates in this area was called “XML vs properties” and I think we came up with a great kind of middle ground in which you can use properties for simple distributed computing configurations and “call out” via URL to a more complex XML file when necessary. We are still working on the proposal but we are planning to start a reference implementation soon using ServiceMix, and through that process refine the proposal further.
During the meeting we also got a great demo from Adrian Colyer of dynamic Spring (aka Spring-OSGi). His spec is really well organized, clean, and reads really well. I am pretty envious of that, although as Hal Hildebrand pointed out, the Spring-OSGi work is by now much better known territory, and the document is more a reflection of reality than an unproven design (it is still early days with distributed OSGi, that’s for sure).
We also spent a good bit of time discussing the proposal for an optional discovery service that should allow any existing discovery mechanism to be included into the distributed environment. For that matter, it’s worth emphasizing (since this seems to be fairly consistently misinterpreted or misunderstood) that we are not proposing to invent any new distributed computing mechanism. The goal is rather to define how any distributed computing mechanism could be configured and deployed into an OSGi platform – and hopefully even define some metadata sufficient for using more than one successfully in combination (i.e. interoperability among supported distributed computing mechanisms).
Neither is the goal to choose or favor any distributed computing mechanism over another – we should be able to support on a fairly (if not totally) equal basis mechanisms such as RMI, RMI/IIOP, SOAP, JINI, SCA, JBI, J2EE, JAX-WS, CORBA, JMS, etc.
Another important part of the EEG activity is coordination with Eclipse and the Equinox project, which is an implementation of OSGi SP R4. Other open source and commercial implementations of R4 exist (see Apache Felix and this list of certified products), and representatives of most of them participate in the EEG, but Eclipse has recently started moving toward the runtime space.
After the Runtime Summit Jeff mentions in his blog, I sat and talked with
Cote of Red Monk about what’s going on. The OSGi folks saw this and told me that the statement about “OSGi being the only other organization legally allowed to create Java specifications” is a bit broad. (Perhaps someone just told me something along those lines when trying to recruit IONA to join .
Anyway now that I’m on the Board I’ve been able to get a look at the actual paperwork – the agreement between Sun and OSGi that allowed the OSGi Alliance to be formed to progress JSR 8 outside of the JCP. I can’t quote from it, but what I can say is that it is somewhat ambiguous. Saying what I did is probably a bit of a stretch. It is more accurate to say the OSGi Alliance is allowed to progress that original JSR and related work.
For the record, IBM has built a new facility in Boca Raton, which is where the meeting actually was held:
And here’s a photo taken right outside the entrance, which is around to the rear of the building.
Ahhh, Florida. I was scheduled to go back there yesterday after the kickoff presentation (which was Sunday morning), but the snow storm caused Florida flight cancellations (Jet Blue, I still love you) and I ended up driving home through the worst of it. Yes! I can still drive in the snow! I ended up joining the meeting by phone, but I missed getting back down to those balmy breezes, palm trees, and fluffy white clouds.
The drive home yesterday did not look like this.