begin with, SCL models a Telecom service as a state machine (Figure 1.6). During Service specification Business rules Rules UI Analyse service Transition interactions (interaction) Service Model interactions of interest profile Specify rules/ templates Enabler protocol Specify actions Runtime Design time Figure 1.6 Flexible rule-driven service delivery in SCL. Service Delivery Platforms the execution of an SIP service, SCL listens for the exchange of service interactions (e.g., SIP INVITE) of interest between parties (applications and users) engaged in a service). Rules are then attached to state machines, typically for actions on state transition, such that they are triggered for evaluation on processing of a given protocol message. Each action is, in turn, mapped to a service-oriented capability that needs to be blended during service delivery. These actions invoke service- oriented external business capabilities at runtime in order to control, enhance, or personalize the service. The external capabilities are invoked through a configu- rable interface or Control Enabling Proxy (CEP). The CEP abstracts out the func- tionality of the external services and manages the interaction between SCL and the services transparently. 1.3.2.1 System Architecture Figure 1.7 illustrates the system architecture of the SCL. The core components and their functionalities are described as follows. The Protocol Adaptation module handles different incoming protocol messages (e.g., SIP), and translates them into an internal format (known as Common Format Business Objects) for processing within the SCL. Additionally, it includes an SIP Service delivery capabilities Control enabling proxies Control sequence processor State machine engine Event Service/Party dispatcher identification Capability profile orchestration External databases Protocol adaptation SIP processor Service control layer Service interaction e.g. SIP INVITE IMS and CSP Subscribers Service logic Figure 1.7 SCL architecture. Service Composition and Control processor that 