search in network service management. Some of the early works [20,21] in IP service control were targeted for legacy net- works, mostly in an ad hoc manner. Later, IP-based service control was somewhat formalized [22] for next-generation networks by standard bodies such as 3GPP, resulting in overlay service control frameworks (namely IMS) for delivering advanced services. Service control in IMS, however, is very rudimentary and much of the flexibility in service control has been delegated to a fuzzy architectural com- ponent, namely SCIM, which has been left to the vendors for design and imple- mentation. Stray attempts have been made to realize the SCIM functionalities and beyond. For example, JSR 289 [23], which is aimed at enhancing the capabilities of JSR 116 [24] SIP Servlet specification, is a step in the direction of standardizing the orchestration capabilities of SCIM in a converged Web-Telecom service layer. A key agenda of JSR 289 is to make HTTP (SOAP)-based services available on the same platform with SIP-based services. An early SCIM implementation has been reported in [25] but fails to address the flexible control requirements imposed by blended services. With the emergence of Web 2.0 and a large number of short-lived services in this paradigm, the requirement of flexible service control has become even more critical. A number of vendors have started offering service development and deploy- ment platforms in this space. Examples are BEAs Aqualogic [16], British Telecoms Web21C [5], and Microsoft's Connected Services Framework Sandbox [18]. The key feature of all these offerings is the exposure of Telecom services as lightweight widgets, which are easy to incorporate in a mashup environment. However, none of these consider runtime control and mediation of the mashup services. To bridge Service Composition and Control this gap, the SCL architecture was proposed in [3] for executing Telecom mashups in a Web 2.0-oriented domain. 1.4 Illustrative Example We now demonstrate how the twin components of Serv