SOA基础知识总结

SOA 基础知识简介
SOA 简介
如果您接触 SOA 不久，则可能会希望在开始本教程前了解本部分给出的一些基本信息的简介。

SOA 是一种体系架构方法，用于定义、链接和集成具有清晰边界且功能方面自包含的可重用业务服务。

在这种类型的体系架构中，您可以对业务流程中的业务服务进行协调。

通过采用服务的概念（一个独立于应用程序或基础设施 IT 平台以及上下文和其他服务的较高级别的抽象），SOA 将 IT 提升到了一个新的级别，更为适合互操作性和异类环境。

因为 SOA 构建于主要 IT 提供商认可和支持的标准（如 Web 服务标准等）之上，因此可以快速构建服务和进行互连。

可以在不考虑所支持的基础设施的情况下在企业间进行互连，从而为委托、共享、重用现有资产并实现其好处的最大化打开方便之门。

通过建立 SOA，可以将内部 IT 基础设施提高到一个更高、可见性更好且可管理的级别。

通过可重用服务和高级流程，能以比以往任何时候都方便的方式进行更改，而且更像是分解部件（服务）并将其重新组合为新的与业务一致的流程。

这不仅提高了效率和重用，而且还提供了极强的更改和保持 IT 与业务一致的能力。

SOA 的价值
那么，为什么大家对 SOA 的出现如此兴奋呢？它提供了什么，能够有什么帮助？是否所有情况都应该使用？接下来让我们逐一回答这些问题。

SOA 最适合什么？
您可能会想，SOA 最适合哪些业务功能和情况，以及何种情况最能体现出其潜能？某些情况和业务功能应该立即使用 SOA，因为 SOA 可以提高竞争力和效率，清楚地体现出其价值。

此类情况主要包括：
多个实体使用的集中业务功能：SOA 可帮助标识此类功能，并将其打包为可重用的自包含服务，不会受到相关流程更改的影响。

∙与合作伙伴集成：SOA 可推动标准的使用，而这在任何集成中都至关重要，因为标准为所有各方创建了共有的工作基准。

另外，SOA 能提供出色的敏
捷性，能够通过 SOA 的分离功能以对客户几乎无缝的方式灵活地插入、
更改或更新服务，从而能增强集成体验。

∙存在仍然在使用的旧技术：有些组织可能不愿意放弃行之有效的技术。

安全顾虑让有些客户（特别是银行之类敏感行业）对新软件系统及其未知漏
洞持怀疑态度。

在这种情况下，SOA 可以帮助使用标准方式打包遗留技术，以便在适合进行集成和重用的基于标准的环境中使用。

什么因素促成了SOA 最受欢迎的功能：业务敏捷性支持？
因为更改是不可避免的，业务连续性的唯一保证就是预计更改并加以适应，也称为业务敏捷性。

对于任何企业的未来都至关重要的是，SOA 通过以下方面让业务敏捷性成为可能。

松散耦合
∙支持实时业务功能，因为其中消除了阻碍变更能力的硬连接
∙改变 IT 成本分布方式，在实现上面更为廉价，更多的投资可进行重用∙提高对信息源的实时远程访问的可行性，从而减少延迟和依赖关系
∙集成项目是由业务需求驱动，并具有所提供功能的可见性（即业务是主要驱动因素）
∙通过公开和共享信息让公司获得更高的实时数据测定性能
∙缩短上市时间（因为可以加快到客户和合作伙伴的连接时间）
∙合作伙伴可以更快地与您的公司开展业务
∙推广和公开您的服务，更便于客户查找您和您的服务
∙通过搜索最适合您的需求的服务，更便于查找新的合作伙伴和服务
重用
∙提高流程一致性（因为依赖于相同的重用组件）
∙通过服务提供者间的竞争促进质量的提高
∙为客户提供广泛的提供商选择
∙几乎涵盖所有 IT 资产类：硬件、软件、数据和流程资产
∙减少更改的影响（因为更改在集中位置进行，然后就会在所涉及的所有各方上反映出来）
∙让您专注于业务流程，而不用太多考虑技术实现
∙帮助减少集成的成本（因为组件已经进行了集成）
∙让您在不约束业务更改的前提下进行系统更改
∙提升灵活性，从而获得更多的创新空间
∙允许一次发布多次使用
可扩展性
∙让各种规模的组织都能使用 SOA 解决方案
∙更改软件部署活动到更为动态且更为省时的模型，与业务更为相配
∙更便于添加或更改合作伙伴
∙加速合并和收购
∙方便公开服务，而这就代表着新的收益来源
那么，如果公司不采用SOA，将失去什么？
因为对公司而言，SOA 是非常可取的解决方案，不实现此体系架构的代价是，可能会导致在三个方面存在重大落后的情况：
∙无法进入到提供更多业务增长和曝光机会的高值市场。

因为公司受到现有定制系统的束缚，虽然努力想进入高值市场，但始终却在市场原地踏步。

不过，通过 SOA，组织可以改变业务战术和支持新的市场策略，从而获得竞争优势。

∙无法应对与技术更为先进的对手的竞争。

∙来自成本更低的领域的竞争。

SOA 是否总是较好的解决方案？
SOA 可以为所有业务组织带来好处。

不过，在一些非常特殊的情况下，可能会发现 SOA 更多的是一种责任和义务，而不是改善业务的驱动因素。

这些情况包括：
∙同类 IT 环境：如果组织依赖于一组一致的产品（例如，属于相同的提供商）、工作范围有限而且不需要添加或更改其中的任何产品，则 SOA 不
是一项有用的策略，而可能是一种责任。

∙真正的实时性能极为重要的情况：为了在不同使用者和提供者之间提供松散耦合，SOA 依赖于可互操作性协议达到此目的，而这在本质上是很缓慢的。

其中还可能包括中介逻辑和异步协议，而这些并不适合对实时性能要求较高的情况。

∙不会发生变化时：如果客户没有发现业务逻辑、表示、数据流、流程或应用程序任何其他方面的变化，将旧系统转换为 SOA 可能不会带来足够的
好处让所投入的物有所值。

∙紧密耦合并不方便时：松散耦合最好与不在您控制之下的组件（即您无法控制其变更）结合使用。

另一方面，如果组件是您的且受您控制，松散耦合可能成为负担，特别在组件不具有实际可重用性的情况下更是如此。

SOA 概念
接下来让我们了解一些 SOA 概念，以便更好地理解什么是 SOA。

SOA 中服务的定义
关于服务，有大量不同的定义，但我认为以下对什么是服务解释得最好。

摘自Web Services and Service-Oriented Architecture: The Savvy Manager's guide（请参见参考资料部分提供的链接）：
“服务是定义良好、自包含且不依赖于上下文或其他服务的状态的功能。

”
摘自 （请参见参考资料部分提供的链接）：
“...服务定义为代表某个计算实体（如人工用户或其他程序）执行的工作单元。

”
SOA 中松散耦合的概念
为了帮助了解 SOA 中松散耦合的概念，您应该首先了解一下常规的松散耦合概念。

以下说明了什么是松散耦合以及其为何颇有价值：
∙如果交互中一方对实体的更改需要其他方进行对应的修改，则实体是耦合的（例如，业务数据模型）。

∙如果实体的行为在服务接口中指定，且服务请求者和提供者只能在具有匹配的声明行为时才能进行交互，则该实体是声明的。

声明的方面包括安全性、事务行为和服务质量（如响应时间和交付等）。

∙如果实体由服务请求者和服务提供者同时声明，但基础设施提供了一些转换功能来支持声明的行为不匹配的服务请求者和提供者间的交互，则该实体是转换的。

∙如果请求者和提供者都声明了自己能够支持的一系列行为，而对于每个交互，中间层基础设施都能够在二者之间协商一个一致同意的行为，则该实
体是协商的。

∙如果交互中一方对特定方面的更改不需要其他方进行对应的更改，则该实体是分解的。

松散耦合在 SOA 范式中的作用如下：
∙它帮助在服务提供者和服务使用者之间形成一个抽象层。

∙松散耦合可提高在不影响服务使用者的情况下更改服务实现的灵活性。

∙在 SOA 方法中，功能组织为一系列模块化、可重用的共享服务。

这些服务具有定义良好的接口，其中封装了用于访问服务的关键规则。

这些服务
还是在不假设谁将使用服务的情况下构建的。

因此，能够松散耦合到这些服务的使用者。

XML 在SOA 中作出了什么贡献？
SOA 基于开放标准，能够促进独立于平台的业务集成，但是需要公共平台作为其基础设施的基础。

此基础设施需要所涉及的各方的支持，以在认识方面达成一致。

由于以下这些原因，XML 是此基础设施的核心：
∙XML 是几乎所有 Web 服务标准的基础，如 XML 模式、SOAP、Web 服务描述语言（Web Services Description Language，WSDL）及统一描述、发
现和集成（Universal Description, Discovery, and Integration，UDDI）等。

这些标准利用了基于 XML 的表示形式的核心概念，此表示形式是受
到全球广泛支持的格式，能用于在 SOA 中的服务提供者和请求者之间进
行信息交换。

∙通过使用 XML 解决了跨不同平台使用不同应用程序中不同数据格式的问题。

∙XML 本质上具有简化表示形式、基于文本、灵活且可扩展的好处。

SOA 使用的构建于 XML 之上的标准包括：
∙SOAP:这是基于 XML 的简单协议，允许应用程序通过 HTTP 等传输协议交换信息。

在 SOAP 中使用 XML 保证了 SOAP 协议以下方面的特征：o独立于平台。

o可在 Internet 上使用。

o能人工读取，具有结构化特征，且基于文本。

由于具有上述好处，SOAP 是推荐使用的 Web 服务通信协议，使用最为广泛。

由于 Web 服务是 SOA 的基础，因此这个协议也是 SOA 解决方案的
基本通信协议。

∙WSDL：WSDL 是以 XML 格式编写的用于描述 Web 服务的文档。

它指定服务的位置和服务向访问此服务的个体公开的操作（或方法）。

WSDL 文件
描述四个主要事项：
o Web 服务接口提供的服务，如方法的列表名称和属性消息。

o消息的数据类型
o传输协议（如 HTTP 和 JMS）的绑定信息
o调用时使用的服务地址
∙使用可扩展标记语言的电子商务（Electronic Business using eXtensible Markup Language，ebXML）：ebXML 是定义企业间执行的业务事务的标准方式。

ebXML 定义了业务消息交换的标准方法，建立了公司间的贸易通信和注册业务流程。

服务注册中心
服务注册中心是 SOA 系统中可用的服务的目录。

其中包含服务的物理位置、版本及服务有效期、服务文档和策略。

服务注册中心是 SOA 体系架构的主要构建块之一。

下面对其扮演的角色进行了介绍：
∙服务注册中心实现 SOA 的松散耦合承诺。

通过保存服务端点位置，消除了在使用者和提供者之间进行硬编码所带来的高度耦合。

另外还消除了在需要的情况下替换服务实现的潜在难题。

∙服务注册中心具有很高的可伸缩性，可以在系统服务逐步发展的情况下无缝地提升。

∙它允许系统分析人员对企业的业务服务投资组合进行调查。

他们可以随后确定哪些服务可用于实现流程自动化来应对迫切的业务需求，哪些服务不能用于此目的，从而让您知道需要在投资组合中实现和添加什么，并会提供可用服务目录。

∙服务注册中心可以通过强制遵从订阅服务来逐步过渡到治理服务的角色。

这可帮助确保服务治理和策略的完整性。

在本教程稍后，您将了解关于治理及其在 SOA 中的重要性。

∙可用服务及其接口的可见性可加快开发速度、提高应用程序重用、改善治理和改进业务规划及管理。

没有服务注册中心会导致冗余和效率低下。

∙服务注册中心可帮助减少在定位服务信息方面浪费的时间。

∙如果不使用注册中心来跟踪服务及其关系，SOA 环境不仅会缺少一致性和控制，还会出现混乱。

什么是业务流程？
业务流程是在此环境中经常听到的一个术语。

以下是业务流程的两个定义：
摘自“Business processes and workflow in the Web services world”：
“业务流程可以定义为链接到跨功能边界的活动的一组相互关联的任务。

业务流程具有起点和终点，是可重复的。

”
另一个定义是：业务流程可以视为业务实体为了响应事件而执行的一组活动。

这一组活动在业务流程中彼此协调，一起描述并集成到一起。

为个人发放身份证就是一个业务流程。

您提供您的出生证明、教育和专业证书及一张照片来启动流程。

然后将创建内部文件，对您进行安全调查，最后，完成了所有处理后，就拿到了身份证了。

在 SOA 范式中，业务流程对服务流进行控制。

业务流程驱动事件流，调用和协调服务，并为其创建上下文来进行相互通信。

业务流程代表业务抽象，同服务实现进行了分离，是关于业务流的流程。

通过这个关注分离，不仅可以将更多精
力放在流程创建上，而且还可以更方便地根据需要编辑流程，但不用对基础服务实现进行编辑。

业务流程的组成元素
从组成元素的角度定义业务流程的做法可能相对更好一些，这样能从技术角度对业务流程有一些了解。

∙输入：流程的活动为了产生结果所需的信息。

在身份证示例中，输入应该为您的凭据、出生证明和照片。

∙输出：流程生成的所有数据和信息。

输出代表业务目标和业务所需的度量数据。

在身份证示例中，输出是您的内部文件和实际身份证以及关于流程如何进行的度量数据。

∙事件：一些重要情况的通知。

例如，某个指示信息。

事件可能在流程的执行前、执行中和执行后发生。

在身份证示例中，可能会出现关于最开始没有提供需要包括的新文档的事件。

∙子流程：流程中较小的流程或流程步骤。

使用一组活动不足以表示工作范围时，将使用子流程。

子流程具有与流程相同的组成元素。

在身份证示例中，这可以为调查犯罪记录并获得结果的子流程。

∙活动：流程中级别最低的工作单位。

在身份证示例中，为申办身份证的人创建新内部文件的工作就是一个活动。

∙性能度量：表示流程有效性的属性，用于确定是否满足所需的性能。

这些度量可以帮助确定性能并将其与所需的指标进行比较。

通过这些性能度量还能确定流程改进的潜在区域，最终（理想的情况下）实现 SOA 承诺的改进周期。

在身份证示例中，度量数据中将计算流程的哪个部分使用的时间最多或处理命中率最高。

这可以在以后帮助改进流程。

SOA 如何处理事务控制？
因为流程跨多个活动，因此 SOA 环境中出现的业务事务可能会非常复杂。

这是由于 SOA 上下文中长时间运行的流程中的服务的本质所决定的，此类服务通常具有异步、无状态、分布式和不透明的特点。

Web 服务是 SOA 环境中最完美的服务表示形式。

Web 服务具有 SOA 所需的自包含特性，但在涉及跨服务事务需求时就有些局限了。

只要服务位于事务的根部，且事务的范围受到服务的基础解决方案逻辑所执行的活动的限制，就不需要跨服务事务功能，而且事务可以通过封装的任何专有技术（基于组件的技术、遗留技术或其他技术）进行管理。

但随着环境中服务数量的增加，对跨这些服务的事务的需求就会增加。

一些 Web 服务规范被用来处理事务的问题。

这包括：
∙WS-Coordination：允许注册流程参与活动，以创建共享上下文，负责保存流程间传播的有状态数据和信息以及事务状态。

此框架允许现有事务
处理、工作流和其他要协调的系统隐藏其专用协议，从而在异类环境中协
同工作。

此协议为使用其框架的其他协议（如 WS-AtomicTransaction 或WS-BusinessActivity）提供基础设施。

∙WS-AtomicTransaction：用于短期存在的分布式活动。

它提供了可与WS-Coordination 框架结合使用的三种类型的协议，供两阶段提交 ACID 类型（支持原子性、一致性、隔离性和持久性的事务）选择使用：o完成
o易失两阶段提交
o持久两阶段提交
∙WS-BusinessActivity：此协议用于长时间运行的带有补偿流程的事务。

对于 WS-AtomicTransaction 协议，它使用 WS-Coordination 框架提供
用于业务活动协调的两个协议：
o BusinessAgreementWithParticipantCompletion
o BusinessAgreementWithCoordinatorCompletion
标准在SOA 中扮演什么角色？
通常，SOA 项目与标准非常相关，因为标准能带来以下好处，所以在其中对标准进行了充分利用：
∙标准能确保跨系统和合作伙伴的互操作性。

∙使用标准提高通过流程和工具进行的开发和交付。

∙通过标准能更好地管理 IT 资产和提高其可见性。

∙标准能确保服务质量（Quality of Service，QoS）。

∙标准能通过减少对特定实现的依赖性提供灵活性。

接下来我们将给出一些 SOA 所利用的标准示例，了解标准如何帮助实现 SOA 的承诺。

WS-Security
WS-Security 协议基于向消息 Header 添加 SOAP 扩展来存储安全元数据，此类元数据旨在用于通过消息完整性、保密性和身份验证提供保护。

这些扩展提供了用于将安全令牌与消息关联的通用机制，从而替代了固定的安全机制。

通用平台支持不同的安全机制。

此协议设计为可扩展协议。

BPEL4WS
用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS）在 BPEL 的 OASIS 在线社区中定义如下：
“此协议定义了用于基于流程及其合作伙伴间的交互描述业务流程的行为的模型和语法。

它还定义与合作伙伴的多个服务交互如何协调来实现业务目标，以及此协调所必要的状态和逻辑。

”
由于有明确的需求，BPEL4WS 引入了处理业务异常和错误的方法，还引入了用于补偿可能需要在出现错误的情况下反转的其他已提交流程的方式。

因为 BPEL 需要通用支持，因此该协议以广泛认可的 WSDL 协议为基础，而 WSDL 本身又是基于 XML 的。

WS-I
正如 WS-I 网站中所述（请参见参考资料提供的链接）：
“Web 服务互操作性组织（Web Services Interoperability Organization，WS-I）是一个开放行业组织，其宗旨是为所选的 Web 服务标准组建立跨平台、操作系统和编程语言的 Web 服务互操作性最佳实践。

”
这个组织关注不同实现、平台及其实际互操作性方面的 Web 服务标准开发。

其主要目标是就如何在使用 Web 服务对系统互连的时候确保互操作性提供指导和建议。

WS-I 具有四个主要的可交付内容：
∙概要，即描述可互操作且作为集合工作的 Web 服务的实现指导原则和最佳实践的具有版本控制的规范
∙用于演示概要中的指导原则的用例和使用场景
∙示例应用程序
∙概要遵从性测试工具
基本SOA 体系架构
接下来让我们了解一些更为复杂的技术主题，如企业服务总线（Enterprise Service Bus，ESB）的角色、业务流程、其编排及 Web 服务的角色。

基本 SOA 体系架构由哪些部分组成？
基本 SOA 体系架构包括服务提供者、服务和可选的服务目录。

应用程序到应用程序的消息传递在信息交换中使用。

这个模型和简单 Web 服务之间的相似性非常明显，二者都将 WSDL 作为存储在服务目录中的调用契约（可以通过 UDDI 在其中进行查询和获取）。

Web 服务实际上是最基本的 SOA 实现。

在此模型中，基本场景如下：首先，服务提供者创建服务，并决定将其公开并发布。

发布是通过将服务信息发布到服务目录上来完成的。

另一方面，需要特定服务的服务请求者将在服务目录中搜索满足必要条件的服务。

找到服务后，通过使
用服务目录中的可用信息，服务请求者能够以正确的方式直接联系服务提供者，从而满足业务需求。

图 1. 基本 SOA 体系架构
以下是此部分中使用的一些术语的定义：
∙服务提供者：发布了调用契约和位置的服务的提供者
∙服务使用者：服务目录中找到的与其业务需求匹配的服务的使用者
∙服务目录：用于发布服务和为使用者列出可用服务的目录。

ESB 在SOA 中扮演什么角色？
ESB 在 SOA 中扮演着重要的角色。

从基础的角度而言，它代表着能够连接服务提供者和服务使用者的中枢和基础架构。

以下是 ESB 的角色的详细介绍：
∙提供与 SOA 原则一致的集成基础设施：
o强制使用独立于实现的显式接口来定义采用松散耦合的服务
o使用强调位置透明性和互操作性的通信协议
o促进采用封装可重用业务功能的方式定义服务
∙提供管理服务基础设施的方法
∙在分布式异类环境中操作，因为它：
o支持同步和异步通信
o使用标准接口和标准协议
∙集中控制和分散处理
∙支持中介，根据需要在不同各方之间形成请求/响应，而且不用更改其中任何一方
∙将安全性和 QoS 应用到 SOA 项目
Web 服务在SOA 中扮演什么角色？
尽管 Web 服务的出现早于 SOA，但它代表了寻求系统和平台之间的互操作性需求的 SOA 问题的答案和实现。

因为已经有了支持技术来满足需求，所以能帮助快速建立 SOA 并运行。

显然 Web 服务代表着 SOA 的基础及建议的互操作性技术。

Web 服务之所以是 SOA 的基础，是因为 Web 服务：
∙采用标准，从而提高了兼容性和可移植性。

∙跨平台、跨语言。

∙受到广泛的支持，让 SOA 的采用过程相对简单。

∙面向消息。

∙提供更快的工具支持，从而加快了 SOA 实现。

什么是编排？它如何适应SOA 大方略？
业务服务编排考虑的是业务流逻辑的开发和执行，与基础服务和业务逻辑相独立。

这意味着，流程编排考虑的是事件的顺序，以及事件如何相关，但并不关心事件本身。

流程和服务之间的关注分离提供了足够的灵活性，能够方便地更改流程，而不会对核心服务造成影响。

这一点遵循了 SOA 的松散耦合目标。

为了描述业务流程，创建了一个新兴标准 BPEL4WS。

BPEL4WS 建立于 Web 服务标准之上。

此类标准的兼容性让流程能够调用基于标准的开放基础设施中的基础服务和合作伙伴服务。

使用 BPEL4WS 定义的流程包括：
∙活动，即流程内的各个业务步骤。

活动可以为基本活动或由其他活动组成（结构化活动）。

∙合作伙伴链接，指定使用 WSDL 接口与流程交互的外部实体（或反向关系）。

∙存储活动间传递的消息的变量，因而代表状态。

∙相关集，用于将多个服务请求或响应消息与相同的业务流程实例相关。

∙错误处理程序，用于处理在业务流程运行时可能出现的异常情况。

∙事件处理程序，并行于普通执行进程接受和处理消息。

∙补偿处理程序，指定在出现异常时撤销一个或多个活动的补偿逻辑。

人工任务
业务编排也提供了对人工任务的支持，人工任务是涉及到通过服务或其他人进行的人工干预的组件。

关于出差申请的管理审批或由个人处理客户请求就是这一方面的例子。