Monday, May 22, 2006

SOA 2.0 ignorance

The viral nature of gossip has taken hold of SOA 2.0 and run with it. There are more and more articles coming out every day, or so it seems.

My question is this: why do we need the term? OK, if you're an analyst firm looking to stand out from the crowd I can understand throwing a lot of new buzzwords at a wall and seeing which ones stick! But for the rest of us living in the real world, it has no meaning at all. Despite all the hype, I think we're all agreed on what SOA means: it's an architectural approach to building loosely coupled applications. Companies have been "doing SOA" for many years, even before the term was coined, using technologies as diverse as CORBA and JMS. Think of it as a pattern, or an architectural approach in the same was as distributed object-oriented systems. It has its place in any good architects toolbelt and we're finally coming to grips with it as an industry.

Then WHAM! Along comes SOA 2.0! How? Why? WTF?! I also expected more of Oracle on this one! Giving an architectural approach a version number is crazy: it makes no sense at all! Only in software would we even consider such a thing. Can you imagine going back in pre-history: is a hut also to be known as Cave 2.0? Would a house be Cave 3.0 or Hut 2.0? Where would the St Paul's Basilica come in the grand scheme of things?! If something is truly an architectural advance over its predecessors, then it should be named uniquely for a start. Caves, huts, houses, high-rise buildings all share some commonality, but they have different architectural approaches too. To call the Empire State Building an upgraded cave is to do it an injustice (at the very least)!

Steve says it's about a combination of EDA and SOA. I hate that distinction because I think that either EDA is a specific implementation of SOA or it's simply another way of reasoning about your SOA system. Gartner then say that the difference is that SOA 1.0 (yuch!) was about client-server interactions and SOA 2.0 is about events. Apart from seeing my previous comment concerning EDA, where does it say that SOA is all about clients and servers? For a start, that implies synchronous interactions, which SOA certainly doesn't require. Secondly, I know of many SOA deployments that work on an asynchronous peer-to-peer level. Hey, maybe those guys are doing SOA 3.0?!

But in all seriousness, it seems to me that people are confusing implementation with architecture. Where does it say that SOA has to be client-server driven? That's a fairly arbitrary (aka poor) way on which to base architectural differences: by any strict definition of interaction styles, something is always a client (sender) and something is always a server (receiver), but those roles can be transient and change between invocations. That's the case in most distributed systems, not just SOA based. In the early days of distributed systems it was common to have entities that were pure clients: that's less of the case these days. Take a look at some event-driven systems: they have clients and servers too!

Furthermore, is it then really necessary to confuse the issue by adding implementation semantics within the architectural approach (i.e., events)? Why not give it its own acronym, something like that captures events, the fact that they drive things and that it's an architectural methodology? Hmmm, that would then be EDA and I'm sure some analysts coined that term a long time ago, but it didn't really capture the public imagination like some other three-letter acronyms.

You know, a more cynical person might think that the only reason for SOA 2.0 is to ride on the back of all the Web 2.0 hype that's going round at the moment. But our industry doesn't work that way, now does it?

So stay clear of SOA 2.0. If you really want to talk about SOA and EDA then do so as separate entities in their own right, or coin a new term (any suggestions?) EDSOA?


Greg Pavlik said...

Good to see some passion there Mark. But I think you're being a little pedantic for the target audience.

In practice, most people have been conflating SOA and Web services. What people are trying to get across to CIOs and IT architects is that that's not quite right: we're maturing to an architecture that combines both service invocation-style interactions and messaging.

The second problem is that there is not a clear mechanism to rationalize how these two styles should be combined. What Oracle is coming to the table with is a model that combines invocation style semantics and broadcast semantics into a coherent, integrated framework. The Fabric platform extends SCA to include support for business events, and provide a model for moving between the two modes of interaction seamlessly.

Call it what you want -- or don't give it a name. At the end of the day, the discussion among practioners has to happen somehow. To my way of thinking, this is as good a mechanism as any.

Duane Nickull said...

Mark - awesome post!!! Couldn't agree with you more. More on subject here:

Anonymous said...

How about EDSOA 2.0?


Mark Little said...

Greg, I don't think I'm being pedantic at all (not so sure about passionate either). I understand why we may want to indicate the transition from one implementation approach to another, but calling it SOA 2.0 isn't the right way to go (to be honest, I'm not so sure about the Web 2.0 tag either). I thought I'd made that clear in my post. SOA is an *architectural* approach. Web Services is an *implementation* style. We shouldn't confuse the target audience by bundling things together like this.

As an industry, if we believe this "new era" needs a name, let's give it something unique. The Cretaceous Period wasn't named Jurassic 2.0 for a very good reason!

I still wonder whether SOA 2.0 would have been so named if there wasn't so much activity around Web 2.0!

Neil Ward-Dutton said...

Nice post Mark!
I just came across this (unattributed) quote: "Everyone is entitled to be stupid, but some abuse the privilege." I think it sums up pretty well how I feel about the recent emergence of the term "SOA 2.0"...

See my post here. (I referred to you, but you don't have trackback enabled...)
If I get some encouraging comment on this post, I'll set up an online petition...

Mark Little said...

Thanks. As Greg alludes to, I don't usually let things like this (aka Analyst Speak) bother me, but this one just goes too far.

Mark Little said...

James McGovern said...

Creating new terminology for things we have always been doing also helps us book authors :-)

Does AJAX fit into this same camp?

Neil Ward-Dutton said...

Thanks for the support Mark!
The petition is now up - see

Fight the power! ;-)


Unknown said...

This is the essentially the same problem of Web 2.0... "now it is safe to go back into javascript waters".

It is the need to create a market. SOA wasn't understood so let's further confuse people by adding a version number, seemed to work with DHTML and javascript.

Freedom to add events to a service which I am sure will trigger the usual discussion about whether an operation within a service is an event. What is an event... maybe Duane needs to update the SOA Reference Model with some version numbers on the entities. :)

Jack van Hoof said...

Hi Mark,

Perhaps the SOA-EDA discussion is a matter of definition, but:

Did you ever notice that EDA is an inverse of RPC-style SOA? (RPC-style SOA: may I nowadays call that SOA 1.0 since the raise of SOA 2.0?) In EDA the data-supplier takes the initiative in contrast to RPC-SOA where the consumer does. In EDA the supplier and consumer do not know anything of each others existence, they are decoupled. On the other hand in RPC-SOA the consumer calls the supplier by name and even waits for a reply. If the reply doesn't come, the consumer falls into an error procedure; that really is tightly coupled, isn't it?

You can have RPC-SOA to behave asynchronous by using asynchronous queues to perform service requests. Well, you are tricking around but it is not EDA; EDA is asynchronous by nature, you can't trick it to act synchronously. EDA has focus on data (message) while RPC-SOA has focus on function (service).

EDA has affinity with business processes and SOA has affinity with application construction. Taking into account that the EDA approach is an inverse of the well known SOA approach you might say the two paradigms are complements by nature.

I recognize a huge business potential of asynchronous, event oriented design. And I believe that EDA by its nature will be the paradigm to realize the ultimate alignment of business processes and the supporting IT-systems. I think that the ultimate layer between our real world events and artificial application constructs will be an EDA. And I recognize the possibilities offered by the current IT-technology evolutions to support this paradigm.

Jack (see my thoughts here)