一家公司把业务流程和应用功能分解成服务的能力，将决定它能够获得什么样的灵活性和可重用性，最终决定SOA项目的成功程度。

　　丹麦银行（Danske Bank AS）在构建SOA方面的开创性工作已到了非常深入的阶段，现在，它的大型机和应用服务器发布出来的服务有1000多项。但这家总部设在哥本哈根的银行却发现自己落入了让人沮丧的困境。这家银行的首席架构师Claus Torp说: “服务太多了，我们找不到它们。”

　　这个问题有可能让SOA的主要优点之一 重用化为泡影。不得已，丹麦银行开始着手改动服务的概念，改进服务中心库，并制订了执行最佳实践的管理流程。结果把服务数量精简至140项，这大大提高了可管理性。

　　如果你深入分析SOA方面的几个开创者，就会发现丹麦银行所采取的措施是公司能够重复使用代码、提高开发应用的速度和效率、并且最终节省资金的关键所在。但这并非易事，同是，实施的先后顺序也很重要。如，Sun公司曾构建了注册中心（registry），还成立了一个架构审查委员会。但IT部门只是现在才回过头去，对Sun的80到100项Web服务进行比较认真的审查及分析。

　　Sun的IT主管Karen Casella建议，开始踏上SOA之路的公司应当首先分析业务需求，然后确认需要哪些Web服务。她说: “我们吃过苦头才明白了这个道理。我们还没有完全弄清楚实施SOA需要什么，就建立了一部分基础设施。”

　　定义服务是关键

　　公司要弄清楚哪些业务流程可以转化成服务、认真设计及定义服务，并且学会区别服务和组件。

　　丹麦银行开始构建标准接口以发布遗留程序时，它把服务定义为“一项功能”。如今它在较高的层面来描述服务: 即从逻辑上分组的功能和数据，譬如“顾客”或者“账户”。该银行的140项服务每一个都由大约10个“操作”或者组件组成，这些实际上就是粒度更细的服务。目前共有超过1365个操作。丹麦银行估计最终会有250项服务。

　　Torp说，一家公司把业务流程和应用功能分解成服务的能力将决定它能够获得什么样的灵活性和可重用性。

　　丹麦银行利用建模工具来设计功能模块和业务流程的逻辑图（Logical Map）。然后，它把业务流程与服务进行匹配，确保自己解决了所要解决的问题。

　　Torp说: “大量正向服务的开发工作就是为了确保，你可以在同样的服务基本模块上运行不同的业务流程。如果你想取得良好效果，就要确保同样的功能只有一个地方在实现。”

　　首席技术官Robert Wiseman说，Cendant公司的旅行分销服务部门为了确定服务和服务组件的最佳粒度花了相当长的时间。最终确定服务是可以借助名称为Rosetta Stone的业务领域模型（business domain model）供外部调用的构件，而服务组件如日志功能只是在内部调用。

　　所以“预订酒店”这项服务可能会调用几个低层服务，譬如该公司为顾客提供的经度/纬度“目的地查找器”。但Cendant的货币兑换器却是个组件，因为目前它并不提供给顾客使用。

　　Wiseman说，Cendant期望正在开展的一个项目能够从整体应用抽取组件以获得巨大回报。比如，旅客姓名记录（PNR）是一个基本的数据单元，供预订引擎和全球分销系统（如Cendant的Galileo）使用。通过把“Super PNR”作为一项服务来提供，IT部门就没有必要维护在不同应用里面的六七个PNR。哈特福德金融服务集团公司在过去三年里构建了一批Web服务及其他服务，但直到一年半前才开始在整个企业开展SOA方面的工作。

　　这家总部设在康涅狄格州的保险公司负责应用基础设施交付的经理Benjamin Moreland说，非常适合成为企业服务的是两个或者更多个应用需要的功能。“但不是每项功能都应当成为服务，”Moreland警告。他特别指出，发布服务可能会给性能带来影响。

　　建立注册中心

　　厂商们也许期望基于通用标准发现集成协议（UDDI）标准的因特网注册中心能够迅速流行起来。但SOA的早期采用者更关心的却是内部注册中心。

　　不过，这并不是说UDDI因此没有。UDDI对哈特福德公司来说实在太重要了，结果它选择的注册中心就是基于符合UDDI 3.0的产品（工作人员不愿透露产品名称，这是由于公司政策规定不得为厂商做宣传）。注册中心里面包含描述服务的元数据以及通过特定传输协议与服务相连的机制。

　　但UDDI注册中心并不适合每家公司。哈特福德各个部门继续为各自创建的一些服务维护本地注册中心，原因是哈特福德对哪些服务进入企业注册中心有所选择。

　　Moreland说: “我们不想什么服务都放在里面。我们觉得，放在企业UDDI里面的应当是能为我们在整个企业带来优势和灵活性的服务。”
　　
　　普罗维登斯医疗系统（Providence Health System）使用Infravio公司的管理框架管理其服务中心库。

　　让该公司原先持怀疑态度的人士大跌眼镜的是，开发人员居然可以重复使用服务，原因是他们能够找到定义接口的Web服务描述语言（WSDL）文件。普罗维登斯医疗系统的研究开发主管Michael Reagin说: “我们通常把这称之为‘像Google那样搜索’Web服务。如果要稍加改动，他们在几小时内就可以完成，然后就可以重复使用服务。这样，员工的工作效率提高了。大家都很高兴。”如今，普罗维登斯医疗系统比较关注的问题是，如何从业务角度来管理其越来越多的Web服务及SOA框架。该公司有近50项组合式服务，每一项都由1到20项粒度更细的子服务组成。

　　找不到适合自身需要的注册中心的早期采用者只好自行构建。丹麦银行为来自其大型机及基于J2EE和微软.Net的应用服务器的诸多组件维护不同中心库。

　　IO Peter Schleidt说，这些中心库能够彼此复制服务，从而形成单一的逻辑中心库——这实际上是UDDI注册中心的超集，并增加了负载均衡等功能的业务操作参数。服务集成商的工作人员可以通过HTTP或者更有效的专有协议使用简单对象访问协议（SOAP），动态地选择最有效的方式来调用服务。

　　丹麦银行还为其服务及相应接口提供了一个结构化中心库。该中心库还存放了有关其功能模型和流程模型之间相互关系的信息。甚至还设有中心库管理人员，那样开发人员可以随时向他求助。但直到一年前才开始使用中心库，“这比我们预定的要晚得多，”Schleidt如是说。

　　Web服务的管理必不可少

　　遇到紧要关头，管理部门可以帮助公司坚持奉行SOA的原则。丹麦银行分管产品、流程和IT开发的18个业务部门均设有指导委员会。但如果业务经理想急于打败对手，一旦需要比较长的时间才能完成，他们有时候会忍不住抛弃通用的SOA方法。Schleidt说: “你需要一个管理流程，好应对上面这样的情形。我们总是有时间在事后进行改变，那为什么不改变做法，一开始就把事件做好呢？”这种一劳永逸的方法会产生长远影响。Torp说，丹麦银行现在有两个个性化引擎、四项交互式顾客沟通服务以及四个支付处理应用。

　　几年前，哈特福德成立了一个中心部门，名为Property and Casualty Architects Collective，负责监管如何在整个企业采用SOA。该部门组建了一个参考架构，概述可以在特定环境下使用的推荐的方法、实践及产品。

　　哈特福德的企业架构师James McGovern说: “其实质思想就是交流架构方面的想法、重复利用思维过程。工作的艰辛就体现在这方面，但正是这方面体现了价值所在。”

　　负责应用基础设施交付的另一部门负责选择及实施管理平台、业务流程引擎和UDDI注册中心，并且确保用来描述服务接口的WSDL文件符合标准。没有参与特定项目的架构师负责检查项目的应用设计，确保服务没有重复。

　　在Cendant公司，项目经理负有这项责任。可以通过Rosetta Stone业务领域模型当中基于XML的层，访问服务名称和输入及输出字段。一个部门专门负责更新业务领域模型。Wiseman说: “这就是我们控制重复使用的方法。”

　　如果业务领域所有者发现某项服务早已在注册中心里面，服务会被打上标记，表明它适合重复使用。基本上由IT经理组成的SOA管理委员会随后接过工作。开发人员用不着操心。

　　Wiseman说: “编程人员是最不适合做出决策的人。他们总是希望编写新的东西。”