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.