Allow case data types to be dynamically altered at run-time: "parametrised" cases

[yawlfoundation]

The Worklet Service allows one of a number of pre-prepared cases to be
substituted dynamically for a workitem at run-time.

However, each of these is still restricted to the data type definitions
coded in it at edit time. What would be very powerful (and kind of a
complement to the worklet service stuff) would be the ability to alter
particular data types at runtime programmatically (from a custom service,
observer gateway, or even a codelet I guess).

To illustrate, I have developed a case which uses a "gateway" custom
service to pass various requests onto remote objects. Each request type
will have differing input/output XML requirements. The input/output data
types are used at many places within the case, because I have
multi-instance tasks which will call multiple remote object instances and
aggregate their responses. (The case is not just a single "DoRemoteThing"
task, but has various bits and pieces to prepare data and synchronise the
remote objects with the potentially multiple workitem YAWL threads.)

Currently, I have to develop *separate* entire cases for each remote object
request type and launch the appropriate one programmatically (with
resultant parallel-maintenance headaches if I decide to change how the
cases work).

What I really want is to be able to define RemoteObjectInput and
RemoteObjectOutput complex data types in a *single* case and, when I launch
it, dynamically change these particular definitions to the correct
input/output complex element sequences. The API available to a custom
service doesn't give me this ability. (Maybe I could from an observer
gateway, given its "native" access to the YAWL engine code, but this
effectively requires me to have detailed internal knowledge and potentially
break things badly.)

I would imagine that such a capability could have many novel uses (e.g. for
dynamic forms?). One might also want to dynamically alter data types
*within* a case, particularly when moving to a subnet (which currently just
shares the exact same data type definitions as the root net).

This is something I may well try to develop myself soon anyway (because I
really need the functionality), so would be happy to liaise with YAWL
developers if any are willing. (I have a fair amount of Java development
experience and--now at least-- some understanding of the YAWL code's
architecture. Obviously some developer assistance would massively help
though.) 

Many thanks in advance for any consideration,
Stuart

Original issue reported on code.google.com by [email protected] on 16 Oct 2009 at 5:31

[yawlfoundation]

Perhaps I should summarise, since I think there are three main potential 
capabilities
discussed here:

1. Defer the definition of (selected) XML Schema data types until case launch 
time
(or be able to redefine them; amounts to the same thing)

2. Dynamically change XML Schema data types during case execution.

3. Restrict/alter the XML Schema data types for composite task subnets. That 
is, be
able to *statically* define the data types for the subnet, as well as the 
actual net
parameters, instead of using the overall specification ones (so that one can 
tighten
the runtime validation and define subnet specific complex types).
[Capabilities 1 and 2 might then also enable one to change these dynamically as 
well.]

Capability 1 seems the most useful, and is the main one I'm personally 
interested in
as a user. Having had a quick look at the (excellent!) workflow patterns 
material, I
guess that:

-- 1 is effectively a flavour of an "Environment to Case" push-oriented 
interaction
which affects case scope data *types*

-- 2 is some kind of "Task to Case" data interaction which isn't in the 
patterns (?)

-- 3 reflects the concept of well-defined block scope data, where YAWL currently
supports the definition of variables at this scope, but not data *types* (which 
are
just carried over from the overall case)

I suppose that, therefore, there may be some research/theoretical interest in 
how
data types and instances are jointly or separately regarded in the workflow 
patterns.
For example, the Environment to Case - Push pattern states:

"During the course of the execution of a case, new case-level data elements may
become available or the values of existing items may change. A means of 
communicating
these data updates to a nominated case is required."

This doesn't explicitly cover this type/instance distinction (where YAWL 
currently
requires expected instances and types to be statically defined at case design 
time).

Anyway, enough from me. Hope this makes sense and is of interest.

Regards,
Stuart

Original comment by [email protected] on 22 Oct 2009 at 1:39