Thats fine. You would like the state of the workflow saved in spite of a
server failure. The truth is we should figure out both situations anyway
for both types of requirements:
1) storing state in a database
2) storing state in the web container
----- 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!
>
