An Interview with Nokia's Asko Komsi

Frank Sommers: In the first half of this year, your company, Nokia, outshipped the entire PC industry by a factor of close to three, delivering 153 million mobile phones to consumers. Non-PC devices, such as mobile phones, game consoles, or telematics systems now reach far more users than PCs or servers, and almost all those devices ship with a version of Java ME. Developers are naturally anxious to get a piece of that action, but so far only niche Java applications, such as games, have fared well on mobile devices. Why do you think that is?

Asko Komsi: What happened is that in the early days of J2ME we had MIDP and a bunch of different APIs, but nobody defined a framework that every handset should support. A lot of handsets offered MIDP support, but what additional APIs were supported varied between different operators and different handset manufacturers.

The first attempt at solving that problem was setting up JTWI [Java Technology for the Wireless Industry, JSR 185]. That was the first try at defining a full API stack for developers, requiring, for instance, that a handset provide MIDP or a messaging API. JTWI tried to come up with a tiny stack. Unfortunately, that initiative didn't work well. One reason had to do with licensing, a very important part of all this.

After JTWI, Nokia, Vodaphone, and the entire industry wanted to provide a better initiative that not only defined a common stack, but that also provided a path to future progress. We wanted a process that led not to a one-shot initiative—which we finish and just be done with—but to something ongoing. The vision was that new versions [of a common stack] would be defined when there is new technology to incorporate, and when we see the market need to come up with a better platform.

The results of that new initiative are JSRs 248 [Mobile Service Architecture, or MSA] and 249 [Mobile Service Architecture Advanced]. JSR 248 is now being finalized, with the approval ballot slated for August, while work on JSR 249 will commence shortly. We anticipate that JSR 249 will exist in a draft version by the end of this year. These two JSRs together will finally provide a unified stack for developers to build on.

So, to answer your question, once you have that unified platform on a majority of handsets from the main manufacturers and operators, developers will have a much easier time building a variety of applications, even beyond games and entertainment.

Frank Sommers: Why have two separate JSRs for defining that common Java ME stack?

Asko Komsi: Both of these JSRs address the handset, but the difference is in the types of applications each JSR makes possible, and in the business cases these JSRs serve. If you look at what's happening with handsets today, and what they're used for, there are all kinds of mobile games and multimedia services provided for consumers. That's the area JSR 248 serves.

In the consumer space, a model emerged for developers to bundle their applications in a MIDP-type package. That package can then be bought by consumers, downloaded to [consumers'] handsets, and then simply used on those handsets. The price-point for those applications is typically not that high, with the biggest business for those applications being games. JSR 248's focus is to make sure we have all the APIs available [on the handset] for games and multimedia-type features.

The JSR 248 stack is excellent for applications that use 3D graphics [Mobile 3D Graphics API, JSR 184], it provides a Mobile Media API [JSR 135], and you can even create person-to-person games with the included BlueTooth API [Java APIs for BlueTooth, JSR 82]. You can build applications that use SIP [SIP API for J2ME, JSR 180], and you can use the Payment API [JSR 229] to pay for services and games on the mobile handset. You also have access to content handlers that allow you to view different types of content [Content Handler API, JSR 211].

While the target is primarily consumer applications, JSR 248 also offers features enterprises may find useful. For instance, Web services are supported with JSR 172 [J2ME Web Services], and you also have security and trust [Security and Trust Services API, JSR 177], which are very important for enterprises that require secure access to corporate data from a mobile device. Then the JSR 248 stack also provides location-based services with the Location API for J2ME [JSR 179]. That serves use-cases for applications where you want to provide access to enterprise data to, say, truck drivers needing location-specific information.

However, JSR 248 does not provide all the features enterprises need, mainly because JSR 248 defines a very static environment. With JSR 248, you have a fixed set of APIs a developer can use, you can download one application at a time, and run that application. The security feature is very simple: It's a sandbox where you can run the application. That's pretty much it. There is not much dynamic element in that environment. That's fine for certain kinds of applications, especially for consumer-type applications, but we think we need to move toward a richer, more powerful platform that offers features dynamically.

JSR 249 is about a dynamic environment. With JSR 249, you can dynamically download new APIs to the handset. What APIs are available on the handset is no longer tied to that handset or even to what the MSA initiative can provide you with JSR 248. I think that [dynamic environment] is really what enterprises, and even consumer applications, will need in the future.

For example, consider a situation where you have lots of data on the back-end, or an enterprise application that you want to access. Many enterprise software firms—such as IBM or BEA—offer some kind of middleware that allow you access to those applications or to the enterprise database. With JSR 248, all you can do is place some kind of middleware in your backend, and access that middleware through Web services from the handset.

But with JSR 249, you can provide that middleware on the handset. If an enterprise needs a new API, they can simply download that to all of their employees' handsets. JSR 249 provides a nice, secure framework to do that, with monitoring and everything. That dynamic download ability provides an advantage in how you architect a mobile application. If you can download the middleware to the handset, then not just one application can access that middleware, but you can implement many applications that access enterprise data through that middleware. You don't have to download [the middleware] multiple times: You just download it once, and when you need to access corporate applications, you already have that on your handset.

This dynamic download capability is really the only way to support enterprises. The other way is that Nokia and other manufacturers come up with IBM-specific handsets and BEA-specific handsets, with the [respective] middleware components pre-installed. As you can see, that doesn't work. Being able to download any API to the handset will, by contrast, help defragment the Java [ME] market. But it's very important on the consumer side, too. You can think of operators offering some kind of game-specific middleware that will be on your handset, and you can run multiple games on top of that.

Frank Sommers: Can you explain how JSR 249's dynamic API download works?

Asko Komsi: Our goal was to get JSR 248 out the door, and while we now have a clear charter to define in JSR 249 all that I mentioned, the expert group has not made any technical selections yet. We're just now starting to focus on JSR 249.

Note that MSA's charter is not to create any new technology, but to take technologies that are available, and combine those to create a nice unfragmented stack. From Nokia's perspective, we think that OSGI already offers us a lot of what we need, and it would provide an excellent framework for the dynamic environment we envision in JSR 249.

OSGI is not new to Java ME or to the JCP, because we already have JSR 232 [Mobile Operational Management], with Nokia and Motorola as the spec leads. From MSA's perspective, if we wanted to use OSGI, all we'd have to do would be to deploy JSR 232. JSR 232 was a way to combine the OSGI and JCP-based standardization efforts. We wanted to make sure that on the OSGI side we can define the technology and provide a reference implementation, and then bring all that technology to the JCP so that the technology is available not only to OSGI licensees, but to the JCP as well.

The OSGI environment provides not only for the download of applications and middleware to clients, but also monitoring, as well as a very secure framework where you can define any type of policies on components and for accessing the various APIs on the handset. As soon as you start moving to a JSR 249-type environment, you need to have security beyond what the sandbox environment offers, and OSGI addresses that dynamic security. And OSGI already provides mechanisms that take care of dependencies as well: What an application needs, the version numbers, and how to go and get the needed components.

The reason OSGI is so interesting is that it provides a lot of the features that I think we need to make CDC usable. 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.

Frank Sommers: With JSR 248 now pretty much finalized, when can developers expect MSA-compliant handsets in consumers' hands?

Asko Komsi: You will see MSA-compliant handsets by the end of this year or the beginning of next year. The average use-life of a handset used to be something like eighteen months, or roughly less than two years. How quickly handsets get replaced depends once again on the market. In Europe, you can just go and buy a new handset, take your SIM [chip] and put it into that new handset. People often have multiple handsets—one for barhopping, one for work, and one for home. In the US, you buy a contract and you're tied to that handset for one or two years. But in about two years, most handsets on the market will offer JSR 248 compatibility.

Frank Sommers: You brought up MIDP. Can you explain how MIDP, as well as CDC and CLDC relate to the MSA initiative?

Asko Komsi: CLDC [Connected Limited Device Configuration 1.1, JSR 139] and CDC [Connected Device Configuration, JSR 218] are the foundation for everything else, and they define a virtual machine environment. CLDC is a smaller subset of CDC. Other APIs exist on top of CLDC and CDC.

From Nokia's perspective, I don't think we should focus that much on what the virtual machine should be. We think that CLDC is a very important configuration, but as we are developing more powerful handsets, there will be more memory and more powerful CPUs, and we think we're moving away from the limited configuration to a standard CDC environment. That's something we see happening in the future, and that's one reason we support JSR 249, because we're going towards a more powerful and capable environment. That will lead to less of fragmentation, too, as devices will have more capabilities.

When you look at MIDP, the MIDP 3 profile [Mobile Information Device Profile 3, JSR 271] is led by Motorola, but Nokia is part of that standard, too. While MIDP has been successful so far, it will also have to move into a direction where it offers new features. I can't tell you what those features will be, because they're just now being defined.

Frank Sommers: You said that as handsets become more powerful, and as most manufacturers start supporting JSR 248, the mobile market will be less fragmented, since most handsets will converge on a core set of supported features. How will manufacturers then differentiate their products?

Asko Komsi: The handset is much more than just the Java platform. There are lots of places where you can differentiate. But even on the Java platform, you can still differentiate in the implementation. At Nokia, we naturally think that we have a very friendly Java implementation. In the user interface, you don't necessarily see that you're using a Java application or a native application: Java applications act well together with non-Java applications on the handset.

If you look at it from a handset manufacturer's perspective, we would like to have a standard platform now for handsets. For us, it's pretty much a resource and cost issue. If we have to develop variations of our handsets for every operator, and for every single market, that's going to cost us a lot, which means that the handsets will be more expensive for the operators. The operators also should have an incentive to go with the standard. That's one reason Nokia is leading the MSA initiative. By defragmenting the market and defining the spec, we may lose some capability to differentiate but, from our perspective, it's much more important to come up with an API that's good for developers, good for the operators, and good for the service providers.

Frank Sommers: You mentioned operators. Besides differences in handset capabilities, developers also have to contend with differences between mobile network operators. That concern just doesn't exist in the more stationary world of developing applications that are accessed via a regular desktop browser or desktop application. For those apps, whether a user accesses the network through a Verizon fiber-optic line, an ATT DSL connection, or a Spring frame relay, is immaterial to the application developer. To what extent do differences in mobile network operators impact the developer?

Asko Komsi: The real question is how well the data connection works, if your application needs to access external data sources. There are applications that the user just downloads, and that don't require any kind of external connectivity. That kind of application will not be impacted much by operator differences. The single user can just download that application from the provider's server, and that's it. As soon as you start connecting to other servers, though, you may run into problems.

Frank Sommers: The latent issue here is that many people have a desire to circumvent the operator. Do you see that at some point the operator's role will be minimized, and the developer can more or less communicate directly with the consumer, as in the non-mobile world?

Asko Komsi: There will probably be different types of operators. Some will see it as an advantage to offer open connectivity. Even if you offer open connectivity, it doesn't mean you couldn't offer services, too. You can do both, and play the roles of both connectivity provider and service provider. Then there will be providers who will offer their own kind of world within which consumers can come and obtain content and services. The markets will decide what works better.

An important aspect of all of this is that providers worry about the consumer. One scenario is that mobile phones become like PCs, with no safety, and are inundated with viruses and spyware. Security is even more of an issue with handsets than with PCs: Handsets tend to contain a lot of your personal information—your contacts, your photos. In Europe, many people do their banking with mobile handsets, and that information is also stored on the handset. Who makes sure that the security and safety is there? Is that the responsibility of consumers, manufactures, or the service providers?

At the same time, if you look at what's happening in enterprises, where people want access to their enterprise data centers from home broadband connections, and now increasingly from their mobile handsets, the mobile space will have a very difficult time preventing some kind of open connectivity option from handsets. That will eventually become a reality.

Frank Sommers: You mentioned people in Europe using their mobile phones for payment. If you travel to other countries, you can't help but notice that the US is still behind Europe and Asia in how people use mobile devices. Why do you think that is, and when do you think we in the US will catch up?

Asko Komsi: One thing that helped Asia and Europe is that they agreed early on on one kind of technology, GSM. As a result. interoperability has not been a big issue. Once you have a GSM handset, it works, no matter where you go. Text messaging has always worked, telephone calls work, data services work.

In the US, there has been this technological battle between GSM and CDMA that has taken a lot of resources from the operators and cost a lot of money. That delayed the creation of good interoperable offerings to consumers. Consumers don't care what technology they're using. They would just like to see services that work, no matter where they are, and don't want to have to think about what operator's network they're on.

That's one part of it. But even with GSM, it took a while in the US before operators really started cooperating, for instance, by making sure that text messaging works between different operators. That works now, but you don't have to go back many years when that didn't work. So, convergence on the network technology and increased interoperation between operators will enable the US mobile market to progress much faster.

Frank Sommers: If a developer wants to enter the market for applications for handsets, what are the avenues you recommend a developer take?

Asko Komsi: First of all, they should really take a look at the JSR 248 specification and study the APIs that are part of that stack. From Nokia's perspective, we have Forum Nokia that offers free support for Java developers. You can sign up, and then get access to all the documentation for Nokia handsets, including those that support MSA. You can learn there about what tools you can use to develop for Nokia handsets. Other manufacturers have similar offerings.

Since Forum Nokia supports the MSA standard, all the information there should be applicable to handsets from other manufacturers supporting that standard as well. The APIs should be compatible. You always have some form factor differences because handsets don't have the exact same display sizes. But mobile developers have been dealing with that issue for years now, and have been able to solve that challenge quite nicely.

Distributing the application is the hard part at the moment. You can't just put an application out there and expect people to start using it. Currently, developers have to go through the operators. Since MSA doesn't provide a solution for that, the only thing I can talk about is what Nokia offers in that space: Preminet. This is a turn-key solution that allows an operator to offer services and applications to the consumer. We run a catalog of applications for the operator, and can even host that service. With this system, the developer can have just one contact point to get his application listed in the Preminet catalog, and through that the application will be available to any operator's customers, as long as the operator buys into this Nokia service. Nokia offers this as a simple channel to help developers put

Resources

Mobile Service Architecture, JSR 248:
http://www.jcp.org/en/jsr/detail?id=248

Mobile Service Architecture Advanced, JSR 249:
http://www.jcp.org/en/jsr/detail?id=249

The following are component JSRs of MSA:

Connected Limited Device Configuration 1.1 (CLDC), JSR 139:
http://www.jcp.org/en/jsr/detail?id=139

Mobile Information Device Profile (MIDP) 2.1, JSR 118:
http://www.jcp.org/en/jsr/detail?id=118

Connected Device Configuration, JSR 218:
http://www.jcp.org/en/jsr/detail?id=218

PDA Optional Packages for the Java Platform, JSR 75:
http://www.jcp.org/en/jsr/detail?id=75

Java APIs for BlueTooth, JSR 82:
http://www.jcp.org/en/jsr/detail?id=82

Mobile Media API, JSR 135:
http://www.jcp.org/en/jsr/detail?id=135

Mobile 3D Graphics API, JSR 184:
http://www.jcp.org/en/jsr/detail?id=184

Wireless Messaging API 2.0, JSR 205:
http://www.jcp.org/en/jsr/detail?id=205

Scalable 2D Vector Graphics API for J2ME, JSR 226:
http://www.jcp.org/en/jsr/detail?id=226

J2ME Web Services, JSR 172:
http://www.jcp.org/en/jsr/detail?id=172

Security and Trust Services API, JSR 177:
http://www.jcp.org/en/jsr/detail?id=177

Location API, JSR 179:
http://www.jcp.org/en/jsr/detail?id=179

SIP API for J2ME, JSR 180:
http://www.jcp.org/en/jsr/detail?id=180

Content Handler API, JSR 211:
http://www.jcp.org/en/jsr/detail?id=211

Payment API, JSR 229:
http://www.jcp.org/en/jsr/detail?id=229

Advanced Multimedia Supplements, JSR 234:
http://www.jcp.org/en/jsr/detail?id=234

Mobile Internationalization API, JSR 238:
http://www.jcp.org/en/jsr/detail?id=238

Talk back!

Have an opinion? Readers have already posted 1 comment about this article. Why not add yours?

About the author

Frank Sommers is an Artima senior editor.