I am working on a project to develop a Turbine-based workflow engine for file processing, using the Commons Workflow package and I would be interested in any feedback or suggestions as to how best to implement this. The main focus of the project is to automate file processing for print/publishing workflow. Users move/copy files into predefined "hotfolders" which trigger a series of workflow steps such as converting a file from PostScript to PDF, compressing images or transferring a file or directory to a remote server (via FTP, HTTP, WebDAV, etc...). Currently I have created a WorkflowService, modelled after the Turbine SchedulerService that retrieves items from a queue and initiates the processing sequence. A scheduled job periodically retrieves the list of hotfolders (from storage; they are implemented as OM/Peers), checks for any new files and submits them to the workflow queue, along with a reference to an Activity definition that will be used to process the files. My intention is that as each entry is retrieved from the queue the associated Activity definition file is 'digested' and a processing thread started to perform the workflow steps. I also need to ensure there is a mechanism for maintaining state/progress information for each workflow step -- both to report back to the client UI and for 'recovery' should a process be interrupted. Workflow steps may be quite expensive and/or time consuming -- for instance, PDF conversion of large publishing files typically takes 1-5 minutes, thus processing a directory of files could take significantly longer. During this period a user needs to see progress information such as a progress bar or estimated time to completion. I am unclear at this stage as to how the workflow Context and Scope fit in. I figure the processing thread itself should probably be a Context implementation and maybe the Scope implementation is the conduit to the UI? A Velocity Screen/Action could request a list of processing threads/Contexts from the WorkflowService and insert each Scope implementation into the Velocity Context? The Scope would probably also need to be backed by an OM/Peer to persist state information. I would appreciate any suggestions or alternative design ideas. Thanks, Brett
-- Brett Gullan [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
