When to use SOA (Service Oriented Architecture) [closed]

Question

I had a conversation with one of our architects recently and he summarized his use of SOA as "The only time we'll use services is when we need async actions otherwise we'll use go direct to the data store"

I thought about this statement and it seems fairly logical as services work well in a publish subscribe model, but I was wondering in what other scenarios you should be looking to use SOA?

Answer 1

We expose services to our customers because they shouldn't be able to connect to the datasource directly.

We expose services to ourselves because it's easier to spread them over different technologies using WCF.

We expose services because we have different user interfaces for the same datasource. And when we use services we save a third of the work.

It is never only because of the async actions.

Answer 2

Another case to use services is when you want to integrate a heterogeneous technology stack.

In other words, if your DB is postgres, but you have code in Java, Perl, Python, and C++, you can write stored procedures and have each programming language call those. If you are working with a DB that doesn't have stored procs, or you want to have the capability of switch those out - or you just want to run over port 80, you could wrap the SQL calls in a service-oriented layer (think websphere) that can now be called by anyone - plus you can put the authentication and authorization logic (connect to LDAP, whatever) in the SOA layer.

You can also use that SOA layer to, say build up a logical routine to do "stuff" with that old COBOL box in the corner that manages invoices or creates statements for customers.

So if you've got a number of legacy systems you want to interconnect - say the sales system to the warehousing system to the order predicting systems - SOA might be one way to achieve that goal. (You can also use a "service bus" to create an event driven system as a better way of orchestrating change.)

Just me talkin'.