【IT168 专稿】    ZapThink研究机构的Ronald Schmelzer这样描述SOA的四个关键效益：

1. 减少集成费用（包括开发成本与维护成本两方面）
2. 提高资产重用（无需每次都为重复内容做工作）
3. 提高业务敏捷性（业务节奏已经改变，但只有极少数企业跟上了节奏）
4. 减少业务风险（包括可操作性与顺应性两方面）

    接下来，我们将逐一研究并解释以上价值的具体内容。

减少费用和风险

    一位风趣的CTO这样说过：“为了应付管理层削减成本的要求，我身上随时揣着一美元……”

    降低成本是压在每个技术企业头上的难题。因此，每种新形式的产生（比如客户端/服务器、Web/n-tier、SOA等）都会受到成本削减政策的挤压。问题是许多企业急于求成，没有采用递增的方式部署SOA，也无法在过程中学习和吸取经验。实际上，如果部署得当，SOA可以减少开发与维护两方面的成本。松耦合与标准接口可以降低集成成本：由于采用了标准协议、数据格式和接口，企业可以减少甚至避免大量传统的集成费用。并且，SOA松耦合的系统集成特性可以减少编写集成逻辑的时间，以及最终对此的维护时间。由于使用标准的Web服务接口，而不是一大堆由不同供应商提供的、需要不同授权的连接器或适配器，许多企业甚至减少了中间件的维护授权费用。

    另一个使SOA降低成本的原因是，它能减小大规模系统和基础设施变化带来的影响。SOA中各种粒度的不同层次既方便了业务过程与系统用例上的变化，又能减少对底层软件的影响。

    通过定义良好的接口和合适的架构分层减少各组件和系统之间的依赖性，使SOA减少了与新方案部署有关的系统维护和开发成本。图1对此进行了很好的解释。在一个标准的企业环境下，各系统之间的集成点是紧耦合的：

* 供应商、平台和/或特定语言的绑定
* 使用面向应用的数据格式
* 直接使用面向应用的API

图1 紧密集成的企业环境

    图1中的各个系统都是直接与其交互的系统连接。有时候，外部合作人员甚至可以直接越过防火墙访问企业内部系统。在这种特殊情况下，企业资源规划（ERP）系统是企业的关键组件（主要用于生产、设计和以产品为中心的业务）。这是整个供应链所依赖的任务关键系统。如果需要对这样一个系统做大规模的改动，不管是升级到新系统或是仅仅更新到下一重要版本，其影响将波及到整个企业。图2反映出这样的连锁效果：它影响到其它系统，甚至外部合作人员的外部系统。

图2 对紧密集成环境的改动会产生可怕的连锁反应

    SOA怎样解决这一问题呢？如果你还记得SOA栈，那么你就会知道企业被这些抽象层隔离起来，因此这些变化不会涉及到接口之外。通过对这些变化的控制，面向服务的架构便能降低开发与维护成本并减少风险。

提高资产重用

    问题：下列物品有什么共同特征？

* 一次性尿布
* 一次性纸盘
* 空气过滤器
* 应用软件

    答案：这些都不是面向重用的。

    虽然有个别例外，不过实际上，重用确实已经成为信息技术（IT）王国的圣杯一样。项目经理、业务部门，甚至所有企事业单位都为此奋斗了几个世纪，许多人甚至得出结论：认为这只是个不实际的神话。因此，许多面向服务的拥护者将重用的价值作为部署SOA的主要原因并不奇怪。新加入这个行业的人对面向服务的重用感到很兴奋。而在这个行业做过一段时间的人却都知道每一次新技术浪潮都会颂扬重用这个词，并将其作为该独特方法的优点。面向服务也未能免俗。为了验证SOA重用的有效性，我们将从总体上检测软件的重用性开始，然后找出以前策略的缺点，最后确定用SOA实现重用性的真正潜力。

    复制－粘贴式的重用

    很早以前便有重用的尝试。我们尝试重用子程序、函数、对象以及最终组件。每次我们都会遇到一个最基本的难题。从软件开发的角度来说，不管重用的方式有多高明，一旦我们进入产品阶段，就必须将软件按照各系统的功能需要作为局部模块或库来部署。比如，一个团队开发一个数据存取的软件库，另一团队需要同样的功能，因此他们就把该软件库的一个拷贝部署到自己的服务器上。然后，第一个团队将软件升级到下一版本，而第三个项目团队借用该软件库，并根据自己的应用需求作了修改。很快，就会产生三到四个不同的版本，没有唯一的真实版本，运行时也没有办法对公用库进行直接访问。每次有人想“重用”这个软件库，就会有一份拷贝被复制到另一台服务器上，并随之产生新的开发方式。因此，理论上这里是重用，但实际上，这只是被美化的复制－粘贴而已。

图3 传统意义的重用只是被美化的复制－粘贴

    面向服务的重用

    服务的重用稍微有些不同。一个服务被创建并应用在某个位置，如果有另一个应用程序或系统需要使用该服务，那么它只需要按照一定的格式往这个服务地址发送信息即可（见图4）。这样，便不会造成该服务的各种版本在企业中随意扩散。当然，可能仍然会有对于该服务不同版本的需求，但它们会被集中管理，各种额外用途也可以在不失去控制的同时得到更好地支持。

图4 面向服务的重用可以适用于不同的环境

提高敏捷性

    在并不遥远的过去，商业步调比现在要稍微慢一些。你可以给某人留一条消息，他可能要几天后才答复你；部署新产品和方案也需要几个月甚至几年时间，而不是几天或几周。如果公司某一季度的收入不太理想，但因为市场环境比较宽松，因此通常做法是等着看公司本年度其它季度的表现。而现在，你会发现你已经陷入24小时*7天持续运转的商业周期。所有消息必须当天回复，新产品、新服务以周为单位不停地开发，如果早上公司的股票跌到低谷，那么午饭的时候投资人就会来质问CEO的应对。

    客户和市场似乎更欣赏高速、高响应和安全有序的业务实践。在几个星期甚至几个月后才对时机做出反应已让人无法接受。起初，这些还是小公司的优势，但现在甚至连大型公司也需要灵活、及时、迅速地对新时机做出反应。这就是团队敏捷的意义。敏捷代表一个企业能够以多快的速度调整当前的生产力、创建新产品\新服务，或者调整业务过程。面向服务提高了底层业务规则的可视性，并使企业能够迅速地对生产力做出调整。

    通过把整体式的信息系统分解为一系列的服务，企业可以更快、更容易地对业务能力进行调整。比如，某公司开发了供内部人员使用的客户信息档案服务和定单跟踪服务。随着业务发展，为向客户提供更好的服务并减少售后服务中心接到的电话，需要创建一个客户帐户管理入口。正如图5描述的一样，这时就可以使用这些服务来访问客户档案、定单历史，并利用另外几个服务提高技术支持数据库的可视性。

    所有这些服务都可以通过一个Web入口向客户开放。如果没有SOA，所有这一切就得从零做起，或者至少要从其它应用程序中拷贝出来并整合到新应用程序中。而面向服务的方案比任何一种方式都更快、更廉价。SOA就是这样实现敏捷业务的。

图5 以面向服务的方式实现敏捷业务