Could you suggest a pattern which would most closely match the requirements for the typical workflow application?
When I think of workflow I think of a uber-dispatcher who assigns work based on a)capabilities of the resource b)availability of the resource c)priority of product/service Any thoughts/ideas to implement a viable Architecture would be greatly appreciated Thanks Martin ----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <user@struts.apache.org> Sent: Friday, April 04, 2008 6:14 AM Subject: [OT] What do you code today? > While outward facing web application get the most publicity, I know > that most of us are heads-down on internally-facing applications > designed for fellow employees to use over the corporate intranet. > > I'm trying to put together a list of the typical types of applications > that enterprise developer write in real life. For example, my last > project involved a system to track drafting, granting, monitoring, and > enforcing water permits administered by a government agency. We would > create an initial record for a permit, and then add child records to > track progress through the workflow, and also update the master record > along the way. For management, a key item here is a tracking report, > which we exported to Word (using a third-party tool) for better > formatting. For engineers, a key item was a flexible search system to > quickly find a master or child record. Other interesting features are > workflows where one task leads to another. When we completed one task > (child record), the next is often implied, and so we had a workflow > that would default the next task to work on when a current task was > closed. Another interesting requirement was that sometimes master > items were merged under another uber-master-item, becoming, in effect, > child items themselves. In most cases, the application simply exposed > business models that we designed into the database, so the application > has little business logic of its own. Most of the workflows were > designed to find, list, edit, or view one database entity or the > other. > > So, if anyone else is up for sharing, I'd be interested in hearing > what sort of things other people are doing these days. (If your not > comfortable posting the list, feel free to mail me direct.) > > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
