CN1805345B - Web服务工作流处理器 - Google Patents

Abstract

本发明公开了一种Web服务工作流处理器，包括：接口适配单元，用于接收请求并将请求信息及后端所需的信息封装成统一的消息格式，所述后端指服务调用单元；组合服务处理单元，用于根据所述消息各式中的信息选择与其匹配的工作流实例来处理该请求，所述工作流实例指若干个相关的Web服务按照一定流程在工作流引擎系统中运行的实例；服务调用单元，用于根据所述组合服务处理单元的需要选择相应的Web服务并将所述Web服务执行的结果返给所述组合服务处理单元。本发明能够支持多种Web服务语言，而且具有可扩展性。

Description

Web服务工作流处理器

技术领域

本发明涉及计算机软件中间件领域，尤指一种Web服务工作流处理器。

背景技术

Web服务(Services)工作流是刚兴起的一个领域，Web Services工作流处理器将若干相关Web服务按照一定业务流程执行运转，相当于一个引擎，目前主要有Collaxa和IBM公司提供了相应的产品。

Collaxa公司提供的BPEL Server支持BPEL4WS标准，它实现了对BPEL4WS标准比较全面的支持，提供了一套比较完善的监控管理机制。系统也具有一定的可移植性，可以在多个应用服务器上运行；还实现了对多种服务实现体的支持。

IBM公司提供的BPWS4J支持BPEL4WS标准，它为BPEL4WS标准提供了一个简单的运行管理环境。系统也具有一定的可移植性，可以在多个应用服务器上运行；也实现了对多种服务实现体的支持。

发明内容

本发明要解决的问题是提供一种能够支持多种Web服务语言的Web服务工作流处理器。

为了解决上述问题，本发明Web服务工作流处理器的技术方案为：

接口适配单元，用于接收请求并将请求信息及后端所需的信息封装成统一的消息格式，所述后端指服务调用单元；

组合服务处理单元，用于根据所述消息各式中的信息选择与其匹配的工作流实例来处理该请求，所述工作流实例指若干个相关的Web服务按照一定流程在工作流引擎系统中运行的实例；

服务调用单元，用于根据所述组合服务处理单元的需要选择相应的Web服务并将所述Web服务执行的结果返给所述组合服务处理单元。

所述接口适配单元包括：

若干适配器，用于接收请求并将请求信息和后端所需的信息提取出来；

处理上下文，指一种消息格式，用于存放所述若干适配器提取出来的信息。

所述组合服务处理单元包括全局实例管理器和若干语言实例管理器，其中：

全局实例管理器，用于根据所述处理上下文中的信息将其传递给相应的语言实例管理器；

语言实例管理器，用于根据所述处理上下文中的会话信息把所述处理上下文中的信息传递给正在运行的工作流实例来处理，或者创建工作流实例来处理请求。

所述语言实例管理器包括：

存储结构，用于存放正在运行的工作流实例；

语言文档解析器，用于根据Web服务工作流语言文档的地址解析出与其对应的内存对象；

文档对象存储结构，用于存放经过语言文档解析器解析后的业务流程文档；

若干解释器，用于解释Web服务工作流语言文档；

解释器生成器，用于根据Web服务工作流语言文档生成与其相应的解释器；

会话管理器，用于根据所述处理上下文中的相关器字段来判断请求是否属于正在运行的工作流实例，若属于正在运行的工作流实例，从存储结构中找出对应的流程控制块(简称fcb)并把所述处理上下文中的信息转发给与其相应的解释器；否则调用语言文档解析器以创建工作流实例。

与现有技术相比，本发明Web服务工作流处理器的有益效果是：

由于接口适配单元能够将请求信息封装成统一的消息格式，组合服务处理单元能够根据所述消息格式中的信息选择与请求信息相应的Web)]良务工作流未处理请求，使得本发明Web服务工作流处理器能够处理各种Web3良务工作流语言的请求，因而能够支持多种Web3良务语言。

本发明是在WebSASE这样一个Web Serv北e应用支撑环境中得以发明和实现的。

WebSASE是为WebService提供一个统一的开发、部署、运行和管理平台，它具有一定开放性和可扩展性，足一个拥有自主知识产权的Web Service运行管理平台。

然而，尽管Web服务技术解决了不同的平台/系统之间应用的整合问题，为跨企业边界的业务流程的自动化提供了技术基础，但单个的Web服务所提供的功能单一，无法构成完整的业务应用。一方面考虑到组件的重用性和可维护性等原则，不应该将复杂的业务逻辑封装到单个的Web服务中；另一方面从服务提供者的角度来看，各种服务的提供者分工越来越明确，单个服务提供者不太可能能够提供完整功能的Web服务；因此为了实现完整的业务功能，满足用户多样性的需求，需要把分散的各个Web服务组合起来，形成具有增值价值的Web服务。

但由于Web服务技术本身是无状态的，不能支持服务之间复杂的交互，而跨企业流程往往是由一个确定的过程模型驱动的长期的多方的交互过程，因此需要其他的技术来把Web服务组合起来创建新的功能。这种组合的结果表现为一个自动执行的处理流程，它与传统工作流有很多共同的处理特征，但由于Web服务处在一个开放的、松散耦合的环境中，以及Web服务组合的动态组合机制决定了只能在运行时进行Web服务的动态发现、绑定与调用等特殊性，从而不能基于传统的工作流语言和管理系统来构建Web服务组合处理系统，因此如何实现Web服务的组合成为Web服务领域的研究热点。

而Web Services工作流作为一类特殊的Web Service，也应提供对它的运行和管理系统支持。当前Web Services工作流的发展集中在两个方面：标准和规范的制定以及相应的支撑系统的研发上。在标准规范的制定方面主要是各大技术提供商和标准化组织在进行相应的工作，但不同的标准化组织支持不同的Web Services工作流语言标准，这给相应的支撑系统的研发也提出了很大的挑战。而当前已有的支撑系统都只是提供了对某种特定的Web Services工作流语言的支持，从而限制了它们的应用范围。因此我们认为需要为不同的Web Services工作流语言提供一个统一的运行环境，同时该环境需要具有良好的可扩展性，从而能适应标准的变化。同时，我们认为不同的语言具有很大的共性，因此需要抽象出来一种统一的运行对象，通过该对象来屏蔽不同的语言的差异，从而达到统一的执行和调度的目的。最后，我们认为引擎内部和引擎之间应采用统一的管理技术，因为在统一的管理之下，能极大的简化原本复杂的管理操作，从而更好的满足不同的管理需求。

附图说明

图1是本发明Web服务工作流处理器的结构示意图；

图2是BPEL实例管理器结构；

图3是典型的XSLT转换过程；

图4是事件生产者-中介-事件消费者模型；

图5是事件生产者-事件消费者模型；

图6是本发明运行时机制示意图；

图7是本发明具体工作流程示意图；

图8是采用本发明技术方案的一个例子的示意图；

图9是采用本发明技术方案的另一个例子的示意图。

具体实施方式

如图1所示，本发明Web服务工作流处理器包括：

接口适配单元1，用于接收请求并将请求信息及后端所需的信息封装成统一的消息格式，所述后端指服务调用单元；

组合服务处理单元2，用于根据所述消息各式中的信息选择与其匹配的工作流实例来处理该请求，所述工作流实例指文档解析器翻译BPEL或WSFL语言，将其转化为程序中的可执行对象，这个对象就是流程实例；

服务调用单元3，用于根据所述组合服务处理单元2的需要选择相应的Web服务并将所述Web服务执行的结果返给所述组合服务处理单元2。

所述接口适配单元1包括：

若干适配器，用于接收请求并将请求信息和后端所需的信息提取出来；

处理上下文，指一种消息格式，用于存放所述若干适配器提取出来的信息。

由于不考虑重复实现前端接收Web服务请求的SOAP引擎，因此考虑到系统的通用性和可移植性，必须为不同的SOAP引擎提供对应的调用接口，并向后屏蔽不同的SOAP引擎，从而保持系统各个部分之间的相对的独立性，利于系统的升级和维护。因此在该层中，针对不同的SOAP引擎的接口，提供了专门的适配器来接收它们传递过来的SOAP消息和一些必要的其他配置信息，然后进行创建一个统一的消息格式-处理上下文，并把接收到的信息赋值给处理上下文。如果有些处理上下文所需要的信息不能从SOAP引擎的接口得到，则适配器还需要读取系统的配置文件来取得所需的信息。当创建完处理上下文后，接口适配单元1就把消息传递给组合服务处理单元2。

所述组合服务处理单元2包括全局实例管理器和若干语言实例管理器，其中：

全局实例管理器，用于根据所述处理上下文中的信息将其传递给相应的语言实例管理器；

语言实例管理器，用于根据所述处理上下文中的会话信息把所述处理上下文中的信息传递给正在运行的工作流实例来处理，或者创建工作流实例来处理请求。

组合服务处理单元2是本发明Web服务工作流处理器的核心部分，它完成对组合服务的处理。然而由于不同的Web服务工作流语言所采用的模型各不一样，例如：WSFL(Web Service Flow Language，Web服务流程语言)采用的是有向图的方式，XLANG采用的是结构化的方式，而BPEL(Bussiness Process Excution Language，业务流程执行语言)，因此若设计一个单一的可以支持各种模型的运行系统是非常困难的。基于此考虑，在采用本发明技术方案的系统中采用了分而治之的方法，借鉴了JMX(Java Management Extensions，Java对象管理可扩展框架)中JMX服务注册中心对Mbean(Managerable Bean，可管理组件)职责交给具体的实施者，这样只需要实现给定的要求，就可以把实现加入到系统中，接受系统的统一的管理。在这里我们通过提出两个约束来来对此提供支持：

结构约束：当需要增加对其他的Web服务组合语言的支持，应该按照给定的结构进行设计；

接口约束：当需要增加对其他的Web服务组合语言的支持，则必须实现一些规定的接口；

通过第一个约束，可以缩短开发支持新的Web服务组合语言的时间；而通过第二个约束则保证了开发出来的系统可以被集成到当前的系统中。

当处理上下文传递给组合服务处理单元2后，全局实例管理器首先捕获到该请求，然后根据处理上下文中的信息确定是否已经加载了相应的语言实例管理器，如果已经加载则把处理上下文传递给已加载的语言实例管理器处理；如果在加载的语言实例管理器中没有找到匹配的语言实例管理器，则全局实例管理器重新读取配置文件查看是否已经定义了所请求的语言实例管理器，如果在配置文件中找到则加载该语言实例管理器，否则把错误报文作为处理结果返回。

所述语言实例管理器包括：

存储结构，例如fcb存储结构，用于存放正在运行的工作流实例；

语言文档解析器，用于根据Web服务工作流语言文档的地址解析出与其对应的内存对象

文档对象存储结构，用于存放经过语言文档解析器解析后的业务流程文档；

若干解释器，用于解释Web服务工作流语言文档；

解释器生成器，用于根据Web服务工作流语言文档生成与其相应的解释器，本例的解释器生成器为每一个文档对象生成一个对应的解释器，而不是生成一个全局的解释器来供所有的文档对象使用，这种方式虽然由于多创建对象而牺牲了一部分内存空间，但这样就可以使得各个运行的工作流实例能够同步执行，一个工作流实例出现异常也不会影响到其他的工作流实例的执行；而且因为每一个工作流实例拥有一个解释器，从而避免了解释器在各个工作流实例之间进行切换时所需要的很大的开销；

会话管理器，用于根据所述处理上下文中的相关器字段来判断请求是否属于正在运行的工作流实例，若属于正在运行的工作流实例，从fcb存储结构中找出对应的fcb并把所述处理上下文中的信息转发给与其相应的解释器；否则调用语言文档解析器以创建工作流实例；

fcb创建器，FCB创建器负责创建一个代表一个Web服务组合实例的FCB对象，然后填充其中的各个字段的内容，创建完成后把该对象注册到FCB存储结构中，然后通知会话管理器实例创建完成。

下面以支持BPEL工作流语言的语言实例管理器为例来说明语言实例管理器的实现。

首先介绍BPEL中会话的实现机制。在BPEL中提出了相关器的概念来实现会话。相关器是一个消息中的某一个字段的引用，如一个订单请求中的订单号，服务请求者和服务提供者之间通过这个相关器(此处为订单号)来相互识别对应的业务流程实例。

如图2所示，会话管理器根据文档中定义的消息相关器来判断是否请求的消息是属于对正在运行的工作流实例还是需要创建新的工作流实例来处理该消息；如果是属于正在运行的工作流实例，则从FCB存储结构中查找出对应的FCB，并把消息转发给FCB中的解释器进行处理；否则调用BPEL的语言文档解析器创建新的工作流实例。

BPEL语言文档解析器根据给定的BPEL文档的地址，解析出对应的内存对象。在解析上本例采用了XSLT(Extensible Stylesheet Language Transformations，可扩展标志语言转换)技术来进行文档到对象的转换。XSLT是在XSL(Extensible Stylesheet Language)上发展起来的基于XML的语言，用于将XML文档转换成其他的格式，如HTML、WML、甚至Java对象等其他格式，它通过XSLT处理器和预定义好的XSLT模板来对目标XML文档进行转换。

如图3所示，在XSLT样式表中包含了一系列的处理指令，这些指令定义了如何把XML文档转换成其他的格式，而具体的转换工作则由XSLT处理器完成。

通过XSLT，只需要针对一个Web服务组合规范(BPEL或WSFL的Schema)，写出对应的XSLT样式表以及各个标签的Java对象表示，就可以容易的实现对该语言的解析。

由于BPEL采用的是一种结构化的描述方式，活动的类型繁多，关系复杂，因此在解释器的设计上本例采用了事件生产者-中介-事件消费者的模型。在该模型中涉及到了三个角色：

事件生产者：该角色负责创建事件和把事件发送给中介。

中介：负责把接收到的事件发送给对该事件感兴趣的事件消费者。中介作为一个独立的对象存在，所有的事件都先发送给中介，再由中介转发给事件的消费者。

事件消费者：该角色接收到特定的事件后自主进行相应的处理。

如图4所示，BPEL解释器的运行过程为：

事件消费者把自己注册到中介中，同时告知中介自己能处理的事件类型；

事件生产者在某个时刻，如活动执行完成后发出活动执行完成的事件给中介；

中介接收到该事件，查找出所有能处理该事件的事件消费者，然后把该事件发送给它们。

在这种方式中，事件的生产者和消费者是多对多的关系，它们之间不需要相互知道对方，只需要知道中介和事件的类型就可以进行通信，而且事件的消费者可以动态的注册和注销，从而很好的降低了对象之间的耦合度。但正是因为存在一个中介而带来了额外的开销。因此如果对象之间的关系比较明确和稳定，则采用的是该模型的一个退化模型；在退化的模型中取消了中介这个角色，事件生产者和事件消费者之间进行通信。

如图5所示，退化模型的运行过程如下：

事件消费者把自己注册到事件消费者中；

事件生产者在特定的事件发生后，给所有向自身注册的事件消费者发布事件；

事件消费者对事件进行处理，并在需要时回调事件生产者提供的事件处理接口。

在解释器的设计上，根据对象之间的关系，本例综合采用了这两种事件模型，实现了对BPEL文档对象的解释执行。

本例的文档对象存储结构以散列表的形式存放经过BPEL解析器解析后的业务流程文档，它为BPEL文档解析器提供快速的查找机制。该结构以业务流程文档文件名作为键，文档对象的引用作为值。由于解析文档耗时非常多，故需缓存文档对象，可避免重复解析的开销，因而缓存已经解析后产生的对象可提高效率。

本例的FCB存储结构以散列表的形式存放正在运行的工作流实例，通过该存储结构会话管理器可以快速的查询到正在运行的工作流实例，从而一方面可以查询到工作流实例的各种信息，并可以将管理控制台发送给对应的FCB。

如图1所示，组合服务处理单元2还包括一些基础服务，这些基础服务提供了系统运行时所需的一些必要的功能，本例包含的功能有SOAP解析器、XPath解析器、事务客户端、数据库连接等。

SOAP解析器：SOAP解析器的功能是从给定的SOAP消息中提取出所需的各种信息，如从消息头部提取出会话标志符，从消息体内取得请求的操作的名、参数等。

Xpath(XPath是定义XML文档元素的语法规则集合-XPath使用路径定义XML元素)解析器：其功能是解析使用XPath描述的各种条件表达式。XPath是用来从XML文档中提取信息的语言，它通过对XML结点操作来取得所希望的数据。在BPEL和WSFL中都采用了XPath来描述条件表达式。

事务客户端：提供了进行事务处理的接口。在Web服务组合中，业务流程自身常常需要和其他的Web服务进行交互来完成其业务功能，而由于Web服务处在一个开放的、松散耦合的环境下，Web的时延性、不可靠性等很多因素都对这种交互的可靠性和一致性提出了很大的挑战，因此在Web服务组合中必须提供对事务的支持。在当前的系统中扩充BPEL语法，使得BPEL具有事务性语义。进行这些扩展之后，还集成了Web服务事务处理系统(Web Services Transaction Process System，简称WSTPS)来对事务进行处理。

数据库连接：工作实例在运行过程中需要记录各个阶段的状态，运行结束后也需要保存相关的状态供后续的分析和查询。因此需要一个统一的数据库连接接口，从而不需要了解具体的数据库的位置和类型，简化了编码的工作。

如图1所示的服务调用单元3的目的是集成Web服务的多种实现方式，提供一种统一的、可扩展的机制完成对不同功能实现的调用。在Web服务组合中，由于需要调用其他的Web服务，这些Web服务既可以是对企业内的应用的集成，也可以是Web上的Web服务。由于不同的Web服务功能实现依赖于特定的运行框架和环境，集成多种实现方式的关键就在于分析相关运行框架和环境对自身功能构件的调用和执行过程，进而设计符合特定运行框架和环境的服务适配器来组建服务调用层，通过服务适配器完成对多种Web服务功能实现的调用。

另外，本发明还包括远程管理控制台，由于本发明是一个可配置的模块化结构。对于这种模块化结构的系统管理主要包括两个方面，第一是模块自身的管理，通常的做法是通过配置文件来完成；第二是各个模块之间的相互协调，这部分内容通常没有统一的方式，因系统实现的不同而不同。因此有必要提供一种统一的管理机制来完成系统的监控以及对各个功能模块配置参数的设置和调节。就该运行管理系统的管理需求看来，则主要体现在两个方面，一是对于系统自身信息的维护，包括系统的运行环境和参数配置；二是对于系统中运行的实例的管理，它主要涉及管理实例的生命周期。

在管理框架的设计上，我们引入了J ava管理扩展框架(JMX)，它是SUN提出的一种通用管理技术，定义了一个体系结构、设计模式、API以及提供给Java开发者使用的基础服务，开发者可以利用其中的API来访问服务以完成管理分布式应用程序的功能

如图6所示，本发明运行时机制为：

首先，接口适配单元1中的特定的适配器接收到前端的SOAP引擎的调用，适配器把调用信息和后端所需要的其他信息封装成统一的处理上下文，然后把它传递给的组合服务处理单元2；

组合服务处理单元2中的全局实例管理器根据该上下文中的信息定位特定语言的实例管理器，然后把该上下文传递给查找到的实例管理器；

实例管理器根据上下文中的会话信息把请求消息传递给正在运行的工作流实例来处理或者创建新的工作流实例来处理该请求；

在工作流运行过程中当需要调用到其他的Web Service时，组合服务处理单元2调用服务调用单元3，服务调用单元3根据WSDL中的特定的绑定信息选择具体的调用模块，由调用模块完成调用细节，并把结果封装后返回。

如图7所示，本发明工作流程如下：

第一步：客户端发送SOAP消息，请求组合服务；

第二步：SOAP引擎接收到该请求消息，进行相应的处理后把请求转发给本发明Web服务工作流处理器；

第三步：接口适配单元1中的特定的适配器最先接收到请求，然后把请求的内容转换成后端统一的处理上下文，然后调用组合服务处理单元2进行处理；

第四步：组合服务处理单元2中的全局实例管理器根据处理上下文中的信息定位到具体的语言实例管理器(现阶段支持BPEL和WSFL两种组合服务处理语言)，并调用该语言实例管理器进行处理；

第五步：语言实例管理器根据请求的SOAP消息中的会话信息定位具体的工作流实例，如果找到对应的工作流实例，则把请求的SOAP消息交给该工作流实例处理；否则创建新的Web Services工作流实例，然后把消息交给该工作流实例处理；

第六步：工作流实例开始运行，在运行过程中当需要调用其他的Web Service时，组合服务处理单元2调用服务调用单元3，由服务调用单元3根据WSDL中的绑定信息来调用特定的调用模块来完成具体的调用细节；同时工作流实例也处理接收到的请求消息；

第七步：工作流实例运行结束，通知语言实例管理器回收资源。

下面描述两个实施案例。

WSFL：基于WSFL的网上购买股票服务

该用例使用WSFL来描述网上购买股票的业务流程，在该流程中涉及到了其他的两个服务提供者：提供股票查询和购买的股票服务，提供银行信用卡信息查询的银行服务，这两个服务都是原子服务。

如图8所示，该应用场景由客户端、远程管理控制台、三个Web服务：网上购买股票组合服务、银行服务和股票服务组成，两个原子服务部署在WSR(Web Service Runtime，Web服务运行环境)中，组合服务部署在已经配置了Web服务工作流处理器的WSR中。

下面介绍该应用实例的运行过程。

1、用户填写客户端所提供的表单，填写所要购买的股票的数量信息，然后提交该请求；

2、部署了该组合服务的WSR接收到该请求，在进行相应的处理后把请求转发给组合服务处理单元2；

3、全局实例管理器根据请求的类型把请求转交给WSFL语言实例管理器，WSFL实例管理器创建一个实例来处理该请求，并返回一个会话ID；

4、该工作流实例分别调用股票服务取得用户所要购买的股票的价格、调用银行服务检查用户提交的信用卡信息是否正确；最后调用股票服务来购买股票；

5、工作流实例通过回调的方式把购买的结果返回给客户端；客户端根据消息中的会话信息来把对应的数据更新。

BPEL：网上购书服务

该用例使用BPEL来描述网上购书的业务流程，在该流程中，除了网上购书组合服务外，涉及到了其他的四个服务：提供信用卡交易的银行服务、提供图书交易的出版社服务、提供各种计算的计算服务以及派送公司提供的送书服务，其中出版社服务也是一个组合的服务。

该应用场景由客户端、远程管理控制台、五个Web服务：网上购书组合服务、出版社服务、银行服务、计算服务和派送服务组成，其中的原子服务银行结算服务、派送服务分别部署在两个WSR中，而计算服务虽然也是原子服务，但它的服务实现是本地的Java类，通过这种类型的服务体现了系统对本地应用的集成；两个组合服务：网上购书服务和出版社服务分别部署在已经配置了组合服务处理引擎的WSR中。

如图9所示，其运行过程简单叙述如下：

1、用户浏览图书信息，然后提交所需的图书的名称、数量、地址和信用卡等信息；

2、部署了网上订书服务的WSR接收到该请求，并把请求的SOAP消息转发给Web服务工作流处理器；

3、BPEL实例管理器创建一个实例来处理该请求，首先调用计算服务来检查库存是否能满足需求；

4、如果满足需求，图书销售公司直接将库存中图书卖给用户；当买书的数目多于图书销售公司的库存时，公司会从出版社定购用户需要购买的数目，再卖给用户。

5、同时调用银行服务和派送服务。

6、最后把处理结果返回给用户。

Claims (2)

1.一种Web服务工作流处理器，其特征在于，包括：

接口适配单元，用于接收请求并将请求信息及后端所需的信息封装成统一的消息格式，所述后端指服务调用单元；

组合服务处理单元，用于根据所述消息格式中的信息选择与其匹配的工作流实例来处理该请求，所述工作流实例指若干个相关的Web服务按照一定流程在工作流引擎系统中运行的实例；

服务调用单元，用于根据所述组合服务处理单元的需要选择相应的Web服务并将所述Web服务执行的结果返给所述组合服务处理单元；

所述组合服务处理单元包括全局实例管理器和若干语言实例管理器，其中：

全局实例管理器，用于根据处理上下文中的信息将其传递给相应的语言实例管理器；

语言实例管理器，用于根据处理上下文中的会话信息把所述处理上下文中的信息传递给正在运行的工作流实例来处理，或者创建工作流实例来处理请求。

2.如权利要求1所述的Web服务工作流处理器，其特征在于，所述语言实例管理器包括：

存储结构，用于存放正在运行的工作流实例；

语言文档解析器，用于根据Web服务工作流语言文档的地址解析出与其对应的内存对象；

文档对象存储结构，用于存放经过语言文档解析器解析后的业务流程文档；

若干解释器，用于解释Web服务工作流语言文档；

解释器生成器，用于根据Web服务工作流语言文档生成与其相应的解释器；

会话管理器，用于根据所述处理上下文中的相关器字段来判断请求是否属于正在运行的工作流实例，若属于正在运行的工作流实例，从存储结构中找出对应的流程控制块并把所述处理上下文中的信息转发给与其相应的解释器；否则调用语言文档解析器以创建工作流实例。

Images