URL:
http://www.infoq.com/news/2007/05/osgi-javame
The 2007 JavaOne conference reflected the fact that mobile
computing—for both consumers and enterprise workers—is transitioning
from early adoption to the mass market. But Java ME developers still
face many obstacles that server-side or desktop Java developers never
have to contend with. Those issues include:
- fragmentation of the Java ME platform
- the absence of mobile runtime environments that adequately leverage the capabilities of advanced "smartphone" devices
- the difficulty of managing mobile applications and configurations once the device has left the building
- the
architectural chasm that separates common Java web development skills
and APIs from the specialized rich client practices employed when
developing for mobile devices.
Nokia, Sprint, and IBM teamed for a JavaOne session that outlined a
solution to these problems through an service-oriented architecture
based on OSGi. OSGi was originally developed for telematics
applications where remote management, pluggability, and "hot" software
and firmware updates (no restarts) were required. As mobile handsets
increasingly are used as always-on application platforms, and
particularly as carriers and developers start to grapple with how to
bring some of the dynamism of loosely coupled component architectures
to the currently static mobile Java environment, handsets become a vast
new frontier for OSGi.
The specification for the standard under which this work is taking place is JSR 232: Mobile Operational Management.
As Jon Bostrom, Chief Java Architect for Mobile Software at Nokia put
it, the vision for this is based on the Web 2.0 principle of
"innovation in assembly": to bring a open component model in which
services built into the platform can be plugged together with others
provided by developers in a flexible, but highly manageable manner.
OSGi turns the device into an OS agnostic application server in your
pocket. It enables new components to be delivered on the fly, manages
their lifecycle and permissions, and provides a shared event bus as
well as services like monitoring and logging. In fact, since OSGi
includes a servlet container, OSGi bundles (pluggable components) don't
necessarily have to be written as Java ME applications—they can be
standard servlets living on the edge of the network.
From this broad vision different participants in the JSR 232
working group seem to be moving in somewhat different directions. For
Nokia, for example, the idea is to create a "mobile innovation engine"
that promotes mobile mashups. These will not just be mashups of web
services that we're familiar with today. They could include components
like alternative GUI rendering engines that enable easy ports from
other platforms, for example. Mobile Java developers have long been
constrained by the limited UI toolkit that CLDC/MIDP provides. On a
device with JSR 232 they will have a much more powerful CDC/FP runtime
and class libraries to work with, making AGUI and Swing GUIs a
possibility, a well as the embedded versions of SWT and the Eclipse Rich Client Platform (eRCP).
According to Bostrom there is no reason that engines like
ActionScript/Flash, OpenLaszlo or Flex/Apollo could not be plugged in
as well. Most importantly, the developer doesn't need to wait for the
Java Community Process or device manufacturers to bring these
components to the handset: once wrapped into an OSGi bundle they can be
installed to the device over the air and registered as a service, much
like an Eclipse plugin is installed via Update Manager. In fact, OSGi
is the technology that makes this possible in Eclipse without having to
restart the workbench after the installation. This should be a very
exciting prospect for mobile developers.
For IBM, having a server in your pocket suggests an ever broader
view: what IBM Distinguished Engineer Jim Colson called a "symmetric
portal model." Here OSGi enables service layers that literally span
everything from sensors, to smartphones, laptops and desktops and in
each case these services are accessed via familiar technologies like
JMS and servlets. That unified architecture has several advantages.
Obviously, it opens up mobile devices to a very large group of
developers with skills that are common in enterprise IT departments. It
also addresses a problem that has hindered the use of standard web
technologies on devices: the limited coverage and high latency of
wireless networks. In IBM's OSGi-based Lotus Expeditor
managed client software an application can be run client/server even in
disconnected mode. IBM considers Lotus Expeditor to be an "open
alternative to .NET" that spans Windows, Windows Mobile, Nokia S60 and
Mac OS. Just like Nokia's mobile OSGi implementation, IBM's enables
rich client apps using pluggable GUI libraries and encourages
development by composition. But the business proposition is extending
existing SOA technologies "beyond the data center to people, places and
things."
OSGi opens the door to a more dynamic mobile Java environment, and
states that this together with OSGi services like configuration,
monitoring and conditional privileges "provide a lot of the features
that I think we need to make CDC usable." But it also raises questions
that will need to be resolved by the JCP in specifications such as JSR
249, Advanced Mobile Service Architecture. Komsi explains:
On a high level, JSR 249 has to find solutions for key
features like the primary installation mechanism, the application
model, and the packaging model—how to package those applications and
middleware components so that you can send them to handsets.
Additionally, JSR 249 needs to find a solution for managing the
environment and the applications and services running on it. In the
future you will also have powerful client environments that will allow
you to run multiple applications. So we also need to define an
application cooperation mechanism. These are features for which we have
to find a solution in JSR 249. If we don't have them, then we're only
half done, and we might be faced with fragmentation once again.
But Nokia is not waiting any longer to get OSGi into your mobile.
They have teamed up with Sprint to develop a JSR 232 implementation
they call the Titan platform that will be shipping very soon. Brandon
Annan, Manager of Software Platforms for Sprint's 3G Customer Equipment
group, predicted a "Golden Age of mobile Java technology" that would
begin in the 4th quarter of this year with the launch of three or four
Titan-enabled "PDAs" (presumably with EVDO radios). JSR 232 handsets
will follow in mid-2008. Sprint's 4G product division is also
"seriously considering" JSR 232 for the WiMax devices they will be
releasing for that eagerly anticipated network rollout. Outside of
Sprint the upcoming Nokia E90 handset will also be shipping to the
European market with OSGi and eRCP on board. Whether this premium
smartphone sees North American shores is not yet clear.
Mobile Java developers that can't wait til later this year can
start deploying applications on CDC and OSGi today, but they need to
choose devices with open operating systems like Windows Mobile and
Linux. Brian Coughlin, the Senior Technology Strategist for Sprint's 4G
group put together an OSGi mobile mashup demo on the Nokia N800
Internet Tablet, for example, a Linux device for which Nokia has
suggested there will be a WiMax version.
Developers can get a CDC Java runtime for the N800 and the other
components, including an Equinox OSGi implementation and the mashup
servlet bundle here.