How to Implement Loose Coupling with a SOA Architecture

Question

I've been doing a lot of research lately about SOA and ESB's etc.

I'm working on redesigning some legacy systems at work now and would like to build it with more of a SOA architecture than it currently has. We use these services in about 5 of our websites and one of the biggest problems we have right now with our legacy system is that almost all the time when we make bug fixes or updates we need to re-deploy our 5 websites which can be a quite time consuming process.

My goal is to make the interfaces between services loosely coupled so that changes can be made without having to re-deploy all the dependent services and websites.

I need the ability to extend an already existing service interface without breaking or updating any of its dependencies. Have any of you encountered this problem before? How did you solve it?

Answer 1

What you're asking isn't an easy topic. There are many ways you can go about making your Service Oriented Architecture loosely coupled.

I suggest checking out Thomas Erl's SOA book series. It explains everything pretty clearly and in-depth.

Answer 2

I suggest looking at a different style of services than maybe you've been doing so far. Consider services that collaborate with each other using events, rather than request/response. I've been using this approach for many years with clients in various verticals with a great deal of success. I've written up quite a bit about these topics in the past 4 years. Here's one place where you can get started:

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

Hope that helps.

Answer 3

There are a couple of approaches you can take. Our SOA architecture involves XML messages sent to and from the services. One way we achieve what you describe is by avoiding the use of a data binding library to our XML schema and use a generic XML parser to get just the data nodes you want ignoring those you aren't interested in. This way the service can add additional new nodes to the message without breaking anyone currently using it. We typically only do this when we need just one or two pieces of information from a larger schema structure.

Alternatively, the other (preferred) solution we use is versioning. A version of a service adheres to a particular schema/interface. When the schema changes (e.g the interface is extended or modified), we create a new version of the service. At any time we may have 2 or 3 versions on the go at any one time. In time, we deprecate and then remove older versions, while eventually migrating dependent code onto newer versions. This way those dependent on the service can continue using the existing version of the service while some particular dependency can 'upgrade' to the new version. Which versions of a service are called are defined in a configuration file for the dependent code. Note that it is not only the schema which gets versioned, but all of the underlying implementation code as well.

Hope this helps.

Answer 4

There are a few common pratices to achieve loose coupling for services.

1. Use doc/literal style of web services, think in data (the wire format) instead of RPC, avoid schema-based data binding.

2. Abide strictly by the contract when sending out data, but keep few assumptions processing incoming data, xpath is a good tool for that (loose in, tight out)

3. Use ESB and avoid any directly point to point communication between services.