Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Wed, 14 Nov 2001 10:17:07 -0800 (PST)
From: "Craig R. McClanahan" <craigmcc@apache.org>
Sender: <craigmcc@localhost>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [workflow] comparing web based and message based (was Re:
 Workflow)
In-Reply-To: <0e6101c16d37$b00e7190$9865fea9@spiritsoft.com>
Message-ID: <20011114100746.P61675-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

See intermixed (quite a ways down).

On Wed, 14 Nov 2001, James Strachan wrote:

> Date: Wed, 14 Nov 2001 18:10:47 -0000
> From: James Strachan <james_strachan@yahoo.co.uk>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: [workflow] comparing web based and message based (was Re:
>     Workflow)
>
> From: "Craig R. McClanahan" <craigmcc@apache.org>
> >
> > On Wed, 14 Nov 2001, James Strachan wrote:
> >
> > > Date: Wed, 14 Nov 2001 10:50:41 -0000
> > > From: James Strachan <james_strachan@yahoo.co.uk>
> > > Reply-To: Jakarta Commons Developers List
> <commons-dev@jakarta.apache.org>
> > > To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> > > 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.
>
>
> 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.
>
> Cool.
>
>
> > > 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.
>
>
> 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
> 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.
>
> 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
> mechanism.
>

If your container allows this (simultaneous requests on the same session
to different JVMs), then it is broken -- it's violating the servlet spec
requirements.  It's up to the container to make sure that the atomicity of
"all requests for the same session at the same time go to the same JVM" is
not violated.

Even Tomcat (running behind Apache) gets this one right -- of course, it
does so by sending *all* requests for a session to the original server and
doesn't do any session migration later.

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

That's real easy to have happen, even in a non-distributed environment.
Most browsers are configured by default to issue multiple simultaneous
requests if it makes sense (and it will make sense if you're using frames
or image URLs in your pages; that's why you sometimes see multiple images
being downloaded at the same time).  If you're using sessions, all of
those requests will be for the same session ID, and they will be processed
by your container simultaneously (on different threads).

The web application developer is *always* responsible for dealing with
multiple simultaneous requests to the same session.  You deal with that by
appropriate "synchronized" locks to prevent problems with your session
attributes.  The reason for the servlet spec restriction on distributed
environments is so that the application developer does not need to figure
out problems like how to synchronize a HashMap across JVMs :-).

>
> James
>

Craig


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>