JSLEE Guide

A service in JAIN SLEE terminology is a managed field replaceable unit. The system administrator of a JAIN SLEE controls the life cycle (including deployment, undeployment and on-line upgrade) of a service. The lifecycle management is achieved through the use of the standard management interfaces provided by a compliant JAIN SLEE. A service includes information that describes the service, for example the name of the service, the vendor of the service and its version, and any program code that is part of the service. The program code can include Java classes, Profiles, and Service Building Blocks.

A JAIN SLEE Profile contains provisioned data. This provisioned data has a schema, which is a set of attributes or properties. For example a phone number and an email address for an individual could be considered two attributes of a Profile. JAIN SLEE also defines the concept of a Profile Specification. A Profile Specification includes management interfaces for modifying or updating a Profile, defining the schema of a Profile and logic that may execute to ensure that a Profile is valid. Service Building Blocks running inside the JAIN SLEE may access profiles as part of their application logic.

The element of re-use defined by JAIN SLEE is the Service Building Block (SBB). An SBB is a software component that sends and receives events and performs computational logic based on the receipt of events and its current state. SBBs are stateful components and as such can remember the results of previous computations and those results can be applied in further computations. An SBB may be composed of other SBBs thereby enabling more complex applications to be built from a collection of SBBs. SBBs perform logic based on the receipt of events. Events are used to represent occurrences of importance that may occur at arbitrary points in time. For example the act of an external system delegating to the SLEE to assist in setting up a call may occur at an any point in time and is therefore easily modelled as an event. An SBB definition includes information that describes the SBB (for example the name, vendor and version of the SBB), any events that the SBB receives, and program code that provides the logic of the SBB. The program code for an SBB is comprised of Java classes.

An event represents an occurrence that may require application processing. It carries information that describes the occurrence, such as the source of the event. An event may originate from a number of different sources, for example an external resource such as a communications protocol stack, from the SLEE itself, or from application components within the SLEE. Events are an abstraction used to model occurences that are not related to any particular thread of execution.

For example consider a phone call between two parties, Alice and Bob. Alice can call Bob at any point in time. The occurence of Alice dialing Bob’s phone number can be modelled as an event and the occurence of Bob answering his ringing phone can be modelled as an event.

Resources are external entities that interact with other systems outside of the SLEE, such as network elements (HLR, MSC, etc), protocol stacks, directories and databases. A Resource Adaptor adapts the particular interfaces and requirements of a Resource into the interfaces and requirements of the JAIN SLEE.

Continuous availability is a primary goal of communication services and can only be achieved if the time to detect and recover from a failure is low. The computer industry has historically been concerned about hardware failures. Software failures are a significant cause of downtime (40%).

The complexity of software systems is increasing as a direct consequence of the increasing complexity of the services provided. The cost of developing software in a way that guarantees high availability should not be underestimated. Design approaches that attempt to eliminate software failures on a case-by-case basis significantly increase development costs and still do not guarantee that failures will not occur.

Therefore, in addition to existing methods to deal with hardware failures, there is a requirement for software architectures that address software failures.

The need to introduce new services across telephony networks more rapidly has been driving significant change over the past 10-15 years. The explosion of the Internet has also seen the development of Next Generation services that use features of both the Internet and telephony networks. Significant problems exist in the development of Next Generation services:

In order to satisfy performance and availability requirements, the application programmer must have access to APIs that allow their application logic to:

These APIs must be rich enough to support the kinds of applications that need to be developed yet still lead to reduced development cost and time.

These goals drive the requirements of the programming model used for application development and the requirements of the application server that hosts these applications.

Existing legacy equipment constitutes a significant investment by Network Operators. Transitional network architectures are likely to be adopted as Network Operators embrace new technology. Therefore, it must be possible to deploy applications in the SLEE application environment that use diverse network resources and signalling protocols.

The integration of a new type of network element, signalling protocol, or external system must not require changes to the core software architecture of the application server. This requirement is satisfied by a Resource Adapter Framework that supports integration of network resources.

Example resources include:

Network Equipment Providers and Network Operators have preferred hardware and Operating System platforms. Applications running in the JAIN SLEE application environment must have the following characteristics:

The specification documents can be downloaded from the Java Community Process website - see our download page for details.

The TCK is a collection of tests that a SLEE implementation must pass in order to be certified JAIN SLEE compliant.

The tests cover a wide range of behaviours from transactional correctness to verifying that API methods throw the specified exceptions when given specific parameters. The tests are designed to test both every day use cases, as well as unusual (but covered by the specification) use cases.

Since JAIN SLEE implementations are required to pass these tests, JAIN SLEE application developers to write and test applications on one JAIN SLEE implementation with full confidence that the application will execute correctly on another JAIN SLEE implementation, without requiring modifications to the application code.

The TCK is built and maintained by OpenCloud. The SLEE TCK user’s guide contains detailed information on configuring and running the TCK. This is contained in the TCK download - see our download page for details.

The JAIN SLEE Reference Implementation is a fully functioning implementation of the JAIN SLEE that can be used to build and deploy services. It was implemented using J2EE technology and may be useful in (conjunction with the JAIN SLEE specification) to JAIN SLEE developers. Services that deploy on the reference implementation will deploy on any other JAIN SLEE compliant implementation.

The JAIN SLEE Reference Implementation was built by OpenCloud. Documentation on installing and running the reference implementation (RI) is included in the reference implementation download.

The TCK contains the various documentation, tests, source-code, and build files required in order to test an implementation of JSR 240 for compliance against the specification.

JSLEE TCK

JSLEE API 1.1