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

E-Mail Addresses: Serge.Masse@NetergyNet.COM; JLBakker@research.telcordia.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, JLBakker@research.telcordia.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
Ulticom
Lucent
Fujitsu
Incomit
Broadsoft
Sun Microsystems
TELSIM-Oxygen
Hughes Software
Motorola

Section 2: Request

2.1 Please describe the proposed Specification:

This Java^TM Specification Request (JSR) defines the standard software interfaces of the Service Creation Environment (SCE) for JAIN^TM. The JAIN^TM SCE is a set of software interfaces to support and simplify the creation of portable telecommunication services delivered primarily to the JAIN^TM Service Logic Execution Environment (JAIN^TM 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:

Note 1: Service delivery, activation, and security are already addressed by the JAIN^TM SLEE Specification. JAIN^TM SCE will be consistent with their definition in the JAIN^TM 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 JAIN^TM-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 JAIN^TM 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 JAIN^TM SCE Specification will support the Java^TM 2 Platform, Standard Edition (J2SE^TM). JAIN^TM SCE will also support appropriate JAIN^TM APIs where needed.

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

The JAIN^TM SCE Specification is targeted towards wireline, wireless, and Voice over Internet Protocol (VoIP) networks, as described in the JAIN^TM White Paper (http://java.sun.com/products/jain/WP2000.pdf).

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 JAIN^TM technology based architecture.

SCE tool vendors will be able to manufacture and sell tools for creating services for any JAIN^TM SLEE-compliant implementation, as well as for Execution Environments that are not compliant with JAIN^TM 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 JAIN^TM 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 JAIN^TM objectives that such a specification should be defined. This originally was to be addressed after the specification of the JAIN^TM SLEE and there was a single JSR for both the SCE and SLEE Specifications. Having a specific and separate JSR for JAIN^TM SCE is consistent with JAIN^TM objectives and will result in a more timely specification.

This JAIN^TM 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 JAIN^TM 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 JAIN^TM APIs for cases where the target environment is JAIN^TM-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 JAIN^TM 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 Java^TM 2 Platform and JAIN^TM (including JAIN^TM SLEE), are the Java Authentication and Authorization Service (JAAS), XML, and possibly Java Management Extension (JMX^TM). The JAIN^TM 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:

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

None.

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 JAIN^TM SLEE.

The JAIN^TM 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 (J2SE^TM).

2.9 Are there any internationalization or localization issues?

None. The JAIN^TM SCE Specification is expected to be extensible (e.g., by using appropriate underlying technologies such as J2SE^TM, 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 JAIN^TM SLEE and JAIN^TM SCE, this Specification may impact the JAIN^TM SLEE Specification and in fact may help establish new requirements for the JAIN^TM SLEE Specification. Conversely, the JAIN^TM SCE Specification will probably at times be revised and modified due to changes or additions to subsequent versions of the JAIN^TM 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.

• JSR-000022 JAIN SLEE API Specification
  http://java.sun.com/aboutJava/communityprocess/jsr/jsr_022_jsce.html



• JAIN^TM White Paper (a .pdf file)
  http://java.sun.com/products/jain/WP2000.pdf

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 JAIN^TM SCE and JAIN^TM SLEE Specifications, the JAIN^TM SLEE JSR is used to ensure that work is not duplicated and to ensure interoperability between implementations of the two specifications.

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

Section 4: Additional Information (Optional)

4.1 Reference Implementation (RI) Support.

Because the RI may to a certain extent compete with commercial products for service creation, the JAIN^TM SCE RI is expected to be quite basic such that it could be used as a development tool for JAIN^TM 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.