tion is based on suit- ability (e.g., reading more about each proxy) and other metadata (QoS param- eters like reputation, etc.). 4. Proxy configuration: The developer optionally associates various service coor- dination rules with each proxy. For example, she specifies the time period after which cached location information is to be refreshed by the Location proxy. 5. Codegeneration: Outputs code for the designed service (BPEL, Java, JavaScript inside HTML, etc.). This step is described in more detail in the next subsection. 6. Incorporate other constructs: The developer incorporates appropriate applica- tion logic, UI elements, and SO on to complete the service. At this point, the developer also takes care of data flow between different constructs. * In practice, a Composition Studio would already have some code generation capabilities. In this case, we just need to extend these capabilities to incorporate the proxy model. Service Delivery Platforms 1.2.4.3 Code Generation From a developer's view, once a service has been designed and relevant proxies for the Telecom blocks selected, she expects the composition environment to generate a skeleton code that not only captures the service flow, but also integrates the code for the selected proxies. Further, this code should provide her the extension points to include application logic and other constructs for the non-Telecom blocks. We divide this process of "Code Generation" into three steps (Figure 1.4): 1. Capture service design: Service design is captured in a structured document that we call processDoc. Further, for each Telecom block, processDoc stores information about the proxy that was selected, and the API that was chosen under this proxy. It should be noted that the structure of processDoc and the information it stores is dependent on the programming style of the applica- tion. More specifically, it should be able to represent each programming construct of that style. 2. Generate process skeleton: This step takes processDoc and transforms it to a concrete