您需要准备适当的治理流程模型，以有效地了解面向服务的体系架构（Service-Oriented
Architecture，SOA）开发生命周期活动的优点。本文描述 SOA 治理流程，这些流程基于典型企业在
SOA 开发生命周期中采用的场景。密切研究重要的生命周期活动，例如服务标识、服务创建和重用、服务测试、服务版本管理和更改管理、服务水平管理（服务质量），以及服务安全性。了解您的组织在典型的
SOA 开发生命周期中可能面对的挑战，以及如何通过实现治理子流程，以及通过将某些角色和职责委托给每种场景的治理机构的各层，从而解决这些挑战。
SOA 治理是业务与 IT 治理的交集，注重服务生命周期以确保 SOA 的业务价值。SOA 治理是对服务生命周期的有效管理，而服务生命周期是
SOA 治理的关键目标。
图 1. SOA 治理的定义
IBM 的治理方法包括两个不同的成功方面：定义和执行。SOA 治理和管理方法（SOA Governance
and Management Method，SGMM）是一种端到端的定义方法，通过设计、实现和改进 SOA
治理来进行。SGMM 为您提供了确定所有必需元素以确保适当治理的说明性方法，包括确定新角色和职责、定义策略和指标，以及在
IBM 遵循的流程中放置检查点。在执行过程中，IBM 在不同的执行点之间分布这些策略，并监视和测量相关指标以改进治理模型。
除了上面描述的 SOA 开发生命周期外，IBM 还鼓励使用 SOA Foundation 生命周期。SOA
Foundation 生命周期从业务建模开始，将模型转换为信息系统，部署该信息系统，然后管理该部署。由于
SOA 开发生命周期紧密遵循 IBM 的 SOA Foundation 生命周期，典型的服务开发将经历建模、组装、部署和管理阶段。下面让我们更详细地分析一下这些阶段：
建模
建模阶段以业务需求为基础，在此阶段中将设计业务流程模型，确定业务服务，使用假设业务条件对流程进行模拟，并根据业务目标对随后的结果进行分析。如果目标未得到满足，则使用修改后的业务服务重新定义流程。从这些建模方面看，业务服务的标识是非常重要的活动，此活动是到
IT 服务实现的一对一映射。
组装
定义 IT 服务以后，您将到达设计、规范、创建和测试的组装阶段。使用业务流程的组合对所构造的服务进行独立的测试。测试合格的服务将进入运行时存储库，并针对服务使用者进行发布。由于不同的服务客户端使用的这些服务在功能方面稍有更改，因此将在更改流程获得批准后构建相同服务的具有不同功能的不同版本。
部署
在部署阶段，不同版本的服务将在存储库中进行发布，并在带有集成业务流程的服务容器中进行部署。还可以在运行时动态选择已部署的服务，以基于来自服务请求者的某些选择条件构建组合应用程序。
管理
在管理阶段中，将监视这些服务对不同服务请求的及时响应能力，检测不满足服务水平的情况，并恢复系统的可操作状态。在此阶段中，将优化服务和总体操作环境以满足业务目标。通过适当的服务水平安全性设计和实现对服务进行标识和遵从性管理。
在此 SOA 开发生命周期中，如果缺乏清楚定义并加以执行的 SOA 治理流程，则很可能会遇到以下挑战：
- 难于标识新服务并确定其优先级。
- 服务创建和重用方面的严重问题，例如创建多余或低效的服务。
- 采用测试策略和标准非常随意。
- 服务的更改和版本治理非常粗糙并且未定义。
- 没有系统的方法来执行针对服务管理、服务质量（quality of service，QoS）和服务安全性的治理策略。
这些挑战导致了作为 SOA 治理模型的一部分定义和执行以下流程的需求：
- 控制如何标识新服务和确定其优先级（服务标识）。
- 控制如何创建和重用新服务（服务创建）。
- 执行测试过程和策略以获得最佳服务实现（服务测试）。
- 执行针对服务水平管理（service level management ，SLM）的治理策略。
- 控制服务的更改管理和版本管理（服务版本管理和更改管理）。
- 执行服务运行时的安全标准和策略（服务安全性）。
任何组织都会随着需求的变化而不断增加新服务。服务标识是 SOA 开发生命周期中的第一步。在扩展当前 IT
治理模型以包含这些新服务和了解涉及到的角色的过程中，将会存在相关的挑战。
问题
由于业务和 IT 服务的标识过程中采用的方法不一致，存在各种各样的项目风险。服务可能无法互操作，并且在标识服务以后，其中许多服务可能是多余的。还可能存在这样的情况，其中没有服务标识和交付的可靠所有者。最终，所有这些风险都会导致增加项目成本和无法满足交付时间。但是您可以通过应用治理流程解决这些问题，如图
2 所示。
用于服务标识的治理子流程
在此治理流程场景中，参与定义策略和执行治理流程的参与者是 IT 执行指导委员会的成员；他们包括内部 SOA
卓越中心 (COE) 的成员和业务领域所有者或业务部门（line of business，LOB）负责人。IT
执行指导委员会被授权定义策略，并且在此场景中，他们的目的在于：
- 通过现有的操作系统构建 70% 的服务，只有 30% 的服务作为新服务来构建。
- 使已标识的服务在整个企业中可见以便重用。
图 2. 用于服务标识的治理子流程
该治理流程的定义必须确保满足以下要求：
- 通过同时使用领域分解业务流程模型和自底向上的模型，从而在服务标识过程中采用正确的方法。
- 要开始此治理流程，可以在该财年开头提出 IT 项目建议的时候由指导委员会发起请求，或者由领域所有者作为紧急请求发起该请求。
- SOA COE 应该确保 LOB 负责人捕获的所有业务需求是完整的，并且在服务标识开始前是最新的。这可以确保面向服务的建模和体系架构（Service-Oriented
Modeling and Architecture，SOMA）步骤得到遵循，并且标识的所有服务都是可跟踪的并满足业务目标。
- 将所标识的服务模型递交到领域专家以进行验证和签字同意。
- 在公共存储库中发布已批准的模型，以避免标识多余的服务。
- 此流程清楚地标识了应该拥有服务职责的领域所有者。
- 此治理流程可在设计时驱动更好的服务和重用需求。
在服务创建场景中，标识所需的服务之后，将定义和实现服务的低级规范。治理模型可以不执行这些任务，但它确保有人执行这些任务。COE
对创建服务和需要使用这些服务的团队进行协调，以确保满足相关需求，并避免重复工作。治理模型标识创建此类服务的所有者，并确定这些服务实现的优先级。
问题
目前，某个组织正在遭遇开发和部署多余和低效服务的问题，这些服务是跨不同的水平和垂直领域部门进行构建的，并且没有考虑到其他存储库。其中有些服务的实现以不一致的方式识别系统功能。维护成本与日俱增，因为要维护相似或相同服务的多个副本，并且不存在对此类服务的任何控制，从而进一步阻碍了开发。所有这些问题最终要求对服务创建流程进行控制。
用于服务创建的治理子流程
该治理流程定义了以下步骤，如图
3 所示：
- 在创建新的治理流程定义时，务必记住对候选项目进行检查并决定要进行哪一个项目的当前 IT 规划流程，并了解各个服务领域中对那些服务承担责任的所有权角色。您需要了解资金投入流程，并根据服务规范阶段中的定义来定义全面的
QoS 方法。
- 治理流程通过使用诸如重用、业务敏捷性和 SOA COE 的部署灵活性等公共评分标准，将功能作为潜在的服务进行评估，从而开始一个项目。
- 在决定要将功能作为服务提供之后，搜索不同的服务注册中心并确保还不存在类似的服务。如果该服务不存在，SOA
COE 将基于服务所属的业务领域向该服务分配所有权。
- SOA COE 保留了常用的基础结构和技术服务的所有权。
- SOA COE 确定该服务相对于其他服务的优先级。如果 COE 基于服务所属领域的所有权决定该服务具有高优先级，则领域所有者将分配资金。
- 服务所有者在 SOA COE 中具有专业技能的人员的帮助下，在设计和开发服务过程中投入适当的资源。
- 将所标识的服务模型传播到领域专家以进行验证和签字同意。
- SOA COE 架构师负责定义接口、消息流和非功能需求（nonfunctional requirement，NFR），以及低级功能需求。
- 完成服务的规范以后，SOA COE 再次检查服务，以便为进一步的实现确定优先级。
- 在实现阶段，SOA COE 体系架构团队帮助构建服务的低级设计，并针对垂直领域开发团队将服务映射到技术工具、实现等等。
- SOA COE 进一步确保服务遵守标准和最佳实践，从而降低整个部署和管理方面的风险。
（请参见图
3 的大图。）
图 3. 用于服务创建的治理子流程
在此场景中，将测试已实现的服务的必备功能，以及进行集成和系统测试的适合性。在集成和系统测试级别均合格之后，服务将经历
NFR 测试，例如响应时间测试、资源使用测试、事务吞吐量测试等等。
问题
在此场景中，您将考虑各种各样的团队使用不同的工具和测试策略来测试他们服务的情况。组织中不存在有关对服务实现使用工具、插件和测试策略的统一方法。这可归因于以下事实，即某些服务中的遵从性测试是在垂直单位中开发的，并出现了所实现的
IT 服务未正确满足业务需求的一些问题。某些单位无法在严格的项目时间表中按期完成集成和系统测试。少数项目团队还遇到了处理系统的
IT 服务实现的业务需求更改的难题。所有这些问题给测试场景中的治理带来了挑战。
用于服务测试的治理子流程
图 4 中列出了详细的流程，其中应该包括以下步骤：
- SOA COE 取得确定测试环境的功能和非功能测试工具的所有权，并基于项目需求定义测试策略。
- SOA COE 执行并向其他业务单位推广这些工具和测试策略。
- 项目的治理流程从 SOA COE 的各个域业务分析人员参与准备服务测试用例文档开始，并以分析人员签字同意结束。
- COE 发起服务单元测试，并使用由该项目的开发团队确定的资源，或者由服务所有权确定的资源。
- 该流程等待 SOA 测试人员完成单元测试报告的生成，然后发起服务集成测试请求。
- SOA COE 的一名集成架构师参与准备集成测试用例文档，并从业务分析人员处获得签字同意。
- SOA COE 的成员等待集成所需的所有服务准备就绪，这些服务或者来自某个业务单位中的各个团队，或者跨越业务单位。
- 如果集成所需的任何服务不可用，并且该服务仍在构建过程中，从而导致延迟，则 COE 的成员需要决定使用模拟服务进行测试，并发起集成测试。
- 遵循相似的指导原则发起系统测试，并积极地与基础结构架构师交流，以确定系统测试所需的正确软件和硬件版本及配置。
- 完成系统测试报告以后，COE 将发起 NFR 测试。
（请参见图
4 的大图。）
图 4. 用于服务测试的治理子流程
将新服务发布到生产环境中以后，那些服务的用户开始需要更改。错误需要修复，接口需要重新设计，新功能需要添加，不必要的功能需要删除。服务版本管理帮助系统稳定运行，而不中断现有的经过考验的服务功能，并允许您向那些服务添加新功能。
问题
某些业务需求更改不一定需要在 IT 基础结构中实现。在此场景中，关于所需的业务流程更改是否需要在 IT
中实现，或者是应该在现有服务中实现还是将其实现为下一个版本，组织中不存在做出此决定的权威。企业中没有研究和了解这些更改对其他服务使用者的影响的公共机构。并且不存在决定服务版本管理的运行时策略的权威。由于更改服务版本时的生产中断，客户对系统不可用性产生抱怨。不存在基于规则的自动服务提供者选择以实现顺利转换。不存在跟踪机制以了解系统中哪些服务在运行、哪些服务在实际被使用，以及哪些服务已从系统中退役。所有这些问题催生了服务版本管理治理的实现。
用于服务版本管理和更改管理的治理子流程
图 5 中定义了详细的流程，其中应该包括以下步骤：
- 在此流程中，IT 执行指导委员会在治理机构中发挥重要的作用。它是能够授权 IT 方面的更改以实现业务需求增强的授权机构。
- 该机构还决定哪些基本版本的服务可以进行增强，以及哪些更改可以在服务的现有版本中发布或作为下一个版本发布。IT
指导委员会的输入由 SOA COE 驱动，后者又从项目团队或垂直单位获得服务版本详细信息。
- SOA COE 研究现有服务的更改对其他服务使用者的影响，从而向指导委员会提交影响详细信息。
- SOA COE 研究现有的更改，同时将 NFR 考虑在内。但是如果更改是 NFR 增强，则需要基于提供者-使用者契约定义和标识运行时服务版本管理策略。
- 然后 COE 将确定对应的项目团队以构建和部署不同版本的服务，这些服务版本通过中介、业务规则、选择器和动态业务组装程序进行路由。
（请参见图
5 的大图。）
图 5. 用于服务版本管理和更改管理的治理子流程
服务监视和管理是将服务投入生产应用以后的重要活动。如果任何服务停止工作，系统应该确定并检测此类服务所面对的问题。服务监视可以帮助系统架构师在问题出现之前检测和预防问题。可以检测负载不均衡和停机状况，在这些情况造成重大影响前发出警告，甚至可以尝试自动纠正问题。
问题
在此服务管理场景中，您将考虑正在面对以下困难的组织：监视和管理对不同服务使用者公开的服务。这增加了对服务提供者的依赖。由于服务管理体系架构的设计非常糟糕，服务无法满足高可用性、性能指标和已定义的服务水平协议的预期。体系架构和开发团队不清楚需要基于服务水平协议（service
level agreement，SLA）进行监视的服务和资源。不存在统一的方法来采用涵盖业务应用程序的端到端视图的管理工具，不存在统一的方法来提供有关各个资源的性能和可用性指标的详细信息。所有这些问题催生了服务管理治理的实现。
用于服务管理的治理子流程
服务管理治理流程应该遵循以下基本步骤（另请参见图
6）：
- SOA COE 与业务团队合作从客户那里捕获 NFR。
- 在 SOA Foundation 生命周期的建模阶段中，SOA COE 与 LOB 服务水平经理和管理架构师就如何定义
SLA 进行交流。
- SOA COE 核心团队分析这些 SLA，并设计管理体系架构文档。管理架构师、IT 管理员、主题专家和应用程序开发人员帮助确定用于管理组合应用程序的资源。
- SOA COE 的成员还确定支持该管理体系架构的管理开发工具。
- 在 IT 管理员和各个垂直单位服务提供者的帮助下，COE 确保开发一个用于同时监视业务和 IT
性能资源的公共监视控制台。
（请参见图
6 的大图。）
图 6. 用于服务水平管理的治理子流程
SOA 安全性帮助限制用户对服务的访问。它保护服务提供者与服务使用者之间交换的数据。即使在授权用户中，并非所有用户都应该具有该服务能够访问的所有数据的访问权。必须对服务的访问进行控制，并且将访问权仅限于授权使用者。用户标识必须传播到服务中，并用于授权数据访问。数据保护的质量必须表示为相应范围内的策略。这使得使用者能够表达最低级别的保护和最大的功能，并与可能实际包含其他保护的相应提供者进行匹配。
问题
在此场景中，组织没有用于抵御安全威胁和保护服务避免外部访问的公共策略。多种服务身份验证和授权让操作员感到无所适从。没有准备针对策略采用以及在从开始到实现的过程中跟踪这些策略的安全策略管理框架，并且不存在负责与企业边界组织交互和沟通以维护公共安全标准集的机构。不存在用于与其他服务和数据交互的达成一致的安全标准，并且没有用于策略管理的已定义的角色和职责。这些问题导致组织需要定义和采用服务安全性治理流程，如图
7 所示。
用于服务安全性的治理子流程
该治理流程应该包括以下步骤：
- 在服务开发的建模阶段中，SOA COE 与业务分析人员和公司安全分析人员协作对给定的 SOA 场景进行安全需求建模，例如服务创建、服务连接、服务协作和业务流程管理，因为安全实现随场景的不同而千差万别。
- COE 具备开发 SOA 安全参考体系架构、安全标准、基于场景的安全实现策略和最佳实践的内在能力。
- SOA COE 在业务分析人员的帮助下确定项目所需实现的不同 IT 安全服务，并检查在实现这些服务的过程中是否遵循了开放标准。
- COE 确定各种安全支持因素，例如加密技术、用于存储用户信息的注册中心和存储库、硬件密钥，以及用于
IT 安全服务实现的防火墙。
- COE 基于场景重用并与项目团队共享已定义的逻辑和物理体系架构来实现安全服务。
- COE 在不同垂直单位的应用程序开发人员的帮助下，确定用于实现安全策略的各种工具和产品。
（请参见图
7 的大图。）
图 7. 服务安全性
本文确定了一些可在 SOA 治理方面提供价值的主要场景，并介绍了如何减轻这些主要场景中涉及到的风险。本文定义的所有治理场景可以根据需要进行定制，因为它们可能随组织结构、设置和治理流程所需的上下文的不同而异。
感谢 John Falkl 及其团队、Amar Raiker 和 Yaseen M Yaseen 对本文提供的支持与帮助。
学习
获得产品和技术
- 下载
IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli®
和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
| 
