## 1 Introduction
There have been some initiatives in bringing SaaS offerings from different providers into a joint solution, e.g., the Appirio CloudFactor [5] combines the SalesForce's CRM SaaS offerings with the Google Apps SaaS offerings. However, we observe the lack of a generic approach for integrating SaaS offerings across multiple providers. From the preceding discussion it is apparent that the current cloud solutions are fraught with problems:  
* They introduce a monolithic SaaS/PaaS/IaaS stack architecture where a one-size-fits-all mentality prevails. They do not allow developers to mix and match functionality and services from multiple application, platform and infrastructure providers and configure it dynamically to address application needs. * They introduce rigid service orchestration practices tied to a specific resource/infrastructure configuration for the cloud services at the application level. * The above points hamper the (re)-configuration and customization of cloud applications on demand to reflect evolving inter-organizational collaborations. There is clearly a need to mash up cloud services from a variety of cloud providers to create a Service-based Application (SBA). This type of integration allows the tailoring of services to specific business needs using a mixture of SaaS, PaaS and IaaS. SBAs in the cloud are normally delivered in terms of end-to-end business processes that are usually syndicated with other external SaaS (possibly provided by diverse SaaS providers). SBA developers need to couple their applications in whole or part with external SaaS offerings to provide opportunities related to other areas of their clients' business. Hence, a causal connection of SBA-level operations to configurable supporting SaaS, PaaS and IaaSs is required to allow the full automation and optimization of SBA development and maintenance activities. The above mentioned approach promotes autonomous services (at all levels of the cloud stack) that adhere to the well-established software engineering principle of \"separation of concerns\" to minimize dependencies. This approach allows any service at any layer, _i.e._, SaaS, PaaS or IaaS, to be appropriately composed with a service at the same level of the cloud stack or swapped in or out without having to stop and modify other components elsewhere. Furthermore, SBA developers can rely on existing work to solve incompatibility issues that may occur during the service composition, e.g., the work in [6] solves the incompatibility issues between structural service interfaces and the work in [7] helps to adapt service protocols. At the same time, the above approach also allows multiple (and possibly composed) PaaS and IaaS options for deploying a given SaaS. To ensure the portability between different cloud providers, standards like the Open Virtualization Format (OVF) [8] may be used as part of an IaaS to describe the virtual machine packaging in a uniform way. Our proposed approach takes all these issues into consideration and thus leads to a _syntacated multi-channel delivery model_, which is illustrated in Figure 1, where it is contrasted with the monolithic cloud stack solutions that permeate the cloud today. Monolithic cloud solutions are shown to enforce one-way vertical deployment \"channels\". Cloud Blueprinting is a novel powerful solution allowing SBAs to dynamically run on top of federated cloud virtualization solutions. The SaaS components of a SBA are abstracted and described in a series of templates to provide a fast, simplified method for provisioning and automating cloud services. Cloud Blueprinting seeks to simplify deployment by hiding away the complexity of deploying a SBA by helping to manage all configuring of the underlying middleware and integrating with optimal PaaS and IaaS options. It achieves portability across clouds and cloud providers to leverage the benefits of elasticity and scale. It supports a flexible top-down continuous closed-feedback loop service refinement and improvement approach.