You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oodt.apache.org by Brian Foster <ho...@me.com> on 2012/11/08 00:05:46 UTC
Workflow Task/Condition Instances...
hey chris,
so i'm going through this WorkflowProcessor stuff and finishing it up... I'm trying to make it so that WorkflowProcessor is used by all Workflow Engines... WorkflowInstance holds the state, times, etc.. for a Workflow, and then a WorkflowProcessor is response for analyzing that WorkflowInstance and determining what to run next in the Workflow... in this process i've notices that we really don't have any "WorkflowInstance-like" class for Tasks and Conditions... A WorkflowTaskInstance is actually the runnable task/condition job... I know this would be a big structural change, but i think WorkflowTaskInstance and WorkflowConditionInstance should be similar to WorkflowInstance (it should hold the state, times, etc... for a task/condition)... then possibly introduce a WorkflowTaskExecutable and WorkflowConditionExecutable interface, or something like that, which CAS-PGE and all other runnable tasks would implement instead... then i've already created a version of WorkflowInstance which would hold the WorkflowTaskInstances and WorkflowConditionInstance for it's task, preConds, and postConds... this way when one loads a WorkflowInstance they would have access to all the state, times, etc.. of everything in that workflow... this makes is very easy to create a WorkflowProcessor which then is stateless and when given a WorkflowInstance can easy determine what is the next thing to run or what state the workflow is in... this new design i working toward also ditches the whole WorkflowProcessorListener interface stuff, which i never liked in the first place, but just never came up with something better.
-brian
Re: Workflow Task/Condition Instances...
Posted by Chris A Mattmann <ch...@gmail.com>.
Thanks dude will scope now!
On Nov 8, 2012, at 3:42 PM, Brian Foster wrote:
> hey chris,
>
> i got the initial changes to Workflow, WorkflowInstance, and WorkflowProcessor in... https://reviews.apache.org/r/7944/ ... let me know what you think... lol
>
> -brian
>
>
> On Nov 7, 2012, at 6:16 PM, Brian Foster wrote:
>
>>
>> hey chris,
>>
>> I think i work this out... i'm gonna create a RunnableInstance class... this will then hold the state, start/end times, type (TASK or CONDITION), and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
>>
>> -brian
>>
>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
>>
>>> hey chris,
>>>
>>> so i'm going through this WorkflowProcessor stuff and finishing it up... I'm trying to make it so that WorkflowProcessor is used by all Workflow Engines... WorkflowInstance holds the state, times, etc.. for a Workflow, and then a WorkflowProcessor is response for analyzing that WorkflowInstance and determining what to run next in the Workflow... in this process i've notices that we really don't have any "WorkflowInstance-like" class for Tasks and Conditions... A WorkflowTaskInstance is actually the runnable task/condition job... I know this would be a big structural change, but i think WorkflowTaskInstance and WorkflowConditionInstance should be similar to WorkflowInstance (it should hold the state, times, etc... for a task/condition)... then possibly introduce a WorkflowTaskExecutable and WorkflowConditionExecutable interface, or something like that, which CAS-PGE and all other runnable tasks would implement instead... then i've already created a version of WorkflowInstance which would hold the WorkflowTaskInstances and WorkflowConditionInstance for it's task, preConds, and postConds... this way when one loads a WorkflowInstance they would have access to all the state, times, etc.. of everything in that workflow... this makes is very easy to create a WorkflowProcessor which then is stateless and when given a WorkflowInstance can easy determine what is the next thing to run or what state the workflow is in... this new design i working toward also ditches the whole WorkflowProcessorListener interface stuff, which i never liked in the first place, but just never came up with something better.
>>>
>>> -brian
>>
>
Re: Workflow Task/Condition Instances...
Posted by Brian Foster <ho...@me.com>.
hey chris,
i got the initial changes to Workflow, WorkflowInstance, and WorkflowProcessor in... https://reviews.apache.org/r/7944/ ... let me know what you think... lol
-brian
On Nov 7, 2012, at 6:16 PM, Brian Foster wrote:
>
> hey chris,
>
> I think i work this out... i'm gonna create a RunnableInstance class... this will then hold the state, start/end times, type (TASK or CONDITION), and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
>
> -brian
>
> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
>
>> hey chris,
>>
>> so i'm going through this WorkflowProcessor stuff and finishing it up... I'm trying to make it so that WorkflowProcessor is used by all Workflow Engines... WorkflowInstance holds the state, times, etc.. for a Workflow, and then a WorkflowProcessor is response for analyzing that WorkflowInstance and determining what to run next in the Workflow... in this process i've notices that we really don't have any "WorkflowInstance-like" class for Tasks and Conditions... A WorkflowTaskInstance is actually the runnable task/condition job... I know this would be a big structural change, but i think WorkflowTaskInstance and WorkflowConditionInstance should be similar to WorkflowInstance (it should hold the state, times, etc... for a task/condition)... then possibly introduce a WorkflowTaskExecutable and WorkflowConditionExecutable interface, or something like that, which CAS-PGE and all other runnable tasks would implement instead... then i've already created a version of WorkflowInstance which would hold the WorkflowTaskInstances and WorkflowConditionInstance for it's task, preConds, and postConds... this way when one loads a WorkflowInstance they would have access to all the state, times, etc.. of everything in that workflow... this makes is very easy to create a WorkflowProcessor which then is stateless and when given a WorkflowInstance can easy determine what is the next thing to run or what state the workflow is in... this new design i working toward also ditches the whole WorkflowProcessorListener interface stuff, which i never liked in the first place, but just never came up with something better.
>>
>> -brian
>
Re: Workflow Task/Condition Instances...
Posted by Bruce Barkstrom <br...@gmail.com>.
The basic algorithm for scheduling is covered in almost any
book on operations research. The key is topological sorting,
which is also covered in most books on elementary computer
science.
In somewhat more advanced work, you'll get to scheduling
disciplines that connect with throughput calculations. These
include earliest deadline first and rate monotonic scheduling.
This kind of background does show up in industrial engineering,
as well as job scheduling in CPU's. It's pretty ubiquitous.
Bruce B.
On Sun, Nov 11, 2012 at 2:30 AM, Mattmann, Chris A (388J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Hi Bruce,
>
> Thanks for the insights. It makes me believe that what we're doing is sound
> since we've got your first 2 points covered on a per-workflow, and a
> per-task
> basis, down to the hierarchies and appropriate time tracking and
> scheduling.
>
> I'll think about the appropriate algorithms for duration and scheduling
> based
> on that and I look forward to reading more as I go along implementing.
>
> Thanks and take care!
>
> Cheers,
> Chris
>
> On Nov 10, 2012, at 6:40 AM, Bruce Barkstrom wrote:
>
> > Thanks. It may take a week or two for the WMSCI folks
> > to request a review. My submission deadline is Nov. 16,
> > which should be no problem since I already have a first
> > draft and it's only about 5 pages long.
> >
> > There are a few subtleties about the scheduling
> > problem:
> >
> > 1. To do scheduling, you'll need to include an estimate
> > of the (wall clock) duration of each job. When you do the
> > computation, you'll have an earliest start, latest start,
> > earliest finish, and latest finish for each job. You'll usually
> > want to compute slack times and find the critical path.
> > This kind of work usually appears as a Gantt chart, which
> > may mean you'll have to find software to draw this kind
> > of chart. MS Project can show you what that looks like,
> > but I haven't found a short way to get enough access
> > to the innards of that software.
> >
> > 2. I suspect you're going to have a lot of jobs to track.
> > You may want to figure out how to create hierarchies
> > and to have different time horizons (more precision in
> > times close to now; less precision in times far from now).
> >
> > 3. This stuff can be coupled to cost estimation as well.
> >
> > 4. You may need to consider reprocessing of product
> > lines. That gets into versioning.
> >
> > 5. Schedules are really stochastic.
> >
> > As a strong suggestion, do a simple, deterministic
> > duration schedule algorithm first.
> >
> > Bruce B.
> >
> > On Fri, Nov 9, 2012 at 10:29 PM, Mattmann, Chris A (388J) <
> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> Hey Bruce,
> >>
> >> Yes please provide my name as a reviewer and I have scoped out your ESI
> >> paper I believe when you brought it up before. We definitely need to
> >> incorporate
> >> some of the logic you mention below especially when we are dealing with
> >> the types
> >> of operational scenarios you mention in ES data production.
> >>
> >> Cheers,
> >> Chris
> >>
> >> On Nov 10, 2012, at 2:30 AM, Bruce Barkstrom wrote:
> >>
> >>> I'd strongly suggest looking at my paper in ESI. It's got fairly
> >> detailed
> >>> data structures - in Ada, as you might expect from me. While that
> >>> isn't necessarily critical - I'd recommend doing the calculations in
> >>> RAM because the topological sort (which is a breadth first search
> >>> - if I recall correctly, although you'd be wise to check) is easiest to
> >>> implement as a recursive traversal of the production graph when that's
> >>> represented as an adjacency list, rather than an adjacency matrix.
> >>>
> >>> There are some subtleties that are likely to occur when you want to
> >>> do a multi-time scale approach. In other words, you might want
> >>> a detailed schedule for the next day, but not for the next year.
> >>> Those different time scales need to produce different schedules
> >>> with different granularities. It will complicate the data structures.
> >>>
> >>> There's also an issue for design when the production is done with
> >>> product lines. I don't expect these to show up for many production
> >>> problems. They do show up in operational production and in
> >>> climate data record production.
> >>>
> >>> I've worked on these problems - but it's not what I'm doing right now.
> >>>
> >>> I'm expecting to submit a paper to an odd conference called WMSCI
> >>> 2013. The paper is on using Formal Concept Analysis that is related
> >>> to some of the set theory work that folks doing ontologies use, but
> >>> can also help in classifying things. WMSCI is a bit of an oddball
> >>> conference - all kinds of system work, including semiotics, information
> >>> theory. It's held in Orlando in July - and has a rather large
> contingent
> >>> of participants from Latin America. I think they complicate the
> >> refereeing
> >>> process by using double blind and other methods of reviewing
> submissions.
> >>> I need to provide names of prospective reviewers to get the paper
> through
> >>> the submission. I'd appreciate it if I could put your name in as a
> >>> reviewer.
> >>>
> >>> Bruce B.
> >>>
> >>> On Thu, Nov 8, 2012 at 11:27 PM, Mattmann, Chris A (388J) <
> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
> >>>
> >>>> Thanks Bruce -- yep we carry it forward as a model called "Workflow"
> >> which
> >>>> has a corresponding Java class hierarchy behind it, and a serialized
> >>>> representation
> >>>> in XML, and in a DB format.
> >>>>
> >>>> Cheers,
> >>>> Chris
> >>>>
> >>>> On Nov 9, 2012, at 7:53 AM, Bruce Barkstrom wrote:
> >>>>
> >>>>> You might consider building the graph in advance and use
> >>>>> it for planning purposes.
> >>>>>
> >>>>> Bruce B.
> >>>>>
> >>>>> On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
> >>>>> <ch...@gmail.com>wrote:
> >>>>>
> >>>>>> Hey Brian,
> >>>>>>
> >>>>>> That sounds Perfect! I like the idea of simply creating a
> >>>> RunnableInstance
> >>>>>> and think it fits the architecture well!
> >>>>>> +50 to proceed down that path.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Chris
> >>>>>>
> >>>>>> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> hey chris,
> >>>>>>>
> >>>>>>> I think i work this out... i'm gonna create a RunnableInstance
> >> class...
> >>>>>> this will then hold the state, start/end times, type (TASK or
> >>>> CONDITION),
> >>>>>> and the class to run (WorkflowTaskInstance or
> >>>> WorkflowConditionInstance).
> >>>>>>>
> >>>>>>> -brian
> >>>>>>>
> >>>>>>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
> >>>>>>>
> >>>>>>>> hey chris,
> >>>>>>>>
> >>>>>>>> so i'm going through this WorkflowProcessor stuff and finishing it
> >>>>>> up... I'm trying to make it so that WorkflowProcessor is used by all
> >>>>>> Workflow Engines... WorkflowInstance holds the state, times, etc..
> >> for a
> >>>>>> Workflow, and then a WorkflowProcessor is response for analyzing
> that
> >>>>>> WorkflowInstance and determining what to run next in the Workflow...
> >> in
> >>>>>> this process i've notices that we really don't have any
> >>>>>> "WorkflowInstance-like" class for Tasks and Conditions... A
> >>>>>> WorkflowTaskInstance is actually the runnable task/condition job...
> I
> >>>> know
> >>>>>> this would be a big structural change, but i think
> >> WorkflowTaskInstance
> >>>> and
> >>>>>> WorkflowConditionInstance should be similar to WorkflowInstance (it
> >>>> should
> >>>>>> hold the state, times, etc... for a task/condition)... then possibly
> >>>>>> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
> >>>>>> interface, or something like that, which CAS-PGE and all other
> >> runnable
> >>>>>> tasks would implement instead... then i've already created a version
> >> of
> >>>>>> WorkflowInstance which would hold the WorkflowTaskInstances and
> >>>>>> WorkflowConditionInstance for it's task, preConds, and postConds...
> >> this
> >>>>>> way when one loads a WorkflowInstance they would have access to all
> >> the
> >>>>>> state, times, etc.. of everything in that workflow... this makes is
> >> very
> >>>>>> easy to create a WorkflowProcessor which then is stateless and when
> >>>> given a
> >>>>>> WorkflowInstance can easy determine what is the next thing to run or
> >>>> what
> >>>>>> state the workflow is in... this new design i working toward also
> >>>> ditches
> >>>>>> the whole WorkflowProcessorListener interface stuff, which i never
> >>>> liked in
> >>>>>> the first place, but just never came up with something better.
> >>>>>>>>
> >>>>>>>> -brian
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Workflow Task/Condition Instances...
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Bruce,
Thanks for the insights. It makes me believe that what we're doing is sound
since we've got your first 2 points covered on a per-workflow, and a per-task
basis, down to the hierarchies and appropriate time tracking and scheduling.
I'll think about the appropriate algorithms for duration and scheduling based
on that and I look forward to reading more as I go along implementing.
Thanks and take care!
Cheers,
Chris
On Nov 10, 2012, at 6:40 AM, Bruce Barkstrom wrote:
> Thanks. It may take a week or two for the WMSCI folks
> to request a review. My submission deadline is Nov. 16,
> which should be no problem since I already have a first
> draft and it's only about 5 pages long.
>
> There are a few subtleties about the scheduling
> problem:
>
> 1. To do scheduling, you'll need to include an estimate
> of the (wall clock) duration of each job. When you do the
> computation, you'll have an earliest start, latest start,
> earliest finish, and latest finish for each job. You'll usually
> want to compute slack times and find the critical path.
> This kind of work usually appears as a Gantt chart, which
> may mean you'll have to find software to draw this kind
> of chart. MS Project can show you what that looks like,
> but I haven't found a short way to get enough access
> to the innards of that software.
>
> 2. I suspect you're going to have a lot of jobs to track.
> You may want to figure out how to create hierarchies
> and to have different time horizons (more precision in
> times close to now; less precision in times far from now).
>
> 3. This stuff can be coupled to cost estimation as well.
>
> 4. You may need to consider reprocessing of product
> lines. That gets into versioning.
>
> 5. Schedules are really stochastic.
>
> As a strong suggestion, do a simple, deterministic
> duration schedule algorithm first.
>
> Bruce B.
>
> On Fri, Nov 9, 2012 at 10:29 PM, Mattmann, Chris A (388J) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Hey Bruce,
>>
>> Yes please provide my name as a reviewer and I have scoped out your ESI
>> paper I believe when you brought it up before. We definitely need to
>> incorporate
>> some of the logic you mention below especially when we are dealing with
>> the types
>> of operational scenarios you mention in ES data production.
>>
>> Cheers,
>> Chris
>>
>> On Nov 10, 2012, at 2:30 AM, Bruce Barkstrom wrote:
>>
>>> I'd strongly suggest looking at my paper in ESI. It's got fairly
>> detailed
>>> data structures - in Ada, as you might expect from me. While that
>>> isn't necessarily critical - I'd recommend doing the calculations in
>>> RAM because the topological sort (which is a breadth first search
>>> - if I recall correctly, although you'd be wise to check) is easiest to
>>> implement as a recursive traversal of the production graph when that's
>>> represented as an adjacency list, rather than an adjacency matrix.
>>>
>>> There are some subtleties that are likely to occur when you want to
>>> do a multi-time scale approach. In other words, you might want
>>> a detailed schedule for the next day, but not for the next year.
>>> Those different time scales need to produce different schedules
>>> with different granularities. It will complicate the data structures.
>>>
>>> There's also an issue for design when the production is done with
>>> product lines. I don't expect these to show up for many production
>>> problems. They do show up in operational production and in
>>> climate data record production.
>>>
>>> I've worked on these problems - but it's not what I'm doing right now.
>>>
>>> I'm expecting to submit a paper to an odd conference called WMSCI
>>> 2013. The paper is on using Formal Concept Analysis that is related
>>> to some of the set theory work that folks doing ontologies use, but
>>> can also help in classifying things. WMSCI is a bit of an oddball
>>> conference - all kinds of system work, including semiotics, information
>>> theory. It's held in Orlando in July - and has a rather large contingent
>>> of participants from Latin America. I think they complicate the
>> refereeing
>>> process by using double blind and other methods of reviewing submissions.
>>> I need to provide names of prospective reviewers to get the paper through
>>> the submission. I'd appreciate it if I could put your name in as a
>>> reviewer.
>>>
>>> Bruce B.
>>>
>>> On Thu, Nov 8, 2012 at 11:27 PM, Mattmann, Chris A (388J) <
>>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>>
>>>> Thanks Bruce -- yep we carry it forward as a model called "Workflow"
>> which
>>>> has a corresponding Java class hierarchy behind it, and a serialized
>>>> representation
>>>> in XML, and in a DB format.
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> On Nov 9, 2012, at 7:53 AM, Bruce Barkstrom wrote:
>>>>
>>>>> You might consider building the graph in advance and use
>>>>> it for planning purposes.
>>>>>
>>>>> Bruce B.
>>>>>
>>>>> On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
>>>>> <ch...@gmail.com>wrote:
>>>>>
>>>>>> Hey Brian,
>>>>>>
>>>>>> That sounds Perfect! I like the idea of simply creating a
>>>> RunnableInstance
>>>>>> and think it fits the architecture well!
>>>>>> +50 to proceed down that path.
>>>>>>
>>>>>> Cheers,
>>>>>> Chris
>>>>>>
>>>>>> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
>>>>>>
>>>>>>>
>>>>>>> hey chris,
>>>>>>>
>>>>>>> I think i work this out... i'm gonna create a RunnableInstance
>> class...
>>>>>> this will then hold the state, start/end times, type (TASK or
>>>> CONDITION),
>>>>>> and the class to run (WorkflowTaskInstance or
>>>> WorkflowConditionInstance).
>>>>>>>
>>>>>>> -brian
>>>>>>>
>>>>>>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
>>>>>>>
>>>>>>>> hey chris,
>>>>>>>>
>>>>>>>> so i'm going through this WorkflowProcessor stuff and finishing it
>>>>>> up... I'm trying to make it so that WorkflowProcessor is used by all
>>>>>> Workflow Engines... WorkflowInstance holds the state, times, etc..
>> for a
>>>>>> Workflow, and then a WorkflowProcessor is response for analyzing that
>>>>>> WorkflowInstance and determining what to run next in the Workflow...
>> in
>>>>>> this process i've notices that we really don't have any
>>>>>> "WorkflowInstance-like" class for Tasks and Conditions... A
>>>>>> WorkflowTaskInstance is actually the runnable task/condition job... I
>>>> know
>>>>>> this would be a big structural change, but i think
>> WorkflowTaskInstance
>>>> and
>>>>>> WorkflowConditionInstance should be similar to WorkflowInstance (it
>>>> should
>>>>>> hold the state, times, etc... for a task/condition)... then possibly
>>>>>> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
>>>>>> interface, or something like that, which CAS-PGE and all other
>> runnable
>>>>>> tasks would implement instead... then i've already created a version
>> of
>>>>>> WorkflowInstance which would hold the WorkflowTaskInstances and
>>>>>> WorkflowConditionInstance for it's task, preConds, and postConds...
>> this
>>>>>> way when one loads a WorkflowInstance they would have access to all
>> the
>>>>>> state, times, etc.. of everything in that workflow... this makes is
>> very
>>>>>> easy to create a WorkflowProcessor which then is stateless and when
>>>> given a
>>>>>> WorkflowInstance can easy determine what is the next thing to run or
>>>> what
>>>>>> state the workflow is in... this new design i working toward also
>>>> ditches
>>>>>> the whole WorkflowProcessorListener interface stuff, which i never
>>>> liked in
>>>>>> the first place, but just never came up with something better.
>>>>>>>>
>>>>>>>> -brian
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: Workflow Task/Condition Instances...
Posted by Bruce Barkstrom <br...@gmail.com>.
Thanks. It may take a week or two for the WMSCI folks
to request a review. My submission deadline is Nov. 16,
which should be no problem since I already have a first
draft and it's only about 5 pages long.
There are a few subtleties about the scheduling
problem:
1. To do scheduling, you'll need to include an estimate
of the (wall clock) duration of each job. When you do the
computation, you'll have an earliest start, latest start,
earliest finish, and latest finish for each job. You'll usually
want to compute slack times and find the critical path.
This kind of work usually appears as a Gantt chart, which
may mean you'll have to find software to draw this kind
of chart. MS Project can show you what that looks like,
but I haven't found a short way to get enough access
to the innards of that software.
2. I suspect you're going to have a lot of jobs to track.
You may want to figure out how to create hierarchies
and to have different time horizons (more precision in
times close to now; less precision in times far from now).
3. This stuff can be coupled to cost estimation as well.
4. You may need to consider reprocessing of product
lines. That gets into versioning.
5. Schedules are really stochastic.
As a strong suggestion, do a simple, deterministic
duration schedule algorithm first.
Bruce B.
On Fri, Nov 9, 2012 at 10:29 PM, Mattmann, Chris A (388J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Hey Bruce,
>
> Yes please provide my name as a reviewer and I have scoped out your ESI
> paper I believe when you brought it up before. We definitely need to
> incorporate
> some of the logic you mention below especially when we are dealing with
> the types
> of operational scenarios you mention in ES data production.
>
> Cheers,
> Chris
>
> On Nov 10, 2012, at 2:30 AM, Bruce Barkstrom wrote:
>
> > I'd strongly suggest looking at my paper in ESI. It's got fairly
> detailed
> > data structures - in Ada, as you might expect from me. While that
> > isn't necessarily critical - I'd recommend doing the calculations in
> > RAM because the topological sort (which is a breadth first search
> > - if I recall correctly, although you'd be wise to check) is easiest to
> > implement as a recursive traversal of the production graph when that's
> > represented as an adjacency list, rather than an adjacency matrix.
> >
> > There are some subtleties that are likely to occur when you want to
> > do a multi-time scale approach. In other words, you might want
> > a detailed schedule for the next day, but not for the next year.
> > Those different time scales need to produce different schedules
> > with different granularities. It will complicate the data structures.
> >
> > There's also an issue for design when the production is done with
> > product lines. I don't expect these to show up for many production
> > problems. They do show up in operational production and in
> > climate data record production.
> >
> > I've worked on these problems - but it's not what I'm doing right now.
> >
> > I'm expecting to submit a paper to an odd conference called WMSCI
> > 2013. The paper is on using Formal Concept Analysis that is related
> > to some of the set theory work that folks doing ontologies use, but
> > can also help in classifying things. WMSCI is a bit of an oddball
> > conference - all kinds of system work, including semiotics, information
> > theory. It's held in Orlando in July - and has a rather large contingent
> > of participants from Latin America. I think they complicate the
> refereeing
> > process by using double blind and other methods of reviewing submissions.
> > I need to provide names of prospective reviewers to get the paper through
> > the submission. I'd appreciate it if I could put your name in as a
> > reviewer.
> >
> > Bruce B.
> >
> > On Thu, Nov 8, 2012 at 11:27 PM, Mattmann, Chris A (388J) <
> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> Thanks Bruce -- yep we carry it forward as a model called "Workflow"
> which
> >> has a corresponding Java class hierarchy behind it, and a serialized
> >> representation
> >> in XML, and in a DB format.
> >>
> >> Cheers,
> >> Chris
> >>
> >> On Nov 9, 2012, at 7:53 AM, Bruce Barkstrom wrote:
> >>
> >>> You might consider building the graph in advance and use
> >>> it for planning purposes.
> >>>
> >>> Bruce B.
> >>>
> >>> On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
> >>> <ch...@gmail.com>wrote:
> >>>
> >>>> Hey Brian,
> >>>>
> >>>> That sounds Perfect! I like the idea of simply creating a
> >> RunnableInstance
> >>>> and think it fits the architecture well!
> >>>> +50 to proceed down that path.
> >>>>
> >>>> Cheers,
> >>>> Chris
> >>>>
> >>>> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
> >>>>
> >>>>>
> >>>>> hey chris,
> >>>>>
> >>>>> I think i work this out... i'm gonna create a RunnableInstance
> class...
> >>>> this will then hold the state, start/end times, type (TASK or
> >> CONDITION),
> >>>> and the class to run (WorkflowTaskInstance or
> >> WorkflowConditionInstance).
> >>>>>
> >>>>> -brian
> >>>>>
> >>>>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
> >>>>>
> >>>>>> hey chris,
> >>>>>>
> >>>>>> so i'm going through this WorkflowProcessor stuff and finishing it
> >>>> up... I'm trying to make it so that WorkflowProcessor is used by all
> >>>> Workflow Engines... WorkflowInstance holds the state, times, etc..
> for a
> >>>> Workflow, and then a WorkflowProcessor is response for analyzing that
> >>>> WorkflowInstance and determining what to run next in the Workflow...
> in
> >>>> this process i've notices that we really don't have any
> >>>> "WorkflowInstance-like" class for Tasks and Conditions... A
> >>>> WorkflowTaskInstance is actually the runnable task/condition job... I
> >> know
> >>>> this would be a big structural change, but i think
> WorkflowTaskInstance
> >> and
> >>>> WorkflowConditionInstance should be similar to WorkflowInstance (it
> >> should
> >>>> hold the state, times, etc... for a task/condition)... then possibly
> >>>> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
> >>>> interface, or something like that, which CAS-PGE and all other
> runnable
> >>>> tasks would implement instead... then i've already created a version
> of
> >>>> WorkflowInstance which would hold the WorkflowTaskInstances and
> >>>> WorkflowConditionInstance for it's task, preConds, and postConds...
> this
> >>>> way when one loads a WorkflowInstance they would have access to all
> the
> >>>> state, times, etc.. of everything in that workflow... this makes is
> very
> >>>> easy to create a WorkflowProcessor which then is stateless and when
> >> given a
> >>>> WorkflowInstance can easy determine what is the next thing to run or
> >> what
> >>>> state the workflow is in... this new design i working toward also
> >> ditches
> >>>> the whole WorkflowProcessorListener interface stuff, which i never
> >> liked in
> >>>> the first place, but just never came up with something better.
> >>>>>>
> >>>>>> -brian
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Workflow Task/Condition Instances...
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Bruce,
Yes please provide my name as a reviewer and I have scoped out your ESI
paper I believe when you brought it up before. We definitely need to incorporate
some of the logic you mention below especially when we are dealing with the types
of operational scenarios you mention in ES data production.
Cheers,
Chris
On Nov 10, 2012, at 2:30 AM, Bruce Barkstrom wrote:
> I'd strongly suggest looking at my paper in ESI. It's got fairly detailed
> data structures - in Ada, as you might expect from me. While that
> isn't necessarily critical - I'd recommend doing the calculations in
> RAM because the topological sort (which is a breadth first search
> - if I recall correctly, although you'd be wise to check) is easiest to
> implement as a recursive traversal of the production graph when that's
> represented as an adjacency list, rather than an adjacency matrix.
>
> There are some subtleties that are likely to occur when you want to
> do a multi-time scale approach. In other words, you might want
> a detailed schedule for the next day, but not for the next year.
> Those different time scales need to produce different schedules
> with different granularities. It will complicate the data structures.
>
> There's also an issue for design when the production is done with
> product lines. I don't expect these to show up for many production
> problems. They do show up in operational production and in
> climate data record production.
>
> I've worked on these problems - but it's not what I'm doing right now.
>
> I'm expecting to submit a paper to an odd conference called WMSCI
> 2013. The paper is on using Formal Concept Analysis that is related
> to some of the set theory work that folks doing ontologies use, but
> can also help in classifying things. WMSCI is a bit of an oddball
> conference - all kinds of system work, including semiotics, information
> theory. It's held in Orlando in July - and has a rather large contingent
> of participants from Latin America. I think they complicate the refereeing
> process by using double blind and other methods of reviewing submissions.
> I need to provide names of prospective reviewers to get the paper through
> the submission. I'd appreciate it if I could put your name in as a
> reviewer.
>
> Bruce B.
>
> On Thu, Nov 8, 2012 at 11:27 PM, Mattmann, Chris A (388J) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Thanks Bruce -- yep we carry it forward as a model called "Workflow" which
>> has a corresponding Java class hierarchy behind it, and a serialized
>> representation
>> in XML, and in a DB format.
>>
>> Cheers,
>> Chris
>>
>> On Nov 9, 2012, at 7:53 AM, Bruce Barkstrom wrote:
>>
>>> You might consider building the graph in advance and use
>>> it for planning purposes.
>>>
>>> Bruce B.
>>>
>>> On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
>>> <ch...@gmail.com>wrote:
>>>
>>>> Hey Brian,
>>>>
>>>> That sounds Perfect! I like the idea of simply creating a
>> RunnableInstance
>>>> and think it fits the architecture well!
>>>> +50 to proceed down that path.
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
>>>>
>>>>>
>>>>> hey chris,
>>>>>
>>>>> I think i work this out... i'm gonna create a RunnableInstance class...
>>>> this will then hold the state, start/end times, type (TASK or
>> CONDITION),
>>>> and the class to run (WorkflowTaskInstance or
>> WorkflowConditionInstance).
>>>>>
>>>>> -brian
>>>>>
>>>>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
>>>>>
>>>>>> hey chris,
>>>>>>
>>>>>> so i'm going through this WorkflowProcessor stuff and finishing it
>>>> up... I'm trying to make it so that WorkflowProcessor is used by all
>>>> Workflow Engines... WorkflowInstance holds the state, times, etc.. for a
>>>> Workflow, and then a WorkflowProcessor is response for analyzing that
>>>> WorkflowInstance and determining what to run next in the Workflow... in
>>>> this process i've notices that we really don't have any
>>>> "WorkflowInstance-like" class for Tasks and Conditions... A
>>>> WorkflowTaskInstance is actually the runnable task/condition job... I
>> know
>>>> this would be a big structural change, but i think WorkflowTaskInstance
>> and
>>>> WorkflowConditionInstance should be similar to WorkflowInstance (it
>> should
>>>> hold the state, times, etc... for a task/condition)... then possibly
>>>> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
>>>> interface, or something like that, which CAS-PGE and all other runnable
>>>> tasks would implement instead... then i've already created a version of
>>>> WorkflowInstance which would hold the WorkflowTaskInstances and
>>>> WorkflowConditionInstance for it's task, preConds, and postConds... this
>>>> way when one loads a WorkflowInstance they would have access to all the
>>>> state, times, etc.. of everything in that workflow... this makes is very
>>>> easy to create a WorkflowProcessor which then is stateless and when
>> given a
>>>> WorkflowInstance can easy determine what is the next thing to run or
>> what
>>>> state the workflow is in... this new design i working toward also
>> ditches
>>>> the whole WorkflowProcessorListener interface stuff, which i never
>> liked in
>>>> the first place, but just never came up with something better.
>>>>>>
>>>>>> -brian
>>>>>
>>>>
>>>>
>>
>>
Re: Workflow Task/Condition Instances...
Posted by Bruce Barkstrom <br...@gmail.com>.
I'd strongly suggest looking at my paper in ESI. It's got fairly detailed
data structures - in Ada, as you might expect from me. While that
isn't necessarily critical - I'd recommend doing the calculations in
RAM because the topological sort (which is a breadth first search
- if I recall correctly, although you'd be wise to check) is easiest to
implement as a recursive traversal of the production graph when that's
represented as an adjacency list, rather than an adjacency matrix.
There are some subtleties that are likely to occur when you want to
do a multi-time scale approach. In other words, you might want
a detailed schedule for the next day, but not for the next year.
Those different time scales need to produce different schedules
with different granularities. It will complicate the data structures.
There's also an issue for design when the production is done with
product lines. I don't expect these to show up for many production
problems. They do show up in operational production and in
climate data record production.
I've worked on these problems - but it's not what I'm doing right now.
I'm expecting to submit a paper to an odd conference called WMSCI
2013. The paper is on using Formal Concept Analysis that is related
to some of the set theory work that folks doing ontologies use, but
can also help in classifying things. WMSCI is a bit of an oddball
conference - all kinds of system work, including semiotics, information
theory. It's held in Orlando in July - and has a rather large contingent
of participants from Latin America. I think they complicate the refereeing
process by using double blind and other methods of reviewing submissions.
I need to provide names of prospective reviewers to get the paper through
the submission. I'd appreciate it if I could put your name in as a
reviewer.
Bruce B.
On Thu, Nov 8, 2012 at 11:27 PM, Mattmann, Chris A (388J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Thanks Bruce -- yep we carry it forward as a model called "Workflow" which
> has a corresponding Java class hierarchy behind it, and a serialized
> representation
> in XML, and in a DB format.
>
> Cheers,
> Chris
>
> On Nov 9, 2012, at 7:53 AM, Bruce Barkstrom wrote:
>
> > You might consider building the graph in advance and use
> > it for planning purposes.
> >
> > Bruce B.
> >
> > On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
> > <ch...@gmail.com>wrote:
> >
> >> Hey Brian,
> >>
> >> That sounds Perfect! I like the idea of simply creating a
> RunnableInstance
> >> and think it fits the architecture well!
> >> +50 to proceed down that path.
> >>
> >> Cheers,
> >> Chris
> >>
> >> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
> >>
> >>>
> >>> hey chris,
> >>>
> >>> I think i work this out... i'm gonna create a RunnableInstance class...
> >> this will then hold the state, start/end times, type (TASK or
> CONDITION),
> >> and the class to run (WorkflowTaskInstance or
> WorkflowConditionInstance).
> >>>
> >>> -brian
> >>>
> >>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
> >>>
> >>>> hey chris,
> >>>>
> >>>> so i'm going through this WorkflowProcessor stuff and finishing it
> >> up... I'm trying to make it so that WorkflowProcessor is used by all
> >> Workflow Engines... WorkflowInstance holds the state, times, etc.. for a
> >> Workflow, and then a WorkflowProcessor is response for analyzing that
> >> WorkflowInstance and determining what to run next in the Workflow... in
> >> this process i've notices that we really don't have any
> >> "WorkflowInstance-like" class for Tasks and Conditions... A
> >> WorkflowTaskInstance is actually the runnable task/condition job... I
> know
> >> this would be a big structural change, but i think WorkflowTaskInstance
> and
> >> WorkflowConditionInstance should be similar to WorkflowInstance (it
> should
> >> hold the state, times, etc... for a task/condition)... then possibly
> >> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
> >> interface, or something like that, which CAS-PGE and all other runnable
> >> tasks would implement instead... then i've already created a version of
> >> WorkflowInstance which would hold the WorkflowTaskInstances and
> >> WorkflowConditionInstance for it's task, preConds, and postConds... this
> >> way when one loads a WorkflowInstance they would have access to all the
> >> state, times, etc.. of everything in that workflow... this makes is very
> >> easy to create a WorkflowProcessor which then is stateless and when
> given a
> >> WorkflowInstance can easy determine what is the next thing to run or
> what
> >> state the workflow is in... this new design i working toward also
> ditches
> >> the whole WorkflowProcessorListener interface stuff, which i never
> liked in
> >> the first place, but just never came up with something better.
> >>>>
> >>>> -brian
> >>>
> >>
> >>
>
>
Re: Workflow Task/Condition Instances...
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Thanks Bruce -- yep we carry it forward as a model called "Workflow" which
has a corresponding Java class hierarchy behind it, and a serialized representation
in XML, and in a DB format.
Cheers,
Chris
On Nov 9, 2012, at 7:53 AM, Bruce Barkstrom wrote:
> You might consider building the graph in advance and use
> it for planning purposes.
>
> Bruce B.
>
> On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
> <ch...@gmail.com>wrote:
>
>> Hey Brian,
>>
>> That sounds Perfect! I like the idea of simply creating a RunnableInstance
>> and think it fits the architecture well!
>> +50 to proceed down that path.
>>
>> Cheers,
>> Chris
>>
>> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
>>
>>>
>>> hey chris,
>>>
>>> I think i work this out... i'm gonna create a RunnableInstance class...
>> this will then hold the state, start/end times, type (TASK or CONDITION),
>> and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
>>>
>>> -brian
>>>
>>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
>>>
>>>> hey chris,
>>>>
>>>> so i'm going through this WorkflowProcessor stuff and finishing it
>> up... I'm trying to make it so that WorkflowProcessor is used by all
>> Workflow Engines... WorkflowInstance holds the state, times, etc.. for a
>> Workflow, and then a WorkflowProcessor is response for analyzing that
>> WorkflowInstance and determining what to run next in the Workflow... in
>> this process i've notices that we really don't have any
>> "WorkflowInstance-like" class for Tasks and Conditions... A
>> WorkflowTaskInstance is actually the runnable task/condition job... I know
>> this would be a big structural change, but i think WorkflowTaskInstance and
>> WorkflowConditionInstance should be similar to WorkflowInstance (it should
>> hold the state, times, etc... for a task/condition)... then possibly
>> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
>> interface, or something like that, which CAS-PGE and all other runnable
>> tasks would implement instead... then i've already created a version of
>> WorkflowInstance which would hold the WorkflowTaskInstances and
>> WorkflowConditionInstance for it's task, preConds, and postConds... this
>> way when one loads a WorkflowInstance they would have access to all the
>> state, times, etc.. of everything in that workflow... this makes is very
>> easy to create a WorkflowProcessor which then is stateless and when given a
>> WorkflowInstance can easy determine what is the next thing to run or what
>> state the workflow is in... this new design i working toward also ditches
>> the whole WorkflowProcessorListener interface stuff, which i never liked in
>> the first place, but just never came up with something better.
>>>>
>>>> -brian
>>>
>>
>>
Re: Workflow Task/Condition Instances...
Posted by Bruce Barkstrom <br...@gmail.com>.
I've got a paper a year or two ago that describes the
production graph. The paper was in Earth Science
Informatics and is something like "Provenance Tracking ..."
The nodes in the graph (at the most granular level)
are the individual Product Generation Executables
(usually abbreviated PGE's). There are additional
nodes that represent the files - one set for input
and a second set for output.
If you attach a duration for the PGE's, then you can
use graph traversals to find the total time to completion
through the graph in the forward direction and reverse
the traversal to compute the time in the backward
direction. With those two, you can do the PERT
calculation of critical paths. Thus, one graph suffices
to describe the critical paths. If you know the start
time, you can compute the likely time for all the other
completion times in the schedule.
There are more complicated versions of this basic
calculation - but that will do for starters.
Let me know if you need more sources on algorithms.
This is pretty standard industrial engineering, also
known as operations research. There are also
stochastic versions.
Bruce B.
On Thu, Nov 8, 2012 at 6:58 PM, Brian Foster <ho...@me.com> wrote:
>
> hey bruce...
>
> ya i'm thinking of probably introducing some kinda of store that for a
> given WorkflowInstance you can determine if it belongs to a Graph, and if
> it does then create WorkflowInstance for the next Workflows in the Graph
> and run them.
>
> thanks!
> -brian
>
> On Nov 8, 2012, at 10:53 AM, Bruce Barkstrom wrote:
>
> > You might consider building the graph in advance and use
> > it for planning purposes.
> >
> > Bruce B.
> >
> > On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
> > <ch...@gmail.com>wrote:
> >
> >> Hey Brian,
> >>
> >> That sounds Perfect! I like the idea of simply creating a
> RunnableInstance
> >> and think it fits the architecture well!
> >> +50 to proceed down that path.
> >>
> >> Cheers,
> >> Chris
> >>
> >> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
> >>
> >>>
> >>> hey chris,
> >>>
> >>> I think i work this out... i'm gonna create a RunnableInstance class...
> >> this will then hold the state, start/end times, type (TASK or
> CONDITION),
> >> and the class to run (WorkflowTaskInstance or
> WorkflowConditionInstance).
> >>>
> >>> -brian
> >>>
> >>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
> >>>
> >>>> hey chris,
> >>>>
> >>>> so i'm going through this WorkflowProcessor stuff and finishing it
> >> up... I'm trying to make it so that WorkflowProcessor is used by all
> >> Workflow Engines... WorkflowInstance holds the state, times, etc.. for a
> >> Workflow, and then a WorkflowProcessor is response for analyzing that
> >> WorkflowInstance and determining what to run next in the Workflow... in
> >> this process i've notices that we really don't have any
> >> "WorkflowInstance-like" class for Tasks and Conditions... A
> >> WorkflowTaskInstance is actually the runnable task/condition job... I
> know
> >> this would be a big structural change, but i think WorkflowTaskInstance
> and
> >> WorkflowConditionInstance should be similar to WorkflowInstance (it
> should
> >> hold the state, times, etc... for a task/condition)... then possibly
> >> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
> >> interface, or something like that, which CAS-PGE and all other runnable
> >> tasks would implement instead... then i've already created a version of
> >> WorkflowInstance which would hold the WorkflowTaskInstances and
> >> WorkflowConditionInstance for it's task, preConds, and postConds... this
> >> way when one loads a WorkflowInstance they would have access to all the
> >> state, times, etc.. of everything in that workflow... this makes is very
> >> easy to create a WorkflowProcessor which then is stateless and when
> given a
> >> WorkflowInstance can easy determine what is the next thing to run or
> what
> >> state the workflow is in... this new design i working toward also
> ditches
> >> the whole WorkflowProcessorListener interface stuff, which i never
> liked in
> >> the first place, but just never came up with something better.
> >>>>
> >>>> -brian
> >>>
> >>
> >>
>
>
Re: Workflow Task/Condition Instances...
Posted by Brian Foster <ho...@me.com>.
hey bruce...
ya i'm thinking of probably introducing some kinda of store that for a given WorkflowInstance you can determine if it belongs to a Graph, and if it does then create WorkflowInstance for the next Workflows in the Graph and run them.
thanks!
-brian
On Nov 8, 2012, at 10:53 AM, Bruce Barkstrom wrote:
> You might consider building the graph in advance and use
> it for planning purposes.
>
> Bruce B.
>
> On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
> <ch...@gmail.com>wrote:
>
>> Hey Brian,
>>
>> That sounds Perfect! I like the idea of simply creating a RunnableInstance
>> and think it fits the architecture well!
>> +50 to proceed down that path.
>>
>> Cheers,
>> Chris
>>
>> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
>>
>>>
>>> hey chris,
>>>
>>> I think i work this out... i'm gonna create a RunnableInstance class...
>> this will then hold the state, start/end times, type (TASK or CONDITION),
>> and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
>>>
>>> -brian
>>>
>>> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
>>>
>>>> hey chris,
>>>>
>>>> so i'm going through this WorkflowProcessor stuff and finishing it
>> up... I'm trying to make it so that WorkflowProcessor is used by all
>> Workflow Engines... WorkflowInstance holds the state, times, etc.. for a
>> Workflow, and then a WorkflowProcessor is response for analyzing that
>> WorkflowInstance and determining what to run next in the Workflow... in
>> this process i've notices that we really don't have any
>> "WorkflowInstance-like" class for Tasks and Conditions... A
>> WorkflowTaskInstance is actually the runnable task/condition job... I know
>> this would be a big structural change, but i think WorkflowTaskInstance and
>> WorkflowConditionInstance should be similar to WorkflowInstance (it should
>> hold the state, times, etc... for a task/condition)... then possibly
>> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
>> interface, or something like that, which CAS-PGE and all other runnable
>> tasks would implement instead... then i've already created a version of
>> WorkflowInstance which would hold the WorkflowTaskInstances and
>> WorkflowConditionInstance for it's task, preConds, and postConds... this
>> way when one loads a WorkflowInstance they would have access to all the
>> state, times, etc.. of everything in that workflow... this makes is very
>> easy to create a WorkflowProcessor which then is stateless and when given a
>> WorkflowInstance can easy determine what is the next thing to run or what
>> state the workflow is in... this new design i working toward also ditches
>> the whole WorkflowProcessorListener interface stuff, which i never liked in
>> the first place, but just never came up with something better.
>>>>
>>>> -brian
>>>
>>
>>
Re: Workflow Task/Condition Instances...
Posted by Bruce Barkstrom <br...@gmail.com>.
You might consider building the graph in advance and use
it for planning purposes.
Bruce B.
On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann
<ch...@gmail.com>wrote:
> Hey Brian,
>
> That sounds Perfect! I like the idea of simply creating a RunnableInstance
> and think it fits the architecture well!
> +50 to proceed down that path.
>
> Cheers,
> Chris
>
> On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
>
> >
> > hey chris,
> >
> > I think i work this out... i'm gonna create a RunnableInstance class...
> this will then hold the state, start/end times, type (TASK or CONDITION),
> and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
> >
> > -brian
> >
> > On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
> >
> >> hey chris,
> >>
> >> so i'm going through this WorkflowProcessor stuff and finishing it
> up... I'm trying to make it so that WorkflowProcessor is used by all
> Workflow Engines... WorkflowInstance holds the state, times, etc.. for a
> Workflow, and then a WorkflowProcessor is response for analyzing that
> WorkflowInstance and determining what to run next in the Workflow... in
> this process i've notices that we really don't have any
> "WorkflowInstance-like" class for Tasks and Conditions... A
> WorkflowTaskInstance is actually the runnable task/condition job... I know
> this would be a big structural change, but i think WorkflowTaskInstance and
> WorkflowConditionInstance should be similar to WorkflowInstance (it should
> hold the state, times, etc... for a task/condition)... then possibly
> introduce a WorkflowTaskExecutable and WorkflowConditionExecutable
> interface, or something like that, which CAS-PGE and all other runnable
> tasks would implement instead... then i've already created a version of
> WorkflowInstance which would hold the WorkflowTaskInstances and
> WorkflowConditionInstance for it's task, preConds, and postConds... this
> way when one loads a WorkflowInstance they would have access to all the
> state, times, etc.. of everything in that workflow... this makes is very
> easy to create a WorkflowProcessor which then is stateless and when given a
> WorkflowInstance can easy determine what is the next thing to run or what
> state the workflow is in... this new design i working toward also ditches
> the whole WorkflowProcessorListener interface stuff, which i never liked in
> the first place, but just never came up with something better.
> >>
> >> -brian
> >
>
>
Re: Workflow Task/Condition Instances...
Posted by Chris A Mattmann <ch...@gmail.com>.
Hey Brian,
That sounds Perfect! I like the idea of simply creating a RunnableInstance and think it fits the architecture well!
+50 to proceed down that path.
Cheers,
Chris
On Nov 8, 2012, at 3:16 PM, Brian Foster wrote:
>
> hey chris,
>
> I think i work this out... i'm gonna create a RunnableInstance class... this will then hold the state, start/end times, type (TASK or CONDITION), and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
>
> -brian
>
> On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
>
>> hey chris,
>>
>> so i'm going through this WorkflowProcessor stuff and finishing it up... I'm trying to make it so that WorkflowProcessor is used by all Workflow Engines... WorkflowInstance holds the state, times, etc.. for a Workflow, and then a WorkflowProcessor is response for analyzing that WorkflowInstance and determining what to run next in the Workflow... in this process i've notices that we really don't have any "WorkflowInstance-like" class for Tasks and Conditions... A WorkflowTaskInstance is actually the runnable task/condition job... I know this would be a big structural change, but i think WorkflowTaskInstance and WorkflowConditionInstance should be similar to WorkflowInstance (it should hold the state, times, etc... for a task/condition)... then possibly introduce a WorkflowTaskExecutable and WorkflowConditionExecutable interface, or something like that, which CAS-PGE and all other runnable tasks would implement instead... then i've already created a version of WorkflowInstance which would hold the WorkflowTaskInstances and WorkflowConditionInstance for it's task, preConds, and postConds... this way when one loads a WorkflowInstance they would have access to all the state, times, etc.. of everything in that workflow... this makes is very easy to create a WorkflowProcessor which then is stateless and when given a WorkflowInstance can easy determine what is the next thing to run or what state the workflow is in... this new design i working toward also ditches the whole WorkflowProcessorListener interface stuff, which i never liked in the first place, but just never came up with something better.
>>
>> -brian
>
Re: Workflow Task/Condition Instances...
Posted by Brian Foster <ho...@me.com>.
hey chris,
I think i work this out... i'm gonna create a RunnableInstance class... this will then hold the state, start/end times, type (TASK or CONDITION), and the class to run (WorkflowTaskInstance or WorkflowConditionInstance).
-brian
On Nov 7, 2012, at 3:05 PM, Brian Foster wrote:
> hey chris,
>
> so i'm going through this WorkflowProcessor stuff and finishing it up... I'm trying to make it so that WorkflowProcessor is used by all Workflow Engines... WorkflowInstance holds the state, times, etc.. for a Workflow, and then a WorkflowProcessor is response for analyzing that WorkflowInstance and determining what to run next in the Workflow... in this process i've notices that we really don't have any "WorkflowInstance-like" class for Tasks and Conditions... A WorkflowTaskInstance is actually the runnable task/condition job... I know this would be a big structural change, but i think WorkflowTaskInstance and WorkflowConditionInstance should be similar to WorkflowInstance (it should hold the state, times, etc... for a task/condition)... then possibly introduce a WorkflowTaskExecutable and WorkflowConditionExecutable interface, or something like that, which CAS-PGE and all other runnable tasks would implement instead... then i've already created a version of WorkflowInstance which would hold the WorkflowTaskInstances and WorkflowConditionInstance for it's task, preConds, and postConds... this way when one loads a WorkflowInstance they would have access to all the state, times, etc.. of everything in that workflow... this makes is very easy to create a WorkflowProcessor which then is stateless and when given a WorkflowInstance can easy determine what is the next thing to run or what state the workflow is in... this new design i working toward also ditches the whole WorkflowProcessorListener interface stuff, which i never liked in the first place, but just never came up with something better.
>
> -brian