SOA和Web Service分道扬镳

　　可能在市场上围绕着面向对象的架构(service-oriented architecture，SOA)误解最深的是SOA和Web Service是同一个概念。这个误解传播的很广，影响了架构师和开发人员、咨询师和厂商等。但是尽管ZapThink不断的在日常的事务上澄清很多问题，这种误解还是存在于一些匆匆检查中无法轻易辨别的细微之处。结果，仅仅站起来喊一下“SOA是组织IT资源更好的满足业务不断变化的需求的一种方法!”“Web Service是基于标准的、协议化的软件功能和数据的接口!”是远远不够的。毕竟，如果仅仅是关于不同术语的各自定义的问题，那么这种误解早就消失了。所以，为什么这么基础的误解至今还困扰着我们?我们该做些什么来解决这个问题并最终取得进步呢?对这两个相关、但是各自不同的概念的历史进行简要回顾将有助于澄清这个差异。

　　最初SOA和Web Service是捆绑在一起的

　　表明SOA和Web Service是不同的概念的第一个证据是SOA在Web Service出现之前早已存在。早在1990年，像公用对象请求代管者体系结构(Common Object Request Broker Architecture，简写为CORBA)和微软的分布式组件模型(Distributed Component Object Model，缩写为DCOM)的分布式计算方法都是以一种协议的方法抽象软件功能的架构方法，能够提供一定程度的松耦合性，提供比使用其他方法的紧耦合性接口的架构更大的灵活性——换句话说，它们是面向服务的。虽然CORBA和DCOM都在市场上获得了一定的成功，但是DCOM明显就是一家厂商的架构，而COBRA虽然表面上是厂商独立的，但是在实施中还是和厂商有关，因为CORBA不同的厂商的实现被证明是互相不兼容的。

　　这个故事还算不上有趣，直到1990年代的后期，当时一些厂商达成了两点基本的共识：第一，SOA的方法不会提供真正的灵活性，除非它是与实现独立的，第二，相对较新的可扩展标记语言(eXtensible Markup Language，XML)会成为理想的消息协议，即使它的最初的目的是作为文档标记语言。这些观点导致了多家厂商的标准的努力并最终确立了为Web Service提供基础的规范的核心：Web Service描述语言(Web Services Description Language，WSDL)，统一描述、发现和集成协议(Universal Description, Discovery, and Integration，UDDI)和简单对象访问协议(Simple Object Access Protocol，SOAP)( 现在已经不是这个的缩写了, 因为访问对象已经没有意义)。

　　SOA由三个标准支持的“发现-绑定-发布”三角的早期工作主要集中在商业对商业(business-to-business，简称B2B)的应用上，同时还有全球的“green pages”目录，它允许对整个Internet上商业Web Service的自动发现和绑定。问题是，没有人愿意按照这样的方式来做业务。实际上从黄页上选择一个水管工都十分冒险，所以还有谁会自动化流程，在系统之间增加任意的交互?结果，作为.com繁荣期末尾的“Web 1.0”B2B电子商场趋势的失败的一小部分，这个早期的SOA的B2B计划失败了。

　　Web Service唱主角

　　虽然疯狂的.com的终结和随之而来的IT的衰退打击了很多标准的制订工作，但是我们将2002-2003期间称为Web Service的黄金时代。厂商们意识到在艰难时期唯一有希望产生业务的故事就是节约成本的方案，并且Web Service有一个伟大的特点：降低集成的成本。从私有的接口转到基于标准的接口，想想你可以节约多少钱!虽然那些日子里标准还远不是成熟，但是至少商业案例对于投资者而言已经足够美妙了，这些投资者都在泡沫破灭的回忆中战战兢兢并且寻找新的机会。就这样，Web Service的市场诞生了。

　　当然，凭借着早期对于Web Service技术和趋势、XML&Web Service安全、面向服务的管理和测试Web Service等报道，ZapThink又一次领导了Web Service的潮流。并且，早在2002年二月当我们在《XMLand Web ServicesUnleashed》书中讨论架构的时候，我们建议那时的厂商不要谈到SOA，因为市场还没有准备好SOA所代表的更加复杂、以商业为中心的逻辑。相反，这些报道以Web Service架构为中心，该架构是基于标准的集成方法。

　　并且，回顾2002年的时候，我们意识到在那一年6月的面向服务的集成报告中有一个在今天来看都是预言性的一个基本的真理：虽然Web Service单独就可以降低集成的成本，只有转移到SOA方能降低组织机构的业务变化的长期成本。换句话说，Web Service让你获得了去舞会的入场卷，但是你还要学会跳舞。

　　Web Service黄金时代的结束

　　随着SOA的讨论开始增加，Web Service则进入了挑战的青春期。支持WSDL、UDDI和SOAP并不能保证互操作，并且也不足以标准化随机的系统对系统之间的交互的复杂性。这些限制导致了两方面的努力：Web Service互操作组织(Web Services Interoperability Organization，缩写WS-I)，它致力于提供标准的互操作，和其他各种后续的标准，其中很多都被用术语WS-*来概括(发“WS star”的音，*在老的Unix中表示“一切”)。这些努力，当然，会花费时间，并且随着各种标准的正文都是由各种厂商用自己的计划来填充的，整个情况就开始变的复杂的、政治的泥潭，而这些并没有给试图降低集成成本的组织结构提供些许的真正的互操作。结果，Web Service并没有达到原有的期望，而现在也越来越成为SOA故事的边缘部分了。

　　事实上，当许多IT产品厂商看到SOA井中的黄金之后，Web Service的花车慢慢的没落了。这些厂商开始拍着他们产品上的Web Service接口，叫嚷着这是面向服务的，这种方法无异于给小猪画上口红。事实上，对应用或者数据库的Web Service接口，或者是在私有消息中间件上的Web Service适配器，都不算SOA的。

　　同时，在我们的SOA工具和最佳实践以及面向服务的流程报道中，ZapThink指出以商业流程为中心的SOA是企业架构，并且在2004年，我们开始建议厂商的广告要集中在SOA上而不是Web Service。我们为如今的企业所绘制的图景要比直接采取Web Service更加具有挑战性，因为SOA包括对业务如何从很多不同的方面来利用IT的重新思考。Web Service仍然是故事中的一部分，但是如今很清楚的是Web Service不是SOA的核心，并且更进一步，SOA并不需要Web Service。

　　ZapThink的行动

　　因此，2007年的故事是将Web Service从SOA中分离。我们在SOA环境中所谈到的服务要比开发人员用来支持组织机构的互操作要求的某个接口标准具有更高的抽象级别。很多这样的服务是Web Service，但是很多并不是。此外，很多Web Service的应用发生在SOA的环境之外。事实上，很多这样的应用是B2B，重新回到了Web Service最开始的景象(虽然很感激，没有了green pages)。并且，大部分这样的B2B Web Service仅仅是基于标准的应用编程接口(API)，缺乏提供松耦合、位置无关和业务敏捷性的架构。此外，有很多的组织机构想尝试实施SOA，但是仅仅是实施了Web Service，造成了和架构毫无关系的冗余的、不兼容的、常常是无法管理的服务。

　　回顾SOA和Web Service的历史，展示了一段非常有趣的迂回曲折的婚姻，由于Web Service在将SOA引到台前中发挥了关键的作用，即使SOA现在已经超出了Web Service可以提供的范畴。并且，我们的任务还没有完成，因为围绕着Web Service和SOA还有太多的误解需要澄清。可能最大的挑战就是建立一种观点，SOA是关于业务流程的，而不是集成的。只要厂商还在利用他们的软件对SOA的成功非常关键这样的错误观念来销售集成软件，这种挑战就存在。