From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > > On Wed, 14 Nov 2001, James Strachan wrote: > > > Date: Wed, 14 Nov 2001 10:50:41 -0000 > > From: James Strachan <[EMAIL PROTECTED]> > > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > 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. > 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. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
