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.




2 responses

27 07 2006
Yoichi Takayama


We find that IMS LD also have some problems when one wants to express flow which is more collaboration orinented. We had to extend the to squeese needed fucntionalities. It also has limited global data sharing and Roles are swim lane like and not suitable for local Roles concept which are defined and assigned within each Activity. We regard IMS LD type of workflow as “activity workflow” (a type of human workflow), agaist others which may be document centric, data centric and proces based workflows.

27 07 2006

Yes Yoichi,
Strong agreement with that, in a stack of functionality human workflow is wider than activity workflow is wider than IMS-LD.

So it would be wrong to try and build a Workflow system using the IMS-LD specification, but might be possible to implement a IMS-LD definition using a more sophisticated workflow engine. I think you LAMS/LAMS2 work takes this standpoint as being a \’more sophisticated workflow engine\’

BTW, in the big stack of things, I see IMS-SS and being narrower than IMS-LD ?

%d bloggers like this: