A Service Logic Execution Environment (SLEE) is a well known concept in the telecommunications industry. A SLEE is a high throughput, low latency event processing application environment. JSLEE is the Java standard for SLEE.

Fundamental Concepts

Fundamental Concepts of JAIN SLEE

JAIN SLEE (JAIN Service Logic Execution Environment) is a standard produced using the Java Community Process.

The JAIN SLEE architecture defines an environment targeted at communications applications. The specification includes a component model for structuring the application logic of communications applications as a collection of reusable object-orientated components, and for composing these components into higher level and more sophisticated services.

The programming language used by application developers in JAIN SLEE is Java. The SLEE architecture also defines the contract between the components and the container that will host these components at run-time.

The SLEE specification supports the development of highly available and scalable distributed SLEE specification compliant application servers, yet does not mandate any particular implementation strategy. More importantly, applications may be written once, and then deployed on any application environment that implements the SLEE specification.

In addition to the application component model, the SLEE specification also defines the management interfaces used to administer the application environment and the application components executing within the environment. It also defines a set of standard Facilities (such as the Timer Facility, Trace Facility, and Alarm Facility) that provide common ultility functions for use by application components.


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.

Service Building Block

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 and Resource Adaptors

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.

Design Factors

Factors Influencing the Design of JAIN SLEE

From analysis of critical systems literature and discussions with NEPs, carriers and ISVs in the telecom space, it is clear that telecommunications applications have a range of performance, availability and operational requirements. Many of these requirements may be satisfied by a generalised run-time system (i.e. an application server).

This page discusses some of the drivers that influenced the design of the JAIN SLEE specification.

Importance of Reliable Software

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.

Next Generation Services

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:

  1. Service Portability: Service development is constrained by proprietary interfaces, which increase development cost, time to market, and maintenance requirements. The available developer base for a particular platform is small.

  2. Network Convergence: It is difficult to allow applications and services to run on PSTN, packet (e.g. IP or ATM) and wireless networks.

  3. Secure Network Access: It is difficult for applications outside of telephony networks to access network resources and devices in a safe and manageable way.

Application Development

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

  • Be simple

  • Function through host and process failures

  • Execute independent of particular computing nodes

  • Execute concurrently

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.

Application components:
  • Rely on a defined failure model in order to simplify application behaviour through process and host failure

  • Do not need to explicitly manage concurrency

  • Can have their state replicated

  • Have clearly defined state synchronization points

Application server:
  • Migrates application components between processing nodes in the system as particular processes and nodes may fail

  • Manages concurrent execution of application components

  • Prevents faulty application components from affecting other independent application components

  • Allows application components to be up

SLEE specification:
  • Event based model, asynchronous, support for composition

  • Container manages component state

  • Container manages garbage collection of components

  • Transaction boundaries for demarcation and semantics of state replication

  • Strongly typed event handling signatures

  • 3rd party event driven components

  • Management of lifecycle of Server, Services, Provisioned state

  • Versioned services, upgrade of services, existing activities stay on existing service instances, new activities are directed to instances of upgraded services

  • Independent of network technology/protocols/elements through resource adaptor architecture

Programming model:
  • Simple, Object Orientated, programming model

  • Support for 3rd party application components and application development

  • Application server manages application state

  • Transactional

  • Support independent units of work

  • Possible to naturally model asynchronous systems (applications)

  • Network independent

Standards Based

Adoption of a low-cost infrastructure for telecommunications will likely open opportunities for new services (applications), forbiddingly expensive today. The impact of the new services in a standards-based converged network will be broader and faster than it can be today, …​

— Gartner
March 2006
Open, standard APIs hide the complexity of networks from the application layer, and the use of standard signalling and call control protocols are the keys to providing flexibility and creativity for the next-generation networks enhanced services.
— Yankee Group

Network Independence

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:

  • SIP, Diameter




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:

  • Applications must be able to execute on different compliant platforms without change.

  • Application source code must not require modification when moving between compliant platforms.

  • Applications must be isolated from hardware architecture and systems level APIs (for example POSIX, WIN32, etc)

Application Characteristics

Application Characteristics Drive JAIN SLEE Design

There are many possible implementations of the JAIN SLEE standard. Different implementations provide different availability guarantees, have different cluster architectures, provide different ACID semantics, and exhibit different latency and throughput performance. Essentially it is the characteristics of the application and requirements for the application that dictate the necessary features or capabilities in a JAIN SLEE product.

There are many different types of applications that are run by today’s Network Operators, Enterprises and ISPs. These applications can differ significantly in the requirements. However as Gartner has identified, event driven applications typically have very strict latency, throughput and availability requirements.

In the following comparison we use the typical characteristics of 'Event-Driven Applications' and 'Enterprise Applications' as an example to outline the characteristics that different containers provide. Enterprise applications are typical EAI or database applications.

Event-Driven Applications Enterprise Applications


  • Typically asynchronous

    • Events such as protocol triggers

    • Events occurrences mapped to method invocations

  • Typically synchronous

    • Database, EAI systems

    • RPC Calls

Event Granularity

  • Fine-grained events

  • High Frequency

  • Course-grained events

  • Low Frequency


  • Light-weight fine-grained objects

  • Short transient lifetimes - Rapid creation, deletion

  • Heavy weight data access objects

  • Long persistent lifetimes

Data Sources

  • Multiple data sources

    • Location, context information

    • Provisioned data, cached from master copy

  • Database servers

    • Definitive master copy

  • Back-end systems


  • Light-weight transactions

    • For state replication demarcation

    • Faster completion and more frequent

  • Database transactions

    • Slower completion and less frequent


  • Compute-intensive

    • Processing is resource invocations and events

  • Database access intensive

    • Database, EAI systems

    • RPC Calls

Java Community Process

JAIN SLEE and the Java Community Process

The Java Community Process (JCP) is the mechanism by which JAIN SLEE became a recognised standard. This iterative process involved regular review of the proposed technology both by members of an expert group and by interested members of the public.

Standards produced by way of the JCP are required to contain the following components:

  • Specification Documents

  • Technology Compatibility Kit (TCK)

  • Reference Implementation (RI)

Specification Documents

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

Technology Compatibility Kit (TCK)

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.

Reference Implementation (RI)

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.



Technology Compatibility Kit (TCK)

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.

Application Programming Interface (API)