Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 136: JavaTM Technology for Service Providers

Stage Access Start Finish
Withdrawn   19 Mar, 2004  
Expert Group Formation   19 Jun, 2001 18 Mar, 2004
JSR Review Ballot View results 05 Jun, 2001 18 Jun, 2001
Status: Withdrawn
Reason: Community support was not sufficient to support an Expert Group.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

This would have correlated JSRs targeted at next-generation service providers, documented how these JSRs fit together within end-to-end service provider networks, and introduced developers to emerging service provider network-targeted APIs.

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

Specification Leads
  Mauricio Arango Sun Microsystems, Inc.
Expert Group
  Oracle Sun Microsystems, Inc.  

This JSR has been Withdrawn
Reason: Community support was not sufficient to support an Expert Group.

Original Summary: Over 20 JSRs targeted at next generation service provider networks are being specified by the Java community. This specification will consist of a set to documents that will correlate these JSRs, document how these JSRs fit together within end-to-end service provide networks, and introduce service provider developers to the Java APIs targeted at emerging service provider networks.

Section 1. Identification

Submitting Member: Sun Microsystems

Name of Contact Person: Swee Lim

E-Mail Address:

Telephone Number: (650) 786-6819

Fax Number: (650) 786-8611

Specification Lead: Swee Lim

E-Mail Address:

Telephone Number: (650) 786-6819

Fax Number: (650) 786-8611

List of other Participants who endorse this JSR:

  • Cygent
  • dynamicsoft
  • Fujitsu
  • Motorola
  • NEC
  • Nortel Networks
  • NTT
  • Telcordia Technologies
  • Ubiquity
  • Ulticom
Initial Expert Group Membership:

Projected expert group will include experts from:

  • Network equipment providers
  • Network service providers
  • OSS vendors
  • Next generation network software providers

Section 2: Request

2.1 Please describe the proposed Specification:


The service provider community has been actively driving Java into the service provider industry. This community has submitted over 20 JSRs (see Section 3). Most of these JSRs are hosted under two distinct and independent initiatives; JAINTM and OSS through JavaTM. These JSRs define Java APIs that enable rapid development and deployment of innovative and revenue enhancing applications and services for next generation integrated networks and wireless networks.

  • The JAIN initiative is focused on the emerging network protocols and architectures of both traditional telecommunications networks and next generation integrated networks. JAIN APIs are targeted at developers building applications for softswitches, media gateways, service provider network application servers, and client applications that interact with these service provider networks. Currently, there are 20 JAIN JSRs. These JSRs define APIs for SS7 protocols (such as TCAP, ISUP, MAP, INAP), IP protocols (such as SIP, H.323, MGCP, MEGACO), call control/switching (JCC, JCAT), service provider network open access (JAIN SPA APIs), and application execution/creation environments (such as SLEE, SCE, SIP Servlet).

  • The OSS through Java (OSS/J) initiative is focused on the operations and business support systems ("back office systems") of service providers. The OSS/J APIs are targeted at OSS developers within network equipment vendors, independent software vendors (ISVs), system integrators, and service providers. Currently, there at 3 OSS/J JSRs. These JSRs define APIs for service activation, quality of service, and trouble ticket systems. The initial focus of OSS/J is on 3G wireless networks.
This JSR will correlate the JSRs and APIs produced under these two independent initiatives, as well as, other future initiatives that are focused on service providers.

Scope of this JSR

The primary output of this JSR is a set of documents. This JSR and the resulting specification will:

  • Explain how the above JSRs and Java APIs fit together in one or more end-to-end service provider network architectures.

  • This JSR will correlate and reference the above JSRs in the Java Technology for Service Providers specification. This specification will include a broad overview of the components in current and emerging service provider network architectures, such as PSTN, 2G/3G Wireless, and/or next generation converged networks. It will show which JSRs and APIs are applicable to an individual component and how Java APIs are used to interface related components.
  • Introduce developers to the above service provider Java APIs.

  • This introduction will be provided in the form of a developers guide describing the use and application of the above APIs. This guide may contain code examples illustrating the concurrent use of multiple APIs, common design and interaction patterns, distribution techniques, pitfalls, and recommended coding practices. The JAIN and OSS/J initiatives will continue to provide detailed design and architectural guidelines for JSRs within their respective areas of interest.
  • Complement the JAIN initiative and OSS/J initiative.

  • This JSR recognizes and respects the independence and autonomy of these initiatives from each other and from this JSR. Each initiative's intense focus on their respective areas of interest have been instrumental and very successful at motivating in-progress JSRs and initiating new JSRs within their respective communities. This JSR will continue to depend on these independent initiatives, their respective communities, and their JSRs to define APIs, including future directions and roadmaps. This JSR will embrace the JSR specifications defined under these initiatives, incorporate them by reference into this JSR, and show how the JSRs initiated by these initiatives fit within the above end-to-end service provider network architectures. This JSR should exploit synergy's and avoid duplicating work done by these initiatives. However, the administration of this JSR will be autonomous and independent of the above initiatives..
  • Depend on existing JSRs to revise existing APIs.

  • While working on this JSR, this JSR may receive suggestions and/or become aware of a need to revise APIs being defined by a pre-existing JSR. This JSR will pass on these suggestions and findings to the appropriate JSR's expert group for their consideration and evaluation. Revisions and changes to these APIs will remain the charter of the appropriate JSR's expert group.
  • Provide an initial point of contact for information related to service provider Java APIs.
During the JCP, the expert group may
  • Discover new opportunities for the use of Java technology and APIs in end-to-end service provider networks that are not being addressed by the existing JSRs. This JSR may help to solicit the Java service provider community to initiate a new JSR to address these new opportunities. In addition, a JSPA participant who wishes to submit a new service provider related JSR may also seek guidance from this expert group. In both cases, if the new JSR and an existing initiative, such as OSS/J and JAIN, appear to be a good fit for each other, this JSR may recommend that the new JSR be hosted under the appropriate existing initiative. Since this JSR is expected to maintain a close working relationship with both the JAIN and OSS/J initiatives, this JSR can also assist in referring and introducing the new JSR to these initiatives. This JSR intends to be inclusive in nature and intends to incorporate by reference appropriate new service provider related JSRs into this JSR.
  • Discover opportunities to leverage commonality and reduce redundancy. This JSR provides an opportunity to up-level commonality and redundancy discussions to all service provider APIs, including sharing of common design patterns, guidelines.

  • Discover a need or demand from the service provider industry for new profiles, such as a softswitch profile and/or a telecom application server profile. This JSR may help to solicit support from the Java service provider community to initiate new JSRs to define new profiles, and may assist the effort by providing guidance and contributing suitable expertise when requested.

  • Discover a need or demand for APIs, such as classes and interfaces, that are common to multiple initiatives and service provider JSRs. This JSR intends to maintain its focus on documenting how individual JSRs fit into service provider network architectures, and avoid being distracted by API definition activities within this JSR. Therefore, this JSR intends to solicit existing initiatives when appropriate to create the necessary JSRs to define these common APIs.

  • Provide guidance to the J2SE and J2EE Executive Committee on new service provider related JSR submissions (as suggested and/or requested by the EC).

  • Receive comments for new Java APIs for new areas of interest to service providers. If an existing initiative is appropriate, this JSR will forward these comments to the existing initiatives for evaluation.

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

This specification targets both the J2SE platform and the J2EE platform. The target platform will be determined by the individual JSRs referenced by this specification.

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

Currently, there are over 20 JSRs targeted at the service provider industry and its Java developers. There is a need in the service provider industry and Java community to understand how these JSRs (and APIs) fit together, and how to build an end-to-end Java technology based solution. This JSR will address this need by defining an overall Java Technology for Service Provider architecture which will provide guidance to developers on the use and application of these APIs within the end-to-end service provider network. It will stimulate and facilitate adoption of Java technology in the service provider network. It will also open new market opportunities for vendors in the Java community.

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

The current service provider JSRs target and focus on specific application areas or components within the service provider network. For example, a JAIN protocol JSR focuses on a specific SS7 or IP protocol, while an OSS/J JSR focuses a specific OSS application, such as service activation. There is no existing JSR that attempts to provide a comprehensive overview of how many of the existing JSRs are related and how they fit within the end-to-end service provider network.

This JSR complements the existing service provider JSRs. It presents a macro overview that embraces all the above JSRs, while the existing individual JSRs present detailed views into specific components and their APIs within the Java Technology for Service Provider architecture.

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

This is covered in Section 2.1.

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

Not applicable. This JSR will not define APIs.

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.

The expected schedule for this specification is about 1 year. The target milestones for this JSR are listed below:

Community Draft: Jan 2002
Public Draft: March 2002
Final Draft Proposal: May 2002
Final Release: July 2002

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.

Primary form of collaboration will be via email and augmented by regularly scheduled conference calls when necessary.

Since it is expected that the expert group will consult with the JAIN and OSS/J experts, face-to-face meetings will be coordinated with regularly scheduled meetings of these communities to facilitate fluid exchange of information and encourage participation by the experts of these initiatives. The administration of this JSR will be autonomous and independent of the JAIN and OSS/J initiatives.

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.

For the following JSR contributions, see


  • JAIN TCAP (JSR 11)
  • JAIN ISUP (JSR 17)
  • JAIN OAM (JSR 18)
  • JAIN JCC (JSR 21)
  • JAIN SLEE (JSR 22)
  • JAIN MGCP (JSR 23)
  • JAIN SPA (JSR 24)
  • JAIN MAP (JSR 29)
  • JAIN SIP (JSR 32)
  • JAIN INAP (JSR 35)
  • JAIN H.323 (JSR 81)
  • JAIN SPA 2.1 Mobility (JSR 98)
  • JAIN Service Creation Environment (SCE) (JSR 100)
  • JAIN SPA 2.1 Generic User Interaction (JSR 103)
  • SIP Servlet API (JSR 116)
  • JAIN SPA 2.1 Integrity Management (JSR 119)
  • JAIN Java Coordination and Transaction (JCAT) (JSR 122)
  • JAIN SPA 3.0 Presence and Availability Management (PAM) (JSR 123)
  • JAIN SIP Lite (JSR 125)
  • JAIN OAM 2.0 (JSR 132)
OSS through Java JSRs
  • OSS Service Activation (JSR 89)
  • OSS Quality of Service (JSR 90)
  • OSS Trouble Ticket (JSR 91)
  • OSS IP Billing (JSR 130)
Related telephony, service provider JSRs
  • JTAPI 2.0 (JSR 43)
  • Phonelets API (JSR 61)
Related JSRs currently being drafted and will be submitted in the near future

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

This specification will reference the above JSR specifications and show developers how these specifications fit into a Java technology architecture for service providers.