 meter its usage. For instance, whenever the proxy corresponding to Location information gets invoked within an application, the Telecom operator can authenticate the developer and also charge some amount. In this case, proxies are configured to collect the relevant informa- tion, for example, developer Id, from the developer and send it to the operator. Similarly, the developer can configure the Location proxy to cache the location information locally within itself, and avoid connecting to the operator's infrastruc- ture at each invocation. The proxy model also provides an easy mechanism to incorporate various busi- ness contracts between the operator and the developer. For example, the implemen- tation module in a proxy can be extended to make the proxy display advertisements on behalf of the operator, whenever it is invoked. In this case, logic can be such that the proxy picks what to advertise on a real-time basis. Collaboration and reuse: Using the proxy model, developers can collaborate, share, and contribute toward enriching Telecom functionality. For instance, the user of the Location proxy in an application can publish a utility to parse the output of this service. This utility can be reused by other developers while incorporating this proxy in their applications. Similarly, the proxies can be configured to provide updates to a developer about new entries on the blog, utilities published recently, bug fixes, and SO on. In the case of bug fixes, logic can be embedded in the proxy to automatically download the latest implementation modules. 1.2.4 SewNet Details Next, we present the SewNet framework that utilizes the rich, structured T-Rec proxy model to enable seamless weaving of Telecom functionality with application logic and other constructs required to develop a service. 1.2.4.1 SewNet Architecture As Figure 1.3 shows, SewNet has two main architectural components-SewNet Core and Composition Studio(s). SewNet Core forms the backbone architecture that exposes Telecom functional- ity to developers through