Workflow Implementation

14 06 2006

I’ve resurrected the Workflow implementation that was started at the end of the last JISC VRE project meeting. Wonderful how meetings give you time to think, but leaving it alone for such a long time has done two things. Help me forget what I was doing, and solve the same problems in a different but better way.

The workflow engine is a light weight, in memory engine that has built in transactions and rolls back on failure of any of the activities. Hence in a discrete section of flow it either reaches a steady state or it rolls all the way back to the starting point. The whole operation is contained within a thread and storage transaction manager, this means that the execution engine can explore all the pathways, evaluating or executing all the tasks. Unlike a lamda-calculus approach (XLang, BPML) this avoids the pre determination of an execution route through the discrete segment of workflow. In fact, its rather simple and mirrors some of the execution processes of a multi-threaded CPU. It has an execution stack that winds up and down as the flow pointer traverses the flow pathways. If all goes wrong before the final commit, the storage transaction is rolled back, any XA compliant transaction mangers that took part in the workflow segment are notified and the flow stack, and flow modifications are thrown away leaving the workflow state in the same state as it was before the operation started.

As with other transaction managers, the flow state is attached to the thread and only committed once all is ready to commit. If you think of this in DB terms, this would be characterized as READ_COMMITED. It should also be possible to create SERIALIZABLE mode by synchronizing blocks of the flow.

The one area to watch in this approach is the Business Process Objects (BPO’s) that hand of responsibility to no XA compliant components, must ensure that, either the transaction flow passes synchronously into the component, only returning ready for commit when the component is able to do so, or when the component is able to take full responsibility. State modifications that go outside the scope of the transaction cannot be rolled back. An I don’t fancy implementing a ‘whoaa there, give me my data back, I need to make a change’ protocol.

IMS-LD and Workflow

12 06 2006

There has been a thread on sakai-pedagogy on Learning Design sparked by Mark Norton. This discussion triggered a long held thought, that IMS-LD is a specialized form of workflow that could be implemented and enacted in a generic workflow environment. I dont know how true this is, or if there is a sufficiently complete mapping to make this possible, but experimentation will help us discover if this is the case.

I am in the process of writing a lightweight workflow engine that does not specify or bind to anything that is available as part of the Sakai framework. The intention being, to provide those services using components from the Sakai framework. This workflow service will not use any heavy weight components (eg EJB’s) and so will not require JBoss or another EJB container.

Currently I think that it will be possible to instance a process by loading an XML definition, potentially embedded inside an IMS-CP, that will manipulate and control items on the Sakai Entity bus. (ie content, messages, tools etc). Once instances, a process design, becomes an instance of a Runtime Entity and manages its own state, storing what it needs to inside its own state persistence service. The workflow service will understand roles in the Sakai context so that it can distinguish between users in different roles. It will have the concept of time, allowing the process flow of a Runtime Entity to pause and restart at the command of the user or by design of the process.

The closest workflow standard that has these concepts is the Workflow Management Coalitions XPDL standard, which we *may* use as the native expression of the workflow definition. Whichever definition format is used, there will be java code to load those definitions into the internal object model of the process.

One of the tasks that needs consideration, is the transformation and loading of IMS-LD into an XPDL like workflow service. Not knowing enough about IMS-LD at present, I don’t know exactly where all the gaps are.

At this point you might be thinking, why havent I mentioned IMS-SS, SCORM2004 or BEPL. IMS-SS and SCORM2004 which contains IMS-SS are a more specialized form of workflow which potentially constrains the learner further. BPEL is a machine-machine workflow, suitable to implementing black box functionality, but not suitable for interacting with a Human. BPEL is ideal for specifying the activities that a XPDL based workfloe might control.