Service-Oriented Cloud Computing Architecture
Wei-Tek Tsai*, Xin Sun, Janaka Balasooriya
Department of Computer Science
Arizona State University
Tempe Arizona 85281 USA
Department of Computer Science and Technology, Tsinghua University, Beijing, China*
{wtsai, xin.sun, janaka}@asu.edu
Abstract
Cloud computing is getting popular and IT giants such as
Google, Amazon, Microsoft, IBM have started their cloud
computing infrastructure. However, current cloud
implementations are often isolated from other cloud
implementations. This paper gives an overview survey of
怎么炸油饼
current cloud computing architectures, discuss issues that
current cloud computing implementations have and propos a
Service-Oriented Cloud Computing Architecture (SOCCA) so绿霸王
that clouds can interoperate with each other. Furthermore, the SOCCA also propos high level designs to better support multi-tenancy feature of cloud computing.
1.Introduction
米面的做法
Clouds have emerged as a computing infrastructure that enables rapid delivery of computing resources as a utility in a dynamically scalable, virtualized manner. The advantages of cloud computing over traditional computing include: agility, lower entry cost, device independency, location independency, and scalability [1].
There are many cloud computing initiatives from IT giants such as Google, Amazon, Microsoft, IBM as well as startups such as Parascale [2], Elastra [3] and Appirio [4]. However, there exist many different interpretations of what cloud computing is. This paper attempts to establish the connections between SOA and cloud computing by prenting related issues, and propos a Service Oriented Cloud Computing Architecture (SOCCA).
This paper is organized as the follows: Section 2 provides a brief survey on cloud computing hierarchy; Section 3 prents a survey on existing cloud computing architectures and their issues; Section 4 propos the SOCCA; Section 5 shows an initial prototype and experiment; Section 6 concludes this paper.
2.A Survey on Cloud Computing
2.1.A Hierarchical View of Cloud Computing
Most of the current clouds are built on top of modern data centers. It incorporates Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), and provides the rvices like utilities, so the end urs are billed by how much they ud. Figure 1 shows a hierarchical
view for cloud computing.
Figure 1: Hierarchical View of Cloud Computing
Data Centers: This is the foundation of cloud computing which
provides the hardware the clouds run on. Data centers are
usually built in less populated areas with cheaper energy rate
and lower probability of natural disasters. Modern data centers
usually consist of thousands of inter-connected rvers.
Infrastructure as a Service: Built on top of data centers layer,
IaaS layer virtualizes computing power, storage and network
connectivity of the data centers, and offers it as provisioned
rvices to consumers. Urs can scale up and down the
computing resources on demand dynamically. Typically,
multiple tenants coexist on the same infrastructure resources [1].
Examples of this layer include Amazon EC2, Microsoft Azure
Platform.
Platform as a Service: PaaS, often referred as cloudware,
provides a development platform with a t of rvices to assist
application design, development, testing, deployment,
monitoring, hosting on the cloud. It usually requires no
software download or installation, and supports geographically
distributed teams to work on projects collaboratively. Google
App Engine, Microsoft Azure, Amazon Map Reduce/Simple
Storage Service are among examples of this layer.
Software as a Service: In SaaS, Software is prented to the
end urs as rvices on demand, usually in a browr. It saves
the urs from the troubles of software deployment and
maintenance. The software is often shared by multiple tenants,
automatically updated from the clouds, and no additional licen
needs to be purchad. Features can be requested on demand,
and are rolled out more frequently. Becau of its rvice
characteristics, SaaS can often be easily integrated with other
mashup applications. An example of SaaS is Google Maps, and 2010 Seventh International Conference on Information Technology
its mashups across from the internet. Other examples and Zoho productivity and collaboration suite. The dividing lines for the four layers are not distinctive. Components and features of one layer can also be considered to be in another layer. For example, data storage rvice can be considered to be either in as IaaS or PaaS. Figure 1 suggests a hierarchical relationship among the different layers; however, it does not mean the upper layer has to be built on top its immediate lower layer. For example, a SaaS application can be built directly over IaaS, instead of PaaS.
In the cloud computing environment, everything can be implemented and treated as a rvice. Figure 1 shows a few examples of what can be treated as a rvice in different layers.
3.Existing Cloud Computing Architectures
Both academia and industry have been active on cloud computing rearch, and veral cloud computing architectures have been propod. In [5], IBM considers current single-providers cloud as limited resource, and the lack of interoperability among cloud providers prevents deployment across different clouds. A cloud computing architecture named Rervoir was propod to create a federation from multiple cloud providers which acts as a global fabric of resources that can guarante
南极洲英文
e the required SLA. In Rervoir architecture, the computational resources within a site are partitioned by a virtualization layer into virtual execution environments (VEEs).
A rvice application is decompod into a t of software components/rvices running on VEEs on the same or different VEEs within a site or across from different sites. However, Rervoir architecture does not allow a component/rvice to run on its duplicates on different VEEs; Moreover, computing resources are abstracted as hosting rvice which might not be necessarily true for all clouds. In [6], a software platform for bad cloud computing named Aneka was introduced. Aneka is a customizable and extensible rvice oriented runtime environment that enables developers to build applications with the supports of APIs and multiple programming models. Aneka is a rvice-oriented, pure PaaS cloud solution. In [7], Rajkumar and his colleagues explained a market-oriented cloud architecture in detail ud by Aneka, which regulates the supply and demand of cloud resources to achieve market equilibrium, adds economic incentives for both cloud consumers and providers, and promotes QoS-bad resource allocation mechanisms that differentiates rvice request bad on their utility. The key component of this architecture is SLA (Service Level Agreement) Resource Allocator which is consisted of Service Request Examiner and Access Control, VM (Virtual Machines) monitor, Service Request Monitor, and Request Dispatcher.
Bad on the feedback from VM and Service Request monitors, the dispatcher routes the requests from urs/brokers to the cloud resources that can fulfill their QoS requirements. In [8], Huang and her colleagues from IBM described a rvice oriented cloud computing platform that enables web-delivery of application-bad rvices with a t of common business and operational rvices. The platform supports multi-tenancy feature by utilizing single application instance model. The isolation among tenants is taken care by the underline design. Other rvices include subscription management, federated ID management, application firewall, etc.
3.1.Issues with Current Clouds
Current cloud computing has following characteristics:
Urs are often tied with one cloud provider: Even though up-front cost for a cloud computing deployment is reduced and long term lea is eliminated, much effort and money is spent on developing the application for a specific cloud platform which makes it difficult to migrate the same application onto a different cloud. Often, migration simply may mean redevelopment. For example, applications deployed on Amazon EC2 cannot be migrated easily due its particular storage framework [9].
Computing components are tightly coupled: This can be clearly explained using an analogy. Suppo one wants a new computer, this person has the choices of either buying a ready-
to-u computer from a manufacturer (buying) or purchasing the components parately and building the computer in a DIY style (building). The advantages of building over buying include wider lection of components, flexibility to customize, and cheaper cost [10]. However, as the computing resources over the internet, current cloud implementations do not allow this kind of flexibility. If a customer opts to u Amazon S3 storage rvice, he is then stuck with other cloud computing rvices Amazon provides, such as EC2, Elastic Map Reduce.
Lack of SLA supports:Currently, SLA is an obstacle that prevents wide adoption for cloud computing. Cloud computing infrastructure rvices such as EC2 are not yet able to sign the SLA needed by companies that want to u cloud computing for rious business deployment [11]. Moreover, business is dynamic. Static SLA is not able to adapt to the changes in business needs as cloud computing promis to.
Lack of Multi-tenancy supports: Multi-tenancy can support multiple client tenants simultaneously to achieve the goal of cost effectiveness. Currently, one has three types of multi-tenancy enablement a
pproaches: virtualization, mediation and sharing [12]. To achieve the full potential of multi-tenancy, three issues remain to be solved [12]:
1. Resource sharing: To reduce the hardware, software and management cost of each tenant.
2. Security isolation: To prevent the potential invalid access, conflict and interference among tenants.
3. Customization: To support tenant-specific UI, access control, process, data, etc.
Lack of Flexibility for Ur Interface:UI is an important part of the application, and ur experience can be a major evaluation factor for a business application. However, cloud/SaaS urs are limited with UI choices becau UI composition frameworks, such as the one propod in [13], have not been integrated with cloud computing.
4.Service Oriented Cloud Computing
Architecture (SOCCA)
4.1.Cloud Computing and SOA
SOA and cloud computing are related, specifically, SOA is an architectural pattern that guides business solutions to create, organize and reu its computing components, while cloud computing is a t of enabling technology that rvices a bigger, more flexible platform for enterpri to build their SOA solutions. In other words, SOA and cloud computing will co-exist, complement, and support each other.
There have been veral initiatives at attempting bridging SOA and cloud computing. Noticeably, the works in [6] [8] have more rvice-oriented features than the other mentioned in ction 3.
Figure 2: Service-Oriented Cloud Computing Architecture
4.2.Layered Architecture of SOCCA
企鹅的故事Our SOCCA is a layered architecture shown in Figure 2: Individual Cloud Provider Layer: This layer rembles the current cloud implementations. Each cloud provider builds its own data centers that power the cloud rvices it provides. Each cloud may have its own proprietary virtualization technology or utilize open source virtualization technology, such as Eucalyptus [14]. Similar to Market-Oriented Cloud Architecture propod in [7], within each individual cloud, there is a request dispatcher working with Virtual Machine Monitor and Service/App Governance Service to allocate th
e requests to the available recours. The distinction from current cloud implementations is that the cloud computing resources in SOCCA are componentized into independent rvices such as Storage Service, Computing Service and Communication Service, with open-standardized interfaces, so they can be combined with rvices from other cloud providers to build a cross-platform virtual computer on the clouds. In order to achieve maximum interoperability, uniform standards need to be implemented. For example, SQL is de facto standard for RDBMS data management, and many databa vendors have their own implementations. A cloud version of SQL needs to be defined, so data manipulation logic of an application that works on one cloud can also work other clouds. A distributed computing framework standard to unify all different implementations of Map/Reduce is also in need for the same reason.
Cloud Ontology Mapping Layer: Cloud providers might not conform to the standards rigidly; they might also have implemented extra features that are not included in the standards. Cloud Ontology Mapping Layer exists to mask the differences among the different individual cloud providers and it can help the migration of cloud application from one cloud to another. Several important ontology systems are needed:
1. Storage Ontology: It defines the concepts and terms related to data manipulation on the clouds, s
uch as data update, date inrt, data delete, and data lect, etc.
2. Computing Ontology: It defines the concepts and terms related to distribute computing on the clouds, such as Map/Reduce Framework.
3. Communication Ontology: It defines the concepts and terms related Communication Schema among the clouds, such as data encoding schema, message routing.
Cloud Broker Layer: Cloud brokers rve as the agents between individual cloud providers and SOA layer. Each major cloud rvice has an associated rvice broker type. Generally, cloud brokers need to fulfill the following tasks:
1. Cloud Provider Information Publishing: Individual cloud providers publish specifications and pricing info to the cloud brokers. Important provider information includes:
Cloud Provider Basic Information: Company Name, Company Address, Company Website, Company Contact Info, etc. Resource Type and Specifications: Whether it is computer/storage/communication resource and its specification and limitation. For example, for the data storage rvice, the data transmission rate can be as high as 2Gb/s.
Pricing Information: How the rvices charge. This varies the most among different cloud providers. For example, currently, Google does not charge for the first 500MB storage, and $0.15 per GB of data after, while Amazon charges $0.11 per GB-month for its EBS Volumes rvice. Even within a cloud provider, the pricing info might change as the market’s dynamic changes.
2. Ranking: Like the rvice brokers in SOA, cloud brokers also rank the cloud resources published. Services can be ranked
cool是酷的意思吗
in veral categories such as price, reliability, availability, and curity, etc. Ranking can be achieved through ur voting or historical rvice governance records.
3. Dynamic SLA Negotiation: Business is often dynamic, and the IT infrastructure has to be adaptive to accommodate the business needs, therefore to achieve the optimal ROI (Return of Investment). It’s often the ca that the IT resources a business demands can be predicted. Cloud rvice brokers can help cloud urs and cloud providers negotiate on a SLA dynamically.
4. On-Demand Provision Model: Most rvices experience asonal or other periodic demand variation as well as some unexpected demand bursts due to external events. The only way
to provide “on-demand” rvices, is to provision for them in advance. Accurate demand prediction and provision become critical for the successful of the cloud computing, which reduces the waste of utility purcha and can therefore save money using utility computing. We are investigating a demand prediction model and model the evolution of multi-tenant as a discrete time stochastic process. We have investigated veral macroeconomic factors in a real mortgage rvice platform [15][16], and the initial results show that the underlying stochastic process may depend on a number of external factors such as macroeconomic variables, as well as rvice internal features. Some analysis results from real applications demonstrate the effectiveness of our models. Due to the space limitation, more details can be found in [15]. Specifically, the process needs to answer the following question: What is the forecast of tenant m days into the future? How to predict the workload distribution at different rvices? How to optimize the rvice provision process and minimize customers' dissatisfaction?
SOA Layer: This layer fully takes the advantages of the existing rearch and infrastructure from traditional SOA. Many existing SOA frameworks, such as CCSOA [17], UCSOA [18], GSE [19] and UISOA [13] can be integrated into this layer. Figure 2 shows a possible SOA layer for SOCCA. Similar to CCSOA, not only rvices but also many other artifacts can be published and shared, suc
h as workflow templates, collaboration templates and test cas. The registry for each type of artifacts is indexed and organized by its according ontology. The fundamental difference of the SOA layer of SOCCA from traditional SOA is that the rvice providers no longer host the published rvices anymore. Instead, they publish the rvices in deployable packages, which can be easily replicated and redeployed to different cloud hosting environments. Application developers can decide which clouds they want to the rvices to run bad a t of criteria. The details will be discusd in ction 4.4. Another major improvement is multi-tenancy support that allows more flexibility, which will be discusd in ction 4.3. SOA layer of SOCCA allows more flexibility than traditional SOA; it further parates the roles of rvice providers and cloud providers, and the rvice logics and its running environments.
4.3.Multi-tenancy Architecture (MTA)
As shown in Figure 2, SOCCA allows 3 different main multi-tenancy patterns. In [8], the authors discusd the left two multi-tenancy patterns: Multiple Application Instance (MAI) and Single Application Instance (SAI). The authors pointed out, the former does not scale as well as the latter, but it provides better isolation among different tenants. Within SOCCA, a new multi-tenant pattern becomes possible: Single Application Instance and Multiple Service Instances (SAIMSI). The motivat
ion behind this pattern is that the workloads are often not distributed evenly among application components, and the performance of the single application instance is limited by the application components having lower throughput. Moreover, to enhance scalability, we want to reduce unnecessary duplications as much as possible as oppod to Multiple Application Instances pattern. Figure 3 shows a simplified example. The example application is compod by A, B, C, three rvices with C being the computing intensive component. With C being the bottleneck to support multiple tenants, 3 instances of C are created to balance the workloads. Note that the 3 instances of the rvices can also reside on different clouds.
Better scalability is not only benefit from the SAIMSI pattern, easy customizability is another gain. Suppo in the sample application, C is a payment rvice. Different tenants might have different payment method requirements, such as credit card, Paypal, or check. The application runtime environment (not described in this paper) will direct urs of each tenant to the correct rvice instance according to tenants’
individual configuration. In the ca that a future tenant has a payment requirement that cannot be met by the existing rvice instances, say money order, an according rvice instance can be easily plugged into the existing rvice instances group. The upcoming papers on multi-tenancy from our r
earch group will provide more details on this topic.
Figure 3: Single Application Instance Multiple Service
Instances
4.4.Application Development on SOCCA
4.4.1.Service Package
Service providers of traditional SOA develop the logic of a rvice and provide its running environment. In SOCCA, rvices are published as re-deployable packages, namely rvice package. A rvice package contains the following required/ optional information and files:
Compiled Code: If rvice providers only u the standard APIs and protocols, a single version of complied code is enough; if rvice providers optimize the performance of their rvices by utilizing some platform unique APIs and features, complied code for each platform is needed.
Source Code: This is optional. It is uful to help its ur to understand the rvice better, also gives the freedom to its urs to tweak the rvices to accommodate their specific requirement.
Configuration File:Services might u external basic rvices. For example, a computing intensive scientific rvice which also us a lot of storage might deploy its computing logic on a cloud that provides high performance computing power, but u the cheaper storage rvice provided by another cloud. This requires a configuration file which specifies the external rvice’s locations, partner link, etc. This can also be achieved in a BPEL manner, however, since basic rvices such as storage rvices, have a widely adopted standards, and are frequently ud, so it is more efficient to handle in a databa connection configuration file style.
Resource Files: Any resource files that the rvice depends on, such as images, documents.
4.4.2.SOCCA Applications
Application development in SOCCA is similar to the development in CCSOA. Developers first arch if there is a workflow template that matches the requirement. A workflow template is compod of rvice stubs/specifications, which specify the functionalities and interfaces of rvices. Later a rvice stub is bound with a rvice package. Depending on the QoS requirements and the budget for the application, cloud brokers will negotiate with cloud providers on SLA, and deploy the rvice packages on one or multiple clouds. An algorithm for request dispatching for a rvice acros
s its deployments on different clouds needs to be applied. Due to the page number constraints, it will be discusd in our upcoming papers. Figure 4 shows a typical application architecture on SOCCA.
Figure 4 SOCCA Application Architecture
5.Initial Prototype and Experiment
Figure 5: Motto Application with GAE Databa
This ction shows an initial prototype and experiment to demonstrate the possibility of SOCCA.
The demonstration web application has one easy requirement: When each ur visits the web page, he/she will be greeted by a random message retrieved from a motto databa.
1. We developed the application by using Google App Engine. Note that a number of mottos are retrieved and stored from and to Google cloud by using Datastore with JDO. Figure 5 shows a screenshot of motto application running on Google App Engine.
2. We created a web rvice that wraps the Azure SQL rvice that allows retrieving and storing mottos from the motto databas deployed on Azure.
3. We utilized the Web Service Connector (WSC) tool provided by [20] to generate Google App Engine compatible client code in java to access the web rvice developed by step
2. WSC is a code-generation tool that takes a WSDL file and
generates an optimized java library that provides access to the web rvice. 4. We created a class that implements
“javax.jdo.PersistenceManagerFactory”, which is the interface GAE Datastore us to manipulate the data on the cloud.
5. We created an instance of
SQLPersistenceManagerFactory that implements
“javax.jdo.PersistenceManagerFactory”, which is the interface
GAE Datastore us to manipulate the data on the cloud. Figure
6, a code snippet, shows that depending on the config file, the
application will be connected with either GAE Datastore databa or Azure SQL databa. Figure 7 shows that after
changing the config file, the motto app is now connected with Azure SQL databa. More implementations of
PersistenceManagerFactory can be added.
Figure 6: Code snippet for Databa Service Configuration
Figure 7: Motto App with Azure Databa
The prototype demonstrates that a rvice package deployed on one cloud can be configured to collaborate with rvices from other clouds. However, it does not show that a rvice package can be redeployed on a different cloud and the instances for the same rvices can live on multiple clouds. This is due to that currently, different clouds support different language ts, and there is no powerful modeling language to support developments for multiple platforms. We are currently developing this feature using a modeling language PSML [21].
6. Conclusion
This paper propod a rvice-oriented cloud computing architecture SOCCA that allows an application to run on different clouds and interoperate with each other. The SOCCA is a 4-layer architecture that supports both SOA and cloud computing. SOCCA supports easy application migration from one cloud to another and rvice redeployment to different clouds by parating the roles of rvice logic provider and rvice hosting/cloud providers. It promotes an open platform on which open standards, ontology are embraced. The paper also introduced related topics for future rearch, such as rvice demand prediction and SLA negotiation, and rvice request dispatching algorithms. More work will also be conducted to devi the ontology systems needed for a working SOCCA, and a prototype with all features discusd.
7. References [1]Wikipedia - Cloud Computing. [Online].
en.wikipedia/wiki/Cloud_computing [2]Parascale. [Online]. / [3]Elastra. [Online]. /
[4]Appirio. [Online]. / [5]Rochwerger B et al., "The RESERVOIR Model and Architecture for," IBM Systems Journal , 2009.
[6]Christian Vecchiola, Xingchen Chu, and Rajkumar Buyya, "Aneka: A Software Platform for-bad Cloud Computing," in High Speed and
Large Scale Scientific Computing , 2010. [7]Rajkumar Buyya and Chee Shin Yeo, "Cloud Computing and Emerging
IT Platforms: Vision, Hype, and Reality for Delivering Computing as the
5th Utility," Future Generation Computer Systems , pp. 599-616, 2009. [8]Ying Huang et al., "A Framework for Building a Low Cost, Scalable and
魔音面条Secured Platform for Web-Delivered Business Services," , 2009.
[9]Bernard Golden. (2009, January) Computer World. [Online].
ud_computing_part_one
[10]Mark Kyrnin. [Online]. /od/general/a/BuildvsBuy.htm
[11]Galen Moore. (2009, Jan) Mass High Tech. [Online].
/stories/2009/01/05/weekly10-Cloud-computings-SLA-obstacles-clear-in-2009.html
[12]Bo Gao, Changjie Guo, Zhihu Wang, Wenhao An, and Wei Sun. (2009,
March) Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 3: Resource sharing, isolation and customization in the single instance multi-tenant application. [Online]. /developerworks/webrvices/library/ws-multitenant/index.html
[13]Wei-Tek Tsai, Qian Huang, Jay Elston, and Yinong Chen, "Service-
Oriented Ur Interface Modeling and Composition," in International Conference on e-Busines Enginerring , Xi'an, 2008, pp. 21-28.
[14]Eucalyptus System. [Online]. /
[15]Qihong Shao et al., "Ranking Mortgage Origination Applications using
Customer, Product, Environment and Workflow Attributes.," in IEEE Proceedings of Congress on Services , 2009. [16]Wei-Tek Tsai et al., "Forecasting Loan Volumes For the Mortgage Orgination Process," , under review.
[17]W.T. Tsai, Bingnan Xiao, Ray A Paul, and Yinong Chen, "Consumer-Centric Service-Oriented Architecture: A New Approach," in SEUS-WCCIA , 2006, pp. 175-180.
[18]Mark Chang, Jackson He, W.T. Tsai, Bingnan Xiao, and Yinong Chen, "UCSOA: Ur-Centric Service-Oriented Architecture," in IEEE International Conference on e-Business Engineering , 2006, pp. 248-255.
[19]Wei-Tek Tsai, Bingnan Xiao, Ray Paul, Qian Huang, and Yinong Chen,
"Global Software Enterpri: A New Software Constructing Architecture," in International Conference on E-Commerce , 2006, pp. 55-55.
桂林独秀峰
[ [Online]. /appengine
[21]W.T. Tsai et al., "Modeling and Simulation in Service-Oriented Software
Development," Simulation , vol. 83, no. 1, pp. 7-32, 2007.
[22]C arl Osipoy, German Goldszmidt, Mary Taylor, and Indrajit Poddar.
(2009, May) Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 2: Approaches for enabling multi-tenancy. [Online]. /developerworks/webrvices/library/ws-multitenantpart2/index.html
