[RT] Usecases, Tasks, and Workflow

[Andreas Hartmann <an...@apache.org>]

Hi Lenya developers,

here's my next architecture discussion mail ...

At the moment, the connection of usecases, tasks, and workflow
is not very clearly defined.

- A task is just a function that can be invoked from
   everywhere in the sitemap or using the scheduler.

- A usecase is a sequence of steps. In most cases, the last
   step involves the execution of a task (when all parameters
   are collected using forms).

-  The workflow of a document is a state machine.

There is no connection between usecases and workflow.
Is this good? There should certainly be no connection from
usecases to workflow, but what about the other direction?

On the implementation side there is a connection between
tasks and workflow. Workflow transitions are triggered
when a task is executed (by the TaskWrapper). I'm not sure
if this is a good idea.

The assignment of workflow events to user actions can be
done in two ways:

1) providing the lenya.event parameter when executing the
    TaskAction

2) using the WorkflowInvokerAction

The usual way is to add the lenya.event request parameter
to the menu entry. I don't think this is a good approach.

At the moment, the workflow execution looks like
(-> means "invokes")

     usecase -> task -> workflow

This "bottom-up" view might be confusing. The integrator has
to trigger the workflow at a certain step of the usecase, so
the "big picture" can be quite scattered.

So, conceptually, it should rather look like

     workflow -> usecase -> task

But I'm not quite sure about that - maybe it is a good
idea to allow workflow triggers on arbitrary places.

---------------------------------------------------

I could imagine the following concept:

- The workflow is defined as it is now.

- Usecases are assigned to workflow transitions.

- There is a kind of usecase inheritance.
   E.g., "Edit with BXE" and "Edit Metadata" inherit
   from the usecase "Edit". This makes it very easy
   and clear to assign different usecases to a
   workflow transition.

- A similar concept would be to introduce the notion
   of "usecase types". Specific usecases would implement
   certain types ("Edit with BXE" would implement the
   type "Edit"). Instead of usecases, usecase types
   are assigned to workflow transitions.

- Tasks and workflow are detached from each other.
   The usecase doesn't know anything about workflow.

- We have to find an interface for usecases. The notion
   of success / failure has to be introduced.

There are some open questions:

If we keep the concept of state machine workflows,
how do we trigger transitions? IMO the workflow transition
should invoke the usecase, like

Workflow.executeTransition() {
     boolean success = usecase.execute();
     if (success) {
         fire();
     }
}

How can this be implemented? It should be possible to
assign usecases to workflow transitions. If such a
usecase is finished, the appropriate transition has to
be invoked - without any further implementation efforts.

Another issue is scheduling.

It is obvious that workflow transitions have to be
invoked when jobs are executed. Currently, this is done
by the connection between tasks and workflow (tasks
are scheduled, task execution triggers workflow invocation).

But IMHO this could be improved. E.g., what about scheduling
a transition without attaching it to a task?
Thinking in objects, I would see the workflow as a listener
of the usecase and the usecase as a listener of tasks.
I see the scheduler as a "delay" during the execution of
a usecase. If usecases are assigned to workflow transitions,
and something like a "continuation" is attached to scheduled
job, this would result in an implicit order of scheduled
jobs and conflicts could be avoided.

Just a few random thoughts - feel free to add your comments!

-- Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org