尽管面向服务的体系结构或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注册表中的服务和产物分类，不但可以使您能够更好地为潜在的候选项分类，而且还能发现可以重用的现有服务，从而避免了功能的不必要重复。

  

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。