ication of complex control and data flows is also required during the service design. We believe that for application development utilizing Telecom blocks composed with the non-Telecom ones, the following challenges need to be addressed: First, functionality available within a Telecom operator is, in general, exposed using multiple protocols. For example, Presence-related information can be accessed via the SIP protocol, and Messaging capabilities using the Short Message Peer-to-peer Protocol (SMPP). As a step toward hiding protocol heterogeneity and complexity, the Parlay consortium has come up with the Parlay and the subsequent Parlay-X standards. Parlay-X exposes a Web Services interface for several Telecom functionalities. However, it does not cover the whole gamut of functionalities that can be offered by the Telecom operator, especially those requiring session control. Further, some of the Telecom func- tionalities can also be exposed through legacy protocols. Therefore, we need an abstrac- tion model that provides interfaces shielding the application developer from the underlying protocols. This model should also allow seamless switching between differ- ent protocols, for example, when moving from legacy interfaces to the Parlay-X ones. Second, developers who want to utilize Telecom functionality in their applica- tion can belong to different categories [2]. More specifically, composite applications modeled in Figure 1.1 can be written in Java, BPEL, HTML/JavaScript, and SO on. Although editors corresponding to the various programming styles provide the developer with constructs for the non-Telecom blocks, they still require the Telecom functionalities packaged in a format suitable for incorporation. For example, in the case of Java applications, a developer needs a Java interface to invoke these func- tionalities (while a Java-based programming environment lets her code much of the non-Telecom blocks). Similarly, developers require a Web Service Definition Language (WSDL) interface for a BPEL-based compos