Software Everywhere — David Beers on Mobile Computing

I was an Economics grad student at George Mason University twenty years ago when Brad Cox was there making the idea of software components famous. He called them Software ICs and envisioned vibrant markets for pluggable software components that would enable vastly more complex and less costly systems to be designed, much as IC chips did for digital circuitry. Object oriented design got us part of the way there, but only today are we really beginning to see this vision come to life. Web 2.0 service platforms from Google, Amazon and Yahoo are fostering a new market for "mashups." The Eclipse platform, with its many hundreds of plugins, is one of the best examples today of what Cox envisioned, although developers are only beginning to catch on to the possibilities of using the Eclipse RCP framework as a service architecture for general application development. These open, service-oriented architectures support truly reusable, network deployable software components that enable applications to be assembled at Internet speed.

But what about mobile software development? When a mobile platform standard is announced it can takes years before the devices implementing the standard are released, then months more for the channel to fill and volume to build. And with a multiplicity of standards and incompatible implementations (MIDP anyone?) writing applications against all these static yet changing APIs (S60 anyone?) is sometimes scarcely worth the effort. The platforms can't evolve faster because their applications are tightly coupled to them. And even when API changes don't break them (Palm OS anyone?) most mobile platforms today don't commend themselves to the loosely coupled, multi-tier designs that are easiest to maintain and evolve. We live with it, but it's a world of pain for the platform architect and application developer alike.

It looks like this is about to change. I wrote last week about how Eclipse eRCP will bring live, on-the-fly software component updates and a loosely coupled component model to mobile devices. JSR 232 (Mobile Operational Management) will take this a step further, creating Java environments on mobile phones that can update components of the system as well as push new, discoverable services over the air for developers to take advantage of--immediately. Many of these services--HTTP, user authorization, permissions, logging, XML parsing, network I/O, to name a few--are ones that can eliminate days of repetitive coding by developers. Others can be 3rd party bundles (plugins) that provide higher levels features like messaging, network presence, mapping or PIM and expose these as reusable services that other plugins can weave into themselves. Once JSR 232 handsets hit the market, an era of mobile mash-ups will begin, combining Web 2.0 services on the network with pluggable component services on the device.

Java ME has been too tightly sandboxed for too long, allowing applications little clue as to whether they were running on a two-way pager or a Treo 650. But the work that Nokia, OSGi, IBM, and Motorola are doing right now on mobile Java is starting to make it look like a platform that could rival the power of native application frameworks--and maybe exceed them in ease of application deployment, manageability and security. Like eRCP, JSR 232 requires a CDC/Foundation Profile Java environment, more full-fledged than the MIDP VMs found on most phones today--a significant rub, to be sure. But MIDP 3 will be JSR 232 compliant. And there are new OSGi-compliant platforms like ProSyst that run on existing MIDP phones and deliver many of the same advantages I've described.

The next couple of years are going to be exciting times to be a mobile Java developer!