Longji Tang

Longji Tang

Biography

Longji Tang is a Senior Technical Advisor in FedEx IT and Professor of the School of Information Science and Engineering in Hunan University. His research focuses on software architecture and design, service-oriented architecture, service computing, cloud computing, mobile computing, big data computing, and system modeling as well as formalism. He began graduate studies at Penn State University in 1992 and graduated in 1995 with a Master of Engineering degree in Computer Science & Engineering and a Master of Art degree in Applied Mathematics. Longji started his part-time PhD studies in 2005 and obtained his PhD degree in Software Engineering in 2011. He published more than 35 research papers from data science, numeric analysis, and inverse problems to SOA, cloud, and mobile computing. He is one of members of Program Committee in 2013/2014/2015 IEEE Mobile Cloud
International Conference.

Contributions

rss  subscribe to this author

Bookmarks



Modeling and Analyzing Enterprise Cloud Service Architecture - Part I Published: January 14, 2013 • Service Technology Magazine Issue LXIX PDF

Abstract: Enterprise Cloud Computing (ECC) is a new paradigm of distributed computing. ECC enables a new business model for enterprise computing and provides a new enterprise architectural style which brings new patterns and design principles into Enterprise Architecture (EA). The enterprise service-oriented architecture (ESOA) is an enterprise architectural style which is an abstraction of concrete enterprise service-oriented architectures. The ESOA includes SOA architectural elements, service design patterns as well as principles, and SOA quality attributes. Both styles share several common goals as well as conceptual foundations and they can connect and refine each other. This paper first presents a framework for modeling architectural styles and then defines a new hybrid architectural style, Enterprise Cloud Service Architecture (ECSA), by combining and refining the ESOA and ECC. The paper also specifies the ECSA formally and informally. We further analyze the consistency, instantiation, and extension of ECSA. Several case studies are also presented.

Introduction

With the globalization of the economic environment, the increasing complexity of business processes makes the enterprise information systems complicated. Enterprise service-oriented architecture (ESOA) is designed to tackle the complexity and build better architectures and solutions for enterprises. Conceptually, the ESOA is an architectural style which defines the concrete ESOA architecture as a set of well-defined services. It may be further abstracted to process layers and composite applications for business solutions. The services are deployed and accessed through SOA infrastructures. They are governed and managed by SOA principles and management systems [REF-REF-61][REF-REF-16][REF-REF-17][REF-REF-47][REF-REF-45]. The ESOA brings the agility aspect to enterprise architectures, allowing enterprises to deal with system changes using a configuration mediation layer, rather than constantly having to redevelop these systems. However, ESOA introduces new challenges and issues to enterprise architecture because of its following characteristics:

  • The enterprise owns the data center with ESOA services but the infrastructure is not dynamic enough to support auto scaling and elastic load balancing [REF-REF-2].
  • The enterprise architecture is built behind firewalls.
  • Resources are dedicated to each workload.
  • Resources are shared only within the enterprise.

Figure 1 shows a traditional ESOA data center in which there are three layered infrastructures:

  • Web server infrastructure;
  • Enterprise application server and service infrastructure which includes application database and SOA services, application monitors and SOA application management;
  • Enterprise information storage and business service infrastructure.

All enterprise services are operating behind firewalls.

Building a data center to support ESOA architecture is expensive and it is not possible for some small to medium enterprises. For large enterprises, it is not possible to complete some complex business processes, such as online shopping and shipping, without third party services. Moreover, many server resources in a large data center are idle or passive, such as during non-peak time periods, since the plan of resources is based on the highest volume of workload. Thus, resources are wasted resulting in increasing cost of resources and operations. Many enterprises view SOA as something that only occurs within firewall. The ESOA faces new challenges from enterprises – reducing complexity as well as cost and increasing capacity, flexibility as well as agility. Leveraging cloud computing to support a new distributed computing for enterprises brings forth many new ideas, concepts, solutions, and principles to enterprise architecture and ESOA. Originally, cloud computing evolved from web computing (such as Web 2.0 [REF-REF-22]), service-oriented computing [REF-REF-51][REF-REF-52][REF-REF-61][REF-REF-47][REF-REF-17], grid computing [REF-REF-63], utility computing [REF-REF-10], and other technologies, including virtualization [REF-REF-26] and virtual applications. Cloud computing [REF-REF-56] is about moving services, computation and/or data off-site to an internal or external, location-transparent, centralized facility or contractor for cost and business advantages. By making services and data available in the cloud, it can be more easily and ubiquitously accessed, often at much lower cost, increasing its value by enabling opportunities for enhanced collaboration, integration, and analysis on a shared common platform [REF-REF-13].


img

Figure 1 - Enterprise SOA Data Center


We proposed a framework defined in terms of EWS-* substyle, for modeling ESOA styles in [REF-REF-45][REF-REF-46]. The framework is used to specify another ESOA substyle, EWOA, in [REF-REF-46]. In this paper, we extend the framework to specify general enterprise architectural styles in terms of ontology-based architectural style modeling proposed by C. Pahl, et al., in [REF-REF-41]. The framework is applied to model and analyze a new architectural style, Enterprise Cloud Service Architecture (ECSA), which is a hybrid of the ESOA and ECC styles.

The rest of this paper is organized as follows: The next section defines the extended framework. Enterprise Cloud Service Architecture specifies and analyzes ECSA based on the framework. Evaluating ECSA and Case Studies evaluates ECSA and presents several case studies to illustrate our approach for evaluating and analyzing cloud enabled service oriented enterprise architecture. Related Work reviews the related works and the Conclusions section summarizes the paper and outlines some future research directions.

Framework of Modeling Enterprise Architectural Styles

This section presents a framework of modeling enterprise architectural styles using the ontology-based modeling methodology proposed in [REF-REF-41]. The framework includes (1) enterprise architectural style (EAS) ontology and (2) EAS style syntax and semantics.

EAS Ontology

[REF-REF-41] proposed the basic architectural style ontology (ASO) based on ontology and description logic ALC language [REF-REF-7], and it presented an operation calculus for developing architectural styles. [REF-REF-41] also shows how ASO integrates with formal ADLs, such as ACME [REF-REF-21]. However, the basic vocabulary contained in the ontology consists of five elements – Configuration, Component, Connector, Port, and Role – and they are suitable for modeling traditional component-based architectural styles, such as Client-Server style, Pipe-Filter style. The five basic elements are not enough to describe enterprise architectural styles, such as ESOA and ECC. We extend the basic architectural style ontology to EAS ontology by using nine parts – Infrastructure, Management (or Governance), Process, Configuration, Component, Connector, Port, Role, and Quality Attributes (QA) and we introduce the time t as a parameter in Infrastructure, Management, Process and Configuration. The time t separates each of four parts to two subparts – static and dynamic parts. If Infrastructure does not change with time, it is a static Infrastructure; otherwise it is a dynamic Infrastructure. The semantics of EAS ontology is defined as follows:

EAType ⊆ Infrastructure(t) ∪ Management (t) ∪
Process (t) ∪ Configuration (t) ∪ Component ∪
Connector ∪ Port ∪ Role ∪ QA, (2.1)
Configuration (t) ≡ ∃ hasPart.( Component ∪
Connector ∪ Port ∪ Role) (t), (2.2)
Component ≡ EAType ∩ ∃ hasInterface.Port, (2.3)
Connector ≡ EAType ∩ ∃ hasEndpoint.Role, (2.4)
where Configuration presents application topology; Component is an abstract of application, component or service; Connector is an abstraction of the communication (behavior) and glue or link (structure) between Components.

Infrastructure(t) ⊆ IConfiguration(t) ∪ IComponent ∪
IConnector ∪ Port ∪ Role ∪ QA, (2.5)
IConfiguration(t) ≡ ∃ hasPart.(
IComponent ∪ IConnector ∪ Port ∪ Role)(t), (2.6)
in which t denotes time, IConfiguration(t) is topology of enterprise architecture. If it is invariant with time, then it represents a static topology; otherwise it denotes a dynamic topology, such as dynamic infrastructure and cloud elastic topology EC2 [REF-REF-1][REF-REF-54].

IComponent ≡ Infrastructure(t) ∩ ∃ hasInterface.Port

IConnector ≡ Infrastructure(t) ∩ ∃ hasEndpoint.Role

The relationship of components in Infrastructure(t) is shown in Figure 2:


img

Figure 2 - Infrastructure Ontology


Management(t) ⊆ MConfiguration(t) ∪ MComponent ∪
MConnector ∪ Port ∪ Role ∪ QA, (2.7)
MConfiguration (t) ≡ ∃hasPart.(
MComponent ∪ MConnector ∪ Port ∪ Role)(t), (2.8)
MComponent ≡ Management ∩ ∃ hasInterface.Port
MConnector ≡ Management ∩ ∃ hasEndpoint.Role

The relationship of components in Management(t) is described in Figure 3:


img

Figure 3 - Management Ontology


Process (t) ⊆ PConfiguration(t) ∪ PComponent ∪
PConnector ∪ Port ∪ Role ∪ QA, (2.9)
PConfiguration(t) ≡ ∃ hasPart.(
PComponent ∪ PConnector ∪ Port ∪ Role)(t), (2.10)
PComponent ≡ Process ∩ ∃ hasInterface.Port
PConnector ≡ Process ∩ ∃ hasEndpoint.Role

The relationship of components in Process (t) is depicted in Figure 4:


img

Figure 4 - Process Ontology


QAType ⊆ Performance ∪ Reliability ∪ Scalability ∪
Reusability ∪ Maintainability ∪ Security ∪ Cost ∪
Interoperability ∪ Availability ∪ Flexibility ∪
Manageability ∪ Agility ∪ Simplicity ∪
Consciousness ∪ Accountability ∪ OtherQA, (2.11)

QA ≡ ∃ hasTradeoff.( Performance ∪
Reliability ∪ Scalability ∪
Reusability ∪ Maintainability ∪ Security ∪ Cost ∪
Interoperability ∪ Availability ∪ Flexibility ∪
Manageability ∪ Agility ∪ Simplicity ∪
Consciousness ∪ Accountability ∪ OtherQA) (2.12)

Here, the roles hasPart, hasInterface, hasEndpointer, and hasTradeoff are part of the basic vocabulary of EA styles. [REF-REF-41] formally defines hasPart by defining an architectural composition principle and introducing a notation   to express the composition relationship. The composition is syntactically used in the same way as subsumption "⊆" to related concept description. (2.2) can be formally described as follows [REF-REF-41]:

Configuration   {Component,
Connector, Port, Role}. (2.13)

The hasInterface expresses the structural link from components to ports and hasEndpoint denotes the structural links from connectors to roles.

As defined here, the five basic elements - Configuration, Component, Connector, Port, and Role are basic atomic concepts. The new concepts – Infrastructure, Management, and Process are defined by those basic concepts. They are defined as sub-types of EAType. The QA can also be formally defined as a composition of architectural quality attributes:

QA   {Performance, Reliability, Scalability, Reusability,
Maintainability, Security, Cost, Interoperability,
Interoperability, Availability, Flexibility,
Manageability, Agility, Simplicity,
Consciousness, Accountability, OtherQA} (2.14)

The composition is under an optimization constraint through tradeoff [REF-REF-38][REF-REF-39] for consideration of design constraints. The vocabulary we defined is extensible by adding additional parts and elements using the same mechanism based on subsumption and concept description.

EAS style syntax and semantics

We denote an enterprise architectural style as EAS defined by a specification based on the style syntax and semantics as
EAS = (∑,Φ) (2.15)
where ∑ = (C,R) consists of concepts C and Roles R.

The concept description ø ∈ Φ is based on ∑ [REF-REF-7].

To build our framework, we define the following major style operations:

Let EAS1 = (∑1, Φ1) and EAS2 = (∑2, Φ2).

  • Intersection of EAS styles
    Removing part of concepts and/or roles from one style based on another style is required for style development. The intersection of styles can specify the requirement, which is expressed by EAS1 ∩ EAS2 defined as
    EAS1 * EAS2 ≡ (∑1,∩∑2,(Φ1∪Φ2) | 1 ∩ ∑2); (2.16)
  • Union of EAS styles
    Adding parts of one style to another style is often required for generating a new hybrid style by two styles. The union of styles is denoted by EAS1 ∪ EAS2 and deals with the scenario which is defined as
    EAS1 + EAS2 ≡ (∑1 ∪ ∑21 ∪ Φ2); (2.17)
  • Refinement of EAS Styles
    Refinement of style is important for keeping consistency of all generation of styles, such as a combination of multiple styles, derivation of a new style from an existing style, and extension of a style. Assume an EAS style expressed by (2.15), for any specification (∑', Φ') with ∑ ∩ ∑' = ø, the refinement of EAS by can be defined as
    EAS ⊕ (∑', Φ') ≡ (∑ + ∑', Φ + Φ'); (2.18)

As we know, ESOA and ECC are different enterprise architectural styles. We have defined the ESOA in [REF-REF-47] and we redefine it based on the ontology-based style notation as
ESOA=(∑ESOA, ΦEOSA); (2.19)
where
EOSA = (S,C,D,SI,SM,SP,SQ). (2.20)

In (2.20), S,C,D,SI,SM,SP,SQ are defined in [REF-REF-47], in which are primary component types in ESOA, SI,SM,SP are architectural sub-types – SOA infrastructure type, SOA management type, and SOA process type, respectively. SQ is the architecture quality type or attribute which is the set of design constraints. The ΦEOSA in (2.19) can be defined as
ΦEOSA ={ ø|ø is a specification of part in ∑EOSA }. (2.21)

Similarly, we can define
ECC= (∑ECC, ΦECC), (2.22)
where
ECC = (Sc,Cc,Dc,SIc,SMc,SPc,SQc,SDc), (2.23)
ΦECC ={ ø|ø is a specification of part in ∑ECC }. (2.24)

In (2.23), Sc,Cc,Dc are cloud services, cloud service consumers, and cloud data, respectively, which are primary component types in the ECC. SIc,SMc,SPc are architectural sub-types and they are cloud service infrastructure, cloud service management and cloud service process, respectively. is the cloud specific architecture sub-types which will be defined in the next Section.

Enterprise Cloud Service Architecture

This section defines the new ECSA style framework for modeling enterprise service-oriented architecture [REF-REF-46][REF-REF-47] and the ontology-based framework for modeling EAS styles presented in this paper. Before defining the new style, we define
Cloud ={public cloud} ∪ {private cloud}, (3.1)
in which the public cloud, such as Google cloud [REF-REF-58] and Amazon cloud (Amazon Web Services - EC2 and S3) [REF-REF-42], is typically on the Internet or off-premise. The private cloud, such as cloud-enabled data center, is typically located on-premise.
Firstly, for some enterprises with both ESOA systems and cloud systems for serving different businesses and customers, we define architectural style ECSA as a combination of ESOA and ECC based on (2.17). Secondly, for some enterprises only with service-oriented private cloud systems, we discuss its refinement form in terms of (2.18).
ECSA= (∑ECSA, ΦECSA) (3.2)
in which
ΦECSA = ΦECOSA ∪ ΦECC (3.3)
includes all concept descriptions for the concepts in ∑ECSA where
ECSA = ∑ECOSA ∪ ∑ECC
= (S,C,D,SI,SM,SP,SQ,SD) (3.4)
where
S = SISIISIII (3.5)
in which
SI = {s | s is a service not on cloud}
SII = {s| s is a service on private cloud}
SIII = {s | s is a service on public cloud}
SIV = {s | s is a service on hybrid cloud}
SV = {s | s is a service on community cloud}
where SIVSIISIII and SVSIII.
C = CICII, (3.6)
in which
CI ={c | c is a non-cloud service consumer}
CII ={c | c is a cloud service consumer}
D = DI ∪ = DII, (3.7)
in which
DI = {d | d is an SOA data element}
DII = {d | d is a cloud data element}
SI = SIISIII, (3.8)
in which
SII ={r | r is an SOA infrastructure}
SIII ={r | r is a cloud infrastructure}
SM = SMISMII, (3.9)
in which
SMI ={m | m is an SOA management}
SMII ={m | m is a cloud management}
SP = SPISPII, (3.10)
in which
SPI ={p | p is an SOA process}
SPII ={p | p is a cloud process}
SQ = SQISQII, (3.11)
in which
SQI ={q | q is a SOA quality attribute}
SQII ={q | q is a cloud quality attribute}
SD = SDISDIISDIII, (3.12)
in which
SDI ={d | d is a building element of development}
SDII ={d | d is a service deployment type}
SDIII ={d | d is a service delivery model}

From the definitions of each element of (3.4), we can see that the ECSA combines both the ESOA and the ECC styles. The advantages of the combined ontology are (1) it provides more concepts and descriptions and (2) it covers broader architectural decision choices. For example, if SII, SIII, CII, DII, SIII, SMII, SQII, SDII are empty, then the style is equal to ESOA. (3) It can be regarded as a top level style and easy to extend to different sub-styles, such as ECSA-EPRC (Enterprise Private Cloud Service Architecture) which brings cloud computing to ESOA [REF-REF-5]. The disadvantages of the combination ontology are (1) concept overlapping, such as SIISIII ≠ ø and (2) description overlapping, since there are a lot of commonalities between ESOA and ECC. Figure 5 depicts the relationship of all parts in (3.4). In the following subsections, we will describe each element defined in formulae (3.4) to (3.12) in detail formally [REF-REF-44] and informally. Since ESOA has been described in [REF-REF-47], so this paper focuses on describing the new concepts in ECC and the relationship between ECC and ESOA.


img

Figure 5 - ECSA Domain Ontology


A 3D Model of Cloud Services

Compared with the enterprise service-oriented ontology in (2.20), only one new element SD is added into the ECSA ontology (3.4). We call SD as the 3D model of Cloud Services. The 3D model with new concepts distinguishes between traditional ESOA services and cloud services as well as between ESOA style and ECSA style. In the 3D model, SDI is a set of building blocks and tools for cloud service and enterprise application development, so it is the basis for developing the services in {PaaS} = {Platform as a Service}. SDII is a set of cloud service deployment types:

SDII ={PrC, PuC, VPC, CoC, HyC}.


img

Table 1 - Deployment Types of Cloud Services


Table 1 provides a description of each type where the CoC can be managed by the community or third party and may be on-premise or off-premise. The VPC was first created by Amazon [REF-REF-55]. It is a private cloud hosted in a public cloud through VPN network. The service consumer (SC)'s resources are isolated in public cloud, which provides an online virtual data center to SC. The CoC infrastructure is shared by a community – several enterprises or organizations which have the same concerns, such as mission, security, and policy requirements.

SDIII is a set of delivery modes of cloud services as follows:

SDIII ={SaaS, PaaS, IaaS, IMaaS, IRaaS, XaaS}


img

Table 2 - Delivery Modes of Cloud Services


Services and Cloud Services

We have formally and informally specified services as self-contained software abstractions of business, technical functionality, or infrastructure management, defined by a well-defined interface [REF-REF-16]. We define the kind of enterprise services as functional services which serve business for completing certain operations, such as shopping transaction web service and hotel reservation web service. They include composed and process services, such as workflow services. If a functional service is not exposed to the Internet (out of enterprise firewall) or it cannot be accessed from the Internet, then SSI. In this paper, we focus on the managed services (or enterprise services) on the cloud. We define an Enterprise Cloud Service (ECS) as a specific managed service with Service Level Agreement (SLA), elasticity/dynamism, accountability/utility, loosely-coupled, which can be accessed and delivered from the Internet.

If S is an within the enterprise internal network, then SSII and S is called a private cloud service.

If S is an in an enterprise cloud service provider network, then SSIII and S is called a public cloud service.

Cloud computing extends the ESOA service concept and capacity to a broader area in two aspects – the vertical and horizontal views as shown in Figure 6.


img

Figure 6 - View of Cloud Services


We define
SESOA ={s | s is a traditional SOA service}
and
SCloud ={s | s is a Cloud service}
= SCloudISCloudII
in which SCloudI = {SaaS} {PaaS} {IaaS}, which includes three kinds of basic cloud services;

SCloudII = {IMaaS} {IRaaS} {XaaS}, which includes other types of cloud services.

Thus, SESOASCloud ≠ ø. If a service SSESOASCloud, then SSII.

In the ESOA ontology, service is a primary type. However if the cloud service SSESOA, such as SaaS, PaaS, IaaS, and is a composed service type, then we call it ECSType, such as PaaSType or IaaSType, or SaaSType. Therefore, we can define its ontology based on our framework:

ECSType = (∑ECS, ΦECS) (3.13)
where ∑ECS includes concepts and roles of ECS and ΦECS defines all concept descriptions for ∑ECS.

To specify an ECSType, let us define the following sets of types of properties:

  • Cloud Service Interface Type
    Itype ={User Interaction Interface, Web Service Interface, REST Interface, Web Application Interface, Event Interfaces}
  • Cloud Service Access Type
    Atype ={a | a is a client access protocol method}, such as Web User Interaction (HTTP), Web Service API (SOAP), REST API (HTTP), Web Application API, Event Trigger, distributed devices (wireless devices).
  • Cloud Service Provisioning Type
    Ptype ={Applications, Business Operations, Resources, Information, Platform, Integration}
  • Cloud Service Control/Ownership Type
    Otype ={ Oown, Othirdparty }, in which Oown = Buy/lease and Own, Othirdparty = Owned by public cloud provider and pay-as-you-go.

Now, we can specify ∑ECS as an 8-tuple:
ECS = (IECS, AECS, PECS, OECS, SDIIECS, SIIIECS, PolicyECS, SQECS)
where IECSItype, AECSAtype, PECSPtype, OECSOtype, SDIIECSSDII, SDIIIECSSDIII, SQECS = QoSECS + SLAECS ⊂ SQ in which QoSECS is the ECS Quality of Service and SLAECS is the ECS Service Level Agreement between ECS provider and its consumer.

For instance, the Amazon EC2 cloud service [REF-REF-42] can be specified as
EC2Amazon = (IEC2, AEC2, PEC2, OEC2, SDIIEC2, SIIIEC2, PolicyEC2, SQEC2)
where IEC2 = {Web service interface, REST interface},
AEC2 ={Web service API, REST API},
PEC2 = resources,
OEC2 = Othirdparty (owned by Amazon),
SDIIEC2 =PuC,
SDIIIEC2 =IaaS,
(PolicyEC2, SQEC2) has two parts – the documentation which can be found from [REF-REF-1] and runtime policy and SLA which are managed by Amazon's runtime cloud management.

Using the style syntax defined in EAS Ontology, ECSType can be defined as
ECSType ⊆ ECSConfiguration (t)
ECSType ≡ ∃ hasPart.( ECSComponent
∪ ECSConnector ∪ Port ∪ Role ∪ QA)

For instance, in IaaSType, the ECSConfigration (t) = managed dynamic Infrastructure (t),
ECSComponent ≡ ECSType ∩ ∃ hasInterface.Port
ECSConnector ≡ ECSType ∩ ∃ hasEndpoint.Role

In IaaSType, the major components include web service, service provisioning service, monitoring agent, and resource virtual instance. The connector is the glue between web service and virtual server instance through SOAP or REST protocol. The Amazon EC2 is one instance of the IaaSType.

Cloud Service Consumers

We have specified ESCA service consumers (3.6) in [REF-REF-45][REF-REF-47][REF-REF-48]. Specifically, the public or private cloud service consumers have the following characteristics:

  • Self-service: users can access services they provide or directly procure services in the cloud. Users also manage and monitor ESCA service consumers cloud services from self-service portal;
  • Standard API for accessing cloud services;
  • Rapid service provisioning;
  • Pay-for-use.

ESCA service consumers are treated as one of primary component types of EAS ontology in Framework of Modeling Enterprise Architectural Styles.

SOA and Cloud Data

The set in (3.4) consists of two sets of ECSA data elements which are used for building ECSA style enterprise architectures. SOA data DI has been specified in [REF-REF-47] and Cloud Data DII has been specified in [REF-REF-3][REF-REF-48]. In this paper, both SOA data and Cloud Data are traded as primary component types of EAS ontology in Framework of Modeling Enterprise Architectural Styles.

SOA and Cloud Infrastructure

The traditional SOA infrastructure SI is the heart of ESOA. It is the bridge for the transformation between business and services. For the new ECSA style, the cloud infrastructure is added. It is easy to show that SISI ≠ ø which means that the infrastructure of the new style is a hybrid of both the SOA and the cloud infrastructure styles. The traditional ESOA infrastructure is not really dynamic and flexible enough. Therefore, it is not adaptable to today's on-demand business workloads and real-time B2B (Business to Business) requirements. It also uses more resources and power in enterprise's data center. The cloud infrastructure SII is a dynamic IT infrastructure which consists of elastic web servers, elastic application servers, elastic MQ servers, and elastic database servers. It has the following three main characteristics:

  • It supports elasticity and dynamism – automatic scalability and load-balancing, failover in terms of virtualization [REF-REF-10][REF-REF-13][REF-REF-15][REF-REF-24] or other technologies [REF-REF-58].
  • It supports resource usage accountability – utility model [REF-REF-10][REF-REF-60].
  • It can be a part of cloud service, such as PaaS type services (Google App Engine), or it can be a cloud service, such as IaaS type service (Amazon EC2).

Therefore, the cloud infrastructure brings cost-effective operations and elasticity to current SOA infrastructures. The traditional SOA infrastructure is now refined with cloud infrastructure's dynamism. We can specify a dynamic infrastructure ontology based on the framework in Framework of Modeling Enterprise Architectural Styles. We assume
IComponents = {INET, DLB, VWEB, PWEB, VAS, PAS, VST, PST, VNET, PNET, IMS, ISS} in which
INET = Internet;
DLB = Dynamic Load Balancer;
VWEB = Virtual Web Server;
PWEB = Physical Web Server;
VAS = Virtual Application Server;
PAS = Application Server;
VST = Virtual Storage;
PST = Storage;
VNET = Virtual Network;
PNET = Physical Network;
IMS=Infrastructure Management Service;
ISS=Infrastructure Security Service
IConnectors={INET-DLB,DLB-VWEB,VWEB-VNET, VWEB-PWEB, PWEB-VNET, PWEB-VST, PWEB-VAS,VAS-PAS, PAS-VNET, PAS-VST, VST-PST, PST-VNET, VNET-PNET, IMS-DLB,IMS-VWEB, IMS-PWEB, IMS-VAS, IMS-PAS, IMS-VST, IMS-PST, IMS-VNET, IMS-PNET, ISS-DLB, ISS-VWEB, ISS-PWEB, ISS-VAS, ISS-PAS, ISS-VST, ISS-PST, ISS-VNET, ISS-PNET}

Now we can define a dynamic infrastructure by using ACME-like language:
Infrastructure(t) DynInfrastructure = {
IComponent Type DLB = {
Ports = {In, Out}};
IComponent Type VWEB = {
hasVirtualInterface = true
Ports = {In, Out}};
IComponent Type PWEB = {
hasPhysicalInterface = true
Ports = {In, Out}};
IComponent Type VAS = {
hasVirtualInterface = true
Ports = {In, Out}};
IComponent Type PAS = {
hasPhysicalInterface = true
Ports = {In, Out}};
IComponent Type VST = {
hasVirtualInterface = true
Ports = {In, Out}};
IComponent Type PST = {
hasPhysicalInterface = true
Ports = {In, Out}};
IComponent Type VNET = {
hasVirtualInterface = true
Ports = {In, Out}};
IComponent Type PNET = {
hasPhysicalInterface = true
Ports = {In, Out}};
IConnector Type INET-DLB = {
Roles = {request, dynamicLoadReq}};
IConnector Type DLB-VWEB = {
Roles = {dynamicLoadReq, provideWeb}};
IConnector Type VWEB-VNET = {
Roles = {routRequest, provideRout}};
IConnector Type VWEB-PWEB = {
Roles = {requestWebExec, provideWebExec}};
IConnector Type PWEB-VNET = {
Roles = {routRequest, provideRout}};
IConnector Type PWEB-VAS = {
Roles = {reqAppProcess, provideAppProcess}};
IConnector Type VAS-VNET = {
Roles = { routRequest, provideRout }};
IConnector Type VAS-PAS = {
Roles = {requestTransExec, provideTransExec}};
IConnector Type PAS-VNET = {
Roles = {routRequest, provideRout}};
IConnector Type PAS-VST = {
Roles = {reqDataAccess, provideDataAccess}};
IConnector Type VST-VNET = {
Roles = {routPST, provideRout }};
IConnector Type VST-PST = {
Roles = {reqAccessExec, provideAccessExec}};
IConnector Type VNET-PNET = {
Roles = {reqRoutExec, provideRoutExec}};
IConstraint Type scalability = {
dynamically scale out and scale down,
on-demand};
IConstraint Type availability = {
SLA-defined, high fault-tolerance};
IConstraint Type agility = {
resilient computing, dynamic reconfiguration};
IConstraint Type security = {
End-to-End security checking};
Ownership Type OwnedbyEnterprise = {
IaaS in PvC enterprise's datacenetr};
Ownership Type OwnedbyVendor = {
IaaS in PuC Vendor's datacenter};
}

In the specification, the management components, End-to-End Infrastructure management service and End-to-End infrastructure security service, are ignored. They are discussed in the next section. Figure 7 is the high-level graphic description of a typical enterprise layered dynamic infrastructure.


img

Figure 7 - Dynamic Enterprise Infrastructure


SOA and Cloud Management

Cloud computing is changing the landscape of ESOA and brings forth new types of services and dynamic infrastructures into ESOA. An enterprise architecture needs SOA to achieve better quality by leveraging cloud computing providers [REF-REF-34]. The relatively mature SOA management or governance SMI is the foundation of cloud management SMII. It is easy to show that SMISMI ≠ ø. The SOA management we have specified in [REF-REF-45][REF-REF-46], such as network and application monitoring, identity management, policy enforcement, service-level agreement management, and service lifecycle management in SMI, are very important for cloud computing. Thus, they are also in SMII. However, cloud computing extends the SOA management to a new level from two perspectives, namely, enhancing SOA managements and adding some new cloud specific managements.

  • Cloud systems are more dynamic and mostly real-time with automatic runtime governance compared to services infrastructure.
  • Cloud systems request highly automatic policy and SLA management at runtime.
  • Cloud systems request an automatic service provisioning management for their utility model.
  • Cloud systems need new identity management for cloud service security and trust, such as the Amazon cloud security process [REF-REF-4].

We specify the refinement ontology of cloud service management with SOA management in terms of ACME-like language and the framework defined in the Framework of Modeling Enterprise Architectural Styles. Assume
MComponents = {MS, SS, RS, SLM, LM, IM, AM} in which
MS = Monitoring service
SS = Security management service
RS = Resource management service
SLM = Service Level Management service
LM = service lifecycle management service
IM = Infrastructure management service
AM=Account management service which includes cloud service consumer's utility billing management.

MConnectors ={MS-IC, MS-AC, MS-SC, MS-SPR, SS-IC, SS-AC, SS-SC, SS-SPR, RS-IC, SC-SLM, SLM-SPR, MS-SLM, SLM-RS, LM-SPR, IM-IC} in which SC = Service consumer, SPR = Service Provider and AC = Application Component are management service consumers, IC = Infrastructure Component which include management service consumer and managed resources.

Management(t) CloudServiceManagement = {
MComponent Type MS = {
hasInterface = true
Ports = {In, Out}};
MComponent Type SS = {
hasInterface = true
Ports = {In, Out}};
MComponent Type RS = {
hasInterface = true
Ports = {In, Out}};
MComponent Type SLM = {
hasInterface = true
Ports = {In, Out}};
MComponent Type LM = {
hasInterface = true
Ports = {In, Out}};
MComponent Type IM = {
hasInterface = true
Ports = {In, Out}};
MComponent Type AM = {
hasInterface = true
Ports = {In, Out}};
MConnector Type MS-IC = {
Roles = {monitoring, runtime}};
MConnector Type MS-AC = {
Roles = {monitoring, runtime}};
MConnector Type MS-SC = {
Roles = {monitoring, runtime}};
MConnector Type MS-SPR = {
Roles = {monitoring, runtime}};
MConnector Type MS-SLM = {
Roles = {report, negotiatingOffering}};
MConnector Type SS-IC = {
Roles = {protect, resources}};
MConnector Type SS-AC = {
Roles = {secure, access}};
MConnector Type SS-SPR = {
Roles = {secure, access}};
MConnector Type SS-SC = {
Roles = {secure, access}};
MConnector Type SC-SLM = {
Roles = {reqService, claimQoS}};
MConnector Type SLM-SPR = {
Roles = {offerService, provideService}};
MConnector Type SLM-RS = {
Roles = {reportResource, mgrResources}};
MConnector Type RS-IC = {
Roles = {mgrResources, dynReconfig}};
MConnector Type LM-SPR = {
Roles = {mgrLifeCycle, provideDynService}};
MConnector Type IM-IC = {
Roles= {mgrInfrastructure,
glueSCAndServices}
Constraint Type CManagedByEnterprise = {
componentsOwnedByEnterprise = true}
Constraint Type CManagedByVendor = {
componentsOwnedByVendor = true}
Constraint Type CManagedByBoth = {
componentsOwnedByBoth = true}};
}


img

Figure 8 - Boundaries of Components


Figure 8 roughly describes the boundaries of components in different types of cloud services. From the figure, we can see a remarkable difference between traditional SOA management and cloud management. Traditional SOA management manages all components in its own data center, but cloud management manages different sub-sets of components by different component ownership.

SOA and Cloud Processes

One of the important parts of the ESOA style is its set of SOA processes. The SOA process or workflow is an abstraction of Business Process Management (BPM). Each process is composed of multiple services in orchestration and/or choreography for completing a whole or partial business process or task. The traditional SOA process can be executed by using an ESOA infrastructure with process engine in the internal network of an enterprise. However, the traditional SOA processes face many challenges and issues: real-time high performance (such as automated trading), on-demand scalability, large payloads (10+ MB), memory constraints, and high availability and reliability. In a distributed SOA environment of an enterprise, the bottlenecks tend to occur in one or more of the following three places:

  • Shared intermediary services;
  • The services themselves;
  • SOA infrastructure operations.

In most cases, the scalability bottlenecks across all these SOA parts in workflow/process are caused when disk I/O, memory, or CPU saturation levels are reached. Moreover, the cluster technology, adopted by traditional SOA, can provide higher availability. However, it depends on static partitioning, where a single backup server is pre-assigned to service requests from a failing server. The grid-enabled SOA [REF-REF-11] provides a way to improve the performance, scalability, and availability of SOA processes. Cloud computing shares the same goal as grid computing, namely, to allow service consumers to obtain computing resources on-demand. However, cloud computing is a new style of distributed computing, which introduces many new architectural styles and technologies to SOA. Compared with grid computing, there are four aspects in which cloud computing differs from grid computing [REF-REF-20]:

  • It is massively scalable.
  • It can be encapsulated as an abstract entity that delivers different levels of services to the customers outside of the Cloud.
  • It is driven by economies of scale.
  • The services can be dynamically configured through virtualization and other approaches and delivered on-demand.

We describe the ECSA style Business Process Management (BPM) process based on the framework in Framework of Modeling Enterprise Architectural Styles and ACME-like language as follows. Assume
PComponent = {BPMB, BPMM, BPME, SPPR, SP, BPMS}, in which
BPMB=BPM Process Buider
BPMM=BPM Process Managment
BPME=BPM Process Engine (Runtime)
SPPR=SOA Process Provider
SP=SOA BPM Process
BPMS=BPM Process Storage
PConnector = {SC-BPMM, BPMB-BPMM, BPMM-BPME, BPMM-BPMS, BPMM-SP, BPME-BPMS, BPME-SPPR, SP-SIN, SP-SOU}, in which
SC=Service Consumer
SIN=Services in enterprise datacenter (on-promise)
SOU=Services in cloud provider's datacenter
Process(t) CloudServiceProcess = { IComponent Type BPMB = {
hasInterface = true
Ports = {In, Out}};
IComponent Type BPMM = {
hasInterface = true
Ports = {In, Out}};
IComponent Type BPME = {
hasInterface = true
Ports = {In, Out}};
IComponent Type SPPR = {
hasInterface = true
Ports = {In, Out}};
IComponent Type SP = {
hasInterface = true
Ports = {In, Out}};
PConnector Type SC-BPMM = {
Roles = {requestProcess, manageRequest}};
PConnector Type BPMB-BPMM = {
Roles = {buildProcess, registerProcess}};
PConnector Type BPMM-BPME = {
Roles = {sendRequest, runControlProcess}};
PConnector Type BPMM-BPMS = {
Roles = {requestInfo, storeProcessInfo}};
PConnector Type BPME-BPMS = {
Roles = {accessInfo, storeProcessInfo}};
PConnector Type BPMM-SPPR = {
Roles = {monitorControlSP, provideSP}};
PConnector Type SP-SIN = {
Roles = {executeSP, provideService}};
PConnector Type SP-SOU = {
Roles = {executeSP, provideCloudService}};
Ownership Type BPMOwnedbyEnterprise = {
SI=IaaS, BPMB and BPMM in PvC enterprise's
Datacenter; BPMaaS ∈ {PvC}};
Ownership Type SIOwnedbyVendor = {
SI=IaaS in PuC Vendor's datacenter; BPMB and
BPMM in PvC enterprise's datacenter;
BPMaaS ∈ {HyC} ∩ {IaaS}};
Ownership Type BPMOwnedbyVendor = {
SI=IaaS, BPMB and
BPMM in PuC Vendor's datacenter;
BPMaaS ∈ {PuC} ∩ {PaaS}};
}

Figure 9 depicts the typical topology of ECSA PConfiguration (t) virtually.


img

Figure 9 - Topology of ECSA Process


In Figure 9, the SI, BPMB, and BPMM can be provided by cloud service providers. For cloud, PConfiguration(t) is dynamic, in which dynamic process can be recomposed by choosing different service providers based on SLA [REF-REF-49]. Therefore service management is also reconfigured by selected different service providers and MConfiguration(t) is also dynamically changed. [REF-REF-50] proposed a service-oriented dynamic reconfiguration framework for dependable distributed computing. [REF-REF-53] presented an approach of ontology-based dynamic process collaboration in SOA. Their work is of theoretical and practical significance for dynamic process management in ECSA.

Cloud Quality Attributes

The software architectural quality attributes [REF-REF-38] include not only the principles of system architecture design, but also the non-functional constraints of the structure and behavior of any software architecture. Therefore, we include the architectural quality attributes as part of ECSA. We have defined common SOA quality attributes SQI of ESOA style in [REF-REF-45][REF-REF-46]. They are also quality attributes of cloud computing, specifically, of private clouds. Therefore, SQISQII ≠ ø. They both share many commonalities, such as performance, security, scalability, and availability. However:

  1. The quality attributes of SOA and public cloud have different degrees of maturity. In general, the maturity of cloud quality attributes is less than that of SOA quality attributes.
  2. The specifications of some cloud quality attributes are different from those of traditional ESOA.
  3. SQII includes some of cloud-specific quality attributes and properties of cloud services.

M. Klein and R. Kazman proposed an Attribute-Based Architectural Styles (ABAS) in [REF-REF-29], in which the architectural style's topology are specified and quality attribute response behavior is used as analysis and reasoning of the style's topology. C. Pahl, et al., introduced a quality ontology which extends the style ontology to capture a vocabulary of quality attributes (non-functional characteristics) and corresponding quality metrics [REF-REF-41]. In this paper, the quality ontology is defined as part of style ontology in Framework of Modeling Enterprise Architectural Styles. The ECSA style's quality ontology is specified based on our framework and (2.11):

CloudSQType ⊆ Performance ∪ Reliability ∪
Scalability ∪ Reusability ∪ Maintainability ∪
Security ∪ Cost ∪ Interoperability ∪ Availability ∪
Flexibility ∪ Manageability ∪ Agility ∪
Recoverability ∪ Visibility ∪
Accountability ∪ Portability ∪ Compatibility ∪
CloudSQ (SQII) ≡ ∃ hasTradeoff.( Performance ∪
Reliability ∪ Scalability ∪ Reusability ∪
Maintainability ∪ Security ∪ Cost ∪
Interoperability ∪ Availability ∪
Flexibility ∪ Manageability ∪ Agility ∪
Recoverability ∪ Visibility ∪
Accountability ∪ Portability ∪ Compatibility ∪

We define and specify major quality attributes of cloud service systems in this section.

Cloud Performance (CSP)

The CSP is one of the most important runtime interaction behaviors of the public cloud architecture. Formally, CSP ≡ ∃ hasMetric.(ResponseTime ∪ Latency ∪ Throughput) ∩ ∃ hasImpactFactor.(CloudServiceType, CloudServiceProvider, PayService)
where
ResponseTime=
RT(payload, bandwidth, Roundtrips, RTT, TS, TC

img

in which αi, βi > 0, N is number of roundtrips between cloud service consumer and service providers; RTTi is network Round Trip Time; Tis, Tis are cloud service computing time and client computing time at ith application turn, respectively.

The cloud application may take multiple network round trips across different enterprise data centers through internet and WAN (Wide Area Network), so latency is an important characteristics of cloud service computing. Latency impacts not only ResponseTime, but also Throughput. Knowing cloud latency greatly helps with architecture design and analysis.

Latency= (LSI LSP, LDT, LSDP, LLP, LSC)

img

where ai, bi, ci, di, ei, hi > 0, which are the ith cloud service provider and its environment related parameters, and LiSI is the ith cloud infrastructure latency which includes low level latency, such as OS, CPU, and Storage I/O latency, high level latency, such as VM, DNS, and Router/Switch latency, and networking latency, such as internet and WAN latency. It can be formally described as
LiSI = LiSI (Distancei, Hopsi, FML, BL, PL, LML, LSP) where Distancei is the geographical distance between cloud client and the ith cloud service; Hopsi is the set of "hops" in the network; FML is the first miles latency; BL is the backbone latency; PL is the peering latency and LML is the last miles latency. LSP=LSP(LQ,LRMD,LIC,LID) is the Latency of service provisioning (such as IaaS EC2) before service runtime execution, in which LQ is the latency from task request queuing [REF-REF-54]; LRMD is the latency from resource management decision program (reject task request because of insufficient capacity or schedule a job for the task request); LIC is the latency from creating instance (such as EC2 instance); LID is the latency from instance deployment. Figure 10 shows the cloud performance challenge, in which the public cloud datacenter is like Amazon Web Service (AWS) and IBM Cloud Datacenter whereas the private cloud datacenter and end users are the consumers of public cloud services. Since public cloud services are located in cloud provider's datacenters, the Distancei plays an important role in WAN latency: the larger the worse. For example, the load time from Bejing has more than two seconds latency than from New York on more than 10% uptime based on a report from BitCurrent.com [REF-REF-9]. Moreover, in (3.15), LiSP is the ith service processing latency; LiDT is the data transmission latency; LiLDSP is the service dependency latency; LiSDP is the propagation latency and LiSC is the service client latency which is coming from slow client processing.

The throughput describes the amount of tasks which can be performed over a given period of time. Therefore, throughput is another important performance metric. The maximum TCP/IP networking can be measured by the following formula [REF-REF-57]:
Throughput.Max.metrics =TWS/RTT, (3.16)
in which TWS is TCP Window Size and RTT is Round Trip Time. The cloud application throughput can be described by the following equation in terms of threads and latency:

img

where APT is the cloud application processing time in seconds and Latency is the total latency in seconds. From (3.17), we see that Latency reduces Throughput and reducing Latency can increase Throughput.

Cloud Performance can be measured by several metrics which are based on distributed computing performance metrics. However, the CSP also has cloud factors which impact cloud performance:

Performance.CloudFactor1=CloudServiceType
{IaaS, PaaS, SaaS}

To describe the performance impact on the factor, we define a concept, cloud affinity level (CAL), as an indicator of close degree of service consumer and other components in enterprise architecture. The higher the CAL the lesser is the latency and the better is the performance. From Figure 8, we see that private cloud and SaaS have the highest CAL, IaaS has the lowest CAL. The BitCurrent report [REF-REF-9] shows that IaaS, such as Amazon EC2, may have higher latency than PaaS, such as Google AppEngine, or SaaS, such as Salesforce, in terms of the same resource.

Performance.CloudFactor2=CloudServiceProvider

which can impact performance in two main aspects: (1) the geographic distance between cloud service consumer and the service provider datacenter; (2) cloud service provider's over or under subscription to resources, such as physical servers, VCPU, may impact the cloud performance.

Performance.CloudFactor3=PayService

which impacts performance, since when a user pays more, the user can get more resources and services. For example, paying $0.17/per hour can get a medium CPU, but paying $0.68/per hour can get an extra large CPU from Amazon EC2 IaaS [REF-REF-1].


img

Figure 9 - Cloud Performance Challenge


Cloud Scalability (CS)

The CS is another remarkable difference from traditional ESOA scalability. The tier-based ESOA architecture with traditional middleware does not scale linearly and does not allow applications to scale on-demand. In terms of framework, we define
CS ≡ ∃ hasMetric.(ScaleUp ∪ ScaleOut ∪
ScaleIntoCloud) ∩
∃ hasImpactFactor.(CloudServiceType,
VMType, Cost),
in which
ScaleUp.metrics=performance (Server, Resources, Demand),
where ScaleUp = Scale Up or Vertical Scale is a traditional way to scale the system. The performance function increases for a given Server when Demand is increasing and Resources (CPU, Memory) are added to the Server. When the performance function is linear, either Throughput is doubled or ResponseTime is cut to half when the resources (CPU, processes, disk) are doubled for the given server computer. It is an ideal scalability, but it is hard to achieve in practice.
ScaleOut.metrics= performance (activeServers,
onDemandServers, Demand)
ScaleIntoCloud.metrics= performance (activeServers,
onDemandServers, Demand)
where ScaleOut = Scale Out or Horizontal Scale is a way to scale system in the same enterprise datacenter. ScaleIntoCloud = Scale into Cloud or Global Scale is a new way to scale out the enterprise system. In the performace function, activeServers is a set of servers in a cloud system and onDemandServers is a set of passive servers in the server pool or queue which are waiting to be added to the system. For ScaleOut, the service pool is inside the enterprise datacenter, but for ScaleIntoCloud, the service pool is in the cloud service provider's datacenter. The performance function is an increasing function or a non-increasing as well as non-decreasing function when Demand is increasing and a sub-set of passive servers are activated and added into the system for the same services, which means that the scale out system can either reduce ResponseTime or increase Throughput. In other words, it can keep the desired performance when the requirements of concurrent users are increasing.

There are several factors that impact cloud scalability. The CloudServiceType impacts the way and level of cloud system scalability. For IaaS, such as Amazon EC2, its scalability is through on-demand instances, while for PaaS, such as Google AppEngine, its scalability is through its auto scalable runtime. VMType (Virtual Machine Type) greatly impacts not only the way of scalability, but also other quality attributes and cloud system design. Table 3 shows the impacts. Public cloud utility computing nature impacts scalability through indicator cost scalability. For example, the Amazon Auto Scaling service uses CloudWatch as the monitoring mechanism for determining to scale up or down. The cost of using Elastic Load Balancer is from $0.025 per hour ($18.25 per month).

Let us also compare the traditional and dynamic ways of implementing scalability from the Configuration perspective. The scalability of the traditional style can be described as follows:

TSM = ESOAscale (resources, connections, deployment, configuration).

Here, all parameters are tied to a workload estimate and are not allowed to be changed dynamically on-demand. The cloud scalability CS greatly improves TS, which allows applications to scale on-demand – scale up and scale down resources and network connections dynamically. The CS can be described as
CS = ECSAscale (resources (config), connections(config), deployment(config), config(t, request, policy))
which means that the resources, such as OS, CPU, memory, and networking capacity and redeployment, depend on a dynamic reconfiguration operation (config) which depends on time t, on-demand request, and policy. The CS can be implemented by an SLA-driven IaaS type service [REF-REF-54]. The CS has elastic scalability, such as Amazon AWS (EC2, S3) and IBM PowerVM which are all based on the scale-out principle. In the following, we show that the scale-out is a better way to get cloud scalability.

If we assume that the cloud system is continuous and that some of its attributes are derivable, then dynamic scalability can be modeled by a mathematical elastic equation:

img

In (3.18), α is a positive constant. Capacity(t) = f(number_of_instances, number_of_threads, t). The desired system performance is invariant of time t when Demand(t) is increasing or decreasing with t. Let us suppose both Capacity(t) and Demand(t) are derivable, then taking the derivative of t on both sides of (3.18), we have:

img

which means that if Capacity(t) and Demand(t) satisfy (3.19), the Performance(t) is invariant of time t. To satisfy (3.19), changes in the ratio of Capacity(t) with t should be the same as that of Demand(t) with t. Therefore, this proves that ScaleOut is a better way for achieving cloud dynamic scalability.


img

Table 3 - Impacts to Attributes of VMType

Cloud Security (CSE)

Security is a common constraint for any enterprise architectural style and a common concern for any enterprise architecture. Enterprises have even more security concerns on adopting public cloud services, since they are located in the provider's datacenters and accessed from the Internet. The information of companies is stored in the system over which the cloud service provider has no control. Therefore, for the ECSA architecture, the is a very important quality attribute for design consideration on public cloud services and cloud service-oriented systems, as well as a very important check point for evaluating an ECSA architecture. Based on our framework, CSE is defined as:

CSE ≡ ∃ hasMetric.(Confidentiality ∪ DataSecurity ∪ Vulnerability ∪ Privacy) ∩
∃ hasImpactFactor.(CloudServiceType, CloudControlModel, CloudSecurityManagement) ∩
∃ hasQualityDependency.(Performance, Cost)

in which Confidentialitty.metrics= NSCG/NSP X 100

where NSCG is Number of Security Check Gates which includes identity management and access control (such as role-based access control); NSP is number of security points in the system from end to end as shown in Figure 11.

DataSecurity.metrics=securityLevel(dataClass)

img

in which FLDS is First Level Data Security, such as data encryption for data (such as credit card number) requiring the highest security; SLDS is Second Level Data Security, such as data validation and encoding for data (such as application data) requiring medium security; TLDS is Third Level Data Security, such as data validation for data (e.g., application data) requiring the lowest security. [REF-REF-12] has defined several vulnerability metrics. We choose one of them – Vulnerability Scan Coverage (VSC) in this paper:

img

Cloud security is also impacted by several factors:

  • CloudServiceType – different types of cloud services have different architectural topology structures and different security check points.
  • CloudControlModel – from Figure 8, cloud computing splits the control domain into three domains, namely, (1) SC domain, (2) a domain shared by both SC and SPR, and (3) SPR domain. Therefore, different types of cloud services have different system control models. All the components in a private cloud are controlled by the organization, so it has maximum security control. However, in a public cloud, service consumers have less control on their data and operations, so it has less security control and the security is highly dependent on the SPR's security provision.
  • CloudSecurityManagement – security management is one of the elements in SMII. Therefore, providers must have security management as part of their ECSA architecture. Better security management can help achieve better Security. Moreover, Security quality attributes also influence the architectural design of security management. The security management should provide easy, virtual controls to manage firewall and security settings for applications and runtime environments in the cloud.

In architectural design, the quality dependency of cloud security should be taken into consideration. Performance is one of the quality attributes. To guarantee data security across clouds, some data is needed by using FLDS. However, data encryption reduces router and server performance. Once data is sent to SC side, the data decryption also reduces client side computing performance. Moreover, improper security architecture design reduces system performance. Cost is another quality attribute. To meet both security and performance requirements, SC has to pay a higher price. The tradeoff between security, performance, and cost is an important consideration of cloud architectural analysis and design.


img

Figure 11 - End-to-End Cloud Security Management


Cloud Service Availability (CSA)

The downtime of cloud service and system directly impacts enterprise business availability. The cloud provider needs to effectively receive and route incoming requests to the appropriate virtualized application instance on behalf of its customers. Google and Microsoft replicate each application instance to multiple physical locations. AT&T Synaptic Hosting spans multiple locations for its enterprise customers. Therefore, availability is a very important quality attribute. The term "high availability" is defined by the Institute of Electrical and Electronics Engineers (IEEE) as: "Availability of resources in a computer system, in the wake of component failures in the system." A system can be called highly available if its applications and services are available even in the case of an error without direct human interaction. The Harvard Research Group (HRG) [REF-REF-23] classifies the availability as its Availability Environment Classification (AEC) as shown in Table 4:


img

Table 4 - AEC and NINES (Number 9s)


In Table 4, the term "Highly Reliable" implies some degree of "Availability". If a system is not available, then the "Highly Reliable" is not possible. High availability is defined in enterprise architecture (EA) and traditional ESOA system by SLA [REF-REF-49]. It is also defined in SLA of public cloud services, such as the availability of Amazon EC2 is defined as 99.95% in its SLA [REF-REF-1]. Amazon's storage service S3 achieves fault-tolerance level availability. The framework proposed in Framework of Modeling Enterprise Architectural Styles provide a formal way to analyze the CSA which can be defined as

CSA ≡ ∃ hasMetric.(SUT) ∩
∃ hasImpactFactor.(CloudServiceType, CloudAvailabilityManagement) ∩
∃ hasQualityRelation.(Reliability, Scalability, Consistency, Performance, Cost) ∩

in which
SUT=Service Up Time=100% - SUA%,
where SUA is service unavailable rate [REF-REF-40]:

img

in which SDFi is Service Degradation Factor for the ith Outage and 0 ≤ SDFi ≤ 1, which indicates the service unavailable degree (such as partial service outage). The N can be a number of outages in a month or year

Traditional Availability is defined based on server up and down times or defined through Mean Time Between Failures and Mean Time to Repair. In cloud service computing, a single server failure and repair should not impact the service availability. The CSA can be gained from cloud dynamic resource and availability management, such as Amazon EC2's availability zones which are within the same region and ensures complete and total redundancy for one's application [REF-REF-1].

Cloud service availability is impacted by several cloud service architectural style parts.

  • CloudServiceType – Private Cloud Service availability can be achieved by its private IaaS. A hybrid cloud service availability can be increased by both private IaaS and public IaaS. Both PaaS and SaaS service availability can be met by using both SPR's private IaaS and other public IaaS, such as Amazon's EC2. Therefore, IaaS type cloud service is a kind of service for other service availability.
  • CloudAvailabilityManagement – CSA requires the service availability (resource) management (CAM) which is one of the elements in SMII in ECSA style and better CAM can increase cloud service availability.

CSA as a quality attribute has relationship with other quality attributes. The relationship between CSA and cloud service reliability (CSR) can be defined as

img

where CSR(t) = Cloud Service Reliability over a time period t and MTTF=1/λ is "mean time to failure" and represents the average time until the first failure occurs, and MTTR=1/µ is "mean time to repair" and represents the average time required for repair, including any time to detect that there is failure, to repair the failure, and place the system back into operational state. CSR(t) = e-λt, so CSR is a decreasing function with respect to λ. It is easy to show CSA is a decreasing function with respect to λ and an increasing function with respect to µ. Therefore, it means less reliability, then less availability. Consider the trip quality attributes = (Consistency, Availability, Scalability). According to the CAP principle [REF-REF-35], for a shared data system (most of web application systems and cloud systems), the strong consistency (ACID-based consistency) could not be reached if the system wants to meet both high availability and the ability to tolerate network partitions. To achieve high cloud scalability, the system needs to be partitioned. Hence, in architecture design, one of the two attributes, Availability or Consistency can be chosen. Therefore, the ECSA architecture should have a better tradeoff between them. For the checkout process, one always wants to honor requests to add items to a shopping cart because it is revenue producing. In this case, one can choose high availability. Errors are hidden from the customer and sorted out later. However, when a customer submits an order, one favors consistency because several services–credit card processing, shipping and handling, reporting–are simultaneously accessing the data.

Availability is related to Performance. Most technologies, such as cluster and resource redundancy, are helpful at increasing performance. However, the fail-over and replication for high availability may sometimes increase temporal latency. Moreover, to reach high availability in the cloud, there are two kinds of cost to service providers: (1) cost of redundancy architecture should be taken into consideration; (2) penalty due to unavailable services, which is a motivation for SPR to consider higher availability.

Cloud Service Reliability (CSR)

While CSA specifies the cloud service uptime, CSR is defined as an ability to deal with external failures, while the cloud service continues to perform its functions in the runtime environment. As one of the cloud service quality attributes, CSR can be formally defined as
CSR ≡ ∃ hasMetric.(MTBF ∪ FailureRate) ∩
∃hasQualityRelation.(Availability, Security, Cost) ∩
∃hasImpactFactor.(CloudReliabilityManagement) ∩
where MTBF = Mean Time Between Failure is a traditional system (hardware and software) reliability metric. It is used as a metric of cloud service. A cloud service system failure reflects a cloud service level outage to service consumers that can only be restored through repair or redundancy. Another typical metric is
FailureRate = 1/MTBF

Obviously, CSR requires a good cloud reliability management which is part of SMII in ECSA style. As shown in the previous section, Availability is a function of Reliability, but it is possible for poor reliability to reach high availability. Moreover, less reliability in cloud service system increases risk of security violations. FailureRate is one of the key service level agreements. If FailureRate > the rate defined in SLA, then cloud service consumer should get service credit from their billing cycle. For example, Amazon S3 defines the FailureRate as "Error Rate" which means: (i) the total number of internal server errors returned by Amazon S3 as error status "InternalError" or "ServiceUnavailable" divided by (ii) the total number of requests during that five minute period. The Cost to service provider, such as Amazon, is to give penalty money back to consumers.

Cloud Resiliency (CR)

One of the concerns to adopting public cloud service is the potential loss of customer data and information when failures or disasters occur. Another concern is how cloud computing can assure guaranteed performance levels under high stress load situations. Cloud resiliency is a new quality attribute to address these concerns. The notion of resiliency has been studied in dependable computing but mainly with regard to fault-tolerance. Cloud computing systems operate in a highly distributed and dynamic environment. The changes are everywhere and at all times. The changes come not only from single-point failures and security attacks, but also due to user demands. Therefore, cloud computing requires not only fault-tolerance and security attack-tolerance, but also high-stress load-tolerance from unexpected operational demands. This constitutes cloud resiliency and is a very important requirement for cloud computing, especially for public cloud services to guarantee business continuity in the cloud. Therefore, Resiliency is one of the key non-functional constraints in ECSA style. This can be described based on our ontology framework:

CR ≡ ∃ hasMetric.(Fault-Tolerance ∪ SecurityAttack-Tolerance ∪ HighStressDemand-Tolerance) ∩
∃ hasImpactFactor.(CloudServiceType, CloudResilientManagement) ∩
∃ hasQualityRelation.(Reliability, Availability, Security, Scalability)

Fault-Tolerance.metrics1=Number of single point failure

Fault-Tolerance.metrics1=Duration of Failover

Fault-Tolerance.metrics2=Duration of Disaster Recovery (DR)

Fault-Tolerance.metrics3=TimeWindow of Fault Outage

SecurityAttack-Tolerance.metrics=Duration of recovering from attack

HighStressDemand-Tolerance.metrics=
How quickly can the system allocate
resources and maintain
the desired system performance

CloudServiceType is a factor that impacts resiliency since different types of cloud services have different control boundaries as shown in Figure 8. The CloudResilientManagement is another factor that impacts resiliency. Better change, resource, and security management are all helpful in improving CR.

Moreover, this attribute has relationships with other attributes. Improvement in any of the Reliability, Availability, Security, and Scalability attributes can increase resiliency. Conversely, resiliency can improve system Reliability, Availability, Security, and Scalability, since it improves failover across a service. Traditional failover is to failover and perform disaster recovery (DR) from one server to another server at the same location (same data center) or in different datacenters in the same enterprise. Cloud failover or DR extends this to failover or DR to cloud. The ECSA style allows failover or DR to be in different datacenters at different geographic locations. For instance, Amazon EC2 is currently available in four regions or datacenters: US East (Northern Virginia), US West (Northern California), EU (Ireland), and Asia Pacific (Singapore). Each region (datacenter) consists of multiple Availability Zones (AZs). Amazon EC2 is able to place instances in multiple locations - multiple regions and multiple AZs. AZs are distinct locations that are designed to be insulated from failures in other AZs and provide inexpensive, low latency network connectivity to other AZs in the same Region. By launching instances in separate AZs, the EC2 consumers' applications can be failed-over to different AZs if their applications experience failures in one location. Thus, Amazon's resiliency keeps applications from being impacted by the failure of a single location. However, Amazon's approach missed a scenario – all AZs could be failed in a region or datacenter. In the case a single point failure could be happened. We discuss the scenario in Amazon Cloud Architecture (ACA).

In this paper, we have focused on specifying and analyzing the most important cloud quality ontology of ECSA. Some of the other quality attributes, such as Cloud Accountability (CAC), Cloud Flexibility (CF), Cloud Visibility (CV), Cloud Agility (CA), Cloud Interoperability (CI), Cloud Portability (CP) and Cloud Compatibility (CCP) are not discussed here, but we include them as part of the ECSA quality ontology. In summary, the cloud specific quality attributes can be described as

SQII = {CSP, CS, CSE, CSA, CR, CAC, CF, CV, CA, CI, CP, CCP}.

Public Cloud Service Properties

We define the properties of traditional web services in [REF-REF-45][REF-REF-46]. In this section, we specify the following major enterprise cloud service properties.

  • Abstraction

img

Table 5 - Cloud Service Abstraction


  • Standard service interfaces or contracts

Cloud computing delivers services to consumers through standard ESOA style service interfaces, such as web service API and SOAP messaging, RESTful service [REF-REF-46] API and HTTP protocol, event-driven service interface, or other well-defined service interfaces. Figure 12 depicts the interfaces of Amazon storage service S3.


img

Figure 12 - Service Interfaces of Amazon S3


  • Loose Coupling

Loose coupling is an important property of traditional ESOA web services. It is also a very important property of cloud services. The property is one of the service design principles [REF-REF-19]. It is also a criterion for evaluating an ECSA architecture. The reason why it is important is that tight coupling results in expensive cloud service agility, reliability, and scalability for enterprise systems. The loose coupling principles and technologies of ESOA style service, such as asynchronous messaging and messaging queues, can help cloud services to achieve the property.

  • Autonomy

Autonomy represents the ability to self-govern, which is one of the principles of SOA service design [REF-REF-19]. The principle is also one of the properties of enterprise cloud services. The on-demand self-service is one of the key characteristics of cloud computing, which means that cloud services should be able to allow consumers to unilaterally provision computing capabilities, such as server time and network storage, as needed without requiring human interaction with each service provider. If a cloud service lacks self-government, it is hard for it to be adopted by other enterprises. For instance, in Amazon S3, a public storage cloud has been designed such that individual components can make decisions based on local information.

  • Reusability

Traditional ESOA services are reused by their owner and owner's partners. Public cloud services can be reused by not only the service provider, but also by all service consumers who subscribe to the services.

  • Statelessness

Statelessness is another important property of ESOA services [REF-REF-19]. It is even more important for enterprise cloud services due to the more dynamic nature of cloud computing. The statelessness does not mean that there is absolutely no state, but services should keep as little of the computing states or service activities as possible. "There are different levels of statelessness a service design can achieve, depending on the frequency of state deferral and the quantity of state data being deferred. These levels are usually specific to each service capability"[REF-REF-19]. Because the components in cloud services are becoming increasingly transient, they can not support persistent state data. Cloud services should be as stateless as possible by pushing the state data out of the service and separating processing and data as much as possible. For example, Amazon Alexa cloud web search service uses SimpleDB to store process states [REF-REF-54].

  • Composability

In SOA and Cloud Processes.7, we have shown that individual cloud services can be composed, integrated, or aggregated into high-level service processes or workflows for completing a complex enterprise task in clouds. Cloud service composability is essentially the extension of one of the SOA principles into the cloud.

  • Discoverability

Discoverability is another extension of ESOA service property to cloud services. The enterprise cloud services should be discoverable and interpretable for consumers. Many cloud providers extend SOA discoverability by extending the SOA registry technology, such as IBM WebSphere service registry and Microsoft Azure's cloud service registry. We propose the following ECSA dual triangles architecture shown in Figure 13 which shows a cloud registry for cloud services.


img

Figure 13 - Dual Triangles


In the dual triangles, the first triangle is a traditional SOA triangle and the second triangle is a cloud service triangle which consists of a cloud service consumer, a cloud gateway for connecting to public cloud services and a cloud service registry. The two triangles are connected through two registries and the service consumer. The cloud services can be discovered through the cloud registry.

  • Subscription

The subscription is a property only for public cloud services. Traditional ESOA services and private cloud services serve internal consumers of the service provider as part of ESOA system through internal service contracts without paying fees for services. However, the public cloud services are serving consumers of other enterprises. The cloud services are executed through a set of provisioning and subscription services [REF-REF-60].

In this section, we defined cloud quality attributes and discussed several important quality attributes for cloud computing systems. We also described the major properties of public cloud services. The cloud quality attributes and service properties are non-functional constraints of ECSA architectural style, and provide the basis for designing and evaluating the ECSA architecture.

This article will continue in part II.

References

[REF-1] Amazon, EC2, http://aws.amazon.com/ec2/

[REF-2] Amazon, Auto Scaling and load banlance, http://aws.amazon.com/autoscaling/

[REF-3] Amazon.com, Instance Metadata, http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?AESDG-chapter-instancedata.html

[REF-4] Amazon, Amazon Web Services: Overview of Security Processes, 2009. http://awsmedia.s3.amazonaws.com/pdf/ AWS_Security_Whitepaper.pdf

[REF-5] Dustin Amrhein, Bringing Cloud Computing to SOA, http://websphere.sys-con.com/node/981796

[REF-6] T. Anstett, F. Leymann, R. Mietzner and S. Strauch, Towards BPEL in the Cloud: Exploiting Different Delivery Models for the Execution of Business Processes, IEEE 2009 Congress on Services, p.670-685

[REF-7] F. Baader, D. McCuiness, D. Nardi and P.P. Schneider (Eds.), The Description Logic Handbook, Cambridge University Press, 2003

[REF-8] C. Babcock, Lessons From FarmVille, p. 29-57, InformationWeek, Issue 1300, May 16, 2011

[REF-9] BitCurrent, New report on cloud Computing Perforance, 2010, http://www.bitcurrent.com/new-report-on-cloud-performance/#

[REF-10] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg and I. Brandic, Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility, Future Gener. Comput. Syst., Vol. 25, No. 6. (2009), pp. 599-616.

[REF-11] D. Chappell and D. Berry, SOA – Ready for Primetime: The Next-Generation, Grid-Enabled Service-Oriented Architecture, SOA Maganzing, Sept. 2007

[REF-12] CIS, The CIS Security Metrics, 2009, https://www.cisecurity.org/tools2/metrics/CIS_Security_Metrics_v1.0.0.pdf

[REF-13] M. Creeger, Cloud Computing: An Overview, Acmqueue, 2009

[REF-14] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pichin, S. Sivasubramanian and P. Vosshall, Dynamo: Amazon's Highly Available Key-value Store, SOSP'07, Oct. 14-17, USA

[REF-15] DMTF, Open Virtualization Format Specification, 2009, http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf

[REF-16] J. Dong, R. Paul, and L.-J. Zhang, High Assurance Service-Oriented Architecture, IEEE Computer, Volume 41, Issue 8, Pages 22-23, August 2008.

[REF-17] J. Dong, R. Paul, and L.-J. Zhang, High Assurance Service-Oriented Architecture, Springer, 2009.

[REF-18] T. Dornemann, E. Juhnke and B. Freisleben, On-Demand Resource Provisioning for BPEL Workflow Using Amazon's Elastic Compute Cloud, The Proceddings of 9th IEEE/ACM International Symposium on Cloud Computing and the Grid, p. 140-147, 2009.

[REF-19] T. Erl, SOA Principles of Service Design, Pearson Education, 2008

[REF-20] Ian Foster, Yong Zhao, Ioan Raicu and Shiyong Lu, Cloud Computing and Grid Computing 360-Degree Compared, Grid Computing Environments Workshop, 2008. GCE '08 In Grid Computing Environments Workshop, 2008. pp. 1-10.

[REF-21] D. Garlan and B. Schmerl, Architecture-driven modeling and analysis, in Tony Cant (Ed.), Proceedings of the 11th Australian Workshop on Safety Related Programmable Systems (SCS'06), Conferences in Research and Practice in Information Technology, Vol. 69, 2006.

[REF-22] J. Governor, D. Hinchcliffe and D. Nickull, Web 2.0 Architectures, Oreilly Media, May 2009.

[REF-23] Harvard Research Group, Availability Environment Classification, Publication # 5968-6578EUC. http://www.hrgresearch.com/pdf/MarathonHPPAgpl060499d.pdf

[REF-25] Jay Heiser and Mark Nicolett, Assessing the Security Risks of Cloud Computing, 3 June 2008, http://www.gartner.com/DisplayDocument?id=685308

[REF-26] HP, The Cloud and SOA, http://www.hp.com/hpinfo/analystrelations/wp_cloudcomputing_soa_capgemini_hp.pdf

[REF-27] IBM, Seeding the Clouds: Key Infrastructure Elements for Cloud Computing, Feb. 2009. http://www-935.ibm.com/services/uk/cio/pdf/oiw03022usen.pdf

[REF-28] J.S. Kim and D. Garlan, Analyzing Architectural Styles with Alloy, In Proc. Workshop on the Role of Software Architecture for Testing and Analysis (ROSATEA06), Portland, Maine, July 17, 2006

[REF-29] M. Klein and R. Kazman, Attribute-Based Architectural Styles, CMU/SEI-99-TR-022, 1999

[REF-30] G. Lakshman and P. Manish, How the Cloud Stretches the SOA Scope, p. 36-41, V. 21, Architecture Journal 2009

[REF-31] Neal Leavitt, "Is Cloud Computing Really Ready for Prime Time?," Computer, vol. 42, no. 1, pp. 15-20, Jan. 2009, doi:10.1109/MC.2009.20

[REF-32] Loraine Lawson (blog), Identifying the Synergy Between SOA and the Cloud Mar 19, 2009 http://www.itbusinessedge.com/cm/blogs/lawson/identifying-the-synergy-between-soa-and-the-cloud/?cs=31219

[REF-33] Eric Lindsk, IBM Brings SOA to Cloud, http://it.tmcnet.com/topics/it/articles/55460-ibm-brings-soa-the-cloud.htm

[REF-34] D. S. Linthicum, Cloud Computing and SOA Convergence in Your Enterprise, Addison-Wesley, Sept. 2009.

[REF-35] N. Lynch and S. Gilbert, Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services", ACM SIGACT News, Vol. 33 Issue 2 (2002), pp. 51-59

[REF-36] Microsoft, Window Azure Platform, 2009, http://www.microsoft.com/azure

[REF-37] Oracle, Architectural Strategies for Cloud Computing, 2009, http://www.oracle.com/technology/architect/entarch/pdf/architectural_strategies_for_cloud_computing.pdf

[REF-38] L. O'Brien, L. Bass and P. Merson, "Quality Attributes and Service-Oriented Architectures", Technical Note, CMU/SEI-2005-TN-014.

[REF-39] L. O'Brien, L. Bass and P. Merson, "Quality Attributes and Service-Oriented Architectures", In Proceedings of the International Workshop on Systems Development in SOA Environments, 2007, pp. 3-7

[REF-40] The Open Group, SLA Management Handbook, ISBN: 1-931624-51-8, 2004

[REF-41] C. Pahl, S. Giesecke and W. Hasselbring, Ontology-based modeling of architectural styles, Information and Software Technology, 51 (2009) 1739-1749

[REF-42] G. Reese, Cloud Application Architectures, O'Reilly Media, Inc, 2009

[REF-43] SUN, Introduction to Cloud Computing Architecture, 2009, http://www.sun.com/featured-articles/CloudComputing.pdf

[REF-44] L. Tang and J. Dong, "A Survey of Formal Methods for Software Architecture", Proceedings of the International Conference on Software Engineering Theory and Practice, pp. 221-227, 2007.

[REF-45] L. Tang, J. Dong and T. Peng, A Generic Model of Enterprise Service-Oriented Architecture, 4th IEEE International Symposium on Service-Oriented System Engineering (SOSE), pp 1-7, December 2008.

[REF-46] L. Tang, Y. Zhao and J. Dong, Specifying Enterprise Web-Oriented Architecture, in High Assurance Services Computing, Springer, pages 241-260, 2009

[REF-47] L. Tang, J. Dong, T. Peng and W. T. Tsai, Modeling Enterprise Service-Oriented Architectural Styles. Service Oriented Computing and Application (SOCA) Vol. 4, No. 2, pp. 81-107. 2010?

[REF-48] L. Tang, J. Dong, Y. Zhao and L.-J. Zhang, Enterprise Cloud Service Architecture, Proceedings of the 3rd IEEE International Conference on Cloud Computing, pp. 27-34, 2010.

[REF-49] L. Tang, J. Dong and Y. Zhao, SLA-Aware Enterprise Service Computing, Chapter 2 in Book "Performance and Dependability in Service Computing: Concepts, Techniques and Research Directions", IGI Global, p. 26-52, July 2011.

[REF-50] W.T. Tsai, W. Song, R. Paul, Z. Cao and H. Huang, Service-Oriented Dynamic Reconfiguration Framework for Dependable Distributed Computing, in Proceedings of the 28th Annual International Computer Software and Applications Conference, 2004,….

[REF-51] W T. Tsai, Service-Oriented System Engineering: A New Paradigm, Proceedings of the IEEE International Workshop on Service-Oriented System Engineering (SOSE), 2005, pp. 3-6.

[REF-52] W. T. Tsai, C. Fan, Y. Chen, R. Paul, and J. Y. Chung, "Architecture Classification for SOA-based Applications", in Proc. of IEEE 9th International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC), April 2006, pp. 295-302.

[REF-53] W.T. Tsai, Q. Huang, J. Xu, Y. Chen and R. Paul, Ontology-based Dynamic Process Collaboration in Service-Oriented Architecture, in Proceedings of the IEEE International Conference on Service-Oriented Computing and Applications, 2007, …

[REF-54] Jinesh Varia, Cloud Architecture, 2008, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1632

[REF-55] Werner Vogels, Seamlessly Extending the Data Center - Introducing Amazon Virtual Private Cloud, Blogs, http://www.allthingsdistributed.com/2009/08/amazon_virtual_private_cloud.html

[REF-56] Mladen A. Vouk, Cloud Computing – Issues, Research and Implenetations, Proceedings of the 30th International Conference on Information Technology Interfaces, p. 31-40, June 23-26, 2008.

[REF-57] Wikipedia, Measure Network Throughput, http://en.wikipedia.org/wiki/Measuring_network_throughput

[REF-58] Wikipedia, Google App Engine, http://en.wikipedia.org/wiki/Google_App_Engine

[REF-59] Wikipedia, Microsoft Azure Service Platform, http://en.wikipedia.org/wiki/Azure_Services_Platform

[REF-60] Liang-Jie Zhang and Qun Zhou, CCOA: Cloud Computing Open Architecture, IEEE International Conference on Web Services, p. 607-616, 2009.

[REF-61] Liang-Jie Zhang, Jia Zhang and Hong Cai, Services Computing, Springer, Oct. 2007.

[REF-62] Liang-Jie Zhang, Carl K. Chang, E. Feig and R. Grossman, Keynote Panel, Business Cloud: Bringing the Power of SOA and Cloud Computing, pp. Xix, 2008 IEEE International Conference on Services Computing (SCC 2008), July 2008.

[REF-63] Liang-Jie Zhang, Haifei Li and Herman Lam, Towards a Business Process Grid for Utility Computing, IT Professional, V. 6, N. 5, P. 63-64, 2004.