eFlow: A Java-Based Work ow Service G. Robert Malan, Jarir Chaar, Santanu Paul Peter Masters IBM T.J. Watson Research Center Lotus Development Corporation P.O. Box 704 1 Rogers Street Yorktown Heights, NY 10598 Cambridge, MA 02142 frmalan, jarir,
[email protected] [email protected]
1 Introduction In today's enterprise, work ow management technologies help focus on the business processes of an enterprise rather than on the individual functions of the components of such an enterprise. They are used to ensure the reliable and repeatable execution of business processes and to improve the eciency of the enterprise by supporting the de nition, planning, execution, and analysis of such processes. eFlow is a lightweight framework for supporting work ow on the Internet. It allows Web-based work ow processes to inter-operate through the use of the Rainmaker interface [7]. These web-based work ow processes are exported to users in the form of web pages with embedded Java applets. The applets consist of eSuite components including: spreadsheet, word processor, charting, and presentation applets. eFlow uses email as its noti cation mechanism, providing a universal inbox for users. Persistence of both state and application data is provided through the Servlet File System (SFS), a distributed web-based le system. eFlow allows mobile users to access their worklist tasks from any point in the network (intranet or Internet) using only a Java-enabled web browser or a thin client platform such as a Network Computer (NC). As a Java-based application, the implementation as well as the data items are de ned within an object oriented framework. This paper describes the eFlow architecture and illustrates its functionality through the use of an example process: a grant proposal work ow process.
2 RainMaker RainMaker provides an object-oriented framework for distributed asynchronous work ow [7]. The Rainmaker interfaces specify the mechanism for data and control ow through a work ow graph; while a Rainmaker work ow coordinator object acts as a management agent and coordinator for the various components' data and control ows { collecting data from upstream service providers, and routing this data down the work ow graph. Figure 1 shows the relationship between the general components in the Rainmaker work ow model. The work ow coordinator contains the representation of the work ow graph, and tracks the progress of the work ow application. Rainmaker utilizes a custom directory service to map abstract work ow service names to their network resources. These resources take the form of work ow services. These services conform to the RainMaker interface for the interchange of work ow data 1
Workflow Coordinator Workflow Service eFlow Server
Workflow Service eFlow Server
HTTP Server
HTTP Server
User Java Client emailClient
Figure 1: Components of a RainMaker work ow system. and control. It is at these work ow services where work is delegated to either a person or an automated process through the introduction of a task. These tasks are managed by a user's (or process's) worklist server. In this model, the worklist server acts as a queue from which users obtain new work ow tasks. Upon completion, the results of the tasks are returned through the Rainmaker interface to the work ow coordinator object for collection and distribution down the work ow graph.
3 eSuite Lotus has developed the eSuite applets [3] to support a broad range of applications targeted at both universal use through Java-enabled Web browsers and Network Computers. These applets range from the highly functional (such as a spreadsheet applet) to those that support basic functional building blocks (an example includes the FileReader applet). As a whole, these applets were designed with the goal of supporting maximal use with the minimum of functionality. Speci cally, they support functionality that is part of a typical business user's application suite including: a word processor, spreadsheet, presentation package, etc. However, these implementations support minimal functionality { the 20% of an application's functionality that is used 80% of the time. The eSuite applets conform to the Java beans object component model [4]. As such, they have been designed to be easily integrated within a single web page to provide aggregate functionality and data sharing. The applets can share data through both direct interfaces or via the Infobus [2]. The Infobus is used as a communication mechanism for Java beans residing in the same Java Virtual Machine (JVM).
2
4 eFlow Architecture The goal of the eFlow framework is to enable a whole class of work ow participants by utilizing portable and lightweight client applications. By freeing participants from proprietary applications, eFlow will decrease the cost of traditional work ow participants as well as enable a new class of work ow users: casual work ow participants. This goal is achieved through the following two speci c components of eFlow:
Universal Access : Work ow services are exported to participants (users) through the Web as tasks. In order to utilize this ubiquitous interface, eFlow participants only need access to a Java client and a network connection. This is typically satis ed by either a Java-enabled Web browser or Network Computer.
Universal Inbox : To increase usability and decrease access latency, communication with the participants, including worklist task noti cation, is conducted using email. This allows a user to have a single point of service { or universal inbox for all their communication needs.
To support these goals, eFlow was created to provide a framework for developing work ow services that utilize eSuite components (word processors, spreadsheets, etc.) for work ow task completion. Since these components are written in pure Java, universal access is assured. The mainstay of the eFlow framework can be viewed as the software support needed to connect a Rainmaker-based distributed work ow system with these eSuite-based work ow tasks. Figure 2 illustrates the interaction between a single eFlow work ow service and an individual participant. The components of this interaction include: the eFlow server; the Servlet File System (SFS) interface; and the participant's email and Java clients. eFlow Server 1 Request/ Query Reply 9
RainMaker Interface
email Client
7 Commit
4
8
HTTP Server
Task #1's URL Task #2's URL ...
Notify 3
SMTP Interface eFlow Interface HTTP Interface
2
SFS Interface
6 Put URL
Java Client/ Browser eSuite Applet eSuite Applet eFlow Applet
5 Get URL
Figure 2: Internal architecture of an eFlow work ow service.
3
4.1 eFlow Server
The eFlow server is the interface to the Rainmaker work ow coordinator. Work is initially given to the eFlow server by the Rainmaker coordinator. Upon receipt it is translated into eSuite-based tasks for users to complete. The eFlow server has three primary tasks: task creation; task allocation; and task collection and distillation.
4.1.1 Task Creation
Upon receipt of a new work ow task, the eFlow server will dynamically create the task's HTML representation utilizing eSuite component applets where appropriate. Any implementation of a work ow service will implicitly understand it's associated tasks and be able to create an eSuite representation of these tasks from a speci c range of input. This can be captured as:
Hhtml = W (IRainMaker ) where the work ow service implementation, W , is equivalent to a function, that given an input IRainMaker generates a speci c output in the form of an HTML hierarchy, Hhtml . After creation, a user can access the task through its HTML representation using a Java-enabled Web browser.
4.1.2 Task Assignment The eFlow architecture is designed so that the management of a user's worklist is separated from a speci c work ow service. This allows for multiple work ow services to queue tasks on a speci c user's task list. This separation is e ected through the use of email. Speci cally, eFlow services will store their tasks on a server, and use email as the noti cation and invocation mechanism. The use of email for task assignment noti cation allows a user to have a universal inbox for both work ow and non-work ow items. This is important for participants that do not frequently service work ow tasks. By using their mailbox, these tasks are promptly brought to their attention, and are easily managed using standard mail handling agents (eg. procmail). Since the work ow task takes the form of a URL, invocation of the work ow's client application is as simple as point-and-click in an HTML-aware mail client.
4.1.3 Task Collection Upon completion of a work ow task, the eFlow server collects the data and either distills the results, or passes a handle to them back through the Rainmaker interface. The eSuite's word processor and spreadsheet applets store their data as XML documents [14]. The eFlow server contains a lightweight XML parser as well as several Java classes that extract named data ranges from these documents, simplifying data distillation and retrieval.
4.2 Servlet File System
The Servlet File System (SFS) was developed to support the persistent storage needs of the eFlow framework. The SFS satis es the following three con icting goals:
The persistent storage system for eFlow should not be centralized. Speci cally, data used to complete a work ow service's task need not be collocated with that service. 4
There should be a single reference handle used by both the eFlow server application, and the URL's accessed by a user's Web browser and eSuite applets. Since the eSuite applets access data using URL's, any data within the storage system must be accessible from the web server that served the applet. This constraint is due to the applet security model.
SFS accommodates these goals by interposing a servlet [11] at the web server collocated with the eFlow server. This servlet intercepts the HTTP GET and PUT methods for a subset of the URL reference space. URL's for les in this space take the following form: http://webServerName/servlet/ leServerName/ lePathName
Where webServerName is the name and port of the web server that served the applets; leServerName is the name of the host that contains the data; and the lePathName is the path on the leServer to the data le.
4.3 eFlow Applet
The eFlow applet, collocated with the eSuite applets (they reside in the same HTML page), provides the functionality to both: collect and save the eSuite applets' state; and notify the eFlow server upon task completion. The eFlow applet can be con gured to present the user with three types of buttons: save, commit, and start. The save button causes the eFlow applet to collect the state from the task's eSuite components in the form of XML documents, and then save these using the HTTP PUT method through the Web server's SFS interface. The commit button generates a message that noti es the eFlow server that the user has completed the task. Finally, the start button is used at the initial work ow node to create a new work ow instance.
4.4 Component Interaction
Figure 2 illustrates the ow of work through an eFlow service. The work is given to the service through the Rainmaker interface at (1). Next, after the new task has been created and stored in the SFS space (2), a reference and description of this task is created and sent through the eFlow server's SMTP [8] mail object at (3). Next, at (4), the task is invoked by the user in their mail client, which launches a Java client { possibly a web browser. The Java client reads the task's applets and data through the SFS interface at (5). After completing the task, the user saves the data back to the SFS at (6), and completes the task by clicking on the commit button. This generates the message to the eFlow server at (7). Finally the eFlow server retrieves the task at (8), extracts the required data, and returns the results to the work ow coordinator at (9).
5 Example Application The grant proposal work ow process, shown in Figure 3, has been implemented to demonstrate the framework's utility. It utilizes data types associated with the eSuite's word processor and spreadsheet components. The work ow represents a process for generating a research grant proposal. To initiate the work ow a unique grant id, the Request for Proposal (RFP), and the responsible faculty members 5
Equipment
Spreadsheet Accounting
Equipment Requirements
Accounting
Task Initiate Proposal
Create Outline
Complete Technical Content
Personnel Requirements Personnel
Grant ID Faculty IDs Associated RFP
Outline
Wordprocessor
Section Title Current State of Practice Problems/ Limitations
Complete Proposal
Research Issues
Figure 3: Example work ow for grant application process. are input to the system. Upon receipt of these data, the work ow creates the grant outline as an eSuite word processor document. This document is forwarded to the faculty members for completion of their parts of the technical content. After the technical content has been completed, the work ow then gathers the equipment and personnel requirements using eSuite spreadsheet components from the faculty. The accounting department is given these spreadsheets to nalize the numbers. Finally, the spreadsheets and the technical content are merged into a dossier that is sent to the grant agency.
6 Related Work Since 1993, the bene ts and use of work ow technologies have been promoted by the Work ow Management Coalition (WfMC), an international group of work ow vendors, users, and consultants. WfMC has sought and successfully implemented a set of standards for software terminology, inter-operability, and connectivity between work ow products [12, 13]. More recently, the Object Management Group (OMG) approved an inter-operability standard for work ow systems as part of a larger e ort to de ne a Business Object Facility for the CORBA architecture [5]. There is a growing body of research in the area of work ow systems, aside from work occurring in the standards bodies. An interesting model of work ow execution that can decentralize both work ow coordination and activity execution has been proposed in the context of the Arjuna project [9]. This execution model decentralizes work ow coordination by installing 'task controller' objects in di erent domains that coordinate with each other to deliver work ow routing functionality. While RainMaker and Arjuna share a belief in the importance of distributed work ow components, our work places greater emphasis on the inter-operability of disparate work ow components, and less emphasis on decentralized coordination. The issue of decentralized process enactment in the domain of software development has been addressed in OZ [1]. The premise of decentralized domains is the same in RainMaker; however, the OZ project emphasizes collaborative steps between independent, dispersed processes as a design requirement, and requires that a common process modeling formalism be used across domains. RainMaker does not address collaborative process steps and does 6
not mandate common modeling formalisms; instead, it emphasizes inter-operability between fully autonomous Performers with heterogeneous formalisms via standardized object interfaces. The issues of reliable messaging and inter-operability between work ow servers and applications in a client-server framework have been discussed in [10]. Programming work ows as active objects using a class libraries approach within a nested-transactional environment has been explored in [6]. All of these systems can be made to conform with the RainMaker interface; thereby allowing the eFlow system to provide a bridge from a large body of work ow systems to a new class of participants.
References [1] I. Z. Ben-Shaul and G. Kaiser. A Paradigm for Decentralized Process Modeling and its Realization in the OZ Environment. In International Conference on Software Engineering, Sorrento, Italy, 1994. [2] Mark Colan. InfoBus 1.1 Speci cation. http://java.sun.com/beans/infobus/spec, March 1998. [3] eSuite home page. http://www.esuite.lotus.com. [4] JavaBeans 1.0.1 Speci cation. http://java.sun.com/beans/docs/spec.html, July 1997. [5] Work ow Management Facility Request for Proposal. OMG Document BO RFP2. [6] M. Papazoglou, A. Delis, A. Bouguettaya, and M. Haghjoo. Class library support for work ow environments and applications. IEEE Transactions on Computers, 46(6), June 1997. [7] Santanu Paul, Edwin Park, and Jarir Chaar. RainMan: A Work ow System for the Internet. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Monterey, California, December 1997. [8] Jonathan B. Postel. Simple Mail Transfer Protocol (SMTP). RFC 821, August 1982. [9] F. Ranno, S. K. Shrivastava, and S. M. Wheater. A System for Speci ng and Coordinating the Execution of Reliable Distributed Applications. In International Working Conference on Distributed Applications and Interoperable Systems (DAIS97), Cottbus, Germany, September 1997. [10] H. Schuster, S. Jablonski, and C. Bussler. Client/server qualities: A basis for reliable distributed work ow management systems. In International Conference on Distributed Computing Systems, Baltimore, Maryland, 1997. [11] Java Servlets. http://www.javasoft.com/products/java-server/servlets, December 1997. [12] The Work ow Management Coalition. The Work ow Reference Model. Document No. TC001003 - Issue 1.1, November 1994. [13] The Work ow Management Coalition. The Work ow Management Coalition Overview. http://www.aiai.ed.ac.uk/WfMC/overview.html, March 1996. [14] Extensible Markup Language (XML). http://www.w3.org/XML, February 1998. 7
