Workflow, process flow, mapping of an activity diagram to code.
In my spare time I've been fooling around with an implementation of an infrastructure that would allow workflow to be configured at run-time. A well-defined process flow is clearly easier to configure/implement at compile-time using the conventional means (coding). Say, bool my_process_flow() { if (call_a() == success/true) { return call_b(); } else { return call_c(); } } However, to be able to quickly adjust to changing customer requirements and/or procedures we might decide to provide a set of building blocks (like call_a, call_b, call_c) that could be assembled into a certain process flow at run-time. Maybe even give that ability to the customer themselves through, say, GUI interface. So, the infrastructure boils down to an Activity class that has an operation associated with it and can have two sub-activities to be called when the operation succeeds or fails. For example, // Create an activity with call_a() as an operation. Activity a(call_a); // Register call_b to be called when call_a succeeds. a.success() = call_b; // Regiter call_c to be called when call_a fails. a.failure() = call_b; call_a, call_b, call_c can be Activity instances themselves. So, we are building hierarchical tree-like structure to represent a certain process flow. We can easily support concurrent activities like a.success() = Concurrent(call_b)(call_c); Loops can be supported in a similar fashion (via pre-defined functiors). All mostly based on boost::function (a very handy gadget I must say. Kudos to the authors). Now after such a long and boring introduction to my actual question. :-) Is there any interest in having/developing such an infrastructure under the boost umbrella? Any input is welcomed even if you think it is a crappy idea. Best, Vladimir.
Batov, Vladimir wrote:
In my spare time I've been fooling around with an implementation of an infrastructure that would allow workflow to be configured at run-time.
A well-defined process flow is clearly easier to configure/implement at compile-time using the conventional means (coding). Say,
bool my_process_flow() { if (call_a() == success/true) { return call_b(); } else { return call_c(); } }
However, to be able to quickly adjust to changing customer requirements and/or procedures we might decide to provide a set of building blocks (like call_a, call_b, call_c) that could be assembled into a certain process flow at run-time. Maybe even give that ability to the customer themselves through, say, GUI interface.
...
Now after such a long and boring introduction to my actual question. :-) Is there any interest in having/developing such an infrastructure under the boost umbrella? Any input is welcomed even if you think it is a crappy idea.
I am not sure whether I understand what this is about ('workflow' and 'customer' being two words I have never had cause to associate with any programs I write ;), but is this applicable to the checkpointing problem? ie, I have a long-running job running in a batch queue, and it gets a signal to terminate (say, by the CPU or wall-clock time exceeding some limit, or perhaps an actual unix signal), so it needs to checkpoint and submit a continuation job to the queue. The serialization part is straightforward, but it needs to break out of the main loop at some point and then restart it later. I currently do this with a 'TaskQueue', which is simply a queue of polymorphic (and serializable!) objects with a 'Run' function. Task::Run() itself returns a TaskQueue which is appended to the front of the queue. If this relates in any way to what you are doing, then YES, I would like a much cleaner and boost-ified way of doing it. Is boost::function serializable? Cheers, Ian McCulloch
participants (3)
-
Batov, Vladimir -
Ian McCulloch