"Craig R. McClanahan" wrote:

> 
> One fairly radical idea I've considered is to not use events for this
> purpose, but to treat the basic processing that the controller servlet
> itself does as a workflow that can be scripted.  That way, you could (in
> effect) insert your own "processXxxx" type functions anyplace you like in
> the standard workflow.  Presumably, the scripting language for the
> workflow would have mechanisms to support conditional processing to deal
> with my question above.
> 
> Craig

Very interesting.  I don't have much background with workflows,
but what you describe sounds like a high level scripting
language that could be invoked from the servlet or any class,
possibly coded in XML.  Each Struts extension could add script
fragments to particular workflows.  The script fragments could
express things like conditionals, calling methods on objects, and
would be able to do things like discontinue the current workflow.
As you point out, doing things like changing the flow of execution
(e.g. taking user to login) are difficult and/or messy using
an event/listener mechanism.

When you mention treating the basic processing of the servlet as a
workflow, what level are you talking about?  Would a substantial
amount of the servlet processing be coded as a workflow (e.g.
replace existing servlet java code with workflow script) or would
most of the servlet java code remain, and the servlet would just look up
and
invoke workflows at particular points in processing (like
validation, request processing, forwarding, etc...).

I took a look at IBM's bean scripting framework and bean markup
language (BML) thinking they might be something that could be
leveraged.  They sounded promising but unfortunately it looks
like BML isn't open source.

An opbervation:
This seems to be on a different level than the other
Workflows discussion that's going on.  This sounds to me like
internal servlet workflows, while the other workflows are
more geared towards interactions between the end user and
the overall web application (e.g. user must go through
credit card entry screen before finally submitting order).

--Ron S

Reply via email to