The OSGi Framework
The JSR 232 Mobile Operational Management Java specification caught the attention of many at JavaOne 2007. A great set of blog post/essays by David Beers on this topic:
This is followed by Anders Borg:
And Ove Nordström:
I look back at the evolution of OSGi… when it was first introduced by the OSGi Alliance, I guess it was around 1998, as a platform for the management of services running on distributed connected computing devices such as Internet Appliances (gateways) — those were the days when the tech word of the day was "internet gateway" (and those were the days of HomeiPliance, a venture I started back then). OSGi went silent after that. OSGi is pretty big inside IBM, where it is leveraged quite a bit within their management products, via the Eclipse Equinox OSGi implementation (which I believe is based on code that was initially donated by IBM). More recently, the OSGi Mobile Expert Group (MEG) and the JCP worked together, submitting OSGi R4 Service Platform Core Specification plus OSGi Service Platform Mobile Specification as JSR 232 Mobile Operational Management (MOM) specification.
Management vs. Fragmentation
When it comes to JSR 232 MOM, I see 2 camps of individuals:
- OSGi for the purpose of addressing fragmentation issues, and/or,
- For providing a management framework of services on handsets
But OSGi is not about fixing fragmentation directly, but it is about management… I guess the point with respect to fragmentation, is that in theory, with OSGi, missing APIs could be delivered to the handset, minimizing API fragmentation. But I'm not sure that will be the case.
OSGi was created for (the management of) services or components – this is, for the distribution, and life-cycle management, including ways to register, start, stop, and listening for services-related events. The framework provides a service-oriented architecture. The framework provides a method that helps service providers and device "owners" (such as carriers) with the means to manage the handsets and their software content while on the field, resulting in better user experience, and handsets can be updated and serviced on the field. This of course means the handsets are Java-based on the first place.
And my question is
So, for a while I've been trying to understand why JSR 232 EG has been pushing MOM mainly to CDC-profiles… IBM is pushing in that direction, Nokia is as well, some at Motorola too. One of the components missing from MIDP environments is a component/service management framework; even for such lower-end handsets that are based on MIDP, a robust (Java-based) management framework is needed. And while I don't see anything on the specification itself that precludes OSGi/CLDC-based profile combination, the push for CDC-only MOM is clear. Is MOM being pushed/leverage to force others to CDC? Or is there a true technical reason? Maybe I'm missing something here.
While I agree that as we move forward over time that handsets will continue to become more powerful, and the CDC-based profiles are a more complete (robust) Java platform when compared to MIDP/CLDC, note that more is not necessarily better, especially on embedded devices such as the mobile handset. Let's not forget about the lower-end MIDP-based handsets, which will continue to be the major Java platform for years to come, and is one that is missing a management framework.
Who will have the power?
The carrier will own how and who will be able to push and query handsets… As a 3rd party developer, are we any better with OSGi Mobile? Time will tell.
- JSR 232 MOM is for component/service management.
- MSA for API fragmentation.
- The combination of MOM (JSR 232) and MSA (JSR 248 and 249), with MIDP3, is the next (sweet) step
- MIDP3 provides a migration path to CDC; MIDP will remain for years. A management framework for MIDP would be useful.
- MSA will continue to evolve, with new JSRs, over time.