JAIN SLEE Principles

Print-friendly Version

1 Introduction

This document outlines the principles behind a Service Logic Execution Environment (SLEE) for the Java Platform [1]. It also highlights the requirements difference between event driven systems and enterprise systems that motivated the definition of the JAIN SLEE [2] specification through the Java Community Process [3]. Examples of event driven systems are telecom switching, industrial automation, or flow control systems. These types of systems were never meant to be enterprise systems, but are specialized high performing event driven engines. The following table illustrates a high-level comparison between event driven and enterprise systems requirements specific to common elements.

Table 1: High-level requirement comparison of event driven and enterprise systems

To solve the requirements differential between these types of systems and incorporate other key requirements of event driven application servers the following functions were identified as key motivators for the SLEE specification:

• Event Model
• Component model
• Management capabilities
• Resource capabilities
• Facility capabilities
• Profile capabilities

1.1 Event Model

Event routing between data resources and SLEE components, including inter-component event routing, is a core function of the SLEE. The SLEE event model is based on a publish/subscribe model (similar to JMS [4]). This model decouples event producers from event sources via an indirection mechanism which routes event from sources to consumers,and is referred to as the SLEE event routing mechanism.

The event router mechanism describes how an event emitted by an event producer is routed and delivered to one or more component instances interested in the event. This router receives events emitted from producers and delivers events to multiple component instances interested in the event.

Event consumers subscribe for events by attaching to Activity Contexts. Event producers publish events to Activity Contexts. An event producer is not directly aware of its event consumers and an event consumer is not directly aware of its event producers. The SLEE defined Activity Contexts maintain the relationships among event producers and event consumers. The SLEE event model has the following benefits:

• Promotes stronger decoupling or isolation of the event producer from the event consumer. This facilitates modularity and fault isolation, as an error in the event producer is less likely to propagate to the event consumer and vice versa.

• Application developers do not need to know the interfaces of event sources and event drivers don't need to know about the applications consuming these events. Applications and event driverdevelopers only need to know about the interface they define with Activity contexts. Such decoupling reduces development complexity and costs.

• Eliminates direct references among event producers and event consumers. Direct references reduce application robustness by introducing the possibility of invalid references.

• Allows the SLEE to know the relationships among event consumers and event producers. This allows the SLEE to provide important value added features such as garbage collection of event consumers that will no longer receive events.

• Allows the SLEE to specify a single consistent event distribution model (e.g. the order of event delivery to multiple event consumers, concurrency control semantics), which benefits the developer with a single model to learn.

• Improves robustness as event producers do not have to implement event distribution code that complies with documented patterns or conventions.

• The application has a flexible event distribution model that only receives event types of interest. Certain applications on a platform may only require event distribution of a specific event type, while other applications require event distribution of a different type.

1.2 Component Model

The SLEE component model is targeted at event driven applications or asynchronous applications. The component model eliminates direct references among event producers i.e. network resources and event consumers i.e. application components. A SLEE component is called a Service Building Block (SBB) and is hosted by a SLEE container. A SBB complies with certain idioms and programming restrictions. The container acts as the building block's run-time environment and provides the following infrastructure services to the SBB:

• Resource and life cycle management 
• Concurrency 
• Security 
• Persistence 
• Transactions

A deployment descriptor allows a declarative association between the infrastructure services and the SBBs hosted by the container at deployment time.

SLEE components receive requests in the form of events that typically represent an occurrence requiring application processing. It carries information describing the occurrence, such as the source of the event. A component running within the SLEE may use events to signal, invoke, or communicate with other applications running in the SLEE.

The SLEE component model models the external interface of an event driven application as a set of events that the application can receive. Each event type is handled by its own event handler method to enforce a well-defined event interface. The event driven component model allows the SLEE to provide the event routing logic for the application. While the SLEE component model borrows heavily from the Enterprise JavaBeans(EJB) [5] component model its does not explicitly inherit from the EJB component. This is because the SLEE is a specialized lightweight environment for high-speed, low-latency event processing application servers not requiring the full function of J2EE. However, the SLEE Reference Implementation is built upon the EJB Reference Implementation to illustrate the mapping of SLEE components to J2EE components and highlight how SLEE deployments can exist on J2EE application server platforms.

1.3 Management Capabilities

In order to operate, administer and manage elements of event-driven systems, an administrator needs the ability to set and inspect values that characterize the configuration of those systems. These configuration aspects are typically provisioned using proprietary interfaces. The SLEE defines a standard set of interfaces for managing the event driven application server, for example, communication systems built using SLEE enable administrators to manage services, profile data and network resources in a uniform manner. These management interfaces enable an administrator to install, uninstall, start and stop services in the SLEE. The SLEE specification also notes how applications running in the SLEE access provisioned data, for example, adding and removing subscriber services.

The SLEE defines management interfaces using Managed Beans (MBean's) as specified by the Java Management Extensions (JMX) [6] specification. An MBean is an external representation of a functional and physical domain of a system. By defining management interfaces as MBean's the SLEE builds upon the standardized management interface for Java platforms and enables the inspection of component attributes and the modification of components via the operations defined by the MBean interfaces.

1.4 Resource Capabilities

Event driven applications developed within the SLEE need to communicate with network resources. A network resource represents a system that is external to a SLEE (i.e. protocol stacks and databases). These resources may or may not have Java APIs and define interfaces to represent events emitted by the resource. The SLEE architecture defines how applications running within the SLEE interact with resources through resource adaptors. Resource adaptors adapt resources to the requirements of the SLEE.

A resource adaptor type declares the common characteristics for a set of resource adaptors by defining the Java interfaces implemented and the event types fired by resource adaptors of the same type. A resource adaptor is an implementation of a particular resource adaptor type and consists of a set of Java classes with a deployment descriptor.

The resource adaptor architecture is important in addressing integration of event driven resources and provides a framework to send and receive events to different network resources. Using resource adaptors to access an event-driven network resource is akin to using JDBC [7] to access a database. Event driven integration implies that the data passed between systems will be in the form of an event or request. Outbound event integration involves requesting data from a remote system in a request form. With inbound event integration, a system receives a request for data via a request and responds with a response.

Event oriented integration lends itself to loose coupling between systems because a system remains unaware of the object types existing on the remote system. The resource adaptor architecture is yet to be standardized by the SLEE specification. This standardization process will begin after SLEE achieves final release. Standardizing the resource adaptor architecture prevents each resource adaptor vendor from creating a proprietary resource adapter interface for its own network resource, thus requiring an adapter to be developed for each network resource vendor and SLEE combination.

1.5 Profile Capabilities

The SLEE specification defines a generic provisioned data schema that is easy to use to define, provision, and access profiles. It includes interfaces for adding, removing, and modifying provisioned data. Typical provisioned data includes configuration data, such as per-subscriber data.

Provisioned data is represented by a profile, where the schema of the profile defines the attributes that may be provisioned in the profile. Profiles that share a schema are grouped into a profile table. A profile specification specifies the provisioned data required by the application to perform its function. A profile specification contains interfaces, classes, and deployment descriptor elements needed to define a profile schema and the interfaces used to provision and access a profile that conforms to that profile schema. The profile specification also describes the schema of profile tables created from the profile specification by the Administrator.

1.6 Facilities Capabilities

To effectively manage application usage, services, event flow and resources it is necessary to monitor and measure the present performance, utilization and availability of these attributes, while estimating future such characteristics. The SLEE specification defines a number of facilities that may be used to satisfy these requirements.

Management interfaces typically employ a combination of measurements and alarms to monitor the current status of the network. From these results an administrator can derive the expected future performance. The facilities defined by the SLEE include:

• Timer Facility - This function provides applications with the ability to perform periodic actions, or initiate actions and check at a later time to ensure they have been completed. The timer facility manages a number of timers, each of which is independent. A timer may fire zero or more timer events when a timer has expired.

• Alarm Facility - Alarms are used to inform management applications that an unexpected change in state has occurred within a network element. SBB components use the alarm facility to generate alarm notifications intended for consumption by management clients external to the SLEE. The sending of alarms to management applications is automatically triggered when a particular condition becomes true. These management clients may be a network management console or a management policy engine. The management client may optionally provide notification filters so only the alarm notifications the management client would like to receive are transmitted to the management client.

• Trace Facility - Applications use the trace facility to generate trace messages intended for consumption by external management clients. The management client is responsible for registering to receive trace messages generated by trace facility and can set a trace level for the application. Applications have access to this trace level to determine the level at which to generate trace messages.

• Usage Facility - Usage or statistics are application or network characteristics that are occasionally or periodically polled by management applications. A management client can use the usage parameter instances of a service to monitor the resource usage of the application. An application uses the usage facility to update usage parameters of that service.

• Profile Facility - The profile facility allows applications to search for profiles stored in profile tables by attribute value. Profiles contain provisioned data in the SLEE.

It is the responsibility of the management application to provide recommendations on measurements regarding the categorization, unit of measurement, when and how often collection should be made, and whether or not it is defined as obligatory from a management point of view to present these measurements.

2 Conclusion

The capability set that defines the SLEE principles provides a robust framework and component model for event driven applications. The SLEE was developed for telecommunications systems, however it is generic in design to provide application to other specialized event driven systems. The SLEE defines an architecture enabling traditional proprietary event driven systems in telecommunications and other vertical markets to migrate to off-the-shelf Java platforms.

3 References

[1] Sun Microsystems, "The Java Programming Language", 1996. See http://java.sun.com.

[2] Sun Microsystems, "JAIN SLEE Specification - JSR 22", 2002. See http://jcp.org/en/jsr/detail?id=22.

[3] Sun Microsystems, "Java Community Process Program - JSR 171", 2002. See http://jcp.org/en/jsr/detail?id=171.

[4] Sun Microsystems, "Java Message Service - JSR 914", 2002. See http://jcp.org/en/jsr/detail?id=914.

[5] Sun Microsystems, "Enterprise JavaBeans Specification - JSR 153", 2002. See http://jcp.org/en/jsr/detail?id=153.

[6] Sun Microsystems, "Java Management Extensions Specification - JSR 003", 2002. See http://jcp.org/en/jsr/detail?id=3.

[7] Sun Microsystems, "JDBC Specification - JSR 054", 2002. See http://jcp.org/en/jsr/detail?id=54.