Enabling cloud infrastructures to evolve into a transparent platform raises interoperability issues. Interoperability

requires standard data models and communication technologies compatible with the existing Internet

infrastructure. To reduce vendor lock-in situations, cloud computing must implement common strategies regarding

standards, interoperability and portability. Open standards are of critical importance and need to be embedded into interoperability solutions. Interoperability is determined at the data level as well as the service level. Relevant modelling standards and integration solutions shall be analysed in the context of clouds

Fowley, Frank

Pahl, Claus

Zhang, Li

English

Enabling cloud infrastructures to evolve into a transparent platform raises interoperability issues. Interoperability\ud
requires standard data models and communication technologies compatible with the existing Internet\ud
infrastructure. To reduce vendor lock-in situations, cloud computing must implement common strategies regarding\ud
standards, interoperability and portability. Open standards are of critical importance and need to be embedded into interoperability solutions. Interoperability is determined at the data level as well as the service level. Relevant modelling standards and integration solutions shall be analysed in the context of clouds

Name not available

Interoperability Standards for Cloud ArchitectureClaus Pahl1, Li Zhang1, Frank Fowley11IC4, Dublin City University, Dublin, Ireland[Firstname.Surname]@dcu.ieKeywords: Cloud Computing; Cloud Architecture, Cloud Interoperability; Cloud Standards.Abstract: Enabling cloud infrastructures to evolve into a transparent platform raises interoperability issues. Interoper-ability requires standard data models and communication technologies compatible with the existing Internetinfrastructure. To reduce vendor lock-in situations, cloud computing must implement common strategies re-garding standards, interoperability and portability. Open standards are of critical importance and need to beembedded into interoperability solutions. Interoperability is determined at the data level as well as the servicelevel. Relevant modelling standards and integration solutions shall be analysed in the context of clouds.1 INTRODUCTIONEnabling clouds to be merged and connected cre-ates interoperability problems (Armbrust et al., 2009;Buyya et al., 2011). Interoperability requires standarddata models and communication technologies com-patible with existing Internet infrastructure. Publiccloud services are available to the public. Hybridclouds are an integrated cloud services arrangementthat includes provision of compute resources frommore than one source. Hybrid architectural modelsmay be vertically partitioned (e.g. data stored pri-vately) or horizontally partitioned (e.g. using publiccloud to prototype a new device view of a servicein parallel with an existing implementation). Inter-operability solutions for flexible composition, migra-tion and portability are sought (451 Group, 2010). Toreduce vendor lock-in, cloud computing must imple-ment universal strategies regarding standards, inter-operability and portability. Open standards are of crit-ical importance and need to be embedded into inter-operability solutions (DMTF, 2010). Interoperabilityis determined at the data level as well as the servicelevel (OMG, 2009; Cloud Standards, 2013). The ob-jectives here include the review of relevant standardsfor cloud architecture interoperability and analysingthe overall maturity of the technology and determin-ing current trends and shortfalls.Typically, cloud computing consists of the threecloud layers infrastructure (IaaS), platform (PaaS)and software (SaaS) as service (Armbrust et al., 2009;Buyya et al., 2011). In addition, we can differen-tiate between (hardware or software) resources pro-vided in a traditional way, and the . . . as a Service ver-sion of them, which considers virtualization, multi-tenancy and elasticity as the main properties (Wanget al., 2009). Different usage models can be derivedfrom the combinations of the layers. For instance, anapplication over a platform: a software provider candevelop an application (e.g., a content management ordelivery system) and publish it. That allows it to bedeployed using some platform software (Web appli-cation container or database) and offered as a service(PaaS). The different usage models rely on interop-erability solutions. Service-based abstractions (APIs)need to be aligned with common (Web) service de-scription, modelling and composition standards.Interoperability concerns arise in different situa-tions: Firstly, interoperability between layers - stan-dardised APIs are necessary to allow higher cloudlayers to link to a range of services provided at thelower layers, e.g. platform implementations to uni-formly link to IaaS offerings. Roles of importanceare service provider and service user. Secondly, in-teroperability within layers - standards are requiredto allow components in a layer to interact and be ex-changeable. Non-service interactions need to be sup-ported, e.g. where a software developer combines dif-ferent platforms in the development of a new system.2 INTEROPERABILITYSTANDARDSStandards are necessary to consolidate efforts in atechnology domain and to enable interoperability inany technology domain. An overview and a categori-sation of standards relevant to interoperability in thecloud computing context that we cover here is:• Service modelling: Open-SCA (service compo-sition and interaction), USDL/SoaML/CloudML(multi-view services), EMML (mashups)• Service interfaces: OCCI (infrastructure manage-ment), CIMI (infrastructure management), EC2(de-facto standard), TOSCA (portability), CDMI(data management)• Infrastructure: OVF (virtual machines)For each standard, we provide background about ori-gins, support and purpose, the intended usage, and ananalysis of the relevance for interoperability consid-erations. Providing a comprehensive overview of allstandards is not the objective. We have singled outthose that represent specific aspects well. Well-knownservices standards and security standards shall not becovered due to space reasons.The OASIS Open Composite Services Architec-ture (CSA) aims to simplify SOA application devel-opment (Open CSA, 2012) connected to the ServiceComponent Architecture (SCA) and Service Data Ob-jects (SDO) families of specifications. The SCA As-sembly Model is a framework to describe service co-ordination and interaction that ties in service compo-sition with common software architecture concerns.The CSA standards can be utilised as is or can serveas input for any composition and assembly language.The specifications on the SCA Assembly Model arevery relevant for interoperability. Data interoperabil-ity is an equally important concern in Open-CSA.Data could be represented in Service Data Objects.Enterprise Mashups combine and remix data fromdatabases, spreadsheets, websites, Web Services,RSS/Atom feeds, and unstructured sources that de-liver actionable information. The Open Mashup Al-liance (OMA) is in charge of the Enterprise MashupMarkup Language (EMML) (EMML, 2012). It cansupport enterprise mashup implementations, improvemashup portability of mashup designs, and increasethe interoperability of mashup solutions. EMML isdesigned to be complimentary to and integrated withlanguages like JavaScript, Java, Groovy, and Rubyvia scripting. It is particularly suited for interop-erability issues related to mashup creation. It sup-ports lightweight and integrative service assemblyand, therefore, represents specific modelling and in-tegration concerns.The aim of the Unified Service Description Lan-guage (USDL) is describing general parts of techni-cal and business services to allow services to becometradable and consumable (USDL, 2012). Technicalservices are considered services based on WSDL,REST or other technical specifications. Business ser-vices are defined as business activities that are pro-vided by a service provider to a service consumer tocreate value for the consumer. The USDL definitionaims at complementing the technical language stackby adding required business and operational informa-tion. The targeted cloud stakeholders for USDL areservice providers, infrastructure providers, service as-semblers and service consumers. USDL defines aninteroperability-centric language that enables its usersto model arbitrary services and to integrate with ex-isting standards. The aim to address service mod-elling and support mappings to different standardsmakes this interesting for interoperable cloud mod-elling. This enables new business models for servicebrokerage because services can automatically be of-fered, delivered, executed, and composed from ser-vices of different providers.Another development to be considered in thiscontext includes SoaML (standardised by OMG, seehttp://www.omg.org/spec/SoaML/), which falls intothe same category as USDL in our categorisation asa service description and modelling language. Whilestill under development (and thus far from being stan-dardised), CloudML (http://www.cloudml.org/) is alanguage more specific to clouds.OCCI (infrastructure lifecycle management) isnow the first of four cloud-specific standards, also in-cluding CIMI (like OCCI on infrastructure manage-ment), TOSCA (portability and cloud-bursting), andCDMI (data management), interleaved with a noteon EC2 as a proprietary solution that has become ade-facto standard. Providers offer IaaS solutions toenhance elastic capacity, where server instances areexecuted in their proprietary infrastructure and billedon a utility computing basis. For the infrastructurelayer this means that typically virtual machines on aper-instance per-hour basis are the units. The OGFOCCI working group provides an API specificationfor the management of cloud computing infrastruc-ture to capture these concerns (OCCI, 2012). Thescope is a comprehensive range of high-level func-tionality required for the life-cycle management ofvirtual machines (or workloads) running on virtual-ization technologies (such as containers) supportingservice elasticity. OCCI provides an API for inter-facing IaaS cloud computing facilities, which is suf-ficiently complete to facilitate the implementation ofinteroperable implementations. While targeting IaaSconcerns, it can foster interoperability endeavours athigher levels. The scope of OCCI is high-level func-tionality required for lifecycle management. This isin part realised through coverage of existing propri-etary APIs. While the focus is on the upper cloudstack layers for the section presented in Figure 1, it isnonetheless a suitable framework for interoperabilityconcerns at the interface of infrastructure services.Similar to OCCI, the CIMI - Cloud Infrastruc-ture Management Interface from DMTF addresses in-frastructure management. CIMI which addresses theruntime maintenance and provisioning of cloud ser-vices. The scope of the CIMI standard covers coreIaaS functionality, addressing deploying and manag-ing virtual machines and other artifacts such as vol-umes, networks, or monitoring. Once interfaced tothe IaaS provider, the information that needs to beprocessed to manage a cloud service can be discov-ered iteratively, including the metadata describing ca-pabilities and resource constraints. Most develop-ers use with the CIMI REST/HTTP-based protocol,the current interface binding to the model (others areexpected later). This delivers standard HTTP statuscodes and supports JSON and XML serialization for-mats. CIMI, if widely used, would allow organisa-tions to design cloud-based business solutions beingassured that management (and governance) processeswill not be compromised if the business solution ismoved to another (standards-based) IaaS provider.While OCCI and CIMI are similar standards,Amazon EC2 as a proprietary solution needs to beconsidered as well. Amazon Elastic Compute Cloud(Amazon EC2) provides resizeable computing capac-ity servers in Amazon’s data centers to build and hostsoftware systems. They allow access to componentsand features using a web-based GUI, command linetools and APIs . EC2 comes with a rich ecosystem.Some open-source standards are pushed by Amazoncompetitors to regain market shares.Supported by OASIS, the TOSCA frameworkaims to enhance the portability of cloud applicationsand services. TOSCA enables interoperable descrip-tion of application and infrastructure cloud services,the relationships between parts of the service, and theoperational behaviour of these services (such as de-ploy, patch, shutdown) independent of the suppliercreating the service, and any particular cloud provideror hosting technology. TOSCA also aims to sup-port higher-level operational behaviour to be associ-ated with cloud infrastructure management. The coreconcept behind TOSCA is cloud bursting, which isthe ability to move workloads between public and pri-vate cloud infrastructures in a transparent way. Thereseems to be some discussion about the prospect ofsuccess, with large IaaS providers not having joinedthe consortium yet. The core to the solution would bea hypervisor-agnostic portability mechanism, whichrequires IaaS compliance. TOSCA also needs to beobserved as a vendor initiative in the context of open-source activities like OpenStack gaining momentum.The CDMI, the Cloud Data Management Inter-face by SNAI targets cloud storage. CDMI is a stan-dard for self-provisioning, administering and access-ing cloud storage. CDMI defines RESTful HTTP op-erations for accessing the capabilities of the Cloudstorage system. CDMI defines the functional inter-face that applications use to create, retrieve, updateand delete data elements from the cloud. As part ofthis interface, a client can discover the capabilitiesof the cloud storage offering and use this interfaceto manage containers and the data that is placed inthem. In addition, metadata can be set on containersand their contained data elements through this inter-face. Compared to OCCI and OVF, CDMI specifi-cally targets data migration and format immigration.Although CDMI can also be used for task manage-ment, this would need extensive rules to be defined.OVF is the most critical and successful standardspecific to cloud infrastructure. The Open Virtu-alization Format (OVF) describes an open, secure,portable, efficient, and flexible format for the packag-ing and distribution of one or more virtual machines(OVF, 2012). OVF features include optimized distri-bution and portability of virtual appliances. It sup-ports compression for more efficient package trans-fers, content verification and integrity checking, andprovides a basic scheme for the management of soft-ware licensing. It supports vendor and platform inde-pendence as it does not rely on the use of a specifichost platform, virtualization platform, or host/guestoperating system. It is also designed to be extendedas the industry moves forward with virtual appliancetechnology. The OVF format provides a completespecification of a virtual machine, which may includemultiple virtual disks.OVF is a portable format thatallows users to deploy VMs in any hypervisor thatsupports OVF. As such, it sits at the core of resourcemanagement in the infrastructure provisioning layer,overcoming previous deficiencies in standardised so-lutions such as VMDK. For supporting interoperabil-ity as a standard for this technical context, other fea-tures like localisation are important.3 DISCUSSION ANDCONCLUSIONSInteroperability between clouds is vital for the fur-ther development of the cloud ecosystem and mar-ket. While standards for the Web Services context areabundant, more specific standards for the cloud com-puting domain reflect the current maturity.• A number of standards for the lower infrastructurelayers apply to respective cloud computing tech-nologies. They address interoperability solutionsfor specific aspects like virtual machine manage-ment or data management.• For platforms and services, the respective (Web)service standards are still of relevance. Standardsexist, beyond the core Web services platform, thatcan further the development of platform and soft-ware services from existing offers. Generic ser-vice solution can provide a starting point wherecloud-specific standards are lacking.In addition, it is worth looking at a number of differ-ent concerns that help us to judge the state of stan-dardisation and it’s impact on interoperability: or-ganisations behind standards and their domain, stake-holders involved through standards, and standards andopen-source/proprietary solutionsFirstly, by looking at the organisations behind thestandards, we can also observe that while the Webservices domain is primarily dominated by W3C andOASIS in terms of standardisation, the situation incloud computing is more diverse. Some of the or-ganisations active include DMTF (management ofdistributed IT systems), the OGF (grid computing),the OMG (middleware), SNIA (storage), OASIS (ser-vices), OCC (cloud), as well as national (e.g. NIST)and sector-specific (e.g. ETSI - telecoms) organisa-tions. Currently, there is a dominance of infrastruc-ture and lower-level management. Secondly, stake-holders are yet another perspective that we can lookat. We have referred to stakeholders in the review anddiscussion of standards where relevant to differenti-ate the different interoperability needs of stakehold-ers in clouds as multi-organisational, multi-role en-vironments. While the infrastructure standards targetclearly software developers, the more generic service-oriented standards are more at the interface (as-a-service) level, targeting service providers and con-sumers. Particularly combined roles, such as pro-sumers or aggregators that are providers and con-sumers benefit from the recent service descriptionand modelling standards. Thirdly, while standardscan achieve interoperability, often de-facto standardsemerge from open-source or proprietary solutions.We dicussed OCCI and CIMI as standards in a contextwhere OpenStack is a compliant open-source frame-work, all competing with Amazon EC2.By looking at the standards we reviewed here forindications of future standardisation needs, emergingfrom the categorisation of standards are the followingobservations: (i) Modelling under incorporation of avariety of standards can support migration and, con-sequently, the uptake of cloud computing solutions.(ii) Composition, e.g. through mashups, is becomingof increasing importance to provide a market for ba-sic and composite offering where providers and ag-gregators compete. (iii) Quality of Service and Ser-vice Level Agreement standardisations beyond secu-rity concerns in the cloud are actually largely lacking.REFERENCES451 Group (2010). Cloud Computing ’As-a-service’ marketsizing. Report IIArmbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R.,Konwinski, A., Lee, G., Patterson, D., Rabkin, A.,Stoica, I. and Zaharia, M. (2009). A view of cloudcomputing. Comm. ACM 53(4), 50-58.Buyya, R., Broberg, J., and Goscinski, A.(2011). CloudComputing - Principles and Paradigms. Wiley.CloudCom (2011). Market Implementation ofCloud Interoperability and Portability Re-search in IaaS and PaaS. Retrieved from:http://www.cloud4soa.eu/workshop2011Cloud Standards (2013). Retrieved from: http://cloud-standards.org/wiki/index.php?title=Main PageDistributed Management Task Force (2010).Interoperable Clouds. Retrieved from:http://www.dmtf.org/sites/default/files/standards/documents/DSP-IS0101 1.0.0.pdfEnterprise Mashup Markup Lan-guage (2012). Retrieved from:http://www.openmashup.org/omadocs/v1.0/index.htmlOCCI Open Cloud Computing Interface (2012). Retrievedfrom: http://occi-wg.org/OMG Object Management Group (2009). Cloud Inter-operability Roadmaps Session. Retrieved from:http://www.omg.org/news/meetings/tc/ca/special-events/Cloud Interop Roadmaps.htmOpen CSA - Open Composite Services Architecture (2012).Retrieved from: http://www.oasis-opencsa.org/OVF Open Virtualization Format (2012.) Retrievedfrom: http://www.dmtf.org/sites/default/files/ stan-dards/documents/DSP0243 1.1.0.pdfPahl, C. (2005) Layered ontological modelling for webservice-oriented model-driven architecture. EuropeanConference on Model Driven Architecture Founda-tions and Applications ECMDA05, 88-102.Pahl, C., Giesecke, S. and Hasselbring, W. (2009). Anontology-based approach for modelling architecturalstyles. European Conference on Software ArchitectureECSA’2007, 60-75.Unified Service Description Language (2012.) Retrievedfrom: http://www.w3.org/2005/Incubator/usdl/Wang, M.X., Bandara, K.Y. and Pahl, C. (2009). Inte-grated constraint violation handling for dynamic ser-vice composition. IEEE International Conference onServices Computing SCC’09.

Interoperability standards for cloud architecture

DCU Online Research Access Service

An ontology-based approach for modelling architectural styles.

Cloud Computing - Principles and Paradigms.

Cloud Computing ’As-a-service’ market sizing. Report

Description Language (2012.) Retrieved from: http://www.w3.org/2005/Incubator/usdl/

Market Implementation of Cloud Interoperability and Portability Research

Enabling cloud infrastructures to evolve into a transparent platform raises interoperability issues. Interoperability
requires standard data models and communication technologies compatible with the existing Internet
infrastructure. To reduce vendor lock-in situations, cloud computing must implement common strategies regarding
standards, interoperability and portability. Open standards are of critical importance and need to be embedded into interoperability solutions. Interoperability is determined at the data level as well as the service level. Relevant modelling standards and integration solutions shall be analysed in the context of clouds

Irish Universities

http://doras.dcu.ie/17824/1/closer13-sp.pdf

Interoperability standards for cloud architecture

Abstract

Similar works

Full text

Available Versions

Name not available

DCU Online Research Access Service

Irish Universities