Pete Lacey started an interesting discussion a few days ago when he reopened the debate over the use of the term “SOA” in his blog post “What is SOA?”. He certainly dove in to attack the idea of SOA, but did not come to any useful conclusions.
He starts by offering a humorous anecdote to explain, to himself apparently, why we need SOA. The most interesting line is this, when describing how CORBA was a huge innovation:
“CORBA. Look, see. Interoperable remote procedure calls.”
Interoperable remote procedure calls. Yep. That was CORBA. Jump down a little…
Worse, CORBA wasn’t quite as easy to use as it seemed. It was complex, nothing interoperated, it didn’t work through firewalls, and a bewildering number of specs were coming out of the OMG.
“Well, how about this new SOAP thing,” said the new new guy…
OK… so here comes SOAP to replace CORBA for what… interoperable remote procedure calls. See where this is going? Fast forward again.
We just need to give this idea a name.”
“I’ve heard it called service-oriented architecture,
So, according to Pete, SOA is a name for a technology, based on SOAP, used to give us interoperable remote procedure calls. I shudder at the thought.
From there, Pete goes on to criticize SOA because it isn’t an architecture and the term ‘service’ doesn’t suit his mindset. Heck, with that definition, he’d be right.
Give me a break! Service Oriented Architecture is not RPC. People who write RPC code to integrate applications have created a ball of rubber bands in their infrastructure… I don’t care if they used CORBA, or DCOM, or RPC, or Stored Procedures, or synchronous pixie dust! When you follow an antipattern in your architecture, the technology cannot save you.
The moment you criticize SOA on the basis of the technology, you’ve missed the point. SOA is an architecture… a technology agnostic architecture. It requires the basic things that are so difficult that folks are afraid to do them, and therefore the technical implementation fails and people blame the technologist… what are these so-important things that people are afraid to do?
Common Information Model
Common Business Event Model
Common Solution Model
Common Technology Model
I dare you to make any form of simplified, integrated, agile infrastructure work without these things.
What is going to become of the ‘beloved SOA’ for those geeks who live and breathe the term? Oh, who cares? We will rename it and it will keep coming back, just as it has always done. Pete even suggests a new name, “Network Oriented Computing.”
Oh… right… we renamed it. THAT will make it work!
The concept is sound. The concept works. (Every implementation of SAP is based on the above elements. SAP integrates extremely divergent systems into a single scalable platform. There’s your proof of concept).
So stop arguing about the name, for goodness sakes. Attacking the name of something you don’t understand is a tactic best reserved for pundits and political candidates. If you don’t like the politics of your opponent, attack his (or her) clothing, hairstyle, automobile, whatever… something that has nothing to do with the point.
Just as Pete did.
6 thoughts on “If you don't like the senator's politics, attack his clothing”
PingBack from http://www.artofbam.com/wordpress/?p=6943
The point of that post, so evidently lost on you, was not to attack SOA, but instead to get people to stop debating what the heck SOA is. In a long winded way I suggested that we reserve the term SOA to describe the technical aspects only. Specifically those technologies that promote an interface describing a collection of operations as their key abstraction. This is in contrast with resource-oriented architectures which promote the resouce as its key abstraction. I invented the new term network-oriented computing (since changed to network-centric computing: http://wanderingbarque.com/nonintersecting/2007/10/08/towards-a-better-network-programming-taxonomy/) to encompass the definition of SOA that you describe.
For the record, though, I am partisan. I do not believe WS-* to be effective technology and I do not believe SOA as practiced (especially its focus on "common") to be an effective model. YMMV.
Oh, the message wasn’t lost. Be aware that, in the process of promoting a new term, you certainly took a stab at the existing one.
I fear we simply will have to agree to disagree on some of the points in your article. One that says, for example, that SOA is not architecture, and another that says that SOA folks picked the wrong technology (which implies that SOA is a technology).
The fact that you reiterated your statement that SOA should be reserved for technology illustrates my point. You do not understand SOA.
I don’t give a flying darn about WS-*. The fact that you think I may makes sense only if you believed that SOA is somehow related to Web Services. Web Services is a tool that can be used to implement Service Oriented Architecture… and SQL Server is a tool that can be used to implement a Relational Database.
Would you criticize the entire concept of RDBMS because you find a flaw in SQL Server, a flaw not shared by Oracle? I think not.
Let’s seperate the implementation from the concept, shall we?
The term SOA has become so bastardised, that misunderstandings like RPC and SOA having any relationship have become horribly blurred.
The best way to realise you aren’t doing SOA, is when you start doing RPC.
Reminds me of a previous boss who wanted me to stop talking about "services" , I was only allowed to talk about "web services" as he had "bought" SOA from IBM and that was what they told him he should refer to only!
So many things to do, so little time, this is what we call a catch-up post SOA Nick starts a new series
So many things to do, so little time, this is what we call a catch-up post SOA Nick starts a new series on Integration with SOA and the CISR Operating Models and adds SOA in the Coordination Models Nick also on a Tale of Two Visions Both Arnon and Nick