Craig,
First of all - great job on the workflow proposal! I had begun writing a
workflow system based on basic Struts Actions with a bit of state
management thrown in, but what you're suggesting is much closer to what I
need.
I have a couple of requirements which I'm sure are not unique to my
application. The processes I'm modelling take a long time - the overall
process takes a few weeks to finish, and individual steps may take a few
minutes, a few hours or even a few days. This has a couple of implications:
1) there isn't going to be a user waiting for an interactive response; the
user triggers the process by sending in some data, and will receive a
notification when it's finally finished. In between, it's up to "the
system" to ensure that each step gets executed. 2) Most of the steps will
therefore be asynchronous (some of them involve getting approval, sometimes
with delays of days).
If the steps are asynchronous, this will require some state management, so
that the workflow engine knows where to start off again. I had been
thinking along the lines that an asynchronous step would actually consist
of two steps, one which will send a message to initiate the process, and
another to assimilate the results of the step (triggered by some event).
Once the message initiating the step has been sent, the activity will be
suspended until the end-of-step-event arrives. The workflow engine will
invoke the activity, starting up at the point it left off (that's where the
state management comes in). This also implies that instances of activities
will need unique ids, so that the workflow engine knows which instance to
invoke. The messaging bit could have several implementations - JMS, email,
HTTP, etc.
I realise it's early days - these are just a few points to ponder. I'll see
if I can adapt my earlier work to what you've come up with.
Regards
Colin M Sharples
I/T Architect
Business Innovation Services Group
IBM New Zealand
email: [EMAIL PROTECTED]
phone: 64-4-5769853
mobile: 64-21-402085
fax: 64-4-5765616
"Craig R.
McClanahan" To: [EMAIL PROTECTED]
<craigmcc@apac cc:
he.org> Subject: RE: Workflow Support Proposal
14/08/2001
07:25
Please respond
to struts-dev
On Mon, 13 Aug 2001, Dan - Blue Lotus Software wrote:
> I've got a few ideas, and a few comments on the proposal.
>
> Reading over your workflow support, it looks not that far from what I had
> done for per-request workflow support. You've also got it extended to
> multiple pages. Nice. The suggestion below, of allowing people to share
> workflows, is an interesting one. Given this, here's a few of my
> suggestions.
>
> First of all, I'd like to see some consistent address space available
across
> an entire workflow. I'd like to be able to request a form field value
from
> a FormBean on the 2nd page of the workflow, even though I'm on the 7th
page.
> I'd like to be able to transfer control for a workflow to another user,
in a
> secure fashion. Given this, here's my proposal.
>
> In your multi-wizard schema, add a <struts:page id="page1"> (or whatever)
to
> indicate a single page within the workflow. This would, in turn, contain
> the <struts:forward> and <struts:navigate> tags. The idea is that this
> provides a namespace for looking up FormBean values. From some other
page
> in the workflow, you should be able to look up values from the FormBean
> associated with a given page that is identified by name.
>
I guess I'm of a somewhat different opinion on how collaboration like this
should happen:
* ActionForm beans (from the perspective of the workflow system) are
an implementation detail -- collaboration that requires information
from multiple pages should be explicit
* If you're using request scope for form beans, they will not in fact
exist "in between" requests, or while other pages are being processed.
In the jakarta-commons code that I'm about to commit, you'll see that a
Context (the dynamic state of a particular computation) has a thing called
Scopes associated with it. Every Context has a "local" scope in which it
can stash beans by name, and the lifetime of these beans is the same as
the lifetime of the Context (i.e. for as long as you are executing the
steps in a particular activity, or until you explicitly remove
them). This seems like a better way for various pieces of a computation
to collaborate, IMHO.
> You should also be able to set up role-based security for a workflow by
the
> workflow name and the page name. I could, for instance, set the third
page
> of an application open for my boss' signature. I would have some GUI
that
> would add my boss to the role associated with the third page of the
> workflow. In such a case, the state (the collection of FormBeans for the
> workflow) must be persisted in some manner. I'm not sure if it would be
> easier/better to make this declarative--declare in the XML config file
that
> the state is persistent--or if the act of assigning a workflow to another
> user would implicitly cause the state to be persisted.
>
That sounds like a reasonable sort of thing to do in the webapp layer on
top of the core workflow engine. If we do, I'm a big believer in
declarative security, so I'd probably lean that way (and also reuse the
user principals and roles already defined in the servlet API).
> At that point, the other user would have to be able to go to the named
page
> of the workflow. If the user has been assigned the workflow from more
than
> one user, then the user will be allowed to choose which workflow should
be
> used. Thus, runtime workflows are identified by workflow name, page
name,
> and user name (the user name that assigned the workflow...probably set to
> null of the user initiated the workflow).
>
> Now, I think we would have a secure way to transfer workflows from one
user
> to another. Your configuration file format only needs to change
slightly.
> Workflow data can be interrogated during the workflow. I think it could
> work. It would require lots of JSP tags to facilitate things like
selecting
> a workflow when more than one is assigned.
>
Right now, I want to focus on getting something for the single-user
activity scripting up and functional, and then address the cross-user
stuff. (Yes, that might mean a partial redesign later, but I think some
real code to play with will help crystalize our thinking).
> What do you think?
>
> -dan
>
Craig
>
> -----Original Message-----
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED].
> org]On Behalf Of Craig R. McClanahan
> Sent: Saturday, August 11, 2001 4:37 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Workflow Support Proposal
>
>
>
>
> On Sat, 11 Aug 2001, Michael Rimov wrote:
>
> > Craig:
> >
> > I read through your proposal. [Which I liked very much] Forgive me if
> I'm
> > just missing it, but can the workflow support multiple users at any
given
> > particular time? What I mean is this:
> >
>
> In other words, multiple users that participate in the *same* workflow
> instance? Yah, I didn't really address that one. I was focused on the
> individual user interaction - but the multiple-user case is very
important
> as well.
>
> > App Flow:
> >
> > -User A Performs Step 1
> > -User A Performs Step 2
> > -Application Mails User B URL to Step 3 (For example, a content
approval
> > message)
> > -User B Clicks on URL to Step 3
> > User B Performs Step 3
> >
> > etc...
> >
> > Now obviously, the mailing mechanism would have to be my own logic, but
> > would the workflow cover the whole process with different users
performing
> > different steps or would you have to have a separate workflow for each
> user?
> >
>
> In terms of the initial workflow proposal, it could be two individual
> workflows that are coordinated (and, at the detail level, this seems
> necessary anyway -- content approval, for example, could be a multi-step
> process in and of itself).
>
> There's also an interesting aspect of this - it is somewhat more
> asynchronous, because you don't really want person A to be locked out of
> doing anything else until person B is finished.
>
> > If so, do you see any way that something like this could be integrated
> into
> > the workflow engine?
> >
>
> I think this is a very useful concept to consider adding. It might take
a
> level of abstraction above the current "Workflow" component to represent
> it. There would also need to be a more formalized way to retrieve the
> current state of a particular flow instance that is in progress (for the
> web application single user case, you'd just store the Context object in
> the session).
>
> Now to figure out how to integrate it ...
>
> > Thanks in advance,
> > -Mike
> >
> >
>
> Craig
>
>
>
