此刻，看着我旁边的书架，有一个区域特别吸引我的目光，一个热门的关于面向服务的架构的书籍的书架。我觉得用这些书几乎就可以无所不能。

　　这不光是书籍。五年来，我都在教SOA，每次咨询都会推荐基于SOA的库存系统、服务总线和EDI对账（reconciliation）应用。

　　现在，看着这些书，它们让我很厌烦，也让我觉得生气。我回头审视基于服务的架构，想到它原本要做什么，为了做到这些花了多少钱，基本上看不到有什么投资回报（ROI）。

　　基于服务的架构本来似乎该给我提供以前没有的所有东西。各种服务应该提供的奇迹是如此之多，很难用一段话就说完：松散耦合（最小的组件间依赖性）；封装逻辑（时序化和最小化）；可复用性（见相同的服务插接到很多应用中！）；无状态性（无状态管理开销）；自治性（服务自行管理自己，与应用程序独立）； 元数据（所有服务将同样的语言），等等。

　　如果你是个开发者，这比大爆炸理论还有趣——但它实际上给我们带来了什么东西呢？

　　我曾经在一个年代里的多数时间都使用基于服务的架构，但只能诚实地说出以下的情况：

• 我从来就没看到我所编写或设计，使其可复用的任何服务有“契约”特性；
• 我从来就没看到某个相同中的服务被重新接入另一个系统；
• 我从来没看到封装逻辑用于多个应用；
• 此时，我觉得我应该可以认为自己被蒙骗了。

　　所以，经过短时的不快，我很快就考虑要将SOA作为一个设计错误而丢弃。这并不是十分困难，因为当今的设计实现方式都可以极其模块化和松耦合，但其本身并不是非得是面向SOA的。

　　回顾这些SOA工作，可喜的效益层并不如SOA信徒所宣称的那么明显。此效益层是如此丰富和巨大，值得人们仔细审视和完全接受。

　　设计了多个SOA系统之后，我真正的结果是这样的：

　　更高级别的编码器

　　需要多优秀的开发者才能实施基于SOA的系统呢？得非常好，SOA要求有非常好的经济性和强健性，很少有其他设计规则要求这些。在某种程度上，要达到SOA设计所要求优良水准的服务，就要求有发散思维的人，也就是同时可看到多个方面的开发者。

　　不再有单一的构件

　　还记得有6000行代码的COBOL程序吗？或许您没那么老。好吧，回想下包括30、40，甚至60个引用的早期.NET程序。还记得维护它们，或者，就先说测试它们，是如何困难吧？是否还记得这些程序是如何容易出错，需要消耗多少个晚上和周末来修复它们？在SOA领域，这些情况不会发生。

　　现在XML是首选的传输中介

　　好吧，不管你对“契约”或“松耦合”的设计概念怎么看—看看XML有多棒？难道它没有使我们的生活变得容易得多？您能立刻就想到好几种使用它的方法，难道它不是总是非常简单和有效吗？
XML是上天的礼物。尽管很多架构师和开发者（包括我自己）有时也对它有些抱怨之词，期望它能顺应我们的意愿，但对于未知数据的传输，它远胜于我们可用的其他方法。这种不可知性是SOA的核心要求，也是迄今为止驱动XML不断推广和IP世界可移植性的巨大推动力。我就是它的信徒之一。

　　开发者默认编写可复用的代码！

　　编写可复用的编码是个艺术。编码必须抽象，必须在功能上尽可能自含，而且其编写方式必须让改变对输出的结果可定量确定。我记得就在不久的从前，开发者要修改代码，然后祈祷不会有事。这种情况出现的频度远远赶不上在SOA工作间中的情况。

　　15年前，让所有人痴迷的被过度宣传的技术是ERP — 有数百家公司购买它，年复一年地付费，最后只是得到琐碎和不完全的结果。SOA很容易被归为它的继承者，但ERP留给我们的除了库房里一堆未使用过的昂贵手册外就没别的。SOA可能也被过度宣传了，但还是有些比ERP好得多的东西：它使我们从爬行类进化到哺乳类，使我们对于未来的世界有更好的适应性。