CBL (Collaborative Benchmarking Laboratory)Department of Computer ScienceCampus Box 7550North Carolina State UniversityRaleigh, NC 27695Collaborative Work ows:A Paradigm For Distributed Benchmarking and Design on the InternetAmit Khetawat Hemang Lavana Franc BrglezTechnical Report 1997-TR@CBL-02-KhetawatFebruary 1997c 1997 CBLAll Rights ReservedIf you choose to cite this report, please add the following entry to your bibliography database:@techreport{1997-TR@CBL-02-Khetawat,author = "{Amit Khetawat and Hemang Lavana and Franc Brglez}",title = "{Collaborative Workflows:A Paradigm For Distributed Benchmarking and Design on the Internet}",institution = "{CBL, CS Dept., NCSU, Box 7550, Raleigh, NC 27695}",number = "97-TR@CBL-02-Khetawat",month = "February",year = "1997",note = "{This report is available as a postscript file via http://www.cbl.ncsu.edu/}",}Permission is granted to copy without fee all or part of this report, provided that the copies are not madeor distributed for direct commercial advantage.To contact the Collaborative Benchmarking Laboratory via Internet, you may consider:WWW : http://www.cbl.ncsu.edu/Anonymous FTP : ftp://ftp.cbl.ncsu.eduFor an auto-reply: benchmarks@cbl.ncsu.eduTo deposit a �le at CBL ftp cbl.ncsu.educd /pub/Incomingput new benchmark.tar.Z

Contents1 Introduction 12 Motivation 23 Work ows based on REUBEN 54 Multicasting: Architecture and Implementation 85 Recording and Playback 116 Conclusions and Call for Participation 18List of Figures1 A view of a typical collaborative session. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 42 OmniBrowser displaying various pull-down menus. : : : : : : : : : : : : : : : : : : : : : : : 63 Some of the windows in REUBEN that may be used during initial setup. : : : : : : : : : : 74 Implementation of a multi-user collaborative environment. : : : : : : : : : : : : : : : : : : : 95 Details of scheduling recorded and playback events. : : : : : : : : : : : : : : : : : : : : : : : 126 Block diagrams of the recording and the playback session. : : : : : : : : : : : : : : : : : : : 147 Implementation details of a recording and playback session. : : : : : : : : : : : : : : : : : : 168 Typical user view of a playback session. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17

Collaborative Work ows:A Paradigm For Distributed Benchmarking and Design on the InternetAmit Khetawat Hemang Lavana Franc BrglezCBL (Collaborative Benchmarking Laboratory)Dept. of Comp. Science, Box 7550, N.C. State University, Raleigh, NC 27695(http://www.cbl.ncsu.edu/demos/) 1Abstract { Tasks in a distributed benchmarking or design environment are complex andvariable. A single paradigm is not suitable for all tasks and teams, and a paradigm thatsuits a task and a team for some time may not be suitable for all of the time. The notionof a collaborative work ow as introduced in this paper is founded on a recon�gurable andcomposable graph-based representation of objects such as programs, �les, decisions, scripts,host de�nitions, team de�nitions, and recorded sessions which are shared across the Internet.Work ows can be executed and controlled in real-time by several distributed participants orcan be scheduled for batch execution and interaction.The collaborative environment we created is being tested in the context of design of ex-periments, exploring a way for an open, peer-reviewed series of benchmarking experimentsusing the Internet. In a parallel e�ort, we are exploring availability, for the �rst time, oflarge classes of equivalent class circuit mutants that may change the benchmarking paradigmas we know it today { in particular, if both e�orts lead to a large number of collaboratingand cooperating participants.1 IntroductionConsiderable e�ort is being directed in support of collaborative activities using the Internet. The com-mercial software market is concerned with collaboration products such as tele-conferencing, e-mail, groupcalendaring and scheduling, and multimedia document editing and management. An overview of researchissues related to sharing applications is presented in [2]. Systems that are available include Xplexer [3],Xshare [4], XMX [5], XTV [6], and ShowMe SharedApp[7]. The work presented in this paper addressessimilar issues. The primary motivation for creating a collaborative distributed environment in this researchis to create an opportunity for open, peer-reviewed, and collaborative benchmarking experiments on theInternet. We expect that the experience and the technology developed to support such experiments can bereadily applied to other environments, such as the distributed environment to support design automationof electronic circuits and systems.The management of teams, design systems, designers within teams, and design tools within systems is acomplex task. Design methodologies and design frameworks addressing these issues before the advent ofthe Internet have been an active area of research in the past decade, e.g. [8, 9, 10, 11, 12, 13, 14, 15, 16,17, 18, 19, 20]. Work ows, as de�ned by the business community [21], address issues of o�ce automation.Work ows for database and scienti�c applications are discussed in [22, 23]. A schema-based approach towork ow management is introduced in [24].1A companion report, which uses the environment described in this report as an infrastructure, to generate new sets ofbenchmarks is available in [1]. 1

Typical tasks in a distributed design environment are complex and can vary signi�cantly. A singleparadigm is not suitable for all tasks and teams, and a paradigm that suits a task and a team for some timemay not be suitable for all of the time. The consensus about what is an e�ective paradigm, when it comesto supporting complex inter-user communication models and a set of tasks distributed in space and time, isstill evolving. This paper presents a composable, recon�gurable, and inter-operable software environmentthat supports collaborative, semantics-sensitive, user-customizable work ow capture across the Internet.The features in this environment are being tested for real-time collaborative applications to evaluate itse�ectiveness. The approach leverages and builds upon the recon�gurable work ow environment we initiatedearlier [25, 26]. Complementary approaches to using the Internet in a distributed design environment canbe examined by accessing the Internet [27, 28].The paper is organized as follows.Section 2 describes a scenario that has motivated much of the direction for the current work.Section 3 introduces the Tcl/Tk-based work ow objects that have been implemented to support work owcapture, consistency checking, and collaborative execution.Section 4 introduces a novel multi-cast Tcl/Tk architecture that has been implemented to meet the needsof the proposed collaborative environment. The approach is applicable to any program written inTcl/Tk [29, 30], which also uses Expect [31], and is compatible with the latest release of Tcl/Tk andExpect [32].Section 5 describes a novel approach to Session Recording and Playback that supports any applicationwritten in Tcl/Tk [29], and is compatible with the latest release of Tcl/Tk and Expect [32] Weanticipate that the feature of Session Recording and Playback will become a major facilitator notonly during a real-time collaborative session but also as an aid in preparing on-line animated softwaredocumentation and various tutorials.Section 6 concludes with a Call for Participation to peers interested in conducting collaborative bench-marking experiments on the Internet, using the collaborative work ow technology in this paper.Examples of typical objectives of such experiments are presented in the companion paper, [33], alsosubmitted to EuroDAC97.A companion report, which uses the environment described in this report as an infrastructure, to generatenew sets of benchmarks is available in [1].2 MotivationDesign of experiments, in particular benchmarking experiments where participants are distributed, requiresa consistent approach and an environment that is stable and repeatable over a long period of time. Thenotion of a collaborative work ow, as implemented in this research, has in large part been driven by suchrequirements.The work ow we introduce in Figure 1, and whose technical features we describe later in this section,illustrates a ow which we may use to benchmark (1) two technology mappers using the same technologylibrary, (2) two libraries using the same technology mapper, or (3) a combination of both. There may beup to three teams participating in this experiment, each at a site that may be a continent away from theother. We show both data and programs ( technology mappers, veri�cation tools) residing at one of thethree sites. Site0 is the source of archived data (benchmarks) to be used by both technology mappers.Upon completion of technology mapping at either Site1 or Site2, results are transferred back to to Site02

for logic equivalence veri�cation, report generation, and archival. As will be clear from the more detaileddescription that follows, the work ow can be executed collaboratively in a synchronous mode (by selectingany of its path segments) or in a batch mode.A more detailed narrative about the work ow background, speci�c example, and typical modes of execu-tion conclude this section. More technical details are provided in the sections that follow.Background. The current version of the work ow has evolved from the earlier prototypes [25, 26]. Thehierarchical, multi-host, collaborative, and recording/playback features as described in this paper are new.The work ow is displayed as an executable directed hypergraph, with nodes representing programs anddata, and hyperedges representing data-to-program, program-to-data, data-to-data, program-to-programdependencies. Both data and programs can reside on any server or on any client with a unique IP address.Program nodes can be hierarchical in the sense that they may expand into their own work ows of data andprogram nodes. Work ow transformations to Petri nets give rise to (1) a canonical, and (2) an executablePetri net representation; the latter generates the schedule of the work ow execution. Unlike the acycliccommercial work ows, work ows we implement are general: they can have loops and decision nodes, andexecute program nodes in parallel. Given a library of program and data nodes, recon�guring work ows isas intuitive as editing a hierarchical netlist schematic. Template editors encapsulate programs and data,such that semantic consistency of the work ow is maintained. Details about the Internet protocols andsecurity are hidden from the �eld user. By highlighting a data node, the user can select/view/edit from adisplayed list of �les associated with the particular data node.An Example of a Collaborative Work ow. A static display of typical windows associated with thework ow is shown in Figure 1. The top window, named as _TechnologyMapping depicts the top view ofa speci�c work ow. Ovals represent data nodes, rectangles represent program nodes, yes/no rectangles aredecision nodes, heavy-drawn rectangles are hierarchical nodes. All major nodes are identi�ed with threehost sites: Site0 , Site1, Site2. The window insert named archiveDataFromSite2 is an example of anexpanded hierarchical node with the same name. While the work ow such as _TechnologyMapping mayroutinely execute at multiple sites, the window named FlowSynchronizer is a generic window that willopen only when there are two or more participants involved in the execution of the work ow.The work ow editing, execution, and interaction with other participants make the work ow display dy-namic. The dynamics of this process can now be captured in a recording session and played back forreview; this process is described in a subsequent section of the paper. Any of the sites in the work ow canbe designated as the server site. During a multi-user multi-site execution, the server site broadcasts to `n'client sites (where the server itself could be one of its clients) at least two windows: the work ow windowand the ow synchronizer window. The work ow window is application-speci�c, the ow synchronizer win-dow is generic, consisting of `n' segments, each segment providing site identi�cation and a scrollable talksubwindow. The site displayed in green in the ow synchronizer window holds the token that controls anyand all paths of the work ow. Any user can request and receive control of the ow from the current tokenholder and execute any path segment, or the complete path in the work ow, while others are observingits behavior. While the example in Figure 1 is speci�c to benchmarking a Technology Mapping Processfor sake of illustration, public domain and commercial tools have been incorporated into the large varietyof work ows and tests of successful demos have already been executed between collaborating sites on theEast and the West Coasts.Modes and Dynamics of a Collaborative Work ow Execution. In the most general case, we envi-sion collaborative work ows as having three principal categories of users, each de�ning its own mode anddynamics: system user, brainstorm and planning user, and �eld user. System (or librarian or adminis-tration) user sets up and maintains the integrity of all communications and objects (programs and data),3

Figure 1: A view of a typical collaborative session.4

including preference-laden-home-page-like-objects of all authorized group participants. Brainstorm andplanning users are part of the team that analyses a problem, develops a solution (or a solution template)and prepares it for a �eld user. Field user either enacts a particular solution or reviews it and requestsadditional planning and solutions.System users at di�erent sites may need to interact synchronously or asynchronously. Brainstorm andplanning users will require synchronous interaction most of the time. Field users will typically be engagedin longer-term, carefully planned executions and may or may not require to interact synchronously.In the context of benchmarking experiment, system users will setup and maintain the basic work owinfrastructure. Brainstorm and planning users will set-up the initial benchmarking work ow and satisfythemselves, using small scaled-down examples, that the ow meets all stipulated objectives. Real-timecollaborative experiments, con�rmations, and negotiations are an essential part of this process. Field userswill carry out long-term experiments using the proven, peer-reviewed benchmarking work ow. Much ofthis process will have been automated and executed in a batch mode.3 Work ows based on REUBENThe speci�c work ow architecture, initiated in [26, 25], has been named REUBEN for REcon�gurableand reUsable Benchmarking ENvironment. Basic details about its editing capabilities and execution havealready been described. The original organization of the graph structure in REUBEN relied on the followingclasses of objects:1. decision nodes2. �le nodes3. program nodes4. script nodes5. work ow nodesThe new classes of objects being added include:1. host de�nition templates2. team de�nition templates3. recorded sessionsA work ow library consists of distinct directories corresponding to each object class. All �les pertaining toa common object class are located in their respective directories. Work ow libraries are of several types:� libraries provided by REUBEN,� site-speci�c libraries created and maintained by system users,� group-speci�c libraries created by brainstorm users and system users,� personal libraries, created and maintained by �eld users.This section describes a top-level view of the initial setup to launch a collaborative work ow in REUBEN.OmniBrowser. OmniBrowser is a powerful utility to traverse and browse not only the local �le systembut also the �le system of a remote site.The browser operates in either one of two modes: 5

User-invoked. In this mode, user can perform simple tasks such as navigating the �le systems, copying,moving, viewing or editing a selected �le, etc. The �le systems can be local or remote.Application-invoked. In this mode, the browser is customized by the calling application, enhancing thefeatures of its user-invoked mode. At any time, user may choose to toggle between the two browsermodes.Figure 2 shows the pull-down menu options available in OmniBrowser: File, Utilities, Filter Objects,Preferences and Help. The calling application customizes the Filter Objects menu. In Figure 2, theFilter Objects menu has been customized by invoking the REUBEN application, hence the listing of thefollowing classes of objects: decisions, �les, hosts, programs, recordings, scripts, teams, and work ows.The selection/deselection of Filter Objects allow the user to dynamically control the display of directoriesand �les.Numerous other features of OmniBrowser will become apparent once we discuss it in the context of theinvoking application such as REUBEN.

Figure 2: OmniBrowser displaying various pull-down menus.REUBEN Manager, shown in Figure 3(a), provides an environment for launching applications. Theseapplications may be launched either as a single user or in collaboration with a selected team. At the sametime, an entire session of a launched application may be recorded for a playback at a convenient time later.This is possible by enabling a recording session from the Utilities option menu and specifying a �lenamefor the data recorded.Nominally, REUBEN Manager also invokes the OmniBrowser. Figure 2 and Figure 3(b) are linked toREUBEN Manager in Figure 3(a). By clicking the `Browse' button for 'Object Selection' in REUBENManager and the `Technology Mapping' under 'work ows' in the OmniBroser, we will have invoked thework ow such as shown in Figure 1. By clicking the `Browse' button for 'Team Selection' in REUBENManager and the `CBLteam1' under 'teams' in the OmniBroser, we will have invoked the FlowSynchronizerwindow such as shown in Figure 1. 6

(a) REUBEN Manager

(b) REUBEN customized OmniBrowser

(c) Host De�nition Editor (d) Team De�nition Editor

Figure 3: Some of the windows in REUBEN that may be used during initial setup.7

Host De�nition Editor. By clicking the `mouse' button on 'zodiac' under 'hosts' in the OmniBrowser,we will have invoked the HostManager window such as shown in 3(c). This is the window where we storeinformation about the host site.Host de�nition editor is useful not only for providing information about host address required in teamde�nition editor, but also for remote execution capability of the work ow. However, telnet address is theonly entry necessary for team collaboration. Other entries are optional.Team De�nition Editor. By clicking the `mouse' button on 'CBLteam1' under 'teams' in the Omni-Broser, we will have invoked the TeamManager window such as shown in 3(d). This is the window wherewe store information about the composition of the collaborative team.Next section introduces mechanisms to achieve a collaborative work ow environment, namely ApplicationsSharing Layer and FlowSynchronizer.4 Multicasting: Architecture and ImplementationDesigners working on complex projects are not always in the same place. Team collaboration is essentialfor the successful outcome of such projects.The Internet, intranets and powerful desktop workstations o�er an opportunity to dramatically improvereal-time collaborative environments. Team members can interact synchronously with applications ondisplays attached to their hosts. All members are given the capability to control, one at a time, anapplication of common interest, and all members have the opportunity to observe the results.We have considered the following methods to implement a collaborative environment for Tcl/Tk applica-tions.(1) Existing Tcl/Tk architecture modi�cation. We may incorporate an intermediate layer between theTcl/Tk application code and the Tcl/Tk Interpreter. This intermediate layer would provide theTcl/Tk Interpreter with a dynamically generated code that would draw the graphics on multipledisplays and also receive events from them.(2) Multiple interpreter invocation. We may create, for each user in the session, an interpreter thatcontrols the events, such as mouse clicks and drawings, on each display. These interpreters, in turn,communicate with a master interpreter which manages the application.(3) Double Bu�ering. The multiple displays in this case could be achieved in two phases. In the �rstphase, all drawings are routed to an o�-screen bu�er called the pixmap. This bu�er maintains anupdated copy of the application's current display. In the second phase, the contents of this bu�erare copied to the displays of all the members participating in the session.Although the �rst two methods seem to be promising, the �rst method is relatively simpler to imple-ment. The bandwidth requirement of the double bu�ering method for transferring the bitmap over thenetwork is its major disadvantage. We use Existing Tcl/Tk architecture modi�cation method to implementcollaborative environment described below.Multi-user collaborative environment. Figure 4(a) shows the single-cast mode operation. This is thedefault operation mode of the Tcl/Tk architecture. In this mode, the Tcl/Tk code is interpreted by aTcl/Tk Interpreter which is a library of C procedures. The results are then output to the user's display.8

(a) single-cast Tcl/Tk architecture

(b) multi-cast collaborative Tcl/Tk architecture

Tcl Application Tcl /TkInterpreter

User 1

Display(Site 1)

Application Sharing Layer (ASL)

DynamicCode

Generator

Hostlist

(Token holder)

DisplayController

(c) implementation detail of multi-cast collaborative Tcl/Tk architecture

User 1

Display(Site 1)

User 2

Display(Site 2)

User 3

Display(Site 3)Tcl Application Tcl /Tk

Interpreter

FlowSynchronizer

Original Application (Hello):----------------------------- label .hello -text "Hello World" pack .hello

Multi-cast Application (M-Hello) generated by Application Sharing Layer:------------------------------------------------------------------------DisplayController and FlowSynchronizer initialization: toplevel .screen1 -screen screen@site1:0 toplevel .screen2 -screen screen@site2:0 toplevel .screen3 -screen screen@site3:0

Dynamic code generation: label .screen1.hello -text "Hello World" label .screen2.hello -text "Hello World" label .screen3.hello -text "Hello World" pack .screen1.hello pack .screen2.hello pack .screen3.helloFigure 4: Implementation of a multi-user collaborative environment.9

We modify the approach in Figure 4(a) to create a multi-cast collaborative mode of operation by insertingan Application Sharing Layer (ASL) between the Tcl/Tk application code and the Tcl/Tk Interpreter, asshown in Figure 4(b). The ASL takes the original application code and a list of hosts as input. Thislayer consists of three components: the FlowSynchronizer, the Display Controller, and the Dynamic CodeGenerator. The FlowSynchronizer is a Tcl/Tk application which provides the ability for real-time confer-encing. The Display Controller facilitates and manages control exchanges of the work ow (or any otherTcl/Tk application) among the collaborators. The Dynamic Code Generator (DCG) provides the abilityto broadcast the application and process input events from the collaborator's displays. DCG also generatesthe dynamic code which is interpreted by the Tcl/Tk Interpreter.The collaborators communicate with each other through the FlowSynchronizer. The FlowSynchronizer islinked to the Display Controller, which in turn controls the Dynamic Code Generator. The user designatedas Token Holder can control the application. The input events from the Token Holder are directed to theDisplay Controller which communicates internally with the DCG.We use a simple application Hello in Figure 4(c) to illustrate, in three parts, the main ideas used toimplement the multicasting operation: Display, Original application, and Multi-casting application.The Display of "Hello World" is what the user sees as a result of executing either the original applicationHello or the multi-cast application M-Hello. The original application Hello consists of Tcl/Tk commandslike "label" and "pack". The Tcl/Tk Interpreter reads the label command and creates a label widget for awindow whose name is ".hello" with text inside this window being "Hello World". Widgets are graphicalobjects similar to those of other GUI toolkits such as Xlib, Xview and Motif. The Tcl/Tk Interpreterinterprets the pack command and actually draws the window ".hello" on the user's display using theTcl/Tk window manager.The multi-cast application M-Hello consists of two parts:� Display Controller and FlowSynchronizer initialization. This creates a toplevel window with a uniquename for each of the displays. This toplevel window acts as a place holder for the various widgetsto be de�ned in the application code. In this case each of these toplevel window is going to hold thelabel widget.� Dynamic Code Generation. This creates the label widgets inside the toplevel window for each ofthe displays. Finally multiple "pack" commands are generated to pack the labels on their respectivedisplays.It is not necessary to use C or C++ in order to manipulate the widgets, and useful applications can bebuilt very rapidly using Tcl/Tk. This is in sharp contrast to tools such as Xplexer [3] and Xshare [5].The �rst is a X application sharing system which uses Xlib for implementation. The second is anothergroupware tool which uses the Motif toolkit for its implementation.Exchange of the control in a collaborative multi-user environment. In most applications, it isessential that at any time, only one user controls inputs during the execution of the application. Severalmethods have been proposed that consider the allocation of control to multiple users. For example:1. No Control. No speci�c end-user has the control of the invoked application. Any user can executeor terminate the application at any time, resulting in contentions.2. Single User Control. Only one user can control the application, with others participants as merespectators. 10

3. Automated Control. The control is pre-con�gured. The control is switched between the end-usersdepending on their actions. Example: In a chess game, the control is passed back and forth betweenthe two players after each players move.4. Floating Control. The control is oating: no-user has the control of the application at the time ofinvocation of the application. The user who grabs the control �rst has the control of the applicationuntil she releases the control. At this point another user can grab the control.5. Request-based Control. The initial control is speci�ed at the time the application is launched. Thecontrol can be transferred from the initial token holder to another user upon request.The control mechanism implemented in our approach uses the request-based control mechanism to exchangecontrol among collaborators. The Display Controller as shown in Figure 4(b) accepts input events such asmouse movements and keyboard events, and responds to the action of the Token Holder only. The inputevents from other users are blocked by the Display Controller. The control can be passed by the TokenHolder to another user by clicking the "othersite" button on the FlowSynchronizer. The Token Holder's"othersite" button on the FlowSynchronizer has a special color to indicate the possession of control. Weillustrate some of these features in the next two examples.Examples of collaboration. An example of what all users typically see on their displays is illustratedin Figure 1. This view consists of two parts: an application speci�c work ow, and the FlowSynchronizer.In the case shown, the work ow encapsulates site-speci�c tools/data for technology mapping, where theperformance of technology mappers from two or more sites can be compared for a large set of benchmarkcircuits.Figure 1(b) shows the FlowSynchronizer which is used to dynamically exchange control using a request-based mechanism. The FlowSynchronizer has two components for each participating site. A clickablebutton (which also has the site name embedded in it) and a scrollable window which provides a real-timeconferencing environment for e�cient and e�ective collaboration. Each collaborator, at any time, has theability to transmit messages in his text box only. But only the Token Holder has the capability to click onthe "othersite" buttons to pass control to a "othersite". Once the "othersite" gets control, it controls theentire environment, including the application.5 Recording and PlaybackCapability to record and playback a session faithfully is as important as team collaboration is in currentworking environments. Recording and playback essentially involves capturing of all events that are generatedduring a session and reproducing those events in exactly the same sequence as they were generated.Event is an occurrence of an interaction between the user and the windowing system. The windowingsystem constitutes of the local display, keyboard, and the mouse. Recording and Playback necessitate event-driven programming using timers and asynchronous I/O. Tcl/Tk provides an easy model for registeringany event generated during the recording session and for regenerating the same events during its playback.In order to distinguish between the events occuring during recording and playback, we categorize theevents into two types:Window events are generated by the windowing system during run time of an application, in responseto the interaction of the user with the application. These events are stored as trace data during therecording of a session. 11

(a) Timing diagram of typical events to be recorded

0 tr 1tr 2 tr 3 tr

time

E2

E

1

0

E

E

3

(b) Run time trace data ofrecorded eventsEvent listE0E1...En : : :: : :: : : Start timestr0tr1...trn(c) Static scheduling of playback eventswait s � tr0 wait s � tr1 wait s � tr2 wait s � trn�1 wait s � trnexecute E0 execute E1 execute E2 . . . execute En�1 execute En(d) Dynamic scheduling of playback eventswait s0 � tr0execute E0 wait s1 � (tr1 � tr0)execute E1 wait s2 � (tr2 � tr1)execute E2 . . . wait sn�1 � (trn�1 � trn�2)execute En�1 wait sn � (trn � trn�1)execute En(e) Comparision of static and dynamic scheduling of playback eventsPlayback time Static scheduling Dynamic schedulingtp0 s � tr0 s0 � tr0tp1 s � tr1 tp0 + s1 � (tr1 � tr0)tp2 s � tr2 tp1 + s2 � (tr2 � tr1)... ... ...tpn s � tr3 tpn�1 + sn � (trn � trn�1)Figure 5: Details of scheduling recorded and playback events.12

Synthesized events are invoked internally by the application using Tcl/Tk commands and not in responseto user input. The Tcl/Tk interpreter arranges for the synthesized events to be processed just as ifit were a part of the user input from the window system. The window events to be synthesized areextracted from the trace data.Every event consists of at least a primitive component, and it may also contain additional details. Ex-amples of primitive components, which occur when the user interacts with an application on the localwindowing system include:� ButtonPress� ButtonRelease� Mouse Motion� Key PressFigure 5(a) shows a timing diagram illustrating the relationship between various events and their record-ing times. We de�ne the various terms related to a recording session as follows:Ei The ith event in a session.tri The time at which event Ei occurs during a recording session.tri+1 � tri The time di�erence between the occurrence of the event Ei+1 and the event Ei.n The total number of a events for a session.Events related to playback are as follows:tpi The time at which event Ei will be played back.s Constant scale factor. This scaling factor remains constant for the entire playback session ofall n events and is pre-computed at the start of a playback session.si The dynamic scaling factor for the ith event. This scaling factor may change anytime duringthe playback session.Figure 5 (b) shows the trace data which is a list of events and their corresponding recording times.This timing information associated with each event is very critical, and is useful for synchronizing thesynthesized events during a playback session. Figures 5(c) (d) (e) illustrate the signi�cance of the timinginformation associated with each event. The timing information along with the scaling factor is used toschedule events for playback.Figure 5(c) shows the static scheduling of events in which all the n events are scheduled at the start ofa playback session. The time, for which the event Ei is scheduled to execute, is computed by multiplyingtri with the constant scale factor s. This approach has several limitations which include the inability toschedule events dynamically during the playback session. This limits the user's ability to pause or varyexecution speed between consecutive events.This limitation can be overcome by using a dynamic approach, as depicted in Figure 5(d). In thisapproach, the event Ei+1 is scheduled at the start of execution of event Ei. The scaling factor used forscheduling event Ei+1 is computed not at the start of playback session but at the start of execution ofevent Ei. This gives the user exibility to pause during playback, or dynamically scale down or scale upthe playback speed.Architecture and Implementation. Figures 6(a) and 6(b) show the block diagrams for recording andplayback session. During the recording mode, the Tcl/Tk code passes through a Recording Interpreterwhich records the user interactions with the application and generates the Run Time Trace Data. This13

(a) Architecture of recording mechanismTcl/Tk Application

Recording Run Time Trace DataInterpreter

(b) Architecture of playback sessionRun TimeTrace Data

Trace DataProcessor

Playback

Session

Figure 6: Block diagrams of the recording and the playback session.

14

trace data, as shown in �g 6(b), then goes through a Trace Data Processor which generates the �nalPlayback Session with all the relevant scaling factors, timing information per event and other headers andtrailers.We use a simple application Print Hello button in Figure 7 to illustrate the main ideas used to implementthe recording and playback mechanism.The left side of the �gure shows the trace data, and the right side of the �gure shows the Tcl/Tk commandsused for synthesis of the recorded events and the user views as each event is synthesized.We now describe the steps illustrated in the Figure 7 to synthesize the events like Enter, ButtonPress,etc.Step 1. Invoke the button application with the commandpack [button .b -text "Print Hello"]Step 2. Synthesize the event "Enter" in the window ".b" with the commandevent generate .b <Enter>Step 3. Synthesize the event "ButtonPress" in the window ".b" with the commandevent generate .b <ButtonPress> -button 1The option "-button 1" speci�es the the Mouse button 1.Step 4. Synthesize the event "ButtonRelease" in the window ".b" with the commandevent generate .b <ButtonRelease> -button 1The option "-button 1" speci�es the the Mouse button 1.Step 5. Synthesize the event "Leave" in the window ".b" with the commandevent generate .b <Leave>User view of a playback session. Figure 8(a) shows a partially constructed ow and a new datanode being created. Figure 8(b) shows the description window, which provides the user with a dynamiccapability to recon�gure his playback session. Each playback session is divided into a number of frames.Each frame is further subdivided into set of steps. Each step by itself consists of sequence of events. Thedescription window consists of following components :� FrameDescription. This is a text box in which the description of the steps involved in creating aframe appears. Figure 8(b) describes a frame which is a set of steps needed to create the data node.� Rewind. This button restarts the playback session. For the given example it would restart to createthe entire ow.� Next Frame. This button invokes the next set of steps de�ned in the next frame. For the givenexample it would invoke steps to add dependency or a link between the previous program node andthe last created data node for site 1.� Exit. This button exits the playback session.� FrameSpeed. This slider is used to vary the playback speed within a frame. This slider providesgranularity of scheduling events within a single frame.� Pause. This button pauses the execution of the active frame. It puts a marker on the next stepwithin the active frame. 15

� Continue. This button continues the execution of the active frame from the next step, which hadbeen marked by the Pause button.Trace Data Froma Recording Session Event Synthesisduring Playback Sessionpack [button .b -text "Print Hello"]Window : .bEvent : EnterTime : tr0 event generate .b <Enter>Window : .bEvent : ButtonPressTime : tr1Mouse button : 1 event generate .b <ButtonPress> -button 1Window : .bEvent : ButtonReleaseTime : tr2Mouse button : 1 event generate .b <ButtonRelease> -button 1Window : .bEvent : LeaveTime : tr3 event generate .b <Leave>

Figure 7: Implementation details of a recording and playback session.16

(a) Work ow creation playback (in progress)

(b) Single frame description of work ow creation playback

Figure 8: Typical user view of a playback session.17

6 Conclusions and Call for ParticipationWe have demonstrated a collaborative work ow environment that can support peer-reviewed distributedbenchmarking experiments using the Internet. The environment can be readily recon�gured by the severalclasses of users for variety of tasks. The user classes include system users, brainstorm and planningusers, and �eld users. Tasks include maintenance of work ow communications, objects and recordings;benchmark support, report generation and archival of veri�ed experimental results; new and novel work owrecon�guration and testing, automated execution of work ows for a series of large-scale benchmarkingexperiments, etc.Real-time collaborative execution of new work ow setups, or playback of recorded sessions, are essentialto support the decision making process among the distributed participants. Linked to a collaborativemulticast implementation proposed in this paper, a distributed team can interact with the work ow ase�ectively as would a team working in a common physical location.Call for Participation. We are interested in discussing options with potential participants about testing,hosting, and facilitating benchmarking experiments within the context described in this and the companionpaper [33].There are two modes in which an interested participant can make initial use of our collaboration technologyto construct collaborative work ows, or ToolFlows:In Mode (A),you/we execute paths in a ToolFlow where none of the non-web toolsreside on participant's host.In Mode (B),you/we execute paths in a ToolFlow where participant gives us permission andworks with us to encapsulate some of the tools residing on participant's host into the ToolFlow.The minimum requirements for any site to launch a Collaborative Work ow are:1. Tcl/Tk interpreter (http://www.sco.com/Technology/tcl/Tcl.html)2. Work ow manager (described in this paper)3. Tcl/Tk Application/Application speci�c Work ow (user-supplied)4. OmniBrowser (described in this paper)5. List of Clients running X windows (user-supplied)For more details, please send e-mail to benchmarks@cbl.ncsu.edu with the following information in thebody of the message:subscribe demos18

References[1] Debabrata Ghosh, Nevin Kapur, Justin Harlow, and Franc Brglez. Synthesis of Signature-Invariant Equiva-lence Class Circuit Mutants and Applications to Benchmarking. Technical Report 97-TR@CBL-01, CBL, CSDept., NCSU, Box 7550, Raleigh, NC 27695, February 1997. This report is available as a postscript �le viahttp://www.cbl.ncsu.edu/.[2] Hussein Abdel-Wahab and Kevin Je�ay. Issues, Problems and Solutions in Sharing X Clients on MultipleDisplays. In Journal of Internetworking Research and Experience, pages 01{15, March 1994.[3] The Application Sharing Technology. Published under URL:http://andru.unx.com/DD/advisor/docs/jun95/jun95.minenko.shtml , 1995.[4] XShare: Workstation Conferencing. Published under URL:http://www.eit.com/software/xshare/ , 1996.[5] XMX : A X Protocol Multiplexer. Published under URL:http://www.cs.brown.edu/software/xmx/ , 1990.[6] XTV: A User's Guide. Published under URL:http://www.visc.vt.edu/succeed/xtv.html , 1993.[7] ShowMe SharedApp . Published under URL:http://www.sun.com:80/cgi-bin/show?products-n-solutions/sw/ShowMe/products/ShowMe_SharedApp.html , 1996.[8] OCT Manual. UC Berkeley EECS Technical Report, 1989.[9] D. S. Harrison, R. A. Newton, R. L. Spickelmier, T. J. Barnes. Electronic CAD Frameworks. Proceedings ofIEEE, 78(2):1062{1081, February 1990.[10] J. Daniell and S. W. Director. An Object Oriented Approach to CAD Tool Control Within a Design Framework.IEEE Transactions on Computer-Aided Design, 10(6):698{713, June 1991.[11] A. Casotto and A. Sangiovanni-Vincentelli. Automated Design Management Using Traces. IEEE Transactionson Computer-Aided Design, 12(8):1077{1095, August 1993.[12] N. Filer, M. Brown and Z. Moosa. Intergrating CAD Tools into a Framework Environment Using a Flexibleand Adaptable Procedural Interface. In European Design Automation Conference with EURO-VHDL, pages200{205, September 1994.[13] A. Hoeven, O. Bosch, R. Leuken, and P. Wolf. A Flexible Access Control Mechanism for CAD Frameworks. InEuropean Design Automation Conference with EURO-VHDL, pages 188{193, September 1994.[14] F. R. Wagner, L. Golendziner, and M. R. Fornari. A Tightly Coupled Approach to Design and Data Management.In European Design Automation Conference with EURO-VHDL, pages 194{199, September 1994.[15] W. Schettler, S. Heymann. Towars Support for Design Description Languages in EDA Frameworks. In IEEEInternational Conference on Computer-Aided Design, pages 762{767, November 1994.[16] S. T. Frezza, S. Levitan and P. Chrysanthis. Requirements-Based Design Evaluation. In 32nd Design AutomationConference, ACM/IEEE, pages 76{81, June 1995.[17] E. W. Johnson and J. B. Brockman. Incorporating Design Schedule Management into a Flow ManagementSystem. In 32nd Design Automation Conference, ACM/IEEE, pages 82{87, June 1995.[18] J. Altmeyer, B. Schurmann and M. Schutze. Generating ECAD Framework Code from Abstract Models. In32nd Design Automation Conference, ACM/IEEE, pages 88{93, June 1995.[19] J. Schubert, A. Kunzmann, and W. Rosenstiel. Reduced Design Time by Load Distribution with CAD Frame-work Methodolgy Information. In European Design Automation Conference with EURO-VHDL, pages 314{319,September 1995. 19

[20] A. Bredenfeld. Cooperative Concurrency Control for Design Environment. In European Design AutomationConference with EURO-VHDL, pages 308{313, September 1995.[21] Layna Fischer. The Work ow Paradigm. (2nd Edition). Future Strategies Inc., 1995.[22] Munindar P. Singh. Synthesizing Distributed Constrained Events from Transactional Work ow Speci�cations.In Proceedings of the 12th International Conference on Data Engineering, March 1996.[23] Munindar P. Singh and Mladen A. Vouk. Scienti�c Work ows. Submitted to the NSF Workshop on Work owand Process Automation in Information Systems: State of the Art and Future Directions, 1996.[24] J. B. Brockman and S. W. Director. The Schema-based Approach to Work owManagement. IEEE Transactionson Computer-Aided Design, 14(10):1445{1267, October 1995.[25] K. Kozminski, B. Duewer, H. Lavana, A. Khetawat, and F. Brglez. REUBEN: A Tcl{Based Reusable En-vironment Driven by Benchmarking Applications. Technical Report 95-TR@CBL-03.1, CBL , ECE Dept.,NCSU, Box 7911, Raleigh, NC 27695, October 1995. This report is available as a postscript �le viahttp://www.cbl.ncsu.edu/demos.[26] H. Lavana, A. Khetawat, F. Brglez, and K. Kozminski. Executable Work ows: A Paradigm for CollaborativeDesign on the Internet. Technical Report 96-TR@CBL-03.1, CBL, ECE Dept., NCSU, Box 7911, Raleigh, NC27695, September 1996. This report is available as a postscript �le via http://www.cbl.ncsu.edu/demos.[27] WELD: Web Based Electronic Design. Published under URL:http://www-cad.EECS.Berkeley.EDU/Respep/Research/weld , 1996.[28] PPP: Low Power Synthesis and Simulation on the Web. Published under URL:http://akebona.stanford.edu/users/PPP/ , 1996.[29] J. K. Ousterhout. Tcl and the Tk Toolkit. Addison-Wesley, 1994.[30] Brent B. Welch. Practical Programming in Tcl and Tk. Prentice Hall, 1995.[31] D. Libes. Exploring Expect. O'Reilly and Associates, 1995.[32] The Tcl/Tk Project At Sun Microsystems Laboratories. URL:http://www.sunlabs.com:80/research/tcl/ , 1997.[33] D. Ghosh, N. Kapur, J. Harlow, and F. Brglez. Synthesis of Signature{Invariant Equivalence Class CircuitMutants and Applications to Benchmarking. Technical Report 97-TR@CBL-02.1, CBL , CS Dept., NCSU, Box7550, Raleigh, NC 27695-7550, February 1997. Available as a postscript �le via http://www.cbl.ncsu.edu/demos.

20