性能、安全和运行时治理

    要不要使用ESB取决于每家组织的独特需求和情况。譬如说，如果分布式服务的编制必不可少，而这些服务没有接入到异步消息传送基础架构，编制起来难度就会相当大。

    不过单单有了ESB并不等于就有了SOA。在实施的各种规模的SOA中，一般不会只有一种。可能需要连接多条消息总线，而且消息在这些总线上传送过程中还需要转换。

    思科、Forum Systems、IBM DataPower、Layer 7和Reactivity等厂商提供的新一代XML设备非常胜任这项工作，这类设备主要用于保护、管理及提升SOA的性能。这些厂商销售的设备可以根据内 容来转发XML消息，并使用专门为此设计的处理器高速完成XML转换、转发及映射等工作。

    这些设备大多集成了一系列功能，其中许多功能与ESB的功能相重叠。它们尤其善于对服务进行虚拟化处理，这样一旦需要提升性能时，就可以动态创建服务，而且可以在运行时使用集中管理软件，执行针对服务制订的策略。大多数设备还包括了一系列XML安全功能。

    实际上，上述这些厂商销售的首批设备是XML防火墙，用来阻挡基于XML的威胁和拒绝服务攻击。如今，XML安全设备支持加密/解密、验证、身份管理、XML模式验证及更多功能，既可以控制应用访问，又能保护网络边界。

    随着SOA日趋成熟，安全服务必不可少。ADP公司就是这种情况，该公司现正致力于部署标准安全模型，作为供其他所有服务使用的集中流程。同样，技术服 务提供商USi也在使用联合身份管理验证用户身份。高级技术部门的副总裁Mike Rulf说: “服务可能甚至不知道用户是谁，但知道该用户已在服务传送过程中的某个阶段通过了验证，因为服务传送了这些验证信息。”

    AMR研究公司 的高级分析师Dennis Gaughan提醒道: “SOA中的安全没有得到足够的注意。”早期项目往往侧重于定义服务和传送接口，或者侧重于把业务逻辑与数据逻辑彼此分开来，并且把它们与执行及显示分开 来。但随着服务得到广泛使用及采用，重新改动服务以适应访问控制和授权机制就变得困难重重——这往往需要大范围改动，因为安全控制会改变流程和数据流。

    USi公司的Rulf说，这就是为什么一开始考虑到安全性比较明智的原因，哪怕你的安全服务和系统还没有得到部署。在USi，所有服务都有一个标准的 Web服务描述语言（WSDL）模板，模板包括了安全验证和访问控制，还包括错误报告、调用行为及数据预期等，确保一开始服务就有安全性。

    使用LDAP将是身份管理项目的关键，Turato计划让所有服务都包括调用LDAP查询的机制。为了防止每个服务在每次运行时进行直接查询，Avis Budget现计划在业务流程的特定阶段进行查询，然后把该验证信息传送给以后的服务。

    这种方法存在的风险是，有人只要一路传送“通过验证的”属性，就可以骗过验证机制，所以Turato准备把验证属性变成签名，签名可以跟踪验证在何处进行、何时进行，目的是为了确保在合适流程的合适阶段进行了验证。

    测试及调试服务

    部署SOA时常不被重视的另一个工作就是测试及调试。ADP公司的Bongiorno说: “从许多方面来看，实施得当的SOA有助于你更快进入市场，但测试方面需要一些时间。”

    虽然使用严格定义的服务接口有助于缓解服务集成测试工作，但服务之间多对多联系的性质以及配置服务的众多软硬件系统给测试带来了难度。eBay的 Barrese说: “你总不至于把整个企业变成质量保证实验室，”所以你得尽量扩大测试平台，但又不能影响企业业务的正常运作。

    eBay自行开发了部分质量保证工具用于自动递归测试，帮助测试SOA固有的许多执行场景。同时也使用现成工具，譬如Mercury Interactive开发的工具（ADP公司也使用Mercury的自动递归测试工具）。另外，eBay正在评估采用开放源代码的Apache Axis服务测试工具与其BEA和IBM平台的兼容性。

    一个与此有关的难题是版本控制。随着服务越来越大，常常需要支持多个版本，因为你没法同时更新所有服务。注册中心或者存储库可以维护版本信息，作为那些服务的标准属性的一部分。这种保护措施很重要，因为这样其他服务就可以相应调整期望。

    当然，再全面的测试也不可能发现每个错误，比如，很可能会在监控过程发现事务错误。但要在运行时确认服务本身的逻辑错误，调用服务必须查看返回的消息，才能根据业务流程的规范，知道格式、策略或者其他预期属性是否出现不一致。

    立足于自己掌握的技术

    选择哪一种开发平台、注册中心/存储库、管理模式、消息传送系统、安全技术以及测试工具，这会让人晕头转向。人们很容易陷入战术性决策，譬如要不要购买ESB、向谁购买。但你应当在确定了业务流程、核心服务和整体架构之后，再去选择方案。

    咨询公司TekFinancial Solutions的总裁Bill Adiletta说: “讨论一大堆技术只会让人分散精力。”别试图评估所有可能的技术，而是要看看已有的技术，摈弃无法满足你需求的任何技术。如果公司内部的技术无法胜任，不 妨把目光转向外面的厂商。他说，在剩下来的合适技术当中，选择最符合现有技术基础和技能组合的那些技术，尽可能避免专有技术。

    Hurwitz说: “如果你对SAP产品坚信不疑，那么SAP的新平台NetWeaver可能值得一用。不然，需要认真分析一下你的应用，然后把它们作为服务来提供。”你先 要分析组件部分，然后决定需要什么。一旦服务清晰起来，你就可以关注像服务总线和业务流程引擎这些技术，以便根据需要来管理服务。

    譬如 说，通用汽车公司在2001年的第一批Web服务项目使用了J2EE平台，那是把公司的14个汽车品牌合并起来的一项网上购车服务。通用汽车新兴技术部门 的首席架构师张洪说他喜欢这一点: J2EE另外有一层可以供数据访问，这样就便于处理许多数据源，又不会围绕数据源形成相互依赖的业务流程。

    就宏观而言，选择特定的平台和技术只是战术性决策，而不是战略性决策。毕竟在SOA中，流程、数据流、数据定义、服务接口和策略等应当加以抽象，以便它 们不依赖特定的技术。伯顿集团的分析师Manes称这一难题是“面向企业的规划、针对本地的实施，SOA并不是中间件”。

    最重要的是设计好SOA时理清架构和业务流程，然后搞清楚实施需求、可接受的折衷方案、可能会有的数据流和流程以及管理和性能需求。弄清楚了这几个方面，你就可以使用自己喜欢的任何技术来构建实际的服务和支持性基础架构。