Ask the Experts

August 20 - August 24, 2007
Experts: Mikhail Gorshenev, Hinkmond Wong, and E-ming Saung

Mobile Service Architecture (MSA) is a Java ME optional package that defines the next generation Java ME platform and serves as a follow-on to Java Technology for the Wireless Industry (JTWI). In this Ask the Experts session, Mikhail Gorshenev, Sun's lead for the JSR 248 Technology Conformance Kit (TCK), E-Ming Saung, Product Line Manager in the Java ME Marketing group, and Hinkmond Wong, one of the current project owners of the phoneME open source project, answered a variety of questions about MSA.

Sally Minh: Does having MSA mean that if I write a MIDlet once for MSA, it will finally be able to run on other cell phones without having to test it and tweak it?

Mikhail Gorshenev: One of the biggest challenges with the mobile application development market is known as fragmentation. Fragmentation is not a single problem, but is a set of different issues: lack of an overarching standard defining which versions of which mobile JSRs must be implemented, optionality allowed by different JSRs, as well as the implementation quality.

MSA (JSR 248) is a step towards resolving these issues. It does create the standardized set of mobile JSRs and eliminates many (though not all optionalities). MSA does not directly address the implementation quality issues, thus we may still see some interoperability problems. But with MSA in place application portability will be greatly improved.

justin joseph: Is there any standard method to get the cell info on Symbian OS across the models?

Mikhail Gorshenev: There is no MSA API to get cell network information such as signal strength or the cell ID. However, MSA does include the Location API (JSR 179), which can be used to determine the physical coordinates and orientation of the handset.

Ramesh S: What's the relationship between JSR 248 (MSA) and JSR 249 (MSA Advanced)?

Hinkmond Wong: JSR 248 (MSA) was targeted originally for CLDC devices or what are called "volume handsets" or "feature phones"". They represent the highest number of cell phones that are shipped today with cost-effective CPUs, memory, and overall hardware to keep costs low as a primary objective. JSR 249 (MSA Advanced) targets CDC devices or what are called "advanced phones" or "smartphones". These phones have higher-end CPUs, more memory, are generally more expensive and have higher capabilities than feature phones. These advanced phones are used much of the time in the enterprise market for corporate wireless applications. So, while JSR 248 (MSA) addresses the everyday cell phone consumer, JSR 249 (MSA Advanced) can be viewed as addressing the higher-end cell phone user who much of the time requires more advanced features such as enterprise wireless application support. The advanced phones of today are expected to become the mass market phones of the future.

Ed Welch: We want to have native text input in our game (i.e., multi-tap, or t9), without needing to use the textbox, or textfield (because the text control has a style incompatible with the rest of the game and it can't be incorperated within a low level drawn screen). Will this be possible with the new Mobile Service Architecture?

Hinkmond Wong: No, unfortunately MSA does not allow for native text input integration, such as with T9. Instead, you should look for device-specific packages that may support what you want, for example, the com.mot.iden.t9 Java package for the Motorola IDEN phones.

Eric Lenahan: With MSA and MSA-Subset are there only two variations or can implementers select JSRs from the full set not included in the subset? For example, could "MSA Subset + JSR 172 + JSR 179" be called an MSA device?

Mikhail Gorshenev: It is not prohibited by either the MSA spec or the MSA TCK to include additional JSRs. A device implemeting extra JSRs on top of the MSA subset is considered an MSA Subset device and is certified as such. A device like this will support all applications written for the MSA Subset, but not for the full MSA. Note that such devices are also not required to implement any MSA requirements which are not part of the MSA subset. So applications cannot rely on them.

Jack Kwok : 1. What are the first set of phones I can buy which are MSA compliant? 2. How consistent are the MSA implementations across OEMs? I need to estimate the level of work required to port an MSA app across handsets.

E-ming Saung:

What are the first set of phones I can buy which are MSA compliant?

The first phones that have been announced with support for MSA are the Sony Ericsson Z750, K850, and W910. They haven't been released yet, but are expected to release in Q3 2007 for the Z750, and Q4 2007 for the K850 and W910. You can also check our Java ME device matrix for an updated list of devices that will support umbrella JSRs like MSA, and other optional package JSRs.

How consistent are the MSA implementations across OEMs? I need to estimate the level of work required to port an MSA app across handsets.

The intent of MSA is to help reduce the fragmentation by defining a base set of supported JSRs and to clarify the optionality that some of the optional package JSRs provided as a standalone JSR. Much of the optionality has been clarified and defined more specifically for OEMs to implement if they plan on supporting MSA. With such a large number of JSRs defined within MSA and clarifications, you will see much improved consistency of MSA implementations across devices that should reduce the amount of work in porting applications to different handsets.

Bruno Ghisi: I was wondering if you have some market numbers involving MSA and OEM in a time period (this and next year).

E-ming Saung: We don't have specific numbers, but Sony Ericsson has already announced the planned release of 3 new phones that will support MSA - Z750, K850, W910, all planned for availability in Q3 and Q4 of this year. Nokia has also planned for support of MSA in it's next gen series 40 handsets as announced at JavaOne 2007.

Just to compare, when JSR 185 - Java Technology for the Wireless Industry (JTWI) was announced, it took about 1 year before the first device was released that supported JTWI. With MSA, you'll have devices supported the new platform in less than a year, and we expect quicker adoption of MSA in new devices. We don't have any market numbers yet because there haven't been any shipping devices that support MSA yet, but if you look at our device matrix, you can see that after 4 years, the number of phone models that support JTWI is huge, and we expect to see the same level of adoption among the OEMs for MSA.

Guy Agin : Typically JSR 232 and OSGi are discussed in the context of Java applications and middleware management. However, it is often mentioned that the OSGi Framework allows you, in principle, to manage native components as well (perhaps through an interface called JNI?) Is this something that can be done today or does it require building additional functionality?

Hinkmond Wong: Yes, OSGi allows you to manage native components as well as Java apps and components on a device via JSR 232. There is no additional functionality that needs to be added to JSR 232 or to CDC to allow this, but of course you will first need an implementation of JSR 232 on top of CDC, such as the Prosyst implementation of OSGi on CDC, before you are able to attempt that. If you do have all the proper framework implemented on CDC for your device, that OSGi stack allows you to describe either native or Java components to install or start as services. So, in theory, if you have a Java app, like a calendar or phonebook app that needs to use a native shared library component, you can describe that dependency as an OSGi service and have the framework launch the Java app and install any needed native dependencies (like native libraries) when you want them. After OSGi installs all the proper dependencies, the Java app can use a native interface (such as JNI) to then call into the native library.

Guy Agin : JSR 232 and OSGi "operational management" requires a CDC environment. On Mobile Phones, CDC is targeted for very high end phones. What is the reason? Memory requirements? In a world of falling memory prices is that such an inhibitor? Are there other issues that complicate/inhibit implementing OSGi and CDC on mainstream mobile phones?

Hinkmond Wong: CDC by itself is targeted to run on phones with 32-bit processors and more than 2MB RAM/2MB ROM. (Note that OSGi will require more than that.) As Moore's Law works its magic on mobile phones, 32-bit processors (like the XScale and other ARM-based chips) plus 2MB RAM/2MB ROM are not considered features of "high-end phones" anymore, even though they were considered "high-end phones" back when JSR 232 was first started. Already in many places, these types of phones that can run CDC are considered mainstream mobile phones.

So, CDC targets where the mobile phone market is heading, not where it is currently, since as you point out, mobile phone features are always dynamically changing. The complication is that since CDC targets where mobile phones are heading, you cannot run out to your local store and buy a current phone to develop CDC applications (even though there are a few CDC phones in the market now, but they are not development devices). You must work with OEMs and/or carriers who are working on the next-generation mobile devices, which creates an extra step. But, it's worth it if you want to work on the next generation of devices.

Ove Nordstrom : What about JSR-249, any progress? Why is it delayed? Any new schedule? I read this at http://jcp.org/en/jsr/detail?id=249 the targeted schedule for the JSR is as follows:

Expert Group formation: September 2004
Early Draft Review: December 2004
Public Review: January 2005
Proposed Final Draft: May 2005
Final Approval Ballot: September 2005

E-ming Saung: The progress and completion of JSR 249 is more or less independent of the completion of JSR 248. As you can see on the JCP website, the original intent was for both JSR 248 and JSR 249 to be completed around the same timeframe. With JSR 248, it didn't get completed in the JCP until 1+ year later. The fortunate thing about JSR 248 is that it's building upon a well-defined core system of CLDC/MIDP/JTWI. With JSR 249, you have additional complexities because the wireless platform for CDC is less defined even at the level of what profile is to be used - personal profile, personal basis profile, mobile information device profile. It's taking longer to define what JSR 249 is because a compromise needs to be reached between the Expert Group for a platform that is still in its early stages of definition. There are several reasons that lead to the delays in the progress of moving JSR 249 forward:

1. No existing CDC wireless market to start from, so all Expert Group members have their own definition that don't necessarily sync up very well.
2. Being an open standard guided by the Expert Group, you have to reach a compromise between the different Expert Group members around what technologies will be supported. Sometimes this is not easy thing to do in such a large forum.

For an update on the schedule, I would recommend contacting the spec leads from Nokia and Vodafone.

C. Enrique Ortiz: With the number of interesting APIs not currently part of MSA (248) how often (quick) do you expect MSA to be updated to include those? Once a year? Will such revisions require a total new JSR or just a maint JSR?

E-ming Saung: To answer your question about how often MSA will be updated to include new JSRs, you don't want frequent updates to MSA because there is a normal time lag it takes to manufacture phones with a new standard, so you don't want a spec. to change while those batch of current phones are trying to be launched and catch on. You don't want a shifting standard normally and want at least several years for stabilization and adoption to occur. The expectation would be that every few years you would reset the baseline to include more APIs that define the Java ME platform.

A next revision of MSA which includes new components will require a new JSR with a new EG since it is not a small update. It took three years to go from JTWI to MSA ,which is very long, but we don't see a major MSA revision happening any time soon.

pankaj tripathi: I searched everywhere in the forums, but I could not get an answer to this question. So I'm submitting it here. My question is on J2ME technology. It is not possible currently to retrieve device personal information like imei/imsi numbers as it restricts the portability of J2ME since these options are manufacturer-dependent. Is there any support in J2ME that would enable us to read the code written in other language(c/c++) using JNI? In that case, if a developer needs to retrieve personal information from the device, he can write a code in c/c++ or any low level language and then further read it using JNI-like technologies in Java. That will not only support the portability of J2ME but also will improve the power of J2ME.

Mikhail Gorshenev: MSA (or any other Java ME technology based on CLDC) does not currently support native interface (JNI) for applications. This functionality is restricted for both memory and security reasons. While this restriction limits what the application can do on particular device models, it helps ensure portability of applications.

San Agarawal: What APIs are available to stream live video from a cell phone? Is there a way to access low level multimedia APIs? Is it possible to self start a J2ME application on a phone?

Hinkmond Wong: For streaming video see JSR 135: Mobile Media API (and possibly JSR 234: Java Game Profile) which are both part of MSA and are multimedia related JSRs.

There are not many low level types of APIs inside these JSRs, since each device can be very different in its multimedia capabilities. But, the above JSRs do a good job in exposing the most used multimedia functionality that most apps require.

If you want to self-launch MSA apps, you might want to take a closer look at JSR 211: Content Handler API. This JSR allows the application management software of the device to control the execution of Java ME applications.

Evan Goff: Please describe in detail the advantages of an MSA implementation in the context of a specific development effort. Assume the objective is to develop a photo-capture application to be deployed to an array of hand-held devices with cameras (iDEN, Nokia, Motorola, Blackberry, PocketPC, etc...) that simply capture an image, add it to a record store, and allow the user to review each captured image with the option to save it elsewhere on the network. I would anticipate possible differences in the implementation of displaying thumbnails of captured images on a form or canvas, perhaps in stored image retrieval on the device, and perhaps network connectivity. Additionally, the description of the security permissions in the .jad file could vary. Also, how might MSA make testing easier for this kind of Java ME development effort?

E-ming Saung: The benefits that an MSA implementation provides to developers are twofold. The first benefit is giving an application developer an expected set of APIs/JSRs implemented on an MSA-supported device. An application making use of JSR 135 (multimedia), and JSR 75 (PIM and file management) can expect to have available those APIs among all MSA supported devices. The optional features that are defined in specifications have clarifications attached to them to remove some of the optionality or better clarify any ambiguities.

The second benefit of MSA is not so much to do with testing the application itself, but reducing the amount of work of having to create different versions of an application and needing to test those different versions. This will reduce the complexity of how many products require testing, especially if you're porting the application to different handsets that all support MSA. MSA doesn't define a quality level for the implementation, which is up to all device manufacturers to define and meet, but it defines a set of APIs that must be made available for application developers to use. The important thing to understand here is that an MSA implementation only provides an expected and well-known set of APIs that application developers can use to create their compelling applications. You don't write an "MSA application", but you write an application that takes advantage of the APIs and clarifications defined within MSA. And that should make it easier for the application to be supported across over MSA supported devices.