Enterprise SOA vs Ecosystem SOA, Private Cloud Computing vs Public Cloud Computing, Choreography vs Orchestration: Much Violent Agreement

Ownership Domain Confusion Reigns

There seems to be a great deal of confusion and much violent agreement regarding terminology within SOA and Cloud Computing.  In particular there is confusion within the SOA community regarding the difference between Choreography and Orchestration (see my post SOA Choreography and Orchestration Comparison), and much confusion about Enterprise SOA versus Ecosystem SOA and how they relate to Private versus Public Cloud Computing.  Actually, all of these relate in a very straightforward manner, once the definitions of each is understood, and once the proper architectural framework is applied.  That framework is based on the Ownership Domain of the Application.  The Ownership Domain is defined as the person or persons, or organization or organizations that either own and maintain the application code.  If there is one owner/steward for the installation, configuration, and maintenance of the code, then the application resides in a single ownership domain.  If  the code runs on an IT infrastructure with a single owner/steward, then it is running in a "Private Cloud", if the code runs within two or more IT infrastructure ownership domains, it is running on in a "Public Cloud".

Let's take a look these concepts using this Ownership domain framework.

Single Ownership Domain Composite Applications

An Enterprise SOA-based composite application is one where all of the application's Service Components are within a single organizational ownership domain.  Characteristics and attributes of the Enterprise SOA-based application include:

• It supports a high-value producing process.  Organization's have two types of processes, those that have some competitive advantage, which produce value for the organization and those supporting processes that are required by the organization to "stay in business".  These are processes like accounting, HR, and finance.
• Enterprise SOA uses:
• Orchestration to assemble the Composite Application because all of the linkages among the various Service Components are controlled by the personnel within the ownership domain.
• An ESB to interconnect the Service Components during Composite Application operation.  In fact, the key characteristic of an Enterprise SOA and an Enterprise Composite Application is that it uses the ESB within a single ownership domain.  (while most ESB suppliers add many functions to their ESB product offerings, functionally, the ESB is simply an application layer communications function.)
• An internal UDDI as the repository of Service Component descriptions (for those using Web Services, this would be the WSDL repository.
• A Private Cloud enables and supports Enterprise SOA.  The caveat is that only the top two layers of the Cloud architecture (the SAAS and PAAS) are required to be within the single ownership domain.  However, by definition, an Enterprise SOA-based application can never operate within the Public Cloud.

Multiple Ownership Domain Composite Applications

An Ecosystem SOA-based composite application is one where the application's Service Components operation across multiple organizational ownership domains.  Characteristics and attributes of the Ecosystem SOA-based application include:

• Typically, it supports, organizational supporting and capacity value producing processes.  These are all processes that are not part of the core competence of the organization, the ones that produce the organization's competitive advantage.  Personnel within an organization may also implement an Ecosystem SOA-based application for applications support ephemeral processes, like a research effort.
• Ecosystem SOA uses:
• Choreography to assemble the application since choreography is much more dynamic during the execution of a Composite Application.  For example, if a Composite Application in one ownership domain uses a Service Component in another, and the owner of the second decides to change the location of the Sevice Component, without the use of Choreography, the Composite Application is very likely to fail from not finding the Service Component.
• the UDDI to a much greater degree than for a Composite Application in an Enterprise SOA. Choreography is much more dependent on UDDI repositories for the reasons just described.  However, the process of discovery during execution is likely to significantly reduce the performance and throughput of the Composite Application; so this is a tradeoff between process effectiveness and cost efficiency.
• Internet instead of the ESB.  The fundamental function of the ESB is to enable and support communications among the Service Components of a Composite Application, that is, it supports application layer communications within an Enterprise (or organization).  However, with Ecosystem SOA, interfacing with Service Components across the Internet is the norm.  While there is much discussion about cross-domain ESBs, the issue is difficult given the security requirement involved in application layer communications across the boundaries.
• A Public Cloud enables and supports Ecosystem SOA.  The Public Cloud is by definition, a multi-ownership domain entity.  Therefore, the Platform as a Service (PaaS) layer and the Infrastructure as a Service (IaaS) layer perfectly support Ecosystem SOA.