This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Can I Get Another Amen?
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
“With regards SOA, I'll again ask the question "What does the 'A' stand for?” If, to you, the 'A' infers 'Architecture', are you telling me that you're going to build your enterprise architecture on top of a quagmire of quicksand? The term SOA is so poorly defined, is so inconsistent and incomplete and has such little value as a term that we have to create new acronyms and terms to describe stuff that fills in the gaps that are missing in the SOA story. Enter, ESB. Some claim that in order to build a SOA you need an ESB. Others claim that by building a SOA you get an ESB. Both are claims made by salespeople selling snake-oil.
The whole SOA/ESB thing is all hype, people! Once you come to realize and accept that, the world becomes clearer. You don’t believe me? Define what SOA is. Then try and find one other person that agrees with you wholeheartedly. If you’re lucky enough to manage this, try and apply your definition of SOA across more than one platform / technology. Repeat for ESB. Good luck! There’s a reason that OASIS is spinning up a technical committee to try and reverse the industry out of this mess.
However, whilst I don’t buy the SOA/ESB hype, I am a firm believer in the principles of Service Orientation as I have articulated several times in this blog. The principles and tenets of SO are technology and platform agnostic. SO contains the mindset and philosophy used to build decoupled, flexible, agile, consistent, available services. As I have said before, the tenets of SO has as much to do with a specific technology as the tenets of OO had to do with a particular object technology.
When it comes to SOA – stop! Let’s get a clear definition of what services are, what they are not, what they are for, how they should be used, what are the guiding principles of SO, etc. Only after we’ve got clear, consistent, broadly adopted definitions of these things should we then try and define an architecture in which we use them.“
Previous Topic
