体系结构实践，第 4 部分: 场景 1：实际 SOA 场景中的服务创建选项

使用 IBM? 面向服务的体系结构（Service-Oriented Architecture，SOA）基础生命周期在软件开发上下文中讨论 SOA。体系结构实践 专栏的本部分将重点讨论 SOA 场景中的第一个场景，服务创建场景。探究 SOA 中的三个主要服务来源，以及为恰当使用相关服务提供指导的体系结构模式。熟悉各个模式及 SOA 生命周期中的各种活动，并了解用于实现和实例化这些模式的 IBM 产品的常用建议。 引言 体系结构实践 专栏文章的第 1 部分“理解面向服务的体系结构”讨论了 IBM 的面向服务的体系结构 (SOA) 基础生命周期（或 SOA 生命周期），以及其如何允许 IBM 客户从软件开发生命周期的角度来看待 SOA。其中详细讨论了 IBM SOA 生命周期的四个阶段——建模、组装、部署和管理。 本专栏讨论各种广泛的主题。有关 IBM SOA 场景的更多信息，请阅读第 2 部分“SOA 解决方案场景介绍”，其中介绍了典型的基于 SOA 的 IT 项目中的八个最常见场景。第 2 部分对各个场景进行了说明，解释了其背后的理念以及能够对其加以应用的广泛上下文。第 2 部分还讨论了用于将特定 SOA 场景应用到启用服务的典型遗留项目。 本文（第 4 部分）重点讨论八个场景中的第一个场景：服务创建场景，可帮助您了解 SOA 如何帮助解决典型的业务挑战。本文将讨论不同的服务创建选项背后的基本原理，并将给出各个选项最相关和最适用的情况。 对于每个服务创建选项，文章中会将其与 SOA 生命周期中各个阶段的高级活动对应起来。另外还将包括有关可用于实现生命周期每个阶段的活动的一个或多个 IBM 产品和工具的建议。 处理业务挑战 快速而有效地实现业务计划是大部分组织都必须处理的一项主要业务挑战。企业必须能够认识各种市场情况并快速地调整其战略，以反映变化。为了获得这种灵活的业务模型，需要有同样灵活的 IT 基础设施作为支持。SOA 中的服务 定义为自包含的可重用软件模块，用于执行特定业务任务。现在将这些服务作为基础软件构建块使用，以提供灵活的 IT 解决方案。服务具有定义良好的接口，独立于其运行的应用程序和计算平台。在现在的环境中，必须了解您的业务及流程（作为一组相互联系的可重复业务任务执行，可以将这些业务任务方便地进行重新排列）。 您的组织需要一种机制来为增值投资（提供独有功能的任务）分配资源。您需要将资源集中在能给业务带来突出优势和价值的投资上，而不用担心经常出现的低价值琐事级的任务。 您还会希望业务能够稳定地增长。您需要确保自己了解和信任的业务系统具有良好的性能和可靠性，同时与值得信赖的业务合作伙伴和服务提供商合作，以便获得您所需要的服务。而且，如果选择收购某个企业，则必须能够将其业务系统与您的系统集成，以确保快速形成统一体。 所建议工具或技术的详细说明不在本文的讨论范畴内。有关更多信息，请参见参考资料部分。 一个不错的着手点是将业务已有的东西 与业务所需的东西 进行比较。建模现有业务流程和未来业务模型，并模拟其功能和效果，从而提供关于业务应该如何运行的参考框架。然后考虑组成业务流程的各个任务应该如何完成的问题。每个任务都需要由服务提供支持。通过 SOA 可以将这些服务连接为灵活的模块化系统，从而为灵活业务模型提供支持。确定服务来自何处是实现优化业务流程远景的第一步。 回页首 服务创建场景的访问模式 IBM 确定了 SOA 中服务的三个主要来源，如图 1 中所示。 图 1. 三个服务来源 四个常用体系结构模式提供了相关指南，说明了关于如何恰当地使用三个主要来源提供的服务创建基于服务的 IT 解决方案。建议的方法是将需要的东西与已有的东西进行比较。可以自己从头创建服务、购买服务或使用现有的支持服务的打包软件或自定义软件。可以通过以下方式利用所有三个类别的服务： 现有应用程序和资产中的现成高价值软件应用程序和系统支持的服务启用任务。 使用外部提供的服务支持琐碎任务。 仅在需要填补剩余空白领域时创建新服务。 本部分剩下的内容将对服务方面和使用方面的不同体系结构模式进行概述。   启用服务的现有资产 SOA 并不是“拆除和替换”。最好的做法是在现有应用程序、系统和资产中确定可重用的高价值业务任务，并采用 SOA 的原则和技术来公开服务。重用已有的应用程序和系统是一项非常明智的业务决策。可以减少新技术方面的投资，而使用现有业务逻辑（这是公司拥有的最宝贵且经过验证和时间考验的资产）。当前应用程序的服务启用工作可以大幅度加速 SOA 项目的采用进度，并能降低其风险。研究表明，这样的开销比从头构建方法少五倍。由于常用功能的代码已经过了严格的生产使用的检验，因此其维护开销也会减少。 图 2. 启用服务的现有资产 在此技术中，单个服务可以利用一个打包或自定义应用程序或者多个系统来提供其预期功能。例如，SAP 客户关系管理系统中的地址记录可以与基于大型机的遗留财务系统进行组合，以创建支持开设新客户帐户的服务。此组合服务可以为涉及配送和开单的订单输入业务流程提供部分支持。这样减少了服务大幅度增加的风险，不会在不管粒度如何的情况下将任何现有 IT 功能都视为服务并加以公开。通过应用恰当的 SOA 方法，如 IBM 提供的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）（请参见参考资料），可以解决服务粒度问题。 用于处理启用服务的现有资产的两个最流行的体系结构模式如下： 直接将现有应用程序功能作为服务公开。 将功能作为服务组件间接公开。   直接将现有应用程序功能作为服务公开 当必须将现有应用程序功能作为服务公开，以供其他系统和应用程序使用，或提供更多的访问渠道时，则使用此方法。对于此模式（如图 3 中所示），其中假定您采用非常简单的场景，其中的现有功能并不复杂，只是使用 Web 服务技术将其作为服务提供者部署。这个简单的拓扑并不需要任何新基础设施，因为此服务使用支持服务的现有应用程序（通常为遗留应用程序）的工具和技术实现。 例如，可以使用 IBM CICS? Transaction Server V3.1 Web 服务技术将 COMMAREA 应用程序直接作为 Web 服务公开。最低要求是所公开的服务符合 WS-I Basic Profile 的要求。（有关技术模式以及现有遗留功能如何作为服务公开的更多信息，请参见参考资料。） 对于此方法，一个好处是服务接口由所公开的遗留资产定义，因此不需要进行分析来设计接口规范。而且，由于新服务可以在与包装的现有资产相同的平台上运行，因此没有必要添加新基础设施。能省略接口定义和分析，而且要处理的平台更少，这样部署周期就会更短。 采用此体系结构模式来提供服务器支持时，需要考虑以下主要体系结构注意事项： 服务使用者与遗留资产的定义建立联系，而后者在很多情况下的最初设计都比较糟糕。 此模式假定现有应用程序平台提供了对服务调用的最新技术的支持。 实现模式经常给系统带来高服务消息处理负担，而这些系统经常针对无内部互锁管道级的微处理器（Microprocessor without Interlocked Pipeline Stages，MIPS）使用进行了优化。   图 3. 直接将现有功能作为服务公开 将功能作为服务组件间接公开 此服务支持体系结构模式代表了在现有应用程序功能和服务之间引入中间软件组件（称为服务组件）的情况。下面的图 4 显示了一个示例。 服务组件也称为企业组件（请参见参考资料），是提供服务和实际实现之间的抽象层的 IT 组件。服务组件可以通过以下方式之一发挥作用： 从头创建业务逻辑和功能时，服务组件可以对内聚业务逻辑从逻辑和功能方面进行封装。 当必须对一个或多个现有操作系统的业务逻辑集成和重用，从而为服务提供集成业务逻辑实现时，服务组件可以封装对外围操作系统（可能为异类系统）的访问机制。   使用中间服务组件有一些好处： 可以在不影响服务使用者的情况下更改现有操作系统中的业务逻辑实现。服务组件可以方便地进行扩展，以封装数据和信息，并为数据或信息服务提供外观层。 可以在操作系统层进行系统和功能的 IT 合并或迁移，而对服务使用者的影响很小或者没有影响。 可以将服务部署在与现有应用程序不同的基础设施上，而现有应用程序的基础设施通常针对服务的特定处理要求进行了硬编码。   对于直接将应用程序功能作为服务公开的情况，此模式还有一些主要体系结构注意事项。首先，它允许与业务保持紧密一致但并不一定直接映射到现有应用程序接口的服务接口定义。可以使用 SOA 的原则和最佳实践来以正确的粒度级别设计服务和接口。不过，这会增加恰当定义服务的设计时间，而且开发周期更长。其次，其设计经常比直接公开更为复杂，因为可能会涉及到使用适配器或连接器技术来与操作系统进行连接。 图 4. 服务组件作为操作系统功能与应用程序层的服务间的中间层 使用外部提供的服务 在此场景中，服务的来源为一个或多个第三方服务提供商。应用程序利用第三方服务来实现其所需的功能。图 5 显示了服务如何依赖第三方实现提供者进行实现。 图 5. 依赖第三方提供商 此模式的主要优势在于，并不需要花时间为服务定义开发实现构件，将由外部服务提供者提供这些构件。这可以大幅度减少开发时间。还有个值得注意的优势是，客户机能够根据各种技术、财务和政策注意事项在服务提供者之间进行切换。 有一些主要体系结构注意事项需要加以处理： 必须恰当地定义服务的服务级别协议（Service-Level Agreement，SLA）。在寻找最佳的第三方提供商时，满足 SLA 的能力是一项重要考虑事项。 由于服务实现位于企业防火墙之外，所以必须为服务及其调用配备恰当的安全性措施。 应该非常强调服务治理，以建立用于选择最合适的服务提供者的标准。对行业及开放标准的遵从，以及作为服务提供者的第三方的成熟度之类的因素，应该由治理组织加以确定。   从头构建服务 在此场景中，必须从头设计、定义和开发服务。现有应用程序或任何第三方提供商都不能提供功能或服务来满足您的需求。此场景依赖于 Java? 2 Platform Enterprise Edition (J2EE) 应用服务器支持服务实现。核心业务功能通常使用标准 J2EE 开发，而且通常采用 Enterprise JavaBeans (EJB) 或简单的传统 Java 对象（Plain Old Java Object，POJO）的形式。采用了标准 J2EE 集成开发环境（Integrated Development Environment，IDE）功能和技术来将 EJB 或 POJO 转换为标准 Web 服务。 此方法的优势在于，可通过其根据现有业务需求建模服务，并对其进行恰当的设计来满足将来的业务需求。服务并不受现有操作系统或第三方提供商的约束。 体系结构方面的一个重要注意事项是，需要在整个服务开发流程中（从表示到规范再到实现）应用完整的 SOA 方法（例如 SOMA）。 回页首 服务定义和实现“菜谱” 前一部分所讨论的体系结构模式可帮助标识和设计服务，需要对其进行实例化，以实现端到端 SOA 解决方案。您需要将模式步骤应用到 SOA 生命周期中，并提供正确的工具和产品来创建特定的 SOA 构件。 IBM 使用和遵循 SOA 生命周期（建模、组装、部署和管理）、治理和流程；我们确定了可应用于 SOA 生命周期的每个阶段的每个体系结构的活动（请参见参考资料）。IBM 还提供了大量的相关产品，可帮助实现任何工业强度 SOA 解决方案。 此部分将以下体系结构模式及其较高级别的活动放入 SOA 生命周期的上下文中进行讨论： 现有功能的直接公开 现有功能的间接公开 第三方提供的服务 从头创建的服务 另外，还提供了经常建议使用的 IBM 产品的概述，可通过使用这些产品来在真实的合作项目中帮助实现和实例化模式。   实现现有功能的公开 和所有 SOA 项目一样，最好从生命周期的角度来看待现有功能的直接公开（也称为现有 IT 资产的服务支持）。此处我们将利用得到广泛认可的 IBM SOA Foundation 所定义的服务生命周期。图 6 显示了可以如何应用 SOA 生命周期来为现有资产启用服务。 图 6. 在现有资产的服务支持中应用 SOA 生命周期 SOA 生命周期的每个阶段都可以应用到服务支持工作中。建议的较高级别的活动包括： 建模 开始从当前 IT 应用程序和系统投资组合中形成候选资产目录，以启动建模阶段。在此阶段，最需要关注的是服务建模方法。IBM 的 SOMA 方法是用于面向服务的建模的可靠且经过严格验证的方法。Rational? Unified Process (RUP) 也扩展为可处理面向服务的方法 (RUP for SOA)。RUP for SOA 基于 SOMA 方法。IBM 的 Rational Software Architect (RSA) 提供了建模框架对服务模型进行建模和设计。 组装 使用各项技术在不更改其提供的基本功能的情况下将资产转换为可重用服务。转换流程实际上将涉及使用定义良好的接口包装现有功能。 在此阶段，通常为在 IBM System z? 系统（之前的 IBM eServer?zSeries? 系统）上运行的 CICS 应用程序提供服务支持的工具是名为 IBM WebSphere? Developer for zSeries (WDz) 的 IDE。将需要启用服务支持的现有代码库导入到 WDz 的工作区中。可以利用工具功能来开发 Web 服务描述语言（Web Services Description Language，WSDL）定义。在此过程中，现有应用程序的数据和语言结构可能需要一些映射和转换。可以从此 IDE 生成 WSDL 和特定应用程序绑定。 组装阶段也包括对所开发代码的单元测试。WDz 提供了用于 CICS Transaction Server (TS) 的测试环境，提供了所有基本功能，以便测试在实际工业强度 CICS TS 上运行的 WSDL。可以在 CICS TS 测试环境中作为组装阶段的一部分对生成的 WSDL 进行测试。 部署 使用 SOA 基础设施和中间件产品来部署服务，从而将访问扩展到其他涉及到更多系统和用户的功能。 在此阶段，要将经过单元测试的 WSDL 和所生成的 COBOL 源代码（进行了可能的数据和语言转换后）部署到 CTS 上。随 CTS 3.1 提供了很多 Web 服务功能（如 WS-Security），可以在部署过程中对其进行配置。 管理 以实时方式仔细管理和监视所部署的服务，以了解更新后的资产的性能和安全性。对于此阶段，主要的焦点转移到了管理和监视所部署的服务上。必须仔细地监视服务，以确保遵从已发布的功能和非功能需求。 IBM 的 Tivoli? 品牌产品针对一般系统管理和监视进行了优化，包含用于满足监视和管理服务的大量产品。Tivoli Omegamon-XE for CICS 3.1 常用于在 IBM z/OS? 上管理和监视 CICS TS。Tivoli 还提供了一套产品，专门针对服务调用和安全性的特定领域，如： IBM Tivoli Federated Identity Manager (ITFIM)，提供松散耦合联合标识模型来跨企业边界管理标识。 IBM Tivoli Identity Manager (ITIM)，提供企业内的集中标识管理系统。 IBM Tivoli Access Manager (ITAM)，提供单点登录和授权功能。   治理和流程 确保遵循服务生命周期及其有效控制和管理方面的策略、标准和最佳实践。 对于此阶段，WebSphere Service Registry and Repository (WSRR) 是支持整个 SOA 生命周期的 IBM 产品。WSRR 允许服务提供者安全地注册业务服务，以供服务使用者进行查找和绑定。另外还提供了发布在 SOA 中管理服务的生命周期所需的元数据的功能。   总而言之，在实现直接访问现有应用程序的模式时，可以遵循标准 IBM SOA 生命周期的阶段，并在各个阶段中使用以下产品： RSA，用于服务的建模和设计。 WebSphere Developer for zSeries，用于将现有功能组合为服务，并从 CICS TS Test Environment 对其进行单元测试。 在 CICS TS 3.1 上部署服务定义以及所生成的遗留代码。 使用一系列 Tivoli 管理与监视产品，如主要用于管理和监视服务 SLA 的 Tivoli Omegamon-XE、ITFIM、ITAM 等。 WebSphere Service Registry and Repository，用于在 SOA 中在服务的整个生命周期中对其进行管理。   实现现有功能的间接公开 服务创建的每个机制都具有一组规程，即给定场景下最常遵循的步骤。前面所述的这些步骤可以与 SOA 生命周期的五个阶段建立联系。此场景的主要步骤与实现现有功能的公开非常相似，因此将不在此进行重复说明了。 正如服务创建场景的访问模式中所述，间接公开和直接公开的区别在于其中包含了服务组件层。服务组件提供与业务保持一致的服务接口——自顶向下方法。通过分析现有资产，可以确定可以使用哪些系统中的哪些应用程序功能来实现服务组件定义的服务接口。服务组件充当业务中心视图和现有应用程序之间的中间层。因此，这个新的外观组件在组装阶段需要执行额外的步骤。 在建模阶段，可以使用 SOMA 方法及其抽象规范进行服务定义。这与第一个访问模式并没有太大的区别。在这两者中，都将执行 SOMA 的服务标识阶段。不过，其区别在于阶段中的活动重点。在直接公开期间，其重点在现有资产分析上。在非直接公开场景中，重点在使用自顶向下方法标识与业务一致的服务。此处建议使用的 IBM 产品是 Rational Software Architect。 在组装阶段，最常用的工具是 Rational Application Developer (RAD)。如果在此阶段将 RAD 作为 IDE 使用，请遵循以下步骤： 在 RAD 工作区创建 Web 或 J2EE 项目——最好是新项目。从与业务一致的角度来认识服务及其接口操作，并据此定义 WSDL。使用 SOMA 标识阶段的输入来定义与业务一致的服务（业务服务）。如果已经定义了 WSDL 并且其可用，直接将其导入到 RAD 的项目工作区中即可。   从 WSDL 生成会话 EJB 框架。应该随后实现所有操作的业务逻辑。对于遗留系统在其他环境中运行的情况，应该在实现期间使用适配器技术。例如，对于在独立 System z (zSeries) 计算机上运行的 CICS 应用程序，需要使用 CICS ECI 资源适配器连接到 CICS 系统。 资源适配器通常采用资源存档 (.rar) 文件的形式，需导入到 RAD 工作区。资源适配器包包含应用程序编程接口（Application Program Interface，API），可用于帮助从会话 EJB 访问 CICS 应用程序。还应该针对遗留系统中使用的特定语言使用相关的 Java 数据绑定。 将 WSDL 定义以及所实现的会话 EJB、Java 数据绑定以及可选资源适配器打包为企业存档（Enterprise ARchive，EAR）文件，以供进行部署。   尽管在组装阶段使用 RAD 是一种很常见的做法，但很多 IT 企业仅在使用遗留系统方面非常专业。在这样的客户机环境中，建议使用 WebSphere Developer for z (WDz)。WDz V6.0.1 提供了内置的 CICS TS 测试环境，可与 CICS Transaction Gateway V6.0.2 组合使用，从而提供一个非常强大的用于从遗留系统公开服务的环境。 如前面所提到的，WebSphere Service Registry and Repository 是用于服务生命周期治理的标准 IBM 产品，同时我们也建议使用此产品。 实现第三方提供的服务 当现有遗留系统和应用程序过于晦涩难解而难以替换，或业务需求要求提供现有系统中没有的功能时，则下一个选项就是第三方服务提供商。行业中经常出现第三方程序包提供的功能影响企业的业务需求的情况。很多企业都出现了这样的情况，但后来却发现由于所感兴趣的第三方程序包的特性或功能影响，就开始改变自己的业务需求。这是 SOA 采用中的一个反模式，应该加以避免。 在此场景中，功能需求可由第三方服务提供商完全或几乎完全满足。在业务需求强制要求的可接受限制范围内，必须满足功能需求和 SLA 需求。 此场景的高级活动也可以映射到 SOA 生命周期的各个阶段，如图 7 中所示。 图 7. 将第三方服务包含到企业 SOA 中 SOA 生命周期的每个阶段都可以应用到服务支持工作中。建议的高级活动总结如下： 建模 首先运行转换范围内的业务流程的模拟，并决定哪些服务适合自己创建，哪些服务适合从外部获取。 在建模阶段，重点是分析使用第三方服务提供商而不自行构建服务的理由。将执行各种业务分析和模拟，并评估成本、时间、资源和 IT 可行性。 组装 访问外部服务，并将其与自有服务编排在一起，从而支持端到端业务流程。组装将对第三方服务和企业自有服务进行编排。 在组装阶段，将执行主要工作。所建议的 IBM 产品为 RAD。相关步骤包括： 从服务提供者获取 WSDL。 验证 WSDL，并与提供者进行合作，以成功地通过完整的验证。 在 RAD 中创建新企业应用程序。 将 WSDL 导入项目工作区。 从 WSDL 生成客户端存根。这时请仔细分析哪种 XML 绑定类型是恰当的（JAX-RPC、JAXB 等）。 根据客户端存根开发客户机应用程序，以调用服务。 将项目打包为可部署 EAR 文件。   部署 可以对经过编排的服务进行部署，而不用担心每个服务的出处。 在此阶段，可部署 EAR 文件安装在 Web 服务兼容中间件服务器上。此处建议的 IBM 产品是 WebSphere Application Server。所安装的 EAR 文件提供了客户端 API，以使用第三方服务。 管理 如果第三方服务提供商进行实现工作，则务必监视服务，以确定是否符合和满足业务强制要求的 SLA 和合同规定的关键性能指标（Key Performance Indicator，KPI）。IBM Tivoli Composite Application Management (ITCAM) for SOA 是用于监视运行时服务器来确定遵从性的最为全面的 Tivoli 产品。   治理和流程 在注册中心创建和维护外部服务目录，以方便访问和管理。 在此阶段，将提供外部服务的 WSDL 定义此阶段建议的 IBM 产品是 WebSphere Service Registry and Repository (WSRR)。任何采用服务增强形式出现的更改都在管理服务的生命周期的 WSRR 中进行管理。   实现从头创建的服务 此场景通常是最后的选择。当没有现有应用程序功能可以直接或间接地作为服务公开，而且没有第三方服务提供商提供所需的业务功能时，就会采用此方法。服务定义和所有实现构件都需要从头构建。这可能看起来很简单，没有需要作为基础的现有遗留系统，没有要集成的遗留代码，没有要挂接的第三方提供商服务，也没有部署时要考虑的复杂拓扑。但要确定服务标识和深入规范，可能会有不少的工作要做。图 8 显示了 SOA 生命周期的不同阶段的主要活动。 图 8. 应用于从头创建服务时的 SOA 生命周期 从 SOA 生命周期的角度而言，从头创建服务所涉及的活动如下： 建模 其重点在于设计与服务一致的服务，同时涵盖当前需求和将来的需求。建议的方法是应用 SOMA 的服务标识技术，并同时使用 Rational Software Architect 进行服务建模，以创建实际的建模构件。   组装 用于服务开发的建议 IBM 产品是 Rational Application Developer (RAD)；RAD 是一个可靠且功能丰富的 J2EE 应用程序开发 IDE，它还提供了用于服务开发和实现的各种简单功能和高级功能。它提供了基本服务实现的简单功能，并将其作为 WSDL 文件公开。Rational Application Developer 还可以添加有关 Web 服务实现的高级功能，从 WS-I 遵从性开始，以增量方式逐渐添加 WS-Addressing、WS-Transactions 等实现。使用 Rational Application Developer 进行服务开发的一般步骤（与实现第三方提供的服务类似）如下： 在 Rational Application Developer 中的新工作区创建 J2EE 企业应用程序项目。 基于服务的设计规范创建 WSDL 定义。或者，如果存在 WSDL，则将其导入工作区。 从 WSDL 生成会话 EJB 服务框架。 为服务框架中的所有已定义操作完成业务逻辑实现。 或者，创建用于调用服务的 Web 服务客户机代码。对于调用服务的 J2EE 应用程序客户机，此客户机代码已经足够了。对于非 J2EE 客户机，需要提供技术特定的客户机代码来进行服务调用。 将实现构件打包为部署时使用的 EAR 文件。 对于将企业业务流程作为服务编排实现的端到端解决方案，可以将此场景作为服务设计和开发工作进行构造；组装是这些服务在业务流程上下文中的编排。 建议使用的 IBM 工具为 WebSphere Integration Developer (Integration Developer)，此工具提供了业务流程执行语言（Business Process Execution Language，BPEL）开发环境。除了其他功能外，还提供了将现有服务编排为业务流程流的功能。所得到的流程可以随后部署到 BPEL 运行时引擎中，从而提供编排功能来执行企业级业务流程。 部署 经过打包的 EAR 部署模块安装到 WebSphere Application Server 运行时上。对于分布式环境，建议使用 WebSphere Application Server Network Deployment Edition V6 作为运行服务的中间件。要部署所提到的业务流程，建议使用的 IBM 产品是 WebSphere Process Server V6（属于 IBM WebSphere Business Service Fabric 中间件）。 管理 需要对所部署的服务进行监视和管理。监视通常是保证遵从服务的 SLA 的典型强制要求，并在达到不遵从阈值时引发警报或事件。在企业范围外公开服务时，最低要求是，要保证非授权访问无法访问服务。前面提到的 Tivoli 产品均适用于此场景。简要总结如下： IBM Tivoli Composite Application Management (ITCAM) for SOA，用于监视服务以确保 SLA 遵从性。 IBM Tivoli Federated Identity Manager (ITFIM)，用于在整个企业范围内进行联合标识管理。 IBM Tivoli Identity Manager (ITIM)，用于跨企业系统提供集中标识。 IBM Tivoli Access Manager (ITAM)，用于单点登录和在服务调用前进行授权。 治理和流程 服务生命周期管理的建议 IBM 产品是 WebSphere Service Registry and Repository，此产品具有可靠的高级功能，能以模块化的方式进行使用。 回页首 总结 IBM 确定了典型的基于 SOA 的 IT 项目的八个不同的常见 SOA 场景。IBM 还提供了全面的指导信息，说明应该如何使用面向 SOA 的 IBM 工具、产品及方法对每个场景进行建模、设计和实现。 在本文中，我们讨论了第一个 SOA 场景，服务创建。我们还对基于以下三个主要服务来源进行良好服务支持的四个最常用的体系结构模式进行了概述：现有应用程序、第三方服务提供商以及从头创建服务。另外，我们还了解了如何将 SOA 生命周期应用到四个体系结构访问模式，以及 IBM 产品套件可以如何处理服务支持的特定设计、开发和运行时需求。