SOA Fable: Do you wear a watch?

Most of us wear watches, and except for those who wear it as a piece of jewellary, we expect a service from this piece of equipment. And what is the unique service provided by this equipment? It lets us know what time it is! Wait, hang on. Aren't there enough service providers, providing this very service, around us? Well every car has a clock in it. every house has many clocks, every PC has a clock. Even every mobile phone, PDA, iPhone has a clock. Why do people wear watches, anyway?

What are your expectation as a consumer from a possible service telling you waht time it is?

Availability: Service must be available when consumer needs it.
If a consumer relies only on mobile phone and battery runs out. The service is not available when consumer may need it.

Reliability: Service response must be reliable and should not require double checking.
A consumer is not sure of the time shown by a clock at public place, he needs to double check it with another reliable source anyway.

Accessibility: Consumer can access the service whenever he needs it.
A clock in laptop in backpack is not easily accessible in a crowded commuter train.

Trust: Consumer trusts that service is backed up by accountability on part of a service provider. When it is a question of life and death, one can trust service provided by one's own piece of equipment to be accurate, reliable and available than a general purpose service. As a consumer one tend to trust no one but oneself as most accountable service provider.

This is a very important insight which helps one prepare a proper versioning policy.
Without that trust versioning schemes can be mis-used for creating specialized services.

In enterprises, since SOA is mandated, project owners will use services. But they will make sure that they get their own private version of a service. This is quite easy by getting a veto power over life cycle of a service and mis-using governance for this sake. Assume a service version 1 is in use. Second consumer wants to create another version, because it has additional needs. This version 2 is derived from version 1. Now first consumer wants an upgrade to his existing service. But he is not willing to accept service version 2 as base for its next version. He will find any execuse to make sure he gets a service version 1.1 rather than 3. This pattern will keep repeating. And soon there will be a lot of versions, changing only in second qualifier. So you will get, what I call parversion (parallel version) anti-pattern.


SOA governance must make sure it guards against this anti-pattern and creates appropriate policies and controls to minimize and eliminate its occurences. Morover governance must recognise that this is a symptom and root cause lies somewhere else.

Moral of the story: Consumer is willing to bend rules to get an acceptable, reliable, accessible and trustworthy service. Watch out for such rules violation and fix root cause.

Blogged for an year

It has been an year since I started to blog regularly (well at least once a month). The blog has given me a platform to express my ideas. I expected a lot of interaction with fellow professionals. That expectation has not been met, mainly because of my inability to continue conversations. Carrying out conversations over blogs need a lot of commitment. Balancing work, personal commitments and finding time for this activity been a challenge for me. For that reason I am in awe of bloggers who blog daily and on variety of subjects.

But whatever limited interactions I have had, opened my eyes to new ways of looking at things. I am ever thankful to blogosphere for enriching my professional life. I hope to meet some of my on-line acquaintances, whose thoughts I found insightful, in person. I also hope someone, somewhere might have found my thoughts useful and feels the same about me.

Not whether but when to REST

There is a debate starting to rage about whether REST or SOAP/XML-RPC is better choice for services. Following is my take on REST v/s SOAP/XML-RPC debate, in traditional enterprise computing scenarios.

From whatever I have read till now, my opinion is that REST is quite close to a distributed object oriented abstraction than a service oriented abstraction. Following table tries to bring out similarities between REST and OO abstraction.

REST	OO
In REST there are resources	in OO you have Classes and Objects
In REST there are HTTP methods(PUT, DELETE, POST, GET ) for lifecycle management	in OO you have facilities provided by OO language (Constructor, Destructor, method invocation, accessor methods)
In REST resources keep application state information	in OO object represents the state
In REST type safety is provided by XML schema	in OO type safety is provided by pre-shared class definitions (e.g. using .h files or java .class files)
In REST dynamic invocation is possible because of repository	in OO dynamic invocation is possible because of reflection.

Of-course REST provides a more open distributed object oriented mechanism than say CORBA or EJB. It does it by usage of XML schema for marshalling/unmarshalling and open protocol like http (as against dcom, iiop or rmi).

But it is bound to face the some of the problems that distributed object oriented mechanisms faced. e.g. granularity of objects, scalability related issues, differing consumer experience based on lazy or early instantiation of resource graphs (object graphs in OO).

REST is an interesting way of implementing distributed object oriented mechanism, and there are times this abstraction is better suited than pure service oriented abstraction. So in my opinion debate should not be either REST or SOAP/XML-RPC, but when to use REST and when to use SOAP/XML-RPC. The limiting factor for time being is availability of tooling and skills. Over period of time these will develop and then, within enterprises both can co-exist.