工作流：第一次发版，设计总结

整体

• 面向接口：消息系统，持久系统等，其实现都是可替换的，主干代码对实际的消息系统或持久系统等一无所知
• 组件复用：Visio对象及Visio模具的使用目前来看取得了极好的效果，极大缩短开发周期、增强功能、并自动将数据与视图进行了相当程度的分离，并且比Jawe等设计器漂亮多了
• 基于SOA：平台所有接口都是通过WebService提供的，提高了复用和跨平台能力；实际上，平台是.Net开发的，而目前支撑的几个应用则是J2EE的
• 服务网关/接口：平台核心功能以类库的形式提供，所有暴露出的接口都是薄薄的一层WebService包装（服务接口）；对接口的访问也以类库的形式提供，隐藏了对WebService的调用（服务网关）
• 遵循标准：对WfMC的遵循使开发组少走了不少弯路，因标准即使不是最佳方案，亦已对常见问题深思熟虑，对缺少业务专家的开发组来说有相当的指导作用；并且开源软件提供了参考实现，与开源软件的互操作验证了产品的正确性

模块

• 通用查询接口：Decorate/Composite

实现手段近似，意图不同

/// <summary>

/// 通用的条件接口，使用Object类型的参数，将类型安全检查踢给子类

/// </summary>

public interface ICondition {

 

/// <summary>

/// 返回传入对象是否满足本条件

/// </summary>

/// <param name="obj">传入对象</param>

/// <returns>传入对象是否满足本条件</returns>

bool Calculate(Object obj);

 

/// <summary>

/// 返回本条件的字符串表示，用于WebService的参数传递

/// </summary>

/// <returns>本条件的字符串表示</returns>

String GetString();

 

/// <summary>

/// 将传入的字符串还原为条件对象

/// </summary>

/// <param name="condition">原始条件对象的字符串表示</param>

void SetString(String condition);

}

 

[Serializable]

public abstract class BaseCondition : ICondition{

//一些缺省实现，定义了几个Template Method

//…

}

 

/// <summary>

/// 通用的全部条件接口

/// </summary>

[Serializable]

public class AllCondition:BaseCondition {

public override bool Calculate(Object obj){

return true;

}

}

 

/// <summary>

/// 通用的与条件接口，当所有条件都为true时返回true

/// </summary>

[Serializable]

public class AndCondition:BaseCondition {

private IList conditions;

public AndCondition(IList conditions){

this.conditions = conditions;

}

public AndCondition(){

this.conditions = null;

}

 

public override bool Calculate(Object obj) {

foreach(ICondition condition in conditions){

if( !condition.Calculate(obj) ){

return false;

}

}

return true;

}

}

 

/// <summary>

/// 通用的或条件接口，当所有条件都为true时返回true

/// </summary>

[Serializable]

public class OrCondition:BaseCondition {

private IList conditions;

public OrCondition(IList conditions){

this.conditions = conditions;

}

public OrCondition(){

this.conditions = null;

}

public override bool Calculate(Object obj) {

foreach(ICondition condition in conditions){

if( condition.Calculate(obj) ){

return true;

}

}

return false;

}

}

 

/// <summary>

/// 通用的非条件接口，返回与原条件相反的结果

/// </summary>

public class NotCondition:BaseCondition {

private ICondition condition;

public NotCondition(ICondition condition){

this.condition = condition;

}

public NotCondition(){

this.condition = null;

}

public override bool Calculate(Object obj) {

return !condition.Calculate(obj);

}

}

• 通用工作流模型：Abstract Factory

虽说XPDL是标准，但各个厂家的扩展属性并不相同，流程设计器和引擎需要兼容各个厂家的模型，就需要用Abstract Factory，各家的工厂生产各自的对象体系，当然接口相同，流程设计器和引擎只对接口操作

public interface ModelFactory {

PDPackage CreatePackage();

PDPackageHeader CreatePackageHeader();

PDProcesses CreateProcesses();

PDExtendedAttributes CreateExtendedAttributes();

PDTransitions CreateTransitions();

PDProcess CreateProcess();

PDActivitySet CreateActivitySet();

PDDataField CreateDataField();

//……

//…

}

 

public class JaweModelFactory:ModelFactory {

public PDProcess CreateProcess() {

return new JawePDProcess(this);

}

//……

//…

}

• 组织适配器：Adaptor

流程设计器和引擎和流程监控工具等看到的只是系统内部定义的类似Party模式的组织模型，外界实际的组织模型需要以单独编写适配器的形式接入到平台中来；如我们开发时的组织数据存放在Xml文件中，几个实际应用的组织数据存放在公司的数据库中，我们用两个适配器将原有模型适配进来，使用时配置一下即可：

<organization_adaptors>

<add key="current" value="usa_db" />

<add key="usa_xml" value="Nucleus.Organization.UseModel.UseAdaptor" />

<add key="usa_db" value="Nucleus.Organization.UseMisModel.UseMisAdaptor" />

</organization_adaptors>

• 流程描述与流程定义：Item and Item Description

流程设计器和流程监控工具和应用等首先看到的只是流程的描述，选中某个流程后才会去获得真正的流程定义

待改进之处极多，优先的几个：

• 微内核：将引擎重构为一个简单的内核与围绕着内核的一组适配器
• 分离调度系统与信息系统：查询时应不需要引擎的参与，引擎负责流程调度，信息系统应承担的工作需剥离开来，提高性能
• 提供控制台：改变手工修改配置文件、注册适配器的局面
• 统一界面框架设计：改变缺少界面规范或模板、界面风格不统一、代码结构不统一的现状
• 剥离对第三方商业产品的依赖：设计器的视图部分增加一个抽象层，隔离Visio组件，毕竟有成本问题
• 要不要语言独立？J2EE平台和.Net平台的相似，Java和C#的相似，提供了若干诱惑，有了一套主干代码，两套平台适配器的想法，并且公司目前的项目即存在对J2EE工作流平台的需求；肯定已经有很多成功项目这样做了，问题在于我们的资源，再讨论一下

开源了目前使用的XPDL解析器，希望能得到反馈

http://cosoft.org.cn/projects/xpdlparser