A graph is a data structure where nodes are linked together. One
node is linked to several other nodes and so on. A directed graph is
a graph where the links have a specific direction. A tree is a special
form of graph (usually directed) that only branches in one direction.
In other words, a child node will never link to something higher in
the tree. It only branches down.
For workflow types of applications the nodes of a graph often represent
states in a workflow. The links between the nodes represent
transitions. Sometimes these transitions also have functionality
attached to them. It is often necessary to have circular workflows
or workflows that transition to another step outside of the normal
flow of the current "process". This makes a tree a poor data
structure to use since it cannot loop back on itself.
Although, I now realize that since we aren't working from the same set
of definitions, I shouldn't have taken your "tree" reference to be so
specific.
-Paul Speed
Jonathan Asbell wrote:
>
> Can you describe what you mean by graph. Do you mean a HashMap or List?
> How do you "jump"? How do you go follow decisions and results?
>
> ----- Original Message -----
> From: "Paul Speed" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 21, 2001 2:24 AM
> Subject: Re: Opening up a thread on ALTERNATE SCOPES
>
> > Just one small point...
> >
> > In all my (admittedly brief compared to some) travels through workflow
> > land, I've never had a workflow that was specifically tree. They all
> > end up forming a graph at some point.
> >
> > One could argue that you can just have jump points from one branch to
> > another, but in my experience, after many iterations the tree becomes
> > more of a hinderance than a boon as jump points become more frequent.
> >
> > It might be better to design it to be a graph structure from the
> > beginning.
> >
> > -Paul Speed
> >
> > Jonathan Asbell wrote:
> > >
> > > Since my needs are for web container persistence, let me make a
> suggestion
> > > in that area.
> > > An object called WorkflowPath could be created with configurable values
> > > sucked up from a file. The values could be some kind of tree, like a
> > > decision/process tree. The WorkflowPath object would be stored in
> > > application scope, or a custom scope as mentioned below in the original
> > > post, such as Sub-Application scope. When you begin a process you grab
> the
> > > WorkflowPath from the scope stored under a name like "loginWorkflow",
> and
> > > you would query it for the next step in the decision/process tree. It
> would
> > > be nice maybe to have a pointer as to where you are in the sequence of
> > > things. Anyone want to add to this? Anyone want to dis this? Are you
> all
> > > asleep on this warm New York Summer night? =)
> > >
> > > ----- Original Message -----
> > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, June 20, 2001 11:25 PM
> > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > >
> > > > Jonathan Asbell wrote:
> > > > >
> > > > > Persistent storage is an option too. I was hoping, however to limit
> > > calls
> > > > > through the enterprise parts and database.
> > > >
> > > > Why?
> > > >
> > > > > You could argue that it belongs
> > > > > there because the database is the central location holding all data
> and
> > > > > information and therefore should hold workflow info, especially in
> the
> > > face
> > > > > of changing services/activities. However, must I consult the
> database
> > > or a
> > > > > db developer each time I want to add, change, or see anything? That
> is
> > > a
> > > > > time waster.
> > > >
> > > > Not really. I mean, I guess it's your design requirements. I would
> > > > want it to be that a user in a process (or a process itself) has no
> > > > requirement of 'immediate completion' - i.e. some part of the flow can
> > > > take a while.
> > > >
> > > > So then if the servlet container goes down, I don't care. No state
> > > > lost.
> > > >
> > > > >
> > > > > If you were not going to use persistent storage, how would you do
> it?
> > > >
> > > > For what I want to do, i can't really escape it. Somewhere, something
> > > > has to remember the state - assume the servlet container is going down
> > > > at some point...
> > > >
> > > > geir
> > > >
> > > > > ----- Original Message -----
> > > > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> > > > > To: <[EMAIL PROTECTED]>
> > > > > Sent: Wednesday, June 20, 2001 10:17 PM
> > > > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > > > >
> > > > > > Can I ask why you don't go with persistant storage, like a rdbms?
> I
> > > > > > have been thinking about workflow recently as well, although not
> > > > > > specifically w/in struts, and I believe that for the general
> solution,
> > > > > > where someone can come back a long time later and resume, or be it
> an
> > > > > > automated process, persistant storage would be required.
> > > > > >
> > > > > > geir
> > > > > >
> > > > > >
> > > > > > > Jonathan Asbell wrote:
> > > > > > >
> > > > > > > Hello all. We were talking about workflow a few weeks ago and
> the
> > > > > > > conversation dissipated. I am trying to open it up again
> because I
> > > > > > > have found a need for more scopes, and a need to implement these
> new
> > > > > > > scopes in the next few months. I am interested specifically in
> how
> > > it
> > > > > > > can be implemented in Struts. Let me begin with the new scopes.
> > > > > > >
> > > > > > > 1) Workflow scope within an application
> > > > > > > Store values from the first step until the final step and then
> get
> > > rid
> > > > > > > of the values
> > > > > > > You could probably use an adaptor, hide implementation from the
> > > > > > > developer, and store this scope inside the "session" scope
> > > > > > > Example - within an application store a value Do Activity 1,
> then do
> > > > > > > Activity 2, then do Activity 3, then throw out the value
> > > > > > >
> > > > > > >
> > > > > > > 2) Workflow between applications (mentioned by Dan Connelly
> earlier)
> > > > > > > Store values from the first step until the final step and then
> get
> > > rid
> > > > > > > of the values
> > > > > > > You could probably use an adaptor, hide implementation from the
> > > > > > > developer, and store this scope inside the "application" scope
> > > > > > > Example - store a value and do Activity 1 in Application 1, then
> do
> > > > > > > Activity 2 in Application 2, then do Activity 3 in Application
> 3,
> > > then
> > > > > > > throw out the value
> > > > > > >
> > > > > > >
> > > > > > > 3) Sub-Application scope
> > > > > > > Store values that pertain to a sub-directory within an
> application
> > > > > > > You could probably use an adaptor, hide implementation from the
> > > > > > > developer, and store this scope inside the "session" or
> > > "application"
> > > > > > > scope though I'm not sure which would be more appropriate.
> > > > > > > Example - Your applcation is a magazine which has 4 different
> > > > > > > sections, and you want to store values only pertaining to each
> > > > > > > section. When you leave the section the value is not visible,
> and
> > > may
> > > > > > > or may not disappear (depending on what you want to do).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Geir Magnusson Jr. [EMAIL PROTECTED]
> > > > > > System and Software Consulting
> > > > > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > > > > You have a genius for suggesting things I've come a cropper with!
> > > > > >
> > > >
> > > > --
> > > > Geir Magnusson Jr. [EMAIL PROTECTED]
> > > > System and Software Consulting
> > > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > > You have a genius for suggesting things I've come a cropper with!
> > > >
> >
