| 许多企业在构建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消息的来
回传送带来额外开销时，她更是觉得不能接受。
性能、安全和运行时治理
要不要使用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时理清架构和业务流程，然后搞清楚实施需求、可接受的折衷方案、可能会有的数据流和流程以及管理和性能需求。弄清楚了这几个方面，你就可以使用自己喜欢的任何技术来构建实际的服务和支持性基础架构。
一切围绕架构
一碰到实际工作，人们很容易陷入战术性决策，譬如要不要购买ESB、向谁购买。但SOA的要点在于创建这种架构:
支持目标非常明确、简化了的业务流程，通过重新安排传统的项目为流程的更改提供灵活性。
系统集成商Infosys的副总裁Sohrab Kakalia说: “人们对SOA存在相当严重的误解，而实际上不从整体上考虑IT和业务，谁也无法取得成功。”
架构描述了提供业务流程的服务的标准层面，包括治理和策略、流程管理、业务逻辑本身、数据管理及访问、内部定义、便于服务联系的服务接口以及消息传送框架——通常就按这顺序加以处理。
英国电信公司已开发了14个服务平台。该公司的Glass说: “每个平台都有一套与业务操作相关的服务——就像是面向对象编程里面的方法。服务只位于一个平台里面。”公司为每个平台派一名架构师来负责，他确保所有服
务都符合这个架构，无论服务是内部开发的、合作伙伴提供的还是向厂商购买的。为了确保始终符合，他们规定，如果英国电信的某个项目没有符合架构，开发小组
的年度资金就会减少四分之一。
为了确保业务的灵活性和流程得到始终如一的执行，“架构应该不依赖任何实施的技术，新出现的技术可以部署，但架构本身具有可持续性，这就确保了SOA策略的一致性”，
Glass说。
SOA高度关注底层的业务流程，反对依赖技术，因为这会限制公司以后更改或者添加业务流程的灵活性。除了架构方面的战略性决策外，成功部署的SOA还依赖IT人员经常确认项目有哪些机会可以重复使用服务或者业务流程。
“这不是一蹴而就的工作。”Intuit公司的Moseley说，谁以为使用SOAP或者WSDL这些技术来提供一种功能或者集成应用就是在部署SOA，那可是大错特错。技术是实现目的的一段手段，而不是目的本身。 |