Software Everywhere — David Beers on Mobile Computing

BoyGeniusReport has leaked some screenshots of someone using what looks like the Palm webOS SDK, complete with revealing console output. (You should know that a normal person looking at that gallery would be admiring at all the pretty UI pictures, of which there are many, but I'm most fascinated with the debug console.) The console shows the JavaScript code making requests using a "luna://" protocol to a Jetty web application server running locally, which in turn uses file I/O to access files with .json extensions in a Linux-like file system. It's not a sure thing I suppose, but it's a pretty darned good bet that we're seeing something very close to what happens when a webOS application is running on a real device like the Pre smartphone. If that's the case we've learned quite a bit, and can guess even a bit more.

First, at least as far as the application framework is concerned, the software on a Pre looks an awful lot like a Linux web server and nothing at all like Android, ALP or any other Linux-based mobile platform we've seen. Second, the server code that is running in the development environment is Jetty, which is Java. That makes sense from the standpoint of enabling developers to use Mac or Windows workstations but maybe there's a native C/C++ server running on the actual device. I doubt it. I say there's a Java app server running on the phone, too, inside a nice Java runtime. Why?

Well first, why not? Java is secure, stable, runs on all kinds of processors and OSes, including x86 PCs and Macs and a billion or so mobile phones. Palm didn't have time to mess around with porting or reinventing the wheel. Second, as I pointed out back in Sept '07 when the Foleo was cancelled, Palm was hiring Java engineers for...

implementation of Java based mobile system software on new product development project. Responsible for all mobile development (design through implementation and release), working with other device engineers and design lead on overall system architecture and design.

There have also been ads for Java web services engineers, but ads like the one above told me to expect that Palm's new Linux system would be "Java based." And I'm more sure than ever now that it is.

Here's what else we know: it's not a J2ME MIDP environment on the Pre like the ones on most other phones. To run an application server it's at least a CDC environment with Foundation Profile, which means it's pretty beefy and has a lot of the power of the underlying Linux system available to it. That doesn't necessarily mean that Palm will be letting 3rd parties write applications that run in the Java runtime as opposed to WebKit, but they certainly could.

This is where I get really intrigued, though. See, Palm's first carrier partner is Sprint. Sprint has been on the forefront of an idea to make mobile devices first class citizens on the web by enabling them to run "desktop class" software. The way they are doing this is through a platform they call Titan released just last month. Titan puts a powerful Java environment together with a technology called OSGi, which is the special sauce. It's a service platform that enables developers to create software by plugging together software components. For example, Sprint's Titan platform includes a web server module to enable iPhone-like widgets (hmmm). Because the server is running inside the OSGi container, widgets can interoperate with other components in the container: components for GPS location, messaging, multimedia, etc (hmmmm!).

The novel service-oriented architecture of webOS bears more than a passing resemblance to Titan. And I can't think of a better way for Palm to have put it all together than with OSGi, just as Sprint did. Loyal readers know I've been waiting years for OSGi to go mainstream on mobile phones. There are so many good reasons, for it, especially for Palm:

• OSGi fixes some unfortunate limitations of Java ME: incompatibility with standard Java packages, no shared libraries, no long-running services, no loading of classes that weren't installed with the app, no intercommunication between applications, no app updates without reinstalling the entire application, etc. Seems like half the places you think there should be a door there's a blank wall.
• OSGi also solves many of the problems that motivated these limitations in the first place, mostly having to do with challenges of delivering high reliability, manageability and security in an open component-based platform, long a sort of holy grail for software development
• OSGi is designed for remote management. It would be ideal for performing firmware, software, or configuration updates over-the-air. Such updates could originate from Palm, from a carrier wanting to deploy a new service or app, a third party developer, or possibly an enterprise customer wanting to update an application or setting across all their users. This capability would give Palm one of the advantages that RIM has traditionally held in the smartphone market.
• OSGi is ideal for delivering the same service with the same code across multiple platforms. If Palm is serious about delivering web services and plans to keep their Windows Mobile smartphone line they can reuse the Java service components they develop for the Pre on their WinMo phones. This can be true even when OS-specific native resources are involved. For example there is a powerful framework called RCP for creating Java GUI applications that can run on Windows Mobile, desktop Windows, Mac OS or Linux--all with a native UI provided by the underlying system. RCP and OSGi are the technologies that enable the Eclipse development environment to run fast with native look-and-feel on Windows, Mac and Linux desktops. Let me be clear here: It's totally feasible with OSGi under the hood for webOS applications and any special services that Palm develops for the Pre to also run on Windows Mobile, and that Java apps with native Windows Mobile GUIs could be developed using RCP that leverage the identical service software. I'd think that would be a pretty compelling proposition for Palm.
• OSGi makes Android's IPC-based component model look slow, weak and restrictive. OSGi communicates with its bundles by ordinary method calls, a much better way to enable the kind of mash-ups that have made Android attractive to developers.
• OSGi is a mature, open standard with strong industry backing, a sizable catalog of mostly free plug-ins, and considerable buzz among developers

So what to make of this? Has Palm jumped on the OSGi train? There's no way to really know at this point. All I really know is that if I were going to develop a system like webOS I would certainly use OSGi, and that some pretty smart guys I know at Sprint (and Nokia, by the way) came to the same conclusion. Keep in mind, if Palm is packing some OSGi goodness it doesn't mean it will all be open to developers when the first SDK is released. If they allow third party Java components at all there will likely be a digital signing requirement. But the day an SDK is available for Java as well as JavaScript developers, and we can target both webOS and Windows Mobile smartphones, Palm will be in a superb position to build a developer ecosystem that draws deeply and broadly on the talent that powers Web 2.0 today.

Oh, and I'll be there, too, heh. With bells on.