Issue in Automatic Combination of Cloud Services

Dinh Khoa Nguyen, Francesco Lelli, Mike P. Papazoglou, Willem-Jan van den Heuvel European Research Institute in Service Science (ERISS)

Tilburg University Tilburg, The Netherlands

{d.k.nguyen, f.lelli, M.P.Papazoglou, W.J.A.M.vdnHeuvel}@tilburguniversity.edu

Abstract— Current cloud service description languages envision the ability to automatically combine cloud service offerings across multiple abstraction layers, i.e. software, platform, and infrastructure service offerings, to achieve a common shared business goal. However, only little effort has been spent in this direction. This paper formalizes the issue of automatic combination of cloud services showing its computationally intensive nature. In order to overcome this issue we propose a Resource Description Framework (RDF)-based prototype implementation that leverages a batch process for automatically constructing possible combinations of cloud services. Using this approach we are able to analyze possible combinations of cloud services that may fit particular customer needs in a timely fashion.

Keywords-component; Cloud, Cloud Services, Service Composition, RDF for Cloud

I. INTRODUCTION Cloud computing is an emerging paradigm for

developing and deploying scalable applications using the virtualized computing, storage and network resources offered as cloud services from diverse providers in the Web. Cloud services are elastic, available on-demand, and usually charged following the pay-as-you-go billing scheme that reduces the need for capital expenditure on equipment. This means that with cloud computing applications can be easily designed and tailored to specific business's individual requirements. Cloud services are typically organized in the following three abstraction layers:

• Software as a Service (SaaS)1: is the delivery of on-demand software that is deployed on the Internet and available to the end-user upon requests.

• Platform as a Service (PaaS)2 is the delivery of an on-demand development platform as a service that has been preconfigured on a solution stack.

• Infrastructure as a Service (IaaS)3 is the delivery of virtual hardware (server, storage and network), and associated software (operating systems virtualization technology, file system), as a service.

1 Salesforce.com, NetSuite, Google’s Gmail

2 Salesforce.com’s Force.com, Google’s App Engine, and Microsoft’s Azure

3 Amazon’s Elastic Compute Cloud (EC2) is a major example of IaaS. Rackspace’s Mosso, GoGrid’s ServePath,

flexiascale are other IaaS offerings

Unfortunately, when examining the current cloud solutions on all abstraction layers, we detect that they are fraught with the following problems:

• They introduce a monolithic SaaS/PaaS/IaaS stack architecture where a one-size-fits-all mentality prevails. Hence, they do not allow developers to mix and match functionalities and services from multiple application, platform and infrastructure providers and configure them dynamically to address application’s needs.

• They introduce rigid service orchestration practices tied to a specific resource/infrastructure configuration for the cloud services on the SaaS level.

The shortcomings and rigidity of the current approaches for cloud services highlighted above discourage the development of flexible service-based cloud applications (SBCAs). It is suggested that the (re-)configuration and customization of SBCAs on demand are necessary to reflect evolving inter-organizational collaborations. In other words there is clearly a need to mash up cloud services from a variety of cloud providers to (re-)engineer SBCAs. This type of integration allows the tailoring of SBCAs to specific business needs using a mixture of SaaS, PaaS and IaaS delivery models.

Recent approaches [1][2] have proposed to describe a cloud service using a common shared set of information that captures requirements and offerings of a component. Their adoptions would open the market and allow differentiation of offerings based on different service level agreements. However, not much effort has been spent on leveraging these descriptions in order to find possible (and optimal) combinations of cloud services. In this paper we try to formalize this issue as a syndication problem where a group or a combination of cloud services joins their efforts for undertaking some specific duty or carrying out a specific business transaction. As we will see in Section III the solution to this problem is computationally intensive and a generic solution may work only for small service ecosystems or private clouds of Small and Medium Enterprises (SMEs). We propose an RDF-based prototype4 that takes advantage of a batch process for discovering and building possible new combinations of cloud services. Configuration requests coming from an SBCA architect can then be served in a reasonably short amount of time.

The rest of the paper is organized as follows: Section II outlines the cloud service composition issue. Section III

4 http://www.w3.org/RDF/

2012 10th IEEE International Symposium on Parallel and Distributed Processing with Applications

978-0-7695-4701-5/12 $26.00 © 2012 IEEE

DOI 10.1109/ISPA.2012.71

487

formalizes this issue as a tree navigation algorithm. In Section IV we present our prototype to implement the algorithm where cloud services are described using a common RDF schema model. Finally in Section V we draw our conclusions.

II. CLOUD SERVICE COMPOSITION PROBLEM As pointed out in the introduction in Section I, the goal

of this paper is to leverage existing description techniques for cloud services to compose them for a SBCA. The concept “Blueprint” has been defined in [1] as a uniform abstract description of a cloud service offering that facilitates the SBCA developers with the selection, customization and composition of cross-layered cloud services across various providers. A blueprint is capable to expose through a set of blueprint properties its offerings, resource requirements, policy profiles, etc., as well as the interdependencies with other blueprints. The advantage of following the blueprint approach is that blueprints can be flexibly (re-)assembled in different configurations to form a complete SBCA. This facilitates the composition of offerings across blueprints to express end-to-end offerings from various providers. The blueprint approach distinguishes two different types of composition of cloud service offerings:

• Vertical composition: the installation and configuration of a SaaS offering on a given PaaS or IaaS offering, or the installation and configuration of a PaaS offering on another PaaS or IaaS offering.

• Horizontal composition or functional composition on the SaaS level: the composition of two or more SaaS offerings to form another composite SaaS offering or to build a complete SBCA.

For the purpose of this paper we do not distinguish between these types of composition, as we would like to focus on the algorithmic aspect of the process of searching for offerings and combining them across multiple blueprints. From the business point of view, SBCA architects would like to search a distributed marketplace and retrieve all the possible compositions of cloud services that may collectively solve their application’s requirements. In addition these compositions must be filtered over policy constrains that are applied to the entire set of constituting cloud services.

Figure 1. Example of Blueprint

Figure 1 introduces an example of describing a cloud service using blueprint. AutoInc-Blueprint is a blueprint that offers the VehicleMgt-SaaS to manage vehicle fleets that can responds to every user request within 5 seconds. However, the VehicleMgt-SaaS offering is still incomplete, as its implementation artefacts (the application core module written in Java and the database setup and configuration script) still require a JEE application server and a database for the deployment. The task here is to find suitable PaaS offerings from the marketplace repository to fulfill these requirements, and then “vertically” compose them with the VehicleMgt-SaaS offering. There could be many offerings in the marketplace that can satisfy these requirements. However, the combination of the two selected offerings for JEE application server and database needs to fulfill the policy constraint stating that the maximum response time (maxRT) of the VehicleMgt-SaaS offering is 5s.

In the next section, we will formalize the process of searching and composing cloud services described by blueprints as a computationally intensive task, based on the running example presented in this section.

III. PROBLEM FORMALIZATION Offerings and Requirements are the two core concepts in

a blueprint. Offerings that have already been submitted in a blueprint to a marketplace repository and thus can be purchased and reused by SBCA developers are called “Source Offerings”. In contrast, an offering under development is called a “Target Offering”.

Figure 2. Resolving a Target Offering

An offering is incomplete if there are requirements on which it relies. For instance in Figure 2, VehicleMgt-SaaS is an incomplete target offering that relies on the two requirements Req01 (JEE App Server) and Req02 (Database). To fulfill these requirements, one has to retrieve source offerings of other blueprints from the marketplace repository.

488

This task is called “to resolve the VehicleMgt-SaaS offering”. Furthermore, each requirement Req01 or Req02 may be fulfilled by a number of source offerings. Hence, there might be many combinations of source offerings as the candidate resolution results for the target offering VehicelMgt-SaaS. A candidate resolution result is selected only if it does not violate the global policy constraint prescribed by the target offering, i.e. the maxRT = 5s.

In Figure 2, a sample resolution result for the target offering VehicleMgt-SaaS is presented that contains the two source offerings Jboss App Server and PostgreQL, with the assumption that they satisfy the stated policy constraint. Note that the retrieved source offerings can be target offerings themselves and not yet be resolved, i.e., they may contain unfulfilled requirements. In this case, the resolution process may be iterative so further source offerings can be retrieved in order to fulfill the new requirements. For instance in Figure 2, the requirement Req02 can be fulfilled by the incomplete source offering PostgreQL that in turn needs to be resolved by the source offering SUSE Virtual Machine to fulfill the requirement Req03.

In general, resolving a target offering can be formalized as an iterative tree navigation process of retrieving source offerings, starting from the target offering as the root of the tree data structure and its requirements as the leaves of the tree. Figure 3 illustrates a sample iterative resolution process. In each iteration, the resolution process tries to match the requirements with the source offerings. There might be many

alternative matched source offerings for each requirement. However, a combination of source offerings is selected only if it can satisfy the global policy constraint of the target offering, e.g. (Off-A1, Off-B1) and (Off-A2, Off-B2) in Figure 3. Solving global end-to-end policy constraints has been known as a complicated task that requires much external knowledge, e.g. we may rely on the work in [3] to solve end-to-end quality of service constraints for service compositions, or the work in [4] to leverage a model-driven rule-based composition approach on the SaaS level. Since the source offerings may still be unresolved, the resolution process continues to the next iteration to fulfill the newly appeared requirements. The iterative resolution process stops when all the requirements have been fulfilled. The result of this process is a number of Abstract Resolved Blueprints (ARB), each representing a resolution result for the target offering. An ARB contains the target offering and all the selected source offerings. A sample ARB is also presented in the Figure 3, which comprises of the target offering and combination of the source offerings Off-B2, Off-C2 and Off-D2 as a resolution result.

In the next section, we present our approach to implement the resolution process.

IV. RDF-BASED IMPLEMENTATION The work in [1] describes the blueprint schema, how it

captures the structure of a blueprint and an example of how it can be implemented, e.g., using XML schema. However, an

Figure 3. Iterative Resolution Process for a Target Offering

489

informal (i.e., XML) representation of the blueprint does not provide an explicit specification of the intended meaning of and relationships between the concepts involved in engineering SBCA. Therefore, to capture an unambiguous, shared understanding of the blueprints, we have chosen to formally represent the blueprint schema using the Resource Description Framework (RDF) schema 5 . The benefits of choosing a RDF-based approach to the representation and structure of the blueprints are that “although XML DTDs and XML Schemas are sufficient for exchanging data between parties who have agreed to the definitions beforehand, their lack of semantics prevents machines from reliably performing this task with new XML vocabularies” [5]. Using RDF to formally describe blueprints provides a powerful and flexible way to manipulate, aggregate and normalize data and metadata about cloud delivery models. This section presents the simplified version of our RDF schema model as the formal representation of the blueprint schema. It captures the key aspects of the description of a cloud service to support the implementation of the resolution process introduced in the previous section III.

Figure 4 illustrates our RDF schema model, and shows that the most significant concept is the Blueprint. A blueprint contains at least a cloud service offering (Offering), i.e. a SBCA, SaaS, PaaS, or IaaS offering. An offering might require specific cloud resources for its deployment. Hence, the Blueprint may contain also the resource requirements (Requirement). The requirements may be delivered using any of the cloud delivery models, i.e., they may be SaaS, PaaS or IaaS resources. A requirement might be fulfilled by other offerings through the object property “fulfills”, i.e.

5 http://www.w3.org/TR/rdf-schema

application developers can reuse the source offerings of other blueprints to fulfill a particular requirement.

Our RDF schema model allows specifying the name of an offering or requirement through the data property “hasName” (in string). This follows a string-based naming approach to allow simple search and matching between offerings and requirements. Successful examples this approach include the unix packaging model (like the Debian package management). Clearly this approach has its own limitations, i.e. the matching does not take into consideration the functional description and signature of offerings and requirements. Existing approaches for matching functional descriptions of services like [6] and matching service signatures like [7] might be included in our future work. Furthermore, offerings and requirements may also be matched based on their policy properties like the quality of service (QoS) properties. We decided to simplify this issue by adding to both offering and requirement a data property “has maxRT” (in integer) for indicating their allowed/required maximum response time (maxRT).

An offering off is considered to “fulfill” a requirement req if the name of off matches the name of req and the maxRT of off can satisfy the required maxRT of req. The RDF schema can be extended to capture more policy properties, e.g. by adding more policy properties to the existing RDF schema. In addition, an URI-typed property may also be added to the schema to reference an external policy description for an offering or requirement using an external language, e.g. WS-Policy6 or SLAng7.

6 WS-Policy: http://www.w3.org/TR/ws-policy/

7 The SLAng SLA Language: http://uclslang.sourceforge.net/

Figure 4. The RDF Blueprint Schema Model

490

The concept offering in our RDF schema model can be used to describe both target and source offerings. A target offering with no requirement is a complete one, i.e. it is already deployed and ready to be consumed. In opposite, a target offering with requirements could be resolved or unresolved. In the former case, it is “resolved” if there exists at least a set of source offerings that can collectively fulfill its requirements. A Resolution Bundle represents such a set of source offerings. Since there could be different alternative source offerings to fulfill a particular requirement, there might be different resolution bundles as the alternative results of resolving a target offering. A target offering remains “unresolved” if there is no resolution bundle for it. A blueprint is “resolved” only if all its contained offerings are “resolved”. This status of a blueprint is captured using the Boolean data property “isResolved”.

In summary, our proposed RDF blueprint schema model captures all the necessary knowledge for representing a cloud service for service consumers, service providers and application developers. RDF-based Blueprint Instance Models (BIM) containing blueprints can be instantiated from the RDF schema to unambiguously describe cloud services on any abstraction layer, e.g., SBCA, SaaS, PaaS or IaaS.

Figure 5 presents a sample BIM containing six different blueprints that conform to the RDF schema model presented in Figure 4. In particular, there are four resolved blueprints, the JBoss-Blueprint offers a Jboss JEE application server with maxRT = 2s, Jonas-Blueprint offers a Jonas JEE Server with maxRT = 2s, SUSEEnterprise-Blueprint offers SUSE Linux virtual machines, and RedhatEnterprise-Blueprint offers Linux Redhat virtual machines, and two “unresolved” blueprints, AutoInc-Blueprint and DB-Blueprint. The

AutoInc-Blueprint offers a SaaS called VehicleMgt-SaaS for managing vehicle fleets with the maxRT = 5s. However, this offering requires a JEE application server and a database to run the SaaS. The DB-Blueprint offers two alternative database PaaS solutions, one with the MongoDB with maxRT = 3s, and one with the PostgreQL with maxRT = 2s. Whilst the MongoDB offering is complete and ready to be consumed, the PostgreQL offering still unresolved and requires a Linux machine as the underlying infrastructure.

The RDF schema described in this section has been modeled in Protege8. The sample instantiated BIM has also been created by Protege as a RDF document to capture the sample blueprints for demonstration purpose. We decided to use the Jena framework 9 for implementing the prototype. The reason for choosing the Jena framework for our prototype implementation is because it supports SPARQL10 that can be used as the query language to retrieve/update information from/to the sample BIM, and a set of Java APIs that can be used for manipulating information in the BIM.

Our prototype contains the two following features:

8 http://protege.stanford.edu/

9 http://jena.sourceforge.net/.” 10 http://www.w3.org/TR/rdf-sparql-query/

Figure 5. Example of a Blueprint Instance Model (BIM) containing blueprints

491

• Feature 1 (Continuous Resolution Process): When a new target blueprint is inserted into our sample BIM, a batch process continuously scans and detects all the new and unresolved offerings, and then resolves them following the tree navigation algorithm in Section III. Matching between a requirement and a source offering follows a simple keyword-based matching approach. Since the maxRT is the only policy constraint specified for each offering, we assume that a combination of source offerings will be selected if the aggregation of the maxRT values of the source offerings is less than the maxRT value of the target offering.

Resolving a target offering will create different alternative combinations of source offerings in the BIM. Each combination is captured as a new instance of the RDF concept “Resolution Bundle”. For instance in Figure 6, Resolution-001 and Resolution-002 are the two alternative resolution bundles for the target offering VehicleMgt-SaaS. Note that each source offering may be target offering itself and hence it may be resolved by other resolution bundles, e.g. the PostgreQL-PaaS source offering in Figure 6 is resolved by the ResolutionBundle-003 and ResolutionBundle-004 resolution bundles. Figure 6 illustrates the three alternative Abstract Resolved Blueprints (ARBs) in the BIM as the final result of resolving the target offering VehicleMgt-SaaS,

• Feature 2 (Querying for Offerings): If a customer submits a SPARQL query to search for a particular offering, the BIM immediately returns all the matched candidate offerings, each with the list of existing resolution bundles in a relatively short time. The code fragment below reports the SPARQL query that is used for querying an offering that offers a “Vehicle Management Software” with maxRT <= 5s: PREFIX bp: <http://www.eriss.org/BlueprintRDFS.owl#> SELECT * { ?tBlueprint bp:has_Offering ?tOff . ?tOff bp:has_Name ?OffName . ?tOff bp:has_max_ResposeTime ?maxRT . FILTER regex(?OffName, “Vehicle Management Software, "i") . FILTER (?maxRT <= 5) OPTIONAL {?tOff bp:is_resolved_by ?resResult .}}

Executing this query in our sample BIM will return the

AutoInc-Blueprint with the VehicleMgt-SaaS offering, and the two alternative resolution bundles Resolution-001 and Resolution-002 that represent the current resolution results stored in the BIM. By continue submitting further SPARQL queries to the BIM, users can retrieve the three complete ARBs of the VehicleMgt-SaaS.

Figure 6. The three Abstract Resolved Blueprints (ARBs) of the AutoInc-Blueprint

492

V. CONCLUSION Cloud resources offered as services can be described

using a common schema model and hence can be composed in order to achieve a common business goal. We present in this paper the issue of composing cross-layered cloud services to build a Service-based Cloud Application (SBCA), and formalize it as a tree navigation algorithm involving external approaches for matching cloud service descriptions. Given the fact that there could be a huge number of cloud service offerings in a real marketplace, this algorithm may grow exponentially and become a computationally intensive task. For our prototype implementation, RDF is used to create a sample model containing sample cloud service offerings, a batch process is implemented to continuously scan the model and discover possible compositions of cloud services, and SPARQL is used to retrieve cloud services and their possible compositions in a timely fashion. In the future, we intend to continue investigating the issue of cross-layered cloud service composition in order to discover and quantify the benefits and the limits of this approach by providing experimental results.

ACKNOWLEDGMENT The research leading to this result has received funding

from the Dutch Jacquard program on Software Engineering

Research via contract 638.001.206 SAPIENSA; and the European Union’s 685 Seventh Framework Programme FP7/2007-2013 (4CaaSt) under grant agreement no 258862.

REFERENCES 1. D.K. Nguyen, F. Lelli, Y. Taher, M. Parkin, M.P. Papazoglou, W.J.

van den Heuvel, “Blueprint template support for cloud-based service engineering”, in Proceedings of the 4th European ServiceWave’11, 26th – 28th October 2011, Poznan, Poland, Springer LNCS 6994.

2. OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA), http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca (last acessed on 18/04/2012)

3. F. Rosenberg, P. Celikovic, A.Michlmayr, P. Leitner, and S. Dustdar. 2009, “An end-to-end approach for QoS-aware service composition”, in Proceedings of the 13th IEEE EDOC'09. IEEE Press, USA, 128-137.

4. B. Orriëns , J. Yang , M. P. Papazoglou, “Model driven servicce composition”, in Proceedings of ICSOC 200, LNCS 2910, Springer.

5. N. Balani, “The Future of the Web is Semantic”, IBM DeveloperWorks, October 2005. [Online]. Available: http://www.ibm.com/developerworks/web/library/wa-semweb/ (last accessed on 18/04/2012)

6. P. Oaks, D. Edmond, and A. ter Hofstede, “Capabilities: Describing what services can do,” in Proceedings of ICSOC 2003, pp 1 - 16, 2003.

7. V. Andrikopoulos, S. Benbernou, M.P. Papazoglou,”Managing the Evolution of Service Specifications”, in Proceedings of CAiSE 2008: 359-374

493