Unfortunately, the benefits of SI don’t extend to a JSLEE hosting multiple services, unless you combine it with a SIS.
The problem: coordinating multiple services processing multiple events
In a conventional SLEE configuration: A resource adaptor gets a request from the network, converts it into a SLEE event, and then fires that event into the SLEE. The SLEE event router then determines which SLEE services are interested in receiving the event, and then passes that event to those services in priority order.
Typically just one service will process an event, but the SLEE model allows more than one service to process the same event. On the surface this sounds like service interaction, given that it allows many services to process the same event. However there are two big problems:
-
The order of event processing is inflexible, depending only on the services'
default-priorityvalues — so different scenarios cannot have different priorities. -
When processing events, services can easily send network messages or change activity states — potentially making those activities unusable to subsequent services.
For example, one service may decide to disconnect a call. The SLEE has no knowledge of the protocol, and will continue passing the event to subsequent services despite the call being disconnected. The subsequent services then fail (because they cannot use a disconnected call).
The solution: controlled service interaction
The SIS solves such problems by managing service interaction intelligently — by letting services operate independently (without concern for what other services are doing). The SIS does this using a combination of the following techniques:
-
taking over some of the SLEE’s event-routing functions, so it can pass events to configurable sets of services, according to parameters in the request
-
understanding particular network protocols, so it can present each service with a virtual view of real network activity, and control whether or not a service can directly affect that real activity
-
intercepting any operations that services perform affecting activity state, and ensuring that subsequent services see any updated states
-
applying all changes to real network activity, and only sending appropriate protocol-specific messages once all interested services have processed an event.
