Why I Love SOA: Design Business-Related Services
What happens when a customer asks for a simple new bit of functionality? Do you have to execute changes on four different systems, test each in isolation and in combination, involve a separate testing, infrastructure and operations team? If so, your architecture is probably not service oriented. In this post, I will examine the real meaning of coupling, and how it relates to SOA.
I will, like others taking about SOA, try to define what I mean by SOA in this post. I will do this by talking about what SOA is not. Component Based Design: First: SOA is not the same as Component Based Design. Services in a SOA architecture are distributed. Components in component based design are (usually binary) pieces of code that are packaged with each system they are used in. In this sense, EJBs can, and are, used both as services and components. Component based reuse is often simpler than service based reuse. With service based reuse, the impact of a change in the reused component is much less tractable. There might be systems using my service that I’m not aware of. With components, this may also be the case, but each system has to make a conscious decision to upgrade the component, so any accidental breakage in a system can be related back to a change in that system. Business Oriented: More than being distributed, I think SOA Services are intended to be business oriented. That means that the reason to change a service should almost always be a change in a business requirement for that service. Specifically, if a service has to change because of a new business requirement in another service, I lose. Coupling: This is the real meaning of “coupling”: Two systems are tightly coupled if change to one of the systems is likely to require change to the other system. This is a metric that is hard to measure by looking at the code, yet many believe that code metrics can be used to understand coupling. And this is where non-SOA distribution really hurts: Implicit coupling. If I make two parts of my system remotely distributed, they are deploy-time decoupled. But if I have to upgrade both parts at the same time, this decoupling hurts more than it helps. If I pass data as Strings between two parts, so “we can support any changes to the XML schema in the future”, these parts are compile-time decoupled. But if I have to upgrade both parts at the same time, this decoupling hurts - it doesn’t help. The reason is that the coupling is still there - it’s just implicit. I want to call this approach “Using code metrics to shoot yourself in the foot”. If my service network is well designed, my services will really be loosely coupled: Changes to one service is not likely to impact other services. However, achieving this design goal is hard. And if I do it wrong, it hurts me. In conclusion: If you can identify and extract services that really are loosely coupled, SOA may very well work for you. For parts that are tightly coupled, you can still achieve benefits of reuse, but you are better off doing so through component based design.
Comments:
[Daniel] - Sep 14, 2006
Hi In the text you, like most I think, define services to be distributed. I do not understand why everybody introduce that limitation. You can implement a one JVM system in that uses business oriented “services” (interface programing) that locates the service implementors at run or call time. I do not see a fundamental difference in that architecture and the distributed SOA. Equally I do not think you should consider a architecture as SOA if you have hardcoded the impleremtor of a webservice even if it is business oriented and loosely coupled otherwise…
Perhaps it is sufficent to have a broker between the service requestor and implementor? That is when you truly have decoupled the system, if the implementor and requestor runns in the same JVM or not does not seem that relevant. (in theory :-) )
//Daniel
Johannes Brodwall - Sep 14, 2006
Hi, Daniel
Thank you for you comment. I recommend that you post it again on TheServerSide reprinting of this blog article at http://www.theserverside.com/discussions/thread.tss?thread_id=41836
If you do, I will respond to your reservations.
~Johannes
Chat - Nov 17, 2008
In the text you, like most I think, define services to be distributed. I do not understand why everybody i
jhannes - Nov 17, 2008
Thanks for your comment. I’ve encountered people who talk about non-distributed SOA. I think that is an idea that is totally boring, as it says nothing that hasn’t been said for twenty years. The idea escapes my concerns, but at the cost of being vacuous.