ented all over again. This is an expensive proposition, given the rapid changes expected in the external services due to enhancements and new features. In order to mitigate this problem, we introduce a proxy functionality pro- vided by CEP, between the SCL orchestration mechanism and the external services. A key function of CEP is to map actions (and parameters, where specified) supplied by the Rules Engine to an appropriate interface (operation and arguments) sup- ported by the target business service, including processing responses from the latter. A CEP can generate autonomous messages toward other SCL components, for example, a CEP communicating with a charging business service can inform the SCL after a stipulated time period that there is no credit left for a given user and that the SCL must therefore terminate the ongoing session. The introduction of CEP enables the decoupling of the external service interface with the SCL orchestration mechanism. The CEP can be configured for each individual external service, thus rendering flexibility in the interaction between SCL orchestration mechanism and the external services. The CEP consists of four major components as follows: 1. Interface to the SCL orchestration mechanism in CSP: This interface enables the CSP to send the directives to CEP required for leveraging the functional- ities of external business services. 2. A state machine: It models all possible interactions with an external business service. There are as many state machines as there are external business services to interface with. 3. A timer module: The timer is internally managed with the CEP to trigger asynchronous events for both the SCL orchestration mechanism and the external services. 4. The proprietary interface with external business service: This interface hides all the details of the external service and exposes an abstract interface that accepts events from the CEP to trigger certain actions in the external service and send the response back to the CEP for further processing. 1.3.2.3 Ho