WebServices dot org

Arriving at a definition of SOA

I think we have all been in those situations when after a presentation someone asks are rather off topic question and you being the expert in the room need to come up with a coherent answer. I had just made a presentation about the IT architecture to the “business” side of an insurance company when someone from the audience requested a definition of SOA. Luckily for me I was in good territory. Noting the general consensus of nodding heads from his colleagues I recognized this was obviously a point of discussion. I could imagine them reading “insurance business weekly” and spotting the headline “SOA makes IT work” or something of that nature. Business people always think they know best in these matters.

So the pitch of the question was generally over “well, we have heard and seen lots about SOA, it would be good to hear how the architecture team define SOA”. I must admit, I needed time to think. And so with a slowness in my reaction, I pulled myself towards the whiteboard and thought quickly about what to say.

The audience was IT savvy (just as IT people need to be business savvy) and a clear yet non technical explanation was called for. This was a no waffle audience.

Of course, SOA has suffered its fair share of IT industry waffle. I put it down to two things. You can’t overcome the basic fact that English is an expressive language and that promotes the seemingly endless debates over definition and meaning. This is compounded by the typical IT vendors wanting their individual spin on anything SOA. Product differentiation is still the economic principle of success.

The second problem is, there isn’t a mathematical formula for SOA that will tell you exactly what it is. Without a clear understanding therefore of what it exactly is that we can all agree on, the truth is never easy to find. So when someone says they are confused by SOA, they get my sympathy.

So back to the question. As I approach the whiteboard, I get a plan of action. I decide to try and construct a definition of SOA from principles. I draw up three steps to a definition of SOA and explain that if you see the definition from the principles, you’ll understand and therefore remember it.

So here goes. The bold is roughly what got written up.

There a three step process to arriving at a definition of SOA.

Step 1. SOA like any system needs to have some sort of resources. What can I say about the resources in an SOA?

I would say these resources are made available on a network as "services". These services maintain technology neutral interfaces and communication protocols”

Step 2. These two statements above are not new in the world of IT, we have seen them before in other systems, however, so what distinguishes a modern SOA from those in the past?

The answer is “loose coupling” implemented using standardised (and therefore platform agnostic) technologies.

Step 3. So Loose Coupling is at the heart of this new SOA. How would you define this Loose Coupling?

The client is independent of the service, independent of implementation and therefore changes to that implementation. You can achieve loose coupling by using a standard set of composable and extensible protocols and technologies: Web services for example.

So here I arrive at my definition.

Definition Ratings

I am not sure if that is the best definition, but it worked for the audience, was brief and got over the main principles.

There are literally 100s of definitions of SOA on the Web, some good, but sadly many of them contradictory and many leaving more questions unanswered. I have tried in vain myself to read and comprehend them. Once you have read a few, or 20, you start to recognize good and bad definitions. There are commonalities in the good definitions. Good ones contain terms such as abstract, standard interfaces, contracts and standard protocols, reusable, interoperable, vendor neutral, platform agnostic, loosely coupled, and autonomous.

However, equally so, there are bad ones. Generally these definitions “smudge” SOA with other IT paradigms lean towards vague IT business terms or say things I consider should be assumed or implicit in the definition. They contain terms such as communication, event driven, business process execution, business services, business capabilities, style of design, set of related business functions, integration.

Lets have a look at a few alternative definitions. Here are a few that I found, and in the true spirit of the World Cup 2006 “player ratings”, I thought I would give some ratings also.

From Page 8 of OASIS SOA Reference Model

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.

In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. It is natural to think of one person’s needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent’s requirements being met by a computer agent belonging to a different owner.

There is not necessarily a one-to-one correlation between needs and capabilities; the granularity of needs and capabilities vary from fundamental to complex, and any given need may require the combining of numerous capabilities while any single capability may address more than one need. The perceived value of SOA is that it provides a powerful framework for matching needs and capabilities and for combining capabilities to address those needs…..blah..blah

( Read more )

Rating: 1/10. I've lost the plot after the 4th or 5th paragraph. Sadly like everything else this group seems to churn out, it is heavy on words, light on substance. If there is substance, it is hard to find. So for the challenge of keeping awake when reading, 1/10.

From wikipedia

Unlike traditional point-to-point architectures, SOAs comprise loosely coupled, highly interoperable services. These services interoperate based on a formal definition (or contract) which is independent from the underlying platform and programming language (e.g., WSDL). The interface definition encapsulates (hides) the vendor and language-specific implementation. A SOA is independent of development technology (such as Java and .NET). The software components become very reusable because the interface is standards-compliant and is independent from the underlying implementation of the service logic. So, for example, a C# (C Sharp) service could be used by a Java application and vice versa.

( Read more )

Rating: 8/10. Has all the qualities of a good definition and like much of wikipedia is well worth plagiarizing for that coursework essay.

From Searchwebservices

Services provide something of value to those who know how to request and consume them, without having to know how to produce that value. SOA is an approach to building software applications as collections of autonomous services that interact without regard to each other's platform, data structures, or internal algorithms.

( Read more )

Rating: 5/10. Gets some key concepts over but what is with the “something of value”!. I think it should be written, Services provide…ehh..something of value.

From service-architecture.com

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

( Read more )

Rating: 2/10 I consider myself now enlightened that services communicate with each other. Yikes, am I learning! A low mark since it states the blindingly obvious and says nothing about loose coupling, standarisation, interfaces etc.

From Beat Schwegler

In short, SOA is about loosely coupled systems, message based communication and business process orchestration. As an abstract architectural model, it acts as an indirection between the business and the technology model. Web Services are the preferred implementation technology for loosely coupled and inter-operable systems.

( Read more )

Rating: 5/10. A good last line about interoperability, but here we have a description where someone goes into the “void”. SOA is described as an abstract model between business and technology. Waffle at its best, and with the word “indirection”, it gets marks for entertainment value. And when did business process orchestration become part of SOA. Granted, SOA enables orchestration, but it is not part of a definition surely.