• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Specification Leads
	Vishal Aggarwal	Hughes Software Systems
Expert Group
	Hughes Software Systems	SBC Technologies Research

This JSR has been Withdrawn
Reason: There had not been much progress on this JSR since quite some time. The draft was floated for Expert Group review but there was no response even after several reminders. They then decided not to go ahead with this activity and hence requested the PMO to mark this JSR 192 as WITHDRAWN.

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original proposal.

2003.08.14:

Specification Lead: Vishal Aggarwal

E-Mail Address: vaggarwal@hss.hns.com

Telephone Number: +91 124 245 5555 x3303

Fax Number: +91 124 245 5346

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

Since, this specification was the part of JSR 100, some amount of work is already done. Following describes the antcipated revised schedule: JSR Approved: Already placed as was the part of JSR
Expert Group Draft: August 2003
Community Review: September 2003
Public Review: October 2003
Proposed Final Draft: November 2003
RI & TCK complete: December 2003
Final Release: January 2004

Identification | Request | Contributions | Additional Information

Original Summary: JAIN^TM Service Creation Environment (Java^TM PART) is the specification for the Java^TM API to support and simplify the creation of portable telecommunication services delivered primarily to the JAIN^TM Service Logic Execution Environment (JAIN^TM SLEE).

Section 1. Identification

Submitting Member: Hughes Software Systems

Name of Contact Person: Rakesh Srivastava

E-Mail Address: rksrivastava@hss.hns.com

Telephone Number: +91 124 645 5555 x3511

Fax Number: +91 124 645 5346

NOTE that this information has been updated from what is shown here.

Specification Lead: Rakesh Srivastava

E-Mail Address: rksrivastava@hss.hns.com

Telephone Number: +91 124 645 5555 x3511

Fax Number: +91 124 645 5346

Initial Expert Group Membership:

These companies are already expert group members for this JSR (Earlier they were for JSR#100, taken from JSR#100 as such):

Hughes Software Systems
Sun Microsystems, Inc.
Personeta

Supporting this JSR:

These companies are already supporting this JSR (JSR#100), taken from JSR#100 as such:

AePONA
Ericsson Inc.
Fujitsu Limited
Hughes Software Systems
IBM
Mahindra British Telecom Ltd.
Narad Networks
Nokia Networks
Sun Microsystems, Inc.
Taral Networks
Telcordia Technologies, Inc.
TrueTel Communications Inc.

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) (Java^TM PART) 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).
It also povides utilities to automate or simplify the task of writing the deployment descriptors, composition of SBBs into service and may provide skeleton code for SBBs and services, needed as per Java^TM specifications. 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:
1) Java^TM Bean Based Service Primitives:
Covering the defining and devlop service primitives. As a first step, it will be to develop and standardize basic service primitives using underlying JCC/JCAT call control APIs and JAIN SLEE APIs. Later, it will be covered for other domains and will have concept of making high level components and features.
2) Creation: Covering the creation of a service, including the assembly of components, using service primitives. In the creation process, it is assumed that development of new service building blocks and the assembly of services from these building blocks, typically using one or more commercially available, off-the-shelf tools such as an Integrated Development Environment (IDE) or Bean Boxes (providing a library of re-usable Java Beans components).The JAIN^TM SCE Creation APIs will be used to make it JAIN^TM SLEE deployable unit.
3) 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. 4) Security: Covering security regarding the use of the SCE and the interaction with a SLEE, including a JAIN^TM-compliant SLEE.
5)Testing: Covering the testing and validation of a service.6) Bundling: Covering the preparation of a service for its delivery to a SLEE, including the preparation for delivery to a JAIN^TM-compliant SLEE.
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^TM 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 standard service primitive (Java^TM Beans), a set of APIs covering the overall service creation process from which the Service Logic being produced is delivered to a JAIN^TM SLEE-compliant execution environment. 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:

1) Service primitives API in the form of Java Beans (in conjunction with the JAIN^TM APIs for cases where the target environment is JAIN^TM-compliant)

2)Service composition mechanisms & rules API (It is assumed that Service Creation process allows the development of new service building blocks and the assembly of services from these building blocks, typically using one or more commercially available, off-the-shelf tools such as an Integrated Development Environment (IDE) or Bean Boxes (providing a library of re-usable Java Beans components).

3) Service Creation APIs - Creation of components as per JAIN^TM SLEE specification.

4) Bundling, Deployment and Packaging APIs.

Others to be defined after complete analysis The definition for mechanisms to bundle/package a service prior to its delivery to a JAIN^TM SLEE will be as per JAIN^TM SLEE specifications. JAIN^TM SLEE expects following:
1) A service jar deployment descriptor
2) Class files of the service's classes and interfaces
3) SBB jar files of the constituent SBBs of the service

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.)

1) javax.sce - Core of the JAIN SCE
2) javax.sce.primitives - Service primitives (Java[TM] Beans)
3) javax.sce.bundling - Bundling extensions (bundling is the preparation of a Service Logic for its delivery to a JAIN^TM SLEE)
4) javax.sce.security - Security extensions - concerning the use of the SCE (see Section 2.1)
5) javax.sce.testing - Testing extensions - Out of scope for the first release
6) javax.sce.configuration - Configuration (e.g., CM) and IDE extensions - 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?

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.

Since, this specification was the part of JSR 100, some amount of work is already done. The RI/TCK of JAIN SCE is dependent on availability of JAIN SLEE RI and based on current schedule for JSLEE RI availability (Q4, 2002), the following describe the anticipated schedule for rest activities: JSR Approved: Already placed as was the part of JSR
Expert Group Draft: October 2002
Community Review: November 2002
Public Review: December 2002
Proposed Final Draft: January 2003
RI & TCK complete: February 2003
Final Release: March 2003

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

The related work, documents and specifications will be discussed and reviewed by the expert group members.
First, it will be tried that queries and issues can get closed through e-mail and if it is not possible, there will be conference calls to resolve the issues/design points based on need.

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.

1) SR-000022 JAIN SLEE API Specification
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_022_jsce.html
2) JAIN^TM White Paper (pdf file)
http://java.sun.com/products/jain/WP2000.pdf
3) JAIN^TMService Creation Environment (JAIN^TM SCE) - A White Paper describing need, scope and brief overview of JAIN^TM capabilities (June 2002, Draft 0.0.4)

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 (Java^TM PART) Specification is consistent with the objectives and overall technical architecture of JAIN^TM.

Section 4: Additional Information (Optional)

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

The following information provides background for creation of new JSR:
1) Earlier, the activities of this JSR was a part of already existing JSR 100 JAIN^TM Service Creation Environment and was jointly owned by Telecordia and Hughes. JSR 100, was covering both Java^TM PART as well as XML (SCML) PART but since, JavaTM and SCML work are progressing at different pace, it is agreed to separate out JAIN^TM SCE (Java^TMPART) JSR.
2) Now, the activities for this JSR, will be owned by Hughes Software Systems Ltd and will be responsible for Specifications, RI and TCK.