INET Conferences

Conferences

INET


NDSS

Other Conferences

[INET'98] [ Up ][Prev][Next]

An Internet FlowBot Protocol

Ee-Ming TOH <eeming@irdu.nus.edu.sg>
Derek Beng-Kee KIONG <dkiong@iscs.nus.edu.sg>
National University of Singapore
Singapore

Abstract

As the idea of virtual organization across the Internet gains acceptance, the need to standardize a protocol for collaborative workflow among organizations across the Internet becomes evident. To achieve interoperability between workflow products, a standardized protocol is necessary. Although e-mail already has a standard protocol and e-mail-enabled workflow can be easily implemented, such as for form-based routing and approvals, it is not always suited for large transaction-based workflow, which requires highly customized applications. With the advent of multimedia and complex data types, which may contain images, sound/audio, databases, spreadsheet, video, etc., we can no longer rely on ad-hoc e-mail-based collaborative work. We need a protocol that can handle and integrate all complex data types, make complex routing decisions, and perform reliable data delivery.

This paper discusses the flowbot protocol, which we use as a generic workflow protocol to help us deliver our data and make routing decisions. Each flowbot contains both information and process knowledge, allowing each flowbot to operate independently from one another. This also means that each instance of workflow can follow a separate route through a business process. By the same token, each flowbot can be modified while in process without affecting other flowbots in process. Tracking progress in a workflow is also important. We do this simply by sending a tracking flowbot to check the progress of the targeted flowbot.

The flowbot protocol framework goes beyond a simple rule-based approach to provide methods of exception processing. A complex business process sometimes cannot be analyzed due to the difficulty of collecting all the rules that govern dynamic business processes. We train each flowbot by feedback to recognize each new path. Hence it is intelligent enough to make a routing decision in case of exception. Here the flowbot never dies after each process. Instead, it goes into sleep mode together with its newly acquired process knowledge, which might be critical in the next instance.

With this framework, different workflow products can inter-operate using a different user interface, a different server, and different tools for creating workflow and monitoring of processes.

Contents

Introduction

There has been a lot of research and development in the area of Workflow, and we see a lot of exciting and promising Workflow programs emerging from the market. Most of these developers are either using e-mail or non-standard propriety protocol to implement Workflow programs. Although some offer very promising technology, the sad fact is that none of these programs can inter-operate. If inter-operability among Workflow products can be achieved, we will see greater proliferation in the use of Internet technology by businesses and organizations. Consider the scenario whereby an organization's Workflow can be part of another organization's; a lot of time and effort will be saved as a result of this. But before we go into the design of such a protocol, we need to know what Workflow is and why we need to design a new protocol instead of using the existing HTTP and SMTP protocols.

Workflow defined -- what is workflow?

Workflow or computer-supported collaborative work processing (CSCWP) is a toolset for the proactive analysis, compression, and automation of information-based tasks and activities. The basic premise of Workflow is that an office environment is an information factory, or more specifically, a process factory. The process, which can range in format from paper to electronic forms, provides the basic raw material of every office task. Workflow attempts to streamline the components of the document factory by eliminating manual tasks, thereby saving time, effort, and costs associated with the performance of these tasks that are necessary to a process.

Workflow and Workgroup computing. A distinction must be made between workflow and workgroup computing, which are always confused with each other. Workgroup computing focuses on the information being processed, enhancing the user's ability to share information within workgroups. Hence, it is an information-centric model. Workflow, on the other hand, emphasizes the importance of the process, which acts as a container for the information. In this way, Workflow combines rules, which govern the tasks performed, and coordinates the transfer of information required to support these tasks. Hence it is a process-centric model.

Some Workflow terminology that is crucial in the designing process:

Routes -- This controls how the documents or data move from computer to computer in a workflow.


Figure 1: Four basic types of workflow routing scenario:

  • Sequential - This follows a linear path from one task to another. One task must be completed before it is routed to the next point.
  • Split - This enables multiple tasks to occur at the same time. Therefore, tasks are split into multiple sub-tasks to be performed concurrently.
  • Join - Previously split sub-tasks could eventually combine at a rendezvous point.
  • Conditional - This is determined by conditions that occur dynamically in the process. The Workflow system must be able to determine the appropriate route based upon the information that is received along the way.

Rules - These are the rules associated with the processing of documents. These rules define the specific processing activities that are involved in routing Workflow documents and working within specific applications.

Roles - The definition of a specific Workflow requires the establishment of roles for all participants. Each participant has established roles which must be defined as part of the Workflow definition. Each participant is described in terms of location, job function, supervisor, and security level. An employee may be an individual participant as well as part of a workgroup. Role definition enables the Workflow system to distribute tasks to the appropriate individuals for completion. It also allows for workload balancing and distribution to the appropriate employee based on skill level.

Processes - A process consists of a series of tasks and rules that must be defined for each process that takes place.

Why a new protocol is needed

We have seen a lot of Workflow programs emerging, which either use ad hoc e-mail systems to simulate Workflow or propriety protocol and implementation that prevents communication between them. Although the e-mail and HTTP have become a standard in providing a huge amount of information online, they are not suited to support full-blown Workflow operation. Although we can use e-mail to view, edit, comment, and reroute documents, it cannot create complex Workflow and certainly does not support the coordinating of documents and deadlines. As such it is called Document-oriented Workflow, where routing information is directly associated with data objects. The process-oriented model works processes as a sequence of steps, i.e., atomic actions where data objects are associated with the steps. This is a crucial distinction; if routing is limited to documents only, the workflow system does not actually support the "flow of work" but is limited to "flow of document" only. E-mail and HTTP protocols do not inherently support such kinds of operations and thus implementing them will prove clumsy and difficult. Thus we need a new protocol or framework to support such an operation. The idea of virtual organizations and organizations inter-operating and exchanging information cannot be fulfilled fully if this problem is left unsolved.

The flowbot

In this paper, we propose a simple Workflow framework using the concept of mobile code. (It can also be thought of as an agent, although we felt that our idea does not fit the idea of an agent, since a flowbot does not communicate with another directly). We call each piece of mobile code a flowbot that moves from computer to computer performing its required tasks. Instead of executing complex transactions with a remote server by messaging over slow communication links, the self-contained flowbot is transferred to the server and completes the transactions locally. Flowbot(s) can be represented as an instance of a workflow. When necessary, it will spawn another flowbot to form a sub-workflow or they will combine themselves in the event of a join route. When idling, it will be queued or put to sleep until another flowbot wakes it up.

The user communicates with the flowbot by means of a client. Each user is given a user profile which describes the user's role and responsibilities. In the event that the flowbot could not find the required users to service its request, it will look through the users' profiles for a suitable candidate. Based on the feedback given, the flowbot will update its routing table and look for a suitable path. Flowbots are transported using a transport protocol called a flowbot transporter. Once the flowbot reaches its destination, it will then be executed by the flowbot run-time environment locally.

In general we can say that the flowbot model offers the following advantages in Workflow modeling: (1) the inherent mobility model offers a more natural way of routing, and (2) every instance of flowbot operates independently from each other, as one such instance could be modified without affecting the other. The remainder of this paper is structured as follows: we discuss our flowbot framework and architecture, the flowbot protocol, followed by learning by feedback, and finally conclusions are drawn.

The flowbot framework

In this section, we will discuss the facilities which allow the flowbots to offer the users complex Workflow and information management.

The architecture


Figure 2: System architecture of the flowbot framework

The basis of the flowbot architecture is the notion of a flowbot server. The flowbot server consists of a transporter module used for transferring flowbots across the network and a flowbot manager. The flowbot manager manages all flowbots existing on that computer. Its tasks include accepting flowbots and creating the runtime environments and supervising their execution. It also handles the state of each flowbot, puts them to sleep when it is waiting for dependent flowbots and spawns off new ones and combines them in the event of a Workflow join.

Note that this architecture does not require permanent network connectivity. We only need network connectivity for transferring flowbots, after which all the data processing is done on the client side since all the process knowledge and data are contained within the flowbot. Therefore it is also more efficient as the processing is done closer to the data, thus eliminating the bottleneck of going through the network. This framework also saves network bandwidth without all the unnecessary remote messages. Data are also filtered according to tasks and users' roles, thus saving on unnecessary data transfer. Another advantage of this approach is that all flowbots operate independently from each other. The same instance of a flowbot might not necessarily travel the same path. As opposed to a server-centric model, in the event that a modification in path or logic is required, all existing instances of Workflow must be completed before starting new ones.

The user interacts with the flowbot through a client. Each user will also have a profile which describes the user's role and responsibilities, etc. The client will provide the necessary tools to create a new flowbot, instantiate existing ones, and track the progress of ongoing flowbots. The client must also have an interface to communicate with the flowbot. The user is able to log out before a Workflow is completed, as a flowbot does not depend on a user's session. This distributed design also saves computer clock cycles on the client's side.

The main purpose of our flowbot framework is to ensure maximum flexibility in implementing the server and the client that used to interact with the flowbot while standardizing the flowbot. This allows different vendors to come out with different and competing servers and clients which can inter-operate using the flowbot.

Flowbot transporter

The flowbot transporter simply handles the transferring and receiving of flowbots. It operates very closely to the workflow manager. All incoming flowbots are sent to the flowbot manager for creating the appropriate run-time environment, and outgoing flowbots are queued and sorted according to destinations and then sent out.

The flowbot run-time environment (FRE)

The flowbot run-time environment is divided into several modules.


Figure 3: Flowbot run-time environment

Flowbot Manager - Flowbots are handled by this module. The flowbot manager controls the execution of the flowbot, managing the spawning of new flowbots, checking for dependency flowbots, waking up suspended flowbots, and sending waiting flowbots to sleep. It controls and coordinates the execution of the following modules.

Virtual Machines - The flowbot operations are written in a scripting language, and thus they need virtual machines in which to run. The virtual machines are forked by the flowbot manager to execute the program.

Access Control - The access control manages the privileges of each flowbot and checks if it is allowed to use the specified services or applications.

Data Manager - The data manager handles the data of each flowbot. Every flowbot data is stored on disk once it arrives in a server. A pointer to the location will then be assigned to the flowbot. When the flowbot is to be transferred, data are then combined with the rest of the flowbot and sent to the transporter to be transported to another machine. In the event of a Workflow join whereby there are different versions of documents or objects, the data manager will also be responsible for recording the differences and similarities.

Queue Manager- The queue manager manages all waiting dependency flowbot. Any flowbot that is idling and waiting for another flowbot is sent to a queue and put to sleep. It will be awaken when another flowbot is requested for it or when it needs to be executed.

Communication Manager - The communication manager manages all communication between the flowbot and application/client.

A flowbot dissected

To support the framework as discussed, the flowbot needs to have the following basic structure. It contains:

Code. The program that defines the operation of the flowbot. This is the "brain" of the flowbot which controls the execution of the flowbot and the communication between itself and the users. It could be implemented using the Java language developed by SUN or even Perl. In our case, the code is written using the FlowScript, a high-level scripting language which is discussed later.

State. The variables that describe the flowbot's stages of processing. This is usually private to the flowbot and can only be modified by the flowbot manager.

Data. The accompanying documents or objects. It could be an HTML form or even a video clip.

Attributes. All the information describing the flowbot and the Workflow may include the following:
Initiator, Routes, Rules, Roles, Dependencies, Priorities, Deadline. They can be modified as and when it is required. Note that attributes need not be a set of pre-defined variables; they can also be user-defined variables that could aid in the Workflow.

FlowScript: A flowbot scripting language

We use a high-level scripting language, FlowScript, to control the flow and behaviors of the flowbot. FlowScript combines the ease and understandability of conventional computer language construction with extremely high level Workflow controls. Although languages such as Java can be used to specify the flowbot behaviors, it is time-consuming and very difficult to program. FlowScript, which is tailored to construct all kinds of workflow, will prove to be a much easier and perhaps even lighter weight alternative. Users can construct extremely complex workflow with sub-workflow easily using FlowScript. To show how easy it is to write FlowScipt for flowbot, consider the following simple scenario which is part of an article submission process in a printing company.

Users submit articles at T1; the article is sent to T2. T2 verifies the identity of the applicant and sends the article to both S1 and T3 for comments. The comments from S1 are then sent to T3 where they are combined and sent to the various editors for editing. The example scripts will be as follows: 

Flowbot ArtEval {
object article;
form author;
text t3_comments;
Home T1:
request(article, author);
Goto T2:
Send(article, author);
New flowbot ArtEval_sub;
Goto T3:
Request(t3_comments);
Join with ArtEval_sub;
If (article) goto C1:
Send(article);
Else if (article) goto C2:
Send(article);
Else goto C3:
Send(article);
}
sub ArtEval_sub {
object article;
text s1_comments;
goto S1:
show(article);
request(s1_comments);
goto T3:
join with ArtEval;
}

The script contains code for multiple flowbots needed in a workflow. Data objects and attributes can be declared and allocated memory space anyway within the code. The "goto" statement simply means to transport itself to the specified server. Any statements appearing underneath and before the next "goto" statement will be the task to be executed at that server. The parent flowbot will be executed first. Whenever it encounters the "new flowbot" keyword, it will take away all codes belonging to the corresponding flowbot and create a new flowbot operating independently from the parent. In the above example, all code under "sub ArtEval_sub" will be the code of the new flowbot. In the event of a "join," the flowbots will be combined. The above example illustrates the powerful concept of mobile code in the area of Workflow systems. The full language specification will not be discussed in this paper.

Learning from feedback

In the case of exception, whereby the flowbot doesn't know where to go next, it will look up the roles of each user and consult them. In the event that roles aren't defined or cannot be found, it will flow back to the previous machine for consultation. This continues until it finds a suitable route or it reaches the initiator. When it has found its route, the flowbot manager will then update its code so that at the next instance, it will know where to go to. This can lead to an improvement in Workflow performance.

Summary and conclusions

Different Workflow programs cannot inter-operate if there is no standardized protocol. And certainly HTTP and e-mail systems cannot fully support the complexity of Workflow. The proposed Flowbot architecture uses mobile code concepts as a framework for the Workflow system. Despite the many stumbling blocks in adopting this kind of framework, our research and experiments have shown that it is so far the best method that can be used to capture all the intrinsics of a workflow.

Acknowledgments

We would like to thank Aaron Aw for coining the term "Flowbot."

References

  • [1] Thomas M. Koulopoulos, The Workflow Imperative, Building Real World Business Solutions, ITP 1995
  • [2] Steinar Carlsen, Conceptual Modeling and Composition of Flexible Workflow Models, 1997
  • [3] The Agent Society, http://www.agent.org
  • [4] Cheong F.C., Internet Agents: Spiders, Wanderers, Brokers, and Bots, New Riders Publishing, 1996
  • [5] Lau E.F., Chua J.C., Toh E.M., Generic Workflow Management System, NUS, 1997
  • [6] IBM, Aglets Workbench, Agent Transfer Protocol ATP/0.1, http://www.trl.ibm.co.jp/aglets

[INET'98] [ Up ][Prev][Next]