Workflow Automation and Management Services in Web 2.0: An Object-Based Approach to Distributed Workflow Enactment

Peter Y. Wu
wu@rmu.edu
Department of Computer & Information Systems
Robert Morris University
Pittsburgh, PA 15108, U.S.A.

Abstract
Workflow is the automation of business processes in the computer information system.   While it started as an attempt to coordinate transaction based tasks around the monolithic database system, workflow automation has evolved into the orchestrating of concurrent tasks and asynchronous events for distributed application services in today’s distributed computer networks.  The paper very briefly reviews the research work in the development, and outlines an object-oriented approach to workflow automation.  It describes the architectural design built on the central idea of the workflow object which encapsulates relevant information items along with business protocol definition in one unit.  The workflow object serves to coordinate communication between collaborating agents in the network, for the enactment of the workflow, while the agents serve to perform the tasks involved in the business process.   With the agents and their services registered at a workflow server, workflow enactment becomes a service offered by the workflow server.  An interesting design feature is in the integrated workflow management system which incorporates a workflow definition tool to support the creation, customization and verification of new workflow configurations.  With the internet in Web 2.0 becoming a network of distributed services available for discovery and application, the workflow definition tool can provide a service at the end-user level to design and submit their own workflows, offering a new level of flexibility workflow service delivery. 
Keywords: workflow automation, workflow object, workflow server, workflow definition tool, distributed workflow enactment


1. INTRODUCTION
Workflow is the automation of business processes. Since the proliferation of computer information systems, the promise of doing business efficiently has always been conceivable (Gates, 2000) but never quite realized.  Modern database management systems today have certainly made efficient data processing a reality.  Effective coordination of business tasks to achieve workflow automation is still hardly versatile enough.  Workflow automation started with coordinating the transaction based tasks around the database management system. Yet in the networked environment of modern distributed computer systems today, it has evolved into the conducting of an orchestra of asynchronous tasks in the enactment of business processes.
In this paper, we briefly reviewed the history of this development of workflow automation.  We then present the draft architecture of a workflow automation system focused of the design of a workflow object which encapsulates the relevant information items along with knowledge of the business protocol.  The enactment of the business process is then carried out in a workflow server started with the creation of the workflow object.  While the workflow object is alive in the workflow server, it coordinates the communication between various agents in the network for perform tasks accordingly for the completion of the business process (Wu, 2004).
Workflow is therefore started by filling out a workflow template with data, and submitting it to a workflow server, thus creating the workflow object.  In this paper, we also go on to describe the design of a workflow definition tool, to be incorporated into the workflow system.  The definition tool supports the design and verification of workflow templates.   By offering the use of the workflow definition tool as a service to the end-user, we have an integrated workflow management system which is not only for workflow automation, but supports the dynamic customization by end-users in the design and initiation of workflows in the network.
With Web 2.0 in the internet, agents and the services they offer are registered and can be discovered in real time.  Our integrated workflow management system is poised to support business automation on the internet: both workflow design and enactment are services offered by the system.
2. WORKFLOW: A BRIEF REVIEW
In the 1980’s, with database technologies maturing, workflow automation was built upon the database management system. The business processes to be automated involves transaction-based tasks coordinated in concurrent collaboration while preserving information integrity in the database systems.
Workflow automation primarily deals with the coordination of transaction-based tasks knowledge workers must perform around the database system, following the appropriate business rules. The approach is known as the transactional model of workflow automation (Marinescu, 2002). In the early 1990’s, with network-based systems becoming commonplace, workflow dealt with the management of collaborative work for business processes in the computer network.  Research effort began to extend the transactional model: there might be long-lasting transactions in a workflow (Dayal, 1990). Relatively few addressed the issue of customization for protocol changes (Gangopadhyay, 1993). Instead of coordinating tasks around the database system, workflow is then concerned more about the distributed application in the network (Casati, 1995;  Proper, 1995
   ; Alonzo, 1997).
Toward the late 1990’s, the concern on workflow automation began to focus on the robustness and flexibility of workflow in a distributed system (Alonzo, 1997;  Borgida, 1999; Allen, 2001), as well as issues and situations when workflow moves beyond the organizational boundaries (Aalst, 1999).  It is also called the network-based model of workflow automation (Marinescu, 2002).
In the past decade of the new century, the distributed systems built on the internet made much advances. On the one hand, middleware also became more established for the operating platform in Web 2.0 to support service discovery and application, more flexible workflow systems began to emerge (Aalst 2002; Altintas, 2004;  Brown, 2005; Simmhan, 2008).  These systems are aimed mostly at re-configurable workflow design for scientific applications.
3. WORKFLOW SERVICE
Our approach aims at a more flexible application delivery for business workflows. Business workflow automation focuses on the execution of a business process involving multiple parties in the networked environment.  The parties involved may be transaction based tasks which take care of data processing, or knowledge workers who need to make decisions or acknowledge notification in the business process. In either case, they are represented by agents in the network environment offering services.   In order to coordinate the action of the agents, we gather together all the relevant information items for the business process, along with knowledge of the business protocol, into one encapsulated unit.  We call it the workflow object.  Managed by the workflow server for the enactment of the workflow, the workflow object, once instantiated and initiated to become alive in the workflow server, it communicates with the agents involved in the business process to request for services.  By following the prescribed protocol, the workflow object coordinates the actions of the agents to accomplish the business process.  Figure 1 illustrates the communication between the workflow object and an agent in the network.
The workflow object consists of two parts: the data part which comprises the relevant information items for the business process, and the behavior part which keeps the protocol knowledge.   In general, it sends a request for service to an agent and waits for the completion of the requested service.  These agents work on behalf of the parties involved in the business process.  By following the prescribed protocol, the workflow object serves to coordinate the tasks performed by the agents, and it lives on until the workflow is completed.  Workflow automation is thus a service offered by the workflow server.
It is noteworthy that there are various ways to capture protocol knowledge into the behavior part of the workflow object.  Some common approaches include: rule-based system (Meng, 2000), Petri-Net (Salimifard 2001), or a state chart model (Harel, 1987).  While it remains an open research question, we have chosen the state chart model for its simplicity in implementation.
4. WORKFLOW CREATION
How do we create the workflow?  The workflow is created upon the instantiation and the initialization of the workflow object in the workflow server.  Without data for instantiation, the workflow object is a template – a “class” facility for the creation of workflow objects. To submit a workflow, the end-user fills out such a workflow template with actual data, and submits to a workflow server.   Upon the workflow submission request, the workflow server creates the workflow object and gives it the initialization event.  The workflow object then becomes alive until the completion of the workflow.  Figure 2 below show the use of the state chart model in the behavior part of the workflow object: the protocol is there modeled in a state diagram, as depicted.
Workflow design for our system therefore deals with the creation, modification, and validation of these workflow templates. A workflow definition tool can be integrated seamlessly into the system. The workflow definition tool maintains a repository of workflow templates to support creation, editing, and testing for validation. Workflow servers only share access to the repository to serve the workflow submission request. Furthermore, protocol changes can be made using the definition tool without taking the system down.  Workflows initiated subsequently to use the new template will observe the revised protocol while existing workflows started before the change follow the old protocol till its termination.  There is no need for re-programming as long as the agents support the individual tasks to be performed for the workflow.
5. AN INTEGRATED SYSTEM
Figure 3 in the appendix depicts the architecture of the integrated workflow management system. 
Multiple instances of the workflow server can be distributed over the network, customized for the specific workload with the performance requirements on demand.  Each workflow server must have its own recoverable store to maintain the workflow status to be failsafe.  Each workflow object is managed by a workflow server, generally the one which served the request for workflow initiation.  Throughout the lifetime of each workflow object, supported by the workflow server, it communicates with agents on the network.  The agents served on behalf of the various parties involved in the workflows, and they must be registered to a directory service accessible to the workflow servers.
The workflow definition tool is integrated to the system, sharing the repository for workflow templates with the workflow servers.  The end-user can make use of a workflow template by filling it out with actual data, and submitting it to a workflow server.  The workflow object will then be instantiated and initialized.  Created in the workflow server, the workflow object will live on to monitor the successful completion of the workflow.
A much more interesting feature offered by the workflow definition is the ability to design, customize, and verify the workflow, editing the workflow template as desired.  This is then another service offered by the integrated workflow management system.
6. CONCLUSION
We briefly reviewed the development history of workflow automation.  It has evolved from that of coordinating tasks around the database management systems into orchestrating asynchronous tasks in a networked environment for the enactment of workflows.  We presented our design of the workflow automation system built upon the central idea of the workflow object, which encapsulates protocol knowledge of the business process, and the relevant information items in one unit. The business procedure is realized in the workflow template: by filling out the template with actual data and submitting it to a workflow server, the workflow object is then instantiated.  Alive in the workflow server, the workflow object will be able to follow the prescribed protocol for the enactment of the workflow, coordinating the necessary communication between the various the parties involved in the business process.   The interesting extension of the design is the incorporation of a workflow definition tool, designed for the design, verification, and customization of workflow templates.   With the use of the workflow definition tool, the integrated workflow system effectively manages not only the automated enactment of workflows, but also offers end-user customization of workflow templates.  With the service oriented architecture of the internet in Web 2.0, the integrated workflow management system can make use of the registered agents and their services since these can be discovered and applied in real time.
7. REFERENCES
Aalst van der, Wil (1999) “Interorganizational workflows: an approach based on message sequence charts and Petri-Nets.” System Analysis, Modeling, and Simulation, Vol.34, No.3, pp.335-367.
Aalst van der, Wil and Kees van Hee (2002) Workflow Management: models, methods, and systems.  MIT Press, Cambridge MA, USA.
Allen, Rob (2001) “Workflow: an introduction.” The Workflow Handbook 2001, Layna Fischer (ed), Workflow Management Coalition.
Alonzo, et al. (1997) Functionality and limitations of current workflow management systems, Technical Report, Almaden Research Center, IBM Research Division, San Jose CA, USA.
Altintas, Ilkay., C. Berkeley, E. Jaeger, M. Jones, B. Ludascher, S. Mock (2004) “Kepler: An Extensible System for Design and Execution of Scientific Workflows,” available on the web: http://users.sdsc.edu/~ludaesch/Paper/ssdbm04-kepler.pdf
Borgida, A. and T. Murata (1999) “Tolerating exceptions in workflows: a unified framework for data and processes.”  Proceedings of Int. Joint Conference on Work Activities, Coordination and Collaboration, ACM Press, New York, USA, pp.59-68.
Brown, Jeffrey L. et al. (2005) “GridNexus: A Grid Services Scientific Workflow System,” International Journal of Computer & Information Science, Vol.6, No.2, June 2005.
Casati, et al. (1995) “Conceptual modeling of workflows,” Lecture notes in Computer Science 1021, Springer-Verlag, pp.341-355.
Dayal, et al. (1990) “Organizing long running activities with triggers and transactions,” ACM SigMod Record, Vol.19, No.2, pp.204-214.
Gangopadhyay, Dipayan and Peter Y. Wu, (1993) “An object-based approach to medical process automation.”  Proceedings of the 17th Annual Symposium on Computer Applications in Medical Care. Washington DC, USA, published by McGraw Hill, pp. 501-511.
Gates, William H. III. (2000) Business @ the Speed of Thought: Using a Digital Nervous System, Warner Books Inc., New York.
Harel, David (1987) “Statechart: a visual formalism for complex systems.”  Science of Computer Programming, Vol.8, No.3, pp.231-274.
Marinescu, Dan C. (2002) Internet-based workflow management, John Wiley & Sons, New York, USA.
Meng, Jie, Sumi Helal and Stanley Su (2000) “An ad-hoc workflow system architecture based on mobile agents and rule-based processing.”  Proceedings of the 2000 International Conference of Artificial Intelligence, Las Vegas, June 2000.
Proper and Weide (1995) “A general theory for the evolution of application models.” IEEE transactions on knowledge and data engineering, Vol.7, No.6, pp.984-996.
Salimifard, Khodakaram and Mark Wright (2001) “Petri-Net Based Modelling of Workflow Systems: An Overview.” European Journal of Operations Research, Vol.134 (2001), pp.664-676.
Simmhan, Yogesh L., B. Plale, D. Gannon. (2008) “Karma2: Provenance Management for Data-Driven Workflows,” International Journal of Web Services Research, Vol.5, Issue 2, pp.1-22.
Wu, Peter Y. (2004) “An Object-Oriented System for Distributed Workflow Automation.”  Proceedings of the IADIS e-Society Conference, July 2004, Avila, Spain, Vol. II, pp.1037-1040.




Appendix