oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Barkstrom <brbarkst...@gmail.com>
Subject Re: Workflow Task/Condition Instances...
Date Fri, 09 Nov 2012 13:30:56 GMT
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
> > <chris.mattmann@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
> >>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message