扩展Apache ODE --服务的动态选择

一般情况下流程运行中所涉及到的Web服务实例都是固定的，其调用的端点地址是在流程设计时期就指定了的，在运行期间引擎将会向指定的Web服务发送调用信息，并获得运行结果。这种设计虽然执行起来简单，但是其缺点也有很多，首先，流程运行的容错性不高。如果某个流程是一个长期运行实例（其一次运行可能持续几天，甚至几个月），那么在流程设计初期为其指定的服务可能会因为各种原因停止服务，那么引擎对于该实例的合作伙伴的调用将会出错，从而使得实例运行失败；其次，这种设计限制了整个系统运行的性能发挥。很多情况下，某个特定领域中的某个计算程序会在一个流程实例中多次被调用，而同时也会有多个组织或个体拥有该计算程序，如果在设计过程中就将某个常用计算程序指定到某个固定服务器上，那么随着该服务的不断被调用，其服务性能将会迅速下降，从而影响流程运行效率。

因此本系统采用向流程部署文件集（所有流程部署所需信息的集合）中添加动态信息描述文件dynamic.properties的方式，在不影响BPEL标准的前提下，为系统增加服务动态选择功能。该特性可以让流程在运行时对服务的绑定进行重新选择，其选择的依据就是目前该服务的多个实例所部署的服务器当前性能指标，同时可以根据用户所定义的选择策略进行服务筛选，以获得较好的执行效率。

 上图是本系统的动态服务选择框架图，加入该特性后引擎在调用每个服务时候首先检查该服务是否在动态配置文件中存在，该配置文件指定了当前流程中哪个服务的调用是采用动态机制调度的，通过服务名称来表明，同时给出了该服务应该采取的选择策略。如果当前服务不需要进行动态选择，则使用该服务的原始地址进行常规调用；如果需要动态选择，则引擎首先会向动态选择服务发送请求，获得在当前服务名称和选择策略下所对应的最佳服务地址。然后再使用该调用地址替换原来的地址进行调用。在这里，需要注意的是在拿到需要进行动态调用的服务信息之后，要想取得该服务所对应的最佳服务地址，必须有服务注册中心的支持和选择算法的应用。本系统所采用的服务注册中心采用UDDI技术实现，具体工作由本项目组其他成员负责完成，在这里不做讨论。

本系统中服务动态选择实现的特点是，并没有扩充BPEL标准，也就是说在加入该功能后BPEL定义文件不需要做任何修改，仍然是符合标准规范的，而只是在部署流程的时候添加相应的动态信息描述文件即可。与服务注册中心的结合可以通过配置文件实现，当然其中的选择策略也可以由用户自己定义。通过向系统添加该功能特性，对系统运行流程性能有一个较大的提高，但同时付出的代价是服务注册中心部分需要负责收集各个服务性能指标，对其造成了一定的负担。

实际上就是通过一个消息服务器来动态选择流程配置文件，是吗？

恩，差不多，呵呵，只是一个很小的改动
但这个改动需要有服务性能收集装置来作支撑，也就是通过某种工具能监控到所有提供服务的节点当前状态

呵呵，感觉到你们这个项目多半是针对大型应用平台的，都需要采集服务性能，要求肯定比较高。。。。。一般来讲是流程比较复杂和数量比较大的情况