Mobile OSGi Blog

Recent News about Mobile OSGi

2010-05-07T16:12:00.002+02:00

It’s been a while since I wrote about Mobile OSGi (mainly because I was working on Mobile OSGi), so I hope I haven’t lost any followers. Thank YOU for bearing with me!

In this post I want to put forward a few recent news about Mobile OSGi.

Free Off-the-shelf Mobile OSGi Runtimes and Tools

If you’re a developer and interested in getting your hands on Mobile OSGi, take a look at the free offerings from ProSyst. In the last month my team and I have worked hard to create this product portfolio and we’re proud on what we have achieved. What you can download:
- Mobile OSGi for Android
- Mobile OSGi for Windows Mobile
- Mobile OSGi for Nokia S60
- Mobile OSGi SDK (Eclipse based)
Apart from the plain OSGi layer, these stacks come with a host of added value services (e.g. Support for W3C Mobile Web Widgets; Remote Management; Tooling Support; etc.). Every package comes with documentation (find box on the right) so it’s easy to get into it. The Win Mobile and Nokia S60 stacks contain an embedded CDC Java VM, so installation is really as easy as it can get. If you have questions or face issues, use this forum to get feedback.

We also put the stack on external download sites. These are:
- Android Market (for the Android version)
- Handango.com (for the Windows Mobile version)

I am pretty amazed by the number of downloads we get on the Android Market (1500+ in a few weeks only). Who are all these OSGi enthusiasts out there? Please get back to me!!

OSGi on Android

The uptake of Android is accelerating and so I am getting asked frequently how OSGi and Android compare and what’s the value of putting OSGi onto Android. Here’s a slide deck on this matter:

Adding advanced Device Capabilities to Android

View more presentations from Joachim Ritter.

Feedback very welcome, as always!

VisionMobile Mobile Mega Trends 2010: OSGi considered value add for OEMs and MNOs

Andreas Constantinou from VisionMobile once again has done an impressive job in analyzing and describing mega trends of the mobile industry. His annual Mega Trend decks are must-reads for all mobilists – a beautiful piece of visionary thinking.

Starting from page 47 Andreas analysis monetization opportunities for OEMs and MNOs. He distinguishes 10 value areas (Services; Service delivery; Service distribution; Device design; UI design; Core apps; Operating system; HW Platform; Chipset IP and Manufacturing) and identifies those ones where OEMs and MNOs used to or will capture value from –services playing a significant role.

OSGi is considered a value enabler for “Service delivery”, a key instrument for MNOs to implement their smart pipe strategies (which centers around capturing value from services rather than plans only) and for OEMS to leverage their unique position in service distribution.

Not surprisingly, I couldn’t agree more …. ;-) OSGi is the only sophisticated, standardized, embedded and cross-platform service delivery framework on the market.

Mobile OSGi Mass Market Device(s)

Well, those of you following this blog will already know that Sprint has stopped the Sprint Titan project which had OSGi at its core. David Beers has commented on Sprint's move in his post Drove my Chevy to the levee... and Has Sprint caved to Google on its open Java platform?. Really not much to add to this.
Anyway, I do not want to put my fingers into the wound of those that were involved. I just want to mention that 5 mass market devices were developed incl. OSGi, 2 Win Mobile, 2 Android, 1 Brew. The latter is the Samsung Instinct HD device, still on the market. More about its Java capabilities you find in a post of Darryl Mocek. Sad they didn’t continue…

That’s all for now. Please share your feedback!
- Jo

MediaServer for Android

2010-01-26T20:26:00.004+01:00

Thanks to all of you who have been waiting patiently for our MediaServer. I am proud to announce that we just published it on the Android Market. Just take your phone, open the Market app and seach for MediaServer.

Here's a little video about it:

Extract from the app documentation: MediaServer is a DLNA Media Server for devices featuring the Android platform. Using MediaServer, pictures & videos taken with your phone as well as audio files can be played back on your home media appliances like TVs, picture frames, Sony PlayStation 3, etc. Without the need to plug any cables nor to configure any network settings, your home media devices will discover your Android phone automatically once the device is on WiFi and the MediaServer is turned on.
So, take your pictures and videos while you're on the go and play it back on your TV when you come home!

Tech insights: The app embeds Mobile OSGi as an internal architecture. This helped us a lot as we could reuse OSGi's UPnP and http services. It also uses Config Admin and Log Service. While OSGi payed off, implementing multicast protocol features on Android were a pain as we had to work around the lack multicast packet reception support (most vendors don't compile the Android Linux kernel without that feature...). Anyway, it works well, try it out!

-Jo

Innovation Beyond Mobile Apps

2009-11-05T17:08:00.003+01:00

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.

Find the presentation here:

Let the community do more than just Apps!

View more presentations from j.ritter.

As usual, comments are welcome!

- Jo

DLNA Media Server for Smart Phones

2009-08-05T11:51:00.003+02:00

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...

'Opera Unite' released for Android, Win Mobile, Nokia S60 and Brew!

2009-07-09T15:43:00.002+02:00

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?

- Jo

Update on OSGi for Android

2009-06-23T11:02:00.013+02:00

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

Server in Your Pocket & RMA (Richt MobileNet Application)
- 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
- Sotware Component Management Object (SCOMO): Remote management of Android APK packages, OSGi Bundles, OSGi Deployment Packages, Widgets (push-install, update, uninstall)

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.

Jo

Listen to Verizon!

2009-04-21T23:19:00.002+02:00

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... ;-)

1,000 reasons to go for Mobile OSGi

2009-04-02T21:45:00.003+02:00

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!

Mobile OSGi on Android

2009-03-26T13:02:00.003+01:00

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:

OSGi on Android - Value Proposition

View more presentations from j.ritter.

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.

Comments?

EclipseCon 2009

2009-02-20T15:11:00.002+01:00

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!

Sprint Titan 1.0 released - Mobile OSGi goes Mainstream

2008-12-29T19:08:00.004+01:00

Sprint has released the 1.0 version of Sprint Titan™ - a first class Mobile OSGi implementation for Windows Mobile 6.x Standard and Professional devices. Officially the following devices are supported, however, the stack essentially runs on any Win Mobile phone:

HTC Touch
HTC Touch Pro
HTC Touch Diamond
HTC Mogul

Official support for a selection of Windows Mobile Standard (these are typically the ones with the mini Querty keyboard and no touch screen like the Samsung ACE (i325)) is said to be announced shortly as well. Moreover, Sprint Titan is said to be integrated on Sprint’s mainstream Feature Phones.

In addition to the production stack which installs only on devices operated in the Sprint network (Sprint branded phones as well as non-Sprint branded phones provisioned by Sprint), Sprint offers 90 days trial versions of the stack which install on any Win Mobile 6 device. I have tried with a HP iPaq 614c and it works great! In my opinion, with these trial stracks Sprint offers a great service to all OSGi enthusiasts around the world who can pick up the stack and get started.

Compared to what Sprint released in December last year, the new stacks now support Location API on the CDC side, contain a bunch of bug fixes and have been performance improved. Functionality wise, there is still work to be done (full web widget and service remoting support, additional JSR support on CDC (like 135), OSGi Bundle App Model support, etc.). However, the new releases are a major improvement over the old versions and should be fun to use!

The new release package also consists of a new version of Sprint’s Eclipse IDE plugins (now Eclipse 3.4 is supported, several bug fixes were applied) as well as an 80+ page developer guide that helps developers get up speed. A set of application demos (binaries, source code and documentation) will come out shortly as well.

It’ll be very interesting to watch what the creative people around the world will start doing with this beautiful and powerful platform!

Why Mobile OSGi reduces bad fragmentation

2008-10-01T22:05:00.000+02:00

One of Mobile OSGi’s claims is to reduce the platform fragmentation problem the market increasingly suffers under. Why is that so?

In my opinion, there are two types of fragmentation, "good" fragmentation and "bad" fragmentation. It is natural and desirable that a market with 2 billion subscribers develops a large blend of different needs and preferences. The mobile market must and will continue to serve demand for a diverse range of mobile devices and application. This is "good" fragmentation, the market needs that. Btw, that very reason provides a serious challenge to open platform initiative like LiMo, Android or SymbianFoundation. On the one hand, they attempt to standardize a platform which essentially means to define a common set of functionality which is supposed to be equal on any device. On the other hand they must leave enough room for differentiation and diversification. Finding the right balance is not trivial.

Anyway, “bad” fragmentation is what app developers suffers under every day. The market is faced by heavy fragmentation resulting from
- variety of operating systems (Symbian, various Linux, Android, iPhone, WinMobile,..)
- variety of application execution environments (Java, native, WebApps, Flash,…)
- variety of form factors
Multiply the number of OSes by app execution environments by form factors by number of available versions of all of these components and you’ll understand we’re in hell! If you need wide platform support for your apps, you end up developing them multiple times for the various operating systems and/or execution environments.The form factor and hardware dependent aspect of the fragmentation problem cannot be removed (i.e. different screen sizes, different hardware support options like GPS, NFC, etc.). However, there is lots of room for improvement when it comes to the API layers applications make use of. Certainly, the market does NOT need 15 different mobile Linux platforms with incompatible application APIs. Incompatibilities in Java APIs, i.e. resulting from different implementations or spec misinterpretations, obviously make life harder than it should be. Neither will it be particularly helpful for app developers that very soon there'll be dozens of different Widget runtimes out there...

So, how does Mobile OSGi fit in? In my opinion, Mobile OSGi adds a layer exactly at the right spot: above the OS and around the execution environment. In other words, it encapsulates the many different operating system APIs and thus reduces fragmentation. However, it does not constrain the need for differentiation because it does not urge developers to use one particular app model nor a specific UI. Mobile OSGi adds an incredibly powerful & OS agnostic cross-platform execution runtime for your app's business logic, data and network layers. Mobile Enterprise applications, which typically have lots of code under the hoods of the UI, benefit in particular from OSGi's state-of-the-art component and service architecture (which btw has proved to work incredibly well in many other verticals and I'm convinced it'll conquer market share in mobile as well). Why else would companies like IBM or Sprint build their entire enterprise product portfolio upon Mobile OSGi?

Mobile OSGi can run on any platform that supports CDC Java. I am aware of ports for Nokia S60, Win Mobile, Linux, Android and Brew and more are certainly to come.

To keep a long story short: Mobile OSGi certainly reduces “bad” fragmentation but not at the cost of constraining “good” fragmentation. I am not aware of any other technology on the market that has a similar cross-platform proposition. Are you?

Public Resources about Mobile OSGi

2008-06-30T21:25:00.005+02:00

Interested in Mobile OSGi? This collection of public links and resources might help you getting around the net and finding the best resources.

Mobile OSGi Stacks

If you want to start playing around with Mobile OSGi, here is were you find the stacks. There two types of stack you will come across:

Integrated Mobile OSGi stack that includes all of the below mentioned pieces
(a) OSGi framework plus Mobile services (and in some cases eRCP), ideally it is compliant to the OSGi Mobile Specification (aka JSR 232)
(b) platform integration code (this is the part that ties OSGi nicely into the underlying OS. This integration is required for seamless user experiences during download, installation, launching of apps and also for other reasons like security etc)
(c) CDC/FP VM
These type of stacks are off-the-shelf kind of solutions due to their ready to install nature.
Java-only Mobile OSGi stack which is typically only (a) from the list above. This type of stack requires manual integration of a VM, porting on the target device, etc. Thus, I call this type has more the flavour of a SDK.

For Win Mobile:

Download a ready to use and well integrated stack (type (1) stack coming with eval license) from Sprint Developer Site (delivered as an installable cab file). It contains a J9 CDC/FP VM, all sorts of services, eRCP and MIDP support and is highly optimized.
A Java only type of stack with full JSR 232 compliance, called mBedded Server Mobile Extension, you can get from ProSyst
A basic eRCP stack for WinMobile 2003, 5 and 6 you can obtain from the Eclipse eRCP Project site (Java-only type of stack, not JSR 232 compliant, not optimized for embedded use)
A commercial product based on Mobile OSGi is the IBM Lotus Expeditor that comes with a blend of added value enterprise services
You may also want to contact mobileosgi#at#prosyst.com for more information

For Nokia S60 3.1:

A well integrated & ready to use stack (type 1, including eRCP support) is available from Nokia. Write an email to nokia.eRCP#at#nokia.com and ask for it.
You may also want to contact mobileosgi#at#prosyst.com for more information

For Android:

The richest OSGi port (type 2) for Android is probably the one from ProSyst which you can pick up for free from here. Although it contains lot's of OSGi services, it is not fully JSR 232 compliant (yet). I also recommend to read this blog.
The guys from Luminis created the first OSGi port for Android which is based on the Apache Felix project. Find information here.
The Eclipse Equinox OSGi framework has been ported as well (by BJ Hargrave from IBM), not sure if that is available anywhere, though.

For Brew:

The first Mobile OSGi port for the Brew platform is currently under construction, more information you can obtain from .

OSGi for Apple iPhone:

You show me and I owe you a beer! Nonetheless, investigations are going on...

Presentations, Tutorials, Articles

General Presentations covering Mobile OSGi aspects:

Nokia's developer presentation at EclipseCon 2008
Sprint's Titan Introduction presentation
Sprint's developer tutorials
Jon Bostrom's presentation on Sprint Titan and Mobile Rich Internet Applications (he named them Rich MobileNet Applications)
My presentation about Mobile OSGi's value prop for mobile enterprise developers (from OSGi Community Event 2008)
Various eRCP related documents
Basic OSGi developer guides from ProSyst (refer to Getting Started menu)
Gabor's blog about how to write eRCP apps for the Sprint Titan platform
Jon Bostrom's article Next Mobile Java based on CDC/OSGi Technology for Universal Middleware

Tools

Most complete Mobile OSGi toolset based on the Eclipse IDE can be obtained from Sprint. It contains all sorts of tools for developing eRCP apps, debugging, profiling, creating DPs, on-target deployment and execution, remote console, etc.
Mobile OSGi specific tools are provided by ProSyst. A free version of the mToolkit is available as here.
Obviously, the Eclipse Project in general is a great place to look for advanced tools.
Sun also offers a toolset for the Sprint Titan platform here.

Blogs

I have come across Mobile OSGi related postings in the following blogs (but obviously they all deal with other interesting topics as well):

Gábor Pécsy's Blog
ProSyst's Blog
Ove Nordstroem's Blog
Gorkem Ercan's Blog
David Beers' article on mobile OSGi, here
David Beers' Blog
OSGi Blog

Do you know any other good resources? Please let me know!

Jo Ritter

What Mobile OSGi has to offer to mobile enterprise developers!

2008-06-24T20:14:00.003+02:00

It is evident that the market for mobile enterprise solutions grows rapidly. A lot less obvious are the technological trends on which mobile enterprise solutions are going to be built upon. Mobile OSGi technology (i.e. JSR 232, Eclipse eRCP, Sprint Titan) is one of the platforms that enters the market and thus competition against other platform concepts such as MIDP, native applications, Google Android, etc. What is it that mobile OSGi technology has to offer?

Download my Presentation
The OSGi Alliance accepted my proposal to talk about this very topic on the OSGi Community Event in Berlin. Please find my slide deck HERE.

This topic is worth a full day but I had to squeeze it into a 40 minutes talk. Now I get even braver and try to sum it up in a couple of paragraphs only. Let’s start with how Mobile is positioned in comparison with the many other technologies in the field. In my opinion, Mobile OSGi has characteristics of all of these platform elements:

Operation System: OSGi comes with a number of infrastructural features that are usually associated to the OS level. Example: the EventAmin (API to subscribe to or publish events) or the PermissionAdmin (API to dynamically specify security policies).
Other technologies on this level: Symbian (S60, UIQ, FOMA), Linux (LiMo, LiPs, Qtopia, Access), Win Mobile, RIM, Apple iPhone, Google Android, etc.

Application Execution Environment: On top of OSGi you can run a variety of different application types like MIDlets, eRCP applications, Web Widgets, Xlets, etc. Application model support can be plugged in even after the phone has shipped.
Other technologies on this level: MIDP 2, Qualcom Brew, Eclipse eRCP, Adobe FlashLite, Nokia Web Runtime, Yahoo Go!, Plain old Browser Model, Coming: MIDP 3, Sun JavaFX, Android, iPhone Apps, etc.

Remote Access: Due to OSGi’s component based architecture and it’s service concept, remote manageability comes out of the box. The entire runtime is represented in an OMA-DM compliant management tree and enables almost all use cases required for mobile device management.
Other technologies on this level: OMA-CP, OMA-DM, SCOMO, FUMO, OMA-DS / Sync-ML, WAP-Push, etc.

Application: OSGi itself is much more of a container and not an application by itself. However, in some cases it might have a bit like an „application“ flavour since it could be (but should not be) installed as an application into the native OS (the way better approach is to integrate it with the OS, though).

Now, if OSGi is all that does that mean it competes against all these other technologies? NO, IT DOES NOT. OSGi is a complementary and not competitive technology.

What it does, though, is to abstract some of the other elements and thus creates an almost unique value proposition: it can run on almost all platforms which are out there (and capable of hosting a CDC like VM) while providing a homogeneous execution environment for a multitude of apps.

The other key features of Mobile OSGi I want to highlight:

Component & Service model – ready for middleware
In OSGi you structure your apps in components and you share information (or APIs) between components by means of services (or package level sharing). It’s like a SOA infrastructure in the VM. Main benefit: the system encourage the use of middleware. Write you headless middleware as services and have them be used by all your mobile apps. Or use 3rd party middleware instead and focus on your domain specific application aspects.

Security model, dynamic policy model
OSGi contains a dynamic policy infrastructure allowing trusted code to adopt the device policy. By means of this concept, carriers can create tailored device policies for enterprises customer to whom the standard policy does not fit.

Remote manageability out of the box
Mobile Device Management is inherently integrated into OSGi. Plus, the remote management capabilities can easily be extended by plugging your custom functionality into the device management tree.

The market uptake is not what I would call significant yet, but there is good progress underway. As pointed out in other posts, Sprint launches their Titan platform with is Mobile OSGi build into mainstream handsets - the first pre-integrated mass deployment of OSGi. Also IBM bets on OSGi and has built their mobile enterprise product, called Lotus Expeditor (a universal managed client for SOA), on OSGi/eRCP. Furthermore there are lots of development enterprise projects for OSGi/eRCP going on which I cannot disclose at this time. Nokia has build a Mobile OSGi/eRCP stack as well, find an interesting presentation about it here.

Obviously, I am a bit biased about Mobile OSGi (hey, it’s my bread and butter) and I have to admit that even Mobile OSGi does not solve all your problems (don’t ask me about Java UIs…). Nonetheless, what other contemporary technology provides a larger set features that are available cross-platform?

Tell me!

How to develop eRCP apps for Sprint Titan

2008-03-07T15:02:00.003+01:00

In my previous posting I have explained what the Sprint Titan OSGi platform is, what the developer package of Sprint contains and what it is good for. Gábor Pécsy has taken the Sprint Titan analysis to the next level and wrote up a manual on how to develop eRCP apps for the stack.

Gábor's blog adds nicely to the use documentation of Sprint. Have a read!

Sprint Nextel goes live with Mobile OSGi!

2008-02-21T17:24:00.008+01:00

This week’s news from Sprint Nextel marks a cornerstone of OSGi adoption: Sprint has released its first developer version of the Titan platform, an OSGi based next generation mobile Java stack. Titan was announced on the last Application Developer Program (ADP) Conference and is now made available for download at developer.sprint.com. This is very exciting news for a number of technical, business related and strategic reasons!

First of all, let’s take a look at what the Titan SDK contains:

1. A self-contained Java runtime stack for Win Mobile 6 PDA phones. It is a dual stack system consisting of these components:

(Source: Titan documentation)

The stack comes as a cab file, the package format for Win Mobile applications.

Architecture. The architecture is entirely transparent to developers and end users. Plain old MIDlets are executed in the CLDC VM runtime whereas eRCP applications and OSGi bundles run in the CDC/OSGi VM process. The OSGi stack runs in background mode and handles installation, uninstallation and launching of all applications and components. For this reason Titan contains a set of AMS related components which tie into the OSGi runtime.

Supported Standards. Despite its new architecture, Titan is build upon industry standards. It supports:

CLDC 1.1, CDC 1.1, Foundation Profile 1.1 (IBM J9 VM)
MIDP 2 (JSR 118)
File Connection API (part of JSR 75)
Wireless Messaging (JSR 120)
Mobile Media API (JSR 135)
Location API (JSR 179)
Mobile Operational Management (JSR 232 = OSGi R4 Mobile, ProSyst mBedded Server Pro Edition)
Mobile Internationalization API (JSR 238)
OMA-DM 1.2, OMA-DL 1.2, OMA SyncML Commons 1.2
Eclipse eRCP 1.1, eSWT/eJFace 1.1 (not standards, but good open source stuff!!)

Application models. The current version of Titan supports POMs (plain old MIDlets), OSGi bundles and Deployment Packages (DPs) as well as eRCP applications. Other application and package formats may be added in future, a widget based web application model being one of those. I would have loved to see support for OAMs (OSGi Aware MIDlets, i.e. MIDlets that are allowed to access CDC APIs and thus make use of all the beauty of OSGi) but that’s not the case currently. Titan comes with LCDUI and eSWT UI toolkits.

Manageability. One of Titan’s core concepts it manageability. The runtime can be managed from a developer host (using an IP based management protocol) as well as remotely via the OMA-DM protocol. For this reason it contains a full OMA-DM and DL client implementation.

Developer Support. The Titan stack runs on target devices as well as in the Win Mobile emulator that you can download from Microsoft. Moreover, the stack can be launched in normal runtime mode, in debug mode or in profiling mode (requires the tooling add-on, see below).

2. An installation package Titan device tools: This package contains the client side interfaces for the Eclipse based Titan Tooling plugins (debug and profiling libs for the VM, local console app for the OSGi runtime, an agent that communicates with Eclipse, etc.)

3. A set of Titan Tools Eclipse plugins. All the good stuff developers need: VM launcher, DP Editor, OSGi remote management plugin for deployment, installation and launching of apps and bundles and a Java profiler.

4. Demos and documents. Sprint provides a set of videos on how to use the various tools as well as a good documentation on Titan (you need to install the Eclipse plugins to get the docs. Install them and open Help-Help Contents-Titan Developer’s Guide in Eclipse).

I have to admit that I am pretty excited about what they provide and it gives me a hard time to not make this blog a sales pitch for Sprint. Here’s why I believe that Titan is a great step for mobile computing.

What’s in for developers?

Titan offers a lot of enhanced features for mobile application development. The modularity and service registry concepts of OSGi open the door for component based designs, allow code sharing, provide sophisticated solutions for version and security management and offer remote control out of the box – just to mention a few of the many benefits.

Secondly, Sprint offers several application models from which developers can chose. Legacy MIDlet applications are still supported but if you need more than just that you can write bundles, eRCP apps, widgets and perhaps other models which Sprint might add in future. Apparently, the choice of picking the right model has now been taken from the device OEM or operator and been given to those who know best what they need: the developers. However, in contrast to other more or less proprietary platforms like Android, almost all public APIs are based on industry standards and thus secure your investments.

The tooling package provided by Sprint will ease the first steps, although there is still a lot that could and should be added over time (i.e. GUI builder á la NetBeans).

What’s in for Enterprises?

There are at least three reasons why I think enterprises should get involved with Titan:

The market place of mobile platforms is right in the middle of a massive fragmentation process. In terms of open application platforms, until today the choice was more or less limited to MIDP2, Nokia S60, UIQ, Win Mobile and Brew. Tomorrow, a colorful bunch of additional platforms will penetrate the market of smart phones: Android, several Linux platforms like LiMo, Qtopia, MLI, perhaps MIDP3, Maemo, iPhone SDK, JavaFX Mobile, etc. etc. Once ported to all Sprint phones – which I assume is Sprint’s strategy – Titan will provide a homogeneous cross-platform runtime and thus eliminates the fragmentation issue of the underlying layers. This is a huge benefit for enterprises that face the burden of supporting different phone platforms.

Secondly, the introduction of OSGi/eRCP/eSWT is a powerful set of capabilities. For enterprise developers this technology is of particular interest. eSWT offers a large blend of UI widgets that enable development of rich apps. eRCP is a subset of the Eclipse RCP technology (the „e“ in eRCP stands for „embedded“), which seeks a lot of attention from visual desktop application developers (find a list of known RCP apps here). The Eclipse IDE itself, which is based on RCP, is the best example of what you can do with it. Frankly, Titan leverages desktop development know-how and technology to mobile handsets.

The third reason is Titan’s remote management capabilities. The key use cases are: Remote deployment of new apps, updates and upgrades, remote removal of deprecated apps, remote monitoring and remote configuration of your platform and your apps.

What’s in for Sprint?

Hopefully a positive impact on its share price! ;-) The fragmentation problem described in the enterprise context above is equally challenging for Sprint as a network operator. Sprint has built up a large and lucrative application and content ecosystem. Today, most (if not all) of those apps are MIDP2 based. What will happen after MIDP2, though? What can MIDP2 or Brew provide to enterprise developers? Presumingly, Titan is a strategy to offer innovation and yet to satisfy legacy support.

Looking at Titan from a non-technical angle, it appears to me as another episode of the war for share in added value services. Since margins are falling for both mobile hardware and telephony services, device OEMs started to go downstream and battle against operators for service revenue (and so do players which have no traditional roots in the mobile market, i.e. Google, Yahoo!, etc.). Titan – a container technology that is supposed to secure and extend Sprint’s ecosystem business – could be one element of Sprint’s competitive positioning.

What are the downsides?

Well, I guess it is just fair to mention that, alike any other new technology, Titan implies some challenges as well.

The current version of the downloadable Titan runtime works for Win Mobile 6 PDA only. The readme says that it is tested on the Sprint HTC Mogul device only but I know that it works on other devices, i.e. the HTC Touch, as well. Anyway, market penetration requires additional platform support which Sprint already announced in this presentation.

Footage of Titan is probably not an attribute people will get particularly excited about. ROM footprint is around 17.2 MB (incl. everything; size of the OSGi framework is just a couple of 100k) and RAM around 11 MB (stack only, no apps started). Considering the rapid increase of handset memory size and processing power, I don’t think the Titan footprint is really a serious obstacle.

After all, Titan is good news to all of us OSGi enthusiasts. Let’s hope that it’ll gain rapid market acceptance!

Notice: Sun has created a Sprint Titan stack as well and released that right after the last Sprint ADP Conference in December 07. Similar to the package described above, Sun's solution comes with tooling integration and documentation. Definitely worth reading!

Stay tuned...

- Jo

Welcome to the Mobile OSGi Blog!

2008-02-15T20:05:00.006+01:00

Yet another blog about mobile - does the world really need that? Well, yes - and this is why: OSGi is around for almost 10 years and it is just now that it eventually hits the mobile market - an exciting time for all OSGi enthusiasts who have been waiting for so long! Although Mobile OSGi does not yet grap attention of the big press, there is quite something going on. Come back and have a read!

Btw, in my terminology, Mobile OSGi reads OSGi R4+ used in a mobile handset. However, typically it either refers to what the OSGi Mobile Expert Group (MEG) specified (also known as JSR 232), or the Eclipse open source project eRCP.

What I intend to write about:

News and gossip about mobile OSGi
Discussions on what OSGi adds (or adds not) to the mobile market
Reflections on what comes after MIDP2: The next generation of mobile Java

My blog is free content but it does come with one obligation: be critical and comment!

- Jo