available data and be able to modify the data and store an updated version or
submit the final version and complete the activity.
The design of this prototype consists of three increments to the previous
one: an extension to the process definition package to load the information
about the workflow data, an extension to the engine to handle the data
during the enactment, and an extension to the web interface to present the
data to the user and allow modification.
The first increment is summarized by the class diagram shown in Figure
21.17. The WfProcessDefinition contains a new class WfDataDefinition , which
is linked to the WfActivity class through the WfAccessRestriction class that
specifies what data are available, and with what access permission during
the activity enactment.
The second increment addresses the classes WfProcessImpl and
WfActivityImpl . These two classes should now handle the data. The process
must instantiate the data that make up the context when the process is
created. The activity must access the data according to the access restric-
tions defined in the process definition.
How do we limit the access to the workflow data in the activities?
We can chose several actors as responsible for complying with the access
restrictions provided in the process definition. The three main possibilities
are: client code that accesses the JFlow interfaces (e.g. the JSP user inter-
face), the process classes and the activity classes.
Figure 21.17 Process definition with workflow data