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