We have also explored such idea, although this was just a discussion in our
team. We however have also concluded that the notion of workflow, or
"contexts" in our terms, is strongly related to the notion of command token
already discussed in this user list in Dec. 2000, and therefore both should
be looked into at the same time.
Indeed, a workflow very often relates to form submissions, sometimes several
forms across multiple pages. In those cases, a better management of the data
associated to the workflow is needed, so that the session context can be
cleaned up correctly. And wherever forms are submitted, transaction
integrity is also required. And in both cases, tokens are required to handle
them.
This has suggested me the notion of contexts, some being standards (request,
session, etc.), others being custom defined (like your notion of workflow).
Each context type would carry different behavior in terms of:
- how many context of this type can be started during a session
- how many context of this type can run concurrently in a session
- whether going through the starting point of a context will create a new
instance of a context, reuse an existing one, etc.
- critical section handling (useful for form submission and transaction
processing)
- etc.
We haven't given any further thoughts than this, and certainly not in terms
of implementation. But the need has been identified and put in a list of
things to look into someday.
I'd be curious to know whether anybody else agrees with this idea of joining
together into the same concept of custom contexts, things like : workflow,
sensitive forms, and transaction integrity.
François Rey
Financial WebSuite
Capco
http://www.capco.com/
-----Original Message-----
From: TKV Tyler VanGorder [mailto:[EMAIL PROTECTED]]
Sent: 11 May 2001 02:07
To: [EMAIL PROTECTED]
Subject: Adding a new "workflow" scope type
I have seen this asked a couple of times on the strut users mailing list.
The problem this new "workflow" scope is meant to address is as follows:
When a browser client establishes a session with the servlet engine,
there is nothing stopping the user from opening up more than one browser
window during that session. This means that any data stored in the
session scope will be shared by both windows. A user can proceed through
an instance of the same workflow in each of their browser windows and there
is no way of distinguishing which data belongs to each instance. The
"request"
scope doesn't solve this problem if a workflow spans more than one browser
request.
Thus a new scope type: "workflow"
A workflow is started by a particular action mapping and a token
is generated to identify the workflow context. That ID is set on
an attribute of the request.
The workflow context is passed along by encoding the additional
workflow context ID into any URL that is embedded in the JSPs.
So, encoding a standard URL now goes through two layers....
- First we grab the workflow context ID from the request attributes.
- We encode the workflow context ID into our URL.
- Finally, we encode the new URL with the servlet's session ID.
You then modify the ActionServlet, so that when it gets a
request, it can parse out the workflow ID out of the encoded URL and
place it back into the request object.
Objects that are in "workflow" scope are stored in the user's session
using the workflow context ID as the key. The value of that entry is
another hashmap that allows arbitrary key/object mappings.
Finally, you identify a particular action as ending a workflow. The
action servlet parses our the workflow ID from the URL, does NOT put
that into the request object and removes all the data for that
workflow from the user's session.
Any comments on this?
Thanks
Tyler Van Gorder
[EMAIL PROTECTED]
Landacorp.
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
