【IT168 技术文章】

    许多企业在构建SOA，但进展相当缓慢，这主要是由于SOA涉及方方面面，关系太多，太复杂。通过本文可以了解一些公司在部署SOA时实际遇到的问题以及解决方法。

    如果问起负责构建面向服务的架构（Service-Oriented Architecture,SOA）的人什么最困难，他们中很多人会告诉你: 最困难的部分不是技术，而是改动业务流程以及随之而来的角色和职责的重新划分。许多SOA实施者也这样说，而事实可能的确如此。但技术这方面却未必简单， 在所有规划和战略制订完毕后，如何提供及管理服务及消息传送基础架构，还有如何处理已有的平台、应用和系统，并非易事。

    SOA的最终目的是获得极其灵活的基础架构，使IT人员可以在企业里面横跨多种平台和领域的抽象层上开发组合式应用，但谁也无法一蹴而就。在实际应用时，技术人员必须做 出以下关键决策: 在哪些平台上构建服务; 这些服务又将如何被提供、管理。有些公司可能会选择使用企业服务总线（ESB）来连接服务，另一些公司可能为追求重用而选择标准化的服务。现在，有不少公 司在SOA上进行了实践，分析一下这些公司的决策，可以为实际需要构建SOA的人提供宝贵经验。

    构建、提供及监控服务

    选择构建服务所需的平台恐怕是IT人员面临的最简单决策了。大多数组织从头开始编制服务时，只需充分利用开发人员的强项即可，因为面向各大开发平台的 Web服务创建工具已趋于成熟，这些平台包括Java应用服务器、Windows上的.Net和z/OS上的COBOL等。不过，把现有应用的功能作为服 务来提供时，一些公司也使用ESB作为平台，原因是服务可以通过配置而不是编码来提供。

    在完成服务构建及测试之后，开发人员就可以把该 服务发布到服务注册中心（Registry），那样授权者就能发现它，其他服务或者应用也能使用它。如今，大多数注册中心与指向服务元数据的存储库 （Repository）结合在一起——包括管理服务开发的策略，譬如安全设计规则以及运行时管理参数（如服务级别协议或者预期负载）。

    英国电信公司的策略和架构部门主管George Glass说: “一开始我们就认识到，我们需要存储库工具。”但英国电信公司启动SOA项目的时候，市场上其实还没有存储库工具，于是该公司使用Borland设计工具 作为存储库，通过自己重新创建的Web接口把服务提供给业务分析人员。

    哈特福德保险公司的基础服务部门主管Ben Moreland说，哈特福德公司把可用的服务发布到通用描述发现集成协议（UDDI）注册中心，不过是使用Excel电子表格和数据库作为其存储库。作 为整个企业的参考架构项目的一部分，哈特福德公司现在正准备建设比较正规的存储库系统。让Moreland高兴的是，公司当时采取了等一等的策略，因为现 在的注册中心/存储库产品能够有效地处理元数据。

    eBay公司负责系统开发的副总裁James Barrese说: “一旦部署了服务，人们使用服务的速度就会比你想像的快得多。所以基本的基础架构需要落实到位，包括使用者和发布者中央目录、详细记录操作的日志以及仪表板（dashboard）等操作监控技术。”

    有关服务的存储库元数据一般描述应当会出现什么，而不是实际出现了什么。在SOA中，必须实时监控服务的性能、可用性及使用情况——这往往借助于 Actional（最近被Sonic Software收购）、AmberPoint或者Blue Titan（最近被SOA Software收购）等厂商提供的服务管理产品。这些解决方案还支持版本控制、故障替换和消息日志等功能，并提供了集中视图，可以了解网络上服务的总体 运行情况。

    eBay把服务质量（QoS）的参数添加到了服务模板中，其中内置了速率限制和日志功能。正如Barrese所言，这项功能 旨在确保实施起来具有统一性和一致性。比如仪表板服务可以监控日志，以发现性能问题， 负载过大的服务知道性能有问题后，可以请求支持或者通知IT分析人员。

    要不要采用ESB

    服务的监控及提供相对比较简单。最让人困惑的SOA决策是服务如何联系、服务之间应采用哪种仲裁机制。

    在理想情况下，SOA中的每个服务都应符合标准的Web服务规范，健壮可靠，而且可以供需要服务的应用或者XML负载的一系列众多授权的应用或者服务直 接使用。但实际上，企业需要应对使用从MQ到AS2等各种专有协议的遗留系统。而许多人认为，只有WS-Reliable Messaging等Web服务协议完全成形，并得到广泛实施，Web服务的传送才会获得企业所需的可靠性。

    于是，ESB蜂拥而入—— ESB是如今与SOA关系最紧密的一类产品。ESB是一种消息传送总线及服务平台，有了它，连接旧系统、管理及编制服务就会比较简单。与企业应用集成 （EAI）产品一样，ESB也负责转换及发送消息。ESB厂商对自己的产品是否基于标准非常重视，目前大多数使用Java消息服务（JMS）或者某种专有 的消息传送协议，目的是为了提供必要的可靠性。

    支持者喜欢ESB是因为ESB让他们可以配置服务、管理服务之间的联系。经历了好几年没 有ESB的日子后，工资单处理服务市场的巨擘ADP公司最近采用了分布式ESB，因为“很难维护大批一对一的消息传送适配器”，该公司雇主服务部门的 CIO Bob Bongiorno说。这家公司的服务数量从9个增加到了30个以上，但在此过程中，“管理难度绝不是仅仅增加了三倍”。

    Intuit公司集成架构解决方案部门的首席架构师Martin Moseley说，ESB适用于需要编制的长时间运行流程，譬如订单处理。在这种流程中，各步骤必须按某种次序来进行，而且整个过程都要进行验证。譬如， 在计算运费或者批准使用信用卡之前，订单流程可能需要验证顾客的地址（原因是验证信用卡往往需要地址）; 只有完成了所有步骤，才可以发送货物清单。Intuit的订单处理系统就使用这样一种仲裁服务方法。

    但也有人认为ESB只是改头换面的 EAI而已，他们认为ESB有悖于SOA的开放性。伯顿集团的分析师Anne Thomas Manes认可使用ESB配置服务，甚至把细粒度服务编制成可广泛访问的粗粒度服务，但抨击了总线作为传送所有服务的网关这一概念，尤其当ESB消息的来 回传送带来额外开销时，她更是觉得不能接受。