Distributed Workflow using HTTP: Example using Software Pre ...

Distributed Workflow using HTTP: Example using Software Pre-requirements Arthur S. Hitomi

Peter J. Kammer Gregory Alan Bolcer Richard N. Taylor Department of Information and Computer Science University of California, Irvine Irvine, CA 92697 USA +1 714 824 2704 {ahitomi, pkammer, gbolcer, taylor}@ics.uci.edu

ABSTRACT Frequently process workflows are distributed collections of activities that involve groups of individuals at disparate locations. To coordinate these tasks, a process support system should provide for distributed process execution and integration with tools across networks. We describe the use of the Hypertext Transfer Protocol (HTTP), an increasingly ubiquitous technology, to provide a coordination mechanism for distributed process execution and tool integration. To make the distributed workflow and benefits of HTTP more illustrative, the demonstration will focus on a software pre-requirements process designed for the Applications Development Group of Pacific Bell, a major telecommunications company. This document routing and approval process was developed to support a major requirements engineering activity, where participants interact with applets in a web-browser to submit a document for approval.

Effort sponsored by the Defense Advanced Research Projects Agency, and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-97-2-0021. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright annotation thereon. Disclaimer: The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Defense Advanced Research Projects Agency, Air Force Research Laboratory or the U.S. Government.

Keywords open, distributed process technology, architecture INTRODUCTION Process workflows are frequently distributed collections of activities that involve groups of individuals at disparate locations. To coordinate these tasks, a process support system should provide for distributed process execution and integration with tools across networks. We describe the use of Hypertext Transfer Protocol (HTTP) [1], an increasingly ubiquitous technology, to provide a coordination mechanism for distributed execution of process and tool integration. Building on the Endeavors process support system[2], we can use extensions to an HTTP server to provide support for communication and coordination between system components, as well as integration with external tools. To make the distributed workflow and benefits of HTTP more illustrative, the demonstration will focus on a software pre-requirements process designed for the Applications Development Group of Pacific Bell, a major telecommunications company. This document routing and approval process was developed to support the requirements engineering activity, where participants interact with Java applets in a web-browser to submit a document for approval. The document and associated information are stored on the server while execution passes to other clients whose users also participate in the process. Each user’s actions manipulate the status of the object on the server, via the underlying HTTP interfaces. In summary, this technology is demonstrated by: • • • •

Execution of a process over the Internet Invocation and integration of external tools on the client side and server Low entry barrier using Web-based end-user view Manipulation of processes, at design and runtime of

system which both use the Workflow HTTP server. JavaTrain is a WBL (Web Based Learning) process that reflects an instance where there are multiple participants in the process with different roles. In this process developed for a workstation manufacturer, there are course designers, content providers, students, and course managers. These different roles require distinct visualizations of the underlying process taking place as well as different sub-processes. The sub-process execution and individual viewpoint is provided by the individual clients that the users access the system through, interacting with the single server, via HTTP. Bug Tracking, based on the bug tracking process of a major computer software and hardware company, works with end-users, technical support, “Bug Czars,” developers and other stakeholders. These participants collaborate in the development, testing, release and maintenance phases of the software production lifecycle. Required tools and artifacts (e.g. bug metric reports and forms, reviews, etc.) are generated, tracked, and passed from and to the stakeholders until the bug has been resolved.

Figure 1. Endeavors Architecture

• • • • • •

the process Remote manipulation of activities, artifacts, and resources Remote creation and reuse of object activities, artifacts, and resources Dynamic changing of object fields, methods, and behaviors and late binding of resources Dynamic creation of process interpreters Mechanisms to support Multiple Stakeholders in a project Global status view to identify multiple process instances

The demonstration will execute within a web browser environment with the workflow HTTP server running as a background process on a local or remote workstation. The software pre-requirements process will be the feature process used for the demonstration, although currently we have two other processes, JavaTrain and a bug tracking

DISTRIBUTED WORKFLOW AND ENDEAVORS The Endeavors[2] philosophy is derived directly from the WWW-based model. In a similar manner to an end-user managing the exception when encountering a "page not found" error on the WWW, Endeavors places the burden of errors or inconsistencies initially with the end-user. The end-user then has the option to employ automated or

Figure 2. Single HTTP Workflow server with Endeavors

manual workarounds to the exception or inconsistency. Endeavors, however, differs from ad hoc workflow systems by including a semantically rich process description language [8]. This allows highly structured process modeling and execution capabilities to be integrated into the workflow while not being so constraining that ad hoc work is inhibited.

basic client requirements: 1.

2.

It must make the application developers accessible to the clients (in terms of discussing their needs and developing their ideas). It must formalize the steps leading from a basic "concept" to a formal proposal for development. It must provide enough structure to establish accounting and tracking mechanisms for all process and application artifacts.

3. Endeavors is a layered (see Figure 1) and highly componentized system implemented in Java[4]. Various process fragments, including their data and tools, can be embedded in WWW pages and executed using HTTP. Endeavors is also flexible in its approach. Depending on how the system is customized, the level of data consistency enforcement allows Endeavors to be used to either primarily inform the users, as in an ad hoc system, or automate certain activities, as in a standard workflow system. Similarly, Endeavors’ policies can be customized to enforce the workflow process execution, thereby keeping the data consistent, or as a support infrastructure to Figure 3. ADG Activity Network (top left), Specification Editor (top right), and view of enhance the coordination the Exploratory sub-activity (bottom) capabilities between users by loosening these constraints. DISTRIBUTION AND EXECUTION The distributed workflow is provided at the Foundation ADG benefited from HTTP for several reasons, but most level where Class-MetaClass objects are defined and importantly for its ubiquitous and mature nature in the stored. The System level provides a higher abstraction Internet/Distributed domain. HTTP is also an established layer and is interpreted at the client (see Figure 2). and secured infrastructure within the Pacific Bell organization which made adoption of this workflow much easier. End-users in the field required this capability to OVERVIEW OF APPLICATIONS DEVELOPMENT connect remotely to this process. GROUP Pacific Bell Network Operations has no "process" for developing technical applications. For this reason the ADG or Applications Development Group was created. Its first task is to establish such a process. The application development process must satisfy three

When an end user or client wishes to request a software project, he does so by visiting the ADG homepage where an interpreter creates a process instance. In turn, this interpreter executes the first activity, the Client Page ADG (see Figure 3) within the main ADG network on the client

machine where the required tools for the activity can be invoked. In this example, the ADG process is configured to use a common document editing tool within the organization, Netscape Publisher [5]. ADG decided to use this tool since it was integrated within their default web browser and was the standard configuration in all of the client machines. This selection permits end-users to publish all major document artifacts generated within the process to be viewable through any standard web browser, an important requirement imposed by the clientele. Once the end-user finishes this activity, the interpreter will proceed to the next activity and if necessary, make a transition between end-users. The interpreter recognizes end-user transitions by reading the resource attribute attached to each activity. The interpreter can then notify and suspend itself for the next stakeholder to resume process execution on a different machine. The notification

contacted with this encoded URL, the server can then reinitiate the interpreter to resume the process on the new client machine. Figure 4 displays how a current stakeholder can select to whom to direct the next activity. One of the most important activities of this process is the authorizing or voting process. The document approval dialog is a specialized activity that designates a person or committee to authorize a software development request. This stakeholder is provided with the artifact viewing tools (to view attached artifacts from previous activities), an artifact editor (to generate new artifacts) and an option to accept or terminate the client request. (See Figure 5) The result of this request is then returned to the interpreter, which will then continue to the next activity according to the activity network (See Figure 3). All stakeholder participants in this process can view the

Figure 4. Email Handoff

Figure 5. Approve Activity mechanism can be implemented by using an installed Book and Calendar tool, an integrated Agenda tool (e.g. Endeavors Agenda Tool), or through some other asynchronous mechanisms, preferably one that notifies the user immediately without being too obtrusive. ADG uses an email notification system to send a message from the client or server to the next end-user by generating a URL with a pointer to a HTTP Foundation server that is hosting (and storing) the process objects. Once the HTTP server is

Figure 6. Status Page status of a client’s request through a web page that enables users to find information pertaining to a currently executing or finished process. Through this mechanism, users can not only track one software pre-requirement, but view all pending requirement of the ADG (See Figure 6). Process managers or process programmers can use the Endeavors activity network to load and store the process network remotely.

By leveraging the distributed workflow mechanism, endusers can also fully create, modify, and remove processes. For example, process programmers have the option to change document routing and authorizing parameters through the Network Editor. This tool, like any other tool of this process, could be executed remotely through the web browser (See figure 3). The activity network, artifacts, and resources are also modifiable dynamically at runtime to deal with potential and probable organizational changes and exceptions. CONCLUSION These approaches demonstrate the feasibility of using an extended HTTP server to provide distributed process workflow functionality. These techniques build on Endeavors’ open extensible model to provide a mechanism for integrating with the increasing proliferation of Internet technologies. Our goal is to provide a dynamically configurable system to support a wide range of organizational contexts and tasks. Infrastructure that requires additional cost and effort to acquire and maintain can present a barrier to the adoption of new technologies and approaches. The Endeavors system is designed to alleviate these problems by supporting incremental adoption and automated installation processes. By utilizing extensible HTTP servers to provide a distribution mechanism, Endeavors takes advantage of technology already available and familiar at many locations. We have examined and implemented a number of approaches to this integration and found it to be a practical approach to supporting distributed process participants at minimal additional cost. We believe the approach we have taken can be usefully adopted by others. Our current and future work with Distributed Workflow and HTTP will include security features of HTTP[3], WebDAV[6], and Java signed applets. Through HTTP, Endeavors should also provide the functionality to disconnect and then reconnect to synchronize a process participant’s state with that of others. ACKNOWLEDGMENTS The authors would like to recognize the hard work and effort in the design and implementation of Endeavors by Patrick Young, Peyman Oreizy, Clay Cover, and Ed Kraemer. In addition we would like to acknowledge the members of the C2, Chimera, and WebSoft projects at UCI for their exchange of ideas during the development of this system. Thanks also to Kari Nies for her review of this paper. REFERENCES 1. T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext transfer protocol -- HTTP/1.0. Internet Informational RFC

1945, MIT/LCS, UC Irvine, May 1996. http://www.ics.uci.edu/pub/ietf/http/rfc1945.txt 2. G. A. Bolcer and R. N. Taylor. Endeavors: A process system integration infrastructure. In 4th International Software Process Workshop, pages 76-85, Brighton, U.K., IEEE Computer Society Press, December 1996. 3. R. T. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, and T. Berners-Lee. Hypertext transfer protocol -- HTTP/1.1. RFC 2068, UC Irvine, DEC, MIT/LCS, January 1997. http://www.ics.uci.edu/pub/ietf/http/rfc2068.txt 4. J. Gosling, B. Joy, and G. Steele. The Java Language Specification. Addison-Wesley. August 1996. http://java.sun.com/docs/books/jls/html/ 5. Netscape Communications. Netscape Collabra server 3.0, open discussion server for enterprise collaboration, Datasheet. Netscape Communications Inc., 1997. http://home.netscape.com/comprod/server_central/product/ news/collabra3_data.html 6. E. J. Whitehead. World wide web distributed authoring and versioning (WebDAV): An Introduction. ACM StandardView, 5(1): 3-8, (March 1997). Relevant URLs Endeavors: http://www.ics.uci.edu/pub/endeavors/ HTTP: http://www.ics.uci.edu/pub/ietf/http/ Netscape Collabra: http://home.netscape.com/comprod/server_central/product/ news/ URIs/URLs: http://www.ics.uci.edu/pub/ietf/uri/ WebDAV: http://www.ics.uci.edu/pub/ietf/webdav/