Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 212: Server API for Mobile Services: Messaging - SAMS: Messaging

Stage Access Start Finish
Maintenance Release Download page 12 Jan, 2005  
Maintenance Draft Review 2 Download page 18 Nov, 2004 20 Dec, 2004
Maintenance Draft Review Download page 17 Sep, 2004 18 Oct, 2004
Final Release Download page 15 Jul, 2004  
Final Approval Ballot View results 08 Jun, 2004 21 Jun, 2004
Proposed Final Draft Download page 02 Jun, 2004  
Public Review Ballot View results 27 Apr, 2004 03 May, 2004
Public Review Download page 31 Mar, 2004 03 May, 2004
Community Draft Ballot View results 25 Nov, 2003 01 Dec, 2003
Community Review Login page 30 Oct, 2003 01 Dec, 2003
Expert Group Formation   29 Apr, 2003  
JSR Review Ballot View results 15 Apr, 2003 28 Apr, 2003
Status: Maintenance
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

This specification defines a protocol agnostic messaging API for composing, sending and receiving short messages and multimedia messages. The API shall work on the J2SE and J2EE.

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Hannu Mettala Nokia Corporation
Expert Group
  Apache Software Foundation BEA Systems Beacock, Andrew
  Cingular Wireless Incomit AB IOPSIS Software Inc.
  Jain, Myank Logica Cmg Wireless Networks Matsushita Electric Industrial Co., Ltd.
  Nesek, Vjekoslav Nokia Corporation Oracle
  Siemens AG Sun Microsystems, Inc. Vazquez, Johann
  Yuan, Michael Juntao

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Original Summary: This specification will define a protocol agnostic messaging API for composing, sending and receiving short messages and multimedia messages. It provides a client API to Short Message Service (SMS) and Multimedia Messaging Service (MMS) servers. The API shall work on the J2SE and J2EE.

Section 1. Identification

Submitting Member: Nokia

Name of Contact Person: Mikko Kolehmainen

E-Mail Address:

Telephone Number: +358 40 589 2725

Fax Number: +358 71 806 8467

Specification Lead: Petri Niska

E-Mail Address:

Telephone Number: +358 50 483 6253

Fax Number: +358 71 803 6855

Initial Expert Group Membership:


Supporting this JSR:

Sun Microsystems, Inc

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR will define a standard, portable and protocol agnostic messaging API for SMS and MMS, which enables composing, sending and receiving short messages and multimedia messages. Multimedia message is a message containing text, images and sound. Short messages primarily contain text only, but they can also be used as a bearer for binary data. Both message types are mainly aimed to be sent from a mobile terminal to a mobile terminal. However, there is an increasing need to be able to send these messages also from J2SE/J2EE applications. Content creation tools for images and sound are out of scope. Multimedia messaging service is one of the primary services mainly targeting the third generation mobile system (3G), but applicable also for GSM. SMS was already introduced for GSM networks. Both synchronous and asynchronous message processing will be supported where applicable.

This specification will define a high-level messaging API, which is independent of the underlying network protocols, data formats and technologies for communicating with SMS and MMS servers. The run-time architecture will also enable easy plug-in of implementations for existing and future SMS and MMS protocols, data formats and technologies. It will be possible to specify at the run-time which SMS or MMS implementation driver is used. It may also be possible in the future to add support for other messaging standards than SMS and MMS.

This JSR will be specified within the JAIN community.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification is targeted for use by the Java 2 Standard Edition and Java 2 Enterprise Edition platforms.

2.3 What need of the Java community will be addressed by the proposed specification?

The existing and emerging mobile network services and related interfaces in the mobile networks and terminals create opportunities for innumerable new value-added services and applications. The first and still very successful mobile network service is SMS. One of the most promising of the new mobile network services is multimedia messaging. The proposed API enables Java applications on top of J2SE/J2EE to compose, send and receive short messages and multimedia messages. With a standard Java messaging API developers can implement value-added mobile services and applications independent on the underlying network infrastructure and protocols. The success of 3G depends heavily on these new services and applications. Because of the wide popularity of SMS based services and the launching of MMS services on top of GSM networks has rapidly started all over the world, there is an urgent need for the Java messaging API for SMS and MMS also on top of J2SE/J2EE.

Additionally, the proposed specification serves as an example for future Java APIs accessing other mobile network services as explained in the chapter 4.1.

2.4 Why isn't this need met by existing specifications?

There are no Java SMS or MMS APIs for J2SE/J2EE.

2.5 Please give a short description of the underlying technology or technologies:

Short message service is a wireless communication service originally specified for GSM networks.

Multimedia messaging service is one of the services mainly targeting the third generation mobile system and specified by the 3rd Generation Partnership Project (3GPP).

This API will be independent of the underlying network protocols, data formats and technologies for communicating with SMS and MMS servers.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.8 Are there any security issues that cannot be addressed by the current security model?


2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

Community Review: June 2003
Public Review: September 2003
Proposed Final Draft: December 2003
Final Approval: January 2004
This schedule is subject to change. The actual schedule will be determined by the expert group.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

Continuous email communications, with occasional telephone conferences and infrequent face-to-face meetings (as needed), which will be teleconferenced.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.


2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

It is Nokia'intention to create as open license model as possible under the terms of JSPA2. However, the details of the licensing model shall be provided later on in accordance with JCP 2.5. The following terms are for early information and are therefore subject to change: - Nokia will license to interested parties the RI separately from TCK and will not charge license fee from the RI - The intention is that the TCK will be licensed free of charge to not-for-profit organizations and individuals - For others, the intention is that the TCK will be licensed on basis of one-time fee + annual maintenance fee.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

JSR 120 Wireless Messaging API:

JSR 205 Wireless Messaging API 2.0:

SMS-API: ETSI TS 100 901 V7.4.0 (1999-12) Digital cellular telecommunications system (Phase 2+);
Technical realization of the Short Message Service (SMS);
(GSM 03.40 version 7.4.0 Release 1998):

MMS-API: 3GPP TS 23.140 V5.4.0:

Parlay X/OMA Web Service interface for MMS:,

3.2 Explanation of how these items might be used as a starting point for the work.

JSR 120 defines an API that provides a standard access to wireless communication resources in J2ME. Specifically, it defines an interface for sending and receiving short messages for J2ME.

JSR 205 will define an interface for composing, sending and receiving multimedia messages for J2ME and MIDP. It is based on JSR 120.

Even though it would be advantageous if the messaging APIs for J2ME and J2SE/J2EE would be similar it is not intention to follow JSR 120 and 205 programming model. Additionally, the API proposed in this JSR serves as an example API for future mobile network service APIs and therefore the scope is larger.

ETSI TS 100 901 V7.4.0 is the specification for the SMS API.
3GPP TS 23.140 V5.4.0 is the specification for the MMS API.
Parlay X/OMA will specify a Web Service interface for MMS.

It will serve as an example of a specific network implementation technology for MMS, on top of which the proposed Java MMS API is also expected to have an implementation.

The Parlay X Web Service specification for MMS is expected to be public soon.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

An essential goal of this JSR is that the proposed API will be easy and intuitive to learn and use and thus enable Java community with a head start to MMS based services. Furthermore, this API will be an example API for specifying APIs for other mobile network services, such as delivery, device management and so on. For that purpose, guidelines for specifying APIs will be written e.g. in an appendix of this specification or in a separate white paper. By following these common guidelines the APIs will be consistent, which will further shorten their learning and adoption curve. The same naming schema is also suggested for other JSRs following these guidelines, i.e. Java API for Mobile Services (JAMS): .