Has the term "Service Oriented Architecture" become meaningless jargon? [closed]

Question

I was asked today if I had experience with "Service Oriented Architecture" and although I think I do. The concept, to me, seems so muddled I don't know how you could honestly answer that question anymore.

I resorted to Googling the term in an effort to get a concise definition of the concept and how it differs from other architectures. After reading a number of articles on it, the only common thread I seem to be able to find is a system with multiple components that talk to each other over some kind of interface, with perhaps a slight preference for XML/SOAP.

It seems like almost any application could be defined as SOA, especially a web application. Has this term fallen into the "Web 2.0" trap and become a term meaning whatever you want it to mean?

Am I way off base here? When you guys hear the term does it mean anything specific to you? If so I'd love a concise definition that clearly demonstrates what is and what specifically is NOT SOA.

Answer 1

I believe the original meaning of SOA was based on services with well-defined interfaces that can be consumed programmatically. The focus was on service interfaces rather than UI terminals, communications, or databases. The key part was services consuming other services. Service A can call Service B, get the result and call Service C or D. You can have a set of specialized services and architect a solution out of it by combining them in a way that solves the customer problem.

SOA is often confused with SaaS (software as a service), which refers to the pricing model where the user pays for the usage of the service they subscribed to, rather than buying a license to a copy of the software product. To answer the third paragraph in your question, a Web application is probably not SOA, but can be SaaS.

The term has definitely lost some of its meaning. In the organization where I work, the term SOA is often used interchangeably with SaaS and refers to a team of IT professionals (information technology as opposed to software product development) who configure servers and routers and install software products to run on them. Some of them have titles like "SOA Architect", but none of them have anything to do with architecting, designing, implementing, or testing the software.

Answer 2

I have done the same thing googling SOA to see what it really is, and yes it is abused quite a bit. When I think of SOA I think of the following:

1. A discoverable headless program...
2. That makes use of stateless connectivity (ala HTTP)...
3. Communicating in platform independent formats

SOA can be contrasted with Client-Server architecture(a stateful service architecture) and libraries, which are modules connected to programs through a linker.

So when people talk about it I generally take it with a grain of salt. I also tend to just call it "web services". With web services the architecture is implied.

Answer 3

The strict definitions of SOA are far past the cost/benefit line as to be theoretical in many cases.

Unless your product is the services themselves you often need a different point of view.

A USABLE definition of SOA means that your overall architecture is service friendly. A system built completely from atomic services is usually not the right plan, and some services are going to organized functionally while others are going to be single responsibility. I may have black boxes, I may have offline processes, but if there are a discoverable collection of services through which I can get a meaningful amount of work done that is my minimum definition.

Aside from the debate on what it actually means, the concept (whatever it means) has suffered in many circles by being applied to places it simply does not fit.

For example, If I am building something that is meant to be a black box process and scales through parallelism not segmentation and distribution I may have a service to expose/talk to the black box, but some people keep trying to put the services inside the box.

As a strict technical definition it has always been undefined, but the idea is not without merit where it fits.

Answer 4

I've had the miss-fortune to work on a couple of corporate systems where management has been sold on SOA. As a developer I look at the systems and I see a bunch of software behind a web service that does stuff. It could have been written in a variety of languages and architectures, non of which would matter or be relevant to the clients calling the services and non of which actually have the acronym "SOA" anywhere in their documentation.

But management want "SOA"!!! So they've bought really expensive servers from a certain large company that have "SOA" stickers applied on top of the previous "Web Service" stickers which have been applied on top of the previous "JEE" stickers which have been applied on top of .... you get the idea. And as a result, we as developers sit around dragging and dropping itty-bitty icons around a screen to create "SOA" "COMPONENTS" which work half as well as if we had done it with something simple such as EBJ3 beans, spring components etc.

So my advice is if you get asked about SOA, say "Yes I've done SOA, I've written many systems that make use of a Service Orientated Architecture to do things. Which SOA technology are you asking about?". And if they start talking with glowing eyes and wistful looks about a SOA COMPONENTS, DRAG AND DROP, and how it makes developing easier. Back away slowly and avoid making eye contact!

Answer 5

I think it might make sense a bit: one thing is when you have "slave" modules called when needed, and another thing is when you have service/daemon processes running independently and responding to your requests, possibly talking to each other, living their own life in other words. With this approach you can have a huge, scalable, physically distributed system. I've seen some in the area of mobile telephony, for example. But this is just a guess.

(Now let's see what Wikipedia says about SOA... Whoa.)