To better understand the steps involved in a Sentinel product upgrade it is necessary to understand:

  • the SLEE components

  • the Sentinel components

The information below gives a general overview of those concepts. For more detailed information see:

Basic SLEE components

SLEE stands for Service Logic and Execution Environment (SLEE) and it is part of the Java APIs for Integrated Networks (JAIN).

Extracted from the SLEE specification 1.1.

A SLEE is an application server. This application server is a container for software components.
The SLEE specification is designed and optimized for event driven applications.

An event driven application typically does not have an active thread of execution. Typically, an event driven application defines methods that are invoked when events are delivered to the application.
These methods contain application code that inspect the event and perform additional processing to handle the event.
The application code may interact with the resource that emitted the event or other resources, fire new events or update the application state.

The SLEE architecture defines how an application can be composed of components.
These components are known as Service Building Block (SBB) components.
Each SBB component identifies the event types accepted by the component and has event handler methods
that contain application code that processes events of these event types.
In addition, an SBB component may have an interface for synchronous method invocations.
At runtime, the SLEE creates instances of these components to process events and deletes components that are no longer eligible for event processing.

The SLEE architecture defines the following core abstractions and concepts:

* Event and event type
* SBB component, SBB component graph, and root SBB component
* SBB entity, SBB entity tree, and root SBB entity
* Cascading removal of SBB entity sub-tree
* SBB abstract class and SBB object
* SBB local interface and SBB local object
* Activity, Activity object, and Activity Context
* How the SLEE reclaims an SBB entity tree and its associated descendent SBB entities
* Activity Context Interface interface and Activity Context Interface object
* Profile, Profile Table and Profile Specification
* Service Resource Adaptor type and Resource Adaptor components
* Library component
* Deployable unit
* Management interface

The core abstractions above are implemented as Java components (Jars), configuration artifacts and metadata represented in XML format.

Rhino and SLEE

Rhino is the platform that implements SLEE and is an application server that supports the development of telecommunications applications. Concretely Rhino offers a set of APIs to implement SLEE applications. A simple application is composed of:

  • Resource adaptors (RAs) that define Events and Activities

  • SBBs and SBB parts composing a SLEE service that handles events

  • Configuration data:

    • Profile tables and profiles

    • RA configuration data

Those components are present in Rhino as Jars and Deployable Units (DUs). A deployable unit (DU) is a set of Jars plus metadata that defines a SLEE component. The profiles are present in memory and persisted in the Rhino management database.

Rhino has a set of tools to handle those components. Some of those tools are the rhino-export, the rhino-import and the rhino-console. In a nutshell, rhino-export will dump a SLEE application including its components and configuration to the disk and rhino-import will restore the application to Rhino.

Sentinel Product Components

Sentinel is a services platform and framework that includes, out of the box, several SLEE components ready to be used in order to compose a SLEE application.

It includes main facilities for:

  • SIP, SS7 and Diameter signaling

  • Services and features to handle signaling events that implement Telecom services

Sentinel VoLTE, Sentinel IPSMGW and Sentinel GAA add new components, use and extend existing ones.

Each of these products run signaling flows according to the Telecom service they are implementing and each product has a different set of SLEE components. Each component has a set of dependencies on other components and together compose the product.

Those components when extracted from Rhino, as described above, are Jars, DUs and XML files.

What is a Sentinel Product upgrade?

A Sentinel product upgrade is the act of installing the product components in Rhino (DUs, Jars and configuration) and making sure that the configuration and customizations are maintained in order to guarantee that the product works as expected with the new components.

The difficulties faced during an upgrade are:

  • Minimize service disruption

  • Maintain the current configuration

  • Guarantee safe rollback

The upgrade procedure overview

The overview procedure is:

  • sanity check the parameters

  • check the connection to the hosts

  • clone the cluster on all the hosts

  • backup the installation

  • retrieve the actual system configuration

  • migrate the node on the first host in the given list to the new cluster

  • install the new product version on that first host

  • copy the configuration from the old installation to the new installation

  • clean up the temporary files

  • optionally pause to allow testing of the upgraded node

  • migrate the other nodes of the cluster

For more information see Major Upgrade.

Previous page Next page