精通SOA构建企业应用服务组合

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

◆　由于发布的服务不完全符合服务级要求而导致过程的中断

◆　由于服务问题和故障而使帮助台和现场服务呼叫猛增，导致支持费用的增加

◆　缺乏互操作性，从而形成业务服务的孤岛并时刻面临传统的、紧密耦合的体系结构所带来的挑战

◆　由于无法使主要策略与服务相关联而导致无法满足合归性要求

◆　由于允许随意访问数据和服务而形成安全漏洞

◆　随着服务产品的增加，未受管理的SOA中存在的这些问题所形成的风险会成指数倍地增加。不过，通过对服务组合的正确执行和管理，其中许多风险能够得以减少。

服务发现

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

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

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

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

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

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

服务分类

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

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

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

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

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

◆　服务所有者和联系人信息

◆　服务或产物的功能描述

◆　版本信息/状态，例如”版本“或”状态：测试|生产|维护“

◆　服务类型（”订单输入“）或业务范围（”会计“）

◆　使用模式/建议，例如”事物处理|子事物处理“、”同步|异步“

◆　预期的错误信息，用于现有服务的重用

◆　服务相关性，可能包括相关的策略、XSL转换和XML模式

◆　可用的服务端点，以及Web服务中抽象的和具体的WSDL位置给UDDI注册表中的服务和产物分类，不但可以使您能够更好地为潜在的候选项分类，而且还能发现可以重用的现有服务，从而避免了功能的不必要重复。

确定服务粒度

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

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