IBM Bluemix
点击按钮，开始云上的开发！
developerWorks 社区
您需要准备适当的治理流程模型，以有效地了解面向服务的体系架构（Service-Oriented Architecture，SOA）开发生命周期活动的优点。本文描述 SOA 治理流程，这些流程基于典型企业在 SOA 开发生命周期中采用的场景。密切研究重要的生命周期活动，例如服务标识、服务创建和重用、服务测试、服务版本管理和更改管理、服务水平管理（服务质量），以及服务安全性。了解您的组织在典型的 SOA 开发生命周期中可能面对的挑战，以及如何通过实现治理子流程，以及通过将某些角色和职责委托给每种场景的治理机构的各层，从而解决这些挑战。
, 顾问架构师,
Prabhakar Mynampati 是一名在印度 IBM Software Labs 的 BPTSE 工作的 SOA 架构师。他帮助 IBM 的 ISV 客户使用 IBM SOA、CBS 参考体系架构构建资产密集型解决方案。
什么是 SOA 治理？SOA 治理是业务与 IT 治理的交集，注重服务生命周期以确保 SOA 的业务价值。SOA 治理是对服务生命周期的有效管理，而服务生命周期是 SOA 治理的关键目标。图 1. SOA 治理的定义IBM 的方法：SOA 治理和管理方法 IBM 的治理方法包括两个不同的成功方面：定义和执行。SOA 治理和管理方法（SOA Governance and Management Method，SGMM）是一种端到端的定义方法，通过设计、实现和改进 SOA 治理来进行。SGMM 为您提供了确定所有必需元素以确保适当治理的说明性方法，包括确定新角色和职责、定义策略和指标，以及在 IBM 遵循的流程中放置检查点。在执行过程中，IBM 在不同的执行点之间分布这些策略，并监视和测量相关指标以改进治理模型。SOA 开发生命周期中的治理场景除了上面描述的 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 服务的标识过程中采用的方法不一致，存在各种各样的项目风险。服务可能无法互操作，并且在标识服务以后，其中许多服务可能是多余的。还可能存在这样的情况，其中没有服务标识和交付的可靠所有者。最终，所有这些风险都会导致增加项目成本和无法满足交付时间。但是您可以通过应用治理流程解决这些问题，如 所示。用于服务标识的治理子流程在此治理流程场景中，参与定义策略和执行治理流程的参与者是 IT 执行指导委员会的成员；他们包括内部 SOA 卓越中心 (COE) 的成员和业务领域所有者或业务部门（line of business，LOB）负责人。IT 执行指导委员会被授权定义策略，并且在此场景中，他们的目的在于：通过现有的操作系统构建 70% 的服务，只有 30% 的服务作为新服务来构建。使已标识的服务在整个企业中可见以便重用。图 2. 用于服务标识的治理子流程该治理流程的定义必须确保满足以下要求：通过同时使用领域分解业务流程模型和自底向上的模型，从而在服务标识过程中采用正确的方法。要开始此治理流程，可以在该财年开头提出 IT 项目建议的时候由指导委员会发起请求，或者由领域所有者作为紧急请求发起该请求。SOA COE 应该确保 LOB 负责人捕获的所有业务需求是完整的，并且在服务标识开始前是最新的。这可以确保面向服务的建模和体系架构（Service-Oriented Modeling and Architecture，SOMA）步骤得到遵循，并且标识的所有服务都是可跟踪的并满足业务目标。 将所标识的服务模型递交到领域专家以进行验证和签字同意。 在公共存储库中发布已批准的模型，以避免标识多余的服务。此流程清楚地标识了应该拥有服务职责的领域所有者。此治理流程可在设计时驱动更好的服务和重用需求。服务创建示例在服务创建场景中，标识所需的服务之后，将定义和实现服务的低级规范。治理模型可以不执行这些任务，但它确保有人执行这些任务。COE 对创建服务和需要使用这些服务的团队进行协调，以确保满足相关需求，并避免重复工作。治理模型标识创建此类服务的所有者，并确定这些服务实现的优先级。 问题目前，某个组织正在遭遇开发和部署多余和低效服务的问题，这些服务是跨不同的水平和垂直领域部门进行构建的，并且没有考虑到其他存储库。其中有些服务的实现以不一致的方式识别系统功能。维护成本与日俱增，因为要维护相似或相同服务的多个副本，并且不存在对此类服务的任何控制，从而进一步阻碍了开发。所有这些问题最终要求对服务创建流程进行控制。用于服务创建的治理子流程该治理流程定义了以下步骤，如 所示：在创建新的治理流程定义时，务必记住对候选项目进行检查并决定要进行哪一个项目的当前 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. 用于服务创建的治理子流程服务测试示例在此场景中，将测试已实现的服务的必备功能，以及进行集成和系统测试的适合性。在集成和系统测试级别均合格之后，服务将经历 NFR 测试，例如响应时间测试、资源使用测试、事务吞吐量测试等等。问题在此场景中，您将考虑各种各样的团队使用不同的工具和测试策略来测试他们服务的情况。组织中不存在有关对服务实现使用工具、插件和测试策略的统一方法。这可归因于以下事实，即某些服务中的遵从性测试是在垂直单位中开发的，并出现了所实现的 IT 服务未正确满足业务需求的一些问题。某些单位无法在严格的项目时间表中按期完成集成和系统测试。少数项目团队还遇到了处理系统的 IT 服务实现的业务需求更改的难题。所有这些问题给测试场景中的治理带来了挑战。用于服务测试的治理子流程 中列出了详细的流程，其中应该包括以下步骤：SOA COE 取得确定测试环境的功能和非功能测试工具的所有权，并基于项目需求定义测试策略。SOA COE 执行并向其他业务单位推广这些工具和测试策略。 项目的治理流程从 SOA COE 的各个域业务分析人员参与准备服务测试用例文档开始，并以分析人员签字同意结束。 COE 发起服务单元测试，并使用由该项目的开发团队确定的资源，或者由服务所有权确定的资源。该流程等待 SOA 测试人员完成单元测试报告的生成，然后发起服务集成测试请求。SOA COE 的一名集成架构师参与准备集成测试用例文档，并从业务分析人员处获得签字同意。SOA COE 的成员等待集成所需的所有服务准备就绪，这些服务或者来自某个业务单位中的各个团队，或者跨越业务单位。如果集成所需的任何服务不可用，并且该服务仍在构建过程中，从而导致延迟，则 COE 的成员需要决定使用模拟服务进行测试，并发起集成测试。遵循相似的指导原则发起系统测试，并积极地与基础结构架构师交流，以确定系统测试所需的正确软件和硬件版本及配置。 完成系统测试报告以后，COE 将发起 NFR 测试。（请参见 的大图。）图 4. 用于服务测试的治理子流程服务版本管理和更改管理示例将新服务发布到生产环境中以后，那些服务的用户开始需要更改。错误需要修复，接口需要重新设计，新功能需要添加，不必要的功能需要删除。服务版本管理帮助系统稳定运行，而不中断现有的经过考验的服务功能，并允许您向那些服务添加新功能。问题某些业务需求更改不一定需要在 IT 基础结构中实现。在此场景中，关于所需的业务流程更改是否需要在 IT 中实现，或者是应该在现有服务中实现还是将其实现为下一个版本，组织中不存在做出此决定的权威。企业中没有研究和了解这些更改对其他服务使用者的影响的公共机构。并且不存在决定服务版本管理的运行时策略的权威。由于更改服务版本时的生产中断，客户对系统不可用性产生抱怨。不存在基于规则的自动服务提供者选择以实现顺利转换。不存在跟踪机制以了解系统中哪些服务在运行、哪些服务在实际被使用，以及哪些服务已从系统中退役。所有这些问题催生了服务版本管理治理的实现。用于服务版本管理和更改管理的治理子流程 中定义了详细的流程，其中应该包括以下步骤：在此流程中，IT 执行指导委员会在治理机构中发挥重要的作用。它是能够授权 IT 方面的更改以实现业务需求增强的授权机构。 该机构还决定哪些基本版本的服务可以进行增强，以及哪些更改可以在服务的现有版本中发布或作为下一个版本发布。IT 指导委员会的输入由 SOA COE 驱动，后者又从项目团队或垂直单位获得服务版本详细信息。SOA COE 研究现有服务的更改对其他服务使用者的影响，从而向指导委员会提交影响详细信息。SOA COE 研究现有的更改，同时将 NFR 考虑在内。但是如果更改是 NFR 增强，则需要基于提供者-使用者契约定义和标识运行时服务版本管理策略。 然后 COE 将确定对应的项目团队以构建和部署不同版本的服务，这些服务版本通过中介、业务规则、选择器和动态业务组装程序进行路由。（请参见 的大图。）图 5. 用于服务版本管理和更改管理的治理子流程服务管理示例服务监视和管理是将服务投入生产应用以后的重要活动。如果任何服务停止工作，系统应该确定并检测此类服务所面对的问题。服务监视可以帮助系统架构师在问题出现之前检测和预防问题。可以检测负载不均衡和停机状况，在这些情况造成重大影响前发出警告，甚至可以尝试自动纠正问题。 问题在此服务管理场景中，您将考虑正在面对以下困难的组织：监视和管理对不同服务使用者公开的服务。这增加了对服务提供者的依赖。由于服务管理体系架构的设计非常糟糕，服务无法满足高可用性、性能指标和已定义的服务水平协议的预期。体系架构和开发团队不清楚需要基于服务水平协议（service level agreement，SLA）进行监视的服务和资源。不存在统一的方法来采用涵盖业务应用程序的端到端视图的管理工具，不存在统一的方法来提供有关各个资源的性能和可用性指标的详细信息。所有这些问题催生了服务管理治理的实现。用于服务管理的治理子流程服务管理治理流程应该遵循以下基本步骤（另请参见）：SOA COE 与业务团队合作从客户那里捕获 NFR。在 SOA Foundation 生命周期的建模阶段中，SOA COE 与 LOB 服务水平经理和管理架构师就如何定义 SLA 进行交流。SOA COE 核心团队分析这些 SLA，并设计管理体系架构文档。管理架构师、IT 管理员、主题专家和应用程序开发人员帮助确定用于管理组合应用程序的资源。SOA COE 的成员还确定支持该管理体系架构的管理开发工具。 在 IT 管理员和各个垂直单位服务提供者的帮助下，COE 确保开发一个用于同时监视业务和 IT 性能资源的公共监视控制台。（请参见 的大图。）图 6. 用于服务水平管理的治理子流程服务安全性示例SOA 安全性帮助限制用户对服务的访问。它保护服务提供者与服务使用者之间交换的数据。即使在授权用户中，并非所有用户都应该具有该服务能够访问的所有数据的访问权。必须对服务的访问进行控制，并且将访问权仅限于授权使用者。用户标识必须传播到服务中，并用于授权数据访问。数据保护的质量必须表示为相应范围内的策略。这使得使用者能够表达最低级别的保护和最大的功能，并与可能实际包含其他保护的相应提供者进行匹配。问题在此场景中，组织没有用于抵御安全威胁和保护服务避免外部访问的公共策略。多种服务身份验证和授权让操作员感到无所适从。没有准备针对策略采用以及在从开始到实现的过程中跟踪这些策略的安全策略管理框架，并且不存在负责与企业边界组织交互和沟通以维护公共安全标准集的机构。不存在用于与其他服务和数据交互的达成一致的安全标准，并且没有用于策略管理的已定义的角色和职责。这些问题导致组织需要定义和采用服务安全性治理流程，如 所示。用于服务安全性的治理子流程该治理流程应该包括以下步骤： 在服务开发的建模阶段中，SOA COE 与业务分析人员和公司安全分析人员协作对给定的 SOA 场景进行安全需求建模，例如服务创建、服务连接、服务协作和业务流程管理，因为安全实现随场景的不同而千差万别。COE 具备开发 SOA 安全参考体系架构、安全标准、基于场景的安全实现策略和最佳实践的内在能力。 SOA COE 在业务分析人员的帮助下确定项目所需实现的不同 IT 安全服务，并检查在实现这些服务的过程中是否遵循了开放标准。 COE 确定各种安全支持因素，例如加密技术、用于存储用户信息的注册中心和存储库、硬件密钥，以及用于 IT 安全服务实现的防火墙。 COE 基于场景重用并与项目团队共享已定义的逻辑和物理体系架构来实现安全服务。COE 在不同垂直单位的应用程序开发人员的帮助下，确定用于实现安全策略的各种工具和产品。（请参见 的大图。）图 7. 服务安全性结束语本文确定了一些可在 SOA 治理方面提供价值的主要场景，并介绍了如何减轻这些主要场景中涉及到的风险。本文定义的所有治理场景可以根据需要进行定制，因为它们可能随组织结构、设置和治理流程所需的上下文的不同而异。致谢感谢 John Falkl 及其团队、Amar Raiker 和 Yaseen M Yaseen 对本文提供的支持与帮助。
参考资料 您可以参阅本文在 developerWorks 全球站点上的
。从文章“”中获得有关 SOA 治理机构的结构的更多信息。阅读 Bobby Woolf 的文章“”。IBM developerWorks 提供了大量的文章，以及关于如何开发 Web 服务应用程序的初级、中级和高级教程。使用 进行试验！通过 IBM SOA 进行实际的亲手实践来提高您的 SOA 技能。提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。了解关于 的最新消息。 访问 ，浏览有关这些技术主题以及其他方面的书籍。查看快速的 。下载 ，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。参与 ，从而加入到 developerWorks 社区中来。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
为灾难恢复构建应用，赢取现金大奖。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=SOA and web services, ArchitectureArticleID=365110ArticleTitle=SOA 治理：服务生命周期管理流程示例publish-date=您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
知识型项目团队知识创造过程研究.pdf46页
本文档一共被下载：
次 ,您可免费全文在线阅读后下载本文档
文档加载中...广告还剩秒
需要金币：200 &&
你可能关注的文档：
··········
··········
中文摘要 随着知识经济的到来，企业的生产方式和管理方式都发生了重大改变，越来
越多的管理者都相信，在增强和维持企业的竞争能力方面，知识将成为企业最重
要的资源。党的十七大报告明确指出，提高自主创新能力，建设创新型国家，这
是国家发展战略的核心，是提高综合国力的关键。在知识经济和创新型国家的大
背景下，个人的专业知识己不能够满足完成复杂工作对知识的需要，在此趋势下
知识型项目团队成为一种必然。 知识性项目团队作为本文的研究对象，在知识创造方面具有很强的代表性。
国内知识创造理论的研究受到野中郁次郎的知识创造螺旋理论影响最大，SECI模
型被广泛接受的同时，也接受着各种质疑。本文基于野中郁次郎SECI知识螺旋和
Ba的理论，结合课题组的实践探索，对知识创造过程的知识流动和Ba进行分解分
析。知识型项目团队中的知识流动可以分为团队内部和专家研讨的两个层次，分
析这两个层次中的知识流动，进而得出知识型项目团队的知识创造过程。认为知
识创造是在最适宜的Ba里，通过隐性知识和显性知识的相互转化，以达到知识的
最大化，最终得到新知识的过程。 国家软科学研究计划项目“国家中长期科学技术发展规划实施的阶段性策略、
部署及方法研究”项目专门设计了一个为规划阶段实施服务探索知识管理与知识
创新方法的子课题。本文以该项目研究过程中对知识创造的过程和方法的探索为
基础，作为本文的知识型项目团队知识创造模型的实证研究对象。最后对文章进
行了总结和展望，本文主要结合科研团队的实践研究展开，在企业知识创造方面
还有待进一步实践和补充。
关键词：知识型项目团
正在加载中，请稍后...2 价值流程图 非常好的材料_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
文档贡献者
评价文档：
2 价值流程图 非常好的材料
大小：1.76MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢