SOA, May You REST in Pieces.

Save your valuable time and don't watch this attempt to pump blood into a cadaver: http://www.infoq.com/presentations/Reincarnation-SOA-Anne-Thomas-Manes.  This presentation was so staggeringly ineffective and useless that I felt moved to write yet another SOA epitaph.

I believed in SOA at first.  That was until I had to get small web-based applications built, quickly.  That was until I tried to integrate one of them with Amazon Web Services and went with Amazon's RESTful version (as did an overwhelming majority of all other mash-up developers).

On planet earth, SOA was a vendor-driven monster the best of us eventually ran from.  To survive it, we protected our sanity with a bit of HTTP armor and plenty of REST.

It was about this time that I fell in love with Ruby and eventually, Rails.  Rails, in case you've been living in a SOA catacomb, is a RESTful framework from the smallest brick, on up.

But hang on, buzzword vultures.  Even Rails, at the time of this writing, isn't even cutting hype-edge anymore.  'Cloud', whatever that really means, is all the rage.

And yet, technology hype cycles, no matter how overblown, do have real value.  Planted in the compost pile of rotting buzz are vibrant seeds of truth.

If nothing else, hype cycles force us to take sides.  Sometimes these sides form around the best way to grow a seed of truth.

In fairness to SOA, we were confronted with the idea that standardized system to system interaction over HTTP (with XML and XML Schema) could be an effective building block for highly interoperable systems. 

Fair enough.  So where did it go wrong?

As I see it, SOA architect-astronauts described the wrong environment for growth of standardized system to system interaction over HTTP.  Specifically:

• In reality, there were too many non-standard vendor implementations of WS-* (WS-Death*) which led to ...
• WS-* required wholesale vendor buy-in to expensive tools and software infrastructure.  Startups not welcome!
• SOAP didn't effectively reuse aspects of HTTP.  It ignored three other useful HTTP verbs completely, missing a huge opportunity to make web services really simple.
• SOA required massive up-front thinking to be even partially useful.  Despite SOA evangelists' insistance in top-down/bottom-up agnosticism, SOA was not a bottom-up/organic way of thinking.  And, more than we'd like, 'organically' is typically how we must go about building systems.

Sometimes you see a presentation that is so vapid and useless that you're moved to do something about it.  Or, just moved to throw up.  This was one of those for me.

OK, OK.  Being positive ... 

A little reminiscing from time to time does help you think about how you got to where you are and the little disasters that, with God's grace, you navigated along the way.   For that I'll be forever grateful.

*Organs play ...*

Comments

[Graham Glass]

Hi Ben,

An SOA doesn't imply SOAP. So is your article really saying RIP SOAP, or something else? For example, an SOA can use REST/HTTP/JSON as its mechanism for exposing services, as RAILS does very well. I'm exposing EDU 2.0 as a collection of services using this approach.

Cheers,
Graham

[Matt]

Thanks for posting a response to the video - it's good to hear everyone's opinion.

Some thoughts:

If all you need to do is build small web apps built, SOA is probably too much overhead. But what happens when you need to architect a bigger enterprise system?

I'm not challenging your criticisms of "SOA 1.0" - they seem spot on. But I think the principles behind SOA are valid and very applicable to large enterprises.

You can of course disagree with that last statement, but if you don't, the question is, what is a better foundation for a Service Oriented Architecture? Does REST provide everything SOAP does?

Let's forget, for a moment, the amount of time it takes to create standards, etc. In a vaccuum (time and money are unlimited), how would you architect your own SOA environment?

Thanks again for the post, and looking forward to hearing your thoughts!

[Ben]

Hey, Graham. True, SOA doesn't have to imply SOAP.

However, in most texts and conversations I was a part of, SOAP was a given.

Love the REST/HTTP/JSON stack, btw. Also, congratulations on EDU 2.0 - it's looking really good these days.

[Bob]

Hi Ben,
I agree that the term SOA is dead but not the concept. The problem is as with most things in IT, the vendors get a hold of the concept and create the silver bullets that will be our saviour. Developers then pick up on the idea and run out and buy one of these SOA things and port all their existing applications onto it without really understanding what the benefits of it are. To me the most important thing about SOA is that it is a way of describing your business operating environment. The value chain of an organisation consists of the execution of a number of business services, some manual, some automated. If our applications can reflect the automated services in a cohesive and loosely coupled way then they will better respond to the changes in the real world because changing a value chain will result in changing the individual services. I am not aware of a single vendor offering or technology that delivers that. SOA tells us how to do architecture. Not implementation. Web services are dead, long live SOA.