• 1. SOA 联通专用教程中程在线(北京)科技有限公司内部教程 注意保密
  • 2. SOASOA: Service Oriented Architecture, 面向服务的架构,或者说,以服务为基础搭建的企业IT架构. SOA的服务的理念思想,本质上是一种业务和技术完全分离,业务和技术又能自由组合的思想. 它达到了目前软件设计思想的最高境界.SOA的出现,预示着一个以服务为导向的新的IT时代的到来.
  • 3. IT的本质IT: Information Technology,信息技术,是为企业需要而出现的. IT本质上包括两种信息使用方式: 创建信息, 调用信息
  • 4. 创建信息在企业的各种生产活动中,如接收订单、原料采购、产品生产、发货、收款等活动,必然要产生大量的信息。这样就需要将各种信息整理和收集起来,以备以后的进一步调用。比如收到订单之后,就需要把客户的信息、所购买的产品、产品当时的报价等记录下来,以备将来发货和收款时使用。
  • 5. 调用信息在上面的实例中,接收订单后,企业开始从事生产,产品生产出来后,需要发货。就需要找到原来的订单上面的客户地址用来发货;同时找到当时的报价信息,用来催款。这就是调用信息的实例,也就是IT帮助企业创建信息和调用信息的实例。
  • 6. IT的进一步:集成信息只有创建信息和调用信息是不够的,还需要在创建信息的基础上,进一步集成信息,使所创建的信息得到更好的利用。 例如,企业把所有收集到的订单信息、销售预测信息集成在一起,作出企业的主生产计划。然后整个企业的生产都要依据这个主生产计划来执行,这是企业内部信息集成的实例,可以看到信息集成是非常重要的。
  • 7. 集成信息当企业把产品发货给下游的销售商之后,企业需要从下游销售商那里知道产品的销售状态,以便及时调整自己的生产计划,这样导致企业内部信息需要和下游销售商的销售信息进行集成。 当企业收到订单后,它可能需要向上游的相关的各个供应商购买原材料和零部件,当企业向上游供应商下订单后,它需要不断地追踪原材料和零部件的状态,如是否能及时发货,生产质量如何等,因为这些关系到自己的产品是否能按时发货。这样导致企业的生产信息需要和上游供应商的供货信息进行集成。这是IT帮助企业集成信息的实例
  • 8. IT程序语言发展史1. 面向过程的编程: 最早出现的大众化语言,C语言是最典型的代表,是一种紧密耦合的软件语言技术,用C语言编写的应用程序完成一大堆函数的编写,整个应用程序依赖于一些预定义的全局变量。函数的可重性很差。
  • 9. IT程序语言发展史2. 面向对象的编程: 将面向过程的相关的函数封装起来,消除全局变量,形成能够独立调用的对象。相对于面向过程的含有全部变量的编程,其耦合性已经降低。对象可以重用,可以继承和扩展。基于对象的各种设计模式也随之产生。然而对象之间还是有相互调用的现象。不存在一定的耦合性。这些对象只能本地调用,不能远程调用。
  • 10. IT程序语言发展史3. 将面向对象的程序进行封装,定义一些接口让外部调用。如J2EE(EJB), CORBA,DCOM等。 目的是为了实现远程分布式的调用。它有接口类,另外专门有实现方法类,因为它事先定义接口类,客户端调用的也是接口类。接口类和接品类之间实现了一定程序的解耦。即客户端调用接口类时,不需要知道接口类是如何具体实现的,不需要引用服务器端的实现类。但是客户端和远程服务器端的传输协议是特定的。如J2EE采用RMI传输协议,客户端需要安装特定的STUB程序。上述的组件编程需要和特定的程序实现语言绑定。传输协议也是非标准货摊,传输协议的不一致,导致各种不同组件之间无法互相调用,如J2EE和DCOM无法相互调用。(EJB,JMS)
  • 11. IT程序语言发展史4. 标准化的web service的编程:采用标准化的SOAP传输协议,不同厂商实现的web service之间可以相互调用。如J2EE提供的web service可以被.net来调用。客户端不需要知道服务器端是如何实现的,服务器端所用的是什么样的程序语言,客户端也不需要安装特定的stub程序。
  • 12. IT程序语言发展史从上面可以看出,IT程序语言发展的过程实际上是一个逐步降低耦合性的过程,也是一个接口和接口实现之间逐渐分离的过程。Web service的SOAP传输协议尽管是一种标准的传输协议,但仍是一个特殊的传输协议,一种特定的技术。Web service并不支持其它的传输协议,如RMI等,所以web service还是和特定的SOAP技术绑定在一起的。
  • 13. SOA的基本思想面向对象是对面向过程的一次解耦和封装,就是把面向过程的程序进行分解,把逻辑紧密相关的程序结合在一起,发布成独立的对象单元,对象单元里面含有API 面向组件的编程是将面向对象的程序进行进一步封装,发布成独立的组件,里面含有一些粒度大于API的接口。面向组件和面向对象的最大区别在于组件是通过传输协议来进行远程调用的,组件和传输协议绑定、应用程序服务器的端口绑定在一起的.
  • 14. SOA的基本思想理解了上面的编程思想,就可以进一步理解什么是面向服务了.面向服务的编程是对面向组件编程的进一步解耦和封装.所谓解耦,就是将业务组件和传输协议和端口解耦,也就是说业务组件可以自由地绑定各种传输协议.
  • 15. SOA的基本思想目前面向组件的编程,客户端在调用服务组件时,需要知道服务组件的传输协议,从而创建相应的客户端的调用程序来调用服务组件.如EJB组件,需要创建基于RMI的EJB的客户端调用程序;对象WEB SERVICE组件,需要创建基于SOAP的传输协议等.
  • 16. SOA的基本思想作为面向服务的编程,由于服务组件可以和各种传输协议自由绑定.这样作为服务的消费者,就不需要特别关心服务提供者的具体的技术细节,只需要知道有这么一个完全和技术无关的业务接口.可以把这种完全和技术无关的接口称为”服务接口”.作为客户,不需要去理解这到底是WEB SERVICE的接口还是EJB的接口.这个接口,只和业务相关,而和技术无关.
  • 17. SOA的基本思想所谓”服务”,就是只和业务相关,独立于技术的业务接口.所谓”面向服务”,就是如何实现独立于技术的服务接口. SOA是以服务为导向的架构,也可以进一步翻译为”以独立于具体技术为导向的架构” SOA是在WEB SERVICE的基础上发展起来的;而WEB SERVICE实现了松散耦合的服务和粗粒度的服务.
  • 18. SOA的基本要素SOA有3个基本的要素,只有这3个基本要素全部都满足了,这个应用才能称为SOA的编程. 1. 松散耦合 2. 粗粒度 3. 位置和传输协议透明
  • 19. 松散耦合松散耦合是指相互之间信赖,它是针对目前紧密耦合的应用系统所提出的一个概念,包括3个方面. 1. 服务之间的松散耦合: 不同服务的功能不要互相信赖, 一个服务应用能够自己实现所提供的接口功能(所谓自包含),不要信赖其它的服务.
  • 20. ATM取款机松散耦合的服务
  • 21. 松散耦合2. 接口和实现之间的松散耦合: WEB SERVICE已经实现了这一点,对于用WSDL定义的WEB SERVICE的服务接口,既可以用J2EE实现也可以用.NET实现
  • 22. 松散耦合3. 业务组件和传输协议之间的松散耦合: 这是目前的业务组件所不能实现的.如EJB需要RMI的传输协议,WEB SERVICE 需要SOAP的传输协议.JMS需要JMS的传输协议. 这是新的SOA思想所要实现的
  • 23. 粗粒度粗粒度的意义是SOA中服务的接口应该比面向对象的编程的API要大一些.需要更接近用户的实际操作. 以ATM取款机的取款功能 来说明这个问题.取款功能的实现可能实际要包括下面的3个API 用户身份校验: 系统需要确认用户输入的卡号和密码是否符合 账户是否有足够取款数额 取款: 以上两项都满足后,才真正付给用户现金
  • 24. ATM取款机取款功能的3个API
  • 25. 粗粒度作为SOA的业务接口,就不能将”用户身份校验”和”账户是否有足够取款数额”这两个API公布给用户,因为这样太细了.如果让用户必须操作完两个接口,最后再操作”取款”接口,则不符合用户的操作习惯.所以系统只能给出符合用户操作习惯的一个服务接口”取款”,它里面包含前面两个API功能
  • 26. 位置和传输协议透明位置和传输协议透明是SOA最根本的区别于目前面向组件编程的地方 目前的服务组件如EJB、WEB SERVICE、JMS的发布都是和特定的应用服务器绑定在一起的。如和四种常用的应用服务器。客户端必须知道具体的应用服务器的URL才能调用相应的组件。在全球一体化的情况下,各企业的服务集成是必然的,如果没有新的集成架构思想,会导致客户需要知道每一个服务组件的位置。如果某个服务组件的URL位置修改了,客户端程序必须要做相应的修改,否则整个集成不能工作了。这就是位置组件的不透明。
  • 27. 位置和传输协议透明所谓位置的透明,就是指不论服务组件的实际位置URL如何变化,客户端的调用程序的URL都不需要改变。 所谓传输协议的透明,就是指不管服务组件的传输协议如何变化,客户端的调用程序的传输协议都不需要改变。 目前的服务组件如EJB、WEB SERVICE、JMS都只能接收特殊的传输协议。
  • 28. IT的本质是信息的保存和调用。目前组件的位置不透明,实际上是对应信息的保存地方不透明;组件的传输协议不透明,实际上是对应信息的调用方式不透明。 SOA的思想是通过服务总线对目前的组件的接口进行进一步的封装(新的SCA编程模型可以自由绑定传输协议),将能保证服务的位置的透明和传输协议的透明。
  • 29. 目前的组件调用方式
  • 30. SOA的传输协议和位置透明的调用方式
  • 31. SOA的服务调用方式,传输协议和位置都是透明的。不论实际的服务者传输协议和位置如何修改,客户端都不需要相应的修改 任何传输协议指的是服务总线支持的传输协议。从理论上讲,服务总线应该能够支持任何的传输协议,否则就能称为服务总线,而只能称为某种或某些特殊协议的总线
  • 32. SOA的目标SOA的目标: 敏捷的, 不受限制的集成 随着全球经济一体化的深入发展,敏捷的,不受限制的集成业务的需求已经成为关键的业务需求。企业希望能够实现集成企业内外的信息,同时又能够随时更新这样的集成。目前由于种种的障碍便得企业无法实现这样的集成
  • 33. 传统的集成方式需要把自己的程序(Stub代码)插入到对方程序的代码中,是一种紧密耦合的集成方式。 传输协议的非标准化。如DCOM和EJB组件之间不能相互调用 信息格式的非标准化,导致服务请求者和服务提供者之间 无法进行有效通信 应用组件和传输协议的紧密耦合。如EJB使用RMI协议 接口调用的非标准化。XML的接口调用方法和JDBC的接口调用方式是不一样的,导致XML文件系统的信息资源和数据库的信息资源无法直接集成
  • 34. SOA通过应用组件和传输协议的松散耦合(服务的传输协议的透明化),服务的即时绑定(服务位置的透明化),从而实现业务组件的虚拟化,造就一个虚拟的集成架构或者集成平台服务总线(应用服务器的进一步升华),这样使得服务集成不受任何限制,可以同时集成.NET组件 和J2EE组件,以及集成其它遗留系统的各种应用,现时也可以随时更换这些服务组件。最终达到敏捷的,不受限制的服务集成目标,从而使用IT能够随着业务需求的变化而自动调整,达到随需而变。
  • 35. SOA概述“Service Oriented Architecture,” ,面向服务的架构,或者说,以服务为基础搭建的企业IT架构。SOA是一个完整的软件系统建构体系,包括运行环境、编程模型、架构风格和相关的方法论等。其核心是服务,并涵盖服务的整个生命周期,建模-开发-装配-运行-管理。SOA的核心理念是业务驱动,采用松耦合的、灵活的体系架构来满足随需应变的业务需求。
  • 36. 服务服务是SOA的核心词。从技术概念而言,服务与模块或者功能的概念类似,是用于封装特定功能的一个实体。但是,值得注意的是,服务的核心理念是业务,服务定义了一个与业务功能或者业务数据相关的接口,以及约束这个接口的契约,是粗粒度的。
  • 37. 服务服务是中立的,不依赖于特定的技术和平台。服务的注册、获取可以通过服务注册库管理。多个服务可以被组装成一个业务流程,完成一个特定的业务功能。由此可见,服务是可重用的,一个定义良好的服务可以被用于组装多个业务流程。这也是SOA和服务被比喻成乐高积木的原因
  • 38. 分层结构SOA架构是一个分层的结构,从最底层的功能性服务,到原子服务和服务构件,到顶层的业务流程服务,目的是最大限度地封装不同的服务,从而达到复用的目的。无论哪一个层次,其核心都是服务——简单的和复杂的。一个复杂的服务组件是由不同的原子服务组成,用于提供业务流程所需的功能
  • 39. SOA的概念架构模式
  • 40. 服务总线SOA概念是企业服务总线(Enterprise Service Bus, ESB)。将服务组装成业务流程是目标,但是应该如何实现?点到点的连接是一个方式,可是这种方式增加了系统的复杂度,并降低了服务的可重用性。为了实现真正的SOA,我们需要一个中间层,来完成服务交互、组装、管理的功能。这就是ESB产生的缘由
  • 41. 服务总线ESB采用的是总线的概念,支持服务的即插即用,以消息流转为沟通方式,以标准为基础,可以跨平台、跨技术(如下图所示)。形象地来讲,ESB像一条流动的河流,承载着不同的船只(数据)到达相应的码头
  • 42. SOA计算环境的组成部分
  • 43. 整合以服务为核心的体系架构可以提供松耦合、异构的企业级计算环境。这是企业IT架构的设计思想的一个革新——以业务为导向的设计,而并非传统的技术架构导向。这一SOA架构直接的好处是:企业级整合变得更加得心应手,无论是在一个垂直系统内部,还是跨部门的整合,甚至是跨企业的行业整合
  • 44. 整合重用定义好的服务,无论是包装已有系统功能,还是新开发的业务功能,甚至是采用合作伙伴所提供的服务。这是一件很好的事情,不仅节约了企业内部的投资,还可以创收——向外部的客户和合作伙伴提供服务!理念的变革是,由自给自足变为开放,成为服务的提供者和集成者。
  • 45. SOA编程模型
  • 46. 服务作为构建SOA的一个基础组件,服务具有下面一些特征: — 服务是可以独立操作的。每一个服务都能够提供相应的操作,能够很容易地被独立调用,其执行并不依赖于架构中的其他组件和服务。操作是通过标准方式封装和发布的。
  • 47. 服务— 服务是自描述的。其使用标准的描述格式定义了服务提供的操作和消息格式,无论调用者和被调用者都无需关心其他信息,如地址、实现技术等。
  • 48. 服务— 服务是松耦合和异构的。服务的使用者和提供者可以是分布部署的,可以位于不同的系统平台上,可以使用不同的技术实现。
  • 49. 服务 服务是可组合的。使用相应的服务组装技术,例如流程编排技术,可以将多个简单的服务组装成一个更加复杂的服务。这一过程是可递归的。这一特性极大地提高了服务的灵活度和计算能力。
  • 50. 服务服务是动态的。已发布的服务是可以被动态发现和绑定。 — 服务是标准和开放的。只有在标准的基础上,企业中不同部门或者不同供应商的服务才能够动态地组织到一起提供业务流程。供应商的独立性和互通性是服务的目标
  • 51. 服务服务可以包装已有的应用或组件。这一特性使得服务的领域变得更加广泛,并且可以使现有资产可被重用,保护已有IT投资。 — 服务是有质量保障(QoS)的。
  • 52. 服务的概念模型
  • 53. 服务是可以自描述并独立注册发布的。在一个服务请求者需要使用某个特定业务功能的服务时,可以先在服务管理者,即服务注册中心中发现符合要求的服务——可能得到一个服务列表,因为不同的供应商会提供同一服务(这也是一种竞争)。服务请求者可以根据需要决定使用哪一个服务,也就是服务绑定,然后就理所应当地使用选定的服务了
  • 54. SCA业界逐渐得到广泛认可的一个服务封装技术是服务组件架构(Service Component Architecture,SCA)。SCA是一个跟实现语言无关的服务组件编程模型,可以很好地处理服务网络的建构,因此提供了基于SOA简化开发的解决方案。
  • 55. SCA的主要特点SCA是用于建构服务的,是松耦合的。 —  SCA是一个跟实现语言无关的组件编程模型。SCA提供了统一的调用方式,可以把不同的服务类型,比如POJO、EJB、BPEL、JMS、Web服务等都通过统一的接口来封装调用。这使得整合已有的异构系统成为可能
  • 56. SCASCA还支持不同的通讯协议,如Webservices、JMS、Rest、JSON/RPC等。 —  SCA隔离了业务逻辑和具体技术实现。这使得开发者能更集中于业务逻辑而非技术细节,也极大地提高了业务逻辑的灵活度——可以采用不同的服务实现而无需改变业务逻辑。 —  SCA提供了许多面向企业计算的QoS能力。
  • 57. SCA结构和组装
  • 58. SCASCA的这些特性使得企业应用具有良好的分层架构,能够很好地分离业务逻辑和技术逻辑,使应用易于构建、易于部署、易于变更。这些特性,恰恰是SOA中服务所需要的
  • 59. 数据和消息模型 在SOA的世界里,消息意味着企业的效益,因为其包含的业务数据代表实际发生的交易,数据的丢失等同于是现金的流失。从这个角度而言,一个完备的、丰富的消息数据模型是必需的。
  • 60. 数据和消息模型 同SOA服务建构技术相辅相成,不同的服务有不同的消息定义方式。比如说,Web服务采用SOAP消息作为其数据表现。相应地,和SCA伴生的技术是服务数据对象(Service Data Object,SDO)。SDO以对象为中心的,层次树型数据模型,是一种最贴近业务表现的方式。
  • 61. 数据和消息模型 SDO基于离线数据图的设计理念如下图所示。数据图是一组树型结构或者图型结构的数据对象。离线的访问方式是指客户端从数据源提取并构建数据图,然后在应用中操作数据图,并在变更摘要(Change Summary)中记录相应的数据操作,在动作结束后由数据访问服务(Data Access Service)批量地将相应的改变反映回数据源,其中数据源可以是异构的,并不仅仅限于关系数据库。
  • 62. SDO基本结构
  • 63. SDOSDO的数据表现形式基于数据对象(Data Object)和数据图(Data Graph)的概念,其封装形式和Java类和XML有水到渠成的映射关系。同时,SDO提供了丰富的数据操作接口——动态接口和静态接口,还可以用XPath来直接访问相应的数据对象属性。
  • 64. SDOSDO所解决的另外一个问题是异构数据的兼容性,提出了一个简单并统一的模式供服务处理其相关的数据。开发人员可以用SDO统一其数据访问和处理模式,即使这些数据来源于异构数据源——关系数据库、XML数据、Web服务或者是企业信息系统。
  • 65. 服务编排SOA编程模型的第三个方面是服务编排。诚然,SCA规范中已经包含了服务组件和组装的概念,但是其并非一个严格意义上的服务编排。在考虑业务流程的编排时,希望流程是可视化的、可定制的、灵活的,并且是可管理的。
  • 66. 服务编排一个服务编排模型需要满足SOA松耦合和异构的要求,并且需要是敏捷的。反观BPEL,具有下面的一些特点: — 基于服务。BPEL在对多个服务进行调度与协调,本身只定义业务流程相关的逻辑,而具体的功能则由其所调用的服务来实现,与BPEL无关。BPEL从规范的定义上就自然而然地支持Web服务,但并不仅仅限于Web服务,也可以支持SCA所定义的服务。
  • 67. 嵌套性由服务编排而成的BPEL业务流程可以被封装为一个新的服务,提供更加复杂的业务功能。这一点充分体现了服务的可嵌套性。
  • 68. 松耦合性BPEL定义本身只需指定相应的接口即可,不需要指定实现该接口的服务。BPEL致力于业务逻辑的表现,而相应的实现服务完全可以在部署甚至运行时确定。同时,流程与所调用的服务之间以异步的XML文档形式传递消息,不直接与服务的实现打交道。因此BPEL流程和所调用的服务之间是松耦合的,他们可以独立地进行替换或修改,而不对另一方产生影响。
  • 69. 服务质量、交易和生命周期的管理BPEL并不仅仅是简单的服务装配,还支持长时间的流程定义,以及有状态的交互,并且提供了相应的失败处理和补偿机制。不仅如此,还有相应的服务质量(QoS,Quality of Service)和事务处理机制等。
  • 70. 高度的敏捷性正是由于BPEL具有高度的松耦合性和可重用性,才具有敏捷性的特点。
  • 71. SOA的标准协议栈
  • 72. SCA,用于定义服务,是构建SOA的基础元素。 SDO,用于表示服务中流转的数据,是业务操作的核心。 BPEL,用于编排服务,是业务流程的体现。
  • 73. 在SCA里使用Spring Spring通过实现的方式融入SCA的体系。
  • 74. SDO简介 SDO的目的是把开发人员从处理数据的底层技术中解放出来,从而更关注业务逻辑。放在SOA的大框架下,SCA关注服务,不同的服务用一致的方式来使用,并可以用一致的方式来构建;BPEL关注流程,把各个服务按需要串起来;SDO关注数据,数据整合在SDO之下,这样SDO数据就可以像血液一样,在BPEL流程里无阻碍地流动。
  • 75. 服务整合的目的是为了流程的整合。真正的商业流程是一系列的、各种类型的服务的调用。业务逻辑也反映在商业流程中。当一系列服务汇入流程的时候,应该尽可能地把技术细节屏蔽掉,不能让技术细节干扰了业务逻辑的编写。
  • 76. BPEL流程本身也以由WSDL所描述的接口声明为Web服务。在这里,BPEL实际上作为Web服务的一种实现向外界提供服务调用,实现了与Web服务的无缝兼容,同时也为子流程或嵌套流程的定义提供了解决方案。
  • 77. BPEL是一种基于XML的标准,只描述业务流程本身,而并不关注业务流程的图形化表示,也不涉及业务流程的设计方法学。不同的厂商可以基于BPEL规范在流程建模工具中提供自己的图形化界面来表示BPEL流程。
  • 78. BPEL是以流程规则的定义为中心的,并不是一般意义上的数据操作语言,因此BPEL的数据操作支持应以保证流程建模的需要为基础,提供相对简单的数据操作,比如消息的构建,变量的提取与赋值,简单的数据表达式等。而复杂的数据操作和数据存取功能则应交给BPEL过程所调用的服务来完成,而将结果返回给BPEL过程。
  • 79. 任何流程在执行过程中都可能有异常和错误情况发生。因此BPEL必须将错误和异常情况的处理放在与业务流程本身同等重要的地位。业务流程可能是长期运行的流程并跨越多个事务边界,一旦某个环节发生异常,不可能将整个流程执行中所发生的结果都进行回滚
  • 80. BPEL应提供可定制的错误处理和补偿机制,可在定义流程的同时,根据流程自身的特点、异常类型以及实际需求,定义相应的错误恢复或补偿操作,以应对相应的异常情况。
  • 81. BPEL定义了流程的模板。在BPEL流程的执行环境中,同一个流程模板可以生成多个BPEL流程实例。同时BPEL的服务调用是松耦合的,它所调用的服务不会保留BPEL的实例信息。在BPEL流程与一个服务进行异步交互时,如何将属于同一交互的消息路由到正确的流程实例,是BPEL必须面对的问题
  • 82. PEL提供了消息与流程实例的关联机制以解决该问题。为了保持Web服务的实现无关性,这种关联机制必须依赖于业务数据,也就是消息中所携带的业务数据,而不是实现相关的数据,如流程实例的标示符。
  • 83. BPEL规范定义了关联集合(correlation set)的概念用于消息和流程实例的关联。用户将一组业务属性定义为关联集合,关联集合必须唯一确定一个BPEL流程实例
  • 84. BPEL运行环境将消息路由到与该关联集相匹配的流程实例。而且,对于流程中不同的接口,用户可以定义不同的关联集合,以适应不同的业务需求。
  • 85. BPEL本身可以作为Web服务的实现向外界提供服务调用。Web服务是一种无状态的服务描述,而BPEL作为多个服务的协调服务可以看做一种有状态的服务。对外的无状态性以及自身的有状态性,决定了对BPEL实例的生命周期管理必须是隐含性的
  • 86. 生命周期的隐含性意味着流程实例的创建和销毁是由BPEL运行环境根据到来的消息自动进行的,不需人工干预。因此BPEL服务的调用者也就不能通过Web服务调用直接对BPEL的实例进行管理,如实例的创建,运行实例的挂起与继续,实例的销毁等
  • 87. BPEL规范特点基于开放的Web服务标准,易于实现跨系统、跨部门、跨企业的互操作。BPEL的调用对象是Web服务,本身也可以作为Web服务向外提供服务,因此与现有的Web 服务标准相融合。由于Web 服务是开放标准,已被众多的企业所采用,BPEL使建立跨企业的业务流程成为可能。
  • 88. 高度的松耦合性。BPEL可看作是对多个服务的调度与协调。BPEL本身只定义流程相关的逻辑,具体的功能则由它所调用的服务来实现,与BPEL无关。由于BPEL调用的对象都是一致的Web服务接口,BPEL定义本身只需指定相应的接口即可,不需要指定实现该接口的服务。相应的实现服务完全可以在部署甚至运行时确定。
  • 89. 流程与所调用的服务之间以XML形式传递消息,不直接与服务的实现打交道。因此BPEL流程和所调用的服务之间是松耦合的,他们可以独立地进行替换或修改,而不对另一方产生影响。
  • 90. 服务的重用性。由于BPEL流程的调用对象是服务。一个服务在被一个流程调用的同时也可向其他流程,其他客户提供服务。同时BPEL流程本身也可以封装成流程向客户提供服务或是作为子流程为其他流程所重用。这种服务的可重用性为企业的流程管理减少了开发成本,同时也提高了维护效率。
  • 91. 高度的敏捷性。现代企业的业务需求随时都在改变以适应千变万化的市场。这种需求的快速改变也相应对企业的IT基础设施提出了更高的要求。
  • 92. 在企业的业务需求改变时,相应的IT设施必须能够快速调整为新的业务需求提供支持。从业务流程的角度来说,相应的业务流程必须能够容易的、快速的甚至是动态的改变才能满足这一要求。正是由于BPEL具有高度的松耦合性和可重用性,才使其具有敏捷性的特点。
  • 93. BPEL相关技术
  • 94. XML是所有标准的基础,它为定义标准提供了表述的形式。XPATH则针对XML文档提供了定位某一数据的手段。 XML Schema是定义标准的标准。 XML Schema由XML进行描述,提供了定义标准的语法。SOAP,WSDL以及BPEL均使用XML Schema进行定义。
  • 95. 在BPEL中,XML Schema还被用来定义业务流程的输入输出变量以及中间变量。SOAP为服务调用过程中的消息交换提供了消息的封装标准。WSDL是BPEL流程及其参与者交互时的接口描述语言,同时BPEL流程本身也以WSDL为接口标准对外提供自己的服务。由于BPEL是一种实现无关的标准,其运行环境及其他相关工具可用J2EE、.NET等作为实现平台。
  • 96. Web Service的运行环境则为BPEL流程提供了服务的发布,查询,调用等功能。BPEL则关注于定义流程逻辑,实例关联,错误处理,事件处理,变量定义等与业务流程本身相关的标准。
  • 97. Web服务是Web时代的产物,它可以使得任何信息或服务,无论其原始的实现如何,都封装成统一的形式。用户不需要知道其功能是如何实现的,只要拿到它的接口描述便可以直接访问该服务
  • 98. (本页无文本内容)
  • 99. Web服务屏蔽了客户与服务提供者之间的系统差异,使得客户可以很容易访问或调用所需服务。Web服务提供以功能为单位的调用标准,目的是对功能的实现进行基于标准的封装,对服务的调用者展现统一的调用接口,而屏蔽服务的实现细节。它是一种无状态的功能调用。
  • 100. 当用户需要以某种定制的次序或规则调用多个功能或服务时,Web服务标准本身就显得无能为力了。而这恰恰是BPEL所关注的焦点。因此,BPEL关注于相对独立的服务或功能的组织和协调,从而在整体上形成具有业务价值的业务流程,而所形成的流程作为整体又可以以服务(service)的形式提供给客户。
  • 101. BPEL是基于Web服务的,是指它的标准特别是服务的调用以及自己向用户提供服务的标准以Web服务为基础,尽量不定义新的标准。BPEL标准所定义的是多个服务调用的协作以及流程的规则,而服务的提供与调用与Web服务相兼容。
  • 102. WSDL即Web服务描述语言,用于定义在一个Web服务交互中所需的消息,接口类型,接口参数以及绑定等。下面的XML文档说明了一个WSDL的一般结构。
  • 103. wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"                  targetNamespace="the WSDL namespace"                  xmlns:tns="the WSDL namespace"                  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap">                                                         
  • 104. 在定义一个WSDL接口文档时,一般先定义该WSDL所需要的数据类型(type)。当然,数据类型也可以用import元素直接从外部定义文件引入。然后定义消息(message),这些消息将被接口操作定义引用,作为操作的输入输出参数或错误消息定义。定义消息所需要的数据类型应该已经定义或引入。
  • 105. 端口类型(port type)实际上就是WSDL的接口定义,其内部定义了该接口所拥有的操作(operation)。操作的输入输出参数将引用消息的定义。绑定(binding)定义了调用Web服务时,输入输出消息采用什么样的协议进行传输。
  • 106. 务(service)则定义了访问该服务的URL,也就是指出了用户如何才能调用接口提供的服务。可以看出,绑定和服务的定义是与实现相关的定义。而消息及接口的定义则是与实现无关的定义。
  • 107. 假设一个网上商店提供网上直接下订单的Web服务。用户提交订单信息,系统处理订单后返回订单处理结果。消息的传递将采用soap document的方式进行绑定,服务的访问地址是http://virtualwebshop.com/OrderProcess。相应的WSDL文档如下所示:
  • 108.                                                                < xsd:sequence>                         < xsd:element  name="orderId" type="string"/>                         < xsd:element  name="productId" type="string"/>                         < xsd:element  name="price" type="string"/>                                                          
  • 109. BPEL与Web服务示意图
  • 110. BPEL使用WSDL作为服务调用的接口定义标准。实际上,BPEL通常使用WSDL定义以下信息:
  • 111. 服务的端口类型(port type)定义; BPEL流程的伙伴链接类型(partner link type)定义。伙伴链接类型是WSDL对BPEL的扩展; BPEL流程的属性(property)及属性别名(property alias)定义。属性及属性别名也是WSDL对BPEL的扩展。
  • 112. 服务的端口类型描述了服务将要调用的接口和对外提供的接口以及它们所包含的操作和操作所用到的参数定义。在SOA中,参数通常是符合SDO标准的业务对象,由XML Schema文件定义。WSDL接口定义将引入业务对象的定义,并将其指定为某个操作的输入输出参数。
  • 113. BPEL的伙伴链接类型是为了描述BPEL流程及其参与者的交互以及它们在交互中的作用。伙伴连接类型会引用端口类型定义以指出本交互需要调用的接口,同时还定义了交互的角色(role),以指出本流程在这个交互中是服务的提供者,还是服务的调用者。
  • 114. 属性别名则是将某个变量属性或消息部分(part)映射为另一属性名,这样就可以将多个不同消息的部分映射为同一属性名,从而认为它们实际上是同一属性,只是属于不同消息而已。下面的代码实例分别将InputMessage中的orderId和OutputMessage中的orderId映射到了属性OrderNumber上。BPEL流程的关联集合(correlation set)可以引用这一属性将不同消息关联到同一个流程实例
  • 115.  BPEL流程构成示意图
  • 116. 变量在BPEL流程中表示流程的中间状态,也用做服务调用时的输入参数以及接收服务返回的结果。BPEL中的变量既可以是WSDL中的消息定义也可以是XML Schema所定义的复杂类型或元素。
  • 117. 关联集合实际上是一组属性的集合。在WSDL定义中,通过将多个属性别名定义引用到同一属性上而获得不同消息部分的关联。关联集合用来确定到来的消息将路由到哪个流程实例。
  • 118. 活动是BPEL业务流程的基本构成单位。BPEL规范将活动分为基本活动和结构化活动。基本活动执行变量分配,服务调用等基本任务,它对BPEL流程来说是不可再分的执行单元。而结构化活动是基本活动和结构化活动的容器,它对其内部的活动按照一定的规则执行,如串行执行活动对其内部的活动以串行的方式进行执行,而并行活动则对其内部的活动以并行的方式执行等待。可以看出,活动将构成业务流程的逻辑框架
  • 119. 在业务流程的执行过程中可能发生错误或异常情况,如网络通信错误,服务调用失败等,BPEL规范定义了错误和补偿处理机制。错误处理和补偿与正常的流程逻辑分开,在流程发生错误时,可以对相应的错误进行处理并对已执行生效的操作通过补偿操作的方式进行定制的撤销。
  • 120. 事件处理器为BPEL流程提供了接收并处理随机事件的能力。这里的事件可以是消息事件,即外部服务向本流程发送的消息,也可以是时钟事件,即某个预定的时刻到达或预定的时间长度得到满足而发生的事件。
  • 121. BPEL的活动是通过伙伴链接调用外部服务的,同时BPEL流程也通过伙伴链接向外界提供服务。BPEL活动还可能引用已经定义的变量作为输入输出参数以及引用关联集合进行消息与流程实例的关联。在必要时,错误处理器可以定义在流程以及活动级别上处理错误发生的情况。
  • 122. BPEL流程服务调用示意图
  • 123. BPEL引擎 BPEL文件是一个XML文档,它可以用文本或XML编辑软件手工编写,但手工编写BPEL文件效率低,易出错,而且还要求BPEL文件的编写者对BPEL标准非常熟悉。因此有专门的BPEL设计工具来完成BPEL文件的生成工作。BPEL设计工具提供图形化的用户界面,BPEL标准的所有组件在BPEL工具中都有图形化的表示。
  • 124. 流程设计人员只需要了解所设计流程的业务需求就可以使用BPEL设计工具的图形界面来设计自己的流程。BPEL设计工具将根据用户流程的图形设计自动生成符合BPEL标准的BPEL定义文件。生成的BPEL定义文件将作为输入,由BPEL引擎执行。BPEL引擎中的流程实例的运行情况将由BPEL管理工具进行监控和管理
  • 125. PEL模板定义文件由BPEL设计工具输出。BPEL引擎将根据BPEL模板定义文件的流程定义,生成相应的流程实例。一般来说流程实例由符合BPEL流程定义中的消息接收活动相应条件的消息激发而生成。因此一个BPEL定义模板可能生成多个流程实例
  • 126. 业务流程实例在BPEL引擎中可能是长期运行的,BPEL引擎可能使用数据库等持久化机制来存储流程实例的中间状态信息以及流程的管理控制信息。BPEL引擎可以基于任何平台开发和运行,如J2EE,.NET平台等。
  • 127. BPEL工具及引擎关系图
  • 128. BPEL引擎的典型模块图
  • 129. (本页无文本内容)
  • 130. BPEL引擎利用Web服务处理器接收Web服务消息,如果需要生成新的流程实例,BPEL引擎将根据消息类型与消息内容,从文件系统或数据库得到相应的BPEL定义模板生成BPEL流程实例。如果消息需要发送给现存的流程实例,消息将由消息路由器关联到相应的BPEL流程实例
  • 131. 当流程实例需要调用Web服务时,该调用将由BPEL引擎中的服务调用处理器借助Web服务处理器调用伙伴服务提供者所关联的服务。事件处理器将对流程执行中所发生的事件进行处理,如特定消息到来事件,时钟超时事件等。
  • 132. BPEL与SCA、SDO相结合提供流程服务
  • 133. 业务集成示意图
  • 134. SOA的生命周期
  • 135. 建模(Model)阶段是通过理解业务需求而获得业务流程设计的过程。在设计的初期,可能由于对业务需求理解的还比较粗浅,业务流程的设计也会比较粗糙甚至存有歧义或错误,但随着对业务需求理解的逐步深入,业务流程的设计也会逐渐细化并走向正确。如何表达业务流程是这一阶段面临的问题
  • 136. 可以用自己定义的流程符号在纸张上画出流程的设计思想,也可以用现有的流程图绘制软件表达流程的设计思想,其目的都是希望别人特别是下一阶段的流程设计人员能够理解自己的设计意图。但这种方式只能局限于较简单的流程和较小的项目团队。实际上,这一阶段应有专门的工具以及标准的建模语言予以支持。参与这一阶段的人员通常是业务层面上的流程分析人员,他们具有精深的业务知识但并不一定具有丰富的IT知识
  • 137. 用BPEL进行建模并不合适。这一阶段的建模语言应该能够直观的表达流程逻辑,不需专门的IT知识,具有丰富的语义能够表达丰富的流程逻辑模式。当前具有代表性的是业务流程模型注解(Business Process Modeling Notation,BPMN)由业务流程模型互操作组织(Business Process Management Initiative,BPMI)定义,用于业务流程的建模并可以映射为BPEL定义。
  • 138. 集成(Assemble)阶段,软件架构师将和业务分析师一起将建模阶段的业务设计转换成一系列的业务流程定义(将以BPEL定义)以及活动,并根据活动定义分析获得所需服务组件。服务组件应首先在现有的系统中寻找,有的组件可能会完全适合,有的则需作调整,有些则需要创建新的服务组件。
  • 139. 所需服务组件具备后,就可以按照业务流程的定义将它们集成在一起,并进行调用绑定,安全设置,事务设置,资源依赖等的配置。这时业务流程已经是可执行的流程,项目已经准备好部署到运行环境中执行了。集成阶段的支持工具能够将建模阶段的输出导入,创建新的服务组件以及对现有的服务组件进行集成。此外集成工具还可对每个服务组件进行单元测试,以及集成测试,保证集成阶段业务流程的正确性。
  • 140. 部属(Deploy)阶段,集成阶段完成的项目将被部属到运行环境上从而实现业务上的需求。部属阶段应根据实际的业务需求,充分考虑运行环境的配置,如是否采用高可用性配置,是否需要负载均衡,数据库的配置,安全策略的配置,消息中间件的配置等。
  • 141. 管理(Manage)阶段,管理阶段将基于相应的软件工具和技术对运行环境中的服务和流程进行管理和监控,发现系统运行错误,恢复系统状态,获得关键性能指标,发现性能瓶颈。管理阶段所获得的业务流程的性能数据和运行统计数据还会反馈给建模阶段以对流程进行不断的优化。
  • 142. 业务流程是对现实世界的业务需求的抽象,我们可以抽取业务流程中的共性的逻辑形成模式以便流程建模时进行重用。业务流程的建模语言如BPEL也定义了专门的组件(在BPEL中称为结构化活动)来表达基本的流程模式,对于更为复杂的模式,我们可以用多个基本模式的组合来达到要求
  • 143. 串行执行模式
  • 144. 条件选择模式
  • 145. 事件选择模式
  • 146. 循环执行模式
  • 147. 重复执行模式
  • 148. 重复循环执行模式
  • 149. 并行执行模式
  • 150. SOA总结Service Oriented Architecture Concept SOA是一种分析、设计和实现企业应用的方法 SOA是一种分布式的应用架构 SOA以服务为最基本的、可重用的单元 SOA以业务流程为核心,是对业务逻辑高层次的、粗粒度的抽象
  • 151. SOA总结 SOA一般基于某些标准(XML\SOAP\Web Service\SCA\SDO)实现异构系统及服务的集成 SOA 不仅仅是一套构架,其更像是一套设计思想、方法——为解决客户所面临的业务敏捷性问题提供了一套新的解决方法。
  • 152. SOA特性松耦合 服务之间的依赖较小 基于契约的 应用由服务之间定义良好的接口和契约联系起来 自治的 服务提供商完全控制其所提供的业务逻辑
  • 153. SOA特性抽象的 对服务消费者来说,服务隐藏了具体业务逻辑的实现 可重用 将业务逻辑划分为多个可重用的服务 复合的 通过服务的复合完成业务功能 可发现的 服务是自描述的,基于服务描述去发现和访问服务
  • 154. SOA进化从业务需求角度看企业应用的发展阶段: 信息发布 即传统的Information Management System,在这个阶段最主要的任务是把某一个业务下的信息数据管理起来。 企业系统的内部整合 当企业内部绝大多数信息系统都已经建立之后,是否能够有效地进行协作和资源整合,成为主要解决的问题。 企业内部的信息系统与外部环境整合 这包括与供应商、分销商和客户进行整合。
  • 155. SOA进化从技术发展角度看企业应用的发展阶段: 从软件架构的角度: 结构化(Structured) 面向对象(Object Oriented) 组件(Component) 服务(Service)
  • 156. SOA开发工具IBM工具系列 ORACLE工具系列 BEA工具系列