偶继承了它的Configuration接口

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.Configuration;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IConfiguration extends Configuration
{
 /**
  * @deprecated getIWorkflowStore()
  */
    WorkflowStore getWorkflowStore() throws StoreException;
   
    /**
     * return WorkFlowStore which implements the interface of IWorkFlowStore
     * @return
     * @throws StoreException
     */
    IWorkFlowStore getIWorkflowStore() throws StoreException;
   
}

你可能奇怪我为何要继承它的接口（肯定是Bad smell），原因如下，

IWorkFlowStore 接口定义

import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.spi.Step;
import com.opensymphony.workflow.spi.WorkflowEntry;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IWorkFlowStore extends WorkflowStore
{
 
 public Step createCurrentStep(WorkflowEntry _entry , Step _step) throws StoreException;

}

WorkflowStore接口定义

    /**
     * Persists a step with the given parameters.
     *
     * @param entryId The workflow instance id.
     * @param stepId the ID of the workflow step associated with this new
     *               Step (not to be confused with the step primary key)
     * @param owner the owner of the step
     * @param startDate the start date of the step
     * @param status the status of the step
     * @param previousIds the previous step IDs
     * @return a representation of the workflow step persisted
     */
    public Step createCurrentStep(long entryId, int stepId, String owner, Date startDate, Date dueDate, String status, long[] previousIds) throws StoreException;

看到了吧？

其实我只是希望在createCurrentStep时按照OO的方法执行，而不是传递那些"Bad Smell"的参数，而OSWorkflow中的WorkflowStore是需要Configuration来获取的，此时为了增加一个看似合理的方法，需要分别继承Configuration与WorkflowStore；这还没有完，你需要实现一个Configuration实现！！

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.DefaultConfiguration;
import com.opensymphony.workflow.spi.WorkflowStore;

public class DefaultIConfiguration extends DefaultConfiguration implements IConfiguration
{
 
    public static DefaultIConfiguration INSTANCE = new DefaultIConfiguration();
    private transient IWorkFlowStore store = null;

 /**
  * @deprecated getIWorkflowStore()
  */
 public WorkflowStore getWorkflowStore() throws StoreException
 {
  return null;
 }

 public IWorkFlowStore getIWorkflowStore() throws StoreException
 {
  if (store == null)
  {
   String clazz = getPersistence();

   try
   {
    store = (IWorkFlowStore) Class.forName(clazz).newInstance();
   }
   catch (Exception ex)
   {
    throw new StoreException("Error creating store", ex);
   }

   store.init(getPersistenceArgs());
  }

  return store;
 }

}

总结

1。OSWorkflow与WorkflowStore接口的关系比较的微妙，它需要借助于Configuration接口的实现来获取到实际的WorkflowStore对象。

2。由于这样的一种微妙关系，对WorkflowStore接口的扩展必将连带着需要扩展Configuration接口，而产生这样的"果冻效应"的罪魁祸首就是由于WorkflowStore接口与Configuration接口耦合的太紧。

3。OSWorkflow并没有很好的遵守OO的设计规则，尤其在它的参数传递上，非常的差！

DB2ConnectFactory 中getConn方法
/**
* 获取数据库连接
* @return
* @throws SQLException
*/
public Connection getConn() throws SQLException
{
Object obj = threadLocal.get();
if(obj == null)
{
this.initFactoryStack();
}else
{
connect = (Connection)obj;
}
connect.setAutoCommit(false); //事务的回滚必须建立在将Commit状态为False下，默认是true
logger.debug("Get connect from factory - " + connect.hashCode());
return connect;
}

AbstractWorkflow 的doAction()方法

try {
//transition the workflow, if it wasn't explicitly finished, check for an implicit finish
if (!transitionWorkflow(entry, currentSteps, store, wf, action, transientVars, inputs, ps)) {
checkImplicitFinish(id);
}
} catch (WorkflowException e) {
context.setRollbackOnly(); // 这里调用WorkContext对象的setRollbackOnly()方法，执行事务的回滚
throw e;
}

GearWheelWorkFlowContext 的setRollbackOnly方法
/**
* Tranaction : Set Roll back
* @throws SQLException
*/
public void setRollbackOnly()
{
logger.debug("Context execute setRollbackOnly() !!");
Connection connect = null;
try
{
DB2ConnectFactory factory = new DB2ConnectFactory();
connect = factory.getConn();
logger.debug("Context get connect " + connect.hashCode());

if(connect != null) connect.rollback();
}
catch (Exception e)
{
e.printStackTrace();
}
finally
{
this.clostConnection(connect); //这里将关闭数据库连接
}
}

可是这是"异常"情况下的处理流程，如果正常执行呢？
刚开始我想写在CleanUp()方法里，但又一想不行，因为正常执行的流程需要做两个工作
1。将Commit状态更新为true,并提交连接
2。关闭数据库连接

关键就是关闭数据库的连接在哪里写？！现在写在CleanUp()不合适，因为每一个WorkStore的方法都要默认（程序已经写死了,我可不想重载它的所有的方法！！）的关闭数据库连接！
仔细的分析了一下，其实有两个方法可以做到
1。编写Proxy类
2。重载所有AbstractWorkflow中设计到事务的方法，（本来可以重载transitionWorkflow但是方法的类型却为private?!）在它的方法下增加一个"提交"的方法。比如这样

try {
//transition the workflow, if it wasn't explicitly finished, check for an implicit finish
if (!transitionWorkflow(entry, currentSteps, store, wf, action, transientVars, inputs, ps))
{
checkImplicitFinish(id);
}

dosubmit();

} catch (WorkflowException e) {
context.setRollbackOnly(); // 这里调用WorkContext对象的setRollbackOnly()方法，执行事务的回滚
throw e;
}

可以看到方法2比较"烂"，看来下一步即使编写方法1的实现

可是我以前不太了解Sequence的概念，这片资料倒是很有价值
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0407zhang/
不过我以为查询Sequence就只需要执行SELECT NEXT VALUE FOR seq_os_wfentry 就ok了，可是谁知道总是报错？！在比较仔细的看了这片文章之后发现，其实根本就无法执行这条SQL！而需要这样
INSERT INTO EMPLOYEE ( SERIALNUMBER, FIRSTNAME, LASTNAME,
SALARY) VALUES(NEXTVAL FOR EMPSERIAL, 'Martin', 'Wong', 1000.00)

可是看看JDBCWorkflowStore的实现，这里是JDBCWorkflowStore的主键生成策略！
protected long getNextEntrySequence(Connection c) throws SQLException {
if (log.isDebugEnabled()) {
log.debug("Executing SQL statement: " + entrySequence);
}

PreparedStatement stmt = null;
ResultSet rset = null;

try {
stmt = c.prepareStatement(entrySequence);
rset = stmt.executeQuery();
rset.next();

long id = rset.getLong(1);

return id;
} finally {
cleanup(null, stmt, rset);
}
}

c.prepareStatement(entrySequence) － 其实执行了一条SQL语句，所以看来JDBCWorkflow根本不支持Sequence生成策略！！

该死的实现方式，看来我要重载其实现方式，不过说真的JDBCWorkflow的编码人员其实水平不匝地！