Internet-based workflows: a paradigm for dynamically reconfigurable desktop environments

Internet-based A Paradigm

for Dynamically

Workflows:

Reconfigurable

Desktop Environments

Amit Khetawat

Hemang Lavana

Franc Brglez

CBL (Collaborative Benchmarking Laboratory) Department of Computer Science Box 7550, NC State University, Raleigh, NC 27695, USA http://www.cbl.ncsu.edu/ . - The Internet-based

Abstract

desktop environment as de-

fined in this paper consists of a cross-platform browser, a

number of server icons (host nodes), a number of application icons (program nodes) and a number of data iwns’(file nodes). In contrast to typical desktops of today, where data icons may be dragged and dropped onto application icons for execution, this environment allows (I) user-defined and reconfigurable execution sequences by creating dependency edges between program nodes (application icons) and file nodes (data icons); (2) data-dependent execution sequences by dynamic scheduling of path as well as loop executions; (3) host-transparency as to the location of applications and data (60th can reside on any host with a unique IP address). We argue that the Internet-based workflow paradigm is suitable for creation of dynamically reco;lfigurable desktop environments.

The summary of 450 Internet-based

demonstrates

expen’ments

(1) the value of making the desktop recordable,

and (2) the feasibility of rendering it collaborative.

Keywords: collaborative,

Internet, desktop, workflows, reconfigurable, recordable, Petri net.

The Internet is removing the barriers across space, time and technologies. In particular, network-integrated computing on the Internet is an area of great expectations and on-going r+ search. Questions that arise concern system in&structure ma quality-of-service, security mechanisms, information retrieval, writing programs that run on the Internet, user interface, groups of distributed users that require collaboration and other types of software tools. Presently, the basic desktop environment of a computer This research was supported Corporation

(94-DJ-563),

by contracts

SEMATECH

from the Semiconductor (94-DJ-300),

and

Research

DARPA/ARO

(P-3316-EL/DAAHO4-94-G-2030).

Pennission

to make digitalhnrd

copies ofall

or part ofthis

mnterinl

for

personal or classroom use is granted without fee provided that the copies ore not made or distributed for profit or commercial ndvanhge, the copyright notice. the title ofthe publication and ils dale appear, and nohx is given that copyright is by permission ofthe ACM, inc. 7‘0 copy otherwise, to republish. to post on servers or to redistribute lo lists, requires specific permissionand/or fee. GROLJP

97 Phoenix Arizona

Copyright1997

ACM

US4

O-89791-897-5/97/1

1..$3.50

204

display is largely determined by the winclowing/operoting system of the host, e.g. MacOS and WindowsNT. The Common Desktop Environment (CDE) that makes applications running on UNIX systems portable and easy to use is a relatively recent commercial development (11. Alternatively, there is Tkl?esk [Z], a public-domain desktop and file manager for Unix and X written in Tcl/Tk. However, none of the current desktop environments directly provide GUI capabilities for Internet-based desktop computing, with data and applications distributed on different hosts. The Internet-based ReubenDesktop environment described in thii paper has been driven, to a large extent, by the requirements of a user-reconfigurable and collaboralive workflow environment, whose goal is to introduce and to support collaborative peer-reviewed benchmarking experiments in EDA (Electronic Design Automation) on the,lnternet. Since this work started before the advent of JAVA [3], the current prototype is written in Tcl/Tk [4]. Features such as rendering the desktop collaborative as well as recordable, have evolved as a byproduct of the current approach [5, 6, 71. Formalized descriptions of workflow modeling concepts, architecture, and implementation are still evolving, e.g. [B]. Many are application-specific rather than generic. Our approach expands on the attributes of the design control language deco1 [9] devised to deal with a large number of data files aa programs aa applied to integration of a large number of external tools into a comprehensive VLSI design system [lo]. Some aspects relate to the work in the area of design methodologies and design frameworks such as [ll, 12,13,14]. However, this research predates the challenges and opportunities that have arisen with the Internet. We argue that one can view the simple drag-and-drop of a data icon onto an application icon as one of the simplest cases of an executable workflow. In our formal notation, we will have created a directed graph of three nodes: an input data node driving an application (or a program) node, which in turn drives an output data node. In the most general case, nodes may reside on three hosts, thus edges from one node to the other also signify data transfers between the hosts, according to some Internet protocol. The Internetbased desktop environment as defined in this paper consists

DataBasket. Here, SimpleText is a text editor; to be used by the Archivist to document the contents of archive. Task 4: Select flies on Venus and on Mars and drag-anddrop them into the DataBasket. Click on SimpleText to create a 97-ReadMe file about the current archive, saving it in the DataBasket. Task 5: Drag-and-drop the DataBasket onto DropStuff to create DataBasket. sea, a compressed archive of all files on the desktop. While each of the tasks described above is simple to do, the user may forget details about the use of Chooser, forget to create and include a ReadMe file for the archive, or the application DropStuff could have been moved to an obscure location, delaying the completion of Task 5.

of a cross-platform browser, a number of server icons (host nodes), a number of application icons (program nodes) and a number of data icons (file nodes). In contrast to typical desktops of today, where data icons may be dragged and dropped onto application icons for’execution, this environment allows . user-defined’ and reconfigurable execution sequences by creating dependency edges between program nodes (application icons) and file nodes (data icons); . data-dependent execution sequences by dynamic scheduling of path as well as loop executions; . host-transparency as to the location of applications and data (both can reside on any host with a unique IP address). The paper is organized into the following sections: (2) motivation, contrasting drag-and-drop fiatures on a MacOS desktop with ones expected in an executable workflow; (3) Internet desktop environment, a user’s view in the context of the executable 9nternet:based workflow; (4) Internet-based workflows, librarian’s and scheduling views; (5) Collaborative desktop environment; (6) summary of 450 Internet-based experiments using ReubenDesktop; and (7) conclusions.

In this paper, we propose to organize the desktop into any number of user-configured executable workflows, where the browse, click, and select-and-drop features are the simplest primitive operations. For example, rather than manipulating an error-prone manual ArchivistFlow described above, the user will ,create an executable ArchivistFlow, as shown in Figure 3, not only by archiving set-up configurations of all icons on the current desktop, but also by introducing decision icons and creating visible dependency edges between data, application, and decision icons. An internal view of these dependencies -Gil create a schedule to ezecute the userselected workflow from the desktop. The distributed desktop environment as described in this paper addresses and removes the limitations (l-4) described above - while also rendering it collaborative and recordable [5, 6, 71.

MOTIVATION Typically, a user customizes the desktop environment by arranging a number of application icons (program nodes) and a number of data icons (file nodes) to execute some of the repetitive click and drag-and-drop tasks.Whilepowerful, this approach has limitations: (1) there is a limit on the number of icons one can put on the desktop before it becomes cluttered and confusing to use; (2) a typical user cannot readily combine the sequence of click and drag-and-drop steps into data-dependent executable workflows of multiple applications; (3) a particular desktop configuration, customized for a project, A, cannot be saved before customizing the desktop for a project B. (4) current desktop environments have been designed for stand-alone use and do not readily support the notion of a distributed, as well as collaborative desktop environment. Specifically, we use the MacOS desktop environment to discuss an example of simplified tasks that must be performed when archiving documents from two remote hosts Venus and Mars onto the user host Jupiter. We refer to this collection of tasks as a manual ArchivistFlow, described next. Task 1: From the desktop menu, select Chooser to locate two servers on the AppleTalk, Venus and Mars, and create the server icons on the desktop for each. Move the icolis to the left-most corner of the desktop for legibility. Click on Venus and Mars to open browser windows on each server. Task 2: Create a desktop folder called DataBasket to the right of Venus and Mars. Click on DataBasket to open a browser window (at thii point, the folder is empty). Task 3: Find and move application icons DropStuff and SimpleText onto the desktop and place them under

INTERNETDESKTOP ENVIRONMENT The Internet desktop environment proposed in this paper expands on the concept and the architecture of an executable distributed workflow REUBEN [S]. The major desktop components, all written in Tcl/Tk, are: (1) ReubenDesktop (2) OmniBrowser (3) WorkJowManager (4) ObjectDefinition templates (5) Workflow libraries

Since the notion of an executable workflow is central to our definition of the Internet desktop, we discuss it first, fol1owe.dby an example that illustrates the functionality of the ReubenDesktop and OmniBrowser. The remaining components are discussed in the section following this one. Executable workflows. One can view the simple dragand-drop of a data icon onto an application icon as one of the simplest cases of an executable workflow. In our formal notation, we create a directed graph of three nodes: an input data node driving an application (or program) node, which in turn drives an output data node. All nodes can reside on three hosts, thus edges from one node to the other also signify data transfers between the hosts, according to some Internet protocol.

205

Fig. 1. Internet

desktop (start-up

view).

In general, the workflow is displayed as an executable directed hypergraph, with nodes representing programs and data, and hyperedges representing data-to-program, program-to-data, data-to-data, program-to-program dependencies. 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 workflows of data and program nodes. Workflow transformations to Petri nets give rise to (1) a canonical, and (2) an executable Petri net representation; the latter generates the schedule of the workflow execution. Unliie the acyclic ’ workflows discussed most frequently, the workflows we implement are general: they can have loops and decision nodes, and execute program nodes in parallel. Given a library of program and data nodes, reconfiguring workflows is as intuitive as editing a hierarchical netlist schematic. Template editors encapsulate programs and data, such that semantic consistency of the workflow is maintained. Details about the Internet protocols and security are hidden from the field user. By highlighting a data node, the user can select/view/edit from a displayed list of files associated with the particular data node. Premises. The Internet-based workflow provides .a basic primitive for the user-defined and dynamically reconfigurable desktop environment: (1) user decides on the desktop organization and clarity of purpose by invoking a subset of user-defined worHows for the specific tasks at hand;

Fig. 2. Internet

desktop (browsing/selecting/dropping).

(4) the user-defined workflow-based desktop can be intcrchangeably used as a stand-alone distributed desktop as well as a collaborative and recordable desktop environment (5,6]# ReubenDesktop. Upon invocation of ReubenDesktop, the UserDesktop window within the ReubenDesktop contains only the OmniBrowser. Through the browser, user selects and moves to the desktop any number of pre-configured workflows. A single hierarchical workflow may support various tasks related to a typical project. Menus File, Library, Utilities associated with the ReubenDesktop support functions such as printing, creation of new library objects, etc, Applications of utilities, collaboration, playback, and rccording, are described in greater detail in the [6, 71. An example of the start-up

view of ReubenDesktop and

OmniBrowser is shown in Figure 1.

OmniBrowser. OmniBrowser is a powerful utility to travers’e and browse not only the local file system but also tha file system of a remote site. The browser operates in eithor one of two modes: User-invoked. In this mode, user can perform simple tasks such as navigating the file systems, copying, moving, viewing or editing a selected file, etc. The file systerns can be local

or

remote.

Application-invoked.

(2) user combines the sequence of click and drag-and-drop steps by constructing data-dependent and executable workflows of multiple applications;

In this mode, the browser is customized by the calling application, enhancing the features of its user-invoked mode. At any time, user may choose to toggle between the two browser modes.

(3) a particular desktop configuration, customized for a project A, is a project-specific workflow that can be saved for re-use before customizing the desktop for a project B.

Figure 1 shows the pull-down menu options available in OmniBrowser: File, Utilities, Filter Objects, Preferences and Help. The calling application customizes the Filter Objects

Fig. 3. Internet

desktop (executing the Archivist

menu. In Figure 1, the Filter Objects menu has been customized by invoking the ReubenDesktop, hence the listing of the following classes of objects: decisions, files, hosts, programs, recordings, scripts, teams, and workflows. The selection/deselection of Filter Objects allow the user to dynamically control the display of directories and files. Desktop browsing, selecting, and dropping. A user invokes a workflow for a specific project such as one shown in Figure 2. This workflow consists of two nodes:

workflow).

follows: (1) It prompts the user to specify the location for archival. If the user-specified directory does not exist, it creates one. (2) It queries the user whether to create a README for the archival data. (3) If the user’s response is yes, then it invokes a text editor for editing the README file. (4) Finally, it compresses the data set for archival.

(1) a remote host browser, which enables the user to browse the directory structure of the remote host, and (2) a hierarchal ArchiwBt workflow, which is periodically used to archive a set of related data at a specified location. A user who decides to archive a set of data, part of which may be on the local host and the remaining part on the remote host, selects the pertinent data with the mouse and drops it onto the Archivist workflow node. This results in automatic expansion of the Archivist worldlow into various nodes encapsulated within it, followed by its execution. Workflow execution from the desktop. Figure 3 shows a full view of the Archivist workflow. It consists of several types of nodes: ovals represent data nodes, rectangles represent program nodes, yes/nd rectangles are decision nodes. Whenever a user drops a set of selected data file on the Data Basket, it triggers the execution of the entire workflow as

207

Thus, all the above steps, performed manually one after another on a traditional desktop, are executed in a predefined sequence as a single task here. In addition, since it is possible to open remote host browsers, this workflow has the added capability to selectively archive data located anywhere on the Internet.

INTERNET-BASED WORKFLOWS Workflows depicted in this paper generalize not only the functionality of traditional desktops, by allowing users to create and work on multiple desktops simultaneously, but also utilies the capabilities offered by the Internet to bring together distributed resources to the user’s desktop As such, we perceive three different views of workflows: (1) user view (2) librarian’s view (3) scheduling view

I

Uwr’s

LcqhId:

)gwst

:Telmt

fkidrea:

jdi

kTP

l3cawss:

ac&bl,~.edu ac,cbl.ncru.ecil

jmng

dlrcctory:

~Vcrb

dsscrrptim:

/hcme/gueet/r~/uotk

Fig. 5. HostManager window. and DatafileManager windows.

Fig. 4. ProgramManager

A typical user is mostly concerned with the user view of the workflow. This has been described in detail in the previous section. On the other hand, it is the job of the librarian to create, maintain and support various workflow objects. The scheduling view is a formalization of the workflow necessary for its successful execution’. Librarian’s View. The organization of the workflowrelies on several classes of objects: data file nodes, program nodes, decision nodes, hierarchical workflow nodes, script nodes, host definitions, team definitions and recorded sessions. A workflow library consists of distinct directories corresponding to each object class. All f&s pertaining to a common object class are located in their respective directories. Workflow libraries are of several types: . libraries provided by ReubenDesktop, . site-specific libraries maintained by system users, . group-specific libraries created by brainstorm users, . personal,libraries, created by field users. We next briefly describe the elements used in defining a few of the object classes, such as program node, data file node and host template. Figure 4 shows the snapshot of a ProgramManager and DatafileManager. Whereas both windows contain common entries such as directory location and host name, DatafileManager has a special entry for specifying file matching pattern and ProgramManager has entries for specifying the command-line arguments and a graphical workspace area. This graphical area is used to add data nodes and specify input/output dependencies in relation to the program ‘Our

perception

we describe The

nominal

so he/she flows.

workflow

The workflow

of users.

as constructed can be executed

librarian

library The

is different from those in [S]. Informally, likely perceived

in terms

of their usage.

to know the functionality

of the menus

edit, and execute

of various

an expanding

variety

user needs

can configure,

and properties tain

of workflow views

views as they are most

needs to know additional

node

configuration

of useful

workflow

from the objects as anticipated

any number

objects

architect

windows that

of task-specific

work-

details such as menus go he/she

can main-

are likely to be used by a

needs to ensure that the workflows

in the library

are semantically

correct and

by the user.

208

Fig. 6. Internet

desktop (search/retrieve

archived data)

node, by creating links of appropriate dependency type. Host definition editor is used for providing information about the host for the remote execution capability of tho workflow. In addition, all other information, such as user’s login, working path, etc. (other than password) are also specified in thii template. Scheduling View. A user-generated workflow, although simple to create, does not always ensure successful exccution. Thii may be attributed to the complex nature of tha workflow which may include cycles and decision nodes in addition to the fact that it may be concurrent, asynchronous, and distributed. We use petri nets to model workflows and provide systematic transformations for deriving firing schcdules for its execution [5]. Consider the OmniGrep workflow shown in Figure 6. OmniGrep workflow is useful for searching a data file from

the archived lit which contains the specified keyword. The steps required to perform such a search are as follows: (1) copy first archived data from the list to /tmp, (2) uncompress and untar the copied archival data, (3) search for the specified string in all the data files, (4) if the specified string is not found, redo the above steps for next archived data in the list, (5) return the archival data when the string is found. These steps include primitive

components

(a) Alice’s desktop

(b) Bob’s desktop I

I

of a workflow

such as decision nodes and cycles. Hence, before executing

such a workflow, it is transformed into canonical and executable Petri net model. The corresponding firing schedule is shown in Figure 7.

(c) A two-participant

collaborative

Fig. 8. Contrasting stand-alone tive desktop environment.

Level

0fPch-i

net fmnsifion

~0~1~2(3(4(6(6(7(8~9~10~11

Fig. 7. Firing schedule of an executable Petri net.

COLLABORATIVEDESKTOPENVIRONMENT Internet-based workflows described in the previous section provide a single user with a powerful desktop capable of efliciently utilizing the resources available on the Internet. However, it is still not capable of handling issues related to several users working on the same project. We, therefore, further extend the functionality of our Internet-based desktops by rendering them collaborative. In our view, a collaborative environment is an extension of a cooperative environment. We argue that a measure of quality and control of the cooperative environment can be related to how effectively it supports collaboration. For example, in the context of a cooperative desktop, two users may (1) share a desktop and thus have a common view of all of the objects on the desktop, and (2) each user has exclusive ownership and control of the appearance, location, and contents of some of these objects. Each user can (1) observe the other user manipulating accessible objects, and (2) react by making adjustments to their own objects. One may argue that such an arrangement supports some measure of coIlaboration as well, in the context just described. However, in the context of thii paper, a desktop is wllaboratiue only once each user is given the capability to pass control over their own environment so that the other user can also manipulate

209

desktop

desktops with a collabora-

desktop objects not accessible in the cooperative desktop environment described earlier. We motivate the discussion further by contrasting the features of a stand-alone with a collaborative desktop followed by postulating a set of properties that define a collaborative desktop environment and presenting a user view. Stand-alone Desktop. Consider the example of two standalone desktops Figure 8(a) and (b). These desktops be long to two architects, Alice and Bob. The arrangements of applications and icons on both desktops rue similar: both use the icons to access the web, e-mail, or move data to trash. To meet their writing and drawing needs, Alice is using FrameMaker, Bob is using LaTex and XFIG. Judging from the respective workspaces, both are engaged in designing the floorplan of a house: Alice seems responsible for the first floor, Bob for the basement. Assuming that they are designing the floor-plan for the same house, the design as it stands has an obvious error: positions of staircases on both floorplans are grossly mismatched. There can be several reasons why this design has an error: 1. incomplete design specifications; 2. oversight or misinterpretation of design specifications; 3. inadequate frequency of design reviews and consultations during the design process. Collaborative Desktop. One can argue that the time to detect an error such as illustrated in Figure 8(a) and (b) could be significantly reduced if Alice and Bob were to work in an environment that supports Pl: replication of desktops, so that each participant can observe desktop actions of the other in the context of the joint design project;

7j

Fig. 9. Typical user views in a multi-user

enviro-n,Tent, we can achieve and maintain the generic properties Pl-P3 of the collaborative desktop environment using Tcl/Tk. The Internet-based desktop environment has User View. been rendered collaborative by the addition of a FlowSynchronizer that provides both the communication channels between collaborating participants and a control passing mcchanism. Just as the collaborative desktop example in Figure 8(c) maintains the properties Pl-P3, so does the collaborative desktop example in Figure 9. Instead of stand-alone applications such as XFIG, FrameMaker and trash in Figure 8 we now have a workflow of applications in Figure 9, The functionality of talk window and locked checkbox has beon replaced with the FlowSynchronizer. Figure 9 shows two windows that are multi-cast simultaneously to all participants: an example of a Partitioning Workjlow and a FlowSynchronizer. The FlowSynchronizer can support n collaborating sites, providing controlled access to two window segments at each site: (a) a token button designating the UserSite, and (b) a message box which provides a real-time conferencing environment. At any time, one and only one site is designated as a TokenHolder, by coloring its UserSite button in a color different from all other sites. At any time, each collaborator can transmit text in the message box to all other sites. However, only the TokenHolder has the capability to click on another UserSite button to pass the token, and hence the control of the entire environment, including any application and data displayed in the workflow window. The Patiitioner Workjlow in Figure 9 is a snapshot of a collaborative session in progress. Three design specialists, User1 at Hostl, User2 at Host2, and User3 at Host3 are working together towards partitioning and optimizing circuits on a newly available device library. The session has been initiated

P2: additions of individual channels of communications, so each participant can alert the other to design inconsistencies; P3: mutual controls and a relationship of trust among participants, to the extent that each gives the other permission to rearrange’and modify objects on their own desktops - for the sake of expediency and to leverage the unique expertise of each participant. Properties Pl-P3

collabora

define a Collaborative Desktop Environ-

ment in this paper.

A conceptual representation of the environment with properties Pl-P3 is shown in Figure 8(c). In contrast to Figure 8(a) and (b), the desktop environment in Figure 8(c) is collaborative: Alice and Bob can now observe not only the workspace of each other along with the application icons such as FrameMaker, XFIG, and trash that each will use to manipulate the floorplan, but also their own assigned talk windows where both can post alerts and requests to each other. Finally, each can indicate to the other the status of permissions in their workspace - by clicking on the locked checkbox in their own talk window. For example, if Bob unchecks hi locked checkbox, Alice can expediently m-arrange the floorplan of the basement and correct Bob’s placement of the ‘staircase’ to m’atch her first-floor plan. Upon making the corrections, she will return Bob’s checkbox to its former locked checkbox status so that Bob can regain control of his workspace. It is easy to conclude that the collaborative desktop as shown in Figure 8(c) will reduce design errors or catch them early in the design process, thereby significantly enhancing the productivity of the team effort. We show next, in the user view, that by generalizing the concept of a collaborative desktop environment such as illustrated in Figure 8(c) to a collaborative Internet-based desktop

210

by Userl. Upon invocation of the Partitioner Workflow, all the users receive an identical view of the Partitioner Workflow, along with the FlowSynchronizer, while User1 additionally gains access to the application. User1 selects the new device library and requests User2 to partition her &c&s and passes the control of the application to her. On gaining access to the workflow, User2 mod&s initialization variables, selects the partitioner node, executes the workflow and passes on the control to User3 for optimization of the circuits. User3 selects the optimizer node which is a hierarchical node and modifies logic optimization parameters. Upon execution, this node expands into a workflow of its own, to perform a series of optimization tasks. However, User3 realizes that the optimization process was not successful and that the circuit needs to be re-partitioned with changed parameters by User2. Hence, he passes the control back to User2. In this example, the collaborative desktop environment allows the three users located on different hosts; to work together on a design problem. By passing the control of the application several times among themselves, they arrive at an acceptable solution in much less time than would otherwise be possible.

EXPERIMENTS The prototipe described in this paper is one of the Internet-based desktop environments that will be put to the test as an integral part of a national-level collaborative and distributed design project involving teams at 8 sites (http://www.cbl.ncsu.edu/vela/). The 450 experiments, summarized in this section, are the initial part of the Internet desktop environment performance and functionality evaluation, conducted before its release to Vela Project participants and others. Each of these experiments relies on interactive user inputs. To maintain consistency of user inputs during the repeated trial executions across the Internet (with variable quality-ofservice), wb first record a single reference instance of each test case on the local server (without relying on the network) and then move these recordings to cross-state and cross-continent servers on the Internet. Each server has an executable version of ReubenDesktop and the experiments are initiated with a playback that executes recorded instances of test cases, multicasting them to 1, 2, or 3 workstation displays at CBL. Technical details about the ReubenDesktop that address multicasting, collaborative team set-ups, recording and playback are given in [5,- 6, 71. Experiments reported in this section support a conjecture that will be the subject of more detailed experimentation later: Task-specific performance server ReubenDesktop under

of a single/mulGple clientexecution can be predicted,

comparable server

measuring

and network loading, by

the performance

of pre-recorded

task-

specific experiments that are executed and~mul&cast by the server to one/multiple

client displays.

211

In other words, to assess the performance of interactive distributed sessions that involve one or more participants, we have verified that the experiments, as reported in this section, can be extrapolated by measuring the performance of single- and multi-cast executions that are based on playback of pm-recorded experiments on a reference server. The benefits of not requiring a number of individuals to sit through repeated session experiments are obvious. Specifics about the testbed configurations, test cases considered, and tabulated results follow. Testbed Configurations. In order to approximate typical instances of a distributed multi-site collaborative desktop environment, we have created: (1) local environment by installing the desktop software on a CBL server2 which is multi-casting its desktop to one or more CBL client hosts; (2) cross-state environment by installing

the desktop software on a server3 at Duke University in Durham, NC, which is multi-casting its desktop to one or more CBL client hosts; and (3) cross-continent environment by installing the desktop software on a server4 at the University of California in Berkeley, CA, which is multi-casting its desktop to one or more CBL client hosts. Test Cases. We have created &nd recorded, directly on the CBL server under negligible loading conditions, six test cases with useful attributes that demonstrate typical user-invoked tasks. The brief description that follows includes tde reports of real-time, user-time +nd system-time as produced by the Unix utility time. The ‘real-time’ corresponds to the ‘stopwatch-time’ that could have been obtained by the user monitoring the task. The ‘use&me’ is the time required by the CPU to complete the task. The ‘system-time’ is the CPU time required by the system on behalf of the task. The ‘real-time’ corresponds to the time required to record each session. When played back on the same server, ‘real-time’ is consistently 3-4 seconds less than the time required to record. The constant difference is related to the saving of the recorded data by the user. Both ‘real-time’ and ‘user-time’ will vary during playback and multi-casting - depending on the CPU-profile, the state of the network, the relative distance and the number of client workstation displays. A brief description of all test cases, that were recorded for the experiment, follows. (1) Editing-l (real&me=15.3s, userfime=6.0s, .systern-time=0.6s): Using ReubenDesktop, we open, and edit, a simple 4node, 3-arc workflow by selecting, opening, and closing a single data file node-configuration window. (2) Editing-8 (real-time=22.Os, user-time=d.b, systern-time=O.gs): Using ReubenDesktop, we open, and edit, the same Cnode, S-arc workflow by selecting, opening, *SUN

SPARC

20 (chip=GOMHz

%UN

SPARC

Ultra

4SUN

SPARC

20 (chip=GOMHz

memory=64Mb

1 (chipd67MHz

swapc732Mb)

memory=256Mb

memory=96Mb

swapz268Mb)

swap=365Mb)

I

TABLE SUMMARY OF 450

SWVer

Real Tim@ CPU

CBL

Reference

Operation

Ret

Pbk*

Time=

m .. . .

lxJrr,ng-1

Usr 15.3

.

11.9

Usr

Max sys

Min

Max

Usr

sys

Min Usr

2-clients

Max

Min

sys

Max

Usr

sys

UCB 3-clients Min

Max

Usr

sys

l-client Min Usr

Server

l-clients

Max sys

Min Usr

3.cllonts

Max sys

Mln

Max

Usr

sys

12.0

13.9

25.5

27.1

30.2

31.1

15.7

16.8

26.9

31.2

35.3

37.6

23.5

24.1

46.0

46.9

58.3

3.4

0.8

15.3

0.7

19.7

0.8

1.9

0.5

8.2

0.5

10.2

0.6

3.2

1.1

14.6

1.0

17.8

1.2

18.6

36.1

37.6

42.7

44.3

23.2

25.0

40.0

42.1

49.7

52.1

31.2

31.9

59.7

60.3

75.7

76.4

59.3

18.2 4.7

0.8

22.7

0.8

28.2

1.1

2.7

0.5

12.2

0.7

14.9

0.9

4.6

1.2

21.1

1.2

26.1

1,5

45.6

42.6

43.5

44.8

71.8

91.7

80.2

84.3

47.9

49.2

70.1

73.8

75.2

79.3

60.3

61.4

99.0

100.0

117.4

120.5

13.1

1.1

43.3

1.4

50.9

1.6

27.1

1.1

46.9

2.0

11 27.8

23.1

11 23.4

31.5

1 51.9 37.4

54.3 1.4

92.7 79.8

104.3 3.4

136.2 116.5

139.5 2.0

minimum

*Recording

sys

Min

l-client

18.1

Editing-3

OBoth

Max

Duke Server Pclients

22.0

Editing-2

I

Server

2-clients

l-client Min

EXPERIMENTS PERFORMED ON THE INTERNET AMONG THREE SITES.

and maximum

time

COnly werage

values of ‘real-time’

is larger than playback

values of ‘user-time’

7.2

0.7

22.2

0.9

WA

24.5 0.8

28.1 0.4

32.3 3.5

33.7 0.6

WA

66.p 1.0

67.9 0.5

74.4 4.3

75.6 0.6

WA

115.5 55.3

120.0 2.8

136.0 101.7

140.2 1.1

1.6

39.5

WA

33.8 0.9

48.9 5.7

50.5 1.1

1.13

WA

WA

74.4 1.9

74.8 0.9

93.9 7.1

95.3 1.2

N/A

WA

139.5 35.3

179.6 3.4

168.6 103.9

223.3 2.7

WA

,

are reported.

time due to overhead

and ‘system-time’

12.8 32.9 1.4

in saving the recorded

data.

are reported.

From each of the three servers, execute and multi-cast IO-times, with interval of 30 seconds between each execution: (1) successively to one, two, and three client hosts at CBL, recordings of editing-l, editing-2, editing-4 (2) successively to one and two client hosts at CBL, recordings of browsing-l, browsing-b; (3) successively to one and two client hosts at CBL, recording of execution-l. A log file, generated by time (real-time, user-time, system-time) command, archives timing data for each expcriment. Similarly, a log fle, generated by sar (system activity report) command, archives the load on each of the three servers during the execution of these experiments. The log file generated by sar provided the information whether or not both the load on the server and the network was sufllciently stable to accept the ‘real-time’ and ‘user-time’ results for tabulation. Table I summarizes results of these experiments as follows: (1) The first column lists all the six test cases described earlier. (2) The second column reports two values for each test case. The value on the left under Ret corresponds to the timo required to record the example on the reference server and the value on the right under Pbk corresponds to the playback time on the same server. (3) Each cell in the remaining columns contains four values. The top two entries report the minimum and maximum values of ‘real-time’ and the bottom two entries report tho average values of ‘user-time’ and ‘system-time’ for each oxperiment. Summary of Results. The data presented in Table I allow5 us to evaluate the performance of Internet-based desktop environments. 1. The ‘real-time’ for playback on the reference server is consistently 3-4 seconds less than the time required to

and closing a single data file and a single program nodeconfiguration windows. (3) Editing-3 (real-time=45.6sJ userfime=20.2s, systern-time=O.gs): Using ReubenDesktop, we open, and edit, a 17 node, 22 arc workflow in Figure 6 by selecting, opening, and closing three data file and a single program nodeconfiguration windows. (4) Browsing-l (realfime=27.8sJ userfime=10.6sJ systern-time=1.2s): Using OmniBrowser, we traverse a directory structure, located on the server’s local file system, across 3levels, with up to 141 items in each directory. The directory structures of all the three servers were made exactly the same for uniform comparison. . (5) Browsing-2 (real-time=68.0sJ user-time=39.8sJ systern-time=2.9s): Using OmniBrowser, we select, open, and scroll, from start to end, the same copy of a text ille of about 1000 pages (2.2Mb), located on each server. (6) Execution-1 (rea14ime=123.9sJ userfime=90.0sJ systern-time=3.8s): Using ReubenDesktop, we open, and mecute, the hierarchical worktlow in Figure 9. As shown, the workflow has 22 nodes and 28 arcs; during execution, the node labeled as optimizer expands into a sub-workflow with ~14 nodes and 15 arcs. As shown in Figure 9, the workflow engages three collaborating partners via its FlowSynchronizer window. As with all other test cases, execution of this workflow has been recorded in a single user-mode only. The additional cost of broadcasting the site-specific FlowSynchronizer window, not executed for the recording for reasons of generality, is negligible.

Evaluation Method. All software and the files of six test cases, recorded directly on the CBL server, have been replicated on the server at Duke U. and the server at UCB. Scripts have been invoked, during the night when both servers and the network were least loaded, to execute the 450 experiments as follows: .

212

.

2.

3.

4.

5.

record the test cases. The constant difference is related to the extra time required for saving the recorded data. The ‘real-time’ for playback from other servers varies, depending on the distance between the host server and its clients. Specifically, the experiment Editing-i takes about 12-15 seconds to execute on the CBL server for l-client, the same experiment takes about 15-17 seconds on the Duke server and 23-24 seconds on the UCB server. When the experiment is multi-cast to 2-clients, it takes about slightly less than two times the time required for single client execution. For J-clients, the execution time increases by approximately a factor of 2.5. The variations in minimum and maximum values of ‘real-time’ for each experiment are negligible since the experiments were performed during the night. However, the same experiments showed significant variations during the day when the network traffic and the server load is unpredictable. Comparing the ‘user-time’ and the ‘system-time’ for each server, we find that the CBL server requires the most CPU time and the Duke server requires the least CPU time. This follows directly from the different types of processors and the configuration of each server.

results demonstrate that the environment can support realtime collaboration among peers who are distributed across the continent, allowing them to devise effective and efficient solutions that may not be practical otherwise. ACKNOWLEDGMENTS. We could not have reported as comprehensively on the results of our Internet Desktop experiments without getting generous user accounts on two remote servers, facilitated by Dr. Richard Newton at UC Berkeley and Dr. Gershon Kedem at Duke U. We thank them and their support staff for thii privilege. REFERENCES

[II

The Common Desktop Environment

Technical Library. Published

under URL: http://wu.av.com/devpress/saries/cde.htm,1997.

PI

Christian Bolik. Tkdesk.

Published under URL;

http://sunl.rrzn-user.uni-hannover.de/-a~ibol/tkdesk/,l997. 131 The Java Home Page. Published http://java.snn.com/, 1997.

under URL:

141 The Tcl/Tk Project At Sun Microsystems lished under URL:

[61

1997.

Also

available

at

Amit Khetawat. Collaborative Computing on the Internet. Master’s thesis, Electrical and Computer Engineering, North Carolina State University, Raleigh, N.C., May 1997. Also available at http://snnr.cbl.ncsu.edu/publications/.

171 H.

Repeated real time executions of experiments, where user-inputs are carefully and consistently entered (rather than prerecorded), gives ‘real-time’, ‘user-time’, and ‘system-time’ performance that is comparable (within 10%) of the times reported for pm-recorded execution on any server - provided that the server load and network conditions are as favorable. The performance of the Internet-based desktop environment, even in a collaborative mode, is quite good under nominal network traffic and load on the server. Hence, with sufficient network bandwidth and powerful processors, it is possible to work collaboratively with efficiency and effectiveness even when participants are’dispersed across the continent. As the number of clients, corresponding to each participant, increase from 1 to n, the ‘real-time’ execution does not increase by n times, but less than n times. Again, this increase is subject to the server and network performance.

Pub-

http://rmv.sualabs.com:80/research/tcl/,1997. F. Brglez, and K. Kozminski. 151 H. Lavana, A. Khetawat, Executable Workfiows: A Paradigm for Collaborative Design on the Internet. In Proceedings of the 34th Design Automation Conference, June http://vvv.cbl.ncsu.edu/publications/.

Observations. The successful completion of all 450 experiments provides us with assurance that the experiments are consistently reproducible on a variety of servers, given that the server nominal load is small and that the network is staSpecifically, we confirmed that

Laboratories.

Lavana,

User’s

A.

Guide.

Khetawat, CBL,

and

F.

Brglez.

IV,

NCSU

REUBEN 1.0 Centennial Cam-

NC 27695.,

1997.

Also available

Research

pus, Box 7550, Raleigh,

at

http://vua.cbl.ncsu.edu/publications/.

[81

S. Jabionski and C. Bussler. Workflow Management Modeling Concepts, Architecture and Implementation. Thomson Com-

M

K.

puter Press, 1996. Kozminski.

Technical

Report

Design

Control

1991-TRQMCNC,

for

a

Silicon

MCNC,

Compiler.

P.O. Box 12889,

Research Triangle Park, RTP, NC 27709, January This report is now available as a postscript file

1991. under

http://www.cbl.ncsu.edu/publications. K. Kozminski. OASIS 2.0 User’s Guide. MCNC, Research

PO1(Ed.)

‘Triangle Park, NC. 27709, 1992. (Over 600 pages, distributed

PY

to

over 60 teaching and research universities worldwide). D. S. Harrison, R. A. Newton, R. L. Spickelmier, T. J. Barnes. Electronic CAD Frameworks. 1081, February 1990.

Proceedings

of

IEEE,

78(2):1062-

WI J. Daniel1 and S. W. Director. An Object Oriented Approach to CAD Tool Control Within a Design Framework.

IEEE

‘I’mnaac-

tiona on Computer-Aided Design, 10(6):698-713, June 1991. A. Casotto and A. Sangiovanni-Vincentelli. Automated Design P31 Management Using ‘Dates. IEEE Transactions on ComputerAided Deaig?, 12(8):1077-1095, August 1993. 1141 J. B. Brockman and S. W. Director. The Schema-based Approach to Workflow Management. IEEE fianaactiona on Computer-

CONCLUSIONS With ReubenDesktop, we have demonstrated a new paradigm to support peer-to-peer communication and control of distributed software and computing resources over the Internet. Rendering the desktop collaborative and recordable is a natural extension of its original architecture. Experimental

Aided Design, 14(10):1445-1267,

213

October 1995.