Dan,
Thanks for the reply. I didn't realize that there was some initial code in
Commons so I'll definitely check it out.
And I agree with you whole-heartedly regarding the XML scripting and
messaging. Our current architecture is heavily database-driven primarily
because our VP of Tech. as well are others are pretty "data-centric". But
then again, they came out of Oracle so it shouldn't be a surprise. At least
I've finally got them away from huge, hideous ASP pages to a Java platform.
:)
In regards to Motes and Exchange/CDO, I took a quick look at them but do you
think their workflow approach is good enough to merit spending some time
"under the hood" to figure out how they do things?
Thanks,
Alex
-----Original Message-----
From: Dan Connelly [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 7:32 PM
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.
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.
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.)
Stay tuned.
Dan Connelly
----- 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
>
