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.

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

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.

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:

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

Core
of the JAIN SCE, including Service Logic assembly rules

?
jain.application.sce.primitives

Service
primitives

?
jain.application.sce.bundling

Bundling extensions (bundling is the preparation of a Service Logic for its delivery to a SLEE)

Configuration
(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?

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.

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: