 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 24: JAINTM SPA TSM, SD and SAM 1.0 API
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: This allows software developers to rapidly develop external Service Provider-type applications to securely access, discover and agree other APIs, which use abstract primitives that hide the heterogeneity of underlying networks. Please direct comments on this JSR to the Spec Lead(s) Team
The following Sections have been updated from the original JSR: Section 1. Identification Submitting Member: Ulticom Name of Contact Person: Stephanie Dithurbide E-Mail Address: stephanie.dithurbide@ulticom.com Telephone Number: +1 856 787 2784 Fax Number: + 1 856 866 2033 Specification Lead: Stephanie Dithurbide E-Mail Address: stephanie.dithurbide@ulticom.com Telephone Number: +1 856 787 2784 Fax Number: + 1 856 866 2033
Initial Expert Group Membership:
AT&T
BT
IBM
Oracle
Sun Microsystems
Telcordia
Ulticom
Section 2: Request
2.1 Please describe the proposed Specification: The JAIN SPA TSM, SD and SAM 1.0 specification will provide Java APIs for use in a Parlay client environment. These APIs are functionally compatible with the Parlay "Client Application to Framework" TSM, SD and SAM 3.0 APIs. State-of-the-art design patterns will be used, hiding some details of the underlying communication model between Parlay client and server. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.) The JAIN SPA TSM, SD and SAM 1.0 specification is targeted for the Java 2 Standard Edition (J2SE) and Java 2 Enterprise Edition (J2EE) platforms. 2.3 What need of the Java community will be addressed by the proposed specification? The JAIN SPA TSM, SD and SAM 1.0 API will be part of a Java technology instantiation of Parlay, which enables external enterprises to rapidly build and deploy applications that exploit capabilities of the underlying telco's network. By adopting Parlay, the Java community can leverage on the huge investment made by Parlay members into the specification and associated adoption across the IT & telecomms industry. This specification is required to ensure continued standardisation across the computing industry with regard to public open APIs. 2.4 Why isn't this need met by existing specifications? There exists no JAIN (or Java) API to represent a Java specification of the Parlay "Client Application to Framework" TSM, SD and SAM APIs at present. 2.5 Please give a short description of the underlying technology or technologies: It is anticipated that the proposed API would be implemented on a Parlay client, using an arbitrary communication protocol to a Parlay server, to access TSM, SD and SAM services in a controlled and secure telecoms environment. It is highly desirable that the API seamlessly interoperates with other JAIN APIs including but not limited to: JAIN SPA IM and EN JAIN SLEE JAIN Call Control JAIN Mobility 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.) The specification will be provided directly in, and in sub-packages of: javax.jain.framework It will contribute common classes and interfaces to javax.jain and javax.jain.framework, as defined in the JAIN Common API. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of? No 2.8 Are there any security issues that cannot be addressed by the current security model? The JAIN Parlay specification API will use standard Parlay authentication and service signing techniques. For instance, the client informs the framework of its capabilities implying ability to handle DES 56 bit shared secret key, RSA 512 bit key or RSA 1024 bit key using the challenge, response mechanism as described in IETF PPP Authentication Protocols - Challenge Handshake Authentication Protocol [RFC 1994, August 1996]. For signing for prior to service usage following authentication the MD5 algorithm will be used to take an input message of arbitrary length and produce a 128-bit message digest of the input. Depending upon the situation, the 128-bit message will be encrypted with the private key under the RSA public-key cryptography system using a 512 or 1024-bit key. The implementation of these interfaces is beyond the scope of this activity but initial investigations show that the java.security, java.security.acl, java.security.cert, java.security.interfaces and java.security.spec can be utilised to provide support the authentication and signing requirements. 2.9 Are there any internationalization or localization issues? No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work? No 2.11 Please describe the anticipated schedule for the development of this specification.
Proposed Final Draft: Q3, 2001 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification. Regular face-to-face sessions during JAIN community meetings and conference calls to solve specific issues when required. 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. Documents describing JAIN can be found at: http://java.sun.com/products/jain/index.html Documents describing Parlay can be found at: http://www.parlay.org/specs/index.asp 3.2 Explanation of how these items might be used as a starting point for the work. The Parlay "Client Application to Framework" TSM, SD and SAM would form the basis of the JAIN SPA "Client Application to Framework" TSM, SD and SAM API. Original Java Specification Request (JSR) Identification | Request | Contributions Original Summary: The JAINTM SPA TSM, SD and SAM 1.0 API is the Java specification of the Parlay "Client Application to Framework" TSM, SD and SAM 3.0 API. The API is intended to allow software developers to rapidly develop external Service Provider type applications to securely access, discover and agree other APIs, which use abstract primitives that hide the heterogeneity of underlying networks.
Section 1. Identification Contact Information: Jonathan Legh-Smith, BT,
Simon Beddus, BT,
Gary Bruce, BT,
The JSR is being submitted and endorsed by the following Java Community Process Participants:
Section 2: Request
The JSR is to define the JAIN™ Parlay API Specification. Java APIs for Intelligent Networks Secure Network API specification. It will define a JAIN Parlay version derived of the Parlay 1.2 specifications that supports secure access to intelligent networks. 2.1 What is Parlay? The Parlay organisation (www.parlay.org) defines a network API architecture and specification that allows legal entities external to the secure telco environment to gain access and control key network capabilities such as call control, IVR and messaging. Parlay is defined in a non-technology specific way using a combination of text and Unified Methodology Language (UML) such that it may be readily translated to technologies such as Java, CORBA IDL and Microsoft MIDL. For instance, Parlay 1.2 supports:
2.2 Target Java Platform The JAIN Parlay Seccure Network Access API specification is targeted towards Central Office switching environments, Voice over IP networks and private voice networks and data networks. Anywhere in fact, where a public network operator, private network operator, distributor or service provider would want to provide a high value secure API to external client applications. The deployment of such a system will be typically behind a firewall using NEBS Certified equipment or servers. 2.3 The Needs of the Java Community this Specification Addresses. The JAIN Parlay Secure Network Access specification API will define a Java technology instantiation of Parlay which enables external enterprises to rapidly build and deploy applications that exploit capabilities of the underlying telco's network. By adopting Parlay, the Java community can leverage on the huge investment made by Parlay members into the specification and associated adoption across the IT & telecomms industry. The JAIN Parlay specification Secure Network Access API is required to ensure continued standardisation across the computing industry with regards to public open APIs. It is the aspiration that the Java API version of Parlay will behave in the same way as a version in CORBA. In itself, it will provide simpler mapping for users and operators of the API to legacy, contemporary and future systems. Section 2.4 The API being Defined The API specified by the JAIN Secure Network API Java Community Process participants is a Java version on Parlay 1.2. The activity will translate existing Parlay 1.2 specifications and UML along with new OAMP requirements into a set of Java interface packages. The JAIN Parlay 1.0 specifications are based on the full set of Parlay 1.2 specifications. This includes all the Service Interfaces, Application Interfaces, and the Framework Interfaces as specified in the "Parlay API Specification 1.2 : Core Specification" document. The API will use the Java Beans event model where appropriate whilst maintaining the spirit of Parlay specification. Simple Parlay types such as TBstring will be mapped to Java classes such java.String. Complex types such as TparlayAddressType will be mapped to new classes. Section 2.5 Underlying technologies The JAIN Parlay Secure Network API specification abstracts underlying network capabilities such as framework, call control, messaging and IVR services. The JAIN Parlay API specifications can be implemented via the following JAIN community extensions or subsetting of: JAIN SCE/SLEE JAIN JCC Or standard extensions such as for example Java Mail. The JAIN JCC specifications abstracts protocol technologies such as H.323, ISUP, MGCP, SIP, TCAP, MAP, and others. These APIs can be implemented via extensions to Java SLEE, JCC, JCAT and Java Mail which in themselves abstract underlying technology such as H.323, ISUP, MGCP, SIP. A longer term goal of this work not to be covered in this JSRsubsequent release of JAIN Parlay will be to ensure that the JAIN Parlay Generic Call Control Service becomes a true subset of the call control as specified in the JAIN JCC specificationJain Call Control. This can only happen once the both the requirements and design of the JAIN JCC specifications become visible (target date is Ooctober 1999). What constitutes a sub-set will have to be decided upon by both the JAIN JCC and JAIN Parlay edit groups teams. The API service operates on a secure server site and may be offered to internal and external client applications in a number of ways:
Section 2.6 Proposed Package Names jain.parlay_1_2.framework This package contains Parlay authentication, discovery, network data and time and integrity management Java interfaces. jain.parlay_1_2.services This package contains Java interfaces for Parlay Service, INAP Call Control, Generic Call Control, User Interaction, Call User Interaction and Messaging. jain.parlay_1_2.support This package contains interfaces for supporting complex Parlay data types. 2.7 Security implications The JAIN Parlay specification API will use standard Parlay authentication and service signing techniques. For instance, the client informs the framework of its capabilities implying ability to handle DES 56 bit shared secret key, RSA 512 bit key or RSA 1024 bit key using the challenge, response mechanism as described in IETF PPP Authentication Protocols - Challenge Handshake Authentication Protocol [RFC 1994, August1996]. For signing for prior to service usage following authentication the MD5 algorithm will be used to take an input message of arbitrary length and produce a 128-bit message digest of the input. Depending upon the situation, the 128-bit message will be encrypted with the private key under the RSA public-key cryptography system using a 512 or 1024 bit key. The implementation of these interfaces is beyond the scope of this activity but initial investigations show that the java.security, java.security.acl, java.security.cert, java.security.interfaces and java.security.spec can be utilised to provide support the authentication and signing requirements. 2.8 Possible platform dependencies In deployment, the API can use a variety of distribution mechanisms such as RMI or CORBA. The decision of who builds the Reference Implementation and what it distribution technology it implies is as yet undecided. 2.9 Internationalization implications None, the JAIN Parlay specification is based on the Parlay 1.2 specifications which itself abstracts the complexity of international standards and will permit that the specification API to be used in Europe and North America to date. Further investigation underway by Parlay and JAIN members will determine what further internalizationinternationalisation will be required. Parlay 1.0 and updates as they become available are currently being downstreamed into ITU, OMG, ETSI and INForum standards areas. 2.10 Risk assessment The JAIN Parlay specification enables the Java Community to develop services that rely on the Parlay 1.2 specifications. This opens a new world where untrusted services have restricted access to trusted telco domains. JAIN PARLAY moves Java into open telco domain. The Telecoms Industry levies stringent security, performance and failure requirements on hardware and software platforms and must maintain these same high standards for applications external to the telco business domain. This activity solely defines the JAIN Parlay API specificationss and cannot stipulate the internal implementation of a vendor's products. However to accompany any future product description that acknowledges adherence to the JAIN Parlay PARLAY API specification there must be evidence to demonstrate throughputdemonstrate throughput under load, fail-over and recovery. Performance evaluation and tests based on API architecture may be published with each release of a vendor product or operator service. Fail-over will be measured and published based on latency to recover to a like platform and recover state data through JDBC interfaces or Transaction based tools. 2.11 Existing specifications rendered obsolete or deprecated Not applicable. 2.12 Existing specifications needing revisions Not applicable. Section 3: Contributions
Documents describing JAIN can be found at http://java.sun.com/products/jain/index.html Parlay information can be found at www.parlay.org |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
