SOA专场1.docx

SOA专场1.docx

《SOA专场1.docx》由会员分享，可在线阅读，更多相关《SOA专场1.docx（86页珍藏版）》请在冰豆网上搜索。

SOA专场1

◆SOA治理：

如何迎接SOA，第1部分:

企业、IT和SOA治理简介

随着社会的快速发展，政府必须对它的IT系统进行现代化改造。

空中交通量在未来20年会增加一倍甚至是两倍，各州的退休人员数量会增加一倍，基础设施会迅速增加，人口也会急剧增加。

在如此大的压力之下，现有的系统肯定不堪重负，如果不采取措施，一定会出现许多问题。

一些政府机构已经把面向服务体系结构（SOA）当作解决这个难题的最有效的方法。

但是，转移到SOA需要克服一些困难。

因此，一个政府机构请求IBM与这个机构的其他伙伴协作编写一份白皮书，解释如何克服这些困难。

本文向这个机构和各个行业提供这方面的信息。

简介

本文分为三个部分：

∙第1部分——介绍治理的一般概念并讨论企业、IT和SOA治理

∙第2部分——讨论治理生命周期以及如何组织SOA和SOA治理

∙第3部分——讨论治理成熟度、工具、生命力和成功模式

需要通过治理过程进行必要的检查和权衡以确保成功

可以把SOA治理看作IT治理的延伸，因为它主要关注业务服务战略和服务（单一服务和服务网络）的生命周期管理，目的是确保它们对企业的业务价值。

转移到SOA对于企业来说是一个重大的挑战。

除了引入新的技术和职责之外，SOA还要求改变原来基于应用程序的思维方式，要求以整个企业范围的视角考虑各种问题，包括如何实现工作流以及如何开发、部署和管理服务和服务组合，从而实现企业的业务目标。

SOA治理肯定应该包括实施、控制和管辖，但是它还需要更多元素。

因为SOA的主要目标是识别、开发、部署和管理服务（和服务组合），所以SOA治理不能是生硬专制的，必须成为协作性的活动，需要集中的IT管理和内部相关社区（COI）的积极参与（如果需要的话，还包括外部人员）。

相关社区参与SOA治理过程的重要性是怎么强调也不过分的。

SOA的许多好处都源于共享服务以及共享信息、最佳实践体系结构及业务过程和目标。

因此，应该考虑尽早采用联合的SOA治理模型。

这应该包括及早建立核心SOA团队或SOACenterofExcellence（COE），它的作用是与ProgramOffice协作，分享需求、服务和资源。

在半自治的相互联系的业务单位之间进行协作往往很困难。

为了克服这种制度上的天然阻碍，SOA治理最初可以是非正式的，甚至可以是不规律的，但是随着时间推移，它应该越来越正式，应该以标准、最佳实践和企业协调一致作为最终目标。

当然，实现这种协作过程的关键因素是管理层的大力支持。

如果没有管理层的支持和企业相关社区的参与，SOA的潜在优势很难实现。

治理简介

良好的治理是完全“透明的”——这确保活动涉及的每个人都清楚地理解自己的角色和责任、别的团队成员对他们的期望以及他们应该如何为总目标做出贡献。

在本节中，我们讨论治理的重要性，定义SOA治理以及它与企业和IT治理的关系。

为什么要治理

治理的一种定义是“用来控制工作方式的规则、实践、角色、责任和协议集（包括正式和非正式的）”。

换句话说，对于每个活动，需要定义以下方面：

∙需要做什么

∙应该如何做

∙应该由谁做

∙应该如何度量

以上定义中的关键是“控制工作方式”。

控制的程度可能差异很大，从非常宽松的非强制性控制（指导）到非常严谨的强制性控制（管辖）都可以。

治理本身并不等同于管理。

治理决定谁有权力做出决策。

管理是做出决策和实现决策的过程。

如果我们考虑标准IT项目的这四个方面（什么、如何、谁和度量），就会发现不一定总是定义了这些功能性属性。

实现信息技术（IT）功能的业务原因是为业务操作提供敏捷性。

但是，IT实现总是面对业务过程本身速度慢且不敏捷的难题。

因此，IT项目往往倾向于忽略关注点以及取消和绕过重要的步骤。

在许多时候，IT项目的“什么”方面（功能性和非功能性需求）并不完整，这取决于IT人员/部门在应该创建什么方面的“想像”。

“如何”通常受到个人风格和喜好的影响。

“谁”取决于可用的人员。

项目结果的度量常常被省略，因为开发团队转到下一个项目了。

因此，尽管IT治理会取得一些成果，但是在通过SOA迁移到服务方式时我们仍然要面对很大的困难。

转移到SOA对于任何组织来说都是一个重大的挑战，尤其是因为：

SOA引入新的技术、角色和责任；SOA需要新的思维方式，要求采用整个企业范围的视角，而不是只关注某一部门或某一业务线（LOB）领域。

如果不在整个企业范围内对服务实施严格的开发、部署和操作管理，SOA的潜在好处就可能无法实现。

过去的SOA项目的教训表明，仅仅增加服务而没有治理策略是无法实现面向服务体系结构的。

缺少治理策略就无法避免在软件开发过程中出现不一致、缝隙和重叠，这会增加重用和业务敏捷的难度（甚至不可能实现），从而导致组织难以实现面向服务的潜在好处。

因此，如果没有治理，SOA迁移很可能会失败。

在任何组织中成功地实现SOA会对人员、过程和技术提出新的要求，必须通过合理有效的治理来解决这些问题。

如果没有治理，业务敏捷性是不可能实现的，服务仍然封锁在组织壁垒中，服务组合管理仍然是分散低效的，安全措施仍然是孤立的，无法实现更全面的企业范围的视图。

企业、IT和SOA治理

SOA治理对IT系统中的业务服务的生命周期进行治理，从而扩展IT治理，使IT更符合业务的需要。

部署SOA应该成为一种催化剂，促使组织开始考虑如何改进企业和IT治理以及如何更好地实现SOA治理实践。

采用SOA会在IT决策权力、度量和控制方面出现新的问题。

随着企业越来越关注面向服务，SOA治理会逐渐扩展IT治理。

SOA提供一种独特的企业级方法，帮助设计和交付各种功能性服务，让业务和IT部门更能满足企业战略和目标的要求。

这种SOA治理需要使用业务策略，包括企业级和部门级策略，这些策略提供上面提到的规则。

建立SOA治理应该还被看作在企业和IT治理之间建立桥梁的机会。

SOA治理会受益于现有的IT和企业治理。

但是，即使现在没有IT和企业治理或没有“实施”IT和企业治理实践，企业仍然可以建立SOA治理。

在许多情况下，SOA治理的需要会促使企业重新检查和调整IT和企业治理。

图1.企业、IT和SOA治理

企业、IT和SOA治理之间的关系随时间变化的方式见上面的图1。

最初，SOA治理涉及的范围有限，主要关注IT和业务部门都关心的相当有限的领域。

随着SOA成熟度的增加，SOA治理的范围会显著扩大。

业务和IT部门应该逐渐增加共同关注的领域，最终SOA治理与IT治理合并在一起，IT治理本身成为企业总体治理方法的一部分。

一般来说，企业级治理要为企业运营业务确定规则和方式。

企业治理包括根据业务方针建立遵从性目标和市场战略。

因为IT是水平的，而且世界各地的企业广泛依赖于IT，所以IT治理是企业治理的重要组成部分。

企业中几乎所有人都使用IT资产来完成他们的责任，所有持久性信息都存储在IT系统中，所以有效的IT治理的影响非常显著。

SOA治理通常会要求IT治理产生变化，从而适当地管理面向服务概念和原则，确保组织能够实现预定的SOA业务目标。

另外，SOA治理会促使业务和IT部门更好地协作，从而提高投资回报和业务敏捷性，实现更大的业务价值。

这需要把业务需求和业务服务实例关联起来。

如果严谨地构造这种关联，就可以实现更好的风险管理并提高IT系统实现的所有阶段的可预测性。

因为SOA是一种分布式体系结构，可能跨越多个业务线领域（包括内部和外部）以及IT领域，所以更需要有效的SOA治理。

另外，SOA治理为服务的重用和共享提供一个框架，重用和共享是SOA的关键价值。

IT治理

IT治理可以定义为：

∙建立和实现与IT相关的决策权力。

∙建立对IT决策的制定和实施方式进行控制和度量所用的机制和策略。

IT治理最重要的方面之一是体系结构治理。

体系结构治理

通过实施体系结构治理在整个企业范围控制体系结构。

企业体系结构（EA）在治理中扮演重要角色，EA方针定义和维护体系结构模型、治理和迁移活动，从而有效地促使半自治的单位向统一的业务和/或IT目标迈进。

SOA治理

∙业务服务战略

∙服务的生命周期，确保SOA的业务价值

∙启用服务方法

∙调整企业和IT治理，帮助实现业务目标

SOA治理常常是改进IT治理的催化剂，在依赖于遗留的IT基础设施的大型组织中尤其如此。

治理模型的机制

SOA治理确保业务和IT之间的成功协作。

它确定共同认可的策略和标准。

这些策略和标准指导由过程实现的受治理过程，而受治理过程是通过治理过程管理和监控的。

图2包含遵从性（Compliance）、交流（Communication）、生命力（Vitality）和异常情况/请求（Exceptions/Appeals）。

这些是治理中最重要的机制。

下面分别讨论它们。

图2.治理的机制

遵从性

受治理的过程由策略和标准控制。

定义策略和确定标准对于实现治理最佳实践非常重要。

但是，如果没有遵从性，策略和标准就不能实现其价值。

因此，控制点、策略决策点和策略实施点等概念是治理的基本部分。

2.4节专门讨论这方面的策略和策略管理。

交流

明确的交流对于治理很重要。

企业内部以及企业与合作伙伴、供应商和客户之间都需要交流。

交流的目标是在适当的时间把适当的消息交付给适当的人员。

交流是帮助人员顺利地通过任何需要感知、理解、提交和采纳的过程的各个阶段的关键因素。

通过使用基于XML的消息传递等开放标准和Web服务通信框架，可以转变业务消息传递方式。

异常情况和请求

治理不应该是一组没有任何灵活性的静态过程。

在治理生命周期中，可以根据异常情况的需要请求建立或废止治理过程。

在管理和监视策略和标准的遵从性时，如果发现不可能实现遵从性（包括临时或永久）的情况，就需要请求建立或废止治理过程。

请求建立或废止治理过程是一个非常敏感的主题，因为治理过程一方面必须足够灵活，能够应对这些异常情况，另一方面又必须足够严格，能够防止不必要的异常情况破坏秩序。

生命力

随着时间的推移，情况会发生变化，治理过程必须能够适应变化。

这种能力就称为生命力。

本文后面的一节专门讨论治理的生命力。

治理策略和策略管理

业务过程管理（BPM）通过识别、定义和创建服务操作来帮助创建服务。

企业必须遵守许多法律和法规，这是实施治理的关键原因之一。

这些服务操作应该映射到设计时和运行时业务过程，应该根据服务质量（QoS）参数建立关键绩效指标，用这些指标衡量操作的绩效，从而满足服务水平协议的要求。

策略管理提供一种机制，根据企业制定的策略或规则分配IT资源。

策略指定数据质量、完整性和持久性需求。

策略规则可以采用“如果，那么”条件陈述的形式，也就是说，在某一条件下应该采取某些措施。

应用程序必须能够将其正式程序策略构建到过程中，然后在系统和工具中实现并执行这些过程。

包含策略的系统要建立策略决策点（PDP），在这些点上定义事件并做出决策。

PDP可以支持各种条件并相应地做出反应。

PDP与策略实施点（PEP）保持同步，PEP监视事件并在PDP的上下文中执行策略。

InternetEngineeringTaskForce（IETF）已经定义了相关标准，包括确定策略决策点的位置、启用分散的企业支持结构以及集成为更高级的策略管理系统。

策略实施点位于网络和IT基础设施中，用来监视事件。

提供适当的IT治理和全面的访问控制需要使用许多工具。

每个应用程序都必须支持自己的基础设施；但是，面向服务体系结构的关键是，能够敏捷地把数据传输给新的相关社区。

启用策略实施功能需要使用web服务管理工具，包括服务注册、存储库和元数据目录、资产跟踪和故障/绩效监视。

ITInfrastructureLibrary（ITIL）标准定义一个配置管理数据库（CMDB），其中存储需要跟踪的数据元素。

需要使用IT工具收集和报告许多数据事务的信息，跟踪用户和关键绩效指标，然后向适当的应用程序正确地报告这些信息。

下面是一些策略示例：

∙策略可能首先出现在业务级：

-项目必须符合内部体系结构方针

-所有IT项目都必须进行安全性和法律遵从性策略检查

∙策略可以针对更特定的法律遵从性问题：

-病人个人可识别信息必须以安全的方式传输和存储（HIPPA）

-所有金融交易必须为强制审计记录提供可跟踪性和防篡改机制（SarbanesOxley）

∙项目外包活动可能有自己的策略：

-外包公司必须提供与内部开发的服务相同的服务生命周期。

∙比较高层的策略常常需要转换为技术性策略，让策略实施工具可以有效地实施它们。

∙信息安全性策略示例：

-消息必须包含授权令牌

-密码元素的长度必须至少是6个字符，并且同时包含数字和字母

-必须惟一地标识每个操作消息并进行数字签名

∙为了确保互操作性和可重用性，还有一些与设计相关的技术性策略：

-不要使用RPC编码风格的web服务

-不要使用Solicit-Response风格的web服务操作

-不要使用XML‘anyAttribute’通配符

∙在SOA战略和规划过程中，每个组织都应该考虑为SOA程序和SOA服务开发生命周期建立一套标准和策略。

下面是一些服务策略示例。

∙服务规格说明应该包含：

-对每个服务操作执行的功能的描述

-每个服务操作的输入/输出消息格式和示例数据

-ComponentBusinessModel（CBM）中相应任务的定义

∙服务规格说明不应该包含：

-关于服务实现方式的任何信息（只要保持服务接口不变，服务提供者可以随时修改服务的实现，例如在淘汰陈旧的IT系统时）

-关于应该以什么次序执行操作的任何说明。

每个操作调用应该被视为独立的任务，任务的次序应该作为业务过程/自动化业务过程在另一个文档中定义

治理标准

标准是控制服务生命周期的规则或需求。

受治理的服务必须符合标准。

标准很少发生变化，违反标准是不允许的，或者需要通过显式的异常情况来处理。

在组织决定部署web服务时，可以考虑采用下表中的标准：

表1.Web服务标准

功能

推荐标准

替代标准

服务组合

BPEL

WS-Choreography

WS-CDL

管理

WS-DistributedManagement

WS-Provisioning

WS-Management

安全性

WS-Security

WS-Trust

WS-Federation

WS-SecureConversation

WS-SecurityPolicy

事务

WS-Transaction

WS-Coordination

WS-CompositeApplicationFramework（WS-CAF）

WS-Context（WS-Ctx）

WS-CoordinationFramework（WS-CF）

可靠性

WS-ReliableMessaging

WS-Reliability

描述

WSDL

UDDI

WS-Inspection

Disco

WS-Discovery

WS-PolicyFramework

WS-MetaDataExchange

消息传递

XML

SOAP

WS-Addressing

WS-Notification

WS-ResourceFramework

WS-Eventing

WS-Policy

SOAPwithAttachment

传输

HTTP

JMS

RMI-IIOP

TCP

UDP

Jabber

SMTP

互操作性

WS-IBasicProfile

SOA借用了网络管理和IT基础设施管理等其他信息技术领域的一些概念，比如策略、服务水平协议和服务质量。

因为目前还没有与SOA策略管理和策略相关的标准，强烈建议参考IETF（InternetEngineeringTaskForce）和ITIL（InformationTechnologyInfrastructureLibrary）定义的标准。

第2部分——讨论治理生命周期以及如何组织SOA和SOA治理

服务生命周期和治理

服务是面向服务体系结构的核心。

因此，SOA治理特别关注服务的治理。

在本节中，我们定义服务的生命周期并讨论建立治理的基本任务。

服务生命周期概述

所有服务都会经历一系列阶段：

首先是形成最初的概念，然后依次经过分析、设计、开发、测试、部署和最终的退役，见图1：

图1.服务生命周期状态图

这实际上是一个状态转换图，其中定义了所有有效状态，为了从一个状态转移到下一个状态，必须执行特定的活动。

与所有模型一样，这是实际情况的简化视图：

例如，没有“正在开发”这样的中间状态，因为这种状态的定义是主观的，意义不明确。

但是，这个开发模型很好地定义了SOA开发过程：

∙可以明确地定义导致状态转换的每个活动，然后把活动分配给具备适当技能的人员或团队反复执行，这样就可以保持一致性。

∙因为明确地定义了稳定状态，所以可以通过质量保证（QA）检查（有时候称为‘控制门’或‘控制点’）判断每个活动的执行质量是否足够好，从而确保可靠地迁移到目标状态。

∙因为活动是可重复的，所以对于需要部署大量服务的IT解决方案，可以预测和监视开发工作量。

服务生命周期的主要阶段包括：

∙识别——识别最初的需要并指定需求

∙规格说明——捕捉详细的需求和高层设计

∙实现——构造和部署服务

∙操作——在服务的生命期内管理服务，直到服务最终修订或退役

一定要注意，不能把所有东西都变成服务，而且不能（也不应该）公开所有服务。

在SOA生命周期治理过程中，需要对候选服务进行资格测试，测试的结果可以建立一套确定服务质量的条件。

这个测试包含以下问题：

这个服务是可重用的吗？

它会有多少用户？

这个服务符合企业的目标吗？

等等。

选择了候选服务之后，下一步是决定是否应该公开它。

公开一个服务意味着让其他人能够以明确的方式（比如通过注册表）使用这个服务。

决定不公开服务有许多原因。

例如，基础设施服务可能不需要在整个企业范围内可用，所以不应该公开；或者，安全限制和策略可能要求企业只向一部分用户公开服务。

服务生命周期与软件/系统开发方法（SDM）大体一致，比如快速应用程序开发（RAD）、RationalUnifiedProcess®（RUP®）、迭代式开发、螺旋式开发和敏捷开发方法。

例如，RationalUnifiedProcess®（RUP®）由以下四个阶段组成：

∙发起

∙细化

∙构造

∙转换

实际上，对于每个服务，都要经历这些阶段。

但是，阶段不完全一致，服务生命周期的操作阶段在某种程度上超越了RUP转换阶段的范围。

图2.RUP阶段

下图详细说明服务生命周期。

橙色的框是与QA相关的步骤，用来确保对SOA开发过程进行有效的治理。

橙色的框可以被看作策略实施点（PEP）。

例如，一个策略规定接收测试必须有95%的成功率，才能把服务向整个企业范围公开。

另外请注意，图3底部显示的活动不属于SDM，这意味着需要扩展当前的方法。

图3.详细的服务生命周期（ComponentBusinessModel（CBM），服务水平协议（SLA））

启动SOA治理

为了实施SOA治理，需要考虑几个基本任务。

任务：

定义SOACenterofExcellence（CoE）的章程

Wikipedia（http:

//www.wikipedia.org/）把CenterofExcellence（CoE）或CenterofCompetence定义为“正式指定和非正式认可的关于某一主题领域的知识和经验团体。

在这里为某一活动领域制定最高标准”。

SOACoE由人员、过程、技术和服务组成，它领导服务在企业中的实现过程。

从根本上说，SOACoE的主要任务是更改管理。

参加CoE的每个人（从领导CoE的执行官到设计、开发和测试服务的专业人员）都必须肩负起这一任务。

SOACoE的目标应该是让服务成为关键的企业资产，因此应该：

∙为与SOA相关的计划和实现建立一个跨组织跨功能的权威机构，通过它领导SOA计划和执行

∙培养专家级的SOA技能，从而掌握最佳实践、技术、标准和与SOA相关的方法

∙针对即将进行的SOA迁移，对组织模型和治理模型提供建议和帮助

∙在CoE的生命期内实现预期的面向服务成熟度目标

∙设计用于管理服务的基础设施改进，涉及的领域包括安全性、监视、性能、版本化和共享使用

∙改进IT过程，从而促进服务的共享和重用以及服务的识别、设计和规格说明，包括解决相关的出资、共享和激励问题

∙帮助计划培养SOA技能所需的教育和培训

∙广泛传播IT部门发展SOA能力的战略意图，使SOA成为整个组织的核心战略能力，为组织提供长期的竞争优势

任务：

识别支持SOA所需的角色和责任

与任何迁移过程一样，迁移到SOA也会带来新的挑战。

成功地采用面向服务方法需要改变组织角色和责任。

组织必须花费时间和精力创建适当的组织和支持结构，从而支持顺利地采用SOA原则。

第一步是建立一个主要关注SOA的CenterofExcellence（CoE）。

我们将用单独的一节详细讨论CoE。

现在只需要指出SOA会引入新的角色和责任，比如服务注册员和服务架构师。

任务：

定义服务所有权和开发出资模型

为了确保顺利地采用SOA，需要明确地理解和宣传出资和所有权模型。

出资模型应该鼓励共享、重用、高效的集成和简单化。

如果没有明确的服务所有权和出资模型，服务仍然会像目前的应用程序和产品系列一样被隔离在组织壁垒中。

请考虑希望跨多个业务线统一用户体验的示例：

在最优的SOA解决方案中，我们创建一组共享的服务，它们跨所有业务线提供统一的用户体验，包括提供统一的数据访问的服务。

但是，创建这样的服务并不仅仅是技术问题。

业务线需要回答以下问题：

∙谁拥有这些数据？

他们是否允许服务访问数据？

∙如何授予访问获得的数据的权限？

∙谁应该为共享的服务提供资金？

谁拥有它，或谁为它的开发出资？

∙如果服务出现问题，谁负责修复它？

∙企业如何鼓励各个业务线重用企业资产和共享业务服务？

∙由谁决定服务是否向其他应用程序公开？

如果服务的潜在用户对它的内容不满意，应该怎么办？

建立明确的服务所有权和出资模型有助于一致且高效地解决这些问题。

尤其是，必须特别关注用户未来的数据访问需求。

任务：

识别成功因素、促进因素和重用激励因素

在考虑SOA和服务重用的成功因素和激励因素之前，一定要了解共享服务模型和重用的传统挑战和局限性。

∙缺少公认的标准、厂商产品/平台互操作性

∙跨域服务、服务发现和服务可见性的语义

∙共享服务模