 of this model. 1.2.2 T-Rec Model Figure 1.2 represents the basic concept of the T-Rec "Proxy" model. In essence, once an application has been broken down into Telecom and non-Telecom blocks, this model is used to realize the Telecom blocks, considering the programming style, while also enabling mechanisms for coordination and enrichment. In prac- tice, these proxies would be created by a Telecom operator and be made available to application developers over the Web (or a converged IP network). 1.2.2.1 T-Rec Structure The rich, structured T-Rec Proxies consist of the following elements: Proxy representation: Contains signatures of the methods (Application Programming Interface (API)) exposed by the proxy along with a textual Composed service Reference Java/ JavaScript/ Encapsulation Telecom Telecom functionality block Parlay-X/ Coordination Legacy protocols T-Rec Proxy Figure 1.2 T-Rec "Proxy" model. Service Delivery Platforms description of the service it represents. The APIs are designed to hide protocol- specific details and abstract the Telecom functionality to the programming language level. As discussed before, APIs corresponding to multiple styles (Java, BPEL, and JavaScript) should be created to support different environments. Implementation: This module connects to the Telecom service using the underlying protocol, and is available in different formats. For example, the implementation could be in the form of a .jar file for a Java proxy, a .js file for JavaScript, or could be encapsulated by visual constructs, such as widgets, and used inside HTML pages. Configuration file: Proxies come with a default setting but can be further configured by developers. This includes assigning default values for some of the parameters in an API, specifying the access control list, and SO on. Such settings could also be functionality specific, for instance, restricting the size of SMS messages. Metadata: To enable easy look up, keywords and tags related to the proxy functionality are associated with it. New tags can be add