工作流第二版设计总结
一、Existing Problems
-
没有进一步总结工作流领域模型，还基本停留在第一版的层次上，导致：
层次不甚清楚
增加新功能困难
事务脚本过多，带来重复代码
-
组件职责相对混乱，尤其是服务组件与其它模块耦合太多，应更清晰的定义一个内核服务层
-
没有做并发设计，导致：
-
性能低下
-
存在死锁可能
-
二、Design Principles
针对接口编程与控制反转
整个系统针对接口编程，降低了编译时依赖；利用IoC，通过配置来组装系统，定制运行时行为；带来的最大好处就是，我们获得了一个可在分布式和嵌入式之间通过配置切换的引擎，不需要修改源代码，大大提高了持续集成的方便性和速度，提高了适用性
三、Architecture Patterns
1、分层（POSA1）
|
通用类库：供所有其它层调用 |
|
内核服务层：供内核调用 |
|
内核：独立运行或作为普通类库被调用 |
|
内核开发包：开发外围服务时使用 |
|
外围服务：与内核一起运行，供应用开发包调用 |
|
应用开发包：开发具体应用时使用 |
|
具体应用：调用应用开发包来与系统交互 |
其中，内核中的工作流领域模型又分三层
|
语法层：负责将流程定义的文本形式转化为内存对象 |
|
语义层：负责将这些内存对象无意义的扩展属性解释为有意义的模型属性 |
|
实例层：表示运行期的语义层对象，其中各个属性使用运行期实际的值来实例化 |
2、微内核（POSA1）
-
内核服务层＋内核，完成了最基本的工作流引擎，如实例化流程并调度之，产生任务表，处理消息请求等；
-
外围服务则提供了做为一个产品化的工作流引擎所必备的特性，如持久化，超时处理，任务通知，查询接口，命令接口等
-
外围服务以插件的形式配置到系统中
四，Design Patterns
1、领域模型(PEAA)＋Visitor(GoF)＋事务脚本(PEAA)＋命令处理器(POSA1,GoF)
Problem：
-
P1：目前对工作流领域模型了解的不够透彻，而开发过程中需要不断增加目前的模型不能直接支持的功能，如撤回、回退等
-
P2：如果坚持使用领域模型，则增加一个功能基本对应着为领域对象增加相应的方法，则同时增加多个功能时，增加了并行开发和版本控制的难度，降低了开发效率
Constraint：
-
C1：需要在不修改领域模型的情况下动态增加功能
-
C2：需要在不修改领域模型的情况下动态为客户端提供新功能调用接口
Solution：
-
S1：使用“领域模型(PEAA)”为当前所了解的工作流领域建模，支持基本功能
-
S2：使用“Visitor(GoF)”为领域模型动态添加功能，这些功能通常还不是很清晰，需要迭代开发，逐渐合并到领域模型中
-
S3：使用消息对象为客户端动态的添加调用接口，使用“命令处理器(POSA1,GoF)”为服务端动态的增加相应的处理接口
-
S4：命令处理器的执行体则是“事务脚本(PEAA)”，它调用领域对象的方法，或“Visit”领域对象来完成功能；目前这一部分存在重复代码，需要进一步弱化或减少事务脚本，丰满领域模型；另一种方案就是“元工作流”，即工作流系统中的事务脚本也用工作流来实现，困难在于抽象出一个工作流的元层次
2、主动对象(POSA2)＋异步完成标志(POSA2)
用于自动型活动；自动型活动在自己的线程中独立、主动的运行，从引擎传入的异步完成标志中获取参数，执行完毕后将结果填写到异步完成标志中，并向引擎发送完成消息，以使“堵塞”的流程继续运行（此处的“堵塞”并不是真的堵塞，而是当自动型活动对流程来说必须是同步完成的时候，流程的一种无所事事的状态）；这里更像是“收集参数(TDD)”模式，而不是异步完成标志
3、反应器(POSA2)＋监听器
用于将内核事件发送给外围服务，实际上是一种手工AOP实现，下一版可将目前手工触发事件的地方重构为pointcuts，将监听器重构为advisors
4、插件(PEAA)
用于将外围服务动态配置到系统中
5、查询对象(PEAA)
就是前一版的“通用查询接口”，这一版用“Generic + Functional Programming”重构了一下；目前系统中所有的查询条件都是通过查询对象来设置和获取的，问题时效率较低
6、包装器外观(POSA2)
用于对Xml、消息系统等外部资源的访问，在将系统从.Net平台移植到J2EE平台时，该模式发挥了巨大作用，大大缩短了移植时间
See Also：