commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [workflow] comparing web based and message based (was Re: Workflow)
Date Wed, 14 Nov 2001 16:54:45 GMT

On Wed, 14 Nov 2001, James Strachan wrote:

> Date: Wed, 14 Nov 2001 10:50:41 -0000
> From: James Strachan <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: [workflow] comparing web based and message based (was Re:
>     Workflow)
> Hi Colin
> Just a few thoughts about using the Workflow project with JMS.
> I think there are close parallels between a web application receiving HTTP
> GET/POST requests with a body, headers & parameters and with a web
> application receiving JMS messages with a body, header & properties. Its one
> of the main reasons why the Messagelet Engine came into being in the
> Messenger project.
> However the current Workflow project looks like its first focus is a typical
> web application scenario, where there is a single web application JVM, using
> HTTP Sessions, performing *all* the steps. As each HTTP request is received
> the HTTP Session can be used to share information across related requests.
> In a typical JMS / MOM based workflow system, each step is often a totally
> seperate process - or even a totally seperate cluster of processes, maybe
> even implemented with different technologies.

Web is *one* of the environments for which Workflow is designed, but it is
by no means the only one.  The key is that you can implement your own
Scope classes, which map variables (as seen by the workflow) to anything
you want.  If you use the web abstractions in
org.apache.commons.workflow.web, the scopes are mapped to the servlet
spec's concept of scopes (although you can still define some additional
ones if you want).  If you use just the base context (o.a.c.w.base), you
can implement Scope (or subclass BaseScope) to connect to anything you

For JMS, you could implement the Scope operations as access to your
remote processes through whatever technology is appropriate.

> This is similar to having a web-application workflow where steps can be
> processed in totally different web applications (and possibly server farms)
> and so session information gets lost across steps. I know of a few companies
> who are starting to vertically align their web applications based on
> business function so can imagine workflows across web applications and
> server farms being useful to some folks.
> I wonder how important is the HTTP Session state in the current workflow
> project - I guess its kinda crucial? Or can it work in a relatively
> HttpSession-less way by keeping all the state in the <form>s as hidden
> fields or using a database?

Where you keep state in a web environment (request versus session) is
always an issue, whether you're using workflow or not.  In fact, the
Workflow implementation should operate correctly even in the absence of
sessions, although there's probably some cases where it will throw an NPE
instead of something more useful.

> For MOM-based workflow we'll either need to ensure all state is sent with
> the message or that we use some other distributed state mechanism, like
> databases, so each step can persist its state for further steps to use.
> I guess many of these issues are common to both web applications (when using
> server farms and multiple web apps) and for JMS based workflows.

There is a restriction in the servlet spec that makes this somewhat
simpler to write applications for -- in a distributable app, all requests
for a single session at any single point in time have to be handled on the
same server.  In effect, you can only migrate sessions (for load balancing
or failover) "in between" requests.

Given this, the application programming model should not have to pay a
whole lot of attention to which server its running on.  (Of course, you
have to also obey the restrictions on Serializable session attributes, but
beyond that the application's view is very similar to a non-distributed

> Thoughts?
> James


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message