A quick status report and some interspersed comments.
I finally had time this evening to post an example of using the Commons
workflow stuff in a web application, but still agnostic to a particular
application framework. Included is a very simple three-page wizard with
the navigation managed by the workflow engine. My thinking is that we
would build Struts specific things on top of this, such as:
* Automatic use of transaction tokens to ensure that the user doesn't
try to execute steps out of order.
* Custom tags to generate the appropriate navigation buttons for things
like "Previous", "Next", and "Finish" in a wizard.
Although not copiously documented, you'll find enough information in the
Javadocs to understand what the provided Step implementations do. And,
since the bean and property accessors are based on the BeanUtils package
that Struts users know and love, you'll find it not so difficult to learn.
See below for additional comments.
On Fri, 14 Sep 2001, Dan Connelly wrote:
> Date: Fri, 14 Sep 2001 22:32:26 -0400
> From: Dan Connelly <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Workflow Management
>
> Alex:
>
> You need to look at the Jakarta Commons Sandbox components to see what is
> going on wiht "our" workflow.
>
> Craig McClanahan is actively developing the Struts-independent part of
> Workflow in that venue.
>
> The Struts-specific workflow has not begun yet, as far as I know. The
> Commons development is a general purpose workflow engine. The Struts
> integration comes later. Also, the Sandbox code is "pre-Proposal." Its
> good code, but very early. Much may change going forward.
>
It's a lot closer to what Struts needs now.
> Craig's insights are, as always, quite excellent. However, the
> implementation has a long way to go, so don't count on using it tomorrow.
>
> The Craig's Commons Workflow is "scripted" workflow, XML as the scripting
> language. He feels that scripts are better "glue" than Java code for the
> composition of existing applications into super-applications.
>
I would make a slight clarification here -- XML is a convenient way of
representing that static content of an Activity, but it's by no means the
only way. In fact, there is nothing intrinsic to the workflow
architecture that *requires* the use of this representation (although I've
tried to make it as easy as possible to use Digester to process the XML if
you like that form).
Applications that host the workflow engine are welcome to construct the
set of Steps associated with an Activity in any manner that they like.
But Dan makes another point as well, which is discussed further below.
> However, in my opinion, there is more to the script approach than just ease
> of programming. The advantage of scripting for workflow is that the script
> (and some context info) can be migrated over a wide network. A central
> database cannot. Database-driven workflow is a bad idea for workflow.
>
> Bacic Messaging servers, like MSFT Exchange and IBM Lotus Note, give you
> workflow of a sort. Adding scripted workflow to this is not new. For
> instance, CDO in Exchange Server. And, now there is BizTalk.
>
> WebApp workflow has failed so far, in my opinion, because there wasn't
> enough Messaging support.. There is resistance to Messaging from the object
> purists who feel that an object can be as mobile as a Message. The battle
> is over the infrastructure.
>
> The more scripting, the more Messaging, or so it seems to me. You must be
> able to migrate seamlessly from the push-world of SMTP to the pull-world of
> HTTP without noticing the transition. We aren't there yet. And Struts is
> only part of the answer. (By the way, NNTP is a nice compromise, but it
> needs to be reinvented.)
I think there are two fairly significant tiers of "workflow" that cause
the word to be overloaded - and, in fact, one could argue pretty strongly
that I haven't yet started implementing workflow in the sense that Dan is
talking about :-).
- "Micro" level workflow is a scripted definition of a particular task,
normally accomplished by a single individual in a fairly short amount
of time. Interaction between the user and the workflow engine happens
synchronously (the user does something, the script does something, and
so on). The Commons workflow engine calls this an "Activity" that is
composed of "Steps".
- "Macro" level workflow is still scripted in some fashion, but normally
involves one or more of the following differences from the micro level:
* Interactions with more than one individual (or application that
is acting on behalf of an individual).
* Asynchronous, sometimes parallel, execution of activities that
comprise the overall workflow.
* Interactions can cross organizational boundaries.
* Interactions can occur in more than one application environment (hence
the need for messaging support of some kind).
* Transactional semantics (it either all succeeds or all fails,
like a database COMMIT or ROLLBACK).
In the workflow proposal, I reserved the term "Process" for this concept,
but haven't really gotten very far in thinking about it. I wanted to
start with solving a need that Struts users have been expressing for a
long time ("how do I create a wizard-type application easily with
Struts?").
After that, we can see if the scripting concepts are scalable to the
larger meaning of workflow or not. If they are, great. If not, well, the
micro level stuff is still pretty useful. For example, the need for a
Java programmer to write Actions (which are supposed to just be glue
between the web tier and the business logic) can be substantially reduced.
> Stay tuned.
+1
> Dan Connelly
Craig
>
>
>
> ----- Original Message -----
> From: "Alex Ross" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, September 14, 2001 10:59 PM
> Subject: Workflow Management
>
>
> > I started working on a Workflow Management system when I recently
> discovered
> > Struts along with its Workflow Proposal and saw *too* many similarities
> for
> > me to plod ahead on my own. :)
> >
> > Our current model is largely database-driven, focusing on the business
> > process / activity level, and I'd like to try to bring it into the Struts
> > framework. Is anyone actively working on the Workflow piece or looking to
> > exchange ideas?
> >
> > Warm Regards,
> > Alex
> >
>
>
