Reflections on SOA

One way I expand my professional knowledge is by reading "good" books on software engineering; those books that are either commonly referenced classics or highly recommended (see sidebar for short reviews of some recommended books).

I have recently been reading "Pattern-Oriented Software Architecture, volume 1", by Buschmann, et al. (commonly referred to as POSA), which includes one of the early (1996) formalisations of the Layers pattern.

What does this have to do with SOA?

Well, the topic came up in a recent training course of what is SOA / what is a service. The training course level was such that only a basic description was appropriate, but what immediately jumped to my mind as important is that a Service Oriented Architecture usually consists of both coarse-grained business services, as well as fine-grained implementation services (often with a workflow component as a means to aggregate them).

Although a lot of knowledge can be learnt on the job, being passed on by other software engineers, it can sometimes be an eye-opener to actually go back and read the original description.

In this case, when defining an Service Oriented Architecture I would strongly suggest reviewing the Layers pattern and think about how your services might be structured in layers. Think about the different abstraction levels you have in your system, name the different layers and assign tasks to each of them. In particular, think about some of the issues from step 4 ("Specify the services"), and step 5:

"5. Refine the layering. Iterate over steps 1 to 4. It is usually not possible to define an abstraction criterion precisely before thinking about the implied layers and their services. Alternately, it is usually wrong to define components and services first and later impose a layered structure on them…"

One way I have seen service oriented architectures broken up is with different layers for Business Process Services, Business Function Services and Data Services, each with their own responsibility and features.

For example Data Services encapsulate business data entities specific to a slice of the business and are usually atomic, stateless, don’t change often and are highly reusable, whereas Business Process Services are designed to encapsulate business process and workflow, are implemented through a stateful orchestration and will change more often.

There is a good diagram of how the different abstraction levels (Layers) of services can interact in "Understanding Service Oriented Architecture" in the inaugural January 2004 issue of the Microsoft Architecture Journal.

Advertisements
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: