August 25, 2013

One way to go about SOA

I had to give a presentation at work about SOA. I did a little reading on Command-Query Segregation Responsibility and how to fuse these things together to give someone the scaling they may need. Enterprise software isn’t that bad, right?

Say you have some code, like so:

 class Repository : where T class { public void Insert(T obj); public void Update(T obj); public void Delete(T obj); public ICollection GetAll(Func<bool, T> whereClause); } </pre> 

What command-query segregation responsibility says is to just split up all the queries and commands into separate classes, modules, etc. A query is something that gets back data, so think of a function that returns data like GetAll. A command is something that alter’s state, like inserts, updates and deletes. Now let’s see a separated class:

 class CommandRepository : where T class { public void Insert(T obj); public void Update(T obj); public void Delete(T obj); } class QueryRepository : where T class { public ICollection GetAll(Func<bool, T> whereClause); } </pre> 

What does this have to do with SOA? Well Commands and Queries are 2 separate functions that you can separate out and scale REALLY well. Now, if you listen to some videos, or read post from Udi Dahan, he says to use a message queue, instead of just sql. He says to use both of these together because one scales horizontally well (message queues) and the other does not (Sql database). The benefits of a message queue are as follows:

  1. 1 Reliable – Delivery Guaranteed
  2. 2 Scalable
  3. 3 Resilient – compared to SQL
  4. 4 Decoupling
  5. 5 Interoperable

The downside of all of this is that message queues are not instant. They do not have transactions. If you can deal with these constraints, and most of the time you can. Then look into a message queue. Whoa, Jorden, you kinda went on a tangent, WTF? Ok, here is an example layout with all of this:

  1. UI wants to add stuff
  2. Command inserts into queue
  3. When a service can, then inserts results into database
  4. UI wants to see status of stuff
  5. Query checks database if it is done
  6. If it isn’t done yet, the service that is processing it will let you know.

If all of this still sounds fuzzy, read up more about CQRS and how it fits into SOA pattern. Here is a start, I got a few articles for you guys to check out: Martin Fowler and Greg Young have some good articles about the subjects.