Persistent storage is an option too.  I was hoping, however to limit calls
through the enterprise parts and database.  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.

If you were not going to use persistent storage, how would you do it?



----- 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!
>

Reply via email to