If SOA is dead, what's replacing it?

Question

Please forgive me if this question is dense.

Background: We have several internal applications that integrate at the database. We are looking at how to break that up, and it seems like moving to an architecture where each application exposes its functionality through services, instead of calling other apps' databases, makes the most sense. This seems like a service-oriented architecture to me. As I look around for info on getting started with a service-oriented architecture, I see a lot of talk around this article: SOA Is Dead; Long Live Services. And I also see this from Martin Fowler & Jim Webber: Does My Bus Look Big In This?.

Question:

• Is SOA dead, or just the buzz around it?
• What is the best way to start on a service-oriented architecture so that it can stay as thin and simple as possible?

Answer 1

SOA is a clever idea, but an enormous hype around it made people writing "SOA IS NOW DEAD". This is not true, just as sentence "Structural programming is dead everybody do OOP now!" is also not always true: sometimes structural code is the only option, but the decision should be made on evaluation, and not on hype. The same is true when talking about SOA: sometimes you will need SOA, sometimes you will need services.

Answer 2

The "best" example of SOA would be the BusinessByDesign adventure from SAP. Spent lots of time and resources, even started to sell it before making it work properly and then trying to fix/shutdown it.

I suggest that you do not let these articles scare you away or influence you in any other fashion. Consider you particular situation: does it bring your benefit having services around? If yes, go for it. If not, then the course of action is obvious.

I believe the minds behind SOA basically have an utopic idea - create the world of various numerous services that discover each other and interoperate to automatically provide you somehow with a high level services. But that's something in he direction of AI/science fiction. You can only achieve something close in a very specific scenario which you can program with an algorithmic approach. More than that.... well, not in this century...

Answer 3

SOA is not dead. Like every good idea it becomes part of our landscape. The term eBusiness was a huge idea in the early days and now we don't even use the word anymore. I don't even use the term object oriented anymore it is almost assumed.

The current hype is cloud computing. Put everything in the cloud.

The best practice for SOA is write good services where you need them. Over use of SOA will increase your latency. Use a stored procedure in your database if that is where you need the code to be executed efficiently. You can't beat a good local service if it does the job either.

Answer 4

SOA is a typical example of what happens when a useful pattern (and not even a particularly new one) is sold as the basis for an architecture. As in "A Core Design For Integrating the Enterprise".

Middleware companies are especially susceptible to these kinds of concepts, because they themselves have a challenge trying to tie their products and services together, and they need Big Ideas with potentially Big Budgets.

Doesn't it seem suspicious on the face of it that a single architecture could encompass all the integration needs of all the software in an enterprise?

Answer 5

instead of SOA, why not go for a modular design exposing functionality through interfaces?

it's the same thing, just less objectionable.

Answer 6

If you are going internal enterprise wide apps, it is ok to implement them with SOA. If you are creating a web-facing app (by that, I mean an app that plays well with the new open stack oAuth, OpenID, etc..), then replace SOA with WOA. Stackoverflow.com is an example of such a beast.

Answer 7

I would say that it isn't dead, but it's now fallen into the toolset of the architect as it is now understood where it can help and were it may not.

There is no point using SOA to talk with your database because you want that integration to be tight and performant. But using it at the right spots can allow you to have nice clean interfaces between different parts of your organisations and possibly allow you to upgrade each system irrespective of the other.

But in real life if your payroll system goes down, everyone would be most unhappy, just because your app may be able to limp without one of it's components doesn't mean that it won't affect your system.

It's not possible to create systems that have knowledge only of an interface but not of the underlying system (I'll caveat that statement with: "that work well and are performant"). Take a web browser as an interesting example of this, every good website starts with "what browser are they using and fix my website and take advantage of feature xyz".

Answer 8

Most SOAs were attempting to trivialize a process better served by the less-used subset of SOA known as Event Driven Arcitecture (EDA).

The problem is that SOA was popularized as something constructed from Web Services, which can be a tough choice of underlying technology to implement SOAs with in the first place. SOAP doesn't have to be but typically is used as a tighly-coupled RPC mechanism. This doesn't scale well even in internal systems, let alone anything crossing systems or worse yet enterprises.

You can build an EDA on top of SOAP, but usually you end up with some grab bag of ad-hoc techniques on top of that. Asynchronous operations and Web services goes into some possible hacks.

Even when you have licked the tightly-coupled nature of RPC Web Services though, you have the problem of close-binding and WSDL versioning between cooperating partners.

You can still use XML payloads and schemas, but SOAP itself degenerates to a fairly dumb transport wrapper around that payload "blob" defined entirely outside the WSDL.

StackOverflow is a mostly-isolated Web application. The closest thing to being SOAish might be the OpenId mechanisms it uses. It is simple client-server, not SOA. You're thinking too small.

Answer 9

I know nothing about SOA, but I usually see these kinds of technology go through a cycle:

1. Technology comes out.
2. Technology is so darned good, that everyone recommends it to everyone for everything.
3. People try to use the technology for everything.
4. When people realize that it can't do everything, they get angry and post that it's dead to their blogs.

My guess is that SOA is just another one of those technologies.

Answer 10

As long as enterprises exist, they will have integration needs, systems will always have to talk. SOA seems to be a wise way to address such distributed issues. But unfortunately, it ignores performance concerns. To propose one possible solution, I have published an article on 'Fluid Services' to harness parallelism between clients and servers by using stream-oriented communication as an alternative to message-oriented communication.

This article on SOA Maganizine describes the concept: http://www.soamag.com/I41/0710-2.php This is a more practical article that also includes sample WCF code on CodeProject: 'An Experiment on Fluid Services for Highly Responsive, Scalable and Reusable SOA Services' (Sorry, can't put the link)

Answer 11

SOA is for architectures which are by nature 'distributed'. If you are talking about just interface based programming approach, then you're heading towards 'component based' technology like COM+, CORBA. Or something like .NET Remoting. But if you're talking about contract based development on a distributed environment which evolves over time, and is developed by multiple independent groups, then you're on the SOA paradigm. Those services have to be distributed. But I'm not saying SOA concepts can't be used for local processing. I'm saying, that's where it really targets where no one else does. But again, SOA doesn't care about things like performance which is unfortunate. Because that's where it's failing miserably.