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. 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? 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. Thoughts? 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]>
