尽管面向服务的体系结构或SOA仍然是新生事物，但许多公司正逐步认识到需要采用SOA方法作为执行满足业务需求的解决方案的方法。采用这种方法的一个关键步骤是构建可重用服务的组合。

　　SOA 表示新应用程序的设计、开发和集成方式的根本性转变。它还将企业应用程序的开发简化为模块化业务服务，可以轻松地对其进行集成和重用。

　　SOA 的一个主要优点是缩小了业务和 IT 之间的差距。作为需求收集活动的一部分，将业务和技术需求与机构的与项目有关的主要业务目标相对应，将对确保项目与业务需求同步大有帮助。

　　着手构建服务组合的动力主要源于意识到需要保持业务需求与 IT 项目之间的一致性。一般来说，该过程始于初步确定所需的服务，进而发展到发现它们所依赖的服务与资源(如定义特定业务规则的政策等)并对其进行分类。理想状况下，这样做的成果是一套面向服务的业务应用程序，应用程序可以修正和重用，以满足企业不断变化的业务需求。

　　尽管在执行 SOA 时有许多问题需要考虑(如业务流程的编排、用户界面的开发以及支持安全和性能的基础架构等)，但是获得服务组合在逻辑上显然是第一步。在“精通 SOA”系列的此部分中，您可以大致了解用于构建服务组合的框架。

　　SOA 管理驱动组合构建

　　对SOA 组合的创建起积极推动作用的通常是那些最为关心 SOA 管理相关问题的人。理想状况下，这个“管理委员会”应当是相关组的交叉项，包括业务流程所有者、系统架构师和开发人员。

　　SOA 管理是一个宽泛的题目，值得专门撰文加以论述。不过，在这里我们不妨将其概括为“将 SOA 的灵活性与传统 IT 体系结构的控制及可预言性相结合的框架”。

　　SOA 管理在本文中一般涉及下列方面:

　　◆　服务与相关资源的生命周期管理
　　◆　相关性管理
　　◆　策略的应用与管理
　　◆　安全性和运行时策略执行
　　◆　服务可用性
　　◆　服务供应
　　◆　执行能够管理不断增长的服务组合的管理平台的重要意义远远不止于对技术基础架构和运行时间环境所需进行的改进。

　　对任何管理计划来说，主要目标都是通过定义将管理建立在其核心内的 SOA 策略来最大限度地降低风险。不受管理的 SOA 可能会导致如下后果:

　　◆　由于发布的服务不完全符合服务级要求而导致过程的中断
　　◆　由于服务问题和故障而使帮助台和现场服务呼叫猛增，导致支持费用的增加
　　◆　缺乏互操作性，从而形成业务服务的孤岛并时刻面临传统的、紧密耦合的体系结构所带来的挑战
　　◆　由于无法使主要策略与服务相关联而导致无法满足合归性要求
　　◆　由于允许随意访问数据和服务而形成安全漏洞
　　◆　随着服务产品的增加，未受管理的 SOA 中存在的这些问题所形成的风险会成指数倍地增加。不过，通过对服务组合的正确执行和管理，其中许多风险能够得以减少。

　　服务发现

　　逻辑上，构建服务组合的第一步是确定需要哪些服务。用于鉴别和发现候选服务的可行技术有三种，即自顶向下分析、自下向上分析以及业务流程跟踪。注意，应当考虑使这些技术互为补充，不要唯一排外，每一种技术都应当在您的服务发现过程中发挥作用。

　　第一步，您应当启动自顶向下的分析，重点将机构的业务分解为若干功能“域”。在这里，域是指密切相关的功能和数据(如客户、产品和合同)的逻辑分组。

　　自顶向下的分析一般会形成一个符合业务需要的、实际的候选服务集。不过，单凭该过程并不能发现机构内的所有候选服务。接下来要做的是对 IT 基础架构、应用程序的功能性、业务应用程序以前曾使用过的数据以及现有的服务进行彻底的检查。这种自下而上的方法通常会产生大量的高级和低级候选服务。

　　作为补充手段，您应当对每个业务事件的生命周期进行跟踪，以便发现哪些服务是通过其生命周期处理该事件所需要的。该过程称为业务流程跟踪，它不但可以发现处理该事件所需的服务，还可以发现仅通过自顶向下或自下而上的方法操作时所遗漏的候选服务。

　　除了识别交付项目所需的服务之外，该业务流程驱动的方法还能够提供完整性检查，并就特定服务的重用潜力给出首要指示。

　　服务发现的最终结果将是一个概念上的服务组合，该组合包含了项目最需要的候选服务。

　　服务分类

　　发现一组候选服务之后，对它们进行分类是对其进行设计、开发和后续执行的至关重要的一环。

　　分类可以按照功能、用途、结构和调用等标准进行。例如，将服务分为基础架构服务(DNS 查找、电子邮件)或工具服务(转换)是基于功能进行的分类。

　　这种分类方法有助于识别属于同一功能域的服务、允许定义标准和最佳方法并对不同服务类的要求进行管理和监控。对服务进行分类的过程还将会发现业务服务的规则，可以将这些规则转换成一组应用于不同类型服务的、标准的、可重用的策略。

　　虽然服务进行分类还没有业界统一的标准，但通用描述、发现和集成 (UDDI) 注册表正在成为事实上的标准。UDDI 不但允许将元数据设置在服务上，还允许将其设置在诸如策略和 XML 模式等相关产物之上。

　　例如，您可以在 UDDI 注册表中创建下列分类模型以简化服务的发现、管理和控制:

　　◆　服务所有者和联系人信息
　　◆　服务或产物的功能描述
　　◆　版本信息/状态，例如“版本”或“状态:测试 | 生产 | 维护”
　　◆　服务类型(“订单输入”)或业务范围(“会计”)
　　◆　使用模式/建议，例如“事物处理 | 子事物处理”、“同步 | 异步”
　　◆　预期的错误信息，用于现有服务的重用
　　◆　服务相关性，可能包括相关的策略、XSL 转换和 XML 模式
　　◆　可用的服务端点，以及 Web 服务中抽象的和具体的 WSDL 位置给 UDDI 注册表中的服务和产物分类，不但可以使您能够更好地为潜在的候选项分类，而且还能发现可以重用的现有服务，从而避免了功能的不必要重复。

　　确定服务粒度

　　争取合适的粒度级别将实现使用、重用和可管理性方面的最佳化。顶级的、业务驱动的分析通常会发现与现有需求相对应的高级(粗粒度)服务。例如，一个粗粒度服务可能表示“流程采购订单”，它清晰地映射到一个业务流程。

　　由于自下而上的分析专注于 IT 基础架构和现有的 API，因此该方法通常会产生大量的粗粒度服务和低级(细粒度)服务。激活低级任务(例如“插入订单行项”)的功能就是一个示例。

　　理想状况下，您的 SOA 组合应当首先包括粗粒度服务界面，该界面直接与业务语义相对应。高级服务在动态的业务环境中灵活得多，因为它们没有紧密地耦合到下层基础架构之中。粗界面还允许您利用来自异类环境的其他服务来构建应用程序和流程，而不必考虑细节和差别。

　　相反，低级服务是和下层基础架构或 API 紧密耦合的，不能轻易加以修改以适应不断变化的业务需求。实际上，将一个服务包装在一个现有业务对象周围(例如企业 JavaBean (EJB))将不可避免地产生细粒度界面，把每个可供呼叫的方法显示在 bean 上。

　　用于处理机构内部非常特殊的案例的服务可以通过细粒度界面执行，这将为使用这些服务的客户端应用提供更多的灵活性。不过请记住，在灵活性增强的同时还须面对复杂性增加所带来的成本问题。

　　一般来说，您应当避免将低级界面公开出来作为服务组合的一部分以试图满足业务需求。可考虑改为将一组细粒度服务结合起来组合成粗粒度服务。

　　最后，需要记住的一点是，一个服务是否适当并不在于其是粗粒度还是细粒度，而要看其是否能使业务价值最大化。

　　服务获取

　　定义完服务组合之后，下一步是确定如何获取实际的服务:内部构建、获取服务或预订外部供应商提供的服务。

　　按照一般规则，那些关键性业务服务(即有益于业务流程、能为机构争取竞争优势地位的服务)最好是由内部提供。

　　您很可能在服务的发现阶段就已经在内部把可以映射到候选项的服务识别出来了。例如，倘若贵机构拥有 ERP 或 CRM 系统，则主要界面(客户、订单、帐户)都是可以加入到您的组合中去的服务。已经在企业内部使用的自定义应用程序可能也值得加以分析，以便识别可用的界面。

　　提供更多商品驱动的功能的服务(例如提供股票报价)可能是外部预订的候选项，很可能来自于贵机构已经与之建立关系的业务伙伴。一旦您开始搜寻符合您需要的服务，服务分类的需要便立即显现出来了。

　　显然，在识别候选服务时，有许多支持产物也需要创建和管理，例如，用于控制服务的策略;服务所使用的消息类型;以及将输入和输出消息转换成适当格式所使用的 XSL 转换。

　　创建一个这些产物及其相应服务之间的关系的目录将大大有助于构建您的组合。UDDI 注册表对本任务来说是一个价值极高的工具，它使您能够构建一个服务和相关产物的完整的在线目录。

　　SOA 管理需要考虑的事项

　　最好您的 SOA 基础架构能提供一个针对如下管理性能的平台:监控与诊断、外化的安全性、集中式审计与事件记录以及服务级协议与策略管理。有许多特定于 SOA 的组件可以用来进一步提高管理能力，例如企业服务总线 (ESB) 可用来实现可靠的消息传递;业务规则引擎可用来捕获和自动化业务策略;业务活动监控解决方案可用来优化服务。

　　采用中间 Web 服务管理服务器尤其受益。在这种配置中，服务通过一个向用户开放的代理 URL 被“虚拟化”，因此请求是通过媒介而不是直接发送到服务端点的。利用本集中管理平台可在服务上统一地设置策略，并为运行时策略的执行提供了一个单独的点。它还简化了服务度量和使用情况统计信息(对维护服务组合的运行状况至关重要的数据)的捕获。

　　服务虚拟化还具有提供位置透明度的优点:通过公开代理，可以在不影响服务用户的情况下对下部基础架构进行改动。该媒介必须维护其自身的虚拟服务到服务端点映射，或者利用 UDDI 注册表发现一个有效的服务端点。