Sentinel allows Features and Mappers to be dynamically "added to", "removed from" and "replaced" inside Rhino.

This capability is supported by the use of Rhino 2.4.x bindings capability, and the tools that are part of the Sentinel SDK.

The user experience of this capability is improved through the introduction of the Logical Service ID. In essence, the logical service ID creates a "constant" Service ID that is able to be used regardless of changes to features and mappers in the running system.

Motivation for a Logical Service ID

The process of binding new or different version features into Rhino may require new Service Copy components to be created. This is because a running service must not change its components. Rhino supports two approaches to achieve the goal of modifying the code used at runtime.

  1. deactivate the service, then its bindings can be updated in order to make use of new features or mappers or different versions thereof, and re-activating once the bindings changes are complete

  2. creation of a new copy (from the existing active copy). The new copy is now inactive, then its bindings are updated in order to make use of new features or mappers or different versions thereof

The net result is that it is possible for the Service ID that is active to change.

As an example the following timeline can occur

  1. initial installation, the Service ID has name="Sentinel Service", vendor="OpenCloud", version="4.1.0"

  2. first bind operation occurs, creating a Service ID with name="Sentinel Service", vendor="OpenCloud", version="4.1.0-copy#1". This copy is activated.

  3. some time passes, and new features are introduced. This may create a new Service ID with name="Sentinel Service", vendor="OpenCloud", version="4.1.0-copy#2". The earlier copy (-copy#1) is deactivated and the new copy is activated.

Collection of statistics from Rhino is one case that illustrates the requirement for a logical service ID. Collection of statistics from a Service inside Rhino requires a Service ID to be passed in. For arguments sake, let’s assume that statistics collection is running, collecting statistics from the current active version ("4.1.0-copy#1). Yet during the timeline above, at some point, the active Service ID is now "4.1.0-copy#2".

Therefore unless the collection of statistics is changed to use the new service ID, the statistics being collected will now refer to an inactive copy.

The user experience is improved by making use of Rhino 2.4.x Linked Components capabilities.

In essence a Linked Component is a Rhino SLEE component, that is set up to "point to" another component. Rhino "follows" the links, to resolve them to a non-linked Component. It is inspired by Unix symlinks.

The Sentinel tooling creates two links for each Sentinel Service upon deployment of the service into Rhino. When the binder creates a new copy, the links are updated automatically.

The process is best understood by comparing it with the timeline above

  1. initial installation, the Service ID name="Sentinel Service", vendor="OpenCloud", version="4.1.0" is installed, two link components are created

    1. Link Component name="Sentinel Service", vendor="OpenCloud", version="current" points to Service ID name="Sentinel Service", vendor="OpenCloud", version="4.1.0"

    2. Link Component name="Sentinel Service", vendor="OpenCloud", version="4.1" points to Service ID name="Sentinel Service", vendor="OpenCloud", version="4.1.0"

  2. first bind operation occurs, creating a Service ID with name="Sentinel Service", vendor="OpenCloud", version="4.1.0-copy#1". This copy is activated.

    1. both link components are updated such that they point to Service ID with name="Sentinel Service", vendor="OpenCloud", version="4.1.0-copy#1"

  3. some time passes, and new features are introduced. This may create a new Service ID with name="Sentinel Service", vendor="OpenCloud", version="4.1.0-copy#2". The earlier copy (-copy#1) is deactivated and the new copy is activated.

    1. both link components are again updated such that they point to the newly activated copy

Now, when collecting statistics from name="Sentinel Service", vendor="OpenCloud", version="4.1" .. the gathered data is always from most recent active version. Therefore collection does not need to be changed as new copies are created and activated.

This approach has similar user experience benefits that are wider than statistics collection, including but not limited to:

  1. SIS compositions - a composition can use a constant Service ID (link) in the composition

  2. SLEE service event firing - directed event firing - an SBB can fire an event to a service link, and Rhino will deliver the event following links

Link components can be changed to point to another place on the fly.

Previous page Next page