This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Clemens says SOA doesn't exist
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
First read Clemens' post. Now, my comments.
I'm not a historian so I don't think I can comment about SOA's newness. However, I do find that if we treat the autonomy tenet as one that includes the meaning that one service will not be "actively waiting" for a response from a different service, that is, that the initiating service can be handling other requests until a response comes back, then the design of the service will be quite different from many of the designs common today.
Why do I think that this meaning of autonomy is valuable? Because, if a number of services on which our initiating service depends are "experiencing technical difficulty", their response times go through the roof, then the "active waiting" which entails holding resources open per request will bring about a self-inflicted denial of service. This would be the exact opposite of autonomy, in my opinion.
A service's availability should not be affected by the services on which it depends.
This would directly affect the way a service handles state. In fact, it makes the message-processing workflow into explicit state that needs to be managed.
Therefore, by viewing state as one of the pillars of architecture, we can say that service orientation does impact our choice of architecture. Would I say that this is "special" about SOA? Well, yes, in so far as it separates SOA from other architectural approaches and the steps taken to get to them.