Two features of this dynamic workflow system make it suitable for the use of quasi-intelligent agents: (a) workflow processes need not be fully specified, and so can be non-prescriptive in approach, and (b) a job can be modified independently of the process of which it is an instance, and so some participants may have permissions to change its course. In the architecture that has been chosen for the research, web clients are used, and web agents generate suggestions based on analysis of the process itself, the current job, and the records of previous jobs.
In today's Internet-enabled society, many applications that would normally have been restricted to only being available within an organisation are now online, and can span not only companies and organisations, but also national boundaries, to be become truly location-independent. Workflow systems, where participants in a workflow process may not be contained solely within one organisation and/or location, are prime examples of applications that can take advantage of this new ubiquity in computer connectivity. The Internet, and consequently, the World Wide Web as its most user-friendly incarnation, is an obvious arena in which workflow systems should become established.
The term dynamic workflow means that the elements defined in a workflow process are not defined rigidly, and can be changed or altered to reflect the way that instances of the workflow process are actually run. The workflow process is dynamic — although elements in it are defined, they can be changed when a job is run for the process. Elements can be edited for individual jobs, and exception conditions handled. A logical extension of this model is to allow process definitions to evolve based on what is actually being done in jobs for the process, when users make changes in the jobs to the definitions initially supplied from the process. This leads to the idea of automatically suggesting changes to a process definition in a process review phase, based on analysis of the jobs that have been run for the process.
The basic architecture for the prototype system is that of a workflow database accessed via various programming interfaces, and web-based user clients, other client applications and standalone agent clients manipulating the database contents through the defined interfaces. The client applications allow the creation of processes, the instantiation of jobs from the processes, and running of these jobs. The agent applications generate suggestions in the database.
In the dynamic workflow system prototype, the server side scripting language php is used to generate dynamic content from the database for producing the standard web pages in the system [3]. php provides a simple scripting language that can be embedded in specialised tags in html documents. When a user requests such a document, the document is parsed by the php interpreter prior to sending it back to the web client, and the embedded scripts can generate the dynamic portions of the document at this point. The main reasons this language was chosen is that the scripting language is fast, simple, and it is easily interfaced to a large number of SQL database systems. The initial implementation was attempted using Perl as the language to generate the dynamic content as a standard CGI application [4], but php proved to have a large performance advantage in generating the dynamic content, especially when used as a module for the Apache web server [2]. It was also a lot simpler for making changes to the web pages in the user interface. However, certain portions of the web interface, namely the workflow calculation, were retained as Perl CGI scripts, since the activity rules were specified in Perl.
Since the prototype workflow system was built as a web application, the user interface to the system is a web browser, and the server parts of the system, including the database, were interfaced through the web server. The other client parts of the system (i.e. the suggestion generator agents) were implemented on the server platform for the sake of simplicity, although this is an implementation decision, rather than a restriction in the system architecture. The suggestion generator agents and other utility programs were written in Perl, and this language proved to be fast and flexible for producing such ad hoc applications.
The workflow client applications all use a basic workflow interface, implemented as a set of common client modules for communication, connection management, and workflow services. There is a similar set of components for the workflow agents.
The interfaces defined between the various components of the workflow system need careful consideration. The Workflow Management Coalition (WfMC) [6] have designed a model for workflow systems that splits the interfaces into five different categories:
•
Process Definition Tool Interface
•
Workflow Client Application Interface
•
Invoked Applications Interface
•
Workflow Interoperability between two different Workflow Enactment Services
•
Administration and Monitoring
Both the web server and the database server were run as a test system for the prototype on a PC running the Linux operating system [5], using the Apache web server [2]. The server elements of the prototype are portable, and should run on most modern Unix systems.
