SOA What and Why?

Fowler famously gave up on SOA encouraging the community to find other terms to describe its various constituents. Instead, the term has only become more prominent and synonymous with more concepts and technologies fed by the big vendors and their vast array of product speak. They employed the services of OASIS in an effort to save the term and succeeded – shoving all those concepts into a broad reference architecture.

Nevertheless, with the term continuing to gain traction and a wealth of related technologies surfacing, I recently ventured into the ivory-towers of SOA trying to grasp some worthwhile truth from the reams vendor-speak out there – with terms such as ‘adapt dynamically’ and ‘business agility’ exclaimed in many a paragraph.

This blog documents my initial experiences wading through the reference architecture and related explanations of SOA. My intention is briefly summarize SOA, condense important terms used in the architecture and offers reasons why the architecture can be of some value.

What is SOA?

SOA is high-level architecture, one that can be realized through a multitude of concrete, low-level, architectures. Its focus is on services and interacting with them. Services have been in existence for decades – companies have extracted important shared behavior into some re-used API for a long time. Technologies have been around equally as long allowing these API’s to be invoked both locally and remotely. The architecture simply encourages you to think about things slightly differently so code shared within an organisation and across organisations can change faster. More concretely, it encourages you to keep these things in mind:

• Define worthwhile services. Their behavior should be useful and serve multiple consumers.
• Rip services out of your apps. Services have traditionally been embedded within apps. Treat them as separate entities, and version and deploy them as such.
• Be vendor independent and support heterogeneous computing. Support consumers using different message delivery mechanisms and technologies.

That’s the guts of it. Physically separating services and treating them independently rather than conceptually separating them and embedding the within applications is, for mind, the key message. Services can then change independently of the applications using them and, among other benefits, multiple versions can be deployed to serve different needs.

SOA Terminology

I’ve divided the terms into two sections, the first more abstract terms, and the second terms more concrete that verge on implementation terms.

Abstract Architectural Terms

Service

An entity performing capabilities (aka processes and behaviors) meeting the needs of consumers.

Realization: Some behavior exposed via an API.

Service Description

Describes the capability of a service and how to use the service. The description seeks to aid both human understanding and automated interaction. It is composed of an Interface, Policies and Contracts.

Realization: API contracts such as WSDL, in code assertions, post-process reconciliation.

Service Interface

Details of protocols, actions and information exchange performed.

Policy

Describes how to interact with a service considering such things as security and SLA’s (e.g. around frequency of use). Automated and manual enforcement is possible, as well as enforcement prior, during of after interaction. Akin to assertions by a Service on it’s expected behavior.

Contract

An agreement between consumer and provider to behave in a specific fashion. Akin to assertions between 2 or more parties, as opposed to Policies which are assertions by 1 party.

Service Provider

Provides a service for use. Multiple perspectives are possible, e.g. the organization/person providing the service or the technology exposing the service.

Realization: An organization such as Amazon, technology such as Apache CXF.

Service Consumer

Uses a service. Like providers, multiple perspectives are possible.

Realization: An organization such as The NY Times, code binding to and invoking a service.

Service Participant

A term describing either a Service Provider or Service Consumer – a generalization.

Visibility

A service and consumer must be able to connection and comply with description for information exchange. Noteworthy as a service can be made visible via a directory or registry.

Realization: Use of UDDI for service discovery via a directory.

Interaction

An interaction between service and consumer. A conceptualization of communication between the two. Consists of an information exchange via described behaviors.

Realization: Point-to-Point communications via HTTP and TCP/IP, an event triggering a service via timer or a change in state, message transmission via MOM.

Execution Context

Embodies an interaction from connection through to completion. Each interaction has a dedicated context which incorporates the connection between participants, the interpretation of information exchanged, enforcement of assertions and execution of the service.

Effect

The consequence of interacting with a service. Usually a state change and/or retrieval of some information.

More Concrete Terms

Message

Embodiment of a request to or a response from a service.

Message Delivery Mechanisms

Message delivery can be both synchronous and asynchronous. Services can be exposed via Web Services (WS-* or REST), simple XML data exchange over HTTP, MOM such as JMS, SMTP, CORBA, COM/DCOM, direct API invocation…

Point of emphasis here is that SOA is not realized solely through Web Services and WS-*.

End-Point

A discoverable location from which a service can be accessed.

Realisation: Connection details such as a URL.

Interaction Patterns

Examples of patterns consumers can use to interact with a service:

• Simple Request-Response: Direct invocation of service from consumer.
• Discovery: Appropriate service is discovered from directory.
• Probe and Match: Query a number of consumers, discovering which consumer fulfils some criteria leading to a subsequent invocation.
• Subscribe and Push: Consumers subscribe to services and receive callbacks for significant events.

Is SOA valuable?

So SOA is not rocket science and the concepts embodied in the terms mentioned are nothing new. For an organization with services embedded in applications that lack a well-defined API, it’s going to be expensive to adopt. On the other hand for an organization with those API’s well-defined and tested it will be much easier. For another organization they may have only one application and no behavior exposed externally, so who cares? The key questions for an organization to consider are:

• Do I expose behavior for external consumption?
• Is it hard for me to change applications where I have ’services’ embedded?
• Am I finding it hard for a service to fulfil the needs of multiple consumers?

Again, for a healthy codebase that’s well designed and tested, if you need to move in an SOA direction your task is significantly easier. If your not in this situation, then I suggest that should be your first step and where you spend the bulk of your investment.

References

What is SOA anyway?

Geospatial Service Orientated Architecture

Service Oriented Architecture (SOA) and Specialized Messaging Patterns

Smart SOA: Best practices for agile innovation and optimization

Update: Uncle Bob agrees with my conclusion in his blog entry A Rational Plan to Start using SOA