Home >

SOA Critique

A collection of essays about the SOA hype.

Posted on August 29, 2013 by Ernesto Garbarino

Introduction

These is a consolidation of various blog posts and articles I had published when consulting under Tesira Ltd about how hyped the SOA market was at the time.

What is SOA?

“No one understands what SOA really is” is the opening line that we often hear from professionals at various presentations. To us, this roughly translates to: “You would buy into it if you understood it, and I am the prophet who is going to show you the way”. This is, in our opinion, a condescending way of treating potential customers.

The reason we decided to offer this free guide is that we did not want customers to look at SOA as a form of general dogma that can only be embraced or rejected in its entirety. Instead, we concluded that it was better to address every single aspect that we have come across in our experience, as being remotely associated with SOA, regardless of what SOA philosophers believe to be “true SOA” or not. Our goal is that you can decide for yourself whether there is something worthwhile in anything somehow connected to SOA and, most importantly, whether you will spend your organisation’s money on it.

What we ask you is not to trust us either. We are not the last “genuine” prophets of SOA; such a claim would be outrageous. In fact we would like to be seen as SOA debunkers more than anything else. It is precisely the practice of software vendors and system integrators of breaking into businesses to dump unnecessary products and consultancy services—all in the name of SOA—that we firmly oppose.

This is the reason why we prefer to focus on the bigger picture—Business Integration— and treat SOA as one possible tactical approach.

We have collected observations that are free from bias to the extent of our experience; we cannot have possibly been in the shoes of so many other professionals who have faced scenarios which are unfamiliar to us. Their story is missing in this guide and we suggest that you talk with as many people as possible to form a balanced view. What’s more, trust your own technical team, the truth is often at home—in your organisation—and it is certainly not in the monopoly of consultancies like ours.

Let us now define SOA for good.

SOA stands for Service-Oriented Architecture. Services are Application Programming Interfaces (APIs) with special qualities which render them different from those APIs outside the service category. Therefore, the whole discussion about SOA is centred around the differences in quality between extraordinary APIs—services—and ordinary APIs.

APIs are the building blocks of all complete software products—ranging from operating systems to the applications than run on them (spreadsheets, smartphone apps and so on). In a nutshell, APIs constitute software artefacts—building materials—for computer programmers.

The “orientation” in SOA institutionalises the bias towards services, as opposed to ordinary APIs, in the same way that Objected-Oriented Programming (OOP) institutionalises the bias towards modelling software artefacts as objects rather than as an “ordinary” mixture of data and functions.

The SOA industry makes a judgement in regards to what qualities make services different from ordinary APIs (for example, reusability) and what benefits are expected from the observance of such qualities (for example, cost reduction).

Furthermore, the industry assumes that the adopting organisation suffers from a range of underlying problems for which SOA products and services are presented as an all-encompassing cure. Sadly, it is often the case that customers end up believing that they are “missing out” on the next wave of technological progress and that they had better jump (spend) now, before they become stuck in the past.

As if this was not enough, the SOA industry has created a language of their own with the purpose of infiltrating the power structures of organisations; the so-called CxO layer in the private sector—the one that approves the fattest cheques. The aim of the embellished language used in SOA is to remove, as much as possible, all traces of anything that may come across as technical, “geeky” or programming-centric—all of that is dirty and it is to be outsourced to India after all. The ultimate goal is to present SOA as a “business investment” as opposed to some sort of unproductive technical gizmo for the IT department.

To further confuse the customer, the idea that “one cannot buy an SOA, one can only build it”, is introduced. This is an even more dangerous take on SOA since it confers on it a pseudo-mystical ideological dimension—akin to “socialism is a way towards communism”. That is to say, if everything fails —like the IT department bleeding expenses—it doesn’t matter because you are supposedly not buying (investing) in an SOA; you are just working “towards it”. The reality is that you will spend—and do it dearly. The SOA market was reported to be worth $7.1 billion in 2012.1 If this figure is accurate, then a significant number of organisations are certainly buying an SOA rather than building one.

Other than the word “service” itself, which we have already established as a code-name for “extraordinary API”, you will find that we have distilled most SOA buzz words down to ordinary explanations so that all the mystery can be removed, and SOA can be understood for what it is: a manufacturing approach for software products. So yes, SOA is mostly to do with software, and little to do with business.

SOA as Defined by Vendors and Authors

This is a collection of SOA definitions provided by a variety of vendors and authors. For each definition, we identify touted principles and properties and promised business benefit.

Accenture

From Accenture’s Services Overview, Service-Oriented Architecture:

Service-oriented architecture (SOA) can help organizations boost business performance while reducing IT costs and enhancing the flexibility of business processes.

Service-oriented architectures (SOAs) connect the modern enterprise, providing the essential links between applications, platforms, business processes and data sources. But many enterprises, having embraced SOA for everything from ERP and mobile devices to social networking and cloud computing, now face challenges. Namely, they need to advance their SOA capabilities, programs and oversight to create a more service-oriented enterprise.

The business advantages of SOA include:

Accessibility: Deliver data and collaboration capabilities to knowledge workers via PCs, portals, mobile devices or composite applications, regardless of where that data resides.

Agility: Create a flexible SOA foundation that supports quick and cost-effective business strategy changes, by separating business processes from technology.

Analysis: Enable rapid decision making by giving business leaders real-time, mission-critical business intelligence, backed by analytics, dashboards, reporting tools and mobile delivery.

Efficiency: Apply SOA to consolidate, streamline and eliminate existing applications, as well as to embrace applications, infrastructure and platforms based in the cloud.

Value: Connect old and new technology investments, as well as mash-ups, social media, the cloud and more, in a secure, controlled and cost-effective manner.

Fetched from http://www.accenture.com/us-en/Pages/service-technology-soa-overview.aspx on 06/08/2012

Touted Principles and Properties

Promised Business Benefit

Comments

It is amusing that Accenture recognises the “challenges” of embracing SOA but proposes as a solution to do more of what caused the challenges in the first place!

…but many enterprises, having embraced SOA for everything from ERP and mobile devices to social networking and cloud computing, now face challenges. Namely, they need to advance their SOA capabilities, programs and oversight to create a more service-oriented enterprise.

Capgemini

From Capgemini’s Services and Solutions page:

Our thinking is matched only by our capability to make SOA real. We are leading the field in developing open standards and our own Integrated Architecture Framework. We have our own Infrastructure Design Framework and our own roadmap for developing a Service-Oriented Infrastructure. We have first-class integration skills with the right tools and centers to support the process. We have alliances with all of the key players and are influential members of both The Open Group and OASIS.

Over the last few years, Capgemini has been instrumental in the development of new standards for The Open Group around Service Orientation. These standards relate to a number of issues such as SOA Governance, SOA Ontology and SOA Maturity (OSIMM) and Capgemini has supported the development of guidelines on how to use The Open Group Architecture Forum (TOGAF) to govern SOA solutions. Recent releases of the SOA standards (SOA Reference Architecture, Cloud Computing Infrastructure and OSIMM 2.0) serve to fill the gaps of architecture standards for SOA.

The release of these new SOA standards from The Open Group reinforce the mantra that re-use and best-practice are extremely important to help organizations leverage emerging business technologies and create efficient and effective IT models which enable them to save time, money and effort in their SOA and Cloud Computing journey, said Mats Gejnevall, co-chair The Open Group SOA Work Group and Global Enterprise Architect, Capgemini, January 2012

Our track record in delivering SOA success stories for a broad range of organizations speaks for itself. We’re a founding partner of the leading Next Generation Insights SOE knowledge website.

Capgemini uses the concept of the services-oriented enterprise (SOE) to stress the importance of achieving the desired business goals or business change. But rather than sell this as a proposition to customers, the firm prefers to tackle business issues — such as supply chain reinvention for CPG businesses — and uses SOE and SOA frameworks and approaches in meeting those issues as a matter of course. Forrester, “Identifying Service Providers’ SOA Value” by Andrew Parker, John Rymer and Caroline Hoekendijk, February 2006

Fetched from http://www.capgemini.com/services-and-solutions/technology/soa/overview/ on 31/08/2012

Touted Principles and Properties

Promised Business Benefit

HP

From HP’s Service-oriented Architecture page:

Service-oriented architecture (SOA) is an architectural approach that enables your IT organisation to modernise your applications and improve business agility. Typically, your company may respond to new business needs by building or acquiring single-purpose applications. SOA allows you to plan, build and deliver capabilities as easily combined, well-described, re-useable services. SOA provides core business and IT capabilities as re-useable modules, otherwise known as shared services. These services are:

Through the use of shared services, you can respond more quickly and efficiently to new business demands. You can also combine these services into new business applications or composite applications to support new business processes.

Fetched from http://h71028.www7.hp.com/enterprise/w1/en/technologies/soa-overview.html on 20/08/2012.

Touted Principles and Properties

Promised Business Benefit

Gartner

From Gartner’s IT Glossary:

Service-oriented architecture (SOA) is a design paradigm and discipline that helps IT meet business demands. Some organizations realize significant benefits using SOA including faster time to market, lower costs, better application consistency and increased agility. SOA reduces redundancy and increases usability, maintainability and value. This produces interoperable, modular systems that are easier to use and maintain. SOA creates simpler and faster systems that increase agility and reduce total cost of ownership (TCO).

Touted Principles and Properties

Promised Business Benefit

Fetched from http://www.gartner.com/it-glossary/service-oriented-architecture-soa/ on 06/08/2013.

IBM

From “What are the major benefits of SOA?”—IBM Service-Oriented Architecture FAQ:

SOA helps create greater alignment between IT and line of business while generating more flexibility - IT flexibility to support greater business flexibility. Your business processes are changing faster and faster and global competition requires the flexibility that SOA can provide. SOA can help you get better reuse out of your existing IT investments as well as the new services you’re developing today. SOA makes integration of your IT investments easier by making use of well-defined interfaces between services. SOA also provides an architectural model for integrating business partners’, customers’ and suppliers’ services into an enterprise’s business processes. This reduces cost and improves customer satisfaction. Finally, SOA reduces business risk and exposure by helping you comply with proliferating government regulations, such as (in the United States) Sarbanes-Oxley, the US Patriot Act, etc.

Touted Principles and Properties

Promised Business Benefit

Fetched from http://www-01.ibm.com/software/solutions/soa/faqs.html#3 on 06/09/2013.

Infosys

From Infosys’ SOA Services, Consulting:

Service-Oriented Architecture (SOA) is an architectural strategy that helps achieve tighter business-IT alignment. SOA provides agility - a crucial requirement for sustained business competitiveness - to enterprises by creating flexible business processes and offering practical and cost-effective means of integration. It uses standards-based interfaces to facilitate needs-based access to IT resources spread over an enterprise network.

Touted Principles and Properties

Promised Business Benefits

Fetched from http://www.infosys.com/consulting/soa-services/soa/pages/index.aspx on 31/08/2012.

Microsoft

From Microsoft’s BizTalk product page:

Service-Oriented Architecture (SOA) is an approach to organizing, developing and integrating information technology. SOA enables data, logic, and infrastructure resources to be organized as a service and be accessed by routing messages between network interfaces. SOA helps IT to become an accelerator for business agility and innovation.

Touted Principles and Properties

None. A pragmatic description. Yes, from Microsoft.

Promised Business Benefit

Fetched from http://www.microsoft.com/es-es/biztalk/soa.aspx on 06/08/2013.

Nicolai Josuttis

From [p.24, ref-07-sipnj]

“SOA is an architectural paradigm for dealing with business processes distributed over a large landscape of existing and new heterogeneous systems that are under the control of different owners.”

Touted Principles and Properties

Promised Business Benefit

None. Actually Josuttis explains all the challenges that an organisation is likely to experience in an attempt to achieve an SOA in his book.

Comments

An honest, short, to-the-point SOA definition.

Oracle

From the Oracle Reference Architecture, SOA Foundation, Release 3.1:

Service Oriented Architecture (SOA) is a strategy for constructing business-focused, software systems from loosely coupled, interoperable building blocks (called Services) that can be combined and reused quickly, within and between enterprises, to meet business needs.

Within the scope of the architectural strategy, SOA describes an approach for enterprise systems development and integration that is both technology agnostic (insofar as it operates across heterogeneous systems) and aligned with business imperatives; it provides loose coupling of course-grained components (Services) for rapid and effective reuse of enterprise IT assets.

The ultimate goal of SOA is to facilitate the creation of new business solutions through the composition of Services without the need for complex programmatic code development that might otherwise duplicate existing capabilities; this leads to a more agile and efficient enterprise that can respond more rapidly to changing market and regulatory demands.

SOA is also an architecture driven design discipline conceived to achieve the goals of increased inter-operability (information exchange, reusability, and “compose-ability”), increased federation (uniting resources and applications while maintaining their individual autonomy and self-governance), and increased business and technology domain alignment."

Touted Principles and Properties

Promised Business Benefit

Tata Consulting Services

From Creating an Enterprise Service Mosaic (p.3):

TCS believes that any solution proposed to its customers should achieve the strategic goals and objectives set by the business. We discussed in our earlier whitepaper “Service Oriented Architecture – An Enterprise Perspective”, that SOA is a key enabler for such solutions. Service-Orientation entails an enterprise-scale business transformation program with a vision to create a Self-Optimizing Enterprise that has superior ability to sense and respond to market opportunities with Agility (responsiveness), Efficiency (cost containment), and Resilience (adaptability).

SOA enables a plug-and-play framework of technology enabled business capabilities that form the building blocks for enterprise solutions. It enables the enterprises to leverage their key business assets within and beyond the enterprise boundaries with true interoperability independent of platforms, languages, and protocols.

Touted Principles and Properties

Promised Business Benefit

Fetched from http://www.tcs.com/SiteCollectionDocuments/White%20Papers/TCS_WP_SOACreatingEnterpriseServiceMosaic_291206.pdf on 07/09/2013.

Thomas Erl

From [p.94-55,2005-erl-soa]:

Contemporary SOA represents an open, extensible, federated, composable architecture that promotes service-orientation and is comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services, implemented as Web services.

SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains.

SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise.

SOA is ideally standardized throughout an enterprise, but achieving this state requires a planned transition and the support of a still evolving technology set.

Contemporary SOA supports, fosters, or promotes: vendor diversity, intrinsic interoperability, discoverability, federation, inherent reusability, extensibility, service-oriented business modeling, layers of abstraction, enterprise-wide loose coupling, organizational agility.

Touted Principles and Properties

Promised Business Benefit

Wipro

From Wipro’s SOA Advisory page:

Service Oriented Architecture (SOA) allows firms to align their IT infrastructure with business needs, lower their development costs, complete integration faster, and adopt industry best practices. It also enables rapid assembly and shortens deployment time, thus facilitating agility and profitability while reducing the risk of failure.

Fetched from http://www.wipro.com/services/business-application-services/service-oriented-architecture.aspx on 12/08/2012.

Touted Principles and Properties

Promised Business Benefit

Dogmatic SOA Principles

The term dogmatic SOA is actually a hyperbole because an architecture that is service–oriented “by the book” is indeed an architecture that follows dogmatic principles. The only way to answer the question “how service–oriented an architecture is?” is to measure the level of adherence to the dogmatic principles that are presented as essential in SOA.

We oppose this view. We think that architectures need to be doable (rather than aspirational), manageable, cheap and flexible—so that that they remain cheap in the future too. An architecture that does not ultimately save money or help increase profits does not work.

The problem is that SOA principles are very appealing on the surface. They are presented as an authoritative compilation of self-evident truths in the same fashion as biblical commandments; failing to observe one single principle may be considered a capital sin.

This situation creates stress because the SOA principles can only be applied in their entirety in a utopian world. The real enterprise, instead, is a complex, dynamic, societal–technical world that cannot be tamed with unchallenged, a priori principles and frameworks alone. Critical thinking and compromise-based decision making is also required.

As we have explained before, a service is the name given to an “extraordinary API”. What most principles do is describe the properties that ordinary APIs should exhibit so that they are elevated to the service category. For example, if an API is not abstract, it may not be service–oriented—according to the dogma’s ethos.

Furthermore, principles often make assumptions about the nature of the supply chain. Some principles apply only if there is no supply chain at all (services are built from scratch). Some others have a specific supply–chain problem in mind which may not exist in your organisation—for example, dreadful legacy systems. Last, but not least, the observance of many principles, especially those touted by vendors, come with the promise of business benefit.

We have compiled a list of what we believe to be the most widespread principles. For each principle, we describe the context in which it is genuinely useful and the consequences of following the principle in a blind, dogmatic fashion.

Core Principles of Service Orientation

These are the original core principles of SOA:

Principle Aspect of Well-designed APIs Subject to the Supply Chain Business Benefit Prediction
Abstraction Yes Yes
Autonomy Contradicts “Composability”
Composability Yes Yes Yes
Discoverability Maybe
Formal Contract Maybe
Loose Coupling Yes Yes Yes
Reusability Yes Yes Yes
Statelessness Contradicts “Autonomy” Yes

Abstraction

Abstraction is the concern of API designers and users. Abstraction is a measure of encapsulation—the hiding of superfluous details that should be of no concern to the API user. Abstraction is only useful insofar as the benefit obtained by the use of the abstract artefact (such as a service) is higher than the cost of producing the abstraction in the first place.

Let’s look at some examples:

Concrete API Abstract API Abstraction Benefit
currentLocation (UserId) : (Lat,Long) currentTown (UserId) : (Town) Spares the API user from resolving geographical coordinates to town names.
verifyAddress (Line1,Line2,Town,Borough) verifyAddress(Number,Postcode) Spares the API user from collecting unstructured data which may fail verification.

The power to create optimal abstractions is heavily constrained by the supply chain. Some systems are simply designed in such a way that it is nearly impossible to encapsulate them in their entirety. This gives way to a phenomenon known as abstraction leak.

Abstraction is one of the principles that cause the most stress to architects when it is taken dogmatically, because they see the inability to produce suitable abstractions as a personal failure.

Recommendation

Create a governance process to decide whether a candidate service is suitable for the abstraction capability or not. Take abstraction as a capability whose only aim is to reduce labour input. If producing an abstraction takes more labour than the labour it saves then reject the abstraction capability for the service in question. Document the reasons as to why a service (or a family thereof) could not be implemented in an abstract fashion and also describe the supply chain’s details that have been leaked as a result.

Referred by [p.298,2005-erl-soa]

Autonomy

Autonomy refers to the degree to which a service is more independent from its supply chain and its inherent problems. Thomas Erl says the following about autonomy:

Autonomy requires that the range of logic exposed by a service exists within an explicit boundary. This allows the service to execute self-governance of all its processing. It also eliminates dependencies on other services, which frees a service from ties that could inhibit its deployment and evolution.

By this account, a composite service seems to be the opposite of an autonomous one. Fortunately, Thomas Erl makes the distinction between service-level autonomy and pure autonomy to clarify this apparent contradiction. In service-level autonomy, it is accepted that the supply chain may impose its own constraints which restrict the level of autonomy. The only possible way to produce a 100% pure autonomous service is if one has complete control of its development from the ground up.

Nicolai Josuttis, instead, in reference to SOA and distributed objects, says the following:

With SOA, data is exchanged between different systems, and each system operates on its local (redundant) copy with its own local methods and procedures. Unlike with distributed objects, this approach decouples the systems and lets them scale.

This suggestion seems to follow the autonomy principle to the extent of avoiding dependencies on external systems by duplicating their data.

It is clear that autonomy is a desirable property; however, composite services—the cornerstone of SOA—are, by definition, dependant rather than autonomous entities. Whether the dependency on such subservient services should be minimised via caching or data replication is a tactical choice. Some services are strictly real-time and cannot afford any form of caching.

Service autonomy is automatically predetermined by the nature (or absence) of the supply chain. Everything else on top of this is a series of “palliative” approaches that render services less or more autonomous. Having said this, service autonomy, by itself, is of no value to the consumer; but service reliability, performance and scalability are. If more autonomy translates to increased reliability, performance and scalability, then it is indeed a desirable property.

Autonomy in Governance

When autonomy refers to service ownership, then the interpretation is different. In this case, it is the domain owners—say, the CRM team—that have full control over their services. Once a threshold of organisational complexity is exceeded, this is indeed a desirable property. A large organisation is likely to require federation and the self-governance of various organisational boundaries.

Recommendation

The following conclusions and recommendations apply to this principle.

  1. There is no direct “autonomy principle” to observe as such. Look, instead, at whether there are reliability, performance or scalability dimensions that need to be considered.
  2. Create a governance check in the design process to determine whether the implementation of a service should implement a given tactic (such as caching or data replication) to increase reliability, performance and/or scalability.
  3. Understand that certain services are real-time and their reliability is inexorably subordinated to that of their supply chain. Use your supply chain’s properties to modify your SLA’s bounds accordingly.

Referred by [p.303,2005-erl-soa], [p.23,ref-07-sipnj].

Composability

The composability quality refers to the fact that an API C may be built out of APIs A and B. Composability is nothing more than the way in which all software is normally built. Composability is a by-consequence of modularity: software is built by assembling smaller functions (modules) into bigger functions which, in turn, form part of even bigger ones and so on. The whole point of APIs is that they are composable; otherwise, they would be useless. Composability is therefore a tautological quality of APIs.

The only sensible way to interpret the composability principle in the SOA context is as follows (our own definition):

“Service interfaces should, whenever possible, cater for general use cases rather than project-specific use cases, so that they can be assembled into composite services that satisfy more elaborate and complex ones.”

However, even the above principle needs to be taken with a pinch of salt. These are the main issues:

  1. Supply–chain constraints: producing general use cases may not be possible and/or too expensive, in the first, place due to supply chain constraints.
  2. The closure property is not guaranteed: A composite service is by nature more specific and less general than its individual dependencies. Therefore, a composite service may not be further composable (from a use–case perspective).
  3. Latency: assembling software at the service level incurs the highest performance hit since each dependant service involves—in general—a network invocation.

The composability principle has caused actual project failure in our experience. Architects need to be careful to avoid applying this principle dogmatically.

For example, in a certain project, all of a back-end system’s entities were exposed as atomic “composable” services. Because of this, non-atomic, cross-entity services that would have required the equivalent of SQL JOIN and WHERE clauses were implemented on the ESB using XPath. The result was unacceptable latency and an outcry “to get back to the mainframe because SOA had failed”.

Recommendation

Our practical recommendation is summarised as follows (extended from the Reusability section):

  1. Reject the dogmatic belief that composability must be achieved at all costs.
  2. Create a Governance process that allows to discriminate general use cases from project-specific ones
  3. Once a general use case has been identified, evaluate whether it can be implemented in a cost-efficient manner observing supply chain constraints and design complexity.
  4. Create a Governance check upon the design of composite services.
  5. Only approve the implementation of a complex use case as a composite service when performance is acceptable; otherwise demand the implementation to occur down the supply chain. Hint: Stored procedures are not legacy Pre-SOA artefacts from an ancient world.

Referred by [p.301,2005-erl-soa], HP, Wipro (SOA Definitions).

Discoverability

Discoverability, as the name suggests, refers to a service’s ability of being discovered. In the early years of dogmatic SOA, discoverability was often associated with UDDI. Later on, this interpretation changed to become more general and include any kind of service registry package. This was a godsend for vendors who had one more product to bundle in addition to their core ESB offerings.

In addition to the “formal contract” principle, this is the one which we find the most genuine and applicable. A service that is not discoverable is as good as a service that does not exist.

However, we need to expand a little bit on this definition to make it more unambiguous. Discoverability is not really a bottom-up property. It is the service catalogue that brings the service into existence rather than the service appearing in the catalogue by itself. Therefore, discoverability is a general top-down strategy. We prefer to use the term service catalogue to refer to the yellow pages of services, rather than registry or repository which is automatically associated with vendor tools.

Having said this, the presence of a service in a catalogue does not make it discoverable. To achieve genuine discoverability, the following points must be considered:

  1. The right stakeholders need to know about the services that concern them at the time they require them.
  2. The services need to be described in a language that the intended stakeholders can understand.
  3. Different stakeholders may require different views upon the same set of services.
  4. Services can rarely be used straight away. An on-boarding/provisioning process is required too.

Recommendation

The management of a service catalogue and the life cycle of each service are key core governance processes. Start off with the service catalogue before any other governance activity so that you can align your service implementation roadmap with your organisation’s project portfolio roadmap.

Sources: [p.309,2005-erl-soa]

Formal Contract

A so-called formal contract is an abstract term that may actually refer to multiple aspects:

  1. Structural constraints
  2. Behavioural semantics
  3. Technical non-functional SLA
  4. Business SLA

This is perhaps the most genuine, useful and valid of all principles. No matter whether services are reusable or not, the lack of contracts is hard to justify. However, since the formal contract, as such, covers different aspects, we need to look at each of them in detail.

Structural Constraints

Unless otherwise specified, one may assume that “the contract” is a WSDL or JSON Schema file. The evil, contract-less alternative would be, for example, an XML-RPC service without a schema.

A contract such as a WSDL file addresses a static, first-order aspect; for example, whether the first field should be called “name” and is a string, and whether the second one is called “age”:

    <xs:element name="customer">
      <xs:complexType>
        <xs:sequence>
          <xs:element name="name" type="xs:string"/>
          <xs:element name="age" type="xs:integer"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>

An interface provided by a regular programming language such as Java, .Net or Python is a form of contract too. These programming language artefacts just possess less expression power in the declaration of constraints and entity relationships. For example, placing a constraint in the number of valid integers that are accepted by the “age” field may not be possible in a certain programming language.

Behavioural Semantics

An interface’s structural contract does not communicate what the data actually means. In practical terms, this results in the fact that interfaces tend to be looser in their constraints in order to accommodate a wider number of semantic use cases. Such semantic use cases are seldom self-evident.

For example, let’s say that the following service allows placing an order for orange juice and cigarettes, among other products:

placeOrder (product : String, customer_date_of_birth : DOB)

A schema definition may establish the following constraint:

1900 < DOB < 2000

However, it may not express the following one:

if product == "cigarettes" DOB < (CURRENT_YEAR-18)

This is just a tiny example to illustrate why a software artefact such as an XSD cannot be considered by itself a “formal contract”. Semantic constraints are as important as structural ones and downplaying their importance by placing them in the “runtime validation” category does not stop software from breaking.

Technical Non-Functional SLA

This contract establishes quality properties that cannot be expressed in structural/behavioural terms. In most cases, a non-functional SLA describes a service’s dynamic behaviour through time (availability & latency) from one or more consumers’ viewpoint (concurrency).

Examples:

An SLA is always formulated from a consumer’s viewpoint. The overall capability of a service is formalised using an OLA.

Business SLA

This contract establishes business prerequisites and rules. For example, the fact that the department that uses the service will pay £0.01 for each invocation using a given cost–centre code.

Recommendation

We recommend always observing the four dimensions and using “worse-case scenario bounds” whenever providers down the supply-chain are unable to offer formal guarantees. For example, a service built on top of an unreliable CRM platform that becomes unexpectedly unavailable at times may present a clause in its Business SLA as follows:

Availability: The availability of this service is not guaranteed. Since it relies on CRM services, it may be down for unpredictable amounts of time without notice. Using our historical data, this time has been as high as 45 minutes; however, we cannot guarantee that the experienced downtime will be lower in the future. An improvement in availability predictability requires us to be provided with assurances from the CRM department. At the moment, this escapes the Business Integration Team’s Governance realm.

Sources: [p.295,2005-erl-soa]

Loose Coupling

Loose coupling refers to how easy it is to change is the relationship between a service consumer and a provider. In other words, how cheap is for either a consumer to change provider, or for a provider to accept different consumers, relative to a baseline “tight coupling” scenario. Nicolai Josuttis has composed a useful comparison table in his SOA in Practice book:

Aspect Tight Loose
Physical Connection Point-to-Point Via Mediator
Communication Style Synchronous Asynchronous
Data Model Common Complex Types Simple Common Types Only
Type System Strong Weak
Interaction Pattern Complex Object Trees Data-Centric Self-Contained Message
Control of Process Logic Central Control Dis tributed Control
Binding Statically Dynamically
Platform Strong Platform Dependencies Platform Independence
Transactionality 2PC (Two-Phase Commit) Compensation
Deployment Simultaneous At Different Times
Versioning Explicit Upgrades Implicit Upgrades

It is key to understand that loose coupling is an economical strategy rather than a technical one. For example, Josuttis suggests that a weak type system is a loose coupling approach. This seems in contradiction to the use of a “formal contract” and a CDM strategy. Josuttis is not misguided at all because the economic benefit of complying with a CDM (Strong Type System) may be indeed uneconomical; this has probably been the case in his experience.

In most cases, the supply chain is already tightly coupled and cannot be easily changed. For example, let’s consider a VT100 mainframe billing system that uses a built-in user account database. There is a new upcoming e-commerce portal that requires interaction with this system. How is the “loose coupling” principle then applied? Some of the choices could be:

  1. Let the e-commerce portal developers write their own VT100 connector and talk with the billing SMEs to set up any required accounts. The portal will cost £850,000 due to this complexity.
  2. Create an adapter service that exposes the billing system as a tidy SOAP service but asks front-end developers to talk to the billing SMEs to create an account in the system. The portal’s cost goes down to £500,000 thanks to the adapter service, but developing the adapter service costs an additional £200,000.
  3. Same as point 2 but the service is enhanced so that it maps the consumer’s credentials to the billing system’s accounts using a mapping database. The mapping database costs an extra £250,000, but the portal goes down to £450,000 since it no longer needs to manage the billing system’s accounts.
  4. Same as point 2 but ask the billing team to modify the system so that it uses accounts from the enterprise identity provider (EIdP). Implementing the EIdP costs £500,000.
  5. Ask the billing team to modify their mainframe so that it exposes an XML/RPC service rather than the VT100 interface. This change would cost £900,000, but the adapter service becomes simpler and goes down to just £50,000.

Loose coupling gives the natural choice (perhaps both points 4 and 5) provided that cost and time are equal. However, whenever time and cost vary, compromises must be made. This is the decision table that emerges from the described scenario:

Approach Portal Adapter Service M apper E IdP X ML/RPC Service T otal
1. Portal w/VT100 Connector £850,000 £850,000
2. Portal w/ Services £500,000 £200,000 £700,000
3. Same as 2 + Mapper £450,000 £200,000 £250,000 £900,000
4. Same as 2 + EIdP £450,000 £200,000 £500,000 £1,150,000
5. Same as 2 + XMP/RPC £450,000 £50,000 £900,000 £1,400,000

A table like this would need to be aided with additional information. A choice cannot be made based on cost alone. For example, if an upcoming project (say, a self-help IVR system) will also require access to the billing system, then spending £1,150,000 rather than £850,000 is perhaps a reasonable choice since not only will the IVR system be spared from developing a custom VT100 connector, the identity management will also be simplified by reducing the number of siloed account systems such as that used by the billing system.

Recommendation

Choose loose coupling whenever the extra cost incurred by a loosely coupled approach will be repaid in the future. Have an insight into your organisation’s vision and project roadmap so that you can justify your decisions. Do not apply loose coupling as a dogmatic default choice for all scenarios; it may not pay off.

Referred by [p.315,2005-erl-soa], [p.26,ref-07-sipnj], Gartner, Oracle (SOA Definitions)

Reusability

Service reusability refers to the degree to which a service is used by two or more consumers. Service reusability is an ambition—an expectation upon latent business benefit. One cannot build “reusable” services, as such, because reusability is in the future—it exists only once it has occurred.

All well-designed APIs are built with reusability in mind. Since services are network APIs, they can be accessed by multiple systems; under this conception, http://news.bbc.co.uk would be a reusable service too. So this is obviously not a satisfactory explanation for reusability.

What reusability truly refers to is that, whenever possible, services should satisfy general use cases rather than project or application-specific ones. This functional design imperative increases the chances of reusability but it does not guarantee it.

Following reusability as a dogmatic principle leads to disappointment due to the following issues:

  1. Supply–chain constraints: The ability to satisfy general use cases is subject to supply chain constraints.
  2. Cost: The ability to satisfy general use cases may increase costs and become prohibitive.
  3. Reusability may not occur: The ability of general use case services promotes, but does not guarantee, reuse.
  4. Lack of overall business benefit: Even when reusability occurs, overall business benefit may not be realised.

Supply–Chain Constraints

Designing a service that caters for general use cases is only possible if the service sits at the bottom of the chain and complete freedom exists to modify functions and data storage systems (for example, schemas in a RDBMS may be altered).

If said control is limited, then the ability to satisfy general use cases is constrained by the aggregate ability of all required functions down the supply chain.

Example:

Let’s suppose that you have a legacy banking system that automatically sends an SMS notification to the customer when a debit larger than £10,000 has occurred in his/her account. If you are trying to build two general “Money Transfer” and “Send SMS” services it may be the case that you cannot because the banking system (down your supply chain) would require them to be modified to prevent the SMS message from being automatically sent.

Cost

As per the above banking example, engaging in a SOA crusade in which all systems down the supply chain need to be altered may increase costs exponentially. Alternatively, costly design complexity may be added just for the sake of satisfying the requirement of building general use case services.

For instance, a costly “hack” would be to implement the “Transfer Money” in such a way that the service first checks if the amount is higher than £10,000, then set the customer’s mobile number to a dummy one, perform the transfer, and finally set the customer’s mobile back to the original number.

Reusability May Not Occur

This is the dreaded future of every SOA priest. Unless a formal project portfolio and roadmap exists to identify projects that have use cases in common, building “reusable services” is merely an act of faith. This is the reason why the favoured development approach is often top-down or “build on demand”.

Lack of Overall Business Benefit

For reusability to pay off, the overall balance sheet needs to be healthier in a future in which reusability has been promoted versus one in which it has not. Let’s consider two alternative futures—A and B:

We will also assume that three projects have taken place and that ROI has to be proven at the end of the period, barring any assets left for posterity.

Future A - Reusable Services

Description Project 1 Project 2 Project 3 TOTAL EXPENDITURE
Required services 10 10 10
Reused services 0 5 7
Reusable services built 10 5 3
Project Cost £300,000 £150,000 £90,000 £540,000
Savings do to reuse £0 £150,000 £210,000

We are quite optimistic in this projection: the second project reuses 50% of the services built by the first, and the third 70%. Actual industrial reusability figures are significantly much lower.

Future B - Non-Reusable Services

Description Project 1 Project 2 Project 3 TOTAL EXPENDITURE
Required services 10 10 10
Reused services 0 0 0
Non-reusable services built 10 10 10
Project Cost £150,000 £150,000 £150,000 £450,000
Savings do to reuse £0 £0 £0

We can conclude that, for reusability to pay off, the aggregate cost of producing reusable services —including not only the cost of building the services themselves but the CAPEX and OPEX cost of any supporting middleware products in place—must not be significantly higher than that of producing non-reusable services during the considered time span.

Recommendation

Our practical recommendation is summarised as follows:

  1. Reject the dogmatic belief that reusability must be achieved at all costs.
  2. Create a Governance process that allows you to discriminate general use cases from project-specific ones
  3. Once a general use case has been identified, evaluate whether it can be implemented in a cost-efficient manner observing supply–chain constraints and design complexity.

Referred by [p.292,2005-erl-soa], Capgemini, HP, IBM, Oracle, (SOA Definitions)

Statelessness

Statelessness is property of a service that is incapable of persisting data. The opposite of statelessness is statefulness which is—in general—an undesirable property because persisting data creates a series of challenges:

  1. Interaction with a data store, such as RDBMS, may be required: this increases latency and adds an additional failure point.
  2. If the Business Integration Layer owns the data store and the data is of “business mission criticality”, it may be the case that the Business Integration Team cannot provide the same safety assurances as the vertical domains down the supply chain. For example, the case in which an invoice that was temporally persisted in the Integration Layer is lost due to a failure in the middleware’s single-instance RDBMS. Had the invoice been stored in the billing system, a proper recovery mechanism would have been in place.
  3. Implementing persistence is, in most cases, a bespoke exercise that reduces code reusability.

In short, a Business Integration team has all the reasons to push persistence down the supply chain where more resilient and tightly-governed systems probably exist. The problem arises when this principle enters into contradiction with other principles. For instance, let’s suppose that you come across this requirement:

Requirement: Service X should always return a successful answer whether its supporting back-end system is up or down. If the back-end system is down, it will be invoked by the service at a later time when it comes back up.

This is a requirement with a strong “autonomy” bias. Fair enough—the problem is that the service needs to be categorically stateful. Autonomy and statelessness cannot both be had at the same time in this case.

Another example is long–running transactions. A service that needs to push data across two or more systems will inevitably hold a state to keep track of the flow, especially if a rollback using compensation is required.

Recommendation

Statelessness is, in general, a good “default principle”. However, some requirements cannot be met by means of a stateless service; highly reliable services and long–running transactions are the two most visible examples.

Referred by [p.307,2005-erl-soa]

Additional Principles and Properties

These are other commonly touted principles and properties:

Principle Aspect of Well-designed APIs Subject to the Supply Chain Business Benefit Prediction
Modularity Yes Yes Yes
Open Standards Maybe No Yes
Technology Independence Maybe Maybe Yes
Heterogeneous Systems n/a Yes Yes
Coarse Grained Maybe Yes
Legacy Systems n/a Yes Yes
Ease of Use Maybe n/a Yes

Modularity

APIs are, by definition, modular and software engineering techniques to achieve modularity have been under use, and subject to continuous research, for decades. Modularity simply re-emphasises an intrinsic aspect of well-engineered APIs.

The biggest problem suffered by organisations that adopt the modularity principle dogmatically is that they focus all the effort on making services modular, disregarding a plethora of other assets that need as much—if not more—modular design principles than services themselves. For example:

A “services only” modularity bias results in spaghetti hourglass architecture. In this type of architecture, both the front-end and the back-end layers are constituted by unmanaged, non-modular artefacts. Services, in the middle layer, give the illusion of modularity and architectural coherence.

Recommendation

If your organisation is not treating conventional non-service artefacts as formal architectural building blocks, rolling out an ESB and trapping functionality inside services will not bring about modularity—it will shift complexity to an additional point of failure which did not exist before.

Modularity applies at many levels of abstraction. Ask your Enterprise Architect to identify all the architectural building blocks that are relevant in your organisation and ensure that governance processes exist to maintain the modularity of the solution blocks that are created based on them. Avoid the risk of growing spaghetti hourglass architecture.

Referred by Gartner, Oracle, Tata Consulting Services (SOA Definitions)

Open Standards

An open standard is, in principle, a desirable property since an open standard is not controlled by a single vendor. However, open standards are not new to the non-service software world—for instance, CORBA, OpenGL and ODBC are all open standards. A vendor promoting open standards is no different than a butcher promoting vegetarianism. The natural customer’s position in this case should be that of scepticism.

Dropping the term “open standard”, as an intrinsically beneficial quality, is dangerous, especially if the touted open standard has been defined by a committee (it is a de jure standard) and has not yet become one effectively embraced by the market (it has not yet become a de facto standard). The belief that we have finally reached a privileged point in history in which we have conceived the last final standard is delusional.

The use of an open standard is not even a guarantee of increased developer productivity—let alone of increased business benefits. For example, is it possible to conclude that Apple would have increased profits had they chosen the standard USB connector over their proprietary one?

Likewise, the Apple Store’s market size has been reported to be worth $8 billion in 2012.2 It relies on a relatively closed system based on the Objective-C language. If your company was in the mobile development business, would betting dogmatically on the J2ME “open standard” have paid off? In short, “open standards”, per se, have no intrinsic business value whatsoever.

Moreover, most of the open standards that SOA vendors drum so loudly about (such as SOAP) concern external interfaces rather than concrete implementations. In the world of concrete implementations, we have the exact opposite of open standards: graphical tools and visual “programming” environments that create non-interoperable artefacts. The vendors’ strategy is to commoditise the external interfaces at the expense of creating entrenched positions in the implementation side.

The question is not whether ESB A is standards compliant. The question is how cheap it is to migrate artefacts created in ESB A to ESB B.

A Cautionary Tale: A customer bought into the dogmatic “open standards” principle in 2008 by adopting a “standards compliant” high-profile ESB which supported SOAP 1.0. At the time of the implementation, there were several interoperability problems with the .Net platform concerning the RPC/Document-Literal encoding “edge cases” (a euphemism used by the consortia and vendors to imply that not all cases are necessarily implemented). Fast forward a few years and the front-end marketplace has moved to REST/JSON which the ESB does not directly support. As of 2012, the company was still stuck with their legacy ESB because they had invested millions of pounds in building services inside it and it is not possible to migrate to a different product without building all services from scratch again or facing a slow and painful migration process. Lesson learned: ESBs and open standards become legacy assets too—and rather quickly.

Recommendation

Do not fall for the “open standards” fallacy. Services are worthless unless they materialise in an application. Ask your market—the future consumers of your services—what is the most efficient way to consume services given their tools and know-how—not yours.

As a service provider, your job is to add value, to reduce your consumers’ costs and time to market. If you increase friction by enforcing a bloated open standard you will fail. It is unlikely that you will be asked to choose a “closed standard” anyway; however, be prepared for suggestions that may not have the blessing from high-profile consortia. A good example is ZeroMQ.3

Create a service and data model that is specification agnostic and that can be adapted to existing and yet-to-come specifications and protocols.

Referred by Capgemini, Infosys, Thomas Erl (SOA Definitions)

Technology Independence

Technology Independence is normally specified as “independence of platforms and programming languages”. In reality, this is merely a natural consequence of APIs being network-enabled and using the TCP transport layer. The entire technical infrastructure that sits behind the API is abstracted away by the OSI layers themselves. It follows that adding an application layer (layer 7) middleware product is not necessary to achieve independence of platforms and programming languages.

Recommendation

If all of your systems rely on intranet technology, and can be accessed remotely using a TCP/UDP protocol, then you already have independence of platforms and programming languages. You do not necessarily need to buy new technology to achieve this.

What you may need is bridging technology. For example, a software that automates the operation of a VT100 interface. Even though a VT100 mainframe system may be accessed using TCP, it is difficult to interact with it programmatically and it may be cheaper to buy an off-the-shelf solution rather than asking your developers to develop a home-brew solution.

Referred by Oracle, Tata Consulting Services, (SOA Definitions)

Coarse Grained

“Coarse grained” is a property that refers to the semantics of service interfaces. A coarse-grained interface is typically understood to address high-level business concerns rather than low-level technical ones.

However, whether an interface is coarse-grained or fine-grained is a matter of human judgement. The computer cannot tell the difference; as far as computers are concerned, all APIs are the same. It follows that technology is not required to design a coarse-grained interface. This is a subjective property rather than a technical one.

Recommendation

If you believe that your interfaces are too fine–grained then you need to modify your design governance process to include an appropriate review check. You can always apply this design principle regardless of your technology stack.

Heterogeneous Systems

This property makes an assumption about the nature of the supply chain. It presumes that the supply-chain would be constituted mainly by systems that are somewhat incompatible among themselves.

The complexity caused by the presence of such a heterogeneous system is a common reason to justify an SOA. To clarify the full meaning of this property, we need to ask to what abstraction level does heterogeneity refer?

Let’s say that the supply chain is technically homogeneous; it is constituted by x86-64 HP blades run all a RedHat/WebLogic/SOAP1.0 stack. However, the business data may be heterogeneous: a customer record may be represented differently in the CRM system than in the Billing one.

The opposite scenario is one in which the data is fairly homogeneous and normalised, but the technical systems are heterogeneous: IBM AS/400, Microsoft IIS, etc. In short, unless we define a specific abstraction layer, homogeneity and heterogeneity are meaningless.

In our experience, we have seen that, when heterogeneity was seen dogmatically as a “natural problem”, mistakes were made and money was lost:

  1. In one case, all of the customer’s supply-chain back-ends already supported SOAP. In spite of this, a bloated middleware package consisting of multiple adapters was adopted. This customer only required security and QoS capabilities that could have been addressed using much cheaper appliance technology.
  2. In another case, a monolithic platform (which was not legacy and was not meant for discontinuation) already integrated the entire supply chain. Again, an unnecessary middleware suite was rolled out just for the purpose of creating proxy 1:1 mappings towards the underlying integration platform. Even though there were heterogeneous systems in the company, as such, they were immaterial from a Business Integration perspective.

Recommendation

If a vendor tells you that their solution addresses heterogeneity, ask for the abstraction level to which they refer and conduct a survey to prepare a matrix that can help to understand whether genuine gaps exist.

Heterogeneity may not be a property that applies to your organisation—especially if it is a relatively small company. Nicolai Josuttis, for example, describes SOA as only applicable to “heterogeneous systems with multiple owners” [p.24, ref-07-sipnj]. This is the reason why we see SOA as a possible tactic within Business Integration that you may well opt out if it does not apply to your organisation.

Referred by Oracle, Nicolai Josuttis (SOA Definitions)

Legacy Systems

The presence of a legacy system is a supply–chain assumption. In general, a legacy system is a dated system that causes distress to the organisation. However, the distress causes may very:

  1. The legacy system is no longer supported by its vendor.
  2. The legacy system is targeted for discontinuation, and it should not incur further investments.
  3. The legacy system will be replaced by a new system.
  4. The legacy system’s maintenance costs have spiralled out of control.
  5. The legacy system is owned by a disfavoured vendor.
  6. The legacy system is despised by programmers because it is old and it offers no opportunity to learn new technical skills.

In most cases, the underlying assumption is that the nature of the APIs (or cursor interfaces) provided by the legacy system in question causes distress to programmers, and therefore, they must be “wrapped” into a less distressful form of APIs: services.

Many organisations do not have any systems that would qualify for any of the criteria presented above. A legacy system, after all, only exists in the human mind; however, money spent on middleware products that supposedly “leverage the value of legacy systems” is very real.

Recommendation

Do not dogmatically assume that there are legacy systems in your organisation. All organisations have dated systems, as such, but this does not mean that they necessarily need to be augmented by a new middleware product.

If you suspect that dated systems cause friction, and such friction translates to increased costs and time to market, then run a survey to understand the specific aspects that cause such friction. A Front–End Integration CBA is a good start.

Referred by Accenture, HP, IBM (SOA Definitions)

Ease of Use

There are three questions to ask when confronted with an “ease of use” claim:

  1. Who will benefit from ease of use?
  2. Does ease of use mean a shorter learning curve or sustained increased productivity?
  3. What is the overall business benefit that results from it?

Who

For example, if you have outsourced all of your IT operations to a single supplier, then buying easy-to-use technology for them is of no evident business value. It is up to your suppliers to figure out how to become more productive—this is why they are the IT experts in the first place. However, if your suppliers claim that by buying an easy-to-use product, they will lower your bills, then you may want to look further into the rationale for this claim.

Learning Curve versus Productivity

Many so-called easy-to-use products, especially those that are GUI-based, present code as a villain. Such products do offer a shorter learning curve; however, after the learning phase has been completed, productivity cannot be longer increased due to the natural limited expression power of graphical interfaces.

We have one sentence to summarise ease of use claims around GUIs:

Touting GUIs as advantageous over code is akin to touting Abacuses as advantageous over arithmetic on Arabic numerals in the field of Finance.

Let’s suppose that your organisation hires two recent graduates: Joe Bloggs and John White. They both have computer science degrees from good universities and are master C++ and OCaml hackers. One department hires Joe and tells him that the enterprise language of choice is C# and that’s what he has to stick to. Another department has attended a vendor’s workshop and become fascinated with the GUI-based point-and-click interface they saw; so they hired John to learn this revolutionary product that requires no code.

Both departments measure productivity in terms of functional points per year. This is what happened:

Whom Product FPs Year 1 FPs Year 2 FPs Year 3 Total FPs
Joe C# 20 60 90 170
John GUI-based 40 45 50 135

Even though John had an advantage in the first year, he could not further increase his productivity afterwards because the GUI had no means to create labour-saving abstractions. All he could do was click faster.

This is merely an illustration and should not serve to conclude that GUIs are necessarily evil. Some GUIs work interchangeably along side code to enhance code navigation and manipulation. The point is that an ease of use claim needs to be justified in terms of sustained increased productivity rather than a shorter learning curve alone.

Overall Business Benefit

Ease of use is only useful insofar as it reduces labour inputs that your organisation pays for directly. If ease of use cannot be demonstrated as an advantage that can be proven financially, then it offers no value and can even reduce productivity as per the Joe and John examples above.

Recommendation

Do not fall for the dogmatic belief that ease of use (and especially GUIs) translates into business benefit. Follow these simple steps:

  1. Ask who is going to benefit from ease of use.
  2. Ask to the party in question how ease of use will reduce costs and/or increase productivity. Listen to suggestions and alternative solutions; ask how they will reduce costs and/or increase productivity instead.
  3. Produce a three-year forecast that allows you to predict when the ROI will occur for each alternative. Make sure that you take into account projected productivity past the learning phase.

Referred by HP, Gartner, Oracle, Tata Consulting Services (SOA Definitions)

Business Logic in SOA

Business Logic is an embellished term commonly used in SOA to refer to the type (or portions) of regular programming code whose main purpose is that of addressing high-level, “business concerns” as opposed to technical ones.

For example, in a CRM application, the code that calculates the deals with highest value for the current day could be classified as part of the CRM’s “business logic”. However, the code that converts the same deals to a PDF file would be—arguably—regular technical logic.

In all cases, the business logic conception only exists in the human mind. The computer does not know the difference between business logic and technical logic. So-called business rules languages, for example, are simply constrained development languages that run in a sandbox which prevent mistakes such as erasing the entire hard drive. The point is that business logic, business rules, business process and any type of automation technology with a business prefix on it, do not come with “additional business powers” that are absent in ordinary “technical” languages.

In the context of distributed systems, business logic is usually further discriminated by the nature of the interaction patterns:

Orchestration

Orchestration is simply an embellished name to refer to the kind of business logic that is realised as one controlling process that manages other subordinate, distributed systems. This emphasis refers to logical execution only. For example, in a physical, clustered environment, many nodes that execute the same code would still be performing “orchestration” rather than “choreography”.

In SOAP, Orchestration is associated with the WS-BPEL specification.

Choreography

Choreography, again, is an embellished name to refer to business logic that is described in the form of a coordination protocol. A coordination protocol establishes how different participants may interact. The interactions themselves typically occur in a peer-to-peer fashion. There is no need for step-by-step execution by one “Big Brother” controlling process.

For this reason, choreography is an architectural style rather than a strict physical property. In most cases, although participants may support coordination protocols (for example, for transaction purposes), there is usually one initial master (orchestrated) flow that is ultimately interested in the outcome produced by one of such “choreographed” participants.

In SOAP, Choreography is associated with the WS-CDL specification.

Specifications

A specification is a set of descriptions and guidelines issued by an individual or an organisation. Specifications are not de facto standards, per se, although many organisations issue them under such an expectation. A specification only becomes a de facto standard when it has been widely accepted by the market. Thus, recently issued specifications can, at best, be regarded as de jure or fiat standards.

Consortia such as OASIS, The Open Group and W3C do not posses intrinsic authority; specifications always need to be observed orthogonally on their own merits. The possibility of a specification failing to achieve de facto standard status must always be considered.

BPEL

Originator: OASIS

Business Process Execution Language (BPEL) is an orchestration-centred specification to describe business processes. The term BPEL by itself may be ambiguous; it may refer to one of the following:

WS-BPEL

The WS-BPEL specification is meant to describe abstract and executable business processes using XML. It relies on existing specifications such as WSDL and XPath. WS-BPEL encompasses the following concepts:

BPEL Engine

A BPEL engine is a software package that executes WS-BPEL documents. The generic term of this type for software package is “BPM Engine”.

SOAP

Originator: W3C

Simple Object Access Protocol (SOAP) defines an XML convention to exchange messages across systems.

WSDL

Originator: W3C

The Web Services Description Language (WSDL) allows structuring a SOAP service by defining its input and output data as message types and binding interfaces to concrete endpoints.

WS-Addressing

Originator: W3C

This specification helps the inclusion of routing data in SOAP headers. The purpose is that all routing information (in essence, precise endpoint details) that is required for each message to reach its destination—or information regarding the endpoint that accepts a response against it—can be encapsulated within the SOAP message itself.

The WS-Addressing specifications encompasses the following entities:

WS-Choreography

Common name for the WS-CDL specification.

WS-CDL

Originator: W3C

WS-CDL is an XML-based specification for modelling protocols shared by web services that cooperate to fulfil one or more complex use cases.

WS-Coordination

Originator: OASIS

Coordination of activities that require multiple participants. WS-Coordination needs to be used in conjunction with a specific activity type such as WS-AtomicActivity and WS-Business Activity. Under the WS-Coordination specification, the participants are called the applications, and the provider is called the coordinator.

WS-Atomic Transaction

It defines three protocols for achieving transactional safety when an atomic logical transaction—it either succeeds or fails as a whole—is performed by discrete distributed services:

WS-BusinessActivity

It provides a mechanism to define arbitrary business logic and flows with the following capabilities:

  1. Exception/Error handling.
  2. Compensation—reversal of a previously completed task’s effects.
  3. Context and life cycle state persistence over a long period of time.
  4. Notification acknowledgement built into the protocol.

WS-Eventing

Originator: OASIS

WS-Eventing is a specification that helps implement the Publish/Subscribe MEP. It is an alternative to WS-Notification

WS-Notification

Originator: OASIS

WS-Notification is a specification that helps implementing the Publish/Subscribe MEP. It includes other sub-specifications such as:

It is similar to WS-Eventing.

WS-Policy

Originator: W3C

WS-Policy allows the definition of policies (constraints, assertion, rules, preferences) that apply to web services in a generalised manner, so that they may be shared with consumers and be evaluated both at design and runtime.

WS-ReliableMessaging

Originator: OASIS

This specification defines a protocol for sending messages when one or more of the following guarantees are applicable:

WS-Security

Originator: OASIS

WS-Security is SOAP extension to introduce security capabilities. Its capabilities are divided into three categories:

WS-Security provides the typical standard mechanism to implement user credentials as header data’s attributes in SOAP. For example:

<wsse:UsernameToken>
    <wsse:Username>joe_bloggs</wsse:Username>
    <wsse:Password Type="wsse:PasswordText">xJ$7N_094</wsse:Password>
</wsse:UsernameToken>

References

  1. http://www.prweb.com/releases/soa-services-oriented/architecture-market/prweb10670370.htm↩

  2. Tech Crunch and Research2Guidance↩

  3. ZeroMQ - http://zeromq.org/↩