SOA defined in a formal way

Service-Oriented Architecture (SOA) has a lot of definitions. Some call it a management vision, others see it more as a system architecture concept. In the second one, a movement is seen pushed by technology vendors. In 2003 they talked just of web services, while by now the talk is of events and process engines. In this article I want to review a couple of the existing definitions and categorize them into one of the steps of the system realization process. I will conclude with a formal definition of how I see SOA.

The System Realization Process

In figure 1 the System Realization Process presented in ‘Architecture, a definition' is shown. In short: an Architecture Framework describes how to architect. The result of architecting is an architecture which describes how to design. Designing leads to a design (if it is really implementation independent it is called an ontology) which is an abstract description of a system. The process of translating a design into an implementation model (in software mostly source code) is called engineering, while implementing refers to the process of deploying a system on or in certain technology. The end result: a system.

Figure 1 – The System Realization Process, based on [1].

The question is now: were do we place SOA? The name Service-Oriented Architecture implies that SOA is an architecture, but is that true?

Service-Oriented Architecture as a system

Sometimes, in marketing writings, it seems to that people think SOA is a system, some kind of of-the-shelf solution. "What your company need is a SOA, that's what we deliver you". Most times they mean that they deliver some SOA-compliant software. If SOA is a system it is just an application running on some predefined hardware. It is obvious that even in the most worse definition SOA isn't a system but something describing properties of a system.
 

Service-Oriented Architecture as a design

It can be concluded that if SOA isn't a system, it also isn't an implementation model. The only difference between a system and an implementation model is that a system is an implementation model deployed (or implemented) on some technology.

Can SOA be seen as a design? According to the following definitions it can.

"SOA is a form of technology architecture that adheres to the principles of service orientation. When realized through the Web services technology platform, SOA establishes the potential to support and promote these principles throughout the business process and automation domains of an enterprise." Thomas Erl, chief architect, XMLTC Consulting Inc.[2]

Thomas Erl calls SOA a technology architecture but the further description learns that by an architecture he mean what is called a design in the system realization process. He said SOA adheres to the principles of service orientation, so SOA is a design adhering to the principles of the architecture called service orientation.

"The SOA models the business as a collection of self-contained services that are available across the enterprise that can be evoked through standard protocols both internally and externally." Dave McComb, president, Semantic Arts [2]

Dave McComb defines SOA also as a design. From the definition above it follows that a SOA describes the business as a collection of self-contained services. It should be noted that when adopting a descriptive notion of architecture (see Architecture, a definition) both definitions in this section define SOA as an architecture. However, in the system realization process the descriptive notion of architecture is rejected. Only the prescriptive notion of architecture is called architecture.

Service-Oriented Architecture as architecture

An architecture is defined as a set of principles restricting the design freedom in a certain design domain (see Architecture, a definition). So, if SOA is an architecture it should be a set of principles (for a definition of principle see Architecture principles formalized). We'll analyze a couple of definitions by industry experts to determine what principles a SOA consist of when looking at SOA as an architecture.

"Service-oriented architecture is an architectural discipline that centers on the notion that IT assets are described and exposed as Services. These Services can then be composed in a loosely-coupled fashion into higher-level business processes, which providing business agility in the face of IT heterogeneity." Ronald Schmelzer, analyst, ZapThink LLC [2]

The principles stated in the definition above are:

• IT assets are described and exposed as Services.
• Services can be composed in a loosely-coupled fashion into higher-level business processes.

"Service Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocol-independent distributed applications composed from well-defined, self-contained software resources accessible as Services across the extended enterprise in a standardized way, enhancing re-usability and interoperability." Ankur Gupta, marketing manager, Fiorano Software Inc. [2]

From the definition of Ankur Gupta the following principles can be derived:

• Applications are accessible as Service in a standardized way.
• Applications are protocol-independent.
• Applications are composed of well-defined, self-contained software resources.
• Applications are re-usable.

The Open Group [3] defines SOA as an architectural style with a couple of distinctive features. From this features the following principles can be derived:

• Services mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes. 
• Services are implemented with open standards to realize interoperability.
• Services are location transparent.

The last definition we analyze is the one from Randy Heffner, vice president, Forrester Research Inc [2]. He defines SOA as:

"A pattern of design, development, deployment, and management of (a) applications and (b) software infrastructure and frameworks"

He also gives a set of properties for this pattern which here are rephrased to the following principles:

• Applications are organized into services that are (typically) network accessible.
• Service interface definitions are first-class development artefacts.
• Services have Quality of Service (QoS) characteristics which are explicitly identified at design time.
• Services and their metadata are cataloged in a repository. 
• Protocols and structures within the design are based on open standards.
• Software infrastructure takes active responsibility for managing QoS and enforcing policy for service access and execution.

We've already seen the definition of SOA by Thomas Erl in the previous paragraph. He defines SOA as a design adhering to the principles of Service Orientation. So Service Orientation is an architecture. He states the following principles in [4]:

• Services within the same service inventory are in compliance with the same contract design standards (Standardized Service Contracts).
• Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment (Service Loose Coupling).
• Service contracts only contain essential information and information about services is limited to what is published in service contracts (Service Abstraction).
• Services contain and express agnostic logic and can be positioned as reusable enterprise resources (Service Reuseability).
• Services exercise a high level of control over their underlying runtime execution environment (Service Autonomy).
• Services minimize resource consumption by deferring the management of state information when necessary (Service Statelessness).
• Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted (Service Discoverability).
• Services are effective composition participants, regardless of the size and complexity of the composition (Service Composability).

Given the different definitions above and the principles derived from them, the following set of principles can be defined:

• IT assets are described and exposed as Services.
• Services mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes.
• Services have standardized contracts.
• Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.
• Services exposes their functionality through an abstract interface.
• Service are reusable.
• Services can be composed into higher-level business processes.
• Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.

If we see SOA as an architecture it will be defined as the set of principles above. This list, of course, is not exhaustive and some principles can be worked out in sub-principles. To make the definition more formal a structured format should be used for describing the principles, as presented in the previous post (see Architecture principles formalized). That process will be left open for now.

Service-Oriented Architecture as architecture framework

SOA is never (as far as I know) defined as an architecture framework, but looking at the principles defined in the previous paragraph an architecture framework can be defined in which these principles can be categorized. Formally, an architecture framework is defined as a tuple where:

• S is a set of system types.
• D is a set of design domains.
• A is a set of areas of concern.

(see Architecture, a definition)

For SOA the set of system types consist at least of an organization (the business processes and process owners), an application (software components) and a technical infrastructure. The set of design domains is less obvious. Looking at the principles two different main elements can be seen:

• the function of services described in interfaces and/or contracts
• the construction of services (composed of other services, legacy applications, etc.)

So the two different system notions, function and construction, are part of the set of design domains.
The set of areas of concern should at least contain: reusability, composability and interopability.

Conclusion

The definition of SOA as an architecture framework isn't very complete and well-founded, but it gives an indication. The question still is were to place SOA? It's obvious that SOA isn't a system, but some people give definitions of SOA in which it is a design. SOA as an architecture is the most used viewing angle and SOA as an architecture framework reflects, in a formal way, the people who say that SOA is more like a vision.

I think SOA can be defined both as an architecture and an architecture framework. However, both situations need to be worked out a bit more. A good first attempt is given in this article.

It can be concluded that SOA still is a vague term which is used in very divergent situations. Even the formal, existing definitions are not complete and most of them have properties from both architecture and architecture framework definitions.

References

[1] Hoogervorst, J.A.P., Enterprise Governance & Architectuur, Corporate, IT en enterprise governance in samenhangend perspectief. Academic Service, 2007.

[2] A defining moment for SOA, http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1017004,00.html

[3] The Open Group, http://opengroup.org/projects/soa/doc.tpl?gdid=10632

[4] Thomas Erl, SOA principles, http://www.soaprinciples.com/