SOA服务计算基础技术介绍.ppt

声明,本课件仅用于教学； 本课件修改采用了一些网络资源（论文、研究报告、技术报告等），在采用的时候并没有准确标注引用信息。,服务计算基础技术介绍,中国科学院软件研究所 2007. 8.31,内容提要,产生背景 社会背景 技术背景 基本概念 面向服务计算范型 web服务 核心标准 soap wsdl uddi,服务计算的产生背景,社会背景,服务化社会,现代社会发展的基本趋势 全球化 全球经济日益成为联系紧密的整体 专业化 专业分工日趋细致 标准化 标准化进程扩大产品适用范围、促进企业间协作 ,服务化社会逐步成型 第一产业 农业 第二产业 工业和建筑业 第三产业 流通部门 服务部门 生产、生活服务 科教、文化服务 社会公共服务,不仅第三产业中的服务部门日益壮大，各产业乃至整个社会的运作模式上也日益呈现出服务化特征。,社会服务的基本特征,定义良好、易于使用的接口 提供较为完备的业务功能 用户不需要了解内部细节（实现、依赖关系） 通常是粗粒度的（业务级） 开放、松散耦合 可能同时为多个用户服务 按需建立和撤销协作关系 能够应用于灵活多样的上下文中 服务质量成为竞争的焦点 性能、价格、品质（“how” instead of “what”）,服务化社会使得企业进一步节约成本、降低库存、提高竞争力成为可能。某企业通过其全球采购及零库存工厂战略形成适应服务化社会的新型生产格局。,工厂驻地：深圳 供应商： 分布在东南亚、欧美及珠江三角洲 料件种类：近8000种不同规格的电子料件 服务时效：料件配送到达时间要求零误差,服务化运作模式对大型企业的挑战： 核心企业协调整个过程，共同完成复杂产品制造 服务化的运作模式需要深层次的高效协作 动态开放的环境要求灵活敏捷应对变化的能力,某企业的全球采购与零库存工厂,服务化运作模式对中小型企业的挑战： 企业可能成为多个合作伙伴生产过程中的环节 跨网络同异构系统进行协作的能力 满足不同合作伙伴多样化的需求 企业的发展壮大可能面临经常性的调整 企业资金有限需要价格低廉、适用范围广、生命力强的技术方案,服务化社会中的中小型企业,服务化社会的挑战,共性问题 提供灵活易用的服务，融入服务化的社会 协调内部、外部服务以实现企业业务功能 敏捷应对各类变化 整合异构系统,个性问题 大型企业 协调业务过程，领导一批企业共同完成复杂业务目标 中小企业 满足多样化需求、提高服务质量，以开拓市场发展壮大,服务计算的产生背景,技术背景,软件增长对技术的需求,数十年的发展使得软件日益渗透入社会生活的方方面面，无论是科学、工程、商务、艺术、传媒或是政务，几乎涵盖了所有的领域和所有的业务，而且这样的增长仍会加剧 软件诞生之初，编写数百行代码亦是很有挑战性的工作 而今，要求数百万行代码能够在几天内被构造、集成、部署和维护 这些都依赖于软件技术的发展进步才可能得以实现,计算范型的演进,为此从软件诞生至今，为提高软件开发的效率与质量、解决各类新兴问题，计算范型的发展与创新从未停滞 从机器语言到汇编语言 高级语言初现雏形（cobol, fortran, algol） 从复杂的语言到简单的语言（pl/1 - pascal） 数据抽象的引入（ada） 面向对象技术逐步成熟（smalltalk, c+, java） 构件化软件（当前大部分软件系统都是基于构件技术、在成熟的软件框架基础上开发的，如：j2ee, .net）,计算范型演进的线索：抽象程度,时间,抽象程度,1950,1960,1970,1980,1990,2000,2010,imperative programming e.g. fortran,procedural programming e.g. c,functional programming e.g. lisp,logic programming e.g. prolog,object-oriented programming e.g. c+,component- based programming,service-oriented programming,计算范型演进的线索：构件粒度,1950,1960,1970,1980,1990,2000,2010,imperative programming e.g. fortran,procedural programming e.g. c,object-oriented programming e.g. c+,programming-in-the-large,programming-in-the-small,component- based programming,service-oriented programming,粒度,时间,计算范型演进的启示,从数十年来计算范型演进的趋势来看，以下方向仍会是计算范型发展的主导 提高构件的抽象程度，让应用架构更加贴近现实、贴近业务、贴近流程，使得用户只需要少量甚至不需要计算机专业知识就能够构造应用 加大构件的粒度，使得编程人员能够在较粗的粒度进行程序设计，大量复用已有的成熟构件，通过简单的连接快速构造应用，以提高软件生产的效率和质量，并支持应用的快速变更,internet引发的变革,另一方面，internet的发展与普及为软件技术带来新的变革 继推动人与人间（e-mail，usenet，etc.）、 人与应用间（c/s，b/s应用）交互模式的革新后， 正日益成为软件实体间互联互通的重要媒介,internet的计算模式,internet的计算模式,时间,1985,1990,1995,2000,2005,2010,service-oriented computing,internet computing,web computing,client/server computing,e-mail, usenet, etc.,internet带来的挑战,基于internet连接软件实体对传统计算范型带来挑战 动态的计算环境 开放的系统范围 异构的实现技术 自治的计算资源 需要新的计算范型以适应新兴的internet计算环境,服务计算的基本概念,面向服务计算范型,面向服务计算范型应运而生,面向对象程序设计的经验告诉我们软件系统是现实世界的反映，服务化社会的运作需要相应的信息基础设施支持 计算范型的演化趋势和新兴的internet计算环境亦指出新的计算范型的演进方向,面向服务计算范型基于soa概念架构为前述问题提供了潜在的解决方案,soa概念架构,面向服务计算是一种新兴的、将服务作为构造应用基本单元的计算范型 服务是自描述、平台无关的计算单元，它支持分布式应用快速、低成本的组合式开发 服务之间基于消息机制，以协调、组合的方式进行面向服务应用的构造 service oriented architecture 三类角色 三类操作 三角关系,soa的过去,soa术语最早什么时候提出，由谁提出，已无从考证 相应思想、概念的出现可以追溯到二十世纪七十年代 2000年前后，随着相应技术的成熟和社会需求的变化，重新获得广泛的关注并迅速发展起来,面向服务计算的特点,松散耦合 服务交互双方不存在紧密依赖的关系 服务契约 服务双方是通过定义良好的契约进行交互 自治性 服务是相对独立的计算单元，具有显式的逻辑边界 抽象性 服务隐藏了实现逻辑，对外只展现服务契约 可重用性 服务是面向重用的、粗粒度的计算单元 组合性 可以通过组合一组现有服务构建新的服务 可发现性 服务可以被动态的发现和访问,面向服务计算范型的内涵,以服务作为基本单元 自治、面向重用 松散耦合 基于契约 通过服务协同构造应用 面向业务流程 支持快速、低成本的组合式开发 能够满足业务敏捷性需求 业务需求变更、计算环境变化 快速响应变化，对服务和协同作相应的调整,面向服务计算范型的优势,整合异构资源 有效保护和利用it资产 快速响应变化 适用于动态开放的internet计算环境 更加贴近业务，合理地分离关注点，支持高效的应用构建,面向服务计算范型的适用范围,异构、开放的计算环境 需要重用新、旧计算资源 要求快速响应变化 但性能问题是其瓶颈,基本开发过程,服务构建（service creation） 服务的构造与调整 服务组合（service composition） 通过发现、组合一组服务形成应用 服务演化（service evolution） 按需对服务和协同做相应的维护和调节,面向服务计算范型的分层视图,transport,data presentation,message format,messaging,qos,reliable messaging,security,description,policy,interface,binding,registry,coordination,transaction,服务计算的基本概念,web服务,web服务,web服务是当前最被广泛接受的面向服务计算范型（soa）实现 核心标准 soap：消息交互 wsdl：接口描述 uddi：注册中心 扩展规范 ws-*：基于核心标准所提供的扩展机制，以相互兼容的方式进一步增强与扩展web服务,web服务协议栈,http,xml,soap,messaging,qos,ws-rm,ws-security,description,*ws-policy,wsdl,*ws- transactions,ws-bpel,uddi,服务计算的核心标准,题外话,标准化组织,在soa领域，三个最主要的标准化组织对soa的发展做出了重要贡献 万维网联盟（world wide web consortium, 简称w3c） 结构化信息标准促进组织（organization for the advancement of structured information standards，简称oasis） web服务互操作组织（web services interoperability organization, 简称ws-i）。,w3c的标准化过程,w3c 正式发布的推荐标准，在技术上讲仅仅是关于进一步标准化的建议，但是由于该组织的权威性，这些建议往往成为事实上的标准。 工作草案(working drafts)，当草案准备递交时生成一个最后版(last call working draft) 候选推荐标准(candidate recommendations)，提出来供开发人员通过实现进行测试 提议的推荐标准(proposed recommendations)，准备进行投票表决 最后规范进入推荐标准(recommendations)状态，正式对外发布,web服务协议栈,完全基于开放标准的web服务很好的体现了soa的思想，是当前最被广泛接受的soa实现方式 历经近10年的探索，标准化组织、工业团体、研究机构共同协作构造了相互兼容的一系列web服务标准，以解决应用面临的各类需求，也使得web服务技术日渐成熟 下面将从web服务协议栈中的核心标准soap与wsdl开始，逐步介绍服务计算中的关键技术,服务计算的核心标准,soap,simple object access protocol,soap是一种在松散的、分布的环境中交换强类型、结构化消息的轻量协议 自由的传输绑定 (不仅仅是http) 自由的编码机制(xml文档、二进制) 可扩展的框架 (基于xml) 完全的中立 (中立、公开的标准) 独立于任何编程语言、对象模型、操作系统、平台,发展历史,soap最早由dave winner、don box和bod atkinson提出。 在1998年初，soap名字就已经被确定。userland在1998年发布了一个xml-rpc规范。 1999年9月soap 0.9提交ietf。 2000年5月，soap 1.1作为note提交w3c。ibm发布soap4j实现，并给开放源代码组织apache xml project。sun公司将web服务集成到j2ee中。 2000年9月，w3c组建了xml协议工作组，专门负责设计xml协议，以便成为基于xml分布式计算的核心。这个工作组将soap 1.1作为基础，并于2001年7月9日提交了第一份工作组草案soap 1.2。,soap的应用场景（1）,soap的应用场景（2）,soap,network protocol,intermediator,soap主要功能,定义通信单元的格式： soap信封、消息头、消息体 灵活的数据表示机制： 编码机制：如何序列化的soap消息以便通过底层传输协议传递 类型系统：xml格式与编程语言数据类型的映射规则 传输协议绑定 将soap绑定到http，因为http是internet上最常用的通信协议 也支持其他形式的绑定如smtp、jms soap消息的处理模型 定义soap节点接收到soap消息后的处理规则 交互模型 如何通过soap支持面向过程（rpc）和面向文档的交互模型 扩展机制： 使用xml模式和名字空间技术，灵活扩展元素,soap协议栈,encoding,soap消息结构（1）,soap 消息的顶层是envelope envelope定义了一系列soap词汇用于包装用户消息 其他协议可以采用自身特定词汇对soap消息进行扩展 使用namespace来区分彼此,soap消息结构（2）,envelope之下是由header和body构成的 header soap消息的接收者应该如处理消息 以及与该soap消息相关的附加特性，如：安全、事务、可靠传输等 header可用来实现web服务的扩展机制，是soap协议的主要扩展点 body 包含服务调用方和服务最终提供方的交互信息，是业务逻辑所需的有效数据,soap 请求消息, fx5q computer ,soap 响应消息, fx5q 8000.00 ,http传输soap,虽然soap可以和多种http请求方法联合使用，但这里只描述了soap如何在http post请求中传输。 soap利用http的请求/响应消息模型，将soap请求的参数放在http请求里，而将soap响应的参数放在http响应里 soap http响应：在http之上的soap遵从用于在http中表示通讯状态的http状态代码的语义。例如，2xx状态代码表明这是客户端包含soap构件的请求被成功的接收、理解和接受等等。 当处理请求的时候发生soap错误的时候，soap http服务器必须发出一个http 5xx “internal server error”响应同时在包含于该响应的soap消息中应包含一个soap fault元素,在http中使用soap,soapaction http请求头字段(header field)可以用于指示soap http请求的目的。它的值是一个标识该目的的uri。 post /stockquote http/1.1 content-type: application/soap+xml; charset=“utf-8“ content-length: nnnn . . . ,在http之上的soap遵从用于在http中表示通讯状态的http状态代码的语义。 http/1.1 200 ok content-type: application/soap+xml; charset=“utf-8“ content-length: nnnn . . . ,soap引擎体系结构,soap engine 解析报文 序列化 附加的qos保障 调用服务实现 构造响应消息 ,public class myservices public void mymethod (int x) return; , 5 ,服务计算的核心标准,wsdl,wsdl的历史（1）,xml、soap推动了web服务的出现。 为了描述web服务，microsoft开发了服务描述语言sdl和soap契约语言scl，ibm推出了可访问网络服务规范语言nassl。 ariba、ibm和microsoft在2000年9月公布了wsdl 1.0版本。,wsdl的历史（2）,当前唯一可用的标准wsdl 1.1 2001年3月wsdl 1.1成为w3c推荐标准，目前被广泛使用。 没有标准命的过渡wsdl 1.2 从2002年7月第1个草案到2003年6月最后一个草案共发布4个草案。 千呼万唤不出来的wsdl 2.0 考虑到wsdl 1.2相对于wsdl 1.1的显著变化，wsdl 1.2很快被重命名为wsdl 2.0继续开发。在该工作组为之奋斗6年之后，wsdl 2.0终于在2007年6月底成为w3c推荐标准。但该标准距离被广泛接受和支持仍有很长的路要走。,wsdl,wsdl的应用场景,服务发布者 开发部署web服务，利用工具生成wsdl文档并注册到服务注册中心 服务调用者 查找需要的web服务获得相应wsdl文档，用工具根据服务的wsdl描述生成客户端调用代码并访问服务 服务注册中心 分门别类地管理注册的web服务，并提供服务及其wsdl文档的查询,uddi,soap,wsdl,wsdl,wsdl,wsdl,abstract,porttype,concrete,wsdl的文档结构（1）,service,port,port,port,binding,operation,operation,operation,operation,message,message,message,types,type,type,type,wsdl的文档结构（2）,types 定义了消息中使用的数据类型 message 定义了交互中使用的消息 porttype 定义了服务所支持的操作集合 binding 为porttype指定具体的底层传输协议和编码方案 service 服务端点的集合,wsdl的文档结构（3）,从描述的层次来划分 抽象部分： 抽象部分是独立于平台、语言和传输的服务接口描述 因为抽象部分是所有服务的共性，因此形式上是固定的，不可扩展的 具体部分： 具体部分描述了依赖于特定底层环境的服务实现细节 具体部分因不同的服务绑定实现而迥异，因此形式上不固定，是可扩展的，具有极大的灵活性,wsdl的文档结构（4）,从描述的内容来划分 服务功能(what)： 主要描述服务能做什么。 对应于文档的抽象描述部分。 包含元素： 服务交互(how)： 主要描述应该怎样调用服务。 属于文档的具体描述部分。 包含元素： 服务寻址(where): 描述怎么样定位一个服务。 属于文档的具体描述部分。 包含元素：,wsdl的文档结构（5）,import元素为wsdl提供了一种在一个文档中引用另一个文档定义的元素的机制。这对wsdl文档的模块化和复用有很大的意义。 我们可以把一个服务的不同元素放在不同的文档里面进行定义，并借助import机制把其他文档中定义的元素引入到当前元素中来。一种典型的实现方法是把服务的抽象部分放在一个文档，而把服务的具体部分放入另一个文档，然后利用import把抽象定义的元素引入到具体部分定义的文档中来。,wsdl的扩展性,wsdl被设计成为一种可扩展的文档框架，我们可以灵活地扩展wsdl文档以支持： 新的类型系统 新的消息交换模式 新的传输协议 新的编码方案 新的qos保障 ,wsdl的扩展性: types,types元素封装了服务交换消息中用到的数据类型定义。wsdl规范允许types元素引入任意的类型系统来定义数据类型。 但是，为了得到最大的互操作性和平台中立性，wsdl强烈推荐使用xsd作为类型系统，并应该作为内建支持的类型系统。目前几乎所有的wsdl文档都是用xsd来描述其数据类型。,wsdl的扩展性: mep,porttype定义了服务支持的操作集合，每个操作又与一个消息交换模式（message exchange pattern, mep）相关，该mep定义了操作调用过程中消息交换的方向和次序，wsdl 1.1中规定了4种mep： one-way：端点接收一个来自服务调用方的消息 request-response：端点接收到一个来自服务调用方的消息，并回送一个关联的消息 solicit-response：端点发出一个消息给服务调用方，并收到一个关联的响应消息 notification：端点发出一条消息给服务调用方 除预定义的mep外，wsdl规范允许自定义特殊的mep,wsdl的扩展性: binding,binding元素描述了服务采用的底层传输协议和数据格式细节，wsdl 1.1中预定义3种标准绑定 soap绑定 http绑定 mime绑定 除预定义的绑定外，wsdl规范还允许自定义特殊的绑定，如：jms绑定能保障消息的可靠传输并提高消息交换的效率,wsdl 的相关工具,wsdl解析器wsdl4j 最早由ibm开发，并在axis等开源项目中得到进一步发展，支持对wsdl及其扩展信息的解析 wsdl4j提供了一个开放的框架，支持用户注册扩展元素的解析实现，自定义对扩展元素的解析方案 wsdl2java java2wsdl,wsdl 2.0的改进,wsdl 2.0相对于wsdl 1.1的变化： 组件命名的变化，更易于理解，如： porttype被重命名为interface port被重命名为endpoint 允许接口的继承 摒弃了message元素 禁止了operation重载 一个service中的所有端点必须实现同一个接口 支持更多的消息交换模式 支持更多的类型系统 增加了pox（plain old xml）/rest风格的服务支持,soap与wsdl小结,soap与wsdl构成了web服务协议栈的核心，它们具备如下一些共同的特点 功能方面 具有高度的互操作性 具有良好的扩展性 非功能方面 容易解析，利于代码自动生成 可读性好，利于学习理解 模块化设计，利于复用和组合 这些特点使得web服务的其他关键技术能够被逐步地添加，随着技术进步不断成长，最终构成功能强大的web服务协议栈,服务计算的核心标准,uddi,服务注册与选择简介,web服务注册和选择是soa体系结构中重要的一环，同时它也是动态web服务组合的基础 已有业务功能实现被包装为web服务时，需要把关于该业务功能提供的服务描述信息登记到一个公共可访问的地方 用户以某种方式在不同类型的web服务中找到其想要的服务,以执行web服务请求 以服务发现的自动化和智能化为目标,采用信息检索中的某些评价标准来评价web服务发现技术的性能,例如查准率(precision)和查全率(recall),在web服务协议栈的位置,bpel,ws-cdl,uddi,wsdl,soap,xml,xml schema,http,https,smtp,tcp/ip,service composition,uddi定义,uddi是一种使贸易伙伴彼此发现对方和查询对方的规范。它是最终用户通过搜索企业列表、企业分类或者实际web服务的可编程描述。uddi使查找产品和服