Wednesday, October 22, 2008

Back to Basics: The Four Tenets of SOA

I've noticed that in some recent conversations I've had, people claim to have service-oriented architectures that stretch exactly what SOA means.

I've seen some recent examples where old-school point to point integrations are called SOA because they're built with web services, or architectures built with a scheduled FTP-Get called service oriented because it uses an
integration middle ware software component.

At the risk of sounding too much like a purist, I think it would be helpful to review the four simple rules that define SOA:

1) Boundaries are Explicit

Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message

passing rather than implicit method invocation.

2) Services are Autonomous

Services are entities that are independently deployed, assigned versions, and managed. This means that they should not be dependent on whatever is consuming them.

3) Services share schema and contract, not class

Services interact based solely on schemas for structures and contracts for behaviors.

4) Service compatibility is determined based on policy

Consumers must be able to determine the capabilities of a provider via a publicly accessible, standard policy.

I know that some people feel more comfortable with Batch/MFT or ETL patterns than with SOI because they've seen them work well in the past. However, I would argue that built properly, there is nothing about service oriented integrations that is less reliable than any other properly implemented pattern.

In order to achieve an event driven architecture and get the flexibility benefits that derive from this type of pattern, SOA is a prerequisite.

1 comment:

  1. preach it brother! I've seen a lot of that jabows (just a bunch of web services) stuff lately too, and people keep calling it "SOA". Don't even get me started on the batch stuff. It's so mid-90's