Factors Influencing the Design of JAIN SLEE

Abstract

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 document discusses some of the drivers the 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 upgraded whilst active

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

"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:

• Java Call Control
• SIP
• SMPP, MM7
• CAMEL (CAP), TCAP, MAP, INAP
• OSA/Parlay

Portability

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)