《SOA基础知识.docx》由会员分享，可在线阅读，更多相关《SOA基础知识.docx（32页珍藏版）》请在三一办公上搜索。
1、SOA基础知识SOA 基础知识简介 SOA 简介 如果您接触 SOA 不久，则可能会希望在开始本教程前了解本部分给出的一些基本信息的简介。 SOA 是一种体系架构方法，用于定义、链接和集成具有清晰边界且功能方面自包含的可重用业务服务。在这种类型的体系架构中，您可以对业务流程中的业务服务进行协 调。通过采用服务的概念，SOA 将 IT 提升到了一个新的级别，更为适合互操作性和异类环境。 因为 SOA 构建于主要 IT 提供商认可和支持的标准之上，因此可以快速构建服务和进行互连。可以在不考虑所支持的基础设施的情况下在企业间进行互连，从而为委托、共享、重用现有资产并实现其好处的最大化打开方便之门。
2、通过建立 SOA，可以将内部 IT 基础设施提高到一个更高、可见性更好且可管理的级别。通过可重用服务和高级流程，能以比以往任何时候都方便的方式进行更改，而且更像是分解部件并 将其重新组合为新的与业务一致的流程。这不仅提高了效率和重用，而且还提供了极强的更改和保持 IT 与业务一致的能力。 SOA 的价值 那么，为什么大家对 SOA 的出现如此兴奋呢？它提供了什么，能够有什么帮助？是否所有情况都应该使用？接下来让我们逐一回答这些问题。 SOA 最适合什么？ 您可能会想，SOA 最适合哪些业务功能和情况，以及何种情况最能体现出其潜能？某些情况和业务功能应该立即使用 SOA，因为 SOA 可以提高竞
3、争力和效率，清楚地体现出其价值。此类情况主要包括： 多个实体使用的集中业务功能：SOA 可帮助标识此类功能，并将其打包为可重用的自包含服务，不会受到相关流程更改的影响。 与合作伙伴集成：SOA 可推动标准的使用，而这在任何集成中都至关重要，因为标准为所有各方创建了共有的工作基准。另外，SOA 能提供出色的敏捷性，能够通过 SOA 的分离功能以对客户几乎无缝的方式灵活地插入、更改或更新服务，从而能增强集成体验。 存在仍然在使用的旧技术：有些组织可能不愿意放弃行之有效的技术。安全顾虑让有些客户对新软件系统及其未知漏洞持怀疑态度。在这种情况下，SOA 可以帮助使用标准方式打包遗留技术，以便在适合进行
4、集成和重用的基于标准的环境中使用。 什么因素促成了 SOA 最受欢迎的功能：业务敏捷性支持？ 因为更改是不可避免的，业务连续性的唯一保证就是预计更改并加以适应，也称为业务敏捷性。对于任何企业的未来都至关重要的是，SOA 通过以下方面让业务敏捷性成为可能。 松散耦合 支持实时业务功能，因为其中消除了阻碍变更能力的硬连接 改变 IT 成本分布方式，在实现上面更为廉价，更多的投资可进行重用 提高对信息源的实时远程访问的可行性，从而减少延迟和依赖关系 集成项目是由业务需求驱动，并具有所提供功能的可见性 通过公开和共享信息让公司获得更高的实时数据测定性能 缩短上市时间 合作伙伴可以更快地与您的公司开展业
5、务 推广和公开您的服务，更便于客户查找您和您的服务 通过搜索最适合您的需求的服务，更便于查找新的合作伙伴和服务 重用 提高流程一致性 通过服务提供者间的竞争促进质量的提高 为客户提供广泛的提供商选择 几乎涵盖所有 IT 资产类：硬件、软件、数据和流程资产 减少更改的影响 让您专注于业务流程，而不用太多考虑技术实现 帮助减少集成的成本 让您在不约束业务更改的前提下进行系统更改 提升灵活性，从而获得更多的创新空间 允许一次发布多次使用 可扩展性 让各种规模的组织都能使用 SOA 解决方案 更改软件部署活动到更为动态且更为省时的模型，与业务更为相配 更便于添加或更改合作伙伴 加速合并和收购 方便公开
6、服务，而这就代表着新的收益来源 那么，如果公司不采用 SOA，将失去什么？ 因为对公司而言，SOA 是非常可取的解决方案，不实现此体系架构的代价是，可能会导致在三个方面存在重大落后的情况： 无法进入到提供更多业务增长和曝光机会的高值市场。因为公司受到现有定制系统的束缚，虽然努力想进入高值市场，但始终却在市场原地踏步。不过，通过 SOA，组织可以改变业务战术和支持新的市场策略，从而获得竞争优势。 无法应对与技术更为先进的对手的竞争。 来自成本更低的领域的竞争。 SOA 是否总是较好的解决方案？ SOA 可以为所有业务组织带来好处。不过，在一些非常特殊的情况下，可能会发现 SOA 更多的是一种责任
7、和义务，而不是改善业务的驱动因素。这些情况包括： 同类 IT 环境：如果组织依赖于一组一致的产品、工作范围有限而且不需要添加或更改其中的任何产品，则 SOA 不是一项有用的策略，而可能是一种责任。 真正的实时性能极为重要的情况：为了在不同使用者和提供者之间提供松散耦合，SOA 依赖于可互操作性协议达到此目的，而这在本质上是很缓慢的。其中还可能包括中介逻辑和异步协议，而这些并不适合对实时性能要求较高的情况。 不会发生变化时：如果客户没有发现业务逻辑、表示、数据流、流程或应用程序任何其他方面的变化，将旧系统转换为 SOA 可能不会带来足够的好处让所投入的物有所值。 紧密耦合并不方便时：松散耦合最好
8、与不在您控制之下的组件结合使用。另一方面，如果组件是您的且受您控制，松散耦合可能成为负担，特别在组件不具有实际可重用性的情况下更是如此。 SOA 概念 接下来让我们了解一些 SOA 概念，以便更好地理解什么是 SOA。 SOA 中服务的定义 关于服务，有大量不同的定义，但我认为以下对什么是服务解释得最好。 摘自 Web Services and Service-Oriented Architecture: The Savvy Managers guide： “服务是定义良好、自包含且不依赖于上下文或其他服务的状态的功能。” 摘自 SearchSystemC： “.服务定义为代表某个计算实体执行
9、的工作单元。” SOA 中松散耦合的概念 为了帮助了解 SOA 中松散耦合的概念，您应该首先了解一下常规的松散耦合概念。以下说明了什么是松散耦合以及其为何颇有价值： 如果交互中一方对实体的更改需要其他方进行对应的修改，则实体是耦合的。 如果实体的行为在服务接口中指定，且服务请求者和提供者只能在具有匹配的声明行为时才能进行交互，则该实体是声明的。声明的方面包括安全性、事务行为和服务质量。 如果实体由服务请求者和服务提供者同时声明，但基础设施提供了一些转换功能来支持声明的行为不匹配的服务请求者和提供者间的交互，则该实体是转换的。 如果请求者和提供者都声明了自己能够支持的一系列行为，而对于每个交互，
10、中间层基础设施都能够在二者之间协商一个一致同意的行为，则该实体是协商的。 如果交互中一方对特定方面的更改不需要其他方进行对应的更改，则该实体是分解的。 松散耦合在 SOA 范式中的作用如下： 它帮助在服务提供者和服务使用者之间形成一个抽象层。 松散耦合可提高在不影响服务使用者的情况下更改服务实现的灵活性。 在 SOA 方法中，功能组织为一系列模块化、可重用的共享服务。这些服务具有定义良好的接口，其中封装了用于访问服务的关键规则。这些服务 还是在不假设谁将使用服务的情况下构建的。因此，能够松散耦合到这些服务的使用者。 XML 在 SOA 中作出了什么贡献？ SOA 基于开放标准，能够促进独立于平
11、台的业务集成，但是需要公共平台作为其基础设施的基础。此基础设施需要所涉及的各方的支持，以在认识方面达成一致。由于以下这些原因，XML 是此基础设施的核心： XML 是几乎所有 Web 服务标准的基础，如 XML 模式、SOAP、Web 服务描述语言及统一描述、发现和集成等。这些标准利用了基于 XML 的表示形式的核心概念，此表示形式是受到全球广泛支持的格式，能用于在 SOA 中的服务提供者和请求者之间进行信息交换。 通过使用 XML 解决了跨不同平台使用不同应用程序中不同数据格式的问题。 XML 本质上具有简化表示形式、基于文本、灵活且可扩展的好处。 SOA 使用的构建于 XML 之上的标准包
12、括： SOAP:这是基于 XML 的简单协议，允许应用程序通过 HTTP 等传输协议交换信息。在 SOAP 中使用 XML 保证了 SOAP 协议以下方面的特征： o 独立于平台。 o 可在 Internet 上使用。 o 能人工读取，具有结构化特征，且基于文本。 由于具有上述好处，SOAP 是推荐使用的 Web 服务通信协议，使用最为广泛。由于 Web 服务是 SOA 的基础，因此这个协议也是 SOA 解决方案的基本通信协议。 WSDL：WSDL 是以 XML 格式编写的用于描述 Web 服务的文档。它指定服务的位置和服务向访问此服务的个体公开的操作。WSDL 文件描述四个主要事项： o W
13、eb 服务接口提供的服务，如方法的列表名称和属性消息。 o 消息的数据类型 o 传输协议的绑定信息 o 调用时使用的服务地址 使用可扩展标记语言的电子商务：ebXML 是定义企业间执行的业务事务的标准方式。ebXML 定义了业务消息交换的标准方法，建立了公司间的贸易通信和注册业务流程。 服务注册中心 服务注册中心是 SOA 系统中可用的服务的目录。其中包含服务的物理位置、版本及服务有效期、服务文档和策略。服务注册中心是 SOA 体系架构的主要构建块之一。下面对其扮演的角色进行了介绍： 服务注册中心实现 SOA 的松散耦合承诺。通过保存服务端点位置，消除了在使用者和提供者之间进行硬编码所带来的高
14、度耦合。另外还消除了在需要的情况下替换服务实现的潜在难题。 服务注册中心具有很高的可伸缩性，可以在系统服务逐步发展的情况下无缝地提升。 它允许系统分析人员对企业的业务服务投资组合进行调查。他们可以随后确定哪些服务可用于实现流程自动化来应对迫切的业务需求，哪些服务不能用于此目的，从而让您知道需要在投资组合中实现和添加什么，并会提供可用服务目录。 服务注册中心可以通过强制遵从订阅服务来逐步过渡到治理服务的角色。这可帮助确保服务治理和策略的完整性。在本教程稍后，您将了解关于治理及其在 SOA 中的重要性。 可用服务及其接口的可见性可加快开发速度、提高应用程序重用、改善治理和改进业务规划及管理。没有服
15、务注册中心会导致冗余和效率低下。 服务注册中心可帮助减少在定位服务信息方面浪费的时间。 如果不使用注册中心来跟踪服务及其关系，SOA 环境不仅会缺少一致性和控制，还会出现混乱。 什么是业务流程？ 业务流程 是在此环境中经常听到的一个术语。以下是业务流程的两个定义： 摘自“Business processes and workflow in the Web services world”： “业务流程可以定义为链接到跨功能边界的活动的一组相互关联的任务。业务流程具有起点和终点，是可重复的。” 另一个定义是：业务流程可以视为业务实体为了响应事件而执行的一组活动。这一组活动在业务流程中彼此协调，一起
16、描述并集成到一起。 为个人发放身份证就是一个业务流程。您提供您的出生证明、教育和专业证书及一张照片来启动流程。然后将创建内部文件，对您进行安全调查，最后，完成了所有处理后，就拿到了身份证了。 在 SOA 范式中，业务流程对服务流进行控制。业务流程驱动事件流，调用和协调服务，并为其创建上下文来进行相互通信。业务流程代表业务抽象，同服务实现进行了分 离，是关于业务流的流程。通过这个关注分离，不仅可以将更多精力放在流程创建上，而且还可以更方便地根据需要编辑流程，但不用对基础服务实现进行编辑。 业务流程的组成元素 从组成元素的角度定义业务流程的做法可能相对更好一些，这样能从技术角度对业务流程有一些了解
17、。 输入：流程的活动为了产生结果所需的信息。在身份证示例中，输入应该为您的凭据、出生证明和照片。 输出：流程生成的所有数据和信息。输出代表业务目标和业务所需的度量数据。在身份证示例中，输出是您的内部文件和实际身份证以及关于流程如何进行的度量数据。 事件：一些重要情况的通知。例如，某个指示信息。事件可能在流程的执行前、执行中和执行后发生。在身份证示例中，可能会出现关于最开始没有提供需要包括的新文档的事件。 子流程：流程中较小的流程或流程步骤。使用一组活动不足以表示工作范围时，将使用子流程。子流程具有与流程相同的组成元素。在身份证示例中，这可以为调查犯罪记录并获得结果的子流程。 活动：流程中级别最
18、低的工作单位。在身份证示例中，为申办身份证的人创建新内部文件的工作就是一个活动。 性能度量：表示流程有效性的属性，用于确定是否满足所需的性能。这些度量可以帮助确定性能并将其与所需的指标进行比较。通过这些性 能度量还能确定流程改进的潜在区域，最终实现 SOA 承诺的改进周期。在身份证示例中，度量数据中将计算流程的哪个部分使用的时间最多或处理命中率最高。这可以在以后帮助改进流程。 SOA 如何处理事务控制？ 因为流程跨多个活动，因此 SOA 环境中出现的业务事务可能会非常复杂。这是由于 SOA 上下文中长时间运行的流程中的服务的本质所决定的，此类服务通常具有异步、无状态、分布式和不透明的特点。 W
19、eb 服务是 SOA 环境中最完美的服务表示形式。Web 服务具有 SOA 所需的自包含特性，但在涉及跨服务事务需求时就有些局限了。只要服务位于事务的根部，且事务的范围受到服务的基础解决方案逻辑所执行的活动的限制，就不需 要跨服务事务功能，而且事务可以通过封装的任何专有技术进行管理。但随着环境中服务数量的增加，对跨这些服务的事 务的需求就会增加。 一些 Web 服务规范被用来处理事务的问题。这包括： WS-Coordination：允许注册流程参与活动，以创建共享上下文，负责保存流程间传播的有状态数据和信息以及事务状态。 此框架允许现有事务处理、工作流和其他要协调的系统隐藏其专用协议，从而在异
20、类环境中协同工作。此协议为使用其框架的其他协议提供基础设施。 WS-AtomicTransaction：用于短期存在的分布式活动。它提供了可与 WS-Coordination 框架结合使用的三种类型的协议，供两阶段提交 ACID 类型选择使用： o 完成 o 易失两阶段提交 o 持久两阶段提交 WS-BusinessActivity：此协议用于长时间运行的带有补偿流程的事务。对于 WS-AtomicTransaction 协议，它使用 WS-Coordination 框架提供用于业务活动协调的两个协议： o BusinessAgreementWithParticipantCompletion
21、o BusinessAgreementWithCoordinatorCompletion 标准在 SOA 中扮演什么角色？ 通常，SOA 项目与标准非常相关，因为标准能带来以下好处，所以在其中对标准进行了充分利用： 标准能确保跨系统和合作伙伴的互操作性。 使用标准提高通过流程和工具进行的开发和交付。 通过标准能更好地管理 IT 资产和提高其可见性。 标准能确保服务质量。 标准能通过减少对特定实现的依赖性提供灵活性。 接下来我们将给出一些 SOA 所利用的标准示例，了解标准如何帮助实现 SOA 的承诺。 WS-Security WS-Security 协议基于向消息 Header 添加 SOAP
22、 扩展来存储安全元数据，此类元数据旨在用于通过消息完整性、保密性和身份验证提供保护。这些扩展提供了用于将安全令牌与消息关联的通用机制，从而替代了固 定的安全机制。通用平台支持不同的安全机制。此协议设计为可扩展协议。 BPEL4WS 用于 Web 服务的业务流程执行语言在 BPEL 的 OASIS 在线社区中定义如下： “此协议定义了用于基于流程及其合作伙伴间的交互描述业务流程的行为的模型和语法。它还定义与合作伙伴的多个服务交互如何协调来实现业务目标，以及此协调所必要的状态和逻辑。” 由于有明确的需求，BPEL4WS 引入了处理业务异常和错误的方法，还引入了用于补偿可能需要在出现错误的情况下反转
23、的其他已提交流程的方式。因为 BPEL 需要通用支持，因此该协议以广泛认可的 WSDL 协议为基础，而 WSDL 本身又是基于 XML 的。 WS-I 正如 WS-I 网站中所述： “Web 服务互操作性组织是一个开放行业组织，其宗旨是为所选的 Web 服务标准组建立跨平台、操作系统和编程语言的 Web 服务互操作性最佳实践。” 这个组织关注不同实现、平台及其实际互操作性方面的 Web 服务标准开发。其主要目标是就如何在使用 Web 服务对系统互连的时候确保互操作性提供指导和建议。 WS-I 具有四个主要的可交付内容： 概要，即描述可互操作且作为集合工作的 Web 服务的实现指导原则和最佳实践
24、的具有版本控制的规范 用于演示概要中的指导原则的用例和使用场景 示例应用程序 概要遵从性测试工具 基本 SOA 体系架构 接下来让我们了解一些更为复杂的技术主题，如企业服务总线的角色、业务流程、其编排及 Web 服务的角色。 基本 SOA 体系架构由哪些部分组成？ 基本 SOA 体系架构包括服务提供者、服务和可选的服务目录。应用程序到应用程序的消息传递在信息交换中使用。 这个模型和简单 Web 服务之间的相似性非常明显，二者都将 WSDL 作为存储在服务目录中的调用契约。Web 服务实际上是最基本的 SOA 实现。 在此模型中，基本场景如下：首先，服务提供者创建服务，并决定将其公开并发布。发布
25、是通过将服务信息发布到服务目录上来完成的。另一方面，需要特定 服务的服务请求者将在服务目录中搜索满足必要条件的服务。找到服务后，通过使用服务目录中的可用信息，服务请求者能够以正确的方式直接联系服务提供者，从 而满足业务需求。 图 1. 基本 SOA 体系架构 以下是此部分中使用的一些术语的定义： 服务提供者：发布了调用契约和位置的服务的提供者 服务使用者：服务目录中找到的与其业务需求匹配的服务的使用者 服务目录：用于发布服务和为使用者列出可用服务的目录。 ESB 在 SOA 中扮演什么角色？ ESB 在 SOA 中扮演着重要的角色。从基础的角度而言，它代表着能够连接服务提供者和服务使用者的中枢
26、和基础架构。 以下是 ESB 的角色的详细介绍： 提供与 SOA 原则一致的集成基础设施： o 强制使用独立于实现的显式接口来定义采用松散耦合的服务 o 使用强调位置透明性和互操作性的通信协议 o 促进采用封装可重用业务功能的方式定义服务 提供管理服务基础设施的方法 在分布式异类环境中操作，因为它： o 支持同步和异步通信 o 使用标准接口和标准协议 集中控制和分散处理 支持中介，根据需要在不同各方之间形成请求/响应，而且不用更改其中任何一方 将安全性和 QoS 应用到 SOA 项目 Web 服务在 SOA 中扮演什么角色？ 尽管 Web 服务的出现早于 SOA，但它代表了寻求系统和平台之间的
27、互操作性需求的 SOA 问题的答案和实现。因为已经有了支持技术来满足需求，所以能帮助快速建立 SOA 并运行。显然 Web 服务代表着 SOA 的基础及建议的互操作性技术。 Web 服务之所以是 SOA 的基础，是因为 Web 服务： 采用标准，从而提高了兼容性和可移植性。 跨平台、跨语言。 受到广泛的支持，让 SOA 的采用过程相对简单。 面向消息。 提供更快的工具支持，从而加快了 SOA 实现。 什么是编排？它如何适应 SOA 大方略？ 业务服务编排考虑的是业务流逻辑的开发和执行，与基础服务和业务逻辑相独立。这意味着，流程编排考虑的是事件的顺序，以及事件如何相关，但并不关心 事件本身。流程
28、和服务之间的关注分离提供了足够的灵活性，能够方便地更改流程，而不会对核心服务造成影响。这一点遵循了 SOA 的松散耦合目标。 为了描述业务流程，创建了一个新兴标准 BPEL4WS。BPEL4WS 建立于 Web 服务标准之上。此类标准的兼容性让流程能够调用基于标准的开放基础设施中的基础服务和合作伙伴服务。 使用 BPEL4WS 定义的流程包括： 活动，即流程内的各个业务步骤。活动可以为基本活动或由其他活动组成。 合作伙伴链接，指定使用 WSDL 接口与流程交互的外部实体。 存储活动间传递的消息的变量，因而代表状态。 相关集，用于将多个服务请求或响应消息与相同的业务流程实例相关。 错误处理程序，
29、用于处理在业务流程运行时可能出现的异常情况。 事件处理程序，并行于普通执行进程接受和处理消息。 补偿处理程序，指定在出现异常时撤销一个或多个活动的补偿逻辑。 人工任务 业务编排也提供了对人工任务 的支持，人工任务是涉及到通过服务或其他人进行的人工干预的组件。关于出差申请的管理审批或由个人处理客户请求就是这一方面的例子。 人工任务的类型有： 参与任务：这些任务由系统启动，需要人员进行响应才能继续执行。系统启动任务，候选执行者中某个人认领任务并执行。然后将输出提供给系统，通知系统已完成此任务。例如，等待经理审批的旅费报帐流程就是这方面的一个例子。 图 2. 参与任务成员和交互 发起任务：正如其名字
30、所示，这些任务是由人员通过用户界面启动的。此类任务以系统为目标；人员创建发起任务并启动此任务；请求发送到系统，以运行所需的服务。只要系统完成执行，将会向发起人发送通知。员工发起旅费报账流程就是一个这样的任务。 图 3. 发起任务成员和交互 纯人工任务：和发起人工任务类似，这些任务也是由人员创建和启动的。与参与人工任务类似，这些任务以认领并完成任务的其他人员为目标。纯人工任务不与业务流程或其他 Web 服务交互。这些任务不是自动任务，不过也同样经历相同的分配和通知周期。 图 4. 纯人工任务成员和交互 人工任务所花的时间完全可能远远超过自动任务，而这就带来了另一个问题：流程是否容许人工任务导致的
31、中断和等待时间？答案是肯定的。为了更为详细地讨论这个问题，让我们先讨论一下业务流程类型。 业务流程类型 业务流程可以为长时间运行的流或微流： 长时间运行流程是可中断的，也可以运行于多个事务中。此类流程可以等待外部诱因，例如使用人工任务导致的结果等。根据经验，如果流 程包含人工任务，则流程一定为长时间运行的流程。长时间运行的流程还可以同时包含同步和异步服务。长时间运行的流程存储每个中间流程状态，以便获得前向可 恢复性。 微流在没有中断的单个线程中运行。此类流程也称为不可中断业务流程。微流仅在一个事务中运行，持续时间短，而且仅由同步服务组成。 SOA 生命周期及其不同的阶段 SOA 具有动态生命周
32、期的特点。动态生命周期即意味着可能持续地改进流程，而这一点通过与 SOA 所采用的松散耦合相结合，可以让流程像分解和重新组合构建块一样方便地进行流程改进，而不用完全返工。这可缩短上市时间和改善业务和 IT 的一致性。 著名的 SOA 生命周期关系图包括四个互连的六边形图。如图 5 中所示，这四个阶段形成了闭合环，代表了监视和改进的持续循环。 图 5. SOA 生命周期的四个阶段 下面将对此进行详细介绍： 建模阶段 建模阶段包括业务分析和需求收集，然后是对业务流程进行建模和优化。模型可帮助对流程、其目标和输出达成一致的认识。它还能确保设计满足业务需求，并为以后测定性能提供基准。 组装阶段 在此阶
33、段，所建模的流程中需要的现有资产、财务系统、IBM CICS 应用程序等）将被包装为服务，并同时实现和测试需要但还不存在的功能。所有服务可用之后，则可以对其进行编排，以实现业务流程。 部署阶段 在部署阶段，可以配置运行时环境来满足所需的服务质量级别和安全需求。可以对环境进行伸缩和优化，以便能可靠地运行任务关键型流程，而且同时还能提供在更改时进行动态更新的灵活性。 管理阶段 在此阶段，将管理和监视多个方面，如服务资产、服务可用性和响应时间以及对服务的版本控制。此阶段的一个重要角色是监视流程的关键性能指标。这可帮助防止或隔离和诊断实时出现的问题，并能提供关于业务流程性能和瓶颈的反馈，以帮助进行改进
34、。此反馈发送到建模阶段 ，用于帮助改进流程。 SOA 管理 正如第一部分所述，SOA 需要可靠的活动管理框架，否则就可能会失控。SOA 管理通过治理概念实现，治理控制着 SOA 的不同方面。因为 SOA 具有开放的特征，因此启用了 SOA 的环境中必须强制要求的另一个方面就是安全。此部分将对 SOA 管理进行详细讨论。 SOA 治理 如果没有控制实体，SOA 不仅会带来管理难题，而且还会由于开放和分布式特性带来混乱。因为这个原因，SOA 需要管理和控制实体：治理。 治理的定义 SOA 治理是用于决策和角色标识的框架，用于鼓励与企业战略同步的 IT 操作，并防止那些与其相悖的操作。此框架由一个专
35、门的团队或委员会管理，他们负责创建策略来执行治理和角色标识、授权和保证获得了决策与策略执行能力的人 员的可靠性。简单来说，此委员会需要处理三个主要问题： 为了确保有效的 IT 资产管理，需要进行哪些决策？ 谁应该负责进行这些决策？ 此类决策如何执行和监视？ 作为治理实现的一部分，将标识和监视服务水平协议，以进行验证。也会收集性能度量来表示治理的有效性。 治理在 SOA 环境中扮演什么角色？ 治理在 SOA 中的角色非常重要；需要在 SOA 生命周期的所有阶段启用治理，如图 6 中所示。 图 6. 相对于 SOA 生命周期阶段的治理位置 对 SOA 治理的需求非常明显，因为： 治理涉及到应用企业
36、战略的原则来指导和控制 IT。 治理的目标是鼓励与用于实现企业业务目标的组织任务、战略和价值相一致的行为，以在求得风险和回报平衡的同时提高价值。 治理确保从完整性、性能、可靠性和资金角度将服务保持在所定义的水平。 治理确保正确地评估业务应用程序需求和确定其优先级，以推动服务的创建和使用，从而确保在保持与业务目标一致的情况下的最佳利用率。 治理确保以有利的方式使用 IT 投资。 治理确保将启用了 SOA 的企业级体系架构作为任何服务设计的主要指导思想。 作为控制实体，治理充分利用了 IT 原则的最佳实践。 为了保护业务资产，治理还会强制要求保证企业的数据安全性和跨边界共享的信息的私密性。 治理用
37、于管理企业的 IT 资产，负责保证数据和流程的完整性和可靠性，以充分利用重用和实现利益最大化。 治理可确保使用者-提供者服务链上的所有组件保持一定级别的性能和服务质量。 标准是 SOA 的基础，因此治理可以帮助实现高级别的互操作性，充分利用开放标准所提供的所有好处。 治理使用度量标准来审核和监视 IT 基础设施开发的进度及其对已经建立的策略的遵从情况。 SOA 治理中的服务质量遵从 在 SOA 治理的框架中，组织会定义和执行 QoS 策略。这实际上是一个开放环境，其中的集成和服务交换并不限于企业的内部概念，而且也包括具备不同规模、不同范围和不同 IT 规模的其他企业，从而维持和保证总体流程处于
38、稳定的水平。例如，如果您将响应时间视为 QoS 指标，如果多个服务未在给定时间内响应，因而未达到 QoS 要求，则其中最慢的服务可能会造成瓶颈，浪费其他较快的服务提供的 QoS。安全性方面也是如此：一个遵从性不好的服务可能会影响整个系统。在某些系统中，基础设施设计为能够检测 QoS 级别并拒绝不满足遵从性要求的服务。 为何 SOA 环境中的安全系统非常复杂，而且是分布式的？ 之所以需要这样复杂的安全系统，是因为： 分布式系统需要分布式安全性。 需要跨多个应用程序、平台、业务合作伙伴和实体管理用户注册中心和访问控制，而这无法通过单点管理实现。 必须在整个环境中执行一致的安全策略。 安全系统需要能
39、够随着企业及其应用程序的发展而发展。 在 SOA 生命周期中，服务中的更改有什么影响？ 通过应用分离原则，服务使用者通过 ESB与服务提供者彼此分离，从而可以非常方便地处理 SOA 环境中的服务更改。提供者一方的更改可以被 ESB 使用，因此使用者保持不变，能对更改保持无缝状态。 另一方面，我必须指出 SOA 环境中的无管理更改的重要性。通过重用原则，每个服务都可以成为企业级的服务，而不再是其所属的部门或单元内的本地服务。此类服务的任何无管理更改都可能 导致不可预测的企业级错误和中断流程。这表明了治理的重要性在于确保有对应的策略管理更改。此策略应该对影响加以度量，允许进行更改，并能确保向受影响
40、方 发送系统通知。分布式系统中的更改需要严格的规则来进行管理。 ESB 在 SOA 治理中扮演什么角色？ ESB 在执行治理方面扮演着重要的角色。可以应用安全性和 QoS 策略来控制其级别和仅仅允许符合要求的请求。总的说来，ESB 扮演着统一平台的角色，所需的策略在此平台强制执行。ESB 实际上是所有通信进行的集中位置，这一点使其成为了激活此类规则的最佳地点。而且，完全可以保证所有各方面的遵从性和彼此隔离。 准备实现 SOA 在组织中引入 SOA 的过程需要特殊的技能，包括： 能够确定组织对这样的调整的准备情况。 标识边界和入口点。 通过 SOA 能够为业务和 IT 带来的好处开导大家。 从业
41、务和技术角度评估 SOA 引入方面的挑战和驱动因素。 SOA 能为业务和 IT 战略提供什么好处？ SOA 对业务的好处包括： 提高业务对市场变化的响应能力，提高组织方面的敏捷性。 避开组织边界，加强与现有资产的协作。 帮助缩短开发时间。 发现业务流程中效率低下的情况。 确保 IT 资源与业务战略及目标保持一致。 通过执行标准减少遵从性和安全性成本。 合作伙伴和使用者能够更方便地找到您，您也可以更方便地找到他们。 保证更为一致的流程。 为提供者提供不同的选项。 允许资产重用。 减少集成的成本。 简化升级和合并的相关工作。 SOA 对 IT 战略的好处包括： 恰当设计系统体系架构，从而有效地使用
42、标准和服务，以获得其承诺的业务优势。 允许使用各种通信机制。 允许加入灵活且可靠的安全系统来确保安全性。 提供服务总线，可以在其中对消息流和消息本身进行管理，从而在系统的灵活性和适应性方面锦上添花。 通过模块化的组件型服务和服务总线简化集成工作。 构建于受到广泛支持的标准和协议之上，从而实现 SOA 从始至终的一个目标，即互操作性。 通过服务存储库和中介模块推动重用。 使用 ESB 推动连接性。ESB 负责协议、数据和格式的中介，以确保兼容性。 组织在准备采用 SOA 时预计会遇到哪些业务问题和驱动因素？ 业务领域关心的是这个新模式的形式和对组织的影响，因此很可能会出现需要标识和处理的一些业务
43、问题。 业务问题 业务问题可能包括： 因为 SOA 更多的是 IT 驱动的而非业务驱动的，因此管理层怀疑或质疑 SOA。 定义采用过程中使用的战略及采用级别，考虑组织当前的情况及其对采用 SOA 的准备情况。 将流程映射到服务。 缺乏关于 SOA 及其提供的好处的知识。 错误地认为 SOA 仅是 IT 体系架构方法。 低估 IT 业务价值。 通过培训课程来说明 SOA 的好处和真正价值，可以解决其中的大部分问题。 业务驱动因素 主要业务驱动因素是 SOA 具有以下潜能： 推动业务的投资回报，可通过采用标准、重用、公开服务和与合作伙伴集成减少实现成本。 通过重用资产和包含合作伙伴提供的服务来缩短
44、上市时间。 提供 IT 资产的可见性及其与业务目标的一致性。 提高内部通信和涉及外部合作伙伴方面的灵活性。 通过减少 IT 资产和使用标准提供更为高效的流程。 促进业务敏捷性，提高方便而快速地适应业务及市场变化的能力。 削减整个组织的成本。 组织在准备采用 SOA 时预计会遇到哪些 IT 问题和驱动因素？ 不要忘记 IT 部门。接下来我们将列出一些对 IT 部门很重要的问题和驱动因素。 IT 问题 IT 问题可能包括： 将现有定制系统更改为基于标准的服务。 服务的管理、治理和控制。 分布式系统的安全挑战。 新系统的可靠性与现有的可靠系统间的抉择。 优化和统一现有资产，以消除冗余。 IT 驱动因
45、素 IT 驱动因素可能包括： 采用标准。标准的驱动因素也被视为问题，但尽管采用标准需要进行大量的工作，所带来的好处是每个 IT 专业人士都非常清楚的。 确保高 QoS。 现有 IT 资产的重用。 服务的松散耦合。 独立于特定的提供商或合作伙伴。 哪些因素会对在组织中采用 SOA 造成影响？ 在准备采用 SOA 时，您将必须标识可能会影响 SOA 采用的因素，并对其影响进行评估，从而确定组织的准备情况。这些因素主要围绕人员和技术，例如： 组织在 SOA 方面的经验。 对 SOA 及其优势的认识度。 用于标识服务和可重用组件的现有技术。 将现有业务作为服务公开的准备情况。 当前访问异类系统的能力。
46、 遗留系统的可重用性级别。 组织结构中的治理模型的存在情况。 可共享服务层的可用性。 现有体系架构支持应用程序间的高级交互的能力。 基础设施通过安全性和连接性等支持 SOA 的能力。 是否存在度量业务流程及其效率级别的方法。 标识采用 SOA 的过程中会遇到的壁垒 组织需要标识并处理阻碍过渡到 SOA 的任何壁垒。此类壁垒包括： 坚持采用旧的瀑布式开发周期的守旧型 IT 人员。 认为复杂系统更好但又对未知充满恐惧的看法。 忽略架构师的重要性，而将他们视为让解决方案严重超支的“恐怖分子”。务必注意，架构师在 SOA 中有着不可忽视的作用，没有他们肯定不能得到想要的结果。 反对采用 SOA 模型的组织阻力。SOA 需要组织中所有团队的合作，而不仅仅涉及到 IT 框架的实现。 组织中 SOA 的入口点是什么？ 要开始在组织中采用 SOA，我们标识了五个入口点： 人员 流程 信息 连接性 重用 组织应该选择 SOA 采用准备情况最好的入口点，并以其为重点，但同时也不要忽略其他入口点。 图 7. SOA 入口点 接下来将提供关于各个入口点的更多信息。 人员
