This is the first in a series of articles on Service Oriented Architecture (SOA) that I will be doing over the coming weeks.  Given that every middleware vendor defines SOA differently and every Systems Architect seems to have their own definitions for various aspects of an SOA, I am going to use this first article to present a sample of what I personally think an SOA stack should be comprised of and I will define the major components using a set of consistent terminology that I will use in the coming articles.  I will focus on the technical part of the stack and not items such as Governance (which I personally feel a lack of is one of the major causes for SOA project failure in large corporations), Infrastructure, etc.  We can discuss those in future articles.

So for most of you who have done some rigorous SOA, I apologize in advance for the SOA 101 Tutorial, but I am always amazed at how much people define the pieces of an SOA (or anything else architecture wise) differently, so this next section is purely to provide us with a common set of definitions on which to base further discussion.

Lets look at the following stack which depicts the typical application stack for a single service component.

A Simple SOA Stack

So what are the main parts to this stack, and what is their role.

Service Component:
This is the true heart of the SOA (not the service interfaces which most people focus on).  The Service Component is that logical unit of code which implements the functionality to support the Service.  The Service Component exposes one or more Services.  A Service Component (at least a foundational one, which I will define shortly) is also usually associated with a data store of some kind.  This can contain data about a fundamental data type (defined below), control data, process, data, etc depending on the nature of the particular service component.

Service:
The Service is a public interface which is exposed by a Service Component.  It can be exposed in a wide array of protocols and need not be just SOAP Web Services.  In fact I will argue that even 20 years ago, that good systems were designed as SOA even though we exposed Services on a socket.

Legacy System Adapter:
It is my personal opinion that any time a Service Component needs to interface to a legacy system, that an Adapter Pattern should be used.  This Adapter performs a number of tasks.  Its primary function is to convert to/from data formats spoken by the legacy system and the common data formats used by the Foundational Service Components.  In order to perform the conversions, it may be necessary for an adapter to interface with many Service Components in order to perform data enrichment or break data apart into its fundamental data types.

Enterprise Service Bus:
Its common for people to use an ESB, at least on paper.  The definition of the ESB is a bit amorphous in my opinion.  Many middleware vendors will tell you that the ESB contains everything including the kitchen sink functionality wise or else it’s not an ESB.  Typically people expect the ESB to provide abstraction, dynamic content based routing, optionally process choreography, Security and a boat load of other features.  Personally, if I am going to use an ESB at all, its most likely not much more than an ultrafast messaging layer with none of these bells and whistles, but that is more a function of the fact that most of what I build needs to be ultra high performance (systems capable of millions of transactions per second with response times as low as 20 microseconds, so no room for overhead).

Application:

So no surprise here.  On top of it all is an Application.  An Application is going to combine the functionality which is exposed by many Service Components.  More importantly, if and only if, the SOA is done well, then many Applications can aggregate the functionality provided through the Services, by those same Service Components to meet completely different end user requirements, without change to any component, except those which need to support a specific process or function for a specific Application.  This should be the goal of any SOA.

Here is one more diagram to consider.

Layering Service Components

In this diagram I am going to contend that the Role Service Component and the Party Service Component are what I will call Foundational Service Components and that the Customer Service Component is a Composite Service Component.

Foundational Service Component:
I am going to define this in a controversial manner.  I am going to content that a Foundational Service Component has one and only one job and that is to support all actions related to a Fundamental Data Type.  So in the case of the Party Service Component it’s job is to provide a Service interface and a supporting implementation in the Component which allows a user to Create, Read, Update and Delete Party Data.  That’s all it should do

Fundamental Data Type:
A Fundamental Data Type is a basic data type, or business object which is typically common across a wide array of applications.

Composite Service Component:
A Composite Service Component is a component which combines the functionality of one or more other Foundational or Composite Service Components.  It may also encapsulate additional functional and data enrichment, business process, etc. In some cases, a Composite Service Component may be purpose built to support one and only one business process or application, where it makes sense to encapsulate a piece of reusable functionality on the server side instead of in the application.

Well this ends our discussion of the basic Anatomy of an SOA.  For those who made it to the end without their brain dripping from their ears, I congratulate you.

Now that we have this common framework and terminology, the next topic will be about “The Importance of Enterprise Data Modeling for Service Oriented Architecture”, and will discuss why starting with the service definition without having identified the Fundamental Data Types or the Foundational Service Components leads to an SOA with little to no reusability.