workflow接口划分

workflow接口划分

1。应用接口 Application Interface
－－interface1 工作流自身提供的服务接口
－－interface2 工作流与应用之间的接口（主要是提供相关数据的调用接口）

2。扩展接口 PlugIn Interface
－－interface3 工作流与组织机构之间的接口
－－interface4 工作流与其他工作流之间的接口

将接口划分成应用接口与扩展接口主要是依据工作流与相关应用的调用关系，比如工作流与组织机构之间，是工作流调用组织机构中的人员信息，所以主动者是WORKFLOW、被动方是组织机构，所以应该采用扩展接口来实现

在扩展接口上应该采用Adapter模式，从而使工作流不局限于某个特定的实现

目前的进展
0。Application Interface接口已经基本实现了
PlugIn Interface接口目前基本完工，但OSWorkflow的实现实在是非常的丑陋，需要更改的地方太多，而且对于Interface3不可以使用它采用的User / Group模型（而且它使用了OSUser这个框架，对于多数的应用程序基本可以说不适合，而且它的User类竟然是Final ?!而且我发现它的很多类的属性都是Protected！也就是说除了他们自己根本没有办法扩展，即使扩展也是很丑陋的方式）

1。现在最大的问题是它的WorkStore接口的扩展，我采用DB2的方式实现了它的接口，但这样的方式会与DB2绑定在一起，如果自己写实现就要根据不同的DB采用不同的SQL语言－也就是不同的方言策略？！而且考虑到性能估计不是什么好主意，看来明天需要更换成HibernateWorkStore的形式，这样工作流的持久层接口将工作在Hibernate之上，看来很完美的解决了这个问题。

2。而且我扩展了它的PropertySet，使其不再依靠JNDI寻找DataSource，而是通过嵌入在程序内部采用JDBC的形式寻找数据库连接，这样我就不必为了验证一个问题去建立那该死的数据库缓冲池了（而且JNDI的形式也就不可避免的要用到容器，太重了！）

3。我编写了UserGroupCondition的实现类，这个类的作用就是调用Interface3的方法，从而判断某个用户是否属于某个组（现在的做法是让WorkStore实现Interface3的偷懒办法，但很乱，看来还是要写一个Adapter去实现interface3才对！）

4。目前工作流引擎的工厂类已经实现完工并测试通过。


用了近一个月的时间完成了这些工作，看起来很少但是基本上大量的时间花费在熟悉工作流规范、WFMC标准、以及学习和扩展OSWorkflow接口上，不过对OSWorkflow的实现基本上掌握了，如果抛开OSWorkflow自己也可以采用自己的方式去实现，或者会考虑使用Spring的方式（Interface3的Adapter不行就采用Spring实现）。

BTW:
OSWorkflow的实现其实比较的丑陋！而且编码根本没有什么规范，接口的定义也是天马行空，看来Heni除了他的大嘴外应该好好的提高自己的技术修养。－实在不敢恭维这位"大师"的编码水平！