The importance of OSGi
Although OSGi has been around
since 1999, it came to my attention in 2004 when it was used as the
basis of the Eclipse
platform 3.0. Since then, it's become clear that OSGi is one of
the key pieces in Eclipse's modularity and runtime flexibility.
However, Eclipse isn't the only application to be based on OSGi.
More recently, the WebSphere application
server has been reworked to sit on top of the OSGi platform, and
the Spring framework is
undergoing integration with Spring-OSGi. And of
course, all of the RCP Applications
based on Eclipse RCP can take advantage of the dynamic extensible
nature of the underlying platform.
Unfortunately, a successful deployment of an OSGi (or RCP)
application may not be enough to convince others that it is the right
way forward. If the application uses OSGi internally (either for
enforced modularity when developing or to take advantage of the RCP
framework), externally it's still likely to be indistinguishable from
a non-OSGi application. Unless there's some form of external
programming model that others can contribute their own functionality,
there's no significant benefit seen by the end user. As an example,
the fact that WebSphere is based on OSGi is a coup for component based
programming, but it may not be possible to install other OSGi bundles
into WebSphere. On the other hand, Lotus Notes "Hannover" is exactly
the kind of application that would benefit from being able to
externally contribute functions, macros etc. by end users (though one
wonders whether the support in LotusScript would provide that by
default anyway). In short, if you have a well-built RCP application,
how do you convince others the benefits of using that over another
competing technology, such as the NetBeans platform?
You'd think that the future of OSGi is pretty much guaranteed.
There's certainly a lot of drive towards OSGi adoption by the large
players, and of course the existing areas of mobile devices are
already an existing base for OSGi systems. However, there's a few
potential bumps in the road ahead.
For starters, Java 7 is likely to have some form of modularity
built in under the guise of JSR 277. Of course, it
may not end up being delivered as Java 7 but pushed back to Java 8,
but something like this is likely to end up in the Java language in
the future. (Whether people adopt it is another question.) There's
probably a 2-year gap before JSR 277 becomes widespread (and maybe
another year or two before it ends up in enterprise-supported
environments). However, for many people just learning Java in two
years time (for example, the CS graduates of 2010) the core Java will
already have a potentially OSGi-incompatible modularity layer. There's
many areas that OSGi could be used in before this time, but only with
good examples (such as Spring-OSGi) to lead
the way.
Secondly, OSGi needs to be easier to learn for new people in order
for it to be adopted by large swathes of open-source projects. There's
limited projects using OSGi at the moment (there was a nice summary by
Piero
Campanelli recently on open-source OSGi implementations and uses)
-- and partially, that's because there's limited learning
opportunities. However, the submissions for EclipseCon (featuring the OSGi Developer
Conference) this year certainly suggest that OSGi is a hot topic
for the coming future.
Thirdly, the documentation for OSGi needs to be more available.
There's a set of documentation in JavaDoc form in the Eclipse help
pages (or similarly for other OGSi implementations) -- but there's a
separate section for the Eclipse
API and the OSGi
API. Apart from other things, it means that the Eclipse API
documentation can't be built with hyper-links to the OSGi
implementation. Unfortunately, it's also not always possible to
understand what the OSGi specification means from the JavaDoc alone;
for example, org.osgi.framework.Constants#BUNDLE_NATIVECODE_OSNAME
can be used to find out what the OS is for determining which native
libraries to load via a Bundle-NativeCode manifest entry.
But there's no documentation on the internet that suggests what the
valid values for Bundle-NativeCode can take for the os
property.
Of course, you can (and should) download the OSGi
specifications, which tell you that the OS can take values such as
WindowsXP, WinXP and so on. However, you
have to submit a request before you're told where the PDF documents
are (though someone ended up posting a reference to the r4.core.pdf on
an archived mail newsgroup recently which turns up on a quick google
search if you don't want to send your e-mail address).
Really, if you want a technology to be adopted, make information
about it freely available; don't expect that people will give you
their e-mail address just to find out about it.
Lastly, there needs to be a lot of good (and varied) examples of
OSGi being used for building dynamic systems. At the moment, it's just
seen as the basis of Eclipse (and thus automatically shunned by
IntelliJ and NetBeans users), or for server-side J2EE/Web-based
systems. There's more to the server-side than web-based applications;
but, go to the
Server-Side equinox and you could be forgiven for thinking that
HTTP is the only use to which this technology applies. I even
submitted a tutorial proposal for OSGi on
the server-side not using HTTP/Web/AJAX, and it was
rejected in favour of building
server-side web applications, for 'being too similar'.
Fortunately, at EclipseZone,
we've got a few articles lined up discussing the Eclipse platform and
OSGi for non-web applications.
OSGi has been chosen by a number of important decision makers, and
a number of key projects. But in order for it to capture the interest
of the wider Java community, it's got to be made more accessible and
easier to quantify the benefits of why your next system should be
implemented on top of OSGi.
Until Next Time,
Alex Blewitt
alex@eclipsezone.com
| 
Join the Battle Against Bad Java Code
EZ News Corner
Find cool Eclipse plug-ins at Eclipse Plug-in Central
