Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Is OSGi the Solution for Mobile Java?

Is OSGi the Solution for Mobile Java?

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 Nokia's Asko Komsi 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.

Rate this Article