> Archive > Issue LXVI, September 2012 > A Case for the Service Orchestrator: Enabling Ubiquitous Ecosystem Performance (Why ACID and BASE Transaction...
Mark Skilton

Mark Skilton


Mark Skilton is a Global Director of Strategy at Capgemini Infrastructure Services. He is also Co-Chair of the Cloud Computing Work Group at The Open Group, an international standards body. His current responsibilities at Capgemini include strategy development, service offer portfolio design, center of excellence development, and leader of the global Government-Cloud interdisciplinary Offer Development. He is also the author of the Capgemini University Cloud Computing Global Education Course. Mark is a recognized expert on cloud computing. His recent publications include:

Editor of "Cloud Computing for Business- The Open group Guide" - Published Sept 2011, Van Haren

Contributing Case Study Author on Cloud Computing for Industry in the 2nd Edition "Handbook of Outsourcing and Off-shoring"; an internationally recognized leading book

Author of the "Building Cloud Computing ROI" in British Computer Society Annual Journal 2011 Syndicated in, ZDnet, Computerweekly, CloudComputingJournal, Reuters, Forbes and others.


rss  subscribe to this author


A Case for the Service Orchestrator: Enabling Ubiquitous Ecosystem Performance (Why ACID and BASE Transaction Consistency Will Not Be Enough)

Published: September 20th, 2012 • Service Technology Magazine Issue LXVI PDF

Abstract: Not "one size fits all." A common misconception in cloud computing is the ability to use "select and go" IT services at will as if they are "Lego bricks" that plug together like a model set of processes. Nothing could be further from the truth in practice. From a consumer perspective, a cloud may involve this user experience of self-service usability on-demand, and the purchasing contracts, terms and conditions may define and constrain the use of these services. But from the provider perspective, the technical service architecture that enables consistency in performance availability and security, let alone if this then becomes an integrated solution, is not trivial. Cloud computing is a distributed architecture connecting different devices, networks and computing components together with different management and control systems to provide software, hardware and content management provisioning and metering services. This is not a "one size fits all" architecture, but instead a range of criteria and design choices that can affect whether the cloud technology can actually support the workload characteristics and service levels that the consumer desires. How accessibility and scalability are established through a cloud architecture can impact the very flexibility, cost, performance and lock-in/out of the offered services. This paper examines the different predominant varieties of cloud architecture styles and the design characteristics that affect their elastic performance. The aim is to raise awareness of these design criteria in the provisioning and selection stage of cloud services as well as during the software development and delivery lifecycles.

Types of Architecture Systems for Cloud Computing

The evolution of architecture management system styles continues on from the client-server era into new expanded roles exploring distributed architectures and revised standards. The developing portability and interoperability issues need to account for these changing architectural styles. The following diagram illustrates three major styles that separate the way IT resources, relationships and actions may be constructed in today's enterprise computing architectures.


Figure 1

  • Distributed - Distributed computing seen in examples of noSQL architecture and in loose coupled protocols such as RESTful interfaces over HTTP define a federated resource identifier, representation and hypermedia approach. HTML, XML, JSON and metadata schema are used to define a representation of the resource. Hypermedia enable actions to be carriers between clients and servers with selected resources using this light weight protocol. Concurrency and parallel computing are also aspects of distributed processing systems that seek to manage highly scalable data and computing seen in examples of big data and grid computing. Distributed architectures can have collections of client (consumer) centric or server (provider) centric resources and operations that meet specific needs spread across a decentralized, distributed environment.
  • Declarative - Operational declarations can be found in the example of SOAP protocol, the WSDL specification, and the widely used relational database and SQL system specifications. Container partitioning, specific appliance-style platforms and resource management enabling strong resource allocation allow for the central management style of the architecture. Extensions of the WSDL approach can be found in an example of business process declarative specification such as WS-BPEL that seeks to orchestrate specific Web services. Declarative architecture styles are often employed to develop functionally expansive environments.
  • Cooperative - Cooperative architectures can define shared communities of resources that might be described as tertiary role models where nodes can be both suppliers, consumers and resources all at the same time (potentially).

Orchestration Versus Choreography

RESTful protocol versus SOAP and WSDL protocols mark a clear delineation between types of message protocols that can result in different payload and execution specifications. The aim here is not to state that one architectural style is intrinsically better than another, but to instead highlight that they have different characteristics and performance issues. The comparison of orchestration versus choreography is a case in point that draws upon managed directed outcomes versus more indirect approaches to the execution of a runtime service.

Orchestration seeks to define directly executable specifications for a managed set of tasks.

  • OASIS WS-BPEL - In WS-BPEL this is within a business process. WS-BPEL defines executable and abstract process orchestration. The abstract process is an independent partial process. An executable process is defined as the ability to establish a set of Web services that invoke a process stage. Within the steps of the execution the results may alter according to the condition of the rules within the steps. Pi-calculus is a type of process calculus that formulates features of concurrent computations that may change the network of operations during the computation. WS-BPEL is not restricted to WSDL but can also call REST, FTP, STMP and other types of protocols.

Choreography seeks to define a protocol for interactions between resources and nodes via interfaces. The difference in choreography is that the direction of the execution is not orchestrated but a feature of the protocol used.

An examination of two current developments in the standards of DMTF and OASIS illustrate the type of next generation schemas that seek to define the management of cloud-enabled interfaces and resources:

  • DMTF CIMI - Cloud Management Interface Using REST Interface and HTTP - The focus of this specification is on the "Cloud Entry Point" and the schema interface for the management of cloud resources. While it is focused on infrastructure, it is not restricted to this and can be applied to PaaS and SaaS. The use of JSON and XML representations define serialization methods of an interface protocol. The CIMI scope is still a work in progress at the time of this writing and includes a cloud resource management schema for requests using a REST protocol to perform various CRUD operations.
    • URI identifiers, headers, credentials, operations CRUD, templates, Configs, images and entities specific to a set of cloud resources remotely via REST Protocol Request. These cloud resources can include systems, machines, volumes, networks, and credentials to create, update, delete, start and stop functions.
  • OASIS TOSCA - Topology and Orchestration Specification for Cloud Applications -This specification is a distributed node model and orchestration-specific for use in operations across nodes, using a similar concept of templates and types to define a set of orchestrated operations via interfaces. The specification is based on WSDL and includes references to types of templates for types of nodes that can include, for example, apps servers, process engines and process models. This level of orchestration abstracts nodes and interfaces into a topology plan that executes the service template.
    • Topology template, node types, relationship types, plans, group template and node template.

The Convergence of Multi-tier Distributed Architectures

These architectural styles are evident in many modern enterprise architectures and the distinction between topologies is often less well-defined. What is evident is that the rise of internet networks and open APIs has led to a change from basic client-server architecture to a potential range of multi-tier architectures that may be distributed, dedicated or a combination of both in cooperative systems. In the ubiquity of the different types of systems and protocols and resources used, the potential is to connect many different solution architectures together. The following table illustrates a few examples.


Table 1

Limitations of Distributed Systems

The performance of these systems can be seen in terms of:

  • Operational Performance - the consistency, service level and security achieved
  • Connectivity Performance - the interoperability , portability and robustness (reversibility) of the system
  • Strategic Performance - the business outcome performance and operational competencies established

Operational Performance

Operational characteristics of database transactions has be described in terms of consistency models.

ACID Transactions Styles - Atomicity, Consistency, Isolation, Durability -are found in declarative control system environments, sometimes referred to as "all or nothing, consistency". An alternative perspective of this is BASE (basically available, software state services with eventual consistency) that represents a federated state model. RESTful/HTTP standards development and no-SQL architectures are examples of BASE styles that represent a greater focus on distributed processing.

In comparing ACID and BASE database type architectural issues there are a number of common implications that are evident in both database transaction consistency styles.


Table 2

The contention is that both ACID and BASE architecture styles can function together in different scenarios. The conjecture is that modern Web services are distributed architectures where federated access to cloud resources may necessitate a less coupled architectural style such as BASE and some RESTful styles. Alternative SOAP/WSDL and appliance-centric homogenous architectures can also offer the benefits of centralized control over resources and available assets . The take-away statement here is that either can work in specific scenarios of a solution architecture.

Beyond the management of loose or strong coupled resources (devices, applications, infrastructure, or data) and hypermedia links to distributed or controlled access is the question that the overall integrity of such architecture can work in practice. In the extreme boundary case of a private, closed system the scenario has different demands. Or consider a closed set of resources with no external interfaces or coupling. In this situation the system could be a pure dedicated architecture that is also homogenous in its components, with all the same configurations being used. The alternative in practice is found in real world cases with a mixture of technologies, distributed connections and heterogeneous systems and interfaces. The concept of decentralized systems that are distributed across multiple organizational boundaries, multiple users and multiple end points and connections is precisely the state of the internet and many enterprise systems. Whether these end points terminate inside a public, private cloud or a network service provider, network control is part of the security domain question, but keep in mind that the bigger issue is how to manage and leverage the consistency of this distributed architecture to an environment's advantage.

The CAP Theorem of distributed computing states that "it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees: Consistency, Availability and Partitioning Tolerance". (Reference: Brewer Conjecture 2000, Gilbert, Lynch Formal Proof 2002).


Figure 2

The fallacies of distributed systems (refer to David Deutsch and Arnon Rotem-Gal-Oz 1993 and Gosling 1997) provides an interesting extreme boundary condition for a distributed systems environment. Many of these boundary conditions are from the pre-cloud computing era, if we state cloud computing to have occurred after around 2005 ( Gosling). The idea that network-centricity is a homogeneous boundary condition of the systems environment can be described in practice to be either homogenous or heterogeneous in terms of its construction, and the measure of distribution of equivalent architecture components. This equivalence can be applied to data center -centricity, application centricity, device centricity or any other tier within a system architecture. This can be applied to a multi-tier architecture environment that can be made up of multiple component tiers, perhaps segregated across device, network, server, database, OS, application, and data groupings. These may be distributed through on-premise and off-premise architectures or through a combination of these. These boundaries can affect the types of systems and extensions found in practice (for more information on this, see Introduction to CIEL - Cloud Interactive Ecosystem Language Project - The Open Group Aug 2012).


Figure 3

This concept can be further expanded into organizational and social network boundaries adapted to the topological design of these environments.


Figure 4

This leads to specific open and closed architectural domains that are distributed, and therefore subject, to Brewers Theorem and conjectures of performance. The issue however is what outcomes can result from this.

Characteristics of distributed systems and service management philosophies need to be appropriately leveraged to manage the consistency of the overall service. The Brewers Theorem can be expanded and applied to ACID and BASE architecture styles. Specifically, enterprise- level service conditions need to be higher than residential systems that don't carry the same conditions of use; but being consistent and available to a tenant is only part of the total value.

  • Consistency - Consistency of the overall service may be repeatable, but can it be guaranteed in specific conditions of use. In enterprise systems there is the concept of the guaranteed consistency of service, where it becomes not a forecast service but a planned consistent service level to be maintained.
  • Availability - Availability is the measurement of uptime and downtime in an environment, and the characteristic of being available when required. But having the right "type" of system available is the larger question here. If infrastructure and applications are available in non-critical business systems this is of less competitive value than maintaining the high availability of business-critical systems.
  • Partition Tolerance - Partition encapsulation can enable resource consistency for services or products within an environment. The underpinning characteristics must also ensure fidelity of the partition that include trust/security controls as well as resource partition tolerance.


Figure 5

Operational, Connectivity and Strategic Performance

The conclusions of these extensions can be summarized in instrumentation and standards that may enable trade-offs in management of distributed systems. While aggregation and strong closed partitioning of environments may minimize the challenges to the maintaining the consistency of distributed services, the wider business model environment suggests a more federated real world environment combining many types of systems, resources and connections. Orchestration is required to maintain the integrity and performance of the boundary conditions of the systems' architectures.

  • Consistency and Guarantees - The correct orchestration of systems management areas of one (or many) system resources is needed to successfully navigate through the many interfaces and potential points of failure.

    Orchestration of multiple failure points can better support service management and version controls.

  • Availability and Effectiveness - Availability needs to also manage the long-tail availability of sourced resources such that they serve more than the availability of individual components. This is the wider range of concern for potential architectural solutions offering resource availability in a cloud-enabled ecosystem.

    The target outcome of resource availability in systems needs to be focused upon the effectiveness of business process performance at a sustainable level that is required by the enterprise. Process-based orchestration is targeted at the management of state and stateless activities (and their actionable results) guided by business performance metric comparisons with aligned operational metrics.

  • Partition Tolerance and Fidelity - Resource management needs to successfully orchestrate the portfolio of IT and business assets inside and outside an organization in a way that best serves the needs of consumers and providers alike.

    Developing the configuration consistency of template resources is part of the standardization model often employed in enterprises, but this needs orchestration across different tenants and sources inside (and outside) the reach of control often available to a consumer or provider. Nonetheless, the preservation of elastic characteristics within "acceptable conditions of use" goals that are within the tolerance levels of the distributed system is paramount.


Figure 6


This paper has looked into some of the issues in distributed architectures that are often glossed over in the sales talk, advertising and in common expectations often championed throughout the contemporary marketplace of cloud technologies.

Establishing an effective cloud portfolio and cloud strategy in your company requires more than the promises of some brochure showing a typical architecture, or relying on copying a vendor cloud strategy that may or may not fit your organization business strategy.

Professional strategists and effective reliable standards-based portfolio management drive this beyond understanding the connection between the capabilities you need inside and outside your company, and what can be established as private, public and hybrid. SaaS and PaaS enable new types of services to be fully realized through commodity and custom software. In modern computing environments, IaaS means datacenters, networks and virtual devices that play a critical role in delivering new mobile and distributed experiences and capabilities for employees, customers and markets through cloud-enabled capabilities.

But there is potential danger here. The danger is that you end up with a collection of disconnected SaaS, PaaS, and IaaS services that do not operate cohesively if you treat the strategy and solution behind their selection as only a sales or support decision. Enterprises succeeding in the cloud space are treating cloud architecture as a digital transformation process for their people, company, and products. To succeed, the cloud services are underpinned by professional architecture design that manage consistency, availability and tolerance with the appropriate system management tools, skills, certifications and disciplines.


"Cloud Computing Synopsis and recommendations" NIST , May 29 2012

"Cloudy Concepts: IaaS, PaaS, SaaS, MaaS, CaaS & XaaS" ZDnet Oct 30, 2011

Deployment Patterns (Microsoft Enterprise Architecture, Patterns and Practices)

"Patterns of Enterprise Application Architecture" Martin Fowler, Addison Wesley, 2002

ACID Principles of Transaction-Oriented Database Recovery - Harder, Reuter, Dec 1983 ACM Computing Surveys 15(4) : 287-317 doi:10. 1145/289.291. Retrieved 2009-01-16

"Brewer's Conjecture and the feasibility of consistent, available, partition-tolerant web services" ACM SIGACT News, Vol 33 Issue 2 (2002) pg 51-59

"Eight fallacies of Distributed Computing" Peter Deutsch, 1993

"Deutsch's Fallacies, 10 Years After"

"SOA Ontology Technical Standard : Service, Service Contract, and Service Interface"

DMTF CIMI with REST Interface over HTTP - Draft Version

OASIS TOSAC Draft working Specification April 2012