关于BPEL

 

在企业应用集成中，可以使用工作流程和BPM结合的方式来协调各个应用，但是WEBSERVICES 中必须要有一种标准来让无论是计算机人员和业务人员都能懂的东西。这种东西既结合计算的程序又综合了工作流程的概念，BPEL就是其中最流行的标准。

 

通过BPEL可以将很多的WEBSERVICE集成起来，通过工作流的形式来自动执行。在集成的过程中，单个的SERVICE的实现部分保持非透明化，也就是说，在BPEL里面用到得只是每个SERVICE的接口（WSDL）而不用管，每个SERVICE在自己的地盘是怎么实现的。BPEL只要知道每个SERVICE 的功能，物理地址，和需要的参数就可以了。这样即使单个SERVICE改变或者变化也对BPEL流程没有太大的影响。这也就是composition of web services的原理：应该调用什么服务，什么时候调用，如何处理异常等等。

 

BPLE具体的结构和细节是如何的？

BPEL实际上也是一个基于XML的文件。

在BPEL中的一个显著特点是定义了不同的 partnerlink, partnerlink定于了这个流程中各个服务所处的地位(role), 比如说bpel中有一个查询票价的服务接口，那么对于这个查询票价的服务就处于一个SERVICE的地位，那么BPEL过程本身就是一个requestor 的地位。

在BPEL总定义好了partnerlink后也要在相应的服务接口文件中定义partnerlinktype，这个type实际指向的就是服务接口文件（WSDL）中的porttype.

 

像一般的流程图一样，BPEL有自己的活动标签。

Receive: 接受信息

Reply:  对之前接受到得信息的相应，同时它还可以返回一个异常。

Invoke: 调用一个相应的服务

Sequence: 按顺序执行一定的活动

Flow: 一些活动可以同时进行。

Switch: 按照情况选择需要执行的活动

Pick: 等待某些活动的完成

Wait: 等待一定得时间

While: 循环

Assign: 复制的操作

 

在FLOW中可以定义一些links元素，用来作为导向的功能

Link 使用连接两个活动的。

活动中可以定义source 元素 或者target元素， source 元素内可以指明满足的条件，当满足条件时，就走到相应的target.

 

Link 中的JoinFault的处理： 当所有导向摸个活动的links都为FALSE的时候，这个活动就应该被跳过，而且从这个活动导出的LINKS也应该被置为FALSE。这个处理可以通过BPEL的suppressJoinFault=”yes” 和在相应的活动中加入 joinconditon来判断。

 

FaultHandling:

BPEL中的异常处理可以是全局的也可以是局部的，可以讲faulthanding加入到整个过程中或者加入到一个局部的scope中，一般的处理FAULT是当异常发生时，中止活动，并转向相应的FAULTHANDLER，这点于compensation handler不同，compensation handler是指当异常发生时，不仅活动会终止而且，之前所有的完成的工作都会被重置为最近的那个没活动发生的状态。

关于workflow(工作流程)：

 

什么是工作流程？

工作流就是一系列相互衔接、自动进行的业务活动或任务。 注意这里的业务活动都是自动的非人力的，在计算机领域也就是传说中的自动化过程。

工作流的出现动力是因为，企业应用集成的发展需要将一系列的商业活动以自动化的，流线型的方式来执行，传统的点对点形式不能满足日益增加的商业过程中的应用和新技术的发展。所以工作流在应用集成方面是一个很好的工具。

 

在当前，企业的应用集成一般是通过一个central bus来连接每个单个的应用，这里需要每个单个的应用有自己的接口,这个接口和WSDL有相似的含义。

在BUS上有很多不同的ADAPTOR，这些ADAPTORS 和每个单独应用的接口相连接，通过这个ADAPTOR可以把每个应用的数据映射为一个共同的模式，在BUS上还会有一个MESSAGE BROKER，这个东西是用来协调ADAPTOR之间的互动的。通过这样的方式，企业各系统之间的异种性就被隐藏了。

所以设计一个EAI的平台关键的步骤就是设计ADAPTOR和MESSAGE BROKER。

 

综上所述，MESSAGE BROKER 隐藏了系统的异种性，而且工作流程则起到了应用集成和增加应用互动性的功能。所以这两个可以结合起来。也就是将工作流程和EAI平台两者相结合，这样既隐藏了系统的异种性，有起到了增加各应用之间互动的作用。工作流程也可以通过一个工作流程ADAPTOR和EAI平台相连接。这样工作流程管理系统就能和企业的其他应用相互互动。

 

那么工作流程管理系统到底能干什么了？

工作流程管理系统是一个软件平台，用来设计，发展，分析，和管理工作流程。

工作流程管理系统就决定了自动化执行一个商业过程，这个商业过程什么时候执行，由谁来执行都能够由工作流程管理系统来自动决定。

 

那么什么是商业过程？

商业过程就是为了达到一个商业目标所需要执行的一系列商业活动的集合，比如发表一篇论坛就必须经过查询资料，开始写，教授审查，发表等等活动，每个活动的执行者和使用到的资源都不一样。

 

工作流程是一个导向图，一般包括起始，结束，工作，和导向节点，每个节点的功能都不相同。

 

工作流程的工作原理是，首先从工作流定义库中搜索工作节点，通过分析，将它们放到对应的资源队列中去（资源可以是人或者计算机）。

 

将BPM和工作流程相结合起来，就出现了一下几点部件

1.       Task: 不能再细分的工作单位

2.       Sequence 某些工作需要按一定顺序执行

3.       Selection 基于默写情况来处理一定得工作

4.       Parallel:   某些工作可能可以平行处理

5.       Synchronization; 某些工作需要等待其他工作的完成才能进行

6.       Iterator: 某些工作需要重复循环的处理

在BMP和工作流程的结合中：

长方形代表单个的task, 圆圈代表一定join 和 split操作， join 有and join 和 or join,同样split 有and split 和or split.

 

基于Petri Net 的工作流管理系统

有两个重要部件，一个是places 存储了一系列的token,对象，比如说一个发送请求，一个客户的投诉等等。

还有一个部件叫tansition，这个决定了之前token的走向，这种构造方式将一个商业过程模式化为了许多个不同的状态，比如说初始化的places 有三个客户投诉，流程图的构造是两个places 中间一个transition, 那么这个商业过程的初始状态就是(3,0),当transition 将第一个places里面的一个投诉转移到第二个places里面后，状态就变为(2,1)了。

 

判断一个transition是否激活的标准时在places里面至少有一个token.

Token可以属于多个transition, work item 是属于transition 的，当时间到达，信息到达或者发生了一个事件，那么这个transition里面的workitem就被分配给某个资源来执行，这个时候称为fireing of transition, 当它处于fireing 的阶段时候，就被称为活动了。

 

在Petri Net中有几种split, 叫or- split, or split 可以分为可以决定的和不可决定的两种，可以决定的是当满足某种情况的时候就进行工作，输出可以个多个，不可以决定的or split包括了可决定的情况，当preconditions重叠的时候就不可决定，反之和决定形的效果一样。

 

 

关于Rest

Rest 到底是个什么东西？

 

Rest 就是一种联网系统的架构风格。比如说SOAP的网络服务的架构风格是服务定义特定的接口，客户通过接口可以了解服务能够干什么和怎么与服务进行互动。但是Rest 的服务与基于SOAP的服务不同，它没有像基于SOAP的那些服务那样有一个接口说明（也就是著名的WSDL）。

 

对于REST而言，整个WEB世界是由许多资源所构成了，你要和一个网络服务互动，只能通过4个特定的服务接口模式：put, post, update and delete.这四个操作是基于REST架构的网络服务的标准活动。这些活动和servlet的doget, dopost相似。

 

如上所述。REST是将WEB上的东西定义为资源（resourse）,那么所有与网络服务相关的就是对资源的获取操作等等了。每个基于REST 架构的服务都要给每个资源指定特定的URI，这个URI是非常重要的而且是极其方便简洁的。客户通过一个设计好的URI可以直接获取需要的资源。

 

那么设计REST 架构的目的是什么？ 很明显，使用REST架构就是为了很好的获取网络的资源。。。。

 

资源到底是什么？

 

资源就是一系列的操作和数据集合。

在REST 架构中，资源是通过一系列数据格式来代表的比如说：XML,JSON,TXT等等。

比如客户要获取自己的账户信息，那么客户根据这个账户信息特定的URI，可以得到自己的资源。服务器端通过XML格式，或者JSON格式返回这个资源给客户。

 

 

REST架构的服务的特点：

1.       首先REST架构有两个方面：客户端和服务器端

2.       统一的接口：put, post, update, delete

3.       资源都是很好命名好的，而且是通过一个设计良好的URI来获取，资源之间也是通过URI来联系互动的。

 

既然REST架构的服务的资源都是通过URI来引用的，那么必然导致一些复杂查询语句的产生。

Rest架构的服务的数据代表格式有两个重要： XML 和 JSON

JSON其实也是基于XML的。

 

那么设计一个REST架构的服务需要什么原则

1.       主要的是对每一个资源定义一个有效的，命名规范的URI，不能使用动词，一定要用名词。

2.       把资源分类，只能读的资源分为一类，不仅能读而且能写的资源分为另外一类。

3.       所有的资源通过服务器返回的只是服务器资源的一个代表，读取资源不能对服务器的资源产生任何的影响。

4.       通过URI来连接资源，同样资源之间的连接也是通过URI来联系的（超连接）

5.       通过一个说明文件向客户阐述这个基于REST架构的服务是怎么操作的。这个说明文件是必须的但是这个说明文件和基于SOAP的服务的WSDL是不同的。

 

既然你设计原则确定了，那么到底应该怎么建立一个REST 服务了？

首先，编程语言是无关紧要的。其次，需要一个支持HTTP协议的服务器，因为REST架构的服务基本是基于HTTP的。第三，定义好REST架构服务的接口，也就是这个服务支持的一些方法： 比如说doget(), doPost(), doUpdate(), doDelete().这跟基于SOAP的服务不同，基于SOAP的服务将方法接口定义到WSDL里面，而REST 将方法接口说明放到一个说明文件里面。

第四，在每个方法里面都要定义好特定的URI等等。最后，定义返回的资源以一种什么样的数据格式来返回给客户，比如是返回XML格式还是JSON格式，还是纯文本格式了。

 

 

基于REST 架构的服务和XML-RPC服务，SOAP服务的不同：

XML-RPC服务： 客户端发送一个请求，这里牵涉到一个xmlrpcclient对象和xmlrpcserver对象， xmlrpcclient可以远程对象xmlrpcserver. 在服务器端，xmlRpcServer接受客户请求并执行相应的操作。

客户发送的请求是以XML格式传说过去的，服务器端返回的数据也是以XML格式传说过来的。这种服务凭借的协议是HTTP-POST，发送一个HTTP-Post 然后得到一个reply.

 

基于SOAP的服务，是XML-RPC服务的进化版本，将数据封装到一个SOAP里面。。。。

Rest 和 SOAP

REST：将WEB看成是一个有资源所组成的世界，仅仅基于HTTP协议。

SOAP: 将WEB看成是一个互动的，每个应用通过信息传输所构成的世界。不仅仅是HTTP协议，可能还有其他协议。

 

REST和SOAP服务在设计的不同：

对于SOAP， 需要定义一个接口说明（WSDL），数据类型，合适的传输协议，注册发布服务。

对于REST， 定义各种资源，使用很好的URI来指向这些资源，区分只读和读写的资源，定义资源之间的超连接，发布服务。

REST 和 SOAP各有个的好处。SOAP比较适合于B2B（business to business）而REST比较适合于B2C。所以将两种构架结合起来是未来网络架构形式的一个趋向。

UDDI: 存储了一些服务的接口说明文件，简单来讲就是存储了一些WSDL。

一个web service 要公布于世，就必须让自己在UDDI上注册，这样才能让客户来寻找和查询它的功能。

一般的， 注册机包含了两个部分：

1.       document-based: 存储WSDL的说明文件

2.       meta-based: 只提取说明文件的精髓内容

 

service provider, service registry, service requestor 之间的关系式：

首要进行service discovery:

Service discovery 分为静态和动态两个部分

静态： design time, 由设计人员检测

动态:   run time, 提供preferences, 选择合适的服务。

 

一个最基本的流程是：

N个服务提供者发布服务在UDDI， 然后一个服务请求者发送一个查询请求（SOAP），然后这个请求者会得到很多满足要求的服务列表，然后选择一个好的服务，再发送一个请求，然后UDDI可以把这个最好的服务的WSDL发给请求者，接下来，这个请求者就可以通过这个WSDL建立PROXY来利用所选择的服务。

 

UDDI的具体结构是如何的？

UDDI的结构和通常的电话本很相似：

包括：

1.       white page: 服务提供者的联系信息

2.       Green page: 也就是服务的porttypes

3.       Yellow page: 关于上面的说明信息。

 

在技术上称为:

1.       Business Entity: 记录了服务提供者的信息

2.       Business Service: 包含了一些列的binding template

3.       Binding template: 指向一系列的tMODE

4.       Tmode: 指向WSDL的实际网络地址(port) 和porttype

 

UDDI能够有效的进行服务的生命周期管理： 一个服务换了地方或者换了其他什么东西

UDDI 充当了一个中间者对于服务的改变，而且保持了服务的更新

比如如果之前的服务出了错误，可以再次访问UDDI，更新新的服务WSDL

 

什么是SOAP?

SOAP就是网络上传说数据的一个协议（简单来讲）。

SOAP定义了服务传输的数据格式，一个显著的特点是SOAP是基于XML语言的。

它包括了四个元素：

1.        Envelope element: 指出了这个信息是SOAP格式的。

2.        Header element: 定义了一些格外的关于这个SOAP信息的应用信息

3.        Body element: 这里就是数据坐落的地方，也就是客户的请求信息和服务的返回信息

4.        Fault element: 指出了服务操作过程中产生的一些错误信息，和程序中的异常相似。

对于header element, 它有三个属性：

1.       Role: none(SOAP处理器不会处理这个header), next(下一个), ultimaterReceiver（最终的节点）

2.       Mustunderstand: 中间的处理器必须正确的处理这个信息，否则就返回错误信息。

3.       encodeingStyle: 表示这个header 的内容是怎么编码的，这个可以告诉处理器如何解码内容。

Fault 元素是在处于body 元素之内的，它有许多属性：code, reason, Node, detail

Code: 值叫value, 表明出错的位置

Reason: 表明出错的原因

Detail: 如果错误是出现在最后的节点，那么可以使用这个属性。

SOAP ENCODEING： 指示了特定的元素是怎么编码的。比如说XML的格式是多样化得，对于计算程序，不同的XML格式可能产生不同的结果。所以encodingStyle就定义了特定元素的XML 格式。

 

关于SOAP有两个重要的区分对于SOAP-RPC和 SOAP-DOCUMENT

SOAP-RPC： 在body元素里面，方法和参数的个数是严格定义的，首先是方法名字，接下来是方法的参数。这样的方式可以让XML里面的东西直接映射为一个对象。

SOAP-DOCUMENT： 在body 元素里面，所有的方法和参数都直接是body的字节点。就是把所有需要的数据封装起来发送给服务。在encodingStyle里面指明特定的语义机构这样服务就可以理解和懂得这个SOAP结构。这种模式可能需要花费一点时间来让服务端理解和懂得结构。

 

所以常用的组合式SOAP-RPC-encoded 和 SOAP-DOCUMENT-literal

 

在数据传说的协议定义之后，那么接下来就是服务的接口定义

服务的接口定义描述： WSDL

描述了一个服务可以实现的功能和需要的参数，但是它并没有指明服务的功能函数执行的顺序。

客户可以根据特定WSDL产生一个proxy, 利用这个可以连接远程的服务。

WSDL 分为两个部分： 服务接口定义部分（定义这个服务可以提供的功能，参数和抽象数据类型）和服务实现部分（将服务的接口绑定一个特定的物理网络地址，实际的数据等等）

 

服务接口定义部分（service-interface definition）:

Types: 定义数据类型

Messages: 定义功能需要用到的参数

Operation: 定义了功能

Porttype: 包含了operaton 和 message, 同时message 可能用到types里面定义的数据类型。

 

服务实现部分：

Binding: 将接口绑定到一个实际的功能，详细阐述功能和功能参数的细节。也就是implements了接口部分定义的porttype. 同时它还定义了信息的编码格式和协议细节，比如这个信息是以SOAP协议来传输的等等。

Service: 提供服务一个实际的物理地址，可以让客户来获取。

 

如前面所述，构成webservice 需要三个标准: SOAP, WSDL, UDDI

关于WebService 的总结：

首先 WebService 是企业应用集成的一个体现， 那么什么是企业应用集成了

对于传统的企业，在内部多半应用点对点的交流方式， 这种点对点交流方式最大的缺点是随着服务和应用的增加， 交流连也随之增加， 对于N各应用，就需要N(N-1)/2 个交流链。

为了适应服务和应用，以及和客户之间联系的促进， 现代的企业应用集成正满足了这个需要。

那么到底什么企业应用集成：

企业应用集成就是把企业的硬件，软件，业务流程等等联合起来，实现企业间的无缝连接， 使得它们像一个整体一样分享业务信息和业务流程。用来满足那些传统的点对点模式所不能满足的逐渐增加的服务需要。

一个应用集成包括： 内容获取， 集成的应用之间的数据内容需采用一定得语句或者语义比如XML。信息流： 集成应用之间的信息传输，传输方式等等。内部和外部商业过程的集成。还有安全性的问题。

 

应用集成包括了哪几个层：

首先是商业处理层（business process layer）:这个层主要定义了企业必须懂得企业之间商业过程的流程。企业之间必须对他们之间的商业活动达成一定得共识。比如说企业A和企业B必须对他们之间的购买商品的顺序 和 商品的发货方式达成一定得共识。而且对于完成这个商品交易的过程都必须对A和B 是透明的。双方必须都懂得。

这也就是服务的接口描述，每个服务都必须有一个明确清晰的接口描述（WSDL）

 

其次是内容层（content layer）：企业必须懂得和理解需要购买的产品，订单的创造就是在这个层产生的。

 

最后是数据交流层(communication layer): 在集成应用中，必须有一个统一的方法来传输各个应用之间的信息和数据。比如说WEBSERIVCE是用SOAP来实现信息和数据的传输的。

 

那么企业的应用集成到底包括了那些了：

1.       用户界面集成： 提供一个集成的企业门户，比如说企业的浏览器

2.       数据集成： 集成应用将异种的和不同应用的数据集成一个整体的数据模式。

           代表性的实现方法是：EII（企业信息集成）

3.       应用集成： EAI，workflow, SOA

Composite application: 将当个的应用集成在一起（mash-up）不仅集成了商业逻辑层，而且将presentation layer 也集成在一起

 

既然WebService 是企业应用集成和SOA构架的一个实现，那么

什么是WebService?

 

定义1： WebService 就是一个能够由特定的URI所表示的软件应用，这个软件应用有一个明确的接口说明，在说明里面描述这个Webserivce 所具有的功能和参数。 这个软件应用通过基于XML的传输协议来传输数据。

 

定义2： WebService 是一个软件系统，用来支持网络上的相互的机器对机器的互动。 它具有一个机器能处理的接口说明，定义了功能和参数， 并且以XML 来传输数据。这样基于不同编程语言或者平台的应用程序都可以调用这个软件系统。

 

 

在面向对象的角度， WebService就是一个远程的对象，那么要调用这个服务就必须有一种调用远程对象的机制。传统的RPC就是一个调用远程对象的机制，它能让本地来调用远程的方法， 但是RPC 是基于过程语言的仅仅支持同步的交流而且不是面向对象和没有接口的概念。微软的COM,DCOM实现了对象的调用，但是它们有一定规则需要遵守。

 

目前比较流行的是JAVA RMI，基于JAVA 语言的远程对象调用机制。

 

综上所述，尽管有很多这样的远程对象调用机制，但是这些调用机制都必须满足下面的三个条件：

1．  Directory Services: 也就是定位远程对象。

2．  Interface Definition: 远程对象的接口定义， 使得客户的应用程序知道怎么调用它

3．  Communicaton: 必须定义个数据交流的格式而且这个数据交流应该是对于客户不可见的，隐藏的。

 

Webservice 有三个标准: UDDI(服务查询)， WSDL（服务接口说明），SOAP（服务数据传输协议）

 

同样webService 有三个roles:

1.       Service provider: 这里必须有一个服务的提供者

2.       Service registry: 必须有一个像电话本一样的机制来存储各种服务的接口说明

3.       Service requestor: 这里必须有个服务的请求者，也就是客户。

 

在WebService 中充当数据传输任务的是一个叫SOAP的传输协议，是由微软发明的