What is SOA (Service Oriented Architecture)?

Question

Call me a troll if you want, but I'm serious -- how exactly is the new SOA trend any different than the client-service architecture that I was building 15 years ago? I keep hearing SOA but I don't see how it's different than what we've always done. Back 10 years ago, ,y company had multiple clients (in multiple languages) which talked to the same service. It wasn't XML (it was a binary protocol called Microsoft DCOM) and there wasn't auto-discovery through WSDL but that's OK since reading the docs was just as easy. Our system was even "open" in the sense we documented it enough to allow 3rd parties to talk to our services. We were not pioneers -- every other company I knew 10 years ago was doing the same thing. The ONLY difference I see between then and now is that now there's a single service available on the internet, whereas 10 years ago, each customer would host his own instance of the service. But that's not an architecture issue -- where the service physically lives is transparent to anyone using the service.

So what exactly is SOA that's different than what we've been doing for years? Is SOA simply a marketing term representing a best practice that actually became common a long long time ago? Or am I missing some subtely to SOA that's different than what we've been doing all along?

Answer 1

a myth of gigantic proportions.

Answer 2

it's the same but worse. It's good for creating more programmer jobs.

Answer 3

Professor Frank Leymann from the University of Stuttgart takes SOA as a key concept for his Service oriented Computing (SOC) research work as he speaks about SOA. He is seen to be asked about the definition of SOA and the ensuing conversation could be a good read.

Please note that our roadmap is about "service oriented computing (SoC)", i.e. the compute paradigm behind service-orientation. Service Oriented Architecture (SOA) is an architectural realization of this compute paradigm. You may compare this with "client/server computing" as paradigm and "browser/web server" or "DB-client/stored procedure" as two (of various other) architectural realizations of this paradigm.

...

SOA is not completely new. Some individual aspects of SOA are used in practice for a long time. For example, take a look at "loose coupling": Enterprises are using reliable messaging technology since decades to integrate applications, i.e. to loosely couple them. Don't get me wrong, there are new concepts in SOA, e.g. concepts resulting from the combination of concepts put together in SOA, i.e. they result from emergence.

Web Service specifications make the corresponding technologies available cross platform. I.e. the corresponding specifications do not invent fundamentally new concepts but define how these concepts and corresponding implementations work in heterogeneous environments. The resulting interoperability is groundbreaking, making SOA real.

In summary, SOA is a mixture of mature things and new emerging things.

There is also a SoC paper reference dated April 2006.

---

A google search identifies Prof. Frank Leymann and his works.

Answer 4

Forget about XML. Forget about WSDL. SOA is not a technology you can buy, though it's often marketed that way.

The real point of SOA is all about IT organization. The point of SOA is to avoid having a huge bunch of "applications" that have isolated data pools and either don't talk to each other at all (and thus often duplicate data), or only in an inefficient, buggy way through adapter layers or EAI systems.

For large companies, this is a serious problem - they have literally hundreds of separate apps that are insufficiently integrated. There's duplicate and inconsistent data everywhere and the result is that customers get pissed off and real money is lost because the billing department keeps sending invoices for a cancelled order and the customer service rep can't even find the order because it's cancelled in the order tracking system, but not the billing system.

SOA is supposed to solve this by designing every app from the ground up to publish its services in a standardized, cross-platfrom manner so that other apps can access the data and don't have to duplicate it.

From a business perspective, this is highly desirable. The buzzword hype and the acronym soup is just IT companies' attempts to cash in on that desirability. Unfortunately, this has (mis)led many people, including CEOs into believing that SOA is a product you can buy and it will magically make your IT more efficient, without realizing that this will only happen if you also reorganize your entire IT (and quite possibly your business units as well) to be SOA-compatible.

Answer 5

It is magic; a silver bullet

See this and this

Answer 6

I think SOA is both a marketing term and an integration of existing solutions with the idea of instead of selling the whole software or machine, we sell the services.

Answer 7

Neal Ford has many strong opinions regarding SOA. You might find his viewpoint interesting.

Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)

Standards Based vs. Standardized (SOA & the Tarpit of Irrelevancy)

Tools & Anti-Behavior (SOA & the Tarpit of Irrelevancy)

Rubick's Cubicle (SOA & the Tarpit of Irrelevancy)

The Triumph of Hope over Reason (SOA & The Tarpit of Irrelevancy)

Guerrilla SOA (SOA & The Tarpit of Irrelevancy)

Answer 8

Let me use the famous whipping boy of Integration Hell: Telco.

Way back in the 90's, cell phone companies were plethoric in my neighborhood, almost as plentiful as the long distance resellers made possible by the communications deregulation of the mid 90's. Well, time goes on, and Bell Atlantic becomes the powerhouse that is Verizon, and swallows up company after company (and at least one Baby Bell). Every single one of these companies has technologies in place, in towers, in switching equipment, in billing systems that are COMPLETELY incompatible with one another.

So the company goes off and says, okay, we have these models for how we do business, let's put a friendly, consistent face on ALL of our technology in the form of WSDL/SOAP/XSD - every language and system we have today can be interfaced to this! Slowly but surely, the company is making all of it's systems capable of reporting on capabilities, being interrogated for load and billing purposes, and exposed for future visionaries to exploit in manners that haven't been accounted for yet.

Anyone can build a SOA client. Anyone with wget and a text editor. And anyone can parse the results (XML).

That is what's fundamentally different from past client/server architectures. I was just talking the other day to someone about interfacing Cobol and Smalltalk based systems to SOA architectures. That's an easy problem to solve. Tell me you can say the same for your DCOM systems.