SOA style architecture in ColdFusion?

Question

The backend of the company's internal system is getting complicated and I would like to explore the idea of doing a SOA style architecture instead of a heavy monolithic system. Where shall I start?

I'm new to SOA. Does it mean... individual CF instances, and they talk to each other through remote web-services calls? How would one deal with things like... error handling and server outage? Would an ESB be beneficial to the architecture if every part of it are in ColdFusion?

How about the DB layer? Should they share one huge DB or should they store things in their own way themselves?

Thank you

Answer 1

First, what are you trying to accomplish? SOA is useful for systems that need to change relatively easily and be accessible to a new programmer. On the other hand you tend to have a performance tradeoff because you end up segregating persistence - so that its interaction happens on the application server rather than in the database. Usually this performance tradeoff is a non-issue, but if you're working on a high through put transactional system you may need to compromise by putting some algorithms in the database and having those violate your services breakdown.

So if you want the pros and are not particularly concerned with the cons, start by reading some applicable books on the topic:

• Martin Fowler's Patterns of Enterprise Application Architecture - in particular pay attention to the Service Layer pattern
• Domain Driven Design Quickly a condensed version of the much (needlessly IMO) longer book of the same name minus "quickly", which help you think about how to define services and the object hierarchy beneath each.

What you want to trend towards is a design with high level service objects whose relationships are managed via dependency injection through a service locator container. In ColdFusion's case ColdSpring is an example. This then allows for object mocking so you can unit test easily. For example, if the services live on other servers, then the have service objects locally that are proxies to be passed in as dependencies. For testing these proxies are mocked so they don't have to talk to the remote server.

Regarding error handling and server outages. I'm assuming you are primarily concerned about dealing with issues outside of the local server's control. This is another reason use a service proxy object. Have this object be responsible for dealing with timeouts, bad response values and the like - effectively an anti corruption layer.

As for database sharing, I would construct my table relationships to reflect my service object relationships. So if the tables in question have data that only relates through services I would not enforce any foreign key constraints. So while they could be in the same database, it doesn't matter. This enables you to move those services and database tables elsewhere with relatively little change to code.

Answer 2

I've heard the term SOA used to describe a lot of different set ups so I am not sure if there is a "right" answer but the core concept is the service layer. The big benefit is that the answer to your last question about the DB layer is - all of the above. Once the logic for handling storage/persistance is isolated in the service layer and the applications just call into this layer, it becomes a lot easier to move certain data to other servers or consolidate them into one when needed. You may even end up with some services just calling others services which is often referred to as a service facade.

For a "real life" example. Suppose you have a customer database of some sorts where you store names, addresses, emails etc. You expose this as a web service where you can get bits of info about a person. At some point you out grow this home brew system and decide to license a full blown CRM system. Because you have isolated all of the customer related transactions in a web service, you only need to update that service to grab info from the CRM software instead of your database. This is really where service architectures really shine.

As far as error handling, if your applications and services are all written in CF, you would have logging and error handling on both (or all) layers. Obviously a server outage on a service server is going to be pretty serious as it will effect everything above it. We use a monitor on that which sends emails to service desk if anything times out or starts to go south. On the client apps the key I have found is setting a reasonable timeout for web service calls. I've never seen an ESB used but I am guessing it would give you another layer of abstraction to manage the actual calls. This may help with timeouts and the like but I can't really say.