Service Engineering and Lifecycle Management: Scientific and Technical Report D2.1.3

(1)

Building the PaaS Cloud of the Future

Service Engineering and Lifecycle

Management: Scientific and

Technical Report

D2.1.3

Version 1.1

WP2 – Service Engineering and Lifecycle Management

Dissemination Level: Public

Lead Editor: Francesco Lelli / Geert Monsieur, ERISS

15/07/13

Status: Final version

The research leading to these results has received funding from the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 258862

(2)

This is a public deliverable that is provided to the community under a Creative Commons Attribution 3.0 Unported License: http://creativecommons.org/licenses/by/3.0/

You are free:

to Share — to copy, distribute and transmit the work to Remix — to adapt the work

Under the following conditions:

Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

With the understanding that:

Waiver — Any of the above conditions can be waived if you get permission from the copyright holder.

Public Domain — Where the work or any of its elements is in the public domain under applicable law, that status is in no way affected by the license.

Other Rights — In no way are any of the following rights affected by the license: Your fair dealing or fair use rights, or other applicable copyright exceptions and limitations;

The author's moral rights;

Rights other persons may have either in the work itself or in how the work is used, such as publicity or privacy rights.

Notice — For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this Web page.

For a full description of the license legal terms, please refer to: http://creativecommons.org/licenses/by/3.0/legalcode

(3)

Contributors: Yehia Taher Dinh-Khoa Nguyen Francesco Lelli Geert Monsieur Dragan Ivanovic Internal Reviewer(s): Frederic Junker, HSG Rouven Krebs, SAP

Version History

Version Date Authors Sections Affected

0.1 28/05/2012 Yehia TAHER Initial version with table of contents

0.2 14/06/2012 Yehia TAHER Second version of the initial version with table of contents. 0.3 24/06/2011 Yehia TAHER Third draft of the document 0.4 30/06/2011 Yehia TAHER Fourth Draft of the document 0.5 1/07/2011 Yehia TAHER Fifth Draft of the document 0.6 10/07/2011 Yehia TAHER First Draft for Internal Review 0.7 13/07/2011 Yehia TAHER Final version integrating the

reviewers’ feedback

0.9 6/06/2013 Francesco Lelli Improved related work, new layout

1.0 28/06/2013 Geert Monsieur First Draft for Internal Review 1.1 15/07/2013 Geert Monsieur Final version – addressing

(4)

Abbreviations

API Application Programming Interface

AWS Amazon Web Service

BCL Blueprint Constraint Language

BDL Blueprint Definition Language

BML Blueprint Manipulation Language

BPEL Web Services Business Process Execution Language

BQL Blueprint Query Language

CRM Customer Relationship Management

DMTF Distributed Management Task Force, inc.

EC European Committee

ECP Elastic Cloud Platform

IaaS Infrastructure as a Service

IT Information Technology

IU Installable Unit

KPI Key Performance Indicator

LTL Linear Temporal Logic

MDE Model Driven Engineering

OASIS Organization for the advancement of Structured Information Standards

OCCI Open Cloud Computing Interface

OVF Open Virtualization Format

PaaS Platform as a Service

QoS Quality of Service

(7)

SaaS Software as a Service

SBA Service-Based Application

SCA Service Computing Architecture

SDD Solution Deployment Descriptor

SLA Service Level Agreement

SM Service Manager

SOA Service Oriented Architecture

SOAD SOA Analysis/Design Modelling

SOAF SOA Framework for service definition and realization SOCCA Service Oriented Cloud Computing Architecture SOMA Service Oriented Modelling and Architecture SOMF Service Oriented Modelling Framework UUID Universally Unique IDentifier

VEE Virtual Execution Environment

VM Virtual Machine

VMAN Virtualization Management

VPDC Virtual Private Data Center

WP2 Work Package 2 (of 4CaaSt Project)

XaaS Everything as a Service

XCP Xen Cloud Platform

XML Extensible Markup Language

(8)

1.

Executive Summary

Recently, Cloud computing has become an emerging research topic in response to the shift from product-oriented economy to service-oriented economy and the move from focusing on software/system development to addressing business-IT alignment.

From an IT perspective, there is a proliferation of methods for Cloud service development. Such methods have clearly shown considerable shortcomings to provide an efficient solution to deal with major aspects related to cloud service-based applications. One of these major aspects is the multi-tenancy of SaaS applications used to compose service-based applications. Current SaaS offerings are often provided as a monolithic one-size-fits-all solution and give little or no opportunity for further customization. As a result, monolithic SaaS offerings are more likely to show failure in meeting the consumers’ individual business requirements.

In this deliverable, we analyze the state-of-the-art of the cloud development, integration and management, identify some shortcomings, and introduce the Cloud Blueprinting approach as a novel approach for breaking down the monolithic stack of cloud service offerings and providing an effective and flexible solution for cloud service-based application designers to select, customize, and aggregate cloud service offering coming from different providers [38],[39].

(9)

2.

Introduction

This technical report belongs to the 4CaaSt work package 2 (WP2) and builds the basis for the upcoming Component Design and Open Specification Deliverable (D2.2.3). It mainly evaluates the state-of-the-art on the cloud service development, integration and management with respect to the SaaS, PaaS, and IaaS layers. Therefore, some shortcomings of existing approaches are identified and requirements for the WP2 proposal (the Cloud Blueprinting approach) are derived. Finally, we show the progress made over the third reporting period (RP3 by providing a high level description of the Cloud Blueprinting approach developed in the context of WP2. This will highlight the link with D2.2.3 that is providing more insight into the different components of the Cloud Blueprinting approach.

2.1.

Motivation and Problem Statement

A cloud ecosystem comprises an assembly of IT resources spanning various cloud providers and diverse (public or private) clouds where each part can be independently selected by the developer and then put together, on demand, by the cloud provisioning system over the Internet [6,12]. In this way, consumers, providers and enterprises will be able to choose freely among a pool of service providers, and service providers will be able to use from other providers any kind of cloud capability – irrespective whether this capability in at the level of infrastructure (IaaS), platform (PaaS), or application (SaaS) – to allow a service aggregation to handle exceptional loads on their own offerings.

Aggregating disparate cloud computing infrastructures with each other allows disparate cloud resources, capabilities, capacity, monitoring, and management to be shared, much like power from a power grid. This means that cloud resources must be able to work together, regardless of whether they are co-located or remote. This approach requires serious efforts to integrate existing infrastructure architecture. Unfortunately, integrating public and private clouds cannot become a reality unless integration issues, such the ones highlighted earlier, are resolved.

Cloud integration goes well beyond the use of common APIs. It needs to fuse interoperability with portability and effective cloud resource management. Cloud integration requires, in addition to common APIs, clear separation of concerns (and control), flexible mappings of cloud resources to services, higher-level forms of abstraction to automate the allocation of resources and to allow for resource sharing and management at a finer level of granularity. It also requires creating a cloud solution with one of its portions running on internal systems, and another portion delivered from the external cloud environment in which on-going data exchanges and process coordination occur between the internal and external environments. When it comes to integrating cloud resources across organizational boundaries, and integrating multiple stakeholders, contemporary cloud technologies face insurmountable obstacles – since they have not been designed with cloud integration in mind. Their major drawbacks can be summarized as follows [49].

– They follow a bottom up (or pull) producer-centric approach to development. Consumers try to ‘squeeze and bolt’ applications onto existing standard cloud APIs without being able to consider the broader application picture and needs. By shifting the burden of conformity to the consumer, the provider basically requires the user to

(10)

burden of installation and configuration post-provisioning to put together the proper cloud environment they need.

– The biggest obstacle is that contemporary cloud technologies introduce a monolithic SaaS/PaaS/IaaS stack architecture where a one-size-fits-all mentality and vendor lock-in prevails. For instance, the SaaS cloud consumer is provided with a SaaS offering which resembles an indivisible block. The SaaS application is inseparable from the platform, which in its turn is inseparable from the infrastructure on which it runs. As a consequence developers cannot mix and match functionality from diverse cloud tiers and configure it dynamically to address their needs. Modularity, which is incumbent with the advent of service-oriented (SOA) solutions, is obviated.

– The consumer usually does not have knowledge of (or control over) the precise physical location, neighboring workloads, hardware, hypervisor, and various other components that are provided by the cloud provider. The consumer has no freedom to manage the aggregate of all cloud services it needs to best optimize their environment. All the above deliberations lead to an inflexible and costly environment, which adds serious complexity, demands serious programming efforts, requires multiple patches and perpetuates vendor lock-in. Many of the benefits of cloud, which are achieved through scale and consolidation, are less forthcoming when consumers cannot exercise any control over the cloud environment.

In a similar manner, cloud management is still not entirely automated even in a single cloud provider environment. Cloud management focuses on the ability to exercise administrative and supervisory actions to help providers manage operations, resource availability, and workload capacity effectively across a variety of distributed cloud infrastructures. To get the most value from the cloud, providers must manually resolve sub-optimal configurations, and maintain an on-going balance between capacity utilization, cost, and service quality [50]. To summarize the points raised above, integration and manageability problems are so intricate and serious that they can be addressed only by designing from basic principles (i.e., from scratch) a novel cloud computing integration and management reference architecture and delivery model to support and automate the integration and management of cloud services. Moreover, this architecture must transform a silo-ed approach to one that is holistic and application aware.

2.2.

Contribution

The shortcomings and rigidity of cloud computing services highlighted above prohibit the development of flexible cloud-enabled service based applications. These limitations can be addressed by combining Service Oriented Architecture with cloud services resulting in a mixing and matching of external services with on-premise assets and services. This merger offers unprecedented control in allocating resources dynamically to meet the changing needs of service-based applications, which is only effective when the service level objectives at the application level guide the cloud’s infrastructure management layer. The combination of SOA with cloud computing concepts brings together scalability, speed, modularity, reuse and the choice of the most appropriate implementation and deployment infrastructure for end-to-end services. Those basic principles must allow us to develop novel approaches that revolutionise the way service development is conducted by giving rise to the notion of smart Internet.

Moving successfully into smart services poses challenges and opens up possibilities for pioneering research. Not only does it require novel concepts and techniques that will infuse

(11)

cloud capabilities into SOA but also requires that application appropriateness be tested and be optimized against both business and technical characteristics. From a business perspective, the application needs to be evaluated in terms of core functionality, service reuse, QoS, compliance requirements, and Service Level Agreement term stipulations. From a technical perspective, the application needs to be evaluated in terms of usage, performance, latency, service-level needs, execution environment and dependencies. Proper application partitioning and fit leads to better performance, scale, ease of change and efficiency than would otherwise be possible.

Our main contribution in this deliverable is twofold:

• An up-to-date state-of-the-art analysis on the Cloud Service development, integration, and management leading to identifying some shortcoming, goals, and requirement for our blueprint proposal.

• A high-level description of the Cloud Blueprinting approach, which aims at realizing the aforementioned view of combination of SOA with cloud computing concepts [38], [39].

2.3.

Document Structure

The rest of the deliverable is organized as follows. Section 3 presents WP2 in a nutshell while highlighting some challenges and research questions. Section 4 introduces a motivating scenario that illustrates the need of our proposal, the Cloud Blueprinting approach. An up-to-date state-of-the-art – extending the one presented in deliverable D2.1.2 – is presented in Section 5. Shortcomings and objectives derived from the evaluation of the state-of-the-art are identified in Section 6. Section 7 presents the WP2 scientific results, namely the Cloud Blueprinting approach, made during the RP3 while Section 8 presents the practical results, namely the Cloud Blueprinting prototype implementation. Section 9 concludes the document.

(12)

3.

WP2 in a Nutshell: Challenges and

Research Questions

Cloud service integration and management provides the means to integrate cloud services to ensure that a cloud application is both active and functioning properly, as well as to check the performance of an application (at any tier of the cloud stack) over time. Cloud integration and management address six necessary integration/management questions:

1. What cloud services need to be integrated or managed? 2. What are their properties?

3. How can we create composite cloud services when they are dependent on external cloud services and content that crosses organizational and geographic borders? 4. Can an aggregated cloud service that abstracts a resource support a specific

workload or should this workload be partitioned between resources?

5. What are the relationships among the integrated and managed cloud resources? 6. How is the management information exchanged (operations, events, notifications,

etc.)?

Figure 1. Elements of Cloud Service Integration and Management

The functional parts for cloud integration and cloud manageability are depicted in Figure 1. The integration part in the center of this figure serves the purpose to guarantee architectural compatibility and inter-working of the planned cloud services and other critical applications. It comprises two integral functional parts: portability and interoperability.

– Cloud portability means that workloads can move around providers and clouds. It means the migration of full application configurations across clouds and the migration of live deployments across heterogeneous clouds (with bounded downtime).

– Cloud interoperability is the ability to use and seamlessly orchestrate cloud services from distinctly separate and independent cloud service providers and clouds [45], [46]. Given that the various tiers in cloud stack pose different requirements with respect to interoperability, interoperability in Cloud-Sourcing is approached from the perspective of two dimensions:

1. Vertical cloud interoperability is between adjacent tiers in the cloud delivery spectrum, e.g., SaaS-to-PaaS, and PaaS-to-IaaS, no matter if these are provided by diverse cloud providers.

(13)

2. Horizontal cloud interoperability is between the same tiers in the cloud stack but between different cloud stack silos, i.e., cross-SaaS, cross-PaaS or cross-IaaS interoperation.

Cloud Service Management includes all of the service-related functions necessary for the management and operation of cloud services required by cloud developers. Cloud service management can be described from the perspective of the following technical dimensions [44]:

– Rapid resource provisioning: A cloud-based application must have the capacity to handle all kinds of demands being made upon it at run-time, such as the need for additional servers to be provisioned and configured dynamically by an automated provisioning engine.

– Configuration: carries out the actual configurations, it reshapes the cloud environment to meet the needs of the requested services (pull-model). This can include definitions of application stack and system configuration as well as runtime configuration and scaling rules management.

– Monitoring and troubleshooting: When a cloud-based application is running, cloud resources should be monitored for bottlenecks and for user-defined thresholds that exceed the prescribed limits to identify potential problems before they are manifested. This is cloud-sourcing for dynamic logging and testing.

– Auditing and Tracking: This provides the ability to observe aspects of a single unit of work or thread of execution across multiple inter-linked cloud resources. Cloud services should be audited and measurements can be used to compare against SLA stipulations. Tracking helps understand where the workload ran, if it completed, how long it took, and, if it did not complete, why. This provides an audit trail for use in operations management.

(14)

4.

Motivating Scenario

This section presents an enterprise Cloud Computing scenario developed for the EC’s 4CaaSt project. Several industrial IT companies, including Telefonica, Telecom Italia, Ericsson, 2ndQuadrant and SAP, have been involved in the definition of this scenario, which is presented as a simplified description of today’s industrial reality. The aim is to provide a case study that is sufficiently complex for capturing real problems and sufficiently simple for proposing and validating research solutions. The scenario promotes a uniform description for cloud service offerings to exist so that the design, configuration, and deployment of a cloud-based solution can occur.

4.1.

Scenario Description

As illustrated in Figure 2, the scenario is about developing a process-based application in the cloud that can receive an order for a taxi from the customer by SMS, check the current status of the taxi fleet, allocate a taxi, and finally confirm the order by SMS. It involves seven actors that collaborate in a marketplace where their cloud services can be offered and purchased. In the following, each actor is described.

There are three actors involved in the scenario that provide complete monolithic PaaS and IaaS offerings hosted on their in-house infrastructure.

1. 2ndQuadrant is a PaaS provider specializing in storage services. It offers the relational PostgreQL Service (PostgreQL-PaaS) or the relational MySQL Service (MsSQL-PaaS) as two alternative solutions for relational database, where each consumer can request for up to five instances of a solution.

2. TelecomItalia is another PaaS provider that provides the native Context-as-a-Service offering for context information delivery (CaaS-PaaS) [40].

3. JonasTeam is another PaaS provider that has two offerings in the marketplace. The first one is a JOnAS server to host Java applications including a Tomcat container to support the execution of servlets (Jonas-PaaS). The second one is an IaaS offering for a 3Gbit Ethernet network link (Ethernet3Gbit-IaaS).

OrchestraTeam is also a PaaS provider that offers an Orchestra BPEL Engine ( Orchestra-PaaS). OrchestraTeam differentiates itself from other PaaS providers in a way that their offering Orchestra-PaaS is not complete and relies on external cloud platform and infrastructure resources for the deployment. In particular, the binary implementation file of the Orchestra engine (OrchestraBinary) needs a Servlet container (Servlet-Req) for the deployment. It is also required that the Servlet-Req is connected to two relational databases (SQL-Req) through a 2Gbit network (NetworkLink2Gbit-Req). To maintain the Quality of Service (QoS) promised in their offering, i.e., response time <= 2s and throughput >= 110 request/s, OrchestraTeam requires the Servlet-Req to be constrained by these QoS assertions as well.

(15)

Figure 2. The 4CaaSt Cloud Computing Scenario

On the SaaS level, Tele1 is a telecom company that provides a basic SMS Delivery SaaS (SMS-Delivery-SaaS) that is hosted on their in-house platform.

In contrast, AutoInc is an established Medium Enterprise and has spotted a business opportunity providing fleet vehicle management in the Netherlands. They plan to deploy their business functions as a Taxi Management SaaS (TaxiMgt-SaaS), since this provides ubiquitous and common access for their prospective customers, e.g., taxi providers and car-hiring providers. To implement the solution, AutoInc has contracted a software consultancy who wrote the taxi management software in Java and BPEL. The software hence contains a number of war files, bpel files and other binary and configuration files (see Figure 2 for more details). The software hence requires a JEE Server (JEE/Servlet-Server-Req) including a Servlet v2.5 for deploying the war files for the web interface, a BPEL Engine ( BPEL-Engine-Req) for deploying the core BPEL process files of the taxi application, and a context information provider (Context-aaS-Req) that is needed by the CMF.war file. The BPEL-Engine-Req is required to be deployed on the JEE/Servlet-Server-Req, and the JEE/Servlet-Server-Req is required to be connected to the Context-aaS-Req and to the outside through a network link with 3Gbit bandwidth (NetworkLink3Gbit-Req).

TaxiTilburg is a provider of a taxi ordering application that is delivered to the customers in terms of a workflow (TaxiOrdering-SBA). In order to implement the steps of their workflow,

(16)

TaxiTilburg completely relies on the SaaS offerings TaxiMgt-SaaS of AutoInc and SMS-Delivery-SaaS of Tele1. To maintain the predefined Quality of Service (QoS) level, TaxiTilburg insists AutoInc to specify the QoS requirements for the prospective platform’s resources of the TaxiMgt-SaaS offering. In particular, all the required platform resources

JEE/Servlet-Server-Req, BPEL-Engine-Req, Context-aaS-Req should ensure a throughput >=100 req/s and a response time <= 3s.

TaxiTilburg also has policy constraints that cannot be violated by the entire end-to-end system landscape 1. These policy constraints prescribe that all the data must be stored only within the Netherlands and all the data communications must be over the Secure Socket Layer (SSL).

In summary, TaxiTilburg has designed their TaxiOrdering-SBA offering as an SBA, since the required SMS-Delivery-SaaS, TaxiMgt-SaaS and the other required platform and infrastructure resources are not under their direct control. Deploying the TaxiOrdering-SBA

on the cloud requires a syndication of the SaaS, PaaS and IaaS offerings of other providers.

4.2.

Scenario requirements

Requirement 1: The 4CaaSt Scenario shows the need for an abstract, uniform, and platform-agnostic description for cloud-based SaaS and PaaS/IaaS that allows specifying not only their offerings but also resource constraints. In this description, the offering is specified in association with a set of KPI values and policy statements. Similarly, resource constraints are associated with a set of non-functional constraints including the QoS, architectural and policy constraints. Furthermore, to achieve the promised KPIs and policy statements in the offering, the description should contain a set of invariant constraints that must not be violated by the cloud service itself and all the external required resources.

Requirement 2: It is necessary to provide a technique to amalgamate cross-layered offerings from different SaaS and PaaS/IaaS providers to support the design, configuration, and deployment of end-to-end composite SaaS offerings.

As mentioned earlier, there is still a lack of support in building such an SBA in the cloud. Based on this case study, we will describe in the following sections the cloud blueprinting approach to select and compose different cloud service offerings to develop such an SBA.

(17)

5.

An Up-to-Date State-of-the-Art

This section summarizes the efforts that have been recently put to describe, represent, and manage cloud services and resources.

This section can be considered as an extension of the extensive state-of-the-art study that has been presented in Deliverable D2.1.1 and Deliverable 2.1.2. This extension includes some recent works that haven’t been discussed in the previous deliverables.

In addition we divided the existing works in: • State of the Art related to SOA; • State of the Art related to IaaS; • State of the Art related to PaaS; • State of the Art related to SaaS.

5.1.

Service Specification Languages in SOA

The de facto standard in specifying services in the SOA domain is to use the Web Service Description Language (WSDL) [51]. It is an XML-based specification schema that allows users to specify the interfaces, operations, message structures, data types of the message payload, binding protocols, and the endpoint addresses of a (Web) service. Using WSDL, a web service can be specified with multiple interfaces (portTypes), where each interface contains a set of operations and each operation is defined with a set of input and output messages. An interface can be mapped to several binding protocols and each binding protocol is defined for a particular endpoint address of the web service.

WSDL has been recognized as the dominant standard for specifying web services, since it is backed by a strong industry support. However, WSDL focuses only on the operational specification of a single service. Hence, other specification standards have been proposed to complement WSDL such as the Business Process Execution Language (WS-BPEL)[52] for composing web services and the WS-Policy [53] for specifying the policy description of a web service. As a result, these standards have collectively formed a Web Service technological stack (or the WS-* stack).

WS-BPEL [52] is an XML-based composition language for web services. A WS-BPEL specification sits on top of the WSDL specifications of other web services and defines a flow of interactions with these web services. WS-BPEL supports the basic constructs of a flow such as the sequence, parallel branches, conditional branches, etc. For each service interaction, WS-BPEL supports the definition of input and output messages by importing the WSDL of a constituting web service.

WS-Policy [53] supports the policy specification of a web service. Similar to other standards in the WS-* stack, it is also an XML-based language and built on top of the WSDL standard. Using WS-Policy, a policy profile can be defined for a web service, which contains a set of policy alternatives. Each policy alternative contains a set of policy assertions. Each policy assertion is specified for a WSDL operation to prescribe either a requirement or capability of its exchanged messages (e.g. the encryption, transport protocol, authentication, etc.) or a non-functional property related to its selection and usage (e.g. QoS property).

(18)

One of the shortcomings of the WSDL is that it supports only the structural specification of a web service. To complement WSDL, the semantic web community has introduced several initiatives to enrich a WSDL specification with more semantic information. For instance, the OWL-S [54] is an OWL ontology that allows for describing the functional and operational semantics of a web service. The operational semantics is described in the sub-ontology “Service Profile” and the functional semantics is described in the other two sub-ontologies “Service Model” and “Service Grounding” in conjunction with a WSDL specification. Another initiative is the WSDL-S [55] that supports semantic annotations directly on a WSDL specification. Lastly, the Web Service Modeling Ontology (WSMO) provides a conceptual framework and a formal language for semantically describing all relevant aspects of Web services in order to facilitate the automatic discovery, composition and binding [56].

It is worth to mention that apart from the languages that specifically target the Web Service technology there exist also other languages that aim for a more general specification of services in a SOA system, which will be mentioned in the following.

The W3C Unified Service Description Language (USDL) Incubator Group3 has been formed

to develop a general language for specifying both the business and technical services. The outcome of this group is the Universal Service Description Language (USDL) [57], which aims to complement the technical service specifications, e.g. using WSDL, with business and operational information. The language can be used by both the service consumers and providers for different purposes: providers can design their services in a tradable and consumable way whilst consumers can use the language for service discovery based on the required business capability. USDL is a generic language that aims for standardizing the service sector, and hence can be extended in several industry domains. It is delivered as a set of reference models that describe many business and technical aspects of a service. The OASIS Reference Model for Service Oriented Architecture [58] provides a reference model for building an entire SOA system. It aims to provide a common understanding of entities and their relationships in a SOA system and can be used to develop standards for specific entities in SOA. In contrast to WSDL and WS-BPEL, this reference model is an abstract model that is not tied to any particular SOA technology and hence can serve as a common reference model across several SOA implementations. The OASIS reference model defines three conceptual views: service ecosystem, realization, and ownership, in which service specification falls under the realization view.

The CBDI-SAE Meta Model for SOA [59] is a meta-model defining the concepts in the CBDI Service Architecture & Engineering Reference Framework, an initiative of the Everware-CBDI consulting company4. Similar to the OASIS reference model, CBDI-SAE Meta Model

for SOA aims to provide a consensus on the definition of a SOA system by conceptualizing the key components of many aspects of a SOA system. Different aspects of SOA are captured in different modeling packages: technology, organization, policy, business modeling, service modeling, deployment, runtime, etc. The CBDI-SAE Meta Model is technology-agnostic. It can be implemented using a concrete SOA technology, e.g. using the WS-* stack or REST.

It is interesting to see that both the OASIS Reference Model and the CBDI-SAE meta model recognize the significance of a reference model for SOA while remaining technology-agnostic. Both of them use the Unified Modeling Language (UML) [60] as the modeling and communication language for their models. Another initiative to define a reference model for SOA based on the UML is the Service-oriented Architecture Modeling Language (SoaML) specification [61] proposed by the Object Management Group (OMG). The SoaML

(19)

specification provides a metamodel and an UML profile that cover both the business and technical specification of a service. Its main goal is to support the modeling and design of a service in a SOA system with a set of core attributes. SoaML can be extended with attributes related to a specific domain. For instance, the work in [62] has proposed specific service attributes and modeling guidelines to use the SoaML for specifying services in the cloud domain.

Another approach for specifying SOA service in a technology-agnostic is to use the Abstract Service Description (ASD) meta-model introduced in [63]. The ASD meta-model in this work is a specification schema for specifying an interface of a service including its structural, behavior and non-functional description. It aggregates the important concepts found in widely adopted technologies like WSDL and WS-BPEL, as well as from the high-level reference models like the OASIS reference model for SOA and the CBDI-SAE meta-model. However, this approach captures only the interface of a service and aims only to provide a mechanism to control the service evolution.

Finally, O’Sullivan proposes in his thesis [64] a taxonomy of non-functional properties for service specification. This work does not specifically target web services or services in a SOA system, but can be used for any types of services. Its aim is to provide a more precise matching and discovery of services based on their non-functional properties. The properties proposed in this work are domain-independent and can be used in different industry domains.

5.2.

IaaS Specification Language

The ability to manipulate, integrate and and orchestrate the deployment of IaaS resources for cloud application development has been proposed in the early time of cloud computing, e.g. through the “Sky Computing” [65] and “Intercloud” [66] proposals. However these proposals fall short of proposing a solution for the problem at hand due to a lack of standardized language to specify the IaaS resources. Since then, much of the recent work in cloud computing specifically focus on supporting a common, standardized specification for IaaSs. In this section, we review and evaluate the existing specification languages for IaaS. The section is divided into 4 parts based on the most common representation techniques provided by these languages. We observe that one group of the IaaS specification languages is based on a template structure which is either a well-defined standard, e.g. the OVF template [12], or a proprietary template of a vendor, e.g. Amazon Formation. The other group of IaaS specification languages follows the model-driven engineering approach by specifying IaaS using models and model transformations.

5.1.1 . Template for Cloud Service Specification

To represent and manage cloud resources, usually a meta-data or model-driven approach is pursued. Meta-data constructs, called templates, are used for providing an understanding of the features used to deliver reliable, and scalable cloud deployments, and achieving better interconnection between physical and digital infrastructures.

The Distributed Management Task Force (DMTF) uses templates that help manage cloud resources of various types and support the cloud service lifecycle by, for instance, describing the way in which a cloud offering is presented and consumed [34]. The service offering is abstracted from the specific type of cloud resources offered and service templates are used

(20)

to describe in a general form what a cloud provider can offer. The cloud service template is then customized to reflect the fact that a service offering needs to be created for consumption by one or more specific consumers by including such information as which machines, Internet Protocol address ranges, and storage requirements.

One of the most prominent initiatives in DMTF, the Open Virtualization Format (OVF) [12] describes a specification of software packaging and distribution to be run in VMs. OVF is a platform independent, efficient, extensible, and open packaging and distribution format for VMs. OVF is virtualization platform neutral, while also enabling platform-specific enhancements to be captured.

There are several extensions of OVF to address low-level interoperability problems. Galan et al. [14] consider configuration parameters (e.g., hostnames, IP and other application specific parameters) for software components included in the VMs as one of the capabilities that should be exposed by an IaaS provider. The 4CaaSt project has extended OVF in several ways. More details about these OVF enhancements can be found in Deliverable D4.1.3. Horizontal VM scalability by relying on non-infrastructure metrics is also briefly dealt with in this publication. In a continuation of this work the authors describe a system for a more complete application life-cycle management on top of an IaaS cloud [41]. However, all OVF-based approaches are very restrictive as they focus on specific points of the application lifecycle: definition and deployment time configuration. The fact that the application horizontally scales and load balances its VMs cannot be considered beyond the configuration step.

5.1.2 Topology and Orchestration Specification

The OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) [42] builds on OVF efforts and plans to enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown) – independent of the supplier creating the service, and any particular cloud provider or hosting technology.

5.1.3 Model-Driven Approaches for the deployment of

Cloud Services

Model-driven approaches are also employed for the purpose of automating the deployment of complex IaaS services on cloud infrastructure. For instance, [18] proposes a virtual appliance model, which treats virtual images as building blocks for IaaS composite solutions. Virtual appliances are composed into a virtual solution model and deployment time requirements are then determined in a cloud-independent manner using a parameterized deployment plan.

In a similar way, [19] describes a solution-based provisioning mechanism using composite appliances to automate the deployment of complex application services on a cloud infrastructure. Model-driven approaches have been employed for automating the deployment on top of IaaS clouds.

Goldsack et al. [43] propose a declarative configuration framework (SmartFrog) in which component descriptions were specified as ordered hash tables. The provided description is checked against a data model representing the life-cycle status of the component and inferences are made as to what changes are required to take the component from its current

(21)

status into the one that matches the hash table declaration. Configurations and descriptions may contain data that comes from different stages of the processing of a description. All the previous approaches concentrate mainly on the physical-level, i.e., predominantly IaaS cloud services. In addition, templates capture static information and cannot be combined easily with other templates to describe composite offerings.

5.2 PaaS Specification Languages

The Service-Oriented Cloud Computing Architecture (SOCCA) proposed in [67] allows developers to build applications within an integrated SOA framework. Cloud platform and infrastructure resources may be discovered by a Cloud Broker Layer and a Cloud Ontology Mapping Layer for deploying the application components. The multi-tenancy feature of cloud computing is also supported by SOCCA where multiple instances of platform resources can be provided to multiple tenants.

Windows Azure1_{is a Microsoft cloud platform that can be used to build, deploy, and host}

applications on Microsoft’s data center. Services in Windows Azure are configured by two XML files [68]:

• The service definition file describes the service model. It defines the roles included with the service and their endpoints, and declares configuration settings for each role. The default extension for the service definition file is .csdef.

• The service configuration file specifies the number of instances to deploy for each role and provides values for any configuration settings declared in the service definition file. The default extension for the service configuration file is .cscfg. The CompatibleOne2_platform

9 is a cloud service broker that offers a simple and unique

interface for discovering and deploying the needed cloud resources. Service requests are described in XML files named MANIFEST documents to capture the specific technical and business specifications. The MANIFEST document allows users to specify both the IaaS resources like the computing, network, or storage resources and the PaaS resources like a database or runtime container.

Cordys3 is a cloud platform that specializes in Business Process Management (BPM) solution. The Cordys platform aims to support the design, execution, monitoring and improvement of business processes. The business processes in Cordys are modeled using the Business Process Model and Notation (BPMN). Services in Cordys are integrated using the WS-* stack to support the business process design and execution. Amazon Elastic Beanstalk4 is a PaaS solution that allows users of the Amazon Web Services (AWS) to quickly deploy their applications and seamlessly manage the underlying AWS resource during runtime. The AWSs that can be managed by Amazon Elastic Beanstalk include the Amazon Elastic Cloud Compute (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon Simple Notification Service (Amazon SNS), Elastic Load Balancing, and Auto Scaling. Amazon Elastic Beanstalk is built using familiar software stack to ensure the

1

Microsoft Windows Azure: http://www.windowsazure.com

2

http://www.compatibleone.org/bin/view/Main/

(22)

portability of users’ applications. The API of Amazon Elastic Beanstalk is described using WSDL5_.

5.3 SaaS Specification Languages

The SaaS layer of the cloud stack is recognized as the intersection between the two research domains SOA and Cloud Computing. Hence, existing service specification languages in SOA, e.g. the WS-* stack, are fully suitable for being used to specify SaaSs. However, one of the biggest disadvantages of these languages is that they do not aim to support the automatic deployment and provisioning of a SaaS. In the following, we present some initiatives in providing specification languages that aim to support the automatic deployment and provisioning of a SaaS.

The Model Driven Engineering (MDE) research community has realized the benefit of combining MDE techniques with application development and suggested combining MDE with cloud computing [71]. As the article describes, there is no consensus on the models, languages, model transformations and software processes for the model-driven development of cloud-based applications. Following the MDE vision, the authors in [72] propose a meta-model that allows cloud users to design SaaS applications independent of any platform and build inexpensive elastic applications. From their point of view, a SaaS application should avoid the vendor lock-in problem concerning the underlying platforms. This meta-model support the description of the capabilities, technical interfaces, and configuration data for the virtualized infrastructure resources of the cloud application service. Similarly, the work in [73] presents a different customer-centric cloud service model. This model concentrates on aspects such as the customer subscription, capability, billing, etc., yet does not cover other technical aspects of the cloud services including the technical interfaces of the cloud services, the elasticity, the required deployment environment, etc. Other existing models, e.g. in [74], also lack a formal structure and dentitions (reducing their usability and reusability) or are not explicit and assume tacit knowledge.

Based on the IaaS specification language proposed by Galan et al. in [69], Chapman et al. defines in [75] a manifest language called Application Description Language to serve as a contract between an application developer and an IaaS provider. In this contract, architectural constraints and invariants regarding the infrastructure resource provisioning for an application are specified and can be used for on-demand cloud infrastructure provisioning at run-time. The abstract syntax of the manifest language is modeled using the Essential Meta-Object Facility (EMOF), an OMG standard part of the Model Driven Architecture initiative6_{. Using the manifest language to specify the structure of an application, i.e., the}

application components and their required Virtual Execution Environments (VEE), the Reservoir architecture in [76] can automatically provision the VEE instances that can run simultaneously without conflict on a federated cloud infrastructure of multiple providers. KPI monitoring mechanisms and elasticity rules in the manifest act as a contract that guarantees the required Service Level Agreement (SLA) between the application developer and the Reservoir architecture.

5_{Amazon Elastic Beanstalk API Reference: http://docs.aws.amazon.com/elasticbeanstalk/latest/api/}

Welcome.html

6

(23)

A cloud-agnostic middleware is introduced in [77] that can sit on top of many PaaS/IaaS offerings and enable a platform-agnostic SaaS development. They provide a meta-model for describing SaaS applications and their needed cloud resources, and APIs and middleware services for the deployment. Sun et al. propose in [78] the use of ontology to specify and match the resource requirements of a SaaS application with the available resources of the cloud infrastructure. They provide also a resource allocation support based on the ontology mapping technique.

The Cafe application and component templates [79] are a relevant approach for cloud-based SaaS development. Cafe provides an ad-hoc composition technique for application components and cloud resources following the Service Component Architecture (SCA). However, this approach requires SaaS developers to possess intricate technical knowledge of the application architecture and the physical cloud deployment environment to select and compose the right application components and cloud resources.

The Topology and Orchestration Specification for Cloud Applications (TOSCA) [70] is an OASIS standardization initiative for describing the deployment topology of a composite application in the cloud environment. TOSCA defines generic templates for specifying nodes and node relationships in an application topology, where each node is defined explicitly with management operations. Furthermore, TOSCA introduces the concept of management plan, which orchestrates the management operations of the nodes using standards like WS-BPEL. Using TOSCA as the underlying specification of the deployment topology, the concept of a portable management of cloud service has been introduced in [80].

5.4 Cloud and Service Composition Techniques

Service compositions [81] are used for performing more complex, structured, or higher-level tasks by putting together individual, specialized component services. They are often designed around the concept of business processes, and integrate services that belong to different back-end information systems and organizational domains. Service compositions come in two main flavours: orchestrations, which describe the composition in terms of a centrally controlled process or a procedure, and choreographies, which give a decentralized view of multi-participant interactions by means of protocols and constraints [82]. One of the key features of service compositions is that they can be themselves exposed as services. This allows the development of multi-layered, complex and flexible service systems.

A widely used industrial standard for orchestration-based service compositions is WS-BPEL (Business Process Execution Language), developed by OASIS, currently in its 2.0 version.7

BPEL processes (i.e., compositions) are described using an XML-based language that describes service invocations and algorithmic constructs, such as the state updates, loops, branches, and parallel flows. A BPEL process definition is accompanied with its WSDL file which defines the process as a service, but also the component services in the composition – known as partners in BPEL. BPEL processes are executed by an orchestration engine, such as the Apache ODE8_{, Orchestra}9_{, or Oracle BPEL Process Manager.}10_{Apart from BPEL,}

7_{http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html} 8_{http://ode.apache.org/}

(24)

several other executable service composition languages have been proposed, including BPMN (Business Process Modeling Notation),11_Yawl,12_Orc,13_{and DecSerFlow [83].}

Cloud technologies not only introduce a powerful medium for delivery of services, but pose new challenges to the service composition techniques [84]. One such challenge comes from the intrinsically complex internal architecture of a cloud system, where ensuring the Quality of Service (QoS) characteristics of a composition – experienced by the end-user – has to take into account the cost of the internal cloud operations. The approaches taken here include introduction of a specialized QoS-aware workflow execution cloud engine SaaS [85], the Aneka framework [86], or a proposal for network-aware composition execution / scheduling in the cloud [87].

Hybrid clouds are another challenge posed to service compositions by cloud technologies. In hybrid clouds, each composition has both a horizontal (across clouds) and a vertical (inside a cloud) dimension. While the former typically relates to distinct application domains that provide heterogeneous services, the latter denotes the ability of a single cloud to provide a scalable pool of homogeneous service nodes that boost its performance. Simulation, synthesis, and analysis of the vertical and horizontal cloud service compositions has been proposed using agent-based methodology and concurrency modelling based on Petri nets [88]. A classification of horizontal/vertical variability required in flexible cloud applications, architectural principles to enable configurability of the corresponding processes and service compositions, and a user-centric design framework were proposed in [89].

Leveraging cloud technologies to support classical service compositions, using standard orchestration languages such as BPEL, has been an object of study [90] that has compared the alternative BPEL execution engines on the IaaS, PaaS and SaaS levels, and discussed different requirements of each of these approaches from the point of view of provision complexity, consumer flexibility, database requirements, and a wider business process management (BPM) setting. On the other hand, a cloud-based scheme for on-demand provision of the component services (i.e., the composition resources) for BPEL processes was proposed using the public Amazon EC2 system and load balancing [91]. Another similar load-balancing scheme for BPEL has been proposed with a specific goal of ensuring fault tolerance in mind [92].

Besides the conventional, general-purpose service compositions, a significant interest was attracted by the study of optimizing the delivery of specialized, scientific workflows, which usually do not fully support an entire service stack with a full spectrum of orchestration constructs and messaging patterns, but instead very much depend on the optimal use of the cloud-supplied processing power and storage. The application of the map-reduce

10_{http://www.oracle.com/technetwork/middleware/bpel/overview/index.html} 11_{http://www.omg.org/spec/BPMN/2.0/}

12_{http://www.yawlfoundation.org/} 13_{http://orc.csres.utexas.edu/}

(25)

computation model for scientific workflows on the IaaS level and using distributed data stores, with its performance evaluation, was analyzed in [93]. Leveraging the intrinsic parallelism of the cloud was studied in the context of automatically distributed scientific service compositions [94].

(26)

6 Shortcomings and objectives

This section summarizes the shortcomings we identified while evaluating and comparing the different approaches in the state-of-the-art (for more details, please refer to Deliverables D2.1.1 and D2.2.2). It is the base for developing the requirements for WP2 proposal, the blueprint concept.

6.1 Shortcomings of Existing Approaches

As a summary, most of the research activities contributing to the state-of-the-art described in the previous section concentrate on platform/infrastructure resource provisioning and attempt to combine and optimize interrelated cloud platform (PaaS) and infrastructure (IaaS) resources. However, we observe little research work on the cloud application (SaaS) level that supports the development of SBAs by utilizing distributed SaaS components that are deployed on a federation of elastic and heterogeneous PaaS and IaaS resources. Unfortunately, current approaches for cloud-based SBA development cannot meet this expectation and usually leads to a vendor lock-in approach, where the constituting monolithic SaaS components are predominantly tethered to proprietary platforms and infrastructure of a cloud vendor; i.e., existing SaaSs from providers like SalesForce14_{, Google}15 _or

SaaSDirectory16 are often not customizable, extendable or interoperable. This approach fails to follow the true spirit of SOA that promotes the reuse of loosely coupled services, thus makes it difficult for SBA developers to migrate the SaaS components from one cloud vendor to another or back to an in-house IT environment.

Moreover, existing approaches hardly address end-to-end non-functional requirements, and are not closed-feedback loop, thus partitioning service systems that involve many providers thereby increasing mean time to resolution of errors. For these methodologies, scalability, optimal use of resources and continuous improvement of services are hardly considered. Further, they do not address the nature of the execution environment that automates the end-to-end services and their subsequent operation. None of the current methodologies considers the appealing characteristics of the “cloud” as a deployment environment. This is where our approach differs by addressing these challenges.

6.2 WP2 Objectives

With the above backdrop, the aim of the WP2 is to conduct cutting edge foundational research in the priority areas of:

• Formal theories for end-to-end service management, consistency and optimization, • Service request languages to enable architects declare desirable combinations of

service offerings,

• Predictive formal approaches for performing operational and performance end-to-end service analysis.

14_{SalesForce CRM: http://www.salesforce.com}

15_{Google App for Business: http://www.google.com/apps/intl/en/business/index.html}

(27)

The unified methodology will focus on evolutionary models to support the prediction of application behaviour and the management and continuous improvement of end-to-end Internet service eco-systems in close association with their implementation and resource consumption needs. The unified methodology will help map high-level application requirements on a demand basis to lower-level virtualized resources and infrastructure. This approach ensures that the integration of cloud service provider types – SaaS, PaaS and IaaS providers – is performed on the basis of (possibly changing) application requirements.

WP2 aims to bring together best-of-breed concepts, theories and techniques from software/services development and cloud computing to fulfil three major purposes:

- To break the monolithic cloud Software-as-a-Service, Platform-as-a-Service and Infrastructure-as-a-Service stack architecture and the “difficult-to-customize one-size-fits-all” cloud models enabling software developers to pick and choose functionality and services from multiple service, platform and infrastructure providers and configure it dynamically and in optimal fashion to address their application needs. This premise promotes autonomous services (at the application, platform and infrastructure levels) that adhere to the same principles of loose coupling and separation of concerns to minimize dependencies, allowing any service at any layer to be appropriately swapped in or out without having to stop and modify other components elsewhere.

- To allow vertical convergence between service and resource virtualization, meaning there should not be a single composition, specific resource/infrastructure or implementation, for the service. Rather, each of these items should be virtualized so as to minimize the impact of failure, improve overall performance, and allow for variability and flexibility when things change.

- To empower software developers through the provision of insights into service inter-relationships, their individual and cumulative (end-to-end) performance-oriented metrics, their patterns of interaction with potentially underlying resources and infrastructure during the design, testing, development and implementation phases of a service-based application.

With these points in mind enormous opportunities for foundational research exist. These require real innovation in areas such as service-engineering methodologies, service architectures, end-to-end service management and evolution, as well as service resource and capacity management, to support the creation of end-to-end service formations that are generated on-demand to span organizational (service provider) boundaries. Such research threads are the main concern of WP2.

(28)

7 WP2 Scientific Results: The Cloud

Blueprinting Approach

Cloud Blueprinting is a novel approach that provides the ability to rapidly and easily deploy pre-built, pre-configured, pre-optimized application payloads on virtual resource pools on the cloud and helps configure a federated cloud environment to meet a broad range of application requirements and policies, (e.g., consistency, security or privacy requirements) by clearly separating service processing concerns.

The term Cloud Blueprinting refers to a detailed deployment plan and a high-order packaged integration solution that provides a description of everything necessary to integrate, and manage the interaction between Cloud services provided by different providers [16,18]. The rationale of Cloud Blueprinting is about abstracting from the technical details of how the user interacts with cloud services and instead providing a way to treat these interactions as part of the abstract description of an entire cloud-based solution.

Cloud Blueprinting is a coordinated effort to modularize and commoditize elements of the Cloud stack and make them available over the Internet for wider use. It provides both a reference architecture and an approach for integrating and managing cloud federations. This approach helps consumers and developers, alike to request, query, and aggregate cloud services into value-added offerings and manage integration flows connecting any combination of cloud-based services within individual, or across multiple, clouds. It consequently offers the foundation for delivering flexible and readily-integrated cloud services sourcing as utilities over the Internet.

7.1 Blueprint Reference Architecture

Cloud blueprinting offers an innovative reference architecture, an enhanced cloud delivery model, which breaks down the inflexibility of the cloud stack and transforms it into modular and easily combinable components that offer integration-as-a-service functionality. Cloud blueprinting targets cloud developers by striving to make their role simpler, more intuitive and more cost-productive. To this end, it empowers an ‘end-user centric view’ which considers cloud consumer application needs and provides readily available standard but highly configurable building blocks (blueprints) that can be used to “assemble” the cloud application. This drastically increases the speed at which tailor-made applications can be developed.

Figure 3 shows that the activation of a new application or function is consumer triggered and involves the use of a request language in which the consumer or developer formulates requests without being burdened by the technical complexities of the underlying cloud infrastructure. Cloud resource allocation becomes just a matter of fitting together predefined building blocks (blueprint images aka service plug-ins), which are described using a simple definition language. Blueprint solutions are then configured for deployment by being transformed to API calls and then executed on the physical cloud. As a result, organizations can implement and configure federated cloud computing incrementally at the pace best suited to their needs and on-premise resources. The unimportant details are handled below the surface.

(29)

Figure 3. Overview of the Cloud Blueprinting Approach

Cloud Blueprinting supports ‘seed and grow’ activities that lead to faster assembly of cloud services that span all the delivery tiers (IaaS, PaaS and SaaS) in the cloud stack. The traditional role of the system developer will become simpler, more intuitive and more cost-productive. Cloud system development will become a matter of assembling disparate preconfigured, customizable building blocks and stack them together to make robust, flexible, scalable, and secure cloud environments. This enables all types of organizations to meet the integration challenges of cloud computing and benefit from new innovative cloud-centric business models.

7.2 Blueprint Service Delivery and Integration Model

When we examine the three cloud delivery models (IaaS/PaaS/SaaS), we observe a recurrent theme. The models are constrained by the capabilities at the respective delivery tier and do not allow for easy extensibility or aggregation options. This is due to the monolithic structure of the cloud stack that does not support modularity (see Section 2). The current monolithic cloud-stack solutions that permeate the cloud enforce one-way vertical deployment ‘channels’. From the consumer’s perspective, who leases a SaaS application (e.g. order management or tax and tariff administration) it means that the consumer receives a monolithic SaaS/PaaS/IaaS stack. This implies that if the consumer wants to develop a new cross-SaaS (or business process as a service) application that combines the application with external billing and collection management services from another cloud stack, the consumer cannot achieve this without the intervention of the original provider. The same problem rises when the consumer wants to run the SaaS application on a different type of PaaS middleware.

The only way to address the limitations highlighted above is by breaking the cloud monolith into its constituent (modular) parts and letting a consumer (or developer) who leases an SaaS application freely choose and intermix the lowest-cost and best quality PaaS/IaaS-layer offerings (which different providers might supply) to service it [16], [18]. This approach, which leads to the syndicated, multichannel cloud delivery model illustrated in Figure 4, promotes autonomous services (at all levels of the cloud stack). It allows consumers or developers to combine or swap any service at any layer of the cloud stack with a service at the same layer without having to stop and modify components elsewhere in the stack.

(30)

Figure 4. Syndicated mixed-channel cloud delivery model

The syndicated cloud delivery model converts all cloud-stack layer components into general-purpose cloud commodities to attract partners and build a true federated cloud ecosystem. As a result, it naturally supports cloud developers (and providers) in the creation of end-to-end business processes as part of a business process as a service, or BPaaS, solution. BPaaS syndicates internal and other external services (possibly provided by diverse SaaS providers) and clouds that run in the best possible combination of PaaS and IaaS resources. BPaaS requires effective integration and management of cloud resources.

As Figure 4 illustrates, the syndicated cloud delivery model promotes horizontal and vertical (upstream or downstream) integration by supporting mixed-channel combinations of cloud services along the horizontal and vertical cloud-stack axes. The syndicated, multi-channel cloud delivery model in Cloud-Sourcing is implemented by means of cloud blueprints as will be discussed in the following section.

The syndicated cloud delivery model lowers the cost of ownership, reduces the risk of vendor lock-in, and ensures greater architectural enforcement and applied automation. Solutions based on the enhanced cloud delivery model described above are integrated and provide a high level of visibility, finer-grained control, and automation.

The cloud integration and management reference architecture promotes standardization and best practices by facilitating a shift from organic growth in business to prescriptive deployment of cloud applications with greater consistency among implementations, ease and reduced implementation effort. Central to this effort is the Cloud Blueprinting approach [16], which realizes the syndicated cloud delivery model illustrated in Figure 5.

Cloud Blueprinting empowers cloud developers to orchestrate and configure cloud applications by combining self-describing modular, reusable virtual cloud components (abstracting service application fragments, documents, or platform/infrastructure resources)

(31)

at any layer of the cloud stack. The primary objective of this approach is to break the cloud stack monolith by creating a highly fluid, configurable cloud-computing environment that allows federating SaaS/Paas and IaaS cloud services on demand. Cloud Blueprinting declaratively maps pre-built, pre-configured points for abstract cloud service specifications to available cloud resources, and composes them into complete solution models (using simple aggregation and cross-configuratio