当客户要求一点简单的新功能时，会发生什么呢？你必须要在四个不同的系统上执行变更吗？一定要分别在独立和组合的环境中测试吗？并且一定要牵涉到各自的测试、架构和操作团队吗？

　　如果这样，你的架构可能不是面向服务的。在这篇文章中，我会调查一下耦合的真正意义，以及它跟SOA是如何关联的。

　　和其他讨论SOA的人一样，我会尽力在这篇文章中定义我对SOA的理解。我要通过讨论什么不是SOA来实现。

　　基于设计的组件：首先：SOA和基于设计的组件不一样。在一个SOA架构中的服务是分布式的。而基于设计的组件中的这些组件是代码片段，通过他们所处每个系统来打包这些片段。从这种意义上来讲，EJB能够作为服务和组件。

　　基于重用的组件通常比基于重用的服务简单。在服务重用时，在重用组件中变更带来的影响更是难以控制。其中可能有使用我的服务以及我没有关注的系统。在组件中，也许也是这种情况，但每个系统不得不有意识的做决定来升级组件，所以在一个系统中任何意外的破坏都与系统中那个早期的变更有关系。

　　面向业务：我认为SOA服务是打算成为面向业务的，这就不仅仅是分布式。这意味着改变一个服务的原因，几乎应该全是为那个服务中业务需求而作的变更。特别是，如果一个服务是由于另一个服务中的一个新业务需求不得不改变，那我就错了。

　　耦合：这是“耦合”的真正意义。如果一个系统的改变很可能需要另一个系统的改变，那这两个系统是紧耦合的。这是一个很难通过观察代码来衡量的标准，然而很多人相信可以用代码的度量来理解耦合。

　　这是非SOA分布式真正让人痛苦的地方：隐式的耦合。如果我让我系统的两个部分远程地分布，它们是部署时解耦。但如果我同时升级这两部分，这个解耦的伤害远比它带来的帮助。如果在这两个部分间把数据作为字符串传递，那么“我们未来能支持任何XML schema”，这些部分是编译时解耦的。但如果我不得不同时升级这两个部分，这个解耦就会带来麻烦——没有任何帮助。原因是耦合仍然不变----这只是隐示的。我想把这种方式称为“使用代码度量来搬起石头砸自己的脚” 。

　　如果我的服务网络设计良好，我的服务将真正的松耦合：一个服务的改变不太可能影响其他的服务。然而，实现这个设计目标很困难。如果我做错了，它会让我陷入困境。

　　结论：如果你确定并提取出真正松耦合的服务，SOA可能会很好的为你工作。对于紧耦合的部分来说，你仍可以实现重用的好处，但你最好不要通过基于设计的组件来完成。

　　关于作者

　　Johannes Brodwall从他记事开始，已经和计算机打了很久的交道，在他六岁的时候他曾痴迷与针式矩阵打印机。从1998年，他的工作一直是一个程序员和软件架构师。Johannes目前在BBS领导java架构，这家公司经营挪威银行的架构。在BBS，他帮助选择Java技术和在这些技术中培训Java开发人员。在他闲暇的时间里，Johannes喜欢学习像Ruby和现代标准阿拉伯文这类深奥的语言。他和他的妻子Sarah和斗牛犬Ada Mae住在挪威的奥斯陆。