Chapter 5: Service-Oriented Architectures for Distributed Computing 面向服务的分布式体系结构 1.

Presentation on theme: "Chapter 5: Service-Oriented Architectures for Distributed Computing 面向服务的分布式体系结构 1."— Presentation transcript:

1 Chapter 5: Service-Oriented Architectures for Distributed Computing 面向服务的分布式体系结构
1

2 本章包括了两种主要面向服务的体系结构形式：表述性状态转移（Representational State Transfer，REST）和Web服务及其扩展。
讨论了面向消息的中间件和带有发布-订阅体系结构的企业总线基础设施。 描述了两个应用程序接口（OGCE和HUBzero），它们使用Web服务(portlet)和Web 2.0(gadget)技术。在分布式系统中，使用服务注册表和语义Web/网格来处理数据和元数据。 使用BPEL Web服务标准、Pegasus、Taverna、Kepler、Trident和Swift阐明通用工作流方法。

3 Services-Oriented Architecture (SOA)

4 服务和面向服务的体系结构 SOA是关于如何设计一套使用服务的软件系统，使其通过已发布或可发现的接口使用新的或已有的应用。这些应用程序通常发布在网络上。 SOA还旨在使得服务的互操作性变得可扩展和有效。它提示支持这一目标的体系结构风格，如松耦合、发布的接口和标准的通信模型。 万维网联盟（World Wide Web Consortium，W3C）定义SOA为一种分布式系统体系结构

5 SOA具有以下典型属性： 逻辑视图：SOA是实际程序、数据库、商业流程等的抽象逻辑视图，定义了它所做的事情，通常执行企业级的操作。服务是依据提供商代理和请求者代理之间交换的消息来形式化定义。 消息方向：提供商和请求者的内部结构包括实现语言、进程结构和数据库结构。这些特征在SOA中都经过精心抽象化：使用SOA的架构，一个人不必也不需要知道实现服务的代理是如何构造的。可以将任何软件组件或应用程序“包装”在消息处理代码中，并使它完全符合形式化的服务定义。

6 描述方向： 服务由机器可执行的元数据来描述。这个描述支持SOA的公开本质：描述中只包括那些公开可访问的并对于服务应用来说很重要的细节。服务语义应通过其描述直接或间接地文档化。
粒度： 服务倾向于使用较少数量的操作，使用大而复杂的消息。 网络方向 ：服务往往是在网络上沿着使用的方向，尽管这不是一个必需的要求。 平台中立性：消息按照平台中立性、标准化的格式通过接口发送。XML是满足这个约束条件的最显然格式。 REST提供一种复杂的标准驱动Web服务技术的替代方法，并在许多Web 2.0服务中应用。

7 REST和系统的系统 REST是应用于分布式系统的软件体系结构风格，尤其是像万维网这样的分布式超媒体系统。
图5-1用户和服务器之间按照HTTP规范的一个简单REST交互

8 REST体系结构风格基于以下四项原则： 通过URI的资源标识：REST的Web服务公开了一组资源，标识了与其客户端进行交互的目标。REST中信息的关键抽象是资源。 统一的受限接口：通过客户端/服务器可缓存的协议HTTP标准来完成与REST风格的Web服务进行交互。 自我描述的消息：REST消息包含足够的信息来描述如何处理消息。这使得中介机构不需要解析消息内容就可以对消息进行更多的操作。 无状态的交互： REST的交互是“无状态的”，意味着消息的含义不依赖于会话状态。

9 REST Architectural Elements

10 创建S3水桶的REST请求-响应示例 REST Request REST Response
PUT /[bucket-name] HTTP/1.0 Date: Wed, 15 Mar :45:15 GMT Authorization: AWS [aws-access-key-id]: [header-signature] Host: s3.amazonaws.com HTTP/ OK x-amz-id-2: VjzdTviQorQtSjcgLshzCZSzN+7CnewvHA+6sNxR3VRcUPyO5fmSmo8bWnIS52qa x-amz-request-id: 91A8CC60F9FC49E7 Date: Wed, 15 Mar :45:20 GMT Location: /[bucket-name] Content-Length: 0 Connection: keep-alive

11 服务和Web服务 图5-2一个在提供商、用户和UDDI注册表之间交互的简单Web服务

12 在SOA范式中，软件能力以基于消息的通信模型通过松耦合、可重用、粗粒度、可发现和自我包含的服务来传递和使用。
Web已经成为一种利用应用程序来连接远程客户端的媒介。 术语“Web服务”经常指那些自我包含的、自我描述的、模块化的应用程序，它们被设计来供网络上的其他软件程序使用或访问。一旦部署了一个Web服务，其他的应用和Web服务就可以发现并激活已经部署的服务 Web服务是SOA实现的最常见实例之一。W3C工作组将Web服务定义为一个软件系统，支持网络上机器到机器的互操作交互。

13 组成目前Web服务核心的技术有： 简单对象访问协议（SOAP）提供了一个标准的封装结构，用来在各种不同的互联网协议（如SMTP、HTTP和FTP）上传输XML文档。通过使用这样的标准消息格式，异构的中间件系统可以实现互操作。 Web服务描述语言（WSDL）描述了接口，即Web服务支持的一系列标准格式的操作。它标准化了操作的输入和输出参数的表示以及服务的协议绑定，消息在线传输的方式。使用WSDL，不同的客户端可以自动理解如何与Web服务交互。 通用描述、发现和集成（UDDI）提供了一种通过搜索名称、标识符、类别或Web服务实现的规范来广告和发现Web服务的全局注册表。

14 WS-I协议栈

15 用来创建S3水桶的SOAP请求-响应例子 SOAP Request SOAP Response <soap:Envelope
xmlns:soap=" soap:encodingStyle= " <soap:Body> <CreateBucket xmlns=" <Bucket>SampleBucket</Bucket> <AWSAccessKeyId> 1B9FVRAYCP1VJEXAMPLE= </AWSAccessKeyId> <Timestamp> T14:40:00.165Z </Timestamp> <Signature>Iuyz3d3P0aTou39dzbqaEXAMPLE =</Signature> </CreateBucket> </soap:Body> </soap:Envelope> <AWSAccessKeyId>1B9FVRAYCP1VJEXAMPLE= </AWSAccessKeyId>

16 SOAP消息包含应用程序使用的一个信封，里面封装了需要发送的消息。信封包括头和体模块。编码风格元素指的是XML模式的URI地址，用于对消息元素进行编码。
SOAP消息中的每个元素可以采用不同的编码方式，但是除非特别指定，整个消息的编码方式定义在根元素的XML模式中。头部是SOAP消息的可选部分，它包含了上面提到的辅助信息，在这个例子中没有包含头部。 SOAP请求-响应消息的体部分包含了会话的主要信息，它是由一个或多个XML模块来组成的。

17 核心WS-*规范包括的10个领域

18 企业多层体系结构 企业应用程序通常使用多层体系结构来封装和集成各种功能。 多层体系结构是一种客户端/服务器体系结构，其中表述、应用处理和数据管理是逻辑分离的过程。已知最简单的多层体系结构是两层，也就是客户端/服务器系统。传统的两层客户端/服务器模型需要集群化和灾难恢复来保证可靠性。虽然在企业中使用较少的节点会简化可管理性，但是改变管理仍然很困难，因为在修理、升级和部署新应用时，都需要服务器下线。而且在胖客户端环境下，新应用和增强的部署非常复杂和消耗时间，从而降低了可用性。

19 一个三层的信息系统包含以下的层次： 表述层 向外部实体描述信息，并且允许它们通过提交操作和获得响应来与系统进行交互。 商业/应用逻辑层或中间件 通过表述层完成客户端请求的实际操作的程序。中间层也可以控制用户的认证、访问资源，以及完成一些客户端查询处理，这样可以减少数据库服务器的一些负载。 资源管理层也称为数据层，处理和实现信息系统的不同数据源。

20

21 网格服务和OGSA 开放网格服务体系结构（OGSA）旨在为基于网格的应用定义一个通用的、标准的和开放的体系结构。OGSA的意图在于： 便于在分布式的异构环境上使用和管理资源。 提供无缝的服务质量。 为了提供不同资源之间的互操作性，定义开放的发布接口。 采用工业标准的集成技术。 开发实现互操作性的标准。282283 在分布式的异构环境中集成、虚拟化和管理各种服务与资源。 提供松耦合的可交互服务，并且满足工业可接受的Web服务标准。

22 OGSA体系结构服务： 基础设施服务 指一系列的公共功能。 运行管理服务 与启动和管理任务这些问题有关。 数据管理服务 用来移动数据到需要它的地方、维护复制的副本、运行查询和更新，以及转换数据到新的格式。 资源管理服务 为网格资源提供管理功能。 安全服务 便于一个（虚拟的）组织内有关安全的策略得以强制执行，支持安全的资源共享。 信息服务 提供关于网格及其构成资源信息的有效产生和访问。 自我管理服务 支持对于一系列服务(或者资源)的服务级实现，并且要尽可能的自动化。

23 OGSA体系结构

24 Web服务资源框架（Web Services Resources Framework，WSRF）

25 其他的面向服务的体系结构和系统 美国国防部网络中心服务的全球信息网格(GiG)

26 CICC中的服务——化学信息网格

27 5.2 面向消息的中间件 企业总线 引入一个封装器，使得服务所期望的不同风格（如SOAP、REST或Java RMI）消息彼此之间能够进行通信。术语“企业服务总线”（Enterprise Service Bus，ESB）指的是总线支持许多组件，通常采用不同的风格，能够方便地集成在一起。产生了图5-6所示的消息黑盒抽象。 　 人们不需要在源和目的之间开一个通道，而是把带有足够信息的消息注入总线，允许它正确的投递。 　多个中介的使用允许总线扩展到多个客户端（服务）和大规模消息流量。

28 Two Message Bus Implementations
图5-6 在服务之间或使用中介网络的两种消息总线实现

29 发布-订阅模型和通知 “发布-订阅”概念，对于消息总线，它描述了把源和目的连接起来的一个特殊模型。在这里消息的生产者（发布者）以某种方式对消息贴上标签——通常的做法是与一个（受控的）词汇表中的一个或多个主题名词关联。然后消息的接收者（订阅者）会指定他们希望接收到相关消息的主题。或者也可以使用基于内容的发布系统，内容可以用某种格式（如SQL）来进行查询。 使用基于主题或内容的消息选择称为消息过滤。

30 队列和消息传递系统 在这个领域中，有几个有用的标准。 最有名的是Java消息服务，它在发布/订阅和排队系统中规定了一系列接口概括通信语义。 高级消息排队协议（AMQP）规定了通信的一套有线格式；和API不同，有线格式是跨平台的。 在Web服务里，WS-Eventing和WS-Notification是互相竞争的标准，但是它们哪一个也没有发展出强力的后续。

31 Comparison of Messaging and Queuing Systems

32

33 5.3 门户和科学网关 科学网关是支持交互的基于Web的科学、教育和协作的工具。网关提供以用户为中心的环境，通过用户界面与远端的计算资源进行交互，典型的用户界面构建方式是使用Web技术。网关是更为复杂的实体。科学网关也称为门户。 我们把网关软件分为“可立即使用的”方案，典型代表是HUBzero；以及“工具箱”方案，典型代表是开放网关计算环境（OGCE）项目。可立即使用的网关软件提供建造网关包括主机的端到端解决方案。工具箱网关软件提供解决特定问题的工具，可以集成到定制的软件栈里。

34 图5-8 科学应用的网关组件软件栈

35 科学协作的HUBzero平台 一个开源的软件平台，用来创建科学协作、研究和教育的网站或“中心”

36 开放网关计算环境（OGCE） 提供了在几个协同网关中使用的开源网关软件。OGCE包括一些组件，为远程科学应用管理提供更为复杂的解决方案。OGCE包括以下的组件工具： OGCE Gadget容器：一个用来集成用户接口组件的谷歌工具。 XRegistry：一个用来存储其他在线服务和工作流信息的注册表服务。 XBaya：一个工作流编排器和演出引擎。 GFAC：一个工厂服务，它可以用来封装命令行驱动的科学应用，把它们组成网络可以访问的鲁棒服务。 OGCE消息服务：支持在多个协作服务之间的事件和通知。

37 5.4 发现、注册表、元数据和数据库 分布式应用需要发现满足需要的资源并管理它们。注册表是复杂的命名和目录服务，它通过分类和归并服务或关于服务的元数据信息，在设计和动态运行时便利了服务资源发现。为了存储在注册表中的元数据，注册项需要一套数据结构规范，为了存储属主、包含和归类服务的元数据，还需要一套操作来存储、删除和查找数据。 注册表通常包含三类信息： 白页包含实体的名字和一般联系信息。 黄页包含条目提供的服务类型和位置的分类信息。 绿页包含如何调用所提供服务的详细信息（关于服务的技术数据）。

38 UDDI和服务注册表 UDDI（统一描述发现和集成）规范通过创建一个平台无关的开放框架定义了一种描述、发布和发现关于Web服务信息的方法。UDDI提供了名字服务和目录服务来通过名字或特定的属性查找服务描述。版本3.0成为OASIS的公共服务注册表标准。 UDDI规范集中在一批服务的定义，它们支持以下内容的描述和发现：商业、组织和其他Web服务提供商；它们提供的Web服务；以及用来访问那些服务的技术接口。 注册表主要有两类：公共注册表，这是一个逻辑的集中式分布服务，彼此之间在一个约定的基础上复制数据；私有注册表，仅仅在单个的组织内部访问，或被一群有特定目的的商业伙伴所共享。

39 图5-10 UDDI实体及其关系

40 数据库和订阅-发布 订阅-发布是在分布式应用之间实现异步交互的设计模式。 许多高级应用为了使它们的运行和信息相适应而要定期地查询数据库。这种周期性的数据轮询不仅效率低和无法扩展，而且也在两端消耗了大量资源，尤其是数据库的调用间隔很短或者有多个消费者应用的情况下，它会大大增加网络通信的流量和CPU的使用。发布-订阅机制解决了这一问题，它已经在今天的应用实现中大量采用。在发布-订阅交互中，事件订阅者注册了某个事件类型，当事件发布者产生这样的事件时，订阅者就会从发布者处得到通知。

41 在事件发布者和事件订阅者之间存在一个动态的多对多的关系，对于在任何时间可能变化的任何类型事件，可以有任何数量的发布者/订阅者。发布-订阅为数据库的静态本质增加了动态性。
发布-订阅系统可以分为基于主题的和基于内容的。 数据库系统提供了基于消息传递的体系结构可以使用的许多特性，例如可靠的存储、事务和触发器。

42 图5-11 Oracle发布-订阅模型

43 元数据目录 元数据目录扮演一个重要的角色，它们为用户和应用在这种环境下提供了在大量站点之间发现和定位所需要的数据和服务的方式。 元数据是关于数据的信息。元数据很重要，因为它为了识别、定位和解释数据，给数据增加了上下文。 网格上的关键元数据包括数据源的名称和位置、在这些数据源中数据的结构、数据项名称和描述以及用户信息（姓名、地址、概括和偏好）或者可用服务的基本列表和简单查找、没有丰富上下文的相关函数和位置。各种群组和社区使用元数据目录，从高能物理到生物医学、地球天文观测站和地理科学。

44 语义Web和网格 网格力求在动态的大型分布式环境中为了服务和资源的自动化信息发现和集成而共享和访问元数据。 语义Web是关于自动化发现和集成的：给数据增加机器可处理的语义，这样计算机可以理解这些信息并代表终端用户处理它，从而基于为Web页面附加丰富元数据而使Web搜索和链接更加智能。 语义Web旨在提供一个环境，在里面软件代理能够动态地发现、询问和互操作资源并代替人执行复杂的任务

45 为了达到这一目的，已经进行了很多工作来保证在公共数据模型——资源描述框架（RDF）中Web资源的含义，RDF使用以公共语言（如OWL Web本体语言）表示的一致本体论，这样我们可以共享元数据，并且增加到背景知识中。 从这个基础上，我们应该可以查询、过滤、集成和聚集元数据，并应用规则和策略在它的上面推理出更多的元数据。 RDF是为语义Web开发的第一个语言，使用XML来表示Web上资源的信息（包括元数据）。RDF使用Web标识符（URI），并且从简单的属性和属性值方面来描述资源。OWL是拓展了RDF模式的一个描述性本体语言。

46

47 图5-13 语义网格体系结构

48 作业执行环境和监控 分布式作业执行环境常常包含两个组件：作业执行引擎和分布式数据管理系统。作业执行引擎主要处理作业调度、资源分配和诸如容错等其他问题。数据管理系统常常为作业访问分布式数据提供抽象。 为了处理互联网级别信息管理和处理的不断增长的需要，许多互联网服务公司为了特定需要建立了他们自己的分布式系统。大多数这些系统提供分布式运行引擎，支持集成的应用。 谷歌MapReduce和微软Dryad是这种系统的两个例子。

49 5.5 面向服务的体系结构中的工作流 工作流的基本概念
图5-14 服务网格之网格的概念图示

50 工作流是“对服务之间交互进行编程”的方法。同称呼工作流描述了“为Web或网格编程”一样，我们也可以使用诸如“软件协调”、“服务编排”、“服务或过程协调”、“服务会话”、“Web或网格脚本”、“应用集成”或“软件总线”之类的名字。 必须注意工作流意味着分布式系统的两层编程模型。基本服务采用传统语言（C、C++、Fortran、Java、Python）进行编程，工作流描述了服务之间彼此交互的粗粒度编程。每一个服务使用传统的语言进行编程，而它们之间的交互用工作流描述。

51 图5-15 层次化的计算、数据和编程抽象

52 工作流标准 主要在2000～2005年之间完成，当时标准被看做实现Web服务梦想的基石，完整的服务特性规范可以实现互操作性。 近来人们意识到这个目标导致重量级的体系结构，加工不能跟上这么多标准的支持。今天我们更强调轻量级系统，互操作性当需要时可以通过临时的变换得到。标准化工作的另一个问题是它大量地超前系统的部署，这样人们会发现遗忘了关键点的不成熟标准。这个背景解释了表5-9中许多未完成的标准活动。

53

54 工作流体系结构和规范 大多数工作流系统都有两个关键组件。我们把它们称为工作流规范和工作流运行引擎。它们通过接口相互链接
工作流体系结构和规范 大多数工作流系统都有两个关键组件。我们把它们称为工作流规范和工作流运行引擎。它们通过接口相互链接

55

56 工作流运行引擎 图5-18 包括说明流水线和循环的子图的工作流图

57 一般的工作流结构是有向无环图，它是顶点和有向边的集合，每一条边从一个节点连到另一个，这样里面没有环。也就是说，从某一个顶点V开始，沿着一系列的边，最终不可能再回到顶点V。
除了复杂的专业工作流系统外，可能使用传统语言和工具集的脚本是构建工作流的主要技术。通常这可以使用任何分布式计算（互联网）支持的环境以非正式的方式实现 最复杂的工作流系统支持层次化规范，即工作流的节点可以是服务或服务集（子工作流）。这和网格的网格概念一致。

58 图5-19 Swift工作流系统体系结构

59