JSRs: Java Specification Requests
JSR 35: JAINTM INAP API Specification
Section 1: Identification
This JSR is being submitted and endorsed by the following Java Community Process Participants:
Section 2: Request
This JSR is to develop the JavaTM APIs for Integrated Networks (JAIN) Intelligent Network Application Protocol (INAP) Specification. It will describe the Java standard API for Intelligent Networks application's interaction in the Telecommunications Industry.
2.1 What is INAP?
INAP protocol allows applications to communicate between various nodes/functional entities of an intelligent network. The protocol defines the operations required to be performed between nodes/functional entities for providing Intelligent Network services. INAP handles number of services such as number translator, time of day, follow me, etc.
2.2 Target Java Platform
The JAIN INAP Specification is targeted towards telephony over integrated Public Switched Telephone Networks (PSTN) , mobile telephony networks, and Internet Protocol networks. This will typically be NEBS Certified equipment or servers that support SS7 or Signaling environments.
2.3 Needs of Java Community this Specification Addresses
Traditionally, telephony applications require costly resources to develop, test, and deploy. A JAIN cross-platform solution gives the Carriers, Service Providers, and Network Equipment Providers a consistent, open environment where they can rapidly develop and deploy telephony services dynamically. The JAIN INAP specification defines an API which allows for the rapid creation and deployment of telephony services into a Java telephony platform. A JAIN INAP component can be rapidly developed, tested, and integrated on a variety of platforms with access to numerous tools and utilities.
2.4 The API being defined.
The API specified by the JAIN SS7 Java Community Process Participants for INAP are based on the ANSI/Bellcore AIN and ITU-T CS-1 INAP specifications. Instead of mapping the standard specifications to a Java interface, the JAIN INAP specification abstracts a functional definition into the variant protocol stacks.
The JAIN INAP API is built upon the Java Beans Event model. The protocol stack vendor supplies the JAIN INAP 'provider' interface into the protocol stack. JAIN INAP 'listeners' may readily be rolled onto the platform by an object manager.
Proprietary stack features are hidden behind a JAIN INAP Factory. Through JAIN INAP interfaces, a protocol stack provider is obtained from the factory, and JAIN INAP listeners are then attached to the providers.
2.5 Underlying technologies
The JAIN INAP specification is based upon the underlying SS7 protocol stacks supplied by the JAIN JSPA members and other 3rd party protocol stack implementations and its initial purpose is to provide a ubiquitous, standard Java interface into SS7 protocol stacks.
A JAIN INAP application can be written as a program, applet, servlet, or bean. The Java bean makes for an ideal telephony component for rapid dynamic service integration. The Telecom industry has defined telephony services built by integrating components in a Service Creation Environment (SCE). The service is then loaded onto a Service Logic Execution Environment (SLEE) where they receive incoming calls and perform the service logic. Telephony components are analogous to objects or Java Beans. A Service Logic Execution Environment may be built within a Java Virtual Machine using Java Bean technology. The SLEE requires Java Beans and a Java Bean Management tool. Service Creation Environments may be built using Java visual tools such as Java Studio, or Visual Cafe.
While there is no dependency on such tools to build a JAIN INAP component, a Java Bean Manager and/or a visual Java bean builder aids in the development, integration, testing, and deployment of telephony services.
2.6 Proposed package names
Package names being considered are:
This package contains the main interfaces, classes and exceptions required to send and receive INAP messages.
2.7 Possible platform dependencies
The Reference Implementation may have a dependency on RMI.
2.8 Security implications
None. JAIN INAP expects to utilize standard JDK security.
2.9 Internationalization implications
JAIN INAP is based on ITU-T specifications. Hence the API can be readily adopted in the European networks.
2.10 Localization implications
Since JAIN INAP also supports ANSI/Bellcore standards, the INAP API can be readily adapted to North American networks.
2.11 Risk assessment
JAIN platform alongwith JAIN INAP and other interfaces moves Java into telco
carrier grade service. The Telecom Industry levies Stringent performance and
failure requirements on hardware and software platforms. Risks include
failure of the Java platform due to poor performance or the inability to
failover or recover. Performance evaluation and tests based on API
architecture will be published with each release of the API. Failover 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.
Section 3: Contributions
Documents describing JAIN can be found at http://java.sun.com/products/jain/index.html