流程运行概述

流程运行需要引擎首先创建该流程的实例，当然实例的创建也是以接收用户发送的调用消息起始的，然后根据该流程对象的定义按顺序执行一个个活动，像赋值操作、等待操作等，当然最重要的还有调用外部服务的操作，同时还要负责接收发送回来的响应消息，根据响应消息的内容再执行后续的流程，最后流程终止后，销毁该实例。

?SOAP消息的接收与传递?

在本系统中与外界的所有通信都由AXIS2来负责，通过其配置文件来指定不同的消息类型如何进行处理，比如可以给所有的进入消息配置一个处理器，该处理器的工作就是检查该消息头部，得知其是否有状态，以及是否需要返回消息等。通过这样的实现方式就可以对所有接受到的消息进行一次前处理，方便后续的操作。同样，我们可以配置多个处理器，针对各种不同的操作都有相应的动作。这种通过配置文件就可以改变消息处理方式的做法非常简单，这也说明AXIS2的设计扩展性非常好，可以很方便的与其他系统进行集成。

在上一节中说到流程编译的最后一个步骤是将流程暴露为Web服务，同时将该服务所有操作（Operation）都绑定一个消息接收器，这里的消息接收器就可以认为是引擎与AXIS2之间的桥梁，通过它来将AXIS2接收到的消息转发到引擎内部。至于AXIS2是如何接收客户端发送来的SOAP消息并不是本论文讨论的重点，这个内容可以查看相关AXIS2的文档。还应注意到的一点是，在引擎系统中所有的消息可以分为两种，一种是由外部客户端发送过来的，而另一种是引擎内部自己作为流程执行所需而传递的消息。对于外部消息可以采用AXIS2系统中的MessageConext类作为消息表示，这就省去了消息格式转化的步骤，但是这种类型消息只能使用在从外部接收到的内容，因为它并不包含下一步的路由信息，不适用于引擎内部进行交互。在流程执行过程中，所有的消息应该采用内部封装的格式，利用事件触发的形式进行流程的执行。

在本系统中我们为AXIS2配置了四个消息处理器，如图，其中第一个消息进入处理器是对所有接收到的SOAP消息进行一个前期处理，来判断此次调用是有状态的，还是无状态的，以及是否需要返回消息。首先判断此次消息调用头部信息中是否已经有了session标识和所要调用的endpoint信息，则将这些消息取出，以属性的形式加入到AXIS2所接收的MessageContext中，同样的，对于是否需要返回消息，也采用此办法。这样，在后续的操作中所有的此次调用信息都可以通过提取MessageContext中的属性来获得，比较方便，不用每次都从消息头部中解析。第二个查找服务处理器，是根据请求地址URL中的服务名称来查找的。在本系统中，对外暴露的服务所调用的地址模式是/processes/service-a