Trond-Eirik is rambling on about stuff

General stuff about system architecture and development

Thursday, November 27, 2008

SOA does not belong in a system architecture

It seems as the words of the SOA hype is starting to fade off, and people is getting more realistic expectations to what SOA actually is and what it can do for them.

From my point of view there seems as if a good number of architects have done a number of pretty bad design choices involving SOA. Often SOA is understood as something that should be used within a single system as a mechanism to separate the different layers of the system.

SOA = Service Oriented Architecture.

That doesn’t sound too bad, does it? Orienting our architecture around services? How can that be bad?

Actually, it might be that bad. The problem might as well be how people understand the realization of a service. Many consider the following statement as true:

A Service in SOA is the same as a WebService.

The other definition that is a bit less extreme is to look at a service as a contract and layer boundary.

Anyway, the practical result of this is that what goes in or out of a service is data. By data I mean dumb data. It might be formed as a Xml document, as string, as classes or other structural information. The point is that it is data structures that do not contain any business logic. Actually, that’s one of the main purposes of SOA: To separate the logic from the data as well as separate the technology dependency from the data, enabling different system to communicate between them.

So, on one side we have a method that is able to transfer dumb data and that is suited to communicate between systems built on different technology and different times.
On the other side we have architects trying to use this as a communication pattern between different layer of systems using the same technology, written at the same time and running in the same environment.

Why is this bad? This is bad because at the second you introduce a service (especially if it is realized as a web service) in a system you end up with a flow of logic and data that goes like the following:
- Service read data from datastorage
- Service internally structures data in a good way, probably in a model
- Service internally verifies data structures
- Service converts data to a suited dumb external format
- Service passes data on to the client
- Client receives dumb data
- Client internally structures data in a good way, probably in a model
- Client internally verifies data structures
- Client changes some data
- Client verifies business logic (some of it)
- Client structures data in the format wanted by the Service
- Client sends data to the Service
- Service internally structures data in a good way, probably in a model
- Service internally verifies data structures
- Service internally verifies business rules and logic
- Service saves data to data storage

This seems bad. And it is! It’s actually awful. The added cost of this type of logic is extreme. The cost is both in pure code realization time, bug tracking, runtime speed and the agility and ability for the system to change.

However, in some cases this is actually needed. But that is when you want to have interaction between systems that is very de-coupled and not actually related. It might for example be that you are communicating with a system in a different company. That company must be able to change it’s internal code without affect other companies. It might also, in some cases, be a suited way of communicating between systems in a large company.
But it IS NOT for communication within a single system, not even if that system is big. If you want to archive separation in your system, use other patterns.

SOA is a good idea, but it has to be used at the right places, and IMO that is not within a system architecture.

Labels: