An approach to unified cloud service access, manipulation and dynamic orchestration via semantic cloud service operation specification framework
© Fang et al. 2015
Received: 6 February 2015
Accepted: 10 June 2015
Published: 18 June 2015
Cloud computing offers various computational resources via convenient on-demand service provision. Currently, heterogeneous services and cloud resources are usually utilized and managed through diverse service portals. This significantly limits the effectiveness and efficiency for tasks implementation. Fundamentally, it is due to the lack of adequate specifications for service concepts, operations and interfaces from diverse cloud service models and types. This paper proposes a service management operation semantic description framework for comprehensive cloud service operation specification. Relying on ontological modelling techniques, cloud service operations are specified via entity classification, attribute assertion, relationship assertion and annotation assertion. Further, the proposed framework benefits from operation reasoning application. It enables intelligent assistance for multiple operation preparation and remote execution tasks. Based on the approach, a cloud service operation ontology and a unified service access and manipulation system prototype are implemented. Extensive experiments are conducted over different cloud service providers and for distinct service models. Obtained results demonstrate that the approach outperforms existing practices by facilitating reliable and effective service access, manipulation and interaction tasks.
In the era of cloud computing, Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) providers offer on-demand services and resources for various compute/platform/software needs [1, 2]. While many cloud service providers (CSPs) provide unique management portals for their own services and resources, the interfaces, functionalities and service operation environments are mostly diverse. Indeed, this is due to the fact that different CSPs tend to act distinctly while addressing service quality of service (QoS), features, customizability, requirements, etc. [3, 4]. As a result, while trying to manage multiple cloud services and resources, users often have to use a variety of cloud portals for different CSPs. This significantly limits the effectiveness and efficiency for tasks deployment and implementation.
To deal with the above issues, a number of approaches to cloud service and resource interoperability and portability are proposed. These solutions include but are not limited to: open cloud API (Application Programming Interface) development such as jclouds , libcloud , fog ; service specifications such as TOSCA , mOSAIC ; generic cloud management protocols/drivers such as OCCI . Despite their capabilities of handling certain specific service and resource categories, it is difficult to find any that allows adequate management for diverse CSPs’ services and resources via a common interface. This is mainly due to the lack of a unified service specification framework that can interpret cloud service and resource entities and deal with the interoperability among CSPs .
This paper proposes a new service operation semantic specification approach, called Service Access and Manipulation Operation Specification (SAMOS) framework. The framework is underpinned by ontological modelling techniques. It is capable of modelling comprehensive specifications for cloud service operations regardless of the service/operation/provider types. The variety of service operations are specified into two categories: service information requests and service manipulation requests. For each category, the proposed framework describes the detailed operation elements involved, including the parameters, requirement, outcome, condition changes, etc.
Based on SAMOS, a cloud service operation ontology and a unified service remote management prototype tool are dev eloped. In this paper, “unified” refers to the term that an integrated and versatile (specification and management) solution is provided for heterogeneous services and resources in multiple cloud environments. To such extent, the proposed model can interpret and preserve the complexity which lies behind cloud service operation executions, in a formal systematic way. By utilizing a cloud service API mapping mechanism, the tool is compatible with real IaaS, PaaS and SaaS services from multiple provider clouds. Accordingly, the ontology and the tool enable users to effectively view, create and manipulate a wide range of cloud service and resource data via a unified structured interface. Additionally, featured with ontology reasoning techniques, the proposed approach can provide a series of operation assistances. This means that appropriate service operations can be dynamically prepared and/or composed into groups and then executed intelligently according to the real-time status of the target cloud services and resources, even if they are originated from multiple clouds. Consequently, the proposed unified cloud service operation specification and reasoning approach is capable of providing effective semantic support to deal with cloud (service) interoperability issues.
The rest of the paper is organized as follows: Section “Background and related work” discusses the background and related work regarding open cloud API, service semantic specification and generic cloud service management tool. Section “SAMOS service operation modelling framework” describes the core and detailed elements of SAMOS framework. Section “Service operation requirement verification and dynamic assistance reasoning” outlines cloud service operation requirement verification and reasoning assistance mechanisms. Section “Prototype implementation” provides the design of the prototype system and components, including the API (and specification) mapping implementation. Section “Case studies” demonstrates case studies and experiments on real cloud services. Section “Evaluation and discussion” evaluates the proposed approach based on findings and the obtained results. Finally, Section “Conclusions and future work” concludes the paper with summaries and future work.
Background and related work
Considerable efforts have been made on enhancing the interoperability and portability of cloud services. The practices are widely applied in open cloud API developments, comprehensive service interface specifications, versatile cloud management protocols or drivers, etc.
Open cloud service specification framework
The Open Cloud Computing Interface (OCCI ) is one of the earliest attempts to eliminate cloud resource heterogeneity. Originally, it was developed only to deal with IaaS remote management tasks such as resource deployment, monitoring and automated scheduling. Later, the evolved Rendering and Extension specification frameworks enable wider application for PaaS and SaaS services, which consequently make it a generic management driver for a number of cloud resources.
The OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA ) is a recently established standard for clouds. With the aim to enhance cloud service portability, it enables specifications for diverse cloud service resources, their relationships and operational behaviors. With several templates (e.g. service and policy templates) and types (e.g. node, relationship, requirement and capability types) specifications, the topology framework can provide semantic support for many cloud service management and orchestration tasks.
Other than the above well-established practices, a series of research projects are also implemented towards the aim. mOSAIC , for instance, advocates application/provider/language-independent cloud service semantic specifications. The mOSAIC ontology model enables separation of application-logic and cloud layers and consequently enhances cloud portability. Likewise, the RASIC framework  attempts to enhance service interoperability through modelling three horizontal layers (i.e. service frontend, SOA, virtualization/execution) and two vertical layers (i.e. semantic and governance). Similarly, the Intercloud  architecture comprises multi-layer cloud service models and a series of management, federation and operations frameworks. They serve as cloud middleware to support the service integration. However, these approaches are developed mainly for infrastructure services and resources, and cannot be effectively applied to PaaS and SaaS models.
Open cloud service API
Deltacloud  provides a REST -based cloud abstraction API that enables service management functions for a number of IaaS resources. The wide range of CSP support makes it feasible to manage heterogeneous resources across diverse clouds. Fundamentally, it runs a series of cloud drivers, which serve as individual service adapters for each CSP specifically. Deltacloud API along with the management interface enables long-term stability for cloud resource utilization.
On the other hand, a number of (stand-alone) language-dependent cloud APIs are also found. Libcloud , for instance, is a Python library that offers wide support for many popular CSPs. The library provides interfacing functions mainly for compute, storage, load balancer, etc. services. Fog  is an API library for Ruby developers. It also has flexible support for several services from mainstream CSPs. Jclouds  and Dasein , are examples of java API library that supports a wide range of CSPs. Likewise, they can be applied to manage various CSPs’ IaaS compute, platform, database, storage, etc. services.
Some open cloud service API research is also found in the field. Bastião Silva et al.  propose a common API and SDCP (Service Delivery Cloud Platform) for delivering services over multi-vendor cloud resources. The platform is capable of describing diverse cloud concepts (e.g. agent, domain, and provider) and managing service data and abstraction conventions. Similarly, Petcu et al.  propose the mOSAIC java API as an example of open interface for service deployment and portability. Nonetheless, a drawback is that it cannot effectively handle the unique features offered among distinct cloud services (i.e. lack of support for many provider-specific service features).
Service and resource management tools for heterogeneous clouds
Bernabe et al.  demonstrate an access control system for multi-vendor cloud resource management. The proposed ontology specifications can describe various entities (e.g. cloud, system, software, etc.), whereas the authorization model can deal with user authentication and authorization tasks. Despite its advanced hierarchical role-based access control, the application is currently limited to IaaS resources and a single CSP (AWS EC2 ).
Cloud Data Imager (CDI)  is seen as a complete system to provide comprehensive functionalities for accessing and managing storage resources across diverse clouds (i.e. Dropbox, Google Drive, and Microsoft SkyDrive). The proposed CDI library is able to handle a variety of functions including user authentication, folder listing, file downloading, etc. Another work addressing resource utilization monitoring issues over heterogeneous multi-tenant clouds is found in DARGOS . The proposed architecture can provide highly reliable monitoring functions. These approaches would only work for their own limited cloud service models/types.
A model-based cloud service integration platform  is advocated to drive service orchestration for business application integration. The proposed framework addresses three levels of modelling: cross-organizational business processes, service operation/orchestration, and dynamic member services binding. Nonetheless, the approach focuses mainly on enhancing cloud service and resource integration for certain specific business processes. The platform is not an ideal tool for a diversity of cloud service and resource management tasks.
In summary, there are well-established cloud specification standards and considerable native/third-party open cloud service API libraries for application over various cloud resources and many CSPs. Meanwhile, many approaches are proposed as a means towards generic cloud service management. They bring some alternatives for avoiding vendor lock-in plus flexible management of services and resources. Nevertheless, due to the gaps among existing studies, currently no solution is available for a unified and effective management of diverse cloud service models/types regardless of CSPs. Consequently, this significantly limits the effectiveness and efficiency for cloud service management and composition tasks.
SAMOS cloud service operation modelling framework
SAMOS models cloud service operation via three components: cloud service entity and operation classification, cloud service entity datatype specification, and cloud service entity operational relationship specification.
Cloud service entity and operation classification specifications
Specifically, cloud services and CSPs are asserted as ontology classes. According to their membership functions (e.g. a service belongs to a certain CSP), the service class is seen as a subclass for the CSP class. Then, cloud service instances (CSIs) created within a cloud service are specified as individuals of the service class.
The classification also applies to additional cloud entities, such as service operation parameter entities, service configuration entities, and service accountability and user authorization data (e.g. service regions, instance attributes, user account data, etc.). Here, considering that almost all of such entities tend to be CSP-specific (i.e. the data formats, names, descriptions, etc. of the entities would all be unique from one CSP to another), they are specified as “provider-specific service aspect” (PSSA). Nonetheless, some PSSAs, i.e. common service/software aspects, may fundamentally indicate the same entity, despite their distinct PSSA names (e.g. public IP addresses, open VM images and SQL database data entries). These associated entities are declared with equivalence (via “equivalent class” or “same individual” axioms). Fig. 1 summarizes the association relationships among cloud services, CSIs and PSSAs.
Further, the diversity of cloud service operations are asserted as ontology classes and individuals according to their associations. As illustrated in Fig. 1, cloud service operation class comprises four subclasses: IaaS, PaaS, SaaS and Common Operations. They each own a set of relevant operations. Obviously, for IaaS, PaaS and SaaS, the majority of the categorized operations would be different from each other. Then, the common cloud service operations, which are available widely for all service models (e.g. “list instance”, “set region”), are gathered in the Common Operation class.
Cloud service entity datatype specifications
Indeed, these data properties enable precise datatype format demonstration, differentiation and validation for cloud entities and operations. With the extracted data presentation patterns and respected pattern examination mechanism, validations can be effectively implemented for cloud service operation preparation and execution (e.g. validations of authorization, input, output, condition, etc.).
Cloud service entity operational relationship specifications
Cloud service operations can be seen as reflections of the operational relationships among relevant cloud service and operation entities. For instance, I) “Create instance” and “List instance” can describe the creation and inclusion relationships from a cloud service to its instance(s). II) “Get instance ID” and “Modify instance name” can clarify the retrievable and modifiable relationships from a service instance to its property and condition. This is how SAMOS tackles cloud service operation specification by modelling the diversity of service entity operational relationships.
Classification of cloud service operations
Classification of cloud service operations
Service Information Request (SIR)
Operation requested to retrieve service entities and entity information
List owned service instances, get instance ID, get available platforms
Service Manipulation Request (SMR)
Operation requested to make changes to cloud services, CSIs or PSSAs
Create new instance, terminate instance, modify instance name
At the cloud service level, SIR often relies on collecting all available cloud service’s settings and instances (e.g. get available regions and list instances). At the CSI level, it is usually to retrieve the diverse real-time information of a certain service instance (e.g. get instance status). At the PSSA level, it tends to acquire the real-time information of the specific CSP entities (e.g. get VM image ID). Generally, SIR operations would not alter any cloud service, CSI or PSSA after execution.
At the cloud service level, SMR is usually to handle the general service settings and overall instances management tasks (e.g. set region and delete all instances). At the CSI level, it is mainly regarding some specific instance control and modification functions (e.g. reboot VM instance). At the PSSA level, it is for the manipulations implemented on those unique CSP entities (e.g. delete VM image). On successful execution, SMR should alter the target cloud service/CSI/PSSA in an intended way.
Cloud service operation object property specifications
Additionally, the details of cloud service operations, i.e. operation conditions, parameters, outcomes and changes are comprehensively described in SAMOS. Here, we utilize a series of systematic operation specification elements to specify the aspects that may be involved (before, during and after operations). These details are stored in the form of ontology annotations for the respective object property relation assertions.
Request subject (SRSubject)
SRSubject is recognized as the target of a cloud service operation. As a user selects a cloud service for operation, the service becomes the target. Similarly, SRSubject can apply to all CSIs and PSSAs if selected.
Request parameters (SRParameter)
Although some cloud service operations can execute with only SRSubjects, many others do need certain parameter inputs, e.g. relevant restrictions, options, customized data, etc. These are required by CSPs to enable accurate and successful service operations. SRParameters specify such details for applicable service operations. Generally, PSSAs make up the majority of SRParameters; CSIs can also be involved as SRParameters; it is unlikely for any cloud service to be used as SRParameter.
SRParameter symbol notations
Denotation (in object property annotation)
Examples service operations and SRParameters
Set authorization: (“basic”)
Deny access: <“user1,2…”>
Request outcome (SROutcome)
As a cloud service operation is executed, certain data response would be returned from its CSP, informing the execution result, e.g. execution status, obtained service information, newly altered service entities, etc. This operation element is represented as SROutcome. Typically, for the majority of operation requests, SROutcome reveals the expected service entities to be returned from the respected CSP. For some simple SMR operations, SROutcome would only be the (expected) success response.
Request pre condition (SRPreCondition)
According to CSP restrictions, there may be various operation request condition requirements. Some operations can be initiated without any condition constraints whilst others do need specific condition fulfilments. This is defined as SRPreConditions of cloud service operations. For SRPreCondition specification, the condition text can be either positive (“VM == off”) or negative (e.g. “service ! = updating”), where specific data formats and symbols can be involved (e.g. “instance count restriction < = 100”). SRPreCondition applies only to those operations which genuinely require so; others would have an empty entry (“unconditional”) for the element.
Request post condition (SRPostCondition)
Using the same specification pattern as SRPreCondition, SRPostConditions describes the (expected) post execution condition of a cloud service operation. Specifically, the condition is accounted whenever a “new” condition is created. This is to drive as many as operation compositions (by paring SRPreCondition and SRPostCondition) towards possible cloud service orchestrations. Hence, a SRPostCondition does not necessarily need to contradict the respected SRPreCondition: some operations may only have SRPostCondition and no SRPreCondition; for some operations, the entities involved in SRPostCondition may be different from those in the respected SRPreCondition. For instance, a VM creation operation can have SRPreCondition of “account restriction == OK” and SRPostCondition of “VM == running”.
Service operation requirement verification and dynamic assistance reasoning
While cloud service entities, their attributes and relationships, and operation elements are comprehensively specified, relevant service operation assistance reasoning can be introduced. In fact, this enables effective cloud service operation execution management, even for cloud service orchestration tasks.
Basic service operation preparation and execution
A typical use of the cloud service operation specifications is verification. Given SRSubject, relevant SRParameters and fulfilled SRPreCondition, an operation can be remotely executed through appropriate programming interface request. If successfully executed, this would result in certain service entity (data) which matches the respected SROutcome and/or SRPostCondition.
Service operation parameter verification
Service operation precondition verification
Cloud service operation reasoning assistance type
Reasoning assistance name
Precondition & parameter preparation
To assist in preparation of precondition and parameters for unsatisfied service operations
Single cloud (CSP)
Guided manual input
1. For the unsatisfied SRParameters and SRPreConditions, list possible options based on current selected SRSubject and SRParameters, plus the real-time status of them;
To assist in multiple concurrent service operations of similar types
Multiple clouds (CSPs)
1. Get SRSubjects’ operations which have satisfied SRParameters;
2. Filter the operations based on whether their preconditions fulfil the real-time SRSubject statuses;
3. Produce the operation lists for the applicable SRSubjects;
To assist in automatic scheduled executions of a series of operations in a logical sequence
Single cloud (CSP)
1. Get SRSubjects’ operations which have satisfied SRParameters;
2. For the operations, seek for those which have precondition SRPostCondition matches;
3. Compose these operations into sequenced chains by filtering
Them from their factorial combinations, according to the two-two sequenced connections;
4. Filter the operation chains based on whether the first operation’s preconditions fulfil the real-time SRSubject status;
Produce the operation lists for the applicable SRSubjects
To assist in seeking possible service interactions by linking appropriate operations in a scheduled sequence
Multiple clouds (CSPs)
1. For all SRSubjects’ operations, seek for those which have SROutcomes SRParameters (equivalence) matches;
2. For all SRSubjects’ operations, seek for those which have SRPreCondition SRPostCondition matches;
3. Compose these operations into sequenced chains as long as their SRPostConditions and SRPreConditions are not contradictory, according to the two-two sequenced connections;
4. Filter the operation chains based on whether the first operation’s preconditions fulfil the real-time SRSubject status;
5. Produce the operation lists for the applicable SRSubjects
Basic Assisted Service Operation Request (BASR) assistance reasoning
BASR serves to help users understand the required SRPreConditions and SRParameters for service operations. It also assists in relevant operation preparations during the operation process. Basically, as a user selects certain cloud service/CSI/PSSA and SRParameter(s), BASR can actively examine all available operations for unsatisfied operation conditions and parameters. Then, relevant information regarding how to fulfil such conditions or/and obtain the mandatory parameter(s) is produced to assist the user for further actions.
BASR is implemented on a per cloud service/service instance and per service request basis. This means that the assistance algorithm does not consider the potential subsequent impact resulted from one operation to another (or from service entity to another).
Concurrent Combined Service Operation Request (CCSR) assistance reasoning
As some cloud services own the same model/type/function, their service operations are very similar. Indeed, the operation specification patterns for such operations often coincide. Due to this nature, these operations can be composed and then executed concurrently towards greater efficiency.
CCSR reasoning algorithm enables a convenient means of executing multiple similar service operations for eligible cloud services or instances, even across multiple clouds. Specifically, as a user selects multiple SRSubjects and a series of required SRParameters, CCSR collects the eligible operations into simultaneously executable groups, and offers the options to the user. For the reason that CCSR assistance is provided at a per request basis, although it acts to control multiple cloud service entities, the algorithm does not consider the potential impact resulted from one request to another. Hence, the assistance still does not adopt any scheduling controls.
Sequenced Chained Service Operation Request (SCSR) assistance reasoning
For some service operations, the SRPostCondition of an operation may happen to match (or be equivalent to) another’s SRPreCondition. In other words, the successful execution of some operations would enable certain subsequent operations dynamically by satisfying their precondition requirements. As a series of such operations are linked one another with precondition and postcondition matches, a sequenced operation chain can be composed in real-time. SCSR serves to seek such operation chains and provide assistances in scheduling their sequenced executions. Although this may happen over multiple clouds, we consider that it would be more reasonable for implementation in a single cloud. Hence, the scale of SCSR reasoning is restricted to that.
SCSR reasoning seeks for operation combinations which satisfy the following three requirements: Firstly, within the available operations of the chosen SRSubjects, there are coherent/equivalence matches between their SRPreConditions and SRPostConditions from one to another (empty condition, like “unconditional”, is not accounted here). Secondly, all of the SRParameters (if any) of such operations are presented in prior simultaneously. Thirdly, the real-time service (entity) condition meets the SRPreCondition of the first operation (in the chain). Fourthly, any duplicate/repeated operation is to be eliminated from the chain. Finally, these dynamically composed operation chains are arranged, where users can select and execute them depending on their intension.
Interactive Orchestrated Service Operation Request (IOSR) assistance reasoning
With a successfully executed service operation, the SROutcome retrieved in real-time can be used as SRParameter for further service operations. This provides another means towards dynamic service (operation) orchestrations. IOSR is designed to provide operation orchestration assistances that require minimum user effort. It can intelligently select and compose all necessary operations, and automatically prepare the SRPreConditions and SRParameters for relevant service interaction tasks. Hence, IOSR assisted operation tasks only ask users for SRSubjects entry and require no further user interventions.
In order to provide the assistance with proactive condition and parameter preparation, IOSR reasoning algorithm does not simply consider the exact match between operations’ SROutcome and SRParameter or between SRPreCondition and SRPostCondition. Instead, it checks the equivalence of SROutcome and SRParameter entities. As long as there is no direct conflict between the SRPreCondition and SRPostCondition, a link can be formed (for certain valid interaction intentions). Indeed, whenever there are commonly recognizable service and resource entities, they can result in “orchestration points” between the interactive pair of clouds, regardless of their CSPs or service types.
This section outlines the implementation in terms of the deployment of cloud service access and manipulation ontology (CSAMO) and system prototype tool (USAMS). Moreover, for real cloud service management enablement, details of cloud service operation API mapping are presented, as a key component of the prototype.
CSAMO is deployed based on SAMOS framework. It encapsulates various real cloud service operation specification data, written in OWL 2 . While CSAMO is utilized as the main knowledge source for cloud service operations, the User Accounts & Profiles database used here stores users’ cloud service account data (including CSP API credentials). This is mandatory for most service operations over different clouds.
Specification Interpreter is responsible for retrieving and translating granular service operation and entity specifications and the respected API request and response data. This includes interpreting all sorts of cloud service entities in SIR and SMR operations, plus gathering the entire operation element details (i.e. SRPreCondition, SRParameter, SROutcome, etc.).
Service Entity & Operation Mapping Manager manages the operation API mapping entries so that users’ service operation requests can be implemented properly. It has two separate mappers inside for use of SIR and SMR operations respectively. Indeed, due to the many different characteristics between the two operation categories, the operation handling processes are treated separately. This prevents potential issues as attempting to schedule a group of mixed operation tasks.
USAMS UI deals with a wide range of service operation execution tasks by providing a unified portal for real-world cloud service access and manipulation. It has two sub components: Unified Service Access and Manipulation Portal and Service Operation Reasoning Assistance. While the former allows users view and execute various service operations, the latter actively assists users for advanced operation execution tasks. Together, these enable a generic and interactive portal for service access, manipulation and interaction regardless of service models/types/CSPs.
Service Operation Reasoning Engine incorporates four individual reasoners, each works for a certain operation assistance scenario. BASR Reasoner assists in preparation of the required operation data so as to guide users throughout operation process. The scale of its reasoning is restricted to operations in a single cloud. CCSR Reasoner assists in grouping similar operations for users so as to enable simultaneous executions, even if such are implemented across distinct clouds. SCSR Reasoner assists in scheduling chained tasks when a series of operation are found with certain execution dependency relations one another. Finally, IOSR Reasoner assists in implementing service orchestration tasks by analyzing the possibilities for potential operation interactions for selected services.
Service Operation Scheduler acts to control the schedule and execution of operation tasks. Whenever a user initiates an operation, the component would first verify the user’s API credentials (for the target cloud). Then, the necessary data format verifications (for SRParameter and SRPreCondition) are performed. If no error occurs, the mapped operation task will be executed execution. Further, for advanced service operation tasks, the component works closely with Service Operation Reasoning Engine, enabling the tasks reasoned by the reasoners. With its internal Dynamic Service Condition Checker, it provides various automatic dynamic scheduling controls for grouped SIR and SMR tasks. For every SMR operations executed, the logs are forwarded to Logging Controller.
Logging Controller documents critical system and operation logs so that users can examine them as required. This enables event tracking, diagnostics and performance evaluation tasks via the platform.
Mapping service operation ontology specifications to service API calls
Nowadays, most cloud service providers also release native service API libraries and/or complete SDKs as customized service and resource control interfaces. Meanwhile, a series third-party service APIs are also available as an alternative programmable service and resource entrance. In fact, these service API call/respond operations often enable more effective service access and enhanced service function manipulation, since they allow users to control services and relevant resources from a much lower level .
As the mapping between service operation specifications and API calls is established, the modelled cloud service operations can be prepared and executed (with relevant cloud API user account credentials) as retrieved.
To demonstrate the practice use and to evaluate the proposed approach, we present some case studies on service operation specifications and service access, manipulation and orchestration tasks, using a series of services from multiple popular clouds. In addition to the contents presented below, more specifications for other cloud services and providers are provided in Appendices A: Table 8, B: Table 9 and C: Table 10.
EC2 service operation specifications
EC2 service/CSI/PSSA operation specifications (from CSAMO)
Cloud Service Level Operations
List VM Instance
Create VM Instance(s)
< account allowance, i.e. 20 instances per region
EC2 RequestCount(O), EC2 InstanceType(M), EC2 AMIID(M), EC2 KeyName (M), EC2 SecurityGroup(O), EC2 Region(M), EC2 Monitor(O), EC2 AvailabilityZone (O), etc.
Instance(s) is in “running” state
Instances are in “stop” state
EC2 InstanceIDs(M), EC2 InstanceTypes(M)
Instances are in “stop” state
CSI Level Operations
AWS EC2 Instance
Get VM Architecture
EC2 Instance Architecture
Create VM Image
AMI is in “available” state
Terminate VM Instance
Instance is NOT in “terminated” state
Instance is in “terminated” state
PSSA Level Operations
AWS EC2 AMI (VM image)
Get Image Platform
EC2 Instance Platform
Create VM Instance(s)
< account allowance, i.e. 20 instances per region
EC2 InstanceID(M) EC2 RequestCount(M), EC2 InstanceType(M), EC2 KeyName (O), EC2 SecurityGroup(O), EC2 Monitor(O), etc.
Instance(s) is in “available” state
Image is in “available” state
Further, the detailed operation elements can be well presented with SAMOS. For instance, basic SIRs such as “List VM Instance” and “Get VM Architecture”, they do not require any SRPreCondition and only require a single SRParameter (each); they would not trigger any SRPostCondition change after execution. In contrast, SMRs act differently: they would alter certain service/CSI/PSSA conditions on successful execution, and may require several SRParameters (e.g. “Create VM Instance(s)”). Additionally, even for the same operation, the specifications can differ for distinct SRSubjects: the two “Create VM Instance(s)” executable for EC2 and EC2 AMI appear to be very similar, except that one requires fewer SRParameters than the other.
Unified cloud service access and manipulation
Every SRSubject is initially displayed in a small panel. There are four buttons in the panel: “Description”, “Use Entity”, “Information” and “Manipulation”. By clicking “Description”, users can view its annotation description through external knowledge sources . “Information” and “Manipulation” buttons lead to the respected SIR and SMR operation retrieval (from CSAMO). Then, if a user’s API account authorization permits, one can execute operations via USAMS.
Due to the simple nature, SIR operations are executed concurrently as the user clicks the “Refresh” button aside. SMR operations are to be executed individually; they would only execute when the all of the requirements (i.e. SRPreCondition and SRParameter(s)) are satisfied, which are checked dynamically by relevant USAMS components. To enhance operation parameter input experience, all dynamically acquired service entity (information) can be reused as parameters.
In addition, for any CSI or PSSA acquired through SIR operations, their operation panels can be called from a click (see Fig. 8). Afterwards, the remaining options follow the same steps as the above. In this way, USAMS achieves a unified service access and manipulation through a common presentation and execution interface, regardless of the CSP, service or operation types.
Cloud service operation reasoning assistance: IOSR
As previously discussed, an additional benefit of SAMOS framework is its operation reasoning assistance. Here, we present an IOSR assistance case on orchestrating EC2 and Rackspace Cloud Load Balancer (RSLB) .
The case validates that IOSR execution process runs intelligently on operation condition and parameter preparation: for SRPreCondition fulfillment, it adds the “start VM” operation at the beginning of the chain due to the “has IP” needing such condition requirement; for SRParameter fulfilment, the IP address is not manually entered but a dynamic real-time service entity acquired form CSP.
Service operation remote execution performance
The cloud service operation execution performance study involves a variety of services and operations from multiple clouds. We provide operation execution time comparisons between USAMS and provider native command line interfaces (CLI). To deal with the test data deviations (e.g. due to unexpected/slight QoS fluctuation), the results are regulated: the operation tests are conducted on two separate days; the results are obtained from several sample tests, where any excessive values are eliminated.
The services selected for the operation experiment are EC2, Relational Database Service (RDS) , Elastic Load Balancer , Cloud Servers , Cloud Databases  and Cloud Load Balancers . They belong to AWS and Rackspace two CSPs respectively. Accordingly, the two CLIs involved in the experiment are AWS CLI  and Rackspace CLI (rumm ). For SIR, a series of service instance data retrieval operations are tested to justify the typical performances for IaaS, PaaS and SaaS operations individually. For SMR, various service instance manipulation operations are tested, including instance creation, deletion, updating, etc.
SIR(s) remote execution performance
Single SIR access time comparison (via native CLI/USAMS)
List cloud VM instances (IaaS)
List cloud database instances (PaaS)
List cloud files (SaaS)
List cloud load balancers (SaaS)
Success rate (based on 200 tests)
Via native CLI
Via native CLI
SMR(s) remote execution performance
The SMR operations selected for the experiment are IaaS and SaaS service instance creation, modification and termination tasks. Specifically, the IaaS VM creation operations are deployed with plain Linux Red Hat 7.0 image on m3.large (2vCPU/7.5GB RAM) for EC2 and 4GB standard instance (2vCPU/4GB RAM) for Rackspace Cloud Servers. Then, the instances created are used for the termination tests. Meanwhile, the SaaS cloud load balancer creation and update operations are performed by creating an http load balancer, followed by node adding modifications.
Single SMR execution time comparison (via native CLI/USAMS)
Create cloud VM instance (IaaS)
Terminate cloud VM instance (IaaS)
Create cloud load balancer (SaaS)
Update cloud load balancer (SaaS)
Success rate (based on 200 tests)
Via native CLI
Via native CLI
Evaluation and discussion
Cloud service specification framework comparison
Model core/Base concepts
Category, Kind, Mixin, Resource Instantiation, Collections, Discovery/Entity, Resource, Link, Action) 
Testing tool, doyouspeak OCCI,OCCI API
Topology Templates, Plans/Service, Node, Relationship, Requirement, Capability, Artifact, Policy, Cloud Service Archive 
OpenTOSCA, jclouds and PyTosca API
Environment, Infrastructure, Resource, Runtime Component, Stateful Component, Stateless Component, etc. 
mOSAIC Cloud Agency
Entity and operation classifications, Entity datatype specifications, Entity operational relationship Specifications, etc.
USAMS prototype tool, flexible choice of API libraries via OCSO API
Lightweight automatic reasoning
Meanwhile, the performance evaluation with USAMS covers a wide range of typical service operations. Obtained experiment results illustrate some performance differences between the proposed approach and provider-native CLIs. For SIR operation handling performance, the prototype demonstrates the same solid success rates regardless of the type/nature of operations, although there are some minor processing overheads. Considering SMR operation tasks, USAMS demonstrates competitive performance in comparison with the native CLIs. There is no obvious delay or distinction for many service management tasks involved. In fact, the slight overheads are caused by two main factors: the API libraries (AWS Java SDK version 1.8.3 and jclouds Rackspace API libraries version 1.7.0) used (by OCSO) decide the main processing time; USAMS components also consume minor extra time while processing the obtained data, preparing for the operations and other additional tasks. In overall, USAMS enables reliable cloud service remote management with acceptable performance. The proposed approach offers a more flexible and intelligent remote management solution than individual portals of vast cloud service providers.
Conclusions and future work
This paper proposes a cloud service operation specification approach which can be applied to diverse cloud service models and resource types, namely SAMOS. The framework can reveal comprehensive information with regard to the involved service entities, their attributes and relationships, plus a series of operational elements including parameters, conditions and outcomes. The ontological modelling approach also enables a range of operation reasoning which can provide assistances for advanced tasks such as simultaneous, chained and service orchestration operations.
To evaluate the proposed approach, CSAMO semantic model and USAMS prototype are implemented. Together, they enable a unified cloud service access and manipulation via a structured management interface. This is validated through considerable experiments that are conducted over Amazon and Rackspace IaaS, PaaS and SaaS clouds. The test results suggest that the proposed approach can provide competitive service operation reliability and effectiveness, especially while handling groups of operation tasks.
In future work, we plan to extend the approach by introducing service recommendation engine and service interaction agent. The recommendation module should enable more user friendly service selection and operation experiences. The service interaction agent would drive more effective service compositions with enhanced operation reasoning applications.
We wish to thank British Royal Society of Edinburgh (RSE-Napier E4161) and Lawrence Ho Research Fund (LH-Napier2012) for supporting the work presented. We acknowledge the support from a joint grant by the British Royal Society and the Royal Irish Academy on a Cloud Migration Framework 2014–2016 (IE131105) and Science Foundation Ireland grant 13/RC/2094 to Lero - the Irish Software Research Centre (www.lero.ie).
- Marinescu DC (2013) Cloud computing: theory and practice. Elsevier, Waltham. USA, pp 2–17Google Scholar
- Buyya R, Vecchiola C, Thamarai S (2013) Master cloud computing: foundations and applications programming. Elsevier, Waltham. USA, pp 3–27View ArticleGoogle Scholar
- Orozco JMS (2012) Applied ontology engineering in cloud services, networks, and management systems. Springer Science + Business Media:23–52Google Scholar
- Moreno-Vozmediano R, Montero RS, Llorente IM (2011) Key challenges in cloud computing: enabling the future internet of services. IEEE Internet Computing 17(4):18–25View ArticleGoogle Scholar
- Apache Jclouds. http://jclouds.apache.org/. Accessed 30 Jul 2014
- Apache Libcloud. https://libcloud.apache.org/. Accessed 12 Aug 2014
- Fog. http://fog.io/. Accessed 02 Aug 2014
- TOSCA Overview. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca#overview. Accessed 27 May 2014
- Moscato F, Aversa R, Martino BD, Venticinque S (2011) An ontology for the cloud in mOSAIC. Cloud Computing: Methodology, System, and Applications. CRC Press:467–485Google Scholar
- OCCI. http://occi-wg.org/. Accessed 31 Jul 2014
- Toosi AN, Calheiros RN, Buyya R (2014) Interconnected cloud computing environments: challenges, taxonomy, and survey. ACM Computeing Surveys 47(1):7Google Scholar
- Loutas N, Peristeras V, Bouras T, Kamateri E, Zeginis D, Tarabanis K (2010) Towards a Reference Architecture for Semantically Interoperable Clouds. IEEE 2nd International Conference on Cloud Computing Technology and Science (CloudCom)., pp 143–150Google Scholar
- Demchenko Y, Ngo C, de Laat C, Rodriguez J, Contreras LM, Garcia-Espin JA, Figuerola S, Landi G, Ciulli N (2013) Intercloud Architecture Framework for Heterogeneous Cloud based Infrastructure Services Provisioning On-Demand. IEEE International Conference on Advanced Information Networking and Applications Workshops (WAINA). p 777–784Google Scholar
- Deltacloud. https://deltacloud.apache.org/. Accessed 22 May 2014
- Fielding R (2000) Architectural Styles and the Design of Network-based Software Architectures. https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf. Accessed 16 April 2015
- The Dasein Cloud API. http://dasein-cloud.sourceforge.net/. Accessed 26 Jun 2014
- Bastião Silva LA, Costa C, Oliveira JL (2013) A common API for delivering services over multi-vendor cloud resources. J Systems and Software 86(9):2309–2317View ArticleGoogle Scholar
- Petcu D, Craciun C, Neagul M, Lazcanotegui I, Rak M (2011) Building an interoperability API for Sky computing. International Conference on High Performance Computing and Simulation (HPCS). p 405–411Google Scholar
- Bernabe JB, Marin Perez JM, Alcaraz Calero JM, Garcia Clemente FJ, Perez GM, Gomez Skarmeta AF (2014) Semantic-aware multi-tenancy authorization system for cloud architectures. Future Gener Comput Syst 32:154–167View ArticleGoogle Scholar
- Amazon EC2 User Guide. http://awsdocs.s3.amazonaws.com/EC2/latest/ec2-ug.pdf. Accessed 17 May 2014
- Federici C (2014) Cloud data imager: a unified answer to remote acquisition of cloud storage areas. Digit Investig 11(1):30–42View ArticleGoogle Scholar
- Povedano-Molina J, Lopez-Vega JM, Lopez-Soler JM, Corradi A, Foschini L (2013) DARGOS: a highly adaptable and scalable monitoring architecture for multi-tenant Clouds. Future Gener Comp Syst 29(8):2041–2056View ArticleGoogle Scholar
- Li Q, Wang Z, Li W, Cao Z, Du R, Luo H (2013) Model-based services convergence and multi-clouds integration. Computer in Industry 64(7):813–832View ArticleGoogle Scholar
- OWL 2 Web Ontology Language Document Overview. http://www.w3.org/TR/owl2-overview/. Accessed 23 Dec 2013
- Fang D, Liu X, Liu L, Yang H (2014) OCSO: Off-the-cloud service optimization for green efficient service resource utilization. J Cloud Computing 3(9). http://www.journalofcloudcomputing.com/content/3/1/9. Accessed 17 Aug 2014
- Fang D, Liu X, Romdhani I (2014) A Loosely-coupled Semantic Model for Diverse and Comprehensive Cloud Service Search and Retrieval. The Fifth International Conference on Cloud Computing. pp 6-11
- Rackspace Cloud Load Balancers Developer Guide. http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/clb-devguide-latest.pdf. Accessed 19 June 2015
- Amazon Relational Database Service User Guide. http://awsdocs.s3.amazonaws.com/RDS/latest/rds-ug.pdf. Accessed 02 May 2014
- Amazon Elastic Load Balancing Developer Guide. http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-dg.pdf. Accessed 16 Sep 2014
- Rackspace Next Generation Cloud Servers Developer Guide. http://docs.rackspace.com/servers/api/v2/cs-devguide/cs-devguide-latest.pdf. Accessed 19 June 2015
- Rackspace Cloud Database Developer Guide. http://docs.rackspace.com/cdb/api/v1.0/cdb-devguide/cdb-devguide-latest.pdf. Accessed 06 May 2014
- AWS Command Line Interface User Guide. http://docs.aws.amazon.com/cli/latest/userguide/aws-cli.pdf/. Accessed 03 Jun 2015
- Rackspace rumm. http://rackspace.github.io/rumm/. Accessed 03 Jun 2015
- AWS Elastic Beanstalk API Reference. http://s3.amazonaws.com/awsdocs/ElasticBeanstalk/latest/awseb-api.pdf. Accessed 16 April 2015
- Open Cloud Computing Interface – Core. https://www.ogf.org/documents/GFD.183.pdf. Accessed 21 Dec 2014
- Topology and Orchestration Specification for Cloud Applications Version 1.0. http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html. Accessed 22 Nov 2014
- Moscato F, Aversa R, Di Martino B, Fortis T, Munteanu V (2011) An analysis of mOSAIC ontology for Cloud resources annotation. Federated Conference on Computer Science and Information Systems (FedCSIS). p 973–980Google Scholar
This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly credited.