SOA != Web 服务

许多人将 Web 服务和 SOA 划上等号，并把它认为是实现 SOA 的唯一选择。对此，Jason Bloomberg 并不同意。最近，他发表了关于“拆散 SOA 和 Web 服务的联姻”的意见。

认为 SOA 和 Web 服务是一码事，可能是市场中围绕面向服务架构（SOA）最令人恼怒的误解。不幸的是，这个混乱的观点非常流行，它对架构师和开发者都造成了影响，咨询师和厂商也不例外。

Jason 并不是第一位说 SOA 不等于 Web 服务的人——决对不是，在他之前就已有很多人这样说过。如，看看 2006 年 InfoQ 的就企业 SOA 对 John Crupi 所做的采访，或我们的就 SOA 对 Frank Leymann 所做的专访，专访中他说到：

FL：我们必须清楚地区分 SOA 和 Web 服务规范——有时，两者被混为一谈：SOA 是架构，而 Web 服务规范则定义了一个支持 SOA 的互操作平台。

SOA 不是全新的。在实际中，SOA 的一些个别方面已被使用很长时间了。如，拿“松耦合”来说：多年前，企业就使用可靠消息传递技术来集成应用，即，使它们之间解耦。请不要误解我，在 SOA 中也有新概念，如组合装配在 SOA 中的概念而产生的那些新概念，也就是说，它们是逐渐产生的。

Web 服务规范使相应的技术能够有效的跨平台。也就是说，相应的规范基本上不会发明新的概念，而是定义这些概念及它们相应的实现如何在异构环境中工作。结果是互操作性破茧而出，SOA 成为现实。

关于 Web 服务与 SOA 既不是一回事也不相同的事实已不是什么新闻了。有趣的是，Jason 试图让我们看得深入一些。一个原因似乎是分析公司自己——正如 Jason 所指出的：

当然，凭借早期关于 Web 服务技术和趋势、 XML & Web 服务安全、面向服务管理，以及测试Web 服务的报告，ZapThink 在Web 服务领域乘风破浪。可是，尽管早在2002 年2 月我们 XML 和 Web 服务揭秘 一书中就已讨论了架构，但当时我们建议厂商不要谈论 SOA，因为市场尚未为 SOA 所代表的更复杂的、以业务为中心的主题做好准备。相反，鼓噪之声集中于 Web 服务架构，它基本上是基于标准的集成方法。

自然地，Jason 也说 ZapThink 恢复得太早了：

可是，回顾 2002 年，在那年 6 月我们书写面向服务集成报告的时，我们意识到一个在今天看来都是预言性的基本事实：尽管单独使用 Web 服务可以降低集成的成本，但只有转向 SOA 才能让组织降低业务变更的长期成本。换句话说，Web 服务给了你一张舞会的门票，但你仍需学习跳舞。

按照 Jason 的说法，其他的罪魁祸首是技术厂商自己：

事实上，在众多 IT 产品厂商看到了 SOA 井中的金子时，Web 服务的花车就开始没落了。这些产商开始拍着它们产品上的 Web 服务接口，声称它们是面向服务的，这种做法就象给猪抹口红一样，没什么价值。事实上，对应用或数据库的 Web 服务接口，甚至是专有消息中间件之上的 Web 服务适配器，都不是 SOA。

Jason 认为，现在是更好地分离这些概念，并让 SOA 在更高抽象级别演化的时候了。但不是所有人都同意 Web 服务应该从 SOA 中分离。如， Frank Cohen 认同它们是不同的术语，但也认为它们关系紧密：

SOA 和 Web 服务是非常有用的愿景，它帮助我们从当前的 XML、平台、应用和服务（我称之为 XPAD 运算）走向未来。多年来，IT 一直想要获得这种互操作性、重用和治理，包括在这方面所做的努力，如 CORBA、OpenDoc、DCE、Client/Server、Web 1、Web 2.0 和企业 Web 2.0。所有那些努力都能提供一个组件架构，在其中软件可被重用加速企业获得市场先机，接着为企业提供更好的消费者意见。

SOA 保留了 WS 组件的思想，关注用于业务工作流的组合应用，并为了静态代理端点，编排治理、业务问题、排错和质量服务（QOS）而丢弃了发现服务的思想。

对我来说，有时企业架构师和技术经理误解 SOA 和 Web 服务的一些术语，没什么大不了的。

你的想法是什么？使用 SOA 来标识 Web 服务是个问题吗（反之亦然）？

查看英文原文： SOA != Web Services