commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [workflow] comparing web based and message based (was Re: Workflow)
Date Wed, 14 Nov 2001 18:10:47 GMT
From: "Craig R. McClanahan" <>
> 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
> > GET/POST requests with a body, headers & parameters and with a web
> > application receiving JMS messages with a body, header & properties. Its
> > 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
> > web application scenario, where there is a single web application JVM,
> > HTTP Sessions, performing *all* the steps. As each HTTP request is
> > the HTTP Session can be used to share information across related
> > In a typical JMS / MOM based workflow system, each step is often a
> > seperate process - or even a totally seperate cluster of processes,
> > 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.

Great - more than anything else I just wanted to check that trying to use
Workflow with JMS wasn't trying to fit square pegs into round holes.

> 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
> want.
> 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
> > and so session information gets lost across steps. I know of a few
> > 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.

It'd be nice to be able to have an alternative to using HttpSessions in
Workflow - say using a database, JDO, EJB or whatever to store the state of
a Scope.

> > For MOM-based workflow we'll either need to ensure all state is sent
> > 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
> > 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.

Agreed. The problem comes when seperate requests for the same HttpSession go
to different JVMs in a server farm - there is usually a small window between
requests that the HttpSession state might not have migrated yet - assuming
the servlet engine you're using has a reliable session-replication

> 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
> environment.)

Agreed. Though I've also experienced multiple concurrent requests for the
same HttpSession before in the past - caused by a browser with several
windows open doing seperate requests - I can't remember off the top of my
head if it was Netscape or IE.


Do You Yahoo!?
Get your free address at

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

View raw message