Author: ctheune
Date: Mon Sep 25 13:08:41 2006
New Revision: 4328
Modified:
AlphaFlow/trunk/doc/proposals/ASPECTS.txt
Log:
- updated and cleaned up docs a bit
Modified: AlphaFlow/trunk/doc/proposals/ASPECTS.txt
==============================================================================
--- AlphaFlow/trunk/doc/proposals/ASPECTS.txt (original)
+++ AlphaFlow/trunk/doc/proposals/ASPECTS.txt Mon Sep 25 13:08:41 2006
(at)(at) -1,41 +1,47 (at)(at)
+===================
The Aspect proposal
===================
:Status: Draft
:Author: Christian Theune, <ct(at)gocept.com>
-Problem
--------
+Preface
+=======
gocept plans to provide a graphical interface for designing and editing
workflows. The intended users are workflow developers who want to keep a good
overview over complex workflows and communicate about workflows with their
customers and users.
-AlphaFlow has a very generic and powerful execution model. However, this has
+Problem
+=======
+
+AlphaFlow has a very generic yet powerful execution model. However, this has
several issues:
- - Everything that happens because of the workflow is a first level
- "activity". This makes simple workflow graphs very quickly hard to
- read because workflow graphs include things that don't belong on the
- business process level.
+ - Everything that happens because of the workflow is a first level
+ "activity". This makes non-simple workflow graphs hard to read because
+ workflow graphs include things that do not belong on the business process
+ level.
+
+ - AlphaFlow has a couple of activity properties, that ask to be handled by a
+ richer execution model. (E.g. startActivities, assignees/responsibilities,
+ common exits like "continue_activity" ...)
- - AlphaFlow has a couple of activity properties, that ask to be handled
- by a richer execution model. (E.g. startActivities)
+ - Typical usage patterns are hard to implement if you do not know the models
+ inside-out.
- - Typical usage patterns are hard to implement if you don't know the
- models inside-out.
Proposal
---------
+========
We propose to:
- - Reduce the number of different activities
+ - Reduce the number of different activities
+
+ - Introduce a new concept called "aspects" to replace the removed activities
+ and therefore simplify each of the various workflow aspects.
- - Introduce a new concept called "aspects" to replace the removed
- activities and therefore simplify each of the various workflow
- aspects.
Aspects
-------
(at)(at) -46,41 +52,152 (at)(at)
A special aspect will be the "business process" aspect, which will feature how
(business relevant) activities are wired up. All other aspects are flexible
-and pluggable. The will be relevant for each activity, but you do not have to
+and pluggable. They will be relevant for each activity, but you do not have to
talk about them when designing the business level of your workflow.
-So how do aspects work? When a work item in the workflow is started, every
-registered aspect will be asked to perform an operation in the context of this
-work item. When a work item finishes, all aspects are called up again, and can
-perform other tasks, depending on the way the work item finished.
-
-This also allows us to make 'fallout' a special way of finishing a work item
-and make aspects handle this, e.g. by spawning a different part of the
-workflow.
+So what are aspects technically?
+
+Aspects have three important roles: They can introduce new configuration for
+activities, new behaviour before an activity is started, and new behaviour
+when an activity triggers an exit.
+
+Therefore they act like a series of filters, preparing the environment for the
+next activity, or cleaning it up after an activity.
+
+
+Exits
+-----
+
+To allow filters to act when an activity triggers an exit, to increase the
+understandability of workflows we define, exits must be more rigorously
+defined than before.
+
+We propose to define an exit as:
+
+ - A name, defined by an activity, that is mapped to a point during the life
+ time of a work item.
+
+ - A set of activities that are spawned when the exit is met during the life
+ time of the work item.
+
+A special exit is named "complete" and acts as a system-defined exit, that
+applies to all work items:
+
+ completion
+ When this exit is triggered, the work items life is over and the status
+ is set to "completed".
+
+Annotations:
+~~~~~~~~~~~~
+
+ - Multiple exits can be triggered during the life time of a work item. E.g.
+ the interaction pattern of a decision work item might look like:
+
+ -> Work item created -> Exit: Decide against -> Exit: complete
+
+ or
+
+ -> Work item created -> Exit: Decide in favor -> Exit: complete
+
+ - We thought about implementing "fallout" as an exit to provide customizable
+ behaviour on fallout situations. However, we discovered an "escalation"
+ pattern recently that will allow workflow developers to handle exceptional
+ situations on their wishes (by either falling out to an administrator or
+ have it managed within the workflow by an escalation manager). This will be
+ discussed in a separate proposal, though.
+
+
+Proposed interfaces
+===================
+
+ class IAspect(Interface):
+ ...
+
+
+Proposed syntax in ALF files
+============================
+
+ <task
+ id="write_document"
+ title="asdf"
+ description="asdf">
+
+ <exit
+ name="complete"
+ activities="review_a review_b"
+ />
+
+ <aspect:assignee
+ kind="actual"
+ roles="Agency"
+ contentRoles="Author"/>
+
+ <aspect:permission-change
+ type="entry" /* XXX "entry" should be thought about
+ add="Edit"
+ roles="Assignee"
+ />
+
+ <aspect:permission-change
+ type="exit"
+ exit="complete"
+ remove="Edit"
+ roles="ProcessUser"
+ />
+
+ <aspect:routing
+ filter="exit"
+ exit="complete">
+ <make-route/>
+ </aspect:routing>
+ </task>
+
+ <task id="review_a">
+ <exit
+ name="deny"
+ activities="deny_review"
+ />
+
+ <exit
+ name="accept"
+ activities="publish"
+ />
+ </task>
+
+ <task id="review_b">
+ </task>
+
+ <expression id="publish">
+ <aspect:routing>
+ <make-gate />
+ </aspect:routing>
+ </expression>
+
How to implement this
---------------------
- - Re-design the work item states and exiting (exit versus
- continuation/spawn)
-
- - Make 'fallout' an exit that can be handled by an aspect that
- re-implements the current fallout behaviour by default.
+ - Re-design the work item states and exiting (exit versus
+ continuation/spawn)
+
+ - Make 'fallout' an exit that can be handled by an aspect that re-implements
+ the current fallout behaviour by default.
- - Define and create aspect infrastructure
+ - Define and create aspect infrastructure
- - Redefine security, responsibility, status, routing and logging as
aspects
+ - Redefine security, responsibility, status, routing and logging as aspects
- - Provide a general "scripting" aspect
+ - Provide a general "scripting" aspect
- - Extend the configuration activity to support configuration of aspects
+ - Extend the configuration activity to support configuration of aspects
- - Provide an initial cut of the visualisation on the business process
- aspect.
+ - Provide an initial cut of the visualisation on the business process
+ aspect.
- - Remove "start_activity" property
+ - Remove "start_activity" property
+
+ - Extend work item interface to include an optional "result".
- - Extend work item interface to include an optional "result".
Future
------
(at)(at) -88,4 +205,3 (at)(at)
In the future, we will add other aspects, including:
- Defer execution (for asynchronous processing)
-
|
