Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 100: JAINTM Service Creation Environment

This JSR has been Withdrawn
Reason: Withdrawn when the Spec Lead asked to withdraw and no one from the Expert Group was willing to become the new Spec Lead.

Updates to the Java Specification Request (JSR)

The following changes have been made to the original JSR:

Specification Lead: John-Luc Bakker

E-Mail Address:

Telephone Number: +1 973 829 5062

Fax Number: +1 973 829 2645

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Original Summary: JAINTM Service Creation Environment (JAINTM SCE) is the specification for the JavaTM API to support and simplify the creation of portable telecommunication services delivered primarily to the JAINTM Service Logic Execution Environment (JAINTM SLEE), while not restricted to this class of Execution Environments. JAINTM SCE is part of the larger JAINTM API suite.

Section 1. Identification

Submitting Members: This JSR is submitted jointly by Netergy Networks, Inc. (Netergy) and Telcordia Technologies, Inc. (Telcordia).

Name of Contact Persons: Serge Masse (Netergy); John-Luc Bakker (Telcordia)

E-Mail Addresses: Serge.Masse@NetergyNet.COM;

Telephone Numbers: S Masse: 514-282-8484 x285; JL Bakker: 973-829-5062

Fax Numbers: S Masse: 514-282-9898; JL Bakker: 973-829-2645

Specification Leads: Serge Masse and John-Luc Bakker

E-Mail Addresses: Serge.Masse@NetergyNet.COM,

Telephone Numbers: S Masse: 514-282-8484 x285; JL Bakker: 973-829-5062

Fax Numbers: S Masse: 514-282-9898; JL Bakker: 973-829-2645

NOTE that this information has been updated since the original JSR.

Initial Expert Group Membership:
(Note that expert group members must have signed the JSPA.)

Not yet formed.

These companies have expressed an interest in joining the Expert Group:

Mahindra BT
Sun Microsystems
Hughes Software

Section 2: Request

2.1 Please describe the proposed Specification:

This JavaTM Specification Request (JSR) defines the standard software interfaces of the Service Creation Environment (SCE) for JAINTM. The JAINTM SCE is a set of software interfaces to support and simplify the creation of portable telecommunication services delivered primarily to the JAINTM Service Logic Execution Environment (JAINTM SLEE), while not restricted to this class of SLEEs.

By itself, the creation of telecommunication services is a complex process. In fact, based on market experience and understanding of the Service Provider business, the creation of a telecommunication service can be subdivided in various steps (or components), namely:

? Creation:Covering the creation of a service, including the assembly of components, possibly making use of service primitives. Examples of service primitives are JavaBeans and XML documents.
? Editing:Covering the modification (e.g., adding or removing functionality) and maintenance (i.e., correcting defects) of a service; this also covers the support of Integrated Development Environment (IDE) and Configuration Management (CM) components.
? Security:Covering security regarding the use of the SCE and the interaction with a SLEE, including a JAINTM-compliant SLEE.
? Testing:Covering the testing and validation of a service.
? Bundling:Covering the preparation of a service for its delivery to a SLEE, including the preparation for delivery to a JAINTM-compliant SLEE.

Note 1: Service delivery, activation, and security are already addressed by the JAINTM SLEE Specification. JAINTM SCE will be consistent with their definition in the JAINTM SLEE Specification.

Note 2: This JSR is not enforcing any specific creation environment (graphical, text-based, etc.) or implementation paradigm (Drag&Drop, XML editor, etc.). For example, a tool vendor can decide to use VXML as the basic technology to create a voice service for delivery to a JAINTM-compliant SLEE; in such a case, the vendor will have to provide the right mapping tool to translate the VXML logic into the proposed APIs in order to allow JAINTM SLEE service delivery.

Note 3: In JAIN Service Provider API (JSR #000024), as well as in other industry efforts, a line is drawn between services and applications; for example, the call control service is offered by JCC and applications are those pieces of software that make use of such services. However, throughout this JSR for JAIN SCE, we will not make any distinction between services and applications. They will be called services collectively, unless noted explicitly. In other words, we recognize that what is called a service in this JSR may be considered to be equivalent to an application in other contexts.

Note 4: Further analysis is required in order to determine the appropriateness of JAIN Service Provider API (JAIN SPA), such as for the Security component (e.g., possibly concerning the interaction between the SCE and a SLEE) or for its navigation component (e.g. to learn about services that are available).

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

The JAINTM SCE Specification will support the JavaTM 2 Platform, Standard Edition (J2SETM). JAINTM SCE will also support appropriate JAINTM APIs where needed.

The first version of the Specification will be compatible with the current JAINTM SLEE Specification. Further versions will drive new requirements for JAINTM SLEE. While further JAINTM SLEE versions will also impact new requirements for JAINTM SCE.

The JAINTM SCE Specification is targeted towards wireline, wireless, and Voice over Internet Protocol (VoIP) networks, as described in the JAINTM White Paper (

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

The Java community needs that are addressed by this Specification are primarily the creation, edition, and testing of portable telecommunication services for the JAINTM technology based architecture.

SCE tool vendors will be able to manufacture and sell tools for creating services for any JAINTM SLEE-compliant implementation, as well as for Execution Environments that are not compliant with JAINTM SLEE. The tool vendors may then, at their discretion, focus on their SCE products, as opposed to the Service Execution Environment.

The end users will be able to select the tools and environments they feel more comfortable with while being reassured that the service that these tools allow them to create will work in their JAINTM SLEE-compliant Execution Environment.

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

No such specification exists today. Furthermore, it has always been clear in the JAINTM objectives that such a specification should be defined. This originally was to be addressed after the specification of the JAINTM SLEE and there was a single JSR for both the SCE and SLEE Specifications. Having a specific and separate JSR for JAINTM SCE is consistent with JAINTM objectives and will result in a more timely specification.

This JAINTM SCE Specification addresses this need by defining a set of APIs covering the overall service creation process from which the Service Logic being produced is normally delivered to a JAINTM SLEE-compliant execution environment, although it is not restricted to such a SLEE. This Specification includes definitions of mechanisms to create a service and to bundle the service prior to its delivery to a SLEE.

The definition for mechanisms to create a service is expressed by the following items:

  • Service primitives API (in conjunction with the JAINTM APIs for cases where the target environment is JAINTM-compliant)
  • Service composition mechanisms & rules API
  • Service portability API
  • Others to be defined after complete analysis

The definition for mechanisms to bundle a service prior to its delivery to a SLEE is expressed by the following items:

  • Service Independent Building Blocks (SIBBs) bundling
  • Service Logic bundling (SIBBs interconnectivity and interdependencies)
  • Data Model bundling
  • Resources bundling

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

The JAINTM SCE Specification can be used in a wide variety of implementations, including modeling tools, model based development environments, and business component frameworks. The specific underlying technologies that are foreseen, along with the JavaTM 2 Platform and JAINTM (including JAINTM SLEE), are the Java Authentication and Authorization Service (JAAS), XML, and possibly Java Management Extension (JMXTM). The JAINTM SCE may also require underlying technologies that are not yet identified.

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

All packages will be under the jain.application.sce qualified name. Foreseen packages are:

? jain.application.sceCore of the JAIN SCE, including Service Logic assembly rules
? jain.application.sce.primitivesService primitives
? jain.application.sce.bundlingBundling extensions (bundling is the preparation of a Service Logic for its delivery to a SLEE)
? jain.application.sce.securitySecurity extensions - concerning the use of the SCE (see Section 2.1)
? jain.application.sce.testingTesting extensions - possibly out of scope for the first release
? jain.application.sce.configurationConfiguration (e.g., CM) and IDE extensions - possibly out of scope for the first release

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?

The Specification will have to define distinct security roles for interacting with the SCE. These roles should be close or similar to the ones defined in JAINTM SLEE.

The JAINTM SCE security components will be based on Java Authentication and Authorization Service (JAAS) and on the security architecture defined as part of Java 2 Platform, Standard Edition (J2SETM).

2.9 Are there any internationalization or localization issues?

None. The JAINTM SCE Specification is expected to be extensible (e.g., by using appropriate underlying technologies such as J2SETM, XML) and defined at a sufficient level of abstraction so that it can be adapted to the needs of international and local markets.

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

Due to the interactions and intrinsic dependencies between JAINTM SLEE and JAINTM SCE, this Specification may impact the JAINTM SLEE Specification and in fact may help establish new requirements for the JAINTM SLEE Specification. Conversely, the JAINTM SCE Specification will probably at times be revised and modified due to changes or additions to subsequent versions of the JAINTM SLEE Specification.

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

Currently planned to be available approximately in September 2001 or prior to this date.

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.

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

Due to the cohesion that is required between the JAINTM SCE and JAINTM SLEE Specifications, the JAINTM SLEE JSR is used to ensure that work is not duplicated and to ensure interoperability between implementations of the two specifications.

The JAINTM White Paper is used to ensure that the JAINTM SCE Specification is consistent with the objectives and overall technical architecture of JAINTM.

Section 4: Additional Information (Optional)

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

4.1 Reference Implementation (RI) Support.

Because the RI may to a certain extent compete with commercial products for service creation, the JAINTM SCE RI is expected to be quite basic such that it could be used as a development tool for JAINTM SCE application developers and implementers of the API in order to better understand the API.

4.2 Primary Responsibilities of Each of the Specification Leads for the JSR's Main Deliverables.

The main deliverables of the JSR are a Specification, an RI, and a Technology Compatibility Kit (TCK). While both Specification Leads will be involved in all JSR deliverables, each one of the main deliverables is assigned to a specific Lead. The Specification Lead being assigned a given deliverable is primarily responsible for this deliverable:

  • Netergy is responsible for the RI and TCK.

  • Telcordia is responsible for the Specification.