Mobile Service Architecture (MSA) 2
Interesting, I just read via Olle’s blog JavaWire, about MSA version 2 (JSR 249)… I haven’t been able to keep up with JSR 249 for a while; so I decided to take a look at it today.
…wow, lots of things have happened. For one, it is no longer called MSA for CDC, but now its called MSA 2; I think they made the right call, good:
Unlike the first version of MSA (specified in JSR-248), MSA 2 does not only cover Java feature phones (CLDC phones), but also more advanced phones (CDC phones). MSA 2 will specify three different sets of API – a limited, a core, and a full set – for different types of phones, from low-end phones to advanced smartphones.
Interesting. They followed the JSR 248 concept of API stacks. With MSA2, the API stacks are as follows:
Click to Enlarge (Source: MSA2 spec)

Click to Enlarge (Source: MSA2 spec)
Very cool. I’m very excited to see the new APIs that MSA2 includes:
- MIDP3 (JSR-271)
- Mobile Sensor API (JSR-256)
- Contactless Communication API (JSR-257)
- Mobile User Interface Customization API (JSR-258)
- Mobile Broadcast Service API (JSR-272)
- XML API for Java ME (JSR-280)
- IMS Services API(JSR-281)
This is great news; from NFC to IMS; can’t wait.
I do see (or fail to see) some JSRs that should be considered for inclusion:
- JSR 304: Mobile Telephony API version 2 -or- JSR 253 MTA version 1
- JSR 266: Unified Message Box Access API (UMBA-API)
- JSR 307: Network Mobility and Mobile Data API
MSA 2 looks hot. If all these APIs get delivered consistently across all handsets, we will be in business…
Related MSA news:
- MSA at JavaOne (Johan Vos)
ceo

“MSA 2 looks hot. If all these APIs get delivered consistently across all handsets, we will be in business…”
Many will be out of business as device fragmentation and devices related issues (see deployment and porting) have a big role in mobile development.
I hope still be in business and without having to remember that model X of brand Y has this or that implementation, that would be nice.
Keep fingers crossed
Greetings
Just don’t put all the eggs in one basket.
Or, screw it, let many go out of business, so that the few who are brave to deal with this issue of fragmentation and decide to continue pushing forward, those shall win, and grab the market. Mobility today is not for the faint-of-heart.
That said, MSA 2 API set look strong…
ceo
The reason for JSR-304,266,307 being left out is that they are all so called “BenQ” JSRs, meaning that the licensing of these APIs is very unclear since BenQ went bankrupt, and there is no way to get access to the TCKs for these JSRs.
Interesting… thanks. Would this be the case even if they used Mobile Telephony API (MTA) v1 (JSR 253)?
What do you think of the branding message with this JSR? My concern is that with all of the different stacks, it does not create a clear message that can be marketed against Android. I think it may be a mistake not to keep MSA2 exclusive to a single stack, with the only optionality being those JSR’s conditional on hardware.
I believe there is and always be classes of handsets: low, mid and advanced. It is a matter of economics. Because this is a generic stack regardless of device manufacturer, it must cater all those classes of handsets; having only one stack means catering only one class of device.
So I feel that it is OK to have low, mid, and advanced stacks, based on hardware functionality support -and- OS functionality support, as long as the stacks are consistently implemented across ALL handsets, both functionality and behavior-wise.
ceo
Good points. My thinking was that to make a clear branding message MSA should remain, and MSA2 should be for advanced handsets. I don’t really understand the reason behind deprecating MSA, and duplicating much of it in MSA2. MSA would eventually die out as the capabilities of the lower tier rise to the MSA2 level.
My concern is that with a marketing message of “JSR-249 mid-segment with JSR-xyz conditional support and the following option JSR’s” there is no way to market this consistently. MSA2 alone will be a meaningless brand without all of the qualifying statements.
A clear brand that removes some of the fragmentation seems important to Java at this point.