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, my 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?

Inviting

This is a duplicate of #974173 and many others, but I'd be inclined to leave it here, simply because it has the best subject line. – Widen

You're not a troll and there is NO difference to client-service architecture you did 15 years ago. Or even 30 years ago. SOA is simply a buzzword for applying computer software fundamentals. It makes the architects and project managers feel better when they sleep at night I suppose. – Wallford

Answer 1

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.

Potentate

I can sumarise it! "SOA is not a technology...is supposed to solve...From a business perspective... duplicate and inconsistent data everywhere...pissed off and real money is lost" – Splint

^ Correct. It's not a technology at all, even though many employers who Ive interviewed with seem to think it is. It is a buzzword to incorporate software development fundamentals and practices that have been happening since the dawn of computer software development. Prove me wrong? – Wallford

"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." -----> What services? You are implying everyone who buys into SOA is using a standard set of SERVICES? What services make you SOA compliant? Define that. You cant!! I will bet you some dollars on that. – Wallford

@Devtron: I will bet you some dollards that you misunderstood what I wrote. I am saying that the point of SOA is designing your apps so that they provide their functionality as services to each other. Tha's why it's called SERVICE Oriented Architecture. You seem to be thinking about specific external services provided by vendors. Different thing, though it can certainly be a beneficial side effect to have those more easily accessible. – Potentate

How is Service Oriented Architecture any different from any other software architecture? Anything can be viewed as a "service" in an application. Define "Services" please? You cant. It all relates to fundamental computer design and programming, the basis of all relevant software. SOA is simply a buzzword to spin and re-define "the wheel". Until someone comes in an defines what "services" in SOA are, it is simply all hype to me. – Wallford

@Devtron: why so aggressive? Of course I can define "service" in the context of SOA: it means that the functionality of the application is available via network, through well-defined, documented interfaces, and without dependencies. So what if that's not a fundamentally new concept? SOA does not re-define anything, it merely puts the focus of application design on this hitherto often neglected aspect. The fact that it was used as a buzzword and distorted through hype does not mean that the underlying idea has no value. – Potentate

Answer 2

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.

Mima

Hmm. We've had unix, tcp and ascii since the 70s. That level of integration is nothing new. – Zeculon

Oh you're correct. We've gone from random proprietary ASCII to standardized EDI to customized EDI to standardized XML to customized XML. At least XML brings schema integration with it. – Mima

^ XML is bloated crap. You know how much bandwidth could be saved, using CSV/flatfiles instead? – Wallford

and why in the world would XML even need schema information? Are you telling me you are exposing your schema, through XML? I am anti-XML, obviously, but I cringe at the thought of providing schema information in a data file. Schema should never be exposed directly, this is why XML sucks. – Wallford

@D3vtr0n: 7 years later, but I am curious: why exactly you think "Schema should never be exposed directly"? Maybe you misunderstood, the actual schema is not included in the data files except sometimes as an URL. The point is that there is a standardized, flexible way of defining a detailed schema that is understood by all parsers and can be used to validate documents, and that definitely has a lot of value. – Potentate

@D3vtr0n: as for the bloat, that is really a non-issue; in nearly all cases bandwidth is not at all scarce, XML documents are still small relative to other payloads, or the bloat can be neutralized by transport-level compression. Sure, if you need to communicate with a low-power microcontroller via BLE, XML is really not a good fit, but that is not what most people are doing. – Potentate

@MichaelBorgwardt speak for yourself about bandwidth, You dont know our bandwidth and are making gigantic assumptions.XML is bloated and was bloated even when it became a standard. I am happy it's dying off. – Wallford

@D3vtr0n: I explicitly said that there may be exceptional cases where XML's "bloat" is in fact a problem. It is in fact you who's making gigantic (and simply wrong) assumptions when you claim it is relevant in general. Then again, if you believe XML is "dying off", maybe you're living in a parallel world were everything is different. – Potentate

Answer 3

SOA is nothing but a way of design, in which the modules comunicates with each others through "services". It is just that, and now the next question is: what is exactly a "service" and what is its difference with a regular "method"??

A service is an operation that performs a single, atomic business operation. This atomicity make it highly reusable from many modules. Then a complex business operation is just the orchestation of the invokation of many of these services in a specific order.

SOA has nothing to do with specific technology, is just an specific way of designing.

Jordanna

simple and precise – Venditti

Answer 4

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.

Plantation

With all due respect to Professor Frank Leymann, who is he, and why should we care? – Widen

^ I dunno who he is, but he sure hit the nail on the head, in exposing this fraudulent buzzword (SOA). – Wallford

Answer 5

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)

Abrams

+1 for a great series of musings and for leading me to the Chuck Norris inspired SOA Facts! – Optimism

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.

Bandur

word. its just a "wrapper" word, to spin ancient technology. – Wallford

Answer 7

For me, a Service Oriented Architecture comes about when an Enterprise wishes to integrate a selection of disparate applications which concern a common domain into a set of interoperable services which operate against a single data source.

In the case of a new startup company with an idea for an item of software/suite of softwares, I can't see how a company can kick off with a Service Oriented Architecture from the off. At first, each solution (which may well evolve into a service such that it may become interoperable) should seek to solve its problem space in isolation.

Perhaps it will be in the roadmap for an enterprise capability or suite for each solution to become an interoperable service as the solutions are completed and enter service. For this, perhaps the development teams will undertake a modular/component oriented approach to building the soluton (eventual service), so as to make it easier to include the solution as a service in a Service Oriented Architecture.

In the case where existing islands of software are to become interoperable services in a Service Oriented Architecture, the approach allows for the software items - which may be distributed and may be written in different languages - to communicate via an exposed API and/or common protocol (for example a flavor of Web Service) and generic data format (for example XML).

SOA is an approach or idea. It is not a framework or a tool. When WDSLs and EJBs get name-dropped, this is often forgotten... as is that the idea of SOA is not new at all.

Optimism

Answer 8

Most of the answers here seems to convey that SOA (Service Oriented architecture) is about building application in a standardized manner so that other applications can interact with it in platform independent manner.

I am not sure if meaning has changed since but I have had an opportunity to work with a company that offers SOA suite and following are my thoughts on it.

Of course when you design an application you cannot guarantee it will be cross platform compliant. Take for example stock Trading systems. They use Fix protocol to transfer messages. Do you expect it now to return data in XML format so that it can be so called SOA compliant? Definitely not! SOA is an architectural approach that can help you decouple your application/services and let them interact with each other. Backbone of SOA is a ESB (Enterprise Service Bus) which is used to transfer data from one service to other. SOA architecture should take care of formats conversions. For example -

FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)

These conversion modules are commonly called as adapters and are generally part of SOA suite. For a bit more information refer to another answer -

Difference between SOA and ESB

Sure SOA is a word is hyped for marketing purpose. Technically speaking it as simple as de-serializing and serializing data so that services can be decoupled and platform independent but the idea behind it is concrete.

Also refer Wiki page for the same.

Pentheus

Answer 9

A service-oriented architecture (SOA) is an architectural pattern in which softwares are designed as building block. i.e. Modular development, which makes flexibility to assemble any way we want. If you want to start new project instead of starting from scratch, we can reuse the services and if you want to new service we can easily integrate with existing service to make new project. So we can save lot of time and money.The basic principles of service oriented architecture are independent of vendors, products and technologies.

Analogy: Toys build using Lego building blocks.

Angola

Answer 10

In reality, SOA is a collection of well-defined services. Basically SOA use loosely coupled service to get the desire result easily. Implementation details of a service are hidden from the client/consumer so any change in the implementation doesn’t affect the service until the contract between them is change. Service providers are components that execute some business logic based on predetermined inputs and outputs, and expose this functionality through an SOA implementation. This allows systems based on SOA to respond more quickly and cost effectively for the business. The main difference between component and SOA is that, SOA provide a open standards message which is not specific to any programming language or platform. As a result, you can achieve a high degree of loose coupling and interoperability across platforms and technologies. In a traditional client-server world, the provider will be a server and the consumer will be a client.You can read more about SOA here :Service Oriented architecture (SOA)

Avlona

Answer 11

In fact, SOA also utilizes client-servier architecture. In addition, SOA is a way to design your software. Suppose that your application can break into simple and independent tasks like search a book, add new book, recommend a book according to user preference and so forth. If you consider a service (an API) for each of task, actually, you are using SOA. The advantage of this architecture is doesn't matter you're building a web app or mobile app, you only need the developed aforementioned services (APIs).

Moneybag

Answer 12

Service-oriented architecture (SOA) is a design approach where multiple services collaborate to provide some end set of capabilities. A service here typically means a completely separate operating system process. Communication between these services occurs via calls across a network rather than method calls within a process boundary. SOA emerged as an approach to combat the challenges of the large monolithic applications. It is an approach that aims to promote the reusability of software; two or more end-user applications, for example, could both use the same services. It aims to make it easier to maintain or rewrite software, as theoretically we can replace one service with another without anyone knowing, as long as the semantics of the service don’t change too much.

Batik