<<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 talking 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.>> You can read this blog at: <http://www.theserverside.com/tt/blogs/showblog.tss?id=ServiceCoupling&asrc=EM_NLN_483813> Gervas Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
