Yesterday I had the pleasure to speak at the droidcon in Berlin. It was a remarkable conference, a lot of interesting people & talks, well organized, lots of fun. As the event name suggests, it was all about Android.
Guess what I was talking about? ;-) Here's the abstract of my story:
Android is a platform the developer community can create innovative mobile applications for. However, much of the community's creativity and power remains untapped. Why? There are barriers for developers to contribute to the platform. First, the Android project is solely and rigidly controlled by Google. Second, the Android application & distribution model is designed to have 3rd parties create apps, not APIs or middleware. This presentations discusses these limitations and presents the concept of OSGi, an Open Services & Middleware Platform as an enabler for 3rd party platform innovation.
Most of my recent blogs are focusing on what you could do with Mobile OSGi. Today I deliver a real practical example for OSGi - in my opinion a pretty exciting case. My colleague Gábor Pécsy has written a first prototype of a DLNA (Digital Living Network Alliance) Media Server that runs on OSGi on various mobile platforms such as Android and Windows Mobile.
For those who are less familiar with DLNA, let me give you a short intro. DLNA is an industry alliance that developed a number of specifications purposed to standardize the interplay of media devices. There are several types of media devices defined such as Digital Media Server, Digital Media Player, Digital Media Controller, etc. As you can imagine, a Media Server is a network instances that serves media content like pictures, videos or music. Likewise, Media Players are devices capable of playing back media content served from Media Servers. The nice thing about DLNA is that devices automatically find each other in the network without the user to be bothered with configuration issues, setting IP addresses, etc. It's a true hot plugging architecture (which is because DLNA is build over UPnP). If you have a Media Player, like a Sony Playstation 3, a Microsoft Xbox, DLNA enabled TV sets, etc. and put a media server to the network, the players will find the server without further doing.
What we did is implementing parts of the DLNA Digital Media Server specification that runs on mobile phones. The use case is that you generate content while you're on the go (i.e. taking pictures or videos) and play that content back on your bigger home screens like the TV or picture frame. Watch this video to get a live demo on how the Sony Playstation and a picture frame plays back your pictures from your phone:
The current version of the Media Server is entirely headless, that's why you don't see any UI on the phone. Future versions of this app will contain a UI on which you can set the server name, your content sharing policies, etc.
Let's zoom into technology. An interesting aspect about this solution is portability. The media server is implemented in Java and on OSGi, thus it is portable over all handsets that support OSGi. Moreover, it leverages the UPnP Service defined in the OSGi Compendium Specification giving it a clean a lean design. Here's a little diagram about the internals of the server: The Media Server is both network and device agnostic and thus easily portable. It pulls media content though the Media Manager Service. This service we created to abstract media access. The Media Manager Implementation is platform specific. In case of Windows Mobile or Brew the MM Implementation fetches Media Content from the local file system. The target folders are configurable through the OSGi Configuration Admin API which makes this implementation portable. I.e. on Brew the target folders are different and all it takes to port the implementation is to reconfigure the folder strings. On Android another implementation is required that pulls media content through the respective Android APIs. Support for media content types can be plugged into the Media Server by means of meta-data plugins.
A key enabler for this solution is UPnP. The Media Server registers itself as a UPnP device and Service with the OSGi UPnP Service. The UPnP stack then broadcasts the availability of the media server into the Wifi network. Other UPnP enabled devices will pick up the broadcast messages and learn about the presence of the Media Server, it's physical network address and where to find the respective services. As demoed in the video, the Playstation contains this functionality, find the media server and is capable of playing back the picture content it offers.
The implementation is functional already but we will keep working on it. It'll get an end user UI and support for additional content types. Moreover, the UPnP implementation needs enhancements for better handling network drops (in the interest of battery savings smart phones tend to switch off their Wifi modules whenever they think it makes sense...). It should be ready by the time Sprint launches the first OSGi handsets...
A few weeks ago Opera announced its latest innovation: Opera Unite, a small web server sitting in the browser enabling true peer-to-peer transfer of content and social networking. A preview version of an Opera desktop browser is available for download, a mobile version is said to be in the works (at Opera).
What most people may not know: The feature that Opera Unite delivers is available on mobile handsets already, namely on Android (here it rather works with Webkit), Win Mobile, Nokia S60 (Webkit again) and a Brew based handset. In fact, it was already demonstrated on JavaOne four weeks ago. How come?
What Opera calls Unite and intends to port to mobile tomorrow is functionally contained in what Sprint (wireless carrier in the US) calls Titan (which essentially is Mobile OSGi plus web browser integration), shipping with a number of handsets this year. What each respective technology does:
it turns your device into a full web server (we call it the The Server in your Pocket)
it lets you share your content peer-to-peer with your friends
the local user interface runs in the browser
new services & capabilities can be injected (taking effect on both the server and the browser based UI)
on broadband networks it discovers peers via some internet lookup service (for instance, the demo on JavaOne used Twitter for that purpose). Certainly, Opera is ahead of the game in this regard as they provide an operational central DNS service operational
on local networks it can discover peers through UPnP
Despite these similarities, OSGi takes the concept one step further and offers additional capabilities:
it is browser agnostic. In fact, on Android and S60 the Webkit browser is used, whereas on WinMobile and a Brew based handset we use Opera Mobile (without Unite support)
the server feature runs in the background and is available even when the browser is down
new services (i.e. a new p2p messaging service) are written in Java and are deployable (push or pull) at any time (even once the device is already shipped). This opens the door to leveraging an incredible amount of existing code, knowhow and developer resources. Moreover, pure Opera Unite services run in the browser sandbox and cannot leverage platform capabilities that Opera does not provide JavaScript APIs for. In mobile this is crucial as file access (essentially the only platform access API currently available in Unite) isn’t all you want to use. There is location, messaging, PIM, etc. … In OSGi, you’re not bound to the APIs of your sandbox, you can bring you own APIs! Not to speak of the many APIs you get out of the box
OSGi is a recognized industry standard, it is not a proprietary technology. It has an open governance model, a reliable spec and a huge developer community behind it
Anyway, despite these differences I am extremely excited about Opera Unite. Alike Sprint and OSGi, Opera has stood up for a new approach of architecting the internet: Turning dump clients into intelligent servers. It is not about yet another social networking platform, it is about expanding the very core fabric of the web and the way social communication works today. It took a popular brand like Opera to finally get a public conversation going about this new architecture. I sincerely thank Opera for having created this level of awareness in public. Sprint & Co. haven’t managed to create even just a fraction of the buzz we have seen in the last few weeks, initiated by Opera's announcement.
Lawrence Eng from Opera says in his blog"I hope you’ll join me in imagining a more personal and social computing experience that actually begins to deliver on the old (but not forgotten) promise of the Internet bringing people together in meaningful ways." I certainly will! Will you?
Opera, why don’t we team up and explore what comes out if we combined Unite and Mobile OSGi?
In Nov 2007 folks from Luminis managed to port OSGi onto Android, or more precisely, onto what was called Android back then. Meanwhile most framework providers have gone ahead and ported their implementations to Android as well. However, as I argue in an earlier post, refer to Mobile OSGi on Android, I see little value in just porting OSGi. The value comes from integrating OSGi with Android. OSGi must be understood as a complementary platform, not a competing technology and that approach requires a good level of integration between the two.
Pursuing the goal to create a value adding OSGi based stack for Android, ProSyst recently releases the first version of the stack. It works on all Android 1.5 (Cupcake) compliant devices. Here's is the list of supported features from the Release Notes:
Compliant to specifications OSGi Core 4.1 and OSGi Mobile 4.0 (JSR232)
Java Security enabled and integration between OSGi and Android security policy frameworks
Support for w3c & Opera based Web Widgets
Web widgets run in WebKit browser-based viewer
Installation and security verification of Widgets executed through OSGi
Local web server functionality, pretty much the same thing as Opera Unite (will blog about that one soon)
Automated translation of OSGi services into local JSON based web services (provides Web Widgets access to platform capabilities like Messaging, Location, etc. You can also write your own OSGi services in Java and provide access to that functionality to your web widgets)
JavaScript Convinience Library for finding, binding and using OSGi services within the browser
Integration of Android Intents with OSGi Event Admin (bi-directional exchange of events/intends)
Access to OSGi Services through Android IDL (enables Android developers to leverage OSGi services)
Access to Android APIs from within OSGi
OSGi runtime lifecycle management: User can select different OSGi runtime modes (Always On, Always Off, On if OSGi content installed)
Content Management User Interface
Listing OSGi content packages
Installing content from SDCard
Unistallation of content
Installation of OSGi Content through WebKit Browser
Full mobile device management support
OMA-DM 1.2 based remote management interface
All OSGi defined Management Objects: Configuration, Application, Logging, Monitoring, Policy
This is pretty much as much as you can get from it right now. Features coming in future releases are:
Support for Bundle App Model (so that you can write bundles that use the native Android UI APIs. To do this properly an integration with the OSGi Application Admin is required)
Connectivity between OSGi runtime in Android with Eclipse IDE based OSGi Development Tools
Extend the OMA-DM device management tree by the Lock&Wipe Management Object (LAWMO), which enables enterprises to remotely wipe lost or stolen phones.
Enabler OSGi Service APIs & JavaScript for accessing phone featuers like Camera, PIM, Messaging, etc.
The stack is available for side-load as well as pre-load (for OEMs who decide to pre-integrate it on their devices). In fact, the Lock&Wipe and Android Package push deployment featuers require the stack to be signed by the OEM.
I hope this solution as well as the work of other OSGi community members (i.e. EZDroid) will help drive adoption of OSGi on Android.
A lot has been written about this years CTIA, big news about new voice services, Skype on iPhone, Samsung presenting Android or not, bla bla bla. The most remarkable statement, however, was littled commented: Verizon committed to Mobile OSGi!
Talking about the carrier's challenge of supporting 8 or 9 different mobile operating systems, Verizon Wireless' CEO Lowell McAdam said that "I don't think I need to bet on an operating system, I need to bet on layers that will bridge those operating systems."
Isn't that exactly what OSGi delivers? A cross platform bridge for apps, services, APIs? A manageable middleware layer that reduces bad fragmentation while unleashing a particular platform's power? I'm absolutely sure McAdam alluded to Mobile OSGi, there's just no other way... ;-)
Apple has recently announced the iPhone OS 3.0 Software. As for any of their public statements, once again Apple is extremely proud of its own achievements. The new OS version is said to come with 100 new features and an incredible set of 1,000 new APIs. Indeed, version 3.0 seems to mark a major milestone in the iPhone evolution and I am sure they really did a great job.
What’s the connect to OSGi, though? The iPhone 3G device was launched in June 2008. The new OS 3.0 is expected to be launched around mid 2009 - that's 1 year period at least. Apple claims that ...With the new SDK, members of the iPhone Developer Program can build applications that do even more... I'm sure they are not exaggerating on this. However, why would developers had to wait 1 full year (!) to get more APIs? Why to have them wait 12 long month to leverage more of the extremely capable and beautiful platform that they had right from the beginning? That's one year of delayed innovation, one year of untapped opportunities, one year of competitors to catch up, isn't it? You think a year is not that long? I claim it is! Recap what has happened meanwhile: Android phones entered the market, Palm Pre has been announced (and if speculations are right will also hit the US market before iPhone OS 3.0 is out), Nokia has launched its touch OS (S60 5.0), etc. etc.
Mobile OSGi is setting out to solve the *API innovation cycle problem*. In OSGi, new APIs can be loaded at any time, by anyone (who has the right permissions). Developers don't need to wait for X years for the manufacturer to complete the next static image version - they just pull the APIs they need and deploy them along with the apps. Internet firms can wrap their services into APIs and have them be used by 3rd party developers to create the next gen mobile apps for them. New business models (like the one Apple is to ship with 3.0: in-app sales) can emerge way quicker than before etc. etc. For sure, there's always more creative brain power outside the manufacturers engineering team, why not leverage that, why not to unfold the true creativity of the worlds developer community?
It’s sad enough that the phone hardware platform got to have a static lifecycle. But the APIs don’t need to be static, really!
Soon after Android was launched most of the OSGi framework developers got ambitious to port their implementations onto this platform. The world now has a number of "hey, see, OSGi runs on Android - isn't that cool?" type of demos. In my opinion noone really needs a plain OSGi framework on Android, the value add is very low.
Little thought has been spent on what OSGi on Android is actually good for, what's the value add that OSGi brings to the platform. We have spent quite some time to analyse the platform and came to the conclusion that it is not a pure OSGi port but a proper OSGi integration that enables value adding use cases. I have summarized a couple of our thoughts, find them here:
To recap the highlights of what OSGi can do for you on Android:
Support for Widgets (local web applications)
Support for enabling web apps to access phone features and custom services implemented in OSGi
Support for OSGi Bundles and Deployment Packages
Support for OSGi Applications that use the Android UI (coming soon)
Support for Remote Management (push/pull deployment of Android apps and OSGi content; remote configuration; remote monitoring and logging; etc.)
Support for eventing between OSGi and Android
Here're some screenshots on how the Widget support looks like. Widgets can be plain Opera Widgets (they comply to the w3c widget spec) or what we call RMA Widgets which are widgets that use OSGi as a local web server to access device functionality.
We'll continue to work out the value proposition so as an implementation that does all that.
I'm extremely pleased to have been given the chance to talk about Mobile OSGi on this years EclipseCon in Santa Clara. Find the abtract here. Hope many of you will join the talk. Let us catch up!
I am interested in and curious about anything that makes mobile devices more open, helps developers to create apps and drives mobile operators from the concept of Closed Garden to Open. The foci of my blogs are web widgets and OSGi.
I work at ProSyst Software in Germany.
