Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 192: JAINTM Service Creation Environment - JavaTM PART

Stage Access Start Finish
Withdrawn   22 Sep, 2004  
Expert Group Formation   01 Oct, 2002  
JSR Review Ballot View results 17 Sep, 2002 30 Sep, 2002
Status: 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.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
This 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).

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

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.

Note that this section has been updated from the original request.

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


Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Original Summary: JAINTM Service Creation Environment (JavaTM PART) 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).

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 JavaTM Specification Request (JSR) defines the standard software interfaces of the Service Creation Environment (SCE) (JavaTM PART) 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).
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 JavaTM 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) JavaTM 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 JAINTM SCE Creation APIs will be used to make it JAINTM 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 JAINTM-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 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 JAINTM 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 ( 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 JAINTM 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 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 standard service primitive (JavaTM Beans), a set of APIs covering the overall service creation process from which the Service Logic being produced is delivered to a JAINTM 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 JAINTM APIs for cases where the target environment is JAINTM-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 JAINTM 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 JAINTM SLEE will be as per JAINTM SLEE specifications. JAINTM 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 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.)

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 JAINTM 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

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.

Note that this section has been updated from this original request.

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) JAINTM White Paper (pdf file)
http://java.sun.com/products/jain/WP2000.pdf
3) JAINTMService Creation Environment (JAINTM SCE) - A White Paper describing need, scope and brief overview of JAINTM 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 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 (JavaTM PART) Specification is consistent with the objectives and overall technical architecture of JAINTM.



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 JAINTM Service Creation Environment and was jointly owned by Telecordia and Hughes. JSR 100, was covering both JavaTM PART as well as XML (SCML) PART but since, JavaTM and SCML work are progressing at different pace, it is agreed to separate out JAINTM SCE (JavaTMPART) 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.