Identifying Adaptation Needs to Avoid the Vendor Lock-in Effect in the Deployment of Cloud SBAs Javier Miranda Juan Manuel Murillo
Department of Information Technology and Telematic Systems Engineering University of Extremadura, Spain
Joaquín Guillén
Carlos Canal
Gloin Calle de las Ocas, 2 Cáceres, Spain
Department of Computer Science University of Málaga, Spain
[email protected]
[email protected]
{jmircar, juanmamu}@unex.es ABSTRACT
Cloud computing has emerged as a new paradigm where IT resources are offered by cloud providers in a flexible and elastic way. However, the use and development of cloud services has not been standardized, thereby deriving in migratability and interoperability difficulties. Different standardization initiatives exist seeking to normalize this situation, however none has predominated and a generalized consensus has not been reached. Consequently, several alternatives have been proposed based on the use of intermediate layers or middlewares seeking to isolate developers from the variability of specific cloud vendor services. These approaches provide a valid solution at the risk of shifting the lock-in effect from vendors to middlewares. In this paper, we explore an alternative solution based on the use of software adaptation (SA) techniques. Different guidelines are presented as the basis of an approach that will favor cloud application interoperability and migratability thereby avoiding vendor lock-in.
General Terms
Design
Categories and Subject Descriptors
D.2.2 [Software Engineering]: Design Tools and Techniques; D.2.12 [Software Engineering]: Interoperability;
Keywords
Cloud computing, component, service, composition, adaptation, interoperability, migratability
1. INTRODUCTION
The enterprise software industry has evolved over the years to an extent where it now requires the design and implementation of large scale, complex and distributed systems. Many engineering paradigms have arisen to deal with this challenge, however two may be considered as the most outstanding: component-based software engineering (CBSE) and service-oriented software Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WAS4FI-Mashups '12, September 19 2012, Bertinoro, Italy Copyright 2012 ACM 978-1-4503-1566-1/12/09…$15.00.
engineering (SOSE). Each of these paradigms provide different development approaches, nevertheless they are both aimed towards building software with loosely-coupled compositional elements, components and services [1]. In the aforementioned context, Cloud Computing has emerged as a novel approach for software deployment as it allows its users to manage their resources differently, whilst they are provided with tools that can help them achieve a greater reliability, scalability and control for their software. Additionally, companies looking to optimize their investments in IT can exploit new business models associated to cloud computing in either of its different forms: software, platform or infrastructure as a service (SaaS, PaaS or IaaS, respectively). Components, services and cloud computing are garnering a great deal of attention both at industrial and academic levels. These technologies favor the rapid development and deployment of large-scale distributed applications in a wide variety of areas (research, e-business, healthcare, military applications, etc.). Therefore, software engineering frameworks that combine services and cloud computing, impulse developers and service providers to diversify the solutions that may be inferred from the adoption of each paradigm [2]. However, the lack of standardization that exists throughout the existent cloud providers, regarding the development of service-oriented applications, is an inherent problem that must be dealt with. Most providers supply specific tools and APIs that differ significantly from those supplied by other providers. This hinders application migratability and interoperability between different cloud platforms, thereby leading to high software migration costs, as well as the ‘vendor lock-in’ effect [3][4]. Although different initiatives, as for example OVF 1, OCCI 2, OGF 3, or OASIS TOSCA 4, have been raised for regulating and standardizing cloud computing environments, so far they have mostly led to discussion and debates. Consensus on how to confront the standardization issue is far from being reached. Therefore, considering that the vendor lock-in problem is slowing
1
Open Virtualization Format: http://dmtf.org/standards/ovf
2
Open Cloud Computing Interface: http://occi-wg.org/about/
3
OpenGridForum: http://www.ogf.org/
4
Topology and Orchestration Specification for Cloud Applications: http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=tosca
down the growth of cloud, different alternatives are being proposed. Amongst them, middleware-based approaches like mOSAIC 5, CloudBees 6, or those described in [5] and [6], are the most popular. In these approaches a middleware layer will behave as a broker between the application and the cloud infrastructures, providing an abstract interface for developers and isolating them from the specific requirements of each cloud vendor. Their use simplifies software development and deployment; however, middleware solutions are often quite complex and heavy. Considering that they have to be deployed in conjunction with the application, they will clearly penalize the deployment and performance of the software components attached to them. Further yet, the source code of middleware dependent components will be tightly coupled to the specification of the middleware, thereby moving the lock-in effect from vendors to middleware. A different approach entails the use of software adaptation techniques. Software adaptation is a discipline that promotes the use of adaptors —specific computational entities whose main goal is to guarantee that software components are able to interact in the right way. Software adaptation has been consolidated as a unique technique for detecting and solving mismatches in compositions of different services [7] and components [8], and generating the needed adaptors automatically [9]. We presented an approach based on adaptation in [10]. Here, the concept of using a software development framework for building cloud applications was introduced. The framework allows developers to separate all possible dependencies between the software being developed and the cloud from the source code through the generation of software adaptors. In [10], an overview of the adaptation approach was presented as the candidate technique to be used in the framework in order to keep the application source code as cloud-agnostic as possible, but the adaptation needs were not identified nor an analysis made of how adaptation would solve each problem. In this paper a further insight of the idea is given by analyzing the range of service adaptation scenarios that show up for cloud environments. In particular, we present and analyze the different types of adaptors that will be required and the main issues that should be addressed at each adaptation level (signature, behavior, semantic and service). Finally a series of guidelines are presented in order to address the identified issues. The most outstanding benefit of using adaptors in cloud environments is the ability to automatically generate loosely coupled applications with a lightweight impact on their deployment, and at the same time favor cloud interoperability, and avoid vendor lock-in. The remainder of the paper is organized as follows: Section 2 describes the motivation of our work. Section 3 presents the sources of mismatch and thus the needs for adaptation that we have detected in the cloud; in this section we identify the scenarios in which the use of adaptors may be considered. Section 4 describes the adaptation approach. Section 5 provides information about the most relevant work related with our proposal. Finally Section 6 gathers our conclusions and the limitations of the proposal, and future work that will have to be done. 5
mOSAIC Framework: http://www.mosaic-cloud.eu
6
http://www.cloudbees.com/
2. MOTIVATION
Cloud computing has become overwhelmingly popular. It provides a virtually unlimited amount of computational, infrastructure and data resources to its users at an accessible cost, as no technology has ever done before. Its popularity has also grown due to the great possibilities that it provides for outsourcing maintenance tasks, thereby allowing organizations to concentrate on their core competencies. Most experts concur in the classification of three delivery models for services in the cloud: SaaS, PaaS and IaaS. Some of these cloud services, supplied by one or more providers, can be combined for building Service-Based Applications (SBAs). Cloud services and SBAs are tightly related: the flexibility of cloud computing provides the fabric through which SBAs can be constructed and deployed [11]. However, two concerns about SBAs and cloud computing must be tackled. The first of them is the absence of standardization. Cloud providers supply cloud computing services which have different specifications from one provider to another. As a consequence of this, cloud users become dependent on a vendor’s services and are unable to switch to a different vendor without undertaking substantial costs. This situation is known as ‘vendor lock-in’. Current cloud services are provided as a one-size-fits-all solution, usually with preconfigured and monolithic IaaS/PaaS/SaaS combinations. The vendor lock-in becomes a lot more evident when certain SaaS applications are built to specific platforms or infrastructures (e.g. .Net applications can only be hosted by Windows/Azure based environments). Further than this, the SaaS solutions provided by cloud vendors often do not comply with the user’s requirements (e.g. some SaaS solutions do not fulfill the QoS levels or data format requirements demanded by users due to incompatibilities with the underlying infrastructure/platform). The second concern, which can be considered an immediate consequence of the first one, is the interoperability issues that must be confronted for communicating services deployed by different cloud providers. The inconsistency of cloud resource descriptions and the use of proprietary technologies by cloud vendors are the main barriers that developers need to overcome for designing and implementing SBA over different clouds. SBA development for cloud environments is harshly conditioned by these two concerns, thereby leading to the current scenario. In order to illustrate this, an example of a generic application, designed as the composition of several service-based components, has been taken. In this case the application was originally conceived to be deployed in a service-oriented in-house IT environment. Herein its components interact with one another via service invocations and one of them behaves as a service consumer for a SaaS application deployed in a cloud environment. In order to analyze the impact that the aforementioned limitations have on the development of SBAs cloud environments, let’s look into a scenario where one of the components (which will be called c-Component) is detached from the application and deployed in a cloud environment. The cloud delivery model of that environment could be IaaS or PaaS. Furthermore, we will consider that the cComponent will be the one consuming external SaaS services. Figure 1 illustrates this scenario. Migrating the c-Component to a cloud environment will require a large amount of work. The dotted lines in Figure 1 represent the different areas in which changes will have to be done in order to
continue supporting the communication between components as it was before. The following working areas have been identified:
SBA development for the cloud, and cloud-based SBA development methodologies.
1. Modifying the communication interfaces between the cComponent and the remaining components, in order to allow service provision and consumption from and to the cloud, in compliance with the cloud provider’s specifications.
In the first case, the paper summarizes the existent approaches and efforts being made to achieve interoperability, as well as their main deficiencies. Special notice must be given to [12], where the authors study how to manipulate, integrate and customize XaaS (anything as a service) over different cloud providers for SaaS development by proposing application and deployment orchestrators for IaaS. Further attempts have been presented by the DMTF organization, which has published standards such as Open Virtualization Format (OVF) or Virtualization Management (VMAN). OVF is an open standard for packaging and distributing virtual appliances, or more generally, software that will be run in virtual machines. Moreover, most of these approaches are targeted towards the infrastructure level thereby only dealing with issues that lie upon the surface of the standardization problem.
2. Modifying the c-Component to transform platform specific service dependencies (like persistence or authentication libraries) to cloud specific service dependencies, taking into account the services supplied by the cloud provider. 3. Modifying the way in which the c-Component consumes external services in order for this to be done in line with the cloud provider’s requirements.
3
1
In the second case, a series of guidelines are presented related to methodologies for developing composite SBAs for the cloud. Works like [5] and [6] propose solutions similar to those where middleware or broker layers are used. These layers behave as mediators between applications and cloud resources by providing their own cloud APIs and an architectural abstraction of the supported clouds. Nevertheless the use of these solutions implies developing cloud applications that will be tightly-coupled to the middleware platforms. Analyzing the previously described difficulties, we could summarize the main problem as a paradigm shift between the way in which components and services interacted initially, and how they do once they have been deployed in cloud environments.
2
Figure 1. Current scenario for SBA with cloud deployment. Once these work areas have been dealt with, the c-Component will have been correctly migrated to the cloud. Under these circumstances migrating it to a different cloud will necessarily imply doing the aforementioned modifications all over again in order to make the component compliant with the specifications of the new cloud environment. Therefore, taking this into account, the current scenario regarding SBA development for the cloud has the following implications: • Communication between components and services is strictly conditioned by the technology supported by each cloud and service provider. • The invocation mechanisms and technologies supported by each cloud provider must be taken into account for invoking external components and services provided by third-parties. • The use of vendor-specific technologies and services provoke migration and portability problems that have to be taken into account during the design stage. Currently little effort is being put into generating tools, techniques, procedures or standard data formats with enough potential to solve these shortcomings. In [3] the authors present an overview of the current state-of-theart regarding how to solve SBA cloud development problems. They distinguish between the existing standardization support for
We strongly believe that software adaptation is a technique which has probed its effectiveness in resolving service mismatching issues successfully [7][8][9]. Therefore we consider it could be a suitable technique for overcoming the limitations that have been identified in SBA development for cloud environments. Cloud computing SBA interoperability arouses a series of concerns that can be solved successfully with the use of adaptors. The variability between the API and service specifications of each cloud provider can be analyzed and defined in a formal notation, as well as the requisites of the different components that make up the developed application. By using this approach based on formal methods, detecting and solving mismatches in the different interoperability levels of the services, and generating the required mappings and adaptation components automatically, will be more straightforward. Furthermore, the adaptors can be generated during a specific stage of the whole application development process.
3. SOURCES OF SERVICE MISMATCH IN THE CLOUD
In order to facilitate the migrability and interoperability we consider that the following requirements are critical for the desired SBA development scenario for the cloud: • The specification and requirements of the components and services involved in the composition should be vendorindependent and technology-agnostic. An example of this could be any component that provides a service that is subject to a particular set of conditions or technological requirements (e.g. it may have to provide a SOAP service). Initially, the component’s specification should
not be conditioned by the restrictions imposed by any cloud provider. Instead, a further stage in the application development process will evaluate whether it is supported or not by specific cloud vendors and, if necessary, solve the mismatch that may occur.
1
• Components and services may or may not be deployed in cloud environments, this being a mutable architectural decision that may be taken at any point during the application’s lifecycle. Applying this to our previous example (see Figure 1), the design and implementation of the c-Component should require the same effort no matter which cloud or non-cloud platform it is deployed in.
3
1
• Third-party services and components may be integrated as part of the software that is being developed. The c-Component illustrated in Figure 1 may behave as a consumer of external components and services. Considering that the requirements and the behavior of services can be expressed semantically, this information can be used to link service consumers with providers that fulfill their requirements. Hence, the development process for cloud SBAs should be quite similar to the one carried out for in-house component-based applications. Software developers should be able to describe all of the components involved in the composition of the application through the use of the same set of techniques and methodologies. Additionally, they may choose to tag the components, thereby providing information about the cloud where they will be deployed. This information will be interpreted at some stage of the development process in order to determine which components need to be adapted as well as the type of adaptation that each one requires. The adaptation needs of each component will be conditioned by the cloud in which it will be deployed. That is, depending on the services provided by the cloud, the delivery model selected for the component (IaaS or PaaS), and the restrictions imposed by the cloud vendor, the adaptation will be done consequently. The desired scenario, where the adaptation points have been included, is illustrated in Figure 2.
2
Figure 2. Desired scenario with adaptors. Three different cases where adaptation would take place have been considered and tagged in Figure 2: 1. Adaptation between components. The way in which a component deployed in a cloud environment communicates with another component deployed in a non-cloud environment differs substantially from a fully in-house approach. Communication between two cloud deployed components has not been included in the figure, however it may be considered as a configuration covered by this case. 2. Adaptation between components and cloud specific services. Cloud environments usually provide specific services which can be consumed by its components. The most common examples of these services are those related with persistence, security/authentication, file management, etc. 3. Adaptation using third-party components or services (SaaS). Cloud deployed components consume external services differently depending on the provider in which they have been deployed. The services being invoked and their location, will also determine how they must be consumed. The following subsections analyze each of these cases in order to clarify their adaptation needs.
3.1 Component-to-component mismatch
Each cloud provider establishes its own set of policies and specifications which have a direct influence on how communication is carried out between components, thereby introducing the need for adaptation. Service provisioning and consumption, both between clouddeployed components as well as external components, may differ from one cloud provider to another. The following sources of mismatch have been identified for the component-to-component interaction side. All of them raise the need for adaptation:
A. Service naming and location: when a component, like the cComponent in our example, is deployed in a cloud environment, the name and the location of its services and operations will change. Adaptation techniques will have to be applied to non-cloud components in order to grant them access to the c-Component, and vice versa. B. Different technologies: some cloud environments may impose limitations on the technologies used by distributed components (e.g. SOAP, REST, Java RMI, etc.). Therefore, different transformations and translations may be required in certain components. C. Operation ordering mismatch: the technological adaptation of some components may imply changes in the order in which its operations are invoked, and it may even require new services and components to be invoked. For example, when a component, that originally provides a stateful service, is deployed in a cloud environment that only supports SOAP invocations, some protocol changes would have to be performed (i.e. WS-Resource and WS-Addressing mechanisms) in the communication to continue supporting a stateful behaviour [13].
3.2 Component-to-cloud mismatch
Component based applications are designed to provide a series of functionalities to other internal and external components. In many cases this may imply the use of architectural components that provide different services, such as storage, security infrastructure, or file management services. If either of these components has been deployed in a cloud environment, these services will have to be consumed from the underlying cloud environment. An adaptation process will be required for the correct use of the services as well as to prevent undesired situations, such as deadlocks. The following sources of mismatch have been identified for the component-to-cloud scenario. Some of them are common to Component-to-component adaptation, so we keep the same numbering: A. Service naming: the name of the very same services or functions that are invoked by the application components may differ from one cloud vendor to another. B. Different technologies: the APIs and services provided by different cloud vendors may be implemented in different technologies (i.e. Java RMI, REST, SOAP, etc.) which may also differ from those used by in-house approaches. C. Operation ordering mismatch: the operation ordering of cloud services may differ between vendors. For example, a generic ‘get’ operation offered by a particular cloud persistence service could imply several operation invocations and/or ordering differences from one provider to another. D. SLA related requirements: each cloud vendor will establish different SLAs for the applications hosted by their environment. The components will have to comply with the SLAs established by each provider and mismatches between application specific QoS requirements and cloud SLAs will have to be detected. E. Cloud-specific performance services: it may be interesting for components, in terms of service composition, to specify cloud intrinsic characteristics once they are deployed in a cloud
environment. For example, green-IT properties regarding power consumption could be specified in order for components to establish energy-saving execution policies. Different cloud providers would have their own specific API, and adaptation would be required to overcome their variability.
3.3 Component-to-SaaS mismatch
The cloud computing Software as a Service (SaaS) model is increasingly used in service composition to build mashups based on third-party components. In the current scenario an extensive catalog of cloud services exist, some of which carry out similar functionalities. These services often differ from each other at different levels, thereby making the use of adaptors very helpful for allowing their consumption. For this scenario the same sources of mismatch (A,B,C,D,E) as in the component-to-cloud scenario have been identified. The potential variability in the naming, protocols and QoS of the external services presents different sources of mismatch in this scenario. Also, an additional source has been identified: F. Semantic and context-aware functionalities: the consumption of external services on behalf of different components (clouddeployed or not), may be specified without determining the interface and location of the targeted service. This could be defined as an abstract concept, where adaptation would match and select the most convenient service according to the consumer’s requirements. For example, a component may require a translation service without having to specify the exact service it is going to consume. Adaptation techniques would be used to search for a suitable translation service that satisfies the requirements specified by the component. Component-to-SaaS adaptation could be carried out at designtime. However run-time adaptation could also be considered for the sake of flexibility.
4. ADAPTATION APPROACH
Software Adaptation (SA) is a branch of Software Engineering whose objective is to define techniques for arranging existing third-party software elements, such as components or services, in order to combine and reuse them in new systems, accommodating any potential mismatch arising from their interaction [9]. These software elements have an inherently black box nature. Hence, SA techniques are mostly non-intrusive and are aimed at developing mediator elements, called adaptors, which are computational entities specifically built for guaranteeing that a set of mismatching software elements will interoperate correctly. In this section we will show how SA techniques can be applied to the cloud sources of mismatch detected in Section 3. We distinguish several levels of software interoperability, and accordingly of interaction problems [14]. First, the signature level, where interoperability issues such as mismatches in operation names, parameters, and other framework-related issues are addressed. Next, the behavioral level, which deals with protocol mismatches; that is, differences in the order or the granularity of messages. Third, the service level, which deals with QoS and non-functional aspects like security, encryption, performance, etc. Finally, the semantic level, dealing with conceptual issues and mismatches in what a component or service actually does and what it is expected to do by its clients.
Mismatch may occur at any (or several) of these levels, and different SA techniques and solutions can be applied to solve them.
4.1 Signature adaptation
As stated above, signature mismatch occur when differences exist in service names and/or parameters, in data representation and encoding standards, and in operation calling conventions. Signature mismatch is the simplest and most frequent source of adaptation need. This kind of mismatch appears as sources A and B in all three interaction scenarios described in Section 3. Indeed, service name and location issues correspond to this level. Usual SA techniques for dealing with these problems imply the use of wrappers or stubs that act as proxies between client components and their service providers (either another component, the cloud it resides in, or a SaaS service). Apart from service name translation, parameter casting, reordering, and/or synthesis, and accommodation of calling conventions and data representation mismatch, the adaptor will also be in charge of acting as a remote proxy, hiding to the client that it may be accessing a previously in-house component that is now hosted in a cloud, or remote SaaS element. Signature adaptation techniques are well established and very particularly suited for solving this kind of problems. Most adaptation approaches imply the use of mappings (cf. [9][15]), that establish one-to-one correspondences between service and operation names in the client, with names in the interfaces offered by the corresponding service providers, and also correspondences among their parameters. From these mappings, and given the service location and the communication technology it uses, a generic adaptor interpreter can be instanced, in charge of translating and transmitting interactions according to a transformation scheme (for instance, from XML to JSON data representations). For the sake of performance, signature adaptors can be also automatically generated and compiled at design time, ensuring correct interaction in a particular scenario. Using these signature adaptation techniques, the system would be kept unaware that some of its components reside now in a cloud; a component could migrate from a cloud to a different one, and the system could freely select a given service among several SaaS providers.
4.2 Behavioral adaptation
Behavioral adaptation deals with mismatch in the granularity of interaction messages (service or operation requests and their responses). For instance, a service request, as being issued by a client component, may correspond to several invocations of the provider's interface. In a general case, complex M:N correspondences between messages may appear. Additionally, the order in which clients and providers require the messages or invocations and their issued replies may also differ, leading to deadlocks, livelocks and other protocol interaction problems when they are composed. As shown in Section 3, behavioral mismatch is likely to appear in all three scenarios as the source previously named C. The access to a service offered by the cloud or an external SaaS provider may include messages with a different granularity or order than those considered by the calling component, which was originally developed unaware of these services.
In the last years several approaches to behavioral adaptation have been presented (cf. [15][7]). Most of these approaches are based on signature mappings for establishing correspondences between messages, but in this case allowing M:N correspondences for accommodating different granularities. The combination of these mappings with a specification of the protocols followed/expected by both interacting elements is used to automatically generate a behavioral adaptor. Its role is to avoid interaction deadlocks and livelocks. In some cases additional properties, typically expressed in some kind of temporal logic, can also be ensured [7]. For that, the protocol adaptor will be in charge of accepting incoming messages from any of the interacting elements, remembering them, and then retransmitting them to the receiver when it is ready to accept them. It may also enforce certain interaction paths in order to avoid the violation of a desired property.
4.3 Service adaptation
QoS adaptation is probably the toughest and less explored of the interoperability problems mentioned above. As it deals with several and very different non-functional issues, such as security, cost, performance, dependability, etc., adaptation techniques (when they have been reported) tend to be applied to very specific problems. That is also the case of the adaptation needs detected in Section 3 (sources D and E), where very different QoS policies would need to be accommodated (if they could in any case be customized in the service provider platform), probably as part of a human-driven selection making and tuning process. Nevertheless, several adaptation proposals have been presented in this field, dealing for instance with context-awareness [8] and security issues [16]. We can also include in this category proposals related to SLA negotiation [17]. In any case, we believe that the increasing number of heterogeneous devices connected to the Internet, each one endowed with very different hardware and software resources and capabilities is making this adaptation level a hot research topic that will start producing interesting results in the next few years.
4.4 Semantic adaptation
Service discovery deals with finding the most appropriate service for fulfilling some given needs. Early approaches to semantic description in the field of Web Services were based in UDDI registries. However, UDDI only supports queries based on keywords and category. This may bring about low-precision results, as it is neither able to solve semantic matchmaking problems, nor to make a system self-adaptive to a changing environment without human intervention [8]. More recently, ontology-based notations, such as OWL-S and WSMO, coming from the field of Semantic Web, have opened a promising research trend in semantic matchmaking. Nowadays, W3C recommends the use of OWL-S to capture the semantic description of services. OWL-S enables a machinereadable representation of the relevant concepts within a domain by capturing the relationships between those concepts. This is called an ontology, which describes classes, relationships, and attributes of a particular domain, and provides a shared and common understanding of them. If several ontologies are defined over a given domain (for instance, vendor-specific ontologies) ontology alignment can be used for establishing relationships on equivalent concepts described in each of them. By using ontologies, the semantic matchmaking process can perform inference on the concepts involved, leading to the recognition of semantic matches despite their syntactic differences. Once a
suitable SaaS provider is found, adaptation techniques can be applied to solve any other interoperability problems (either at the signature, behavior, or service levels). Semantic matchmaking can be performed either at design time or at runtime. The latter brings in an interesting perspective, since it would allow changing the SaaS provider being used at a given point based on non-semantic preferences, such as availability, performance, cost, or any other QoS property. Table 1 summarizes the analyzed sources of mismatch, relating them to the different adaptation interoperability levels in which they could be framed. Table 1. Summary table of adaptation cases and interoperability levels. Interoperability Levels
Sources of mismatch
Involved scenarios
Signature
A, B
Behaviour
C
Component-to-component Component-to-cloud Component-to-SaaS
Service
D, E
Component-to-cloud Component-to-SaaS
Semantic
F
Component-to-SaaS
5. RELATED WORK
Cloud computing has aroused the interest of multiple vendors, consumers and researchers as a fashion term related with new business opportunities, personal computing services, or a new field for publication, respectively. Probably the most extended area of research regarding this field is that related to cloud infrastructure management. Furthermore, not much effort has been made in the standardization of cloud application development methodologies which would allow developers to build cloud-agnostic and cloud-interoperable applications. Regarding the standardization of cloud development and deployment mechanisms, mOSAIC [18] is a reference initiative carried out as a Europe funded project. Its manifesto, motivations, and perspective of how cloud development should be match those contained in our work. They propose a robust solution based on an API and a middleware platform for cloud brokering. In this case our approach, based on SA techniques, may present beneficial results in alternative scenarios where lightweight software components may be required. Additional related works are oriented towards analyzing the existent difficulties in achieving cloud application interoperability. Different solutions are proposed in this area. In [19] a survey is presented containing several cloud computing interoperability efforts which are classified into standardization initiatives, cloud computing interoperability frameworks and semantically interoperable cloud solutions. Each of them overcomes the lack of standardization at different levels with a variety of well-focused techniques and solutions. Neither of them present an approach based on adaptation, which may be simplify many interoperability issues. In [20], authors describe some of the challenges in achieving interoperability for cloud computing, reviewing current industrial efforts and proposing a cloud-to-cloud interoperability maturity
model. Amongst those challenges, the need to achieve cloudservice integration through SOA principles and service composition is clearly emphasized. They propose a cloud orchestration service as an intermediate broker layer. Our proposal contributes by providing an alternative solution for achieving these goals. Another middleware-centric proposal is described in [21], where the current cloud architecture’s shortcomings are discussed, and an intermediary Cloud-Intention Layer is proposed in order to decouple the cloud application source code from the cloud services. This paper shares our motivations for using SOA and service composition as a reference model for building cloud applications. Their proposal is based on an intermediate layer and a XML-based description language which allow users to describe web service runtime requirements as well as additional cloud resources, without having to change the source code. Our adaptation based approach provides an alternative way to overcome runtime requirement changes through the adoption of dynamic adaptors.
6. CONCLUSIONS AND FUTURE WORK
This paper has presented an outline of the main sources of mismatch that need to be solved in the process of building cloudagnostic-code for applications that will be deployed in cloud environments. An overview of the different SA levels has also been presented and they have been matched with each of the previously identified sources where SA could be applied. As a result, SA techniques can be applied to solve the aforementioned sources of mismatch. Nonetheless, some of the sources that have been identified may require a review process to be launched upon their correspondent SA techniques in order for them to comply with new requirements that had not been dealt with earlier (e.g. semantic adaptation, or the use of ontologies). This would be a contribution to the research carried out in the fields of cloud computing and SA. Once the adaptation issues have been categorized, our future work in this field will imply integrating each adaptation case into the framework being developed by [10]. As a part of this integration, different techniques will be explored to provide the adaptation with capabilities of mismatch detection, like formal methods and variability models. Generating dynamic adaptors for the software developed by the framework is one of our main interests since it will contribute to generate applications that can exploit the vast amount of services provided by the cloud, based on runtime service matching and consumption.
7. ACKNOWLEDGMENTS
This work has been partially funded by the Spanish Ministry of Science and Innovation under Project TIN2011-24278, the C.I.C.Y.T. Project TIN2008-05932, as well as by Junta de Extremadura and FEDER funds.
8. REFERENCES [1] H. P. Breivold, and M. Larsson, «Component-Based and Service-Oriented Software Engineering: Key Concepts and Principles», in Software Engineering and Advanced Applications, 2007. 33rd EUROMICRO Conference on, 2007, pp. 13 –20.
[2] S. Yau, and H. An, «Software Engineering Meets Services and Cloud Computing», Computer, vol. 44, no. 10, pp. 47– 53, 2011.
[11] D.K. Nguyen, F. Lelli, Y. Taher et al. (2011). Blueprint template support for engineering cloud-based services. In Proceedings of ServiceWave’11, pages 26–37.
[3] D.K. Nguyen, Y. Taher, M.P. Papazoglou, and W.J. van den Heuvel, Service-Based Application Development on the Cloud. State of the Art and Shortcomings Analysis, CLOSER 2012 Proceedings, 2012, pp. 395-400.
[12] K. Keahey, M. Tsugawa, A. Matsunaga, and J. Fortes (2009). Sky computing. IEEE Internet Computing, 13(5):43–51.
[4] D. Petcu, G. Macariu, S. Panica, and C. Crăciun, «Portable Cloud applications—From theory to practice», Future Generation Computer Systems, no. 0. [5] E.M. Maximilien, A. Ranabahu, R. Engehausen, and L.C. Anderson, (2009). Toward cloud-agnostic middlewares. In OOPSLA09: 14th conference companion on Object Oriented Programming Systems Languages and Applications, pages 619–626. [6] W. Tsai, X. Sun, J. Balasooriya (2010). Service-Oriented Cloud Computing Architecture. In ITNG10 7th International Conference on Information Technology: New Generations, pages 684-689. [7] J. Cámara, G. Salaün, C. Canal, and M. Ouederni. Interactive Specification and Verification of Behavioural Adaptation Contracts, Information and Software Technology, 54(7):701– 723, Elsevier, 2012. [8] J. Cubo, C. Canal, and E. Pimentel. Context-Aware Composition and Adaptation Based on Model Transformation, Journal of Universal Computer Science (JUCS), 17(5):776–806, 2011. [9] C. Canal, P. Poizat, and G. Salaün. Model-based adaptation of behavioural mismatching components. IEEE Transactions on Software Engineering, 4(34):546–563, IEEE Computer Society, 2008. [10] J. Guillén, J. Miranda, and J.M. Murillo (2012). Decoupling Cloud Applications From The Source - A Framework for Developing Cloud Agnostic Software. In CLOSER 2012 Proceedings.
[13] I. Foster, J. Frey, S. Graham, et al. Modeling Stateful Resources with Web Services. Globus Alliance, 2004. [14] C. Canal, J.M. Murillo, and P. Poizat. Coordination and Adaptation Techniques for Software Entities, ObjectOriented Technology. ECOOP 2004 Workshop Reader, LNCS 3344, pp. 133–147, Springer, 2004. [15] R. Seguel, R. Eshuis, and P. Grefen. Generating Minimal Protocol Adaptors for Loosely Coupled Services. IEEE International Conference on Web Services, pp 417–424, IEEE Computer Society, 2010. [16] J. A. Martín, F. Martinelli, and E. Pimentel. Synthesis of secure adaptors. Journal of Logic and Algebraic Programming, 81(2):99–126, Elsevier, 2012. [17] S. Venticinque, R. Aversa, B.D. Martino, et al. A cloud agency for SLA negotiation and management. Euro-Par 2010, 587-594, Springer, 2011 [18] B. D. Martino, D. Petcu, and R. Cossu. Building a mosaic of clouds. Euro-Par 2010, 571-578., Springer, 2011 [19] N. Loutas, E. Kamateri, F. Bosi, and K. Tarabanis. Cloud Computing Interoperability: The State of Play. Cloud Computing Technology and Science (CloudCom), 2011 IEEE Third International Conference on , vol., no., pp.752757, Nov. 29 2011-Dec. 1 2011. [20] S. Dowell, A. Barreto, J.B. Michael, and M. Shing. "Cloud to cloud interoperability," System of Systems Engineering (SoSE), 2011 6th International Conference on , vol., no., pp.258-263, 27-30 June 2011 [21] T. Baker, M. Mackay, M. Randles. "Eternal Cloud Computation Application Development". Developments in E-systems Engineering (DeSE), 2011 , vol., no., pp.392-397, 6-8 Dec. 2011
