WebServices dot org

SOA 2.0 Ignorance

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?