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 II Published: January 14, 2013 • Service Technology Magazine Issue LXIX

Abstract: This is the second article in a two-part article series. Read the first part of this article here.

Evaluating ECSA and Case Studies

In this section, the ECSA is evaluated based on the model and framework we presented in this paper and it is analyzed using several typical enterprise cloud service architectures as our case studies.

Analyzing ECSA Style

ECSA style is defined as a combination of ESOA and ECC in Section 3. Here, we show how to analyze the ECSA style based on [REF-41] and the framework defined in Section 2.

Checking Style Consistency

Based on [REF-41], we should show that the two styles ESOA and ECC are conflict-free, that is, semantically no contradictions should occur. Let us assume that ESOAl and ECCl are interpretations of ESOA and ECC, respectively. Then, it is necessary to show that ESOAlECCl ≠ ø. Obviously, this is true because:

  • Both share the Service concept and the ECC style extends some of the concepts from ESOA. We have shown this in Section 3.2.
  • SClESOASClECC ≠ ø, SIlESOASIlECC ≠ ø, SMlESOASMlECC ≠ ø, SPlESOASPlECC ≠ ø, SQlESOASQlECC ≠ ø

Both styles are complementary with each other and can coexist in an enterprise architecture. Most enterprises are moving to a hybrid cloud architecture in which two styles are applied for designing the next generation enterprise architectures. The style consistency can be checked by another criterion – "A style is consistent if there exists at least one architectural configuration that conforms to the style" [REF-28]. This means that a style is consistent if there is at least one instance of the style. We will show that Amazon.com is an instance of the ECSA style in Subsection 4.4.

Checking Style Extension

ECSA defined in this paper is the top level style which includes abstract service types and other architectural types specified in Section 3. It can be extended. We have introduced a notation   to denote the style extension relationship [REF-49]. We have defined ECSA   ECSA-SLA in [REF-49], in which

ECSA-SLA = (SSLA, CSLA, SSLAI, SSLAM, SSLAP, SSLAQ, SSLAD)

Moreover enterprise private cloud ECSA-EPRC, enterprise service-oriented public cloud ECSA-EPUC and enterprise service-oriented hybrid cloud ECSA-EHYC all can be defined as the sub-styles of ECSA. Therefore:

ECSA   ECSA-EPRC
ECSA   ECSA-EPUC
ECSA   ECSA-EHYC

Private Cloud as Refinement of ESOA

The private cloud defined here is an architectural style – enterprise private cloud service computing, referred to as ECSA-EPRC, is a refinement of the ESOA style. From (2.19) in Section 2,

ESOA = (∑ESOA, ΦESOA).

Also, we know that the traditional service infrastructure (SI) is not elastic and really dynamic. This can be enhanced with:

IaaSSpec = (∑IaaS, ΦIaaS).

which is an internal IaaS specification with elastic and dynamic capacity of cloud IaaS. Obviously,

ESOA ∩ ∑IaaS = ø, so
ECSA-EPRC= ESOA ⊕ (∑IaaS, ΦIaaS).
ESOA + ∑IaaS, ΦESOA + ΦIaaS). (4.1)

Equation (4.1) means that the dynamic infrastructure concept, structure, and description are added into the traditional ESOA style. Since ECSA-EPRC is a refinement of ESOA, it can be a sub-style of ECSA, that is:

ECSA   ECSA-EPRC.

The overall hierarchy of ECSA style and its substyles is depicted as shown in the following Figure 1:


img

Figure 1 - ECSA Style Hierarchy


SO Public Cloud as Refinement of ECC

Enterprise cloud computing as a new distributed computing style is immature and faces many challenges, such as security and service governance. Relatively mature ESOA, such as its standards, service management, and process can help cloud computing to reduce its risks and adaptation by enterprises. From the architectural style point of view, the immature ECC needs to be refined in terms of mature ESOA style. Let enterprise public cloud service computing style = ECSA-EPUC. We show that it is a refinement of ECC with ESOA. From (2.22) in Section 2,

ECC=(∑ECC, ΦECC)

Let SomeESOASpec= (∑SM, ΦSM)

where ∑SM is a part of some specific enterprise server management concepts, such as policy management and enforcement from the ESOA style. Clearly, ∑ECC ∩ ∑SM = ø, so we have:

ECSA-EPUC = ECC ⊕ (∑SM, ΦSM) = (∑ECC + ∑SM, ΦECC + ΦSM). (4.2)

From (4.2), we can see that some of the specific ESOA service management (or governance) concepts, structures, and their descriptions are added to the ECC style, so that ECSA-EPUC is a refinement of ECC with ESOA. That is:

ECSA   ECSA-EPUC

Instance of ECSA Style and Case Studies

If a concrete EA (CEA) satisfies the following conditions, we call the CEA an instance of ECSA.

  1. The CEA can be described by the ECSA ontology (3.2)-(3.4).
  2. The CEA satisfies any one of the following cloud extensions of ESOA or any of the enterprise cloud with service orientation.
    • Enterprise Private Cloud (EPRC)
    • Enterprise Public Cloud (EPUC)
    • Enterprise Hybrid Cloud (EHYC)
  3. The cloud extensions should meet the quality attributes and the public cloud services should satisfy the properties defined in Section Error! Reference source not found...
ECSA-EPRC Style Instance

Figure 2 describes an ESOA CEA with dynamic infrastructure. We show that the CEA is an instance of the ECSA style by the following evaluation form shown in Table 1.


img

Table 1 - Evaluating SOA CEA with EPRC


CEAEPRC = (SEPRC, SEPRC, CEPRC, DEPRC, SIEPRC, SMEPRC, SPEPRC, SQEPRC, SDEPRC) (4.13)

It is easy to specify its ESOA architectural components [REF-46]. We just need to show that it also satisfies EPRC and some specific cloud quality attributes. By the CEA, SDEPRC ≠ ø. Since it delivers IaaS-type of cloud service, either by internal cloud provider or by third party through VPC, it is a private cloud. Therefore, SDEPRCII ≠ ø and SDEPRCIII ≠ ø. Moreover, the CEA satisfies a subset of the cloud quality attributes, such as elastic scalability and flexibility.


img

Figure 2 - ESOA Style CEA with Dynamic Infrastructure


Many existing service oriented enterprises are moving to the kind of ECSA style for building green IT and smart SOA datacenters.

ECSA-EPUC Style Instance

Figure 3 describes a CEA built on IBM cloud and SOA architecture, which can provide public cloud services. Table 2 shows that the EA is an instance of ECSA.


img

Table 2 - Evaluating the CEA Built on IBM Cloud


CEAEPUC = (SEPUC, CEPUC, DEPUC, SIEPUC, SMEPUC, SPEPUC, SQEPUC, SDEPUC), (4.4)

in which

SEPUC={traditional services} ∪ {public cloud services}

CEPUC={traditional service consumers} ∪ {public cloud service consumers}

DEPUC = DIEPUCDIIEPUC

where DIEPUC is SOA data defined in [REF-45][REF-46] and

DIIEPUC ={IBM cloud metadata, cloud SLA data, cloud QoS data, IBM virtualization metadata, cloud service registry data}

SIEPUC={virtualized server, virtualized storage, virtualized network} ∪ {physical server, physical storage, physical network}

SMEPUC={Tivoli User Request Manager, Self-service portal, service lifecycle manager, Tivoli security manager, performance manager, Tivoli monitoring, Usage Accounting management, Virtualization management, policy management, SLA management}

SPEPUC={traditional ESOA business processes} ∪ {cloud business process} ∪ {cloud virtualization orchestration}

SQEPUC={performance, elastic scalability, availability, security, accountability, visibility}

SDEPUC={Prc, HyC} ∪ {SaaS, PaaS, IaaS}


img

Figure 3 - Public Cloud Built on IBM Cloud


ECSA-EHYC Style Instance and Z Cloud

An ESOA style EA with EHYC in enterprise A is shown in Figure 4. We show that it is an instance of ECSA in the evaluation form shown in Table 3.


img

Table 3 - Evaluating ESOA Style EA with EHYC


CEAEHYC = (SEHYC, CEHYC, DEHYC, SIEHYC, SMEHYC, SPEHYC, SQEHYC, SDEHYC), (4.5)


img

Figure 4 - ESOA Style CEA with EHYC


Figure 5 describes the EHYC style instance Zynga hybrid cloud service architecture. Zynga.com is an online game service provider which serves about 250 million active users a month, with 90 millon of them coming from its CityVille addition [REF-8]. It is using Amazon EC2 service, but its business was not impacted by the Amazon 12 hours big EC2 outage on 04/21/2011[REF-8]. Our quality ontology can give us the reasons why Zynga is not impacted by EC2 outage. Based on its architecture, its high scalability is obtained from both scaleOut and scaleIntoCloud (EC2). However its Availability management is based on failover and fail-protect between its Z Cloud datacenter and A Cloud in Amazon datacenter. When Amazon EC2 is down, it is easy to route Zynga’s games’ and users’ traffic to its private Z Cloud with high availability. The lessons learned from Zynga is (1) design should consider multiple failure cases; (2) failover in a single datacenter is not enough; (3) we should consider using multiple ways to prevent single point failures, which include failures over and across datacenters and clouds. Therefore, hybrid cloud service architectures allow enterprises to gain both high scalability and availability.


img

Figure 5 - Zynga Hybrid Cloud Service Architecture


We have evaluated several typical EA and provided the guideline to check if the EA is an instance of ECSA. If a cloud-centric architecture does not adopt the SOA, which means that it does not meet the condition (2), then the cloud architecture is not an instance of ECSA.


img

Figure 6 - Amazon Cloud Architecture


Amazon Cloud Architecture (ACA)

ACA is an instance of ECSA shown in this subsection. Figure 19 is a simplified Amazon Cloud Architecture. Let

SACA= {LBS,EC2,S3,SQS,SDB,EBS,BS}, (4.6)

CACA={CEC2, CS3, CSQS, CSDB}, (4.7)

SIACA={WEB,RT,ELB,AVM,ASP,VPN,DS}, (4.8)

SMACA={CWM,ERM,BM}, (4.9)

SPACA={KVS, PWF}, (4.10)

SDACA={{PrC, PuC, VPC},{IaaS}}, (4.11)

In (4.6)

LBS=Load Balance Service

EC2=Amazon Elastic Compute Cloud Service

S3=Amazon Simple Storage Service

SQS=Amazon Simple Queue Service

SDB=Amazon SimpleDB

EBS=Elastic Block Storage

SQS=Simple Queue Service

BS=Billing Service (Part of Cloud Management)

In (4.7), CEC2, CS3, CSQS, CSDB are Amazon Web Services (AWS) consumers.

(4.8) includes major components in ACA infrastructure:

WEB= Web server infrastructure

RT=Network Router

ELB=Elastic Load Balancer

AVM=Virtual EC2 Instance

ASP=Amazon Service Provider (AppServer)

VPN=Virtual Private Network

DS=Data Storage

(4.9) contains main components of ACA service management:

CWM=Cloud Watch Management

RM=Resource Management

BM=Billing Management

(4.10) is Amazon SOA Process:

KVS=Key Value Store [REF-14]

PWF=Service Provisioning Workflow

(4.11) includes ACA deployment model and service delivery model.

Therefore, we have

CEAACA = (SACA, CACA, DACA, SIACA, SMACA, SPACA, SQACA, SDACA), (4.12)

Table 4 shows that ACA is an instance of ECSA.


img

Table 4 - Evaluating Amazon Cloud Architecture


Although Amazon cloud satisfies the conditions as an instance of ECSA style, it has its weakness in its architecture design. The 12 hours-long outage [REF-8] on 04/21/2011 of Amazon’s IaaS brought many services and websites down. The outage stemmed from a human error in configuration change for its network upgrade in Amazon’s big data center in Northern Virginia. Our cloud quality ontology can provide a good reasoning as to why the disaster outage happened in the Amazon cloud system. First of all, the reliability of the Amazon cloud architecture needs to be improved. The problem began early on Thursday morning and continued into Friday 04/22/2011. The DR duration is longer than 12 hours, so Amazon cloud reliability and DR capacity is relative low. Amazon cloud availability is based on its "availability zones" (see Figure 19), however the availability zones only support failover within the same datacenter. If a disaster occurs, such as the failure of the datacenter on 04/21/2011, there is no mechanism for a datacenter failover. This reduces the availability. Moreover, the Amazon cloud service lacks high visibility to its service consumers, therefore consumers have no idea regarding what was happening. The lessons learned from Amazon public cloud outage are (1) Cloud also has a single point of failure if the failure control and recoverability is not addressed well by design; (2) design tradeoffs of cloud architecture among quality attributes are very important. Supporting failover and DR across datacenters is more expensive than doing that just across availability zones inside a single datacenter. However, we have to consider multiple ways to handle different failures to guarantee high availability. (3) One of the goals of cloud computing is sharing resources. However cloud consumers and cloud providers need to share risks as well. This means that both need to improve their applications to achieve higher security and availability. Some customers of the Amazon cloud, such as Zynga and Netflix, were not impacted by Amazon cloud outage, since they have better architecture design for failure. However, cloud providers should increase their architecture transparency and system visibility, so that their consumers can make their DR plan and improve their design for failure.

Related Work

Current work on bridging ESOA and Cloud Computing (CC) can be classified in the following categories: (1) Specifying and analyzing cloud service-oriented architectural style or framework; (2) CC and SOA convergence in enterprises; (3) creating new approaches combining SOA approaches and cloud computing which includes bringing SOA best practices into cloud computing and adopting cloud computing power for improving existing ESOA architectures.

Zhang and Zhou [REF-60][REF-62] proposed a Cloud Computing Open Architecture (CCOA). The CCOA is a cloud computing centric service-oriented architecture framework which bridges the power of SOA and virtualization in the context of Cloud Computing ecosystem. Seven principles of cloud computing architecture are also presented in [REF-60]. We proposed a new hybrid architecture style modeled and analyzed by a framework defined in Section 2, which is based on the ontology-based modeling technology of software architectural styles [REF-41]. This paper extends the technology from two aspects, namely, (1) it extends five major concepts for describing traditional architectural styles to nine main concepts for modeling and analyzing enterprise architectural styles; (2) it extends the traditional static configuration to dynamic infrastructure.

Many SOA software venders, such as IBM [REF-27], HP [REF-26], SUN [REF-43], Oracle [REF-37] and Microsoft [REF-36], proposed their new software product architectural models and frameworks which combine the SOA and cloud computing powers. The model presented in this paper can be used for evaluating the architectures of the different approaches.

Linthicum presents the dream team of cloud computing and SOA in [REF-34]. He points out that SOA and cloud computing provide a great deal of value when they work together. His book describes the relationship of SOA and cloud computing and guides enterprises on how to achieve cloud computing and SOA convergence step-by-step. We describe the relationship of SOA and cloud computing through the hybrid architectural style.

Lakshman [REF-30] shows how cloud streches the SOA scope and proposes a process for idendifying cloud scenarios. Its case studies show that the Microsoft cloud Azure integrates into the enterprise SOA system.

Lawson [REF-32] points out that SOA can help cloud computing in three aspects: (1) One can move services around as needed – including to a cloud server – to address pressing business needs. (2) One can take advantage of virtualization or, as Linthicum explains, address "core applications as logical instances that may run on any number of physical server instances, providing better resource utilization and scalability." (3) One can create mashups or on-the-fly composite apps with services and tap the cloud's computing power.

Varia [REF-54] introduces the cloud architectures of Amazon Web Services (AWS). AWS is a typical example on adopting ESOA’s web services (SOAP or REST) to their cloud architectures. DeCandia, et al., [REF-14] present Amazon service-oriented cloud architecture through Dynamo design and show how SOA governance can help clouds in achieving high performance and availability.

Dornemann [REF-18] proposes an approach that extends an open source SOA BPEL implementation to use Amazon’s EC2 for providing the process with dynamic resources. Anstett and Leymann [REF-6] discuss the BPEL in the cloud, which utilize different service delivery models for executing business processes.

Several research works, such as [REF-42][REF-54][REF-58], describe Amazon cloud, Google cloud, and Salesforce cloud. Their architectures can be shown as the instances of the hybrid style ECSA.

Compared with all other approaches for modeling enterprise cloud service-oriented architecture, our approach is different in the following aspects:

  • We define ECSA as a new hybrid architectural style with ESOA style and cloud computing style, which is an abstraction of the family enterprise architectures building on ESOA and Cloud computing.
  • The ECSA is specified based on our framework in Section 2. It is based on ontology modeling technology, but our work extends the technology in some aspects. The ECSA as a top style is extensible. It can have several substyles – Private ECSA style, Public ECSA style, and hybrid ECSA style.
  • Our model and style specification emphasize quality constraints. We define and analyze most of the important quality attributes of ECSA based on quality ontology. They can be applied not only for analyzing and evaluating ECSA systems, but also for guiding the design of the ECSA architecture.

Conclusion

SOA-centric enterprises are now extending existing enterprise SOA architectures and investments into the Cloud to address new business pressures and opportunities. Cloud-centric enterprises are now adopting ESOA principles and governance for improving the quality of cloud services and making cloud computing to be adopted by other enterprises. Therefore, the research of how to make ESOA and CC work together with new SOA and CC hybrid architectural styles is very important and getting more attention from both researchers and industry.

In this paper, we define an ontology framework for modeling and analyzing cloud service-oriented architectural style, which combines both ESOA style [REF-45][REF-46] and cloud computing style in a synergistic way. Our major contributions are:

  • Define and specify the ECSA by the ontology-based framework. It gives an insight into the design principles, structures, and behaviors for both functional and non-functional aspects of ECSA architectures.
  • Specifically, build cloud quality attribute tradeoff models and analyze them with metrics and relationship formally and informally.
  • Propose a dual triangle model of ECSA architecture.
  • Define the instance concept of ECSA.
  • Evaluate several ECSA architectures based on the instance concept.

The methodology and model proposed in the paper can be used for:

  • Analyzing and evaluating broad-types of concrete enterprise architectures.
  • Guiding the design of cloud-enabled ESOA system or ESOA style cloud computing systems.

Some future research directions include:

  • Application of the ontology-based framework.
  • Tradeoff analysis of ECSA architectural quality attributes.
  • Architecture of automatic SLA and policy enforcement to ECSA system.
  • Formal methods for rigorously analyzing and verifying ECSA styles and concrete architectures.

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-24] Harvard Research Group, Cloud Computing – Introduction

[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.