This post originated from an RSS feed registered with .NET Buzz
by Anand M.
Original Post: What does SO have to do with Architecture?
Feed Title: .NET From India
Feed URL: http://www.dotnetindia.com/index.rss
Feed Description: Your daily dose of .NET From India
I had wanted to do this post for a long time now, but never actually got down to typing it out.
(Note: Some of the stuff I talk about here are outcomes of some discussions I have had over a few months time with many people)
The Tech community is well known to have a hype cycle for everything (I suppose it is true for a few other industries too, but I personally beleive we are the best). One of the things in the hype mode over the last year has been this stuff that is called SOA. The web is full of people talking about how SOA can actually change the whole way we develop applications (Paradigm shift, is a word that is usally always linked to a hype cycle).
So the idea is overtime everything you would want to do with a computer, would be written up as a service and you just buy different services and patch up an application in a jiffy. Sound good and attractive to the CIO. The only problem is that the services are not yet out there and writing a good service is such a pain in the worng place that few people even attempt it. Anyone remember what components were supposed to do. The interface that was supposed to be a contract stuff. Does this not sound very similar? Except that now you have different protocol underneath (SOAP instead of COM, so it is no longer MS alone hype, but the whole industry can join in). How much reuse has COM given us? What is the difference now?
The other stuff is about the term SOA itself. What does Architecture have to do with Service Orientation? To my mind, the major step toward SO, is that you decide on a Interface and a Messaging format and go ahead and do whatever you have been doing. So this is more of a issue that each programmer has to work on, rather than the Architect. It is like OO to my mind and nothing to do with Architecture at all. The only decision the Architect really makes is to use SO and maybe a little bit in the Service Interface design part. A lot of work on the message strucutre etc are usually made by the programmer and this is the most crucial part if you want reuse.
I also do not buy the argument that each service has to be autonomous etc. In a real business scenario, any part of the application cannot be autonomous. Worst case you need to depend on a external part called the Database server. So if the DB server fails the service fails. Also if the data is bad(What if I fire a few random Updates from ISQL), the service fails. So where is autonomy here?
That does not mean I am against SO. If you do it right, SO can improve reuse and interoperability. But I dont see too much of that happening. I only see people use SOA as miracle cure for everything under the sun.
So if you want go the service oriented way, first start training the programmers. Those are the guys who will have to do the most work to get your applications Service Oriented.
Previous Topic
