ition, JavaScript for a HTML/JavaScript-based composition, and SO on. Therefore, the abstraction model (outlined above) for core Telecom functionalities also needs to be broad to cover a range of programming styles. Third, even though interfaces like WSDL (for Parlay-X) and SIP have tools to generate "clients" for invoking the corresponding functionalities, in real life, however, there is effort required to integrate these clients within the application. For example, code needs to be written to incorporate the client in the application code, while taking care of tertiary library dependencies for this client. It would help the developer immensely if the abstraction model pregenerates the clients corresponding to different programming styles, and packages them in a structured Service Composition and Control manner. Having a well-defined structured format would enable any application development environment (with some extensions to interpret this structure) to integrate these clients seamlessly. Finally, when Telecom functionality gets used in an application, the Telecom operator, as well as the application developer, wants to coordinate its usage. For instance, one needs mechanisms for embedding logic for charging, specifying access control policies, and SO on. Furthermore, with recent trends suggested by Web 2.0, application developers should be able to contribute, implicitly or explicitly, to the enrichment and refinement of the exposed Telecom functionality (and its usage). Therefore, the abstraction model needs to be rich enough to enable all of this. A number of operators are already moving in the direction of making their core functionalities available for application development. For example, British Telecom has released a Software Development Kit [5] that enables its network services to be utilized in Web mashups. However, what is missing is an abstraction model which is broad, structured, and rich, as motivated above. We describe such a model next, and thereafter present a service creation framework on top