**Status: November 1998**

**Notes of the 1^st^ International Workshop on**

\"Desktop Access to Remote Resources\"

Java Grande Working Group on Concurrency/Applications

http://www.javagrande.org

and

Argonne National Laboratory, MCS Division

http://www.mcs.anl.gov

Meeting Web Site and Location

http://www-fp.mcs.anl.gov/\~gregor/datorr

Argonne National Laboratory

Building 221, Room A-261

October 8-9, 1998

Editorial Contact: Gregor von Laszewski, <gregor@mcs.anl.gov>

The list of participants and contributors can be found on the Datorr
website and

will be included upon completion of the report.

# 

# Table of Contents

Table of Contents [2](#table-of-contents)

Meeting Notes to the "1^st^ Workshop on Desktop Access to Remote
Resources\"
[3](#meeting-notes-to-the-1st-workshop-on-desktop-access-to-remote-resources)

Working Group Summaries [4](#working-group-summaries)

Working Group 1: [4](#working-group-1)

User/Application view of the System Architecture
[4](#userapplication-view-of-the-system-architecture)

Definitions: [4](#definitions)

User Scenario: [5](#user-scenario)

Working Group 2: [6](#working-group-2)

The Interface to desktop access: the Metacomputing API
[6](#the-interface-to-desktop-access-the-metacomputing-api)

Fundamental Abstractions [6](#fundamental-abstractions)

Services [7](#services)

The Service API s [7](#the-service-api-s)

Working Group 3: [8](#working-group-3)

Secure Desktop Access to Remote Resources
[8](#secure-desktop-access-to-remote-resources)

Project Descriptions [9](#project-descriptions)

Akenti -- A Distributed Access Control System
[9](#akenti-a-distributed-access-control-system)

Arcade: A Web-Java Based Framework for Distributed Computing
[10](#arcade-a-web-java-based-framework-for-distributed-computing)

CPU-Usage Monitoring with DSRT Sytem
[10](#cpu-usage-monitoring-with-dsrt-sytem)

Distributed Resource Management for DisCom2
[11](#distributed-resource-management-for-discom2)

Condor [11](#condor)

EveryWare [12](#everyware)

Globus: The Globus Grid Computing Toolkit
[14](#globus-the-globus-grid-computing-toolkit)

Globus^J^ [14](#globusj)

Habanero [14](#habanero)

Harness: Dynamic Reconfiguration and Virtual Machine Management in the
Harness Metacomputing System
[15](#harness-dynamic-reconfiguration-and-virtual-machine-management-in-the-harness-metacomputing-system)

IceT [15](#icet)

JINI [16](#jini)

Legion System Architecture [17](#legion-system-architecture)

NCSA Workbench Project [18](#ncsa-workbench-project)

Northrhine-Westphalian Metacomputer Taskforce
[19](#northrhine-westphalian-metacomputer-taskforce)

UCLA Java Effort For Collaborative Computing
[21](#ucla-java-effort-for-collaborative-computing)

UNICORE: Uniform Access to Computing Resources
[21](#unicore-uniform-access-to-computing-resources)

WebSubmit: A Web Interface to Remote High-Performance Computing
Resources
[22](#websubmit-a-web-interface-to-remote-high-performance-computing-resources)

WebFlow: Web Based Metacomputing [23](#webflow-web-based-metacomputing)

# Meeting Notes to the "1^st^ Workshop on Desktop Access to Remote Resources\"

On October 8 and 9, 1998 the "1^st^ Workshop on Desktop Access to Remote
Resources" was held at Argonne National Laboratory in conjunction with
the "Java Grande Working Group on Concurrency/Applications".

The term "remote resource" is defined to include:

-   compute/communication resources (supercomputers, networked
    supercomputers and metacomputers, network of workstations, and
    workstations),

-   data resources (databases, directories, dataservices), and

-   compute/communication services (specialized problem solving and
    visualization environments).

This first meeting concentrated on issues related to compute resources.
The goal of this meeting was to

-   collect the most recent information about the status of current
    projects accessing remote resources,

-   derive a strategy on how remote access to resources can be
    supported, and

-   bring the research community in this area together to initiate
    dialog and collaboration..

In the first part of the meeting, short project presentations including
Condor, Globus, UNICORE, Websubmit, Arcade, Webflow, Tango, DisCom2,
Akenti, IGP, and others, gave an overview of the projects in order to
initiate discussions. These discussions were continued during working
group sessions in the second half of the meeting. Three working groups
were defined according to the following topics:

-   "Interface": Defining the interface to desktop access: the
    metacomputing API.

-   "User requirements": Analyzing the user requirements to the desktop
    access.

-   "Security": Enabling a secure desktop access to remote resources.

The working groups tried to identify issues related to the design of an
architecture, which makes a desktop access to remote resources possible.
This included identifying a list of services, which is planned to be
developed in order to enable a seamless desktop access. The working
groups identified four types of user interfaces, which are related to
the "users" accessing a metacomputing "Grid."

-   The End User who wishes to submit a single job, multiple instances
    of a job, access a collaboration or

invoke a Grid based problem solving environment.

-   The System Administrator who is responsible for the installation of
    grid tools and the addition of new resources into the metacomputing
    system.

```{=html}
<!-- -->
```
-   The Developer of Applications that takes advantage of advanced grid
    services.

```{=html}
<!-- -->
```
-   The Owners of the metacomputing resources that comprise the Grid.

The interface-working group identified the need for fundamental
abstractions like tasks and jobs, resources, events, file names and
object handles. It was determined that services like resource services,
accounting, notification and event services, transaction services,
logging services, keep-alive services, collaboration services, and
execution services have to be defined.

The user requirements group focused on identifying services that are
needed by the users. The user requirements were ultimately included into
the services identified by the interface group. A separation between the
graphical user interfaces and the services to support the desktop access
to remote resources were found to be important. Besides the development
of component building tools such as Arcade, Gecco, and Webflow, the
participants viewed the development of shell commands as very important.

The third group focused primarily on issues related to a "secure desktop
access to remote resources." The security group had a short second
meeting two weeks after the workshop to discuss issues related to secure
data exchange, access control, authentication, as well as the need for
simple administration.

During the workshop, it was decided to produce a report to be
distributed at SC98 and available as a technical report from Argonne
National Laboratory. The report contains a summary of the working group
results, as well as, a collection of one-page descriptions of related
projects. We expect the report to evolve over time, so that a
distribution via WWW seems appropriate.

In order to help exchanging ideas, a mailing list (<datorr@mcs.anl.gov>)
is established and a WWW is available
(<http://www-fp.mcs.anl.gov/~gregor/datorr>). The WWW page will contain
future announcements of this group, and is intended as a collection of
resources including the online proceedings of the workshop (currently, a
set of slides presented at the meeting).

Two follow up meetings are already scheduled. The first meeting takes
place as "Birds of the Feather Meeting at SC98", while a second meeting
on the 28^th^ and 29^th^ of January, 1999 takes place at Sandia National
Laboratory, Albuquerque. In the next meeting, we would like to give
other projects the opportunity to present their work. Future
presentations may focus on how components developed by the project can
be reused by other projects and how an integration of technologies
between projects can be achieved. Nevertheless, the main focus of the
meeting should be the discussions in the working groups.

# Working Group Summaries

## 

## Working Group 1:

## User/Application view of the System Architecture

In this section we examine the requirements for distributed access to
remote resources from the perspective of the users. In particular we
describe the various steps that a user might take in setting up and
executing an application which requires both remote and local resources.
Note that we do not discuss the requirements for supporting multiple
users

collaborating to solve a single problem, rather we focus on a single
user only. We first present some definitions and then describe a
scenario from the user\'s perspective:

### Definitions:

#### Resource: 

A resource, represented by a \"resource object\", includes both hardware
and software resources that might be required by the user for the
application. These include, but are not limited to:

\- compute engines, ranging from workstations to supercomputers

\- networks

\- storage devices

\- visualization hardware

\- instruments, e.g., wind tunnels, telescopes, etc.

\- databases

\- application codes and binaries

\- libraries

\- compilers

\- debuggers

\- performance monitors

\- visualization tools

#### User:

We distinguish between at least two different types of users:

administrators/super users and end users. The former are responsible for
the overall maintenance and control of the system while the latter
utilize the resources to solve their problems. In this section we focus
on the end users only. Each user will be represented in the system by a
\"user object\" which will contain all information directly related to
the user.

#### User workspace:

Each user of the system will have a personal environment which will
represent a logical view of the global resources available to the users.
This workspace will include both real and virtual resources which the
user can access. The former includes resources which the user has direct
control over, e.g., the desktop on which he/she is logged on, his/her
programs, data etc. In addition to these resources, the

user may have access to shared resources such as other workstations,
shared file systems, visualization equipment etc. Going beyond the local
environment, the user may have access to other remote resources, such as
supercomputers. The user\'s workspace represents an agglomeration of all
such resources available to the user.

#### Task:

A task, represented by a \"task object\", can be defined hierarchically
as follows:

\- A simple_task consists of the following:

\- a set of data resources (source and sinks)

\- an action to be performed on the data

\- a context in which to perform the action

\- a set of constraints

Here \"action\" is a single unit of work.

Examples of a simple_task are:

\- compiling a code

\- executing a code

\- copying data from one storage unit to another

\- A task is, then,

\- a set of data resources (source and sinks)

\- a set of tasks

\- dependencies between the set of tasks

\- a context in which to perform the set of tasks

\- a set of constraints

#### Job:

A job is an instantiation of a task and is represented by a
\"job_object.\" In other words, a job is generated by binding the
resources required to execute the task including data resources for
input and output and computing resources for executing the actions
embodied by the task.

### User Scenario:

Consider a scenario in which a user is trying to execute an application
to solve the problem at hand. We describe here a set of phases/stages
that the user must go through in order to accomplish the task. We assume
that the problem at hand requires a complex set of

actions executed on several local and remote resources. In the ensuing
description, we focus on the services required by the user at each stage
of the whole process and do not discuss interface issues. We

presume multiple different front-ends can (and will) be built which rely
on the underlying services to allow access to local and remote
resources. Also, note that we focus here only a single user ignoring the
issues of collaboration and cooperation that may arise if multiple

users have to coordinate their actions in order to solve the problem.

#### Login to the framework:

Before a user can start using the resources of the system, he/she has to
login. This requires a authentication process which will establish the
identity and the credentials of the user This process would also
generate a user object to represent the user and store any information
pertinent to the user. We assume that the user will

have a single system-wide \"id\" which will be used for later
authorization to access local and remote resources. This may require
mapping from the id to a local id to utilize resources under separate
jurisdictional domains.

#### Managing the user workspace: 

The user requires mechanisms to manage his/her personal workspace. Thus
the user may want to add new resources, delete resources which are no
longer available and may even want to monitor the current status of the
resources. Such monitoring can be envisioned to be continuous, on demand
or even at user defined significant events.

#### Task construction: 

A task is a complex entity which needs to be specified before it can be
utilized to solve the problem at hand. This process is mainly an
interface issue, i.e., what kind of interface is available to the user
for setting up the task. For example, a script-based system would allow
a

user to specify all the parts on a textual basis. On the other hand, a
visual system would allow cf-users to drag and drop icons representing
pre-defined tasks and connect them graphically to indicate dependencies.
Essentially this construction requires the ability to peruse and load
pre-defined tasks from the personal workspace. The result of

this process is a task object which hierarchically represents the
actions to be performed, their input/output requirements and the
dependencies between these actions.

#### Job submission: 

Once a task has been created, it can be submitted for

execution. The major issue here is resources allocation. Some resources
maybe specified explicitly by the user. For example, the user may bind a
specific data file to an input, or may specify that a particular code be
executed on a specific computing resource. However, we presume that a
major portion of the resource allocation, in particular, the computing
resources will be automatically allocated by

the underlying system. Thus, we envision a matchmaker\" which attempts
to find the \"best\" match between the requirements and constraints of
the task to the capabilities, constraints and the status of the
resources in the personal workspace of the user. Several issues arise in
this process. The definition of \"best\" maybe dependent on the
user/task and maybe a part of the requirements. For example, some jobs
maybe optimized for throughput while others maybe optimized for
performance. Also, the match making process maybe completely static,
i.e., all resources are chosen before the job starts executing. On the
other hand, the process maybe more dynamic in the sense that the
resources for a sub_task are bound only when the task is ready for
execution. The latter would allow the system to take into account the
dynamic nature of the workspace. Since, in general, finding an exact
match may be difficult, that underlying system may provide a negotiation
capability which would allow the user (or an agent process) to make
intelligent trade-offs in the resource allocation process.

The result of the job submission would be a \"job object\" which would
encompass all the information about the job. It is the underlying
system\'s responsibility to manage the execution of the job including
the management of the intermediate data. A data-flow paradigm could be
used to determine when a action needs to started on designated set of
resources. Starting a action on a remote resource may require
authorization for the user to utilize the resource. Similarly, an
accounting module may keep track of the amount of resources used.

#### Job Management: 

As the job progresses, the underlying system needs to provide support
for management of the jobs. This includes monitoring the execution
status of the job, i.e., which sub_tasks have been completed and which
are waiting. The user should also have the capability of
suspending/restarting, checkpointing, and killing the

jobs.

In addition to monitoring the execution progress of the job, the user
may want to monitor the intermediate data being produced by the
sub_tasks. Based on this, the user may want to steer the computation.
Such steering may take different forms. For example, at the outermost
level, the user may replace the execution code to be used for a task in
order to control the fidelity of the simulation. Similarly, the user may
want to change the arguments input to a code. At finer level, the user
may want to interact directly with an executing code changing the
intermediate data values being used by the code. Thus, the

underlying system has to support multiple levels of steering support.

In the above paragraphs, we have described the various steps a typical
user would take in order to construct and execute a job. We have also
tried to indicate the support that the underlying system has to provide
at each stage. This is a preliminary document. A much more in depth
study is required in order to provide a detailed set of requirements
from the user\'s perspective.

## 

## Working Group 2:

## The Interface to desktop access: the Metacomputing API

Each metacomputing system provides a set of services that constitute the
components of the system architecture. While these services differ
slightly from one architecture to another, there are enough shared
characteristics that it is possible to abstract them and provide a
\"standard\" API from which desktop user tools may be constructed. In
fact, there are four types of user interfaces:

1.  The End User who wishes to submit a single job, multiple instances
    of a job, access a collaboration or invoke a Grid based problem
    solving environment.

2.  The System Administrator who is responsible for the installation of
    grid tools and the addition of new resources into the metacomputing
    system

3.  The developer of applications that take advantage of advanced grid
    services

4.  The owners of the metacomputing resources that comprise the Grid.

In the paragraphs that follow we describe the common services and data
abstractions and the associated APIs needed to build the desktop tools
for these classes of users. Note that we have not identified all the
services nor all interactions between services that go into building a
metacomputing system. Rather we have focused on those services for which
there are user interface interactions and dependencies. Furthermore we
most certainly have omitted or oversimplified in many cases. Suggestions
are always welcome.

### Fundamental Abstractions

There are many basic data type classes that go into the design of a
metacomputing system. There are, however, four core data types that are
fundamental to submitting and managing jobs on the Grid.

-   ***Tasks and Jobs***. A ***Task*** is recursively defined as a basic
    task, i.e. an execution of a single process or transaction on a
    compute or data resource, or a DAG of tasks whose execution order is
    defined by application dependencies. A ***Job*** is an instantiation
    of a task representing an execution of that task in the system.
    Different systems represent Tasks and Jobs in different ways. Globus
    has a specification language RSL to define tasks. In Condor the
    concept of ClassAd is an object which encapsulates the metadata
    associated with a job specification. In Unicore, the Tasks and Jobs
    are defined by an \"Abstract Job Object\".

-   ***Resource.*** A resource typically refers to the hardware:
    computer systems, network links, networked instruments and other
    devices that make up the Grid. However, resources can also refer to
    software, server processes and directory and other services. In
    Condor resources are again defined by ClassAds. In Globus, resources
    are described by MDS classes.

-   ***Events.*** Three types of events are central to a metacomputing
    environment. System level events describe the basic changes in
    structure of the grid or the composition of the resources available.
    A closely related event type includes status events which describe
    the changes of state that are constantly taking place in a
    metacomputing infrastructure.

-   ***File names and Object handles***. The ability to name objects in
    a manner independent of physical attributes that bind them to the
    Grid is also essential. Globus uses URLs to identify files, Sun\'s
    Jini uses references and proxies obtained from the directory
    services to identify resources. While a complete metacomputing
    system may or may not have a global file space, if is clear it must
    have a resource/file/process naming system that spans the Grid.

### Services

The following are the core services that must be abstracted by the APIs.

#### Resource Services. 

There are three basic resource services.

1.  Discovery refers to the service by which new resources and located
    on the network. This may be invoked when a new service is added to
    the system or when a task request resources for which a resource
    handle is required for job execution.

2.  Allocation and Leasing refers to the process by which specific
    resources are bound to job objects during execution.

3.  Resource monitoring services maintain the status (heart beat) of
    each resource in the system.

Java Jini has a complete and sophisticated resource discovery system.
Globus MDS provides the discovery system in that environment. In Condor,
the matchmaker service proved a different model for resource discovery.

#### Accounting.

Accounting services can be derived from resource monitoring, but they
are so important that we list them separately.

#### Notification and Event Services. 

Resources such as compute services and networks come and go from the
system. As the system changes state events are generated and logged. In
addition, Jobs change state as they progress (or fail). Jobs can be
preempted or rescheduled as systems fail or resources change state. In
addition, tools such as performance monitors can be driven by event
services. Distributed debuggers also require event monitoring. Desktop
applications can register to be notified of events of many different
types.

#### Transaction Services

Basic transaction services assure consistency in distributed systems.
From the perspective of desktop access to the grid, tasks such as job
submission require consistency: when a job is submitted, we need to know
that one and not two or zero instances were created. When a special
resource is leased for a job and later released this requires a reliable
transaction.

Jini uses a classical two-phase commit protocol. Other systems provide
similar services.

#### Logging Services

Not all desktop applications can be assumed to be actively monitoring
events. In some cases, the application, when invoked would consult a log
file for a record of events and transactions. The logging service
provides a standard protocol for recording and storing event and system
logs that can be access by other tools.

#### Keep-Alive Service

Some systems, such as directory services and file systems must be kept
alive. When their agent processes die, it is essential that they be
restarted. Keep-Alive services periodically check to make sure that
critical functions are still operational.

#### Collaboration

Collaboration Services provide the backbone with which multiple,
simultaneous users can share desktop tools.

#### 

#### Communication services

Application need to communicate with each other, the filespace as well
as user tools. For example, standard error and I/O streams as well as
specialized communication protocols such as Globus Nexus must be
provided as a service that is available to the desktop system.

#### \"Do it\" Services

The basic task of interacting with a job in the system takes several
different forms. The simple transaction of running a job is one. In
other cases, more complex interaction is required and uses shell like
services. For example, pausing, killing a job. In other cases the job
execution can be managed through scripting interfaces. In both cases,
these are command interpreters which provide the desktop user
fine-grained control over execution.

### The Service API s

The APIs listed below provide the interfaces to the services that will
allow us to build the desktop tools. In many cases these are in
one-to-one correspondence with the corresponding system services and in
other cases they represent a functional interface that interacts with
more than one of the core services. The important point is that
different metacomputing environments differ in the way they implement or
organize services, but the API should be consistent across different
platforms to make it possible to design portable, seamless tools.

#### Job initiation and execution management API

This API provides the basic mechanisms to start or enqueue a job for
execution. It also provides the interface to the basic runtime
management of job. For example, killing or suspending a job,
checkpointing or serializing a job, modifing a job\'s running
properties.

In addition this API should provide a mechanism for application specific
user interface extensions such as attaching a GUI for steering or
attaching a debugger.

#### Event and Notification APIs

Some applications and most system components will generate events. This
API allows user interface tools to register as listeners or to receive
notification. In addition for more passive tools, there is a need to
inquire about past events or to see event logs.

#### 

####  Job and Resource Status and Monitoring API

Given a handle to an abstract job, what is its status? Given a resource
object, what is its status?

This interface also provides for tools that provide dynamic performance
monitoring.

#### 

#### Security

The security interface is defined by the security subgroup and user
requirements group.

#### 

#### Transaction Service API

This interface is a standard, two-phase commit protocol such as provided
by Jini.

#### Informational

There are three parts to the informational API.

-   The basic interface for constructing job and resource objects and
    examining events.

```{=html}
<!-- -->
```
-   The basic mechanism for accessing the discovery/ registry services

```{=html}
<!-- -->
```
-   The global name space for referencing all objects.

## Working Group 3:

## Secure Desktop Access to Remote Resources

## 

The notes of this working group are attached at the end of this paper.

# Project Descriptions

# 

## Akenti -- A Distributed Access Control System

Srilekha S. Mudumbai, William Johnston, Mary R. Thompson, Abdeliah
Essiari, Gary Hoo, Keith Jackson

http://www-itg.lbl.gov/Akenti

Lawrence Berkeley National Laboratory, Berkeley, CA 94720

**Introduction**

Akenti is an access control system designed to address the issues raised
in managing access to distributed resources that are controlled by
multiple remote stakeholders. Akenti enables stakeholders securely to
create and to distribute instructions authorizing access to their
resources. Akenti makes access control decisions based on a set of
digitally signed documents that represent the authorization instructions
and the relevant user characteristics. Public-key infrastructure and
secure message protocols provide confidentiality, message integrity, and
user identity authentication, during and after the access decision
process.

### Akenti Access Control Fundamentals

The resources that Akenti controls may be information, processing or
communication capabilities, or physical systems such as scientific
instruments. The access that is sought may be to obtain information from
the resource, to modify the resource, or to cause that resource to
perform certain functions. Remote access to a resource is typically
provided by a network-based server acting as a proxy for the resource. A
user gains access to the resource via a client program. The client
participates in the following authentication and verification steps
before gaining access to the resource.

-   In an initial two-way process, implemented by the Secure Sockets
    Layer (SSL) protocol, the client and server mutually authenticate
    each other using their X.509 identity certificates and private keys.

-   Akenti then checks the set of use-conditions imposed on the resource
    by the stakeholders in the form of digitally signed documents
    (certificates). If the user satisfies the use-conditions by
    presenting appropriate attribute certificates, then specific actions
    are permitted (i.e. read, modify, etc.) on the resource.

**Components of the Model**

***Authority file*:** This is information stored on the resource server
associated with each resource. It consists of relatively static
information that specifies who can provide access information and where
this information is stored and what X.509 Certificates Authorities are
trusted.

***Identity (X.509) certificates*:** These certificates bind an entity's
name to a public key. They are stored in LDAP (Lightweight Directory
Access Protocol) directory servers from which Akenti obtains them to
verify a subject's identity.

***Use-condition certificates*:** These are signed documents, remotely
created and stored by resource stakeholders, that specify the conditions
("policy") for access to the resource.

***Attribute certificates*:** These are signed documents, remotely
created and stored by a third party trusted by the stakeholder, that
certify that a user possesses a specific attribute (for example,
membership in a named group, completion of a certain training course, or
membership in an organization).

### Implementation Status

***Web Server***

Currently, Akenti is used by the SSL-enabled Apache web server in order
to provide policy based access control. The Apache server's native
access control mechanism has been replaced by an interface to the Akenti
policy engine. This server is being used to provide access control of
experimental results for the DOE Diesel Combustion Collaboratory

***CORBA ORB***

Akenti access control has been added to a [CORBA ORB]{.smallcaps} (Orbix
including the SSL communication protocol). The DOE MMC Collaboratory is
planning to use this ORB to launch a microscope control server. An ORB
defines a callout function that is invoked whenever a request is
initiated. This callout function is used to invoke the Akenti policy
engine that identifies stakeholders and acquires, validates and analyzes
the various certificates The result of this analysis will either permit
the requested access or deny it, depending on whether or not the user
satisfies the use conditions.

**Future Work**

Future work will include deploying a mobile agent system with Akenti
access control; integrating Akenti access control with Globus resource
management software in a secure compute server and a network bandwidth
broker; and integrating Akenti access control with Sandia's PRE
CORBA-based remote invocation system.

## Arcade: A Web-Java Based Framework for Distributed Computing

Arcade is a Web/Java based framework designed to provide support for a
team of discipline experts to collaboratively design, execute and
monitor multidisciplinary applications on a distributed heterogeneous
network of workstations and parallel machines. This framework is
suitable for applications such as the multidisciplinary design
optimization of an aircraft. Such applications in general consist of
multiple heterogeneous modules executing on independent distributed
resources while interacting with each other to solve the overall design
problem.

The Arcade architecture consists of three-tiers:

**First Tier** The first tier provides the user interface to the system.
It comprises of the application specification interface, the resource
allocation and execution management interface, and the monitoring
interface.

The *application design interface* provides both visual and textual
(script-based) mechanisms for the hierarchical specification of
execution modules and their dependencies. In addition to normal
executable modules, the system supports hierarchical modules, SPMD
modules for MPI-based codes, and control structure modules, e.g.,
conditional and loops.

The *resource allocation and execution interface* provides support for
specifying the hardware resources required for the execution of the
application. The resources are currently specified explicitly by the
user. We envision a system where the resources are automatically
allocated based on the current and predicted loads of the system and the
characteristics of the application. The system will also allow the users
to choose the input/output files and any command line arguments for the
modules prior to starting the execution.

The *monitoring and steering interface* will allow users to monitor both
the progress of the execution and the intermediate data flowing between
the module. It will also allow the users to steer the overall
computation by modifying data values and also replacing execution
modules to control the fidelity of the computations.

**Middle Tier** The middle tier consists of logic to process the user
input and to interact with application modules running on a
heterogeneous set of machines. The overall design is a
client-server-based architecture in which the Interface Server interacts
with the front-end client to provide the information and services as
needed by the client.

A Java Project object internally represents each application. The
Project object, consisting of a vector of module objects, is the central
object in our framework. All the information related to the application,
both static and dynamic is stored within this object. When the user
requests the execution of an application, the User Interface Server
passes the corresponding Project object to the *Execution Controller
(EC)*. It is the EC's responsibility to manage the execution and the
interaction by firing up user modules on the specified resources as and
when dictated by the dependencies specified by the user.

**Third Tier** The third tier consists of *Resource Controllers (RC)*
and *User Application Modules*. Each active resource in the execution
environment is managed by a RC which is responsible for launching the
User Application Modules on the resource and also for interacting with
the Execution Controller in order to keep track of the executing
applications.

> The main advantage of a three-tier system is that the client or the
> front-end becomes very thin, thus making it feasible to run on low-end
> machines. Also, since most of the logic is embodied in the middle
> tier, the RCs can be kept lightweight thus keeping the additional
> loads on the executing machines to a minimum also.

The overall goal is to design an environment which is easy to use,
easily accessible, portable and provides support through all phases of
the development and execution of multi-disciplinary applications. We
plan to leverage off of commodity technologies, such as the Web and
Java, to implement various parts of the environment. The current
prototype of the system is capable of executing distributed applications
on a network of resources in a single domain interacting with each other
through files. We are currently expanding the system to incorporate many
new facilities, including multi-domain execution and collaboration
support in all phases of the design and execution of the overall
application. More information on the Arcade system can be found at
<http://www.icase.edu/arcade>.

This research is being supported by the National Aeronautics and Space
Administration under NASA Contract No. NAS1-19480.

## CPU-Usage Monitoring with DSRT Sytem

**Webpage**: <http://dast.nlanr.net/Projects/monitor.html>

Klara Nahrstedt, CS dept, UIUC \<klara@cs.uiuc.edu\>

Kai Chen, NLANR/DAST, NCSA \<roland@nlanr.net\>

Roland Geisler, NLANR/DAST, NCSA \<<kchen@nlanr.net>\>

This is the project is a joint project is in its initial stage. The plan
is to produce a detail design at the end of this year, and start coding
from next year. It is supposed to finish by May 1999.

**Description**

DSRT is a dynamic soft real time system sitting on top of a general
purpose UNIX system with real time extension. It supports several
service classes for multimedia applications based on their CPU usage
time pattern \[1\]. This project is to design and implement a
distributed CPU-usage monitoring tool with DSRT system under the context
of the Globus environment. Currently Heartbeat Monitor (HBM) is running
as a process monitoring tool in the Globus infrastructure. It collects
some basic status information for a process, such as active, blocked and
abnormal \[2\]. We plan to take the architecture of HBM, extend its
functionality to work with DSRT system, and report more status
information for a real time process. Currently we plan to get the
following information from the DSRT system for different service
classes:

PCPT (Constant Processing Time): Period, Peak Processing Time;

VPT (Variable Processing Time): Period, Sustainable Processing Time,
Peak Processing Time;

OCPT (One-Time Constant Processing Time): Start Time, Interval, Peak
Processing Time;

ACPT (Aperiodic Constant processing Time): Peak Process Rate.

**References:**

\[1\] Hao-hua Chu and Klara Nahrstedt, CPU Service Classes for
Multimedia Applications, Technical Report UIUCDCS-R-98-2068,
UILU-ENG-98-1730, Department of Computer Science, University of Illinois
at Urbana Champaign, August, 1998.

\[2\] Globus Heartbeat Monitor,
[http://www.globus.org](http://www.globus.org/), October, 1998.

## Distributed Resource Management for DisCom2

The Distance Computing and Distributed Computing (DisCom2) program is a
DOE multi-lab program that complements the mission of DOE\'s Accelerated
Strategic Computing Initiative (ASCI). The ASCI program was established
to create the computational modeling and simulation capabilities
essential to shift from nuclear and nonnuclear test-based methods of
assessment and certification to computation-based stewardship of the
enduring nuclear stockpile. The DisCom2 program will accelerate the
ability of the Defense Programs complex to remotely access the high-end
and distributed computing resources by creating a simulation intranet.
Distance computing emphasizes remote access to the ASCI-class
supercomputers for capability computations, where the goal is to provide
maximum resources to a single computation. Distributed computing
emphasizes remote access to other distributed resources for capacity
computations, where the goal is to provide some resources to the maximum
number of computations.

The Distributed Resource Management (DRM) project will provide the
capabilities and services needed to access and manage the high-end
simulation resources dispersed throughout the DP complex. The simulation
intranet includes high-performance storage, network, and visualization
resources that must be managed along with the computing resources. Other
remote resources envisioned include databases and utility executables
such as file format conversion routines. To achieve its goal, the DRM
project is divided into several tasks:

-   The Service Model provides a user perspective of requirements across
    the complete range of system operations, problem domains, and
    organizational cultures. The Service Model is being developed from
    use case analysis of in-depth user interviews.

-   The Architecture Model provides the target system design and an
    evolutionary strategy for phased implementation of a DRM system. The
    use of off-the-shelf products is preferred, and they will be
    employed where consistent with the desired system.

-   The Product Evaluation identifies candidate products for testing and
    experimentation.

-   Simulation and Testing activities manage areas of development risk
    by evaluating design alternatives.

-   The System Design defines how services will be implemented.

-   The Prototype DRM System deploys capability in phases, provides for
    user feedback, and positions the system for the implementation of
    future services.

## Condor

Miron Livny, <miron@cs.wisc.edu>

<http://www.cs.wisc.edu/condor>

<http://www.cs.wisc.edu/condor/publications.html>

Building on the results of the Remote-Unix (RU) project and as a
continuation of our work in the area of Distribute Resource Management
(DRM), the Condor project started at the Computer Sciences Department of
the University of Wisconsin-Madison in 1988. Following the spirit of its
predecessors, the project has been focusing on customers with large
computing needs and environments with large collections of heterogeneous
distributed resources. For more than a decade, we have been developing,
implementing, and deploying, software tools that

can effectively harness the capacity of hundreds of distributively owned
workstations. The workstations can be scattered throughout the globe and
may be owned by different individuals, groups, or institutions. Using
our software, the Condor resource management environment, scientists and
engineers have been simultaneously and transparently exploiting the
capacity of computing resources they are not even aware exists. Condor
provided them with a single point

of access to computing resources scattered throughput their department,
college, university or even the entire country.

For many experimental scientists, scientific progress and quality of
research are strongly linked to computing throughput. In other words,
most scientists are less concerned about the instantaneous performance
of the environment (typically measured in Floating Point Operations per
Second (FLOPS)). Instead, what matters to them is the amount of
computing they can harness over a month or a year \-\-- they measure the
performance of a computing environment in

units of scenarios per day, wind patterns per week, instructions sets
per month, or crystal configurations per year. Floating point operations
per second has long been the principal metric used in High Performance
Computing (HPC) efforts to evaluate their systems. The computing
community has devoted little attention to environments that can deliver
large amounts of processing capacity over long periods of time. We refer
to such environments as High Throughput Computing (HTC) environments. We
first introduced the distinction between HPC and HTC in a seminar at the
NASA Goddard Flight Center in July of 1996 and a month later at the
European Laboratory for Particle Physics (CERN). In June of 1997 HPCWire
published an interview with M. Livny on High Throughput Computing. A
detailed discussion of the salient characteristics of a HTC environment
can be found in our contribution in \"The Grid - Blueprint for a New
Computing Infrastructure,\" I. Foster and C. Kesselman editors).

The key to HTC is effective management and exploitation of all available
computing resources. Since the computing needs of most scientists can be
satisfied these days by commodity CPUs and memory, high efficiency is
not playing a major role in a HTC environment. The main challenge a
typical HTC environment faces is how to maximize the amount of resources
accessible to its customers. Distributed ownership of computing
resources is the major obstacle such an environment has to overcome in
order to expand the pool of resources it can draw from. Recent trends in
the cost/performance ratio of computer hardware have placed the control
(ownership) over powerful computing resources in the hands of
individuals and small groups. These distributed owners are willing to
include their resources in a HTC environment only when they are
convinced that their needs will be addressed and their rights protected.
The needs of these owners have been always a key factor in our research,
development and implementation activity.

Condor is based on a novel approach to HTC that follows a layered
Resource Allocation and Management software architecture. Depending on
the characteristics of the application, the customer, and/or the
environment, different layers are employed to provide a comprehensive
set of Resource Management services. Condor was originally designed to
operate in a Unix environment. For the last two years we have been
engaged in an effort to port Condor to the NT environment. Our goal has
been to develop a fully integrated HTC resource management system that
can effectively harness the resources of computing environments that
consists of both Unix and NT resources. We have recently added to Condor
support for Symmetric Multi Processors (SMP) and interfaces to HPC batch
schedulers.

The Condor project is an ongoing Research and Development project in
which research in distributed resource management is performed in the
framework of a team effort in which production software is development,
deployment and supported. Scientists and engineers from a wide range of
disciplines have employed Condor in their daily work and have been
collaborating with us on porting their applications to benefit form the
computing power offered by Condor and on enhancing the capabilities of
Condor. Without these collaborations, Condor would have been a much less
effective resource management system.

## EveryWare

<http://nws.npaci.edu/EveryWare/>

A Toolkit for Building Adaptive Computational Grid Programs

The goal of performance-oriented distributed computing is to harness
widely dispersed, independently controlled resources into a
\"Computational Grid\" that supplies execution cycles the way a power
company supplies electrical power. Since the resources are independently
managed by their individual owners, it is not possible to assume that a
uniform software infrastructure will be installed at every potential
execution site. EveryWare is a set of software tools designed to allow
an application to leverage resources opportunistically, based on the
services they support. By using the EveryWare toolkit, a single
application can combine simulatneously combine the useful features

offered by

-   Globus metacomputing services

```{=html}
<!-- -->
```
-   Legion metacomputing facilities

```{=html}
<!-- -->
```
-   Condor high-throughput computing facilities

```{=html}
<!-- -->
```
-   Netsolve brokered agent computing facilities

Java applet technology

-   NT

```{=html}
<!-- -->
```
-   Unix

to form a temporary virtual Computational Grid for its own use. Each of
these infrastructures offers services that can be combined by an
application profitably. EveryWare allows the application to gauge and
harness the power that is available to it at each potential execution
site, based on the type of the resource at hand, and the software

infrastructure it supports.

##### EveryWare Components

Everyware consists of five services:

-   low-level, portable communication and process control facilities

```{=html}
<!-- -->
```
-   adaptive performance sensing and prediction facilities Organized,
    Regional, Autonomous Group Schedulers (ORAnGS)

```{=html}
<!-- -->
```
-   fault-resiliant persistent state management

```{=html}
<!-- -->
```
-   distributed and adative state synchronization facilities

which are implemented to use the the advantageous features of what ever
infrastructure is present. For example, if the Globus GRAM and GASS
facilities are available, EveryWare uses them for process management. If
Condor is present, EveryWare uses the submission interface to launch
application processes. The low-level software primitives are written to
be extremely portable so that new infrastructures and architectures can
be incorporated quickly.

To gauge the performance value of a particular resource, an

EveryWare application can collect performance information

\"on-the-fly\" and use dynamic prediction techniques to pick a best
resource and recognize emerging performance trends. These facilities
work at the application level so that the overheads introduced by any
resident infrastructure are considered.

Scheduling is a service provided by EveryWare in the form of ORAnGS.
Application components my employ a scheduling service to organize
themselves into autonomous groups. Unlike other schedulers, however,
ORAnGS are servers rather than controllers. Applications request
scheduling service from them as opposed to submitting themselves as
slaves to a master scheduler.

EveryWare also allows application components to register themselves with
a distributed, adaptive state synchronization facility. As state
propagates through the system, components are notified of state updates
automatically.

**Why use EveryWare?**

Computational Grids are dynamic environments. Not only does the
performance vary as a function of resource load (due to contention) but
resources are added and removed from the Grid continuously. It is,
therefore, not possible to assume that a consistent Grid-wide
infrastructure will be in place ubiquitously. New, experimental
architectures will be available long before sophisticated Grid services
are ported to them. Operating system and software revision levels are
often incompatible. Resource owners may wish to temporarily contribute
their resources, but not to install and maintain new infrastructure to
do so. EveryWare allows a single application to combine low-level
\"vanilla\" operating systems facilities (like those provided by Unix)
with sophisticated and robust metacomputing facilities (Globus, Condor,
Legion) and ultra-portable execution environments (Java). The goal is to
allow the application to use a computational resource regardless of what
infrastructure it supports.

**Is EveryWare for Everyone?**

An EveryWare application claims and discards resources dynamically,
based on their perceived performance value. If ORAnGS supplies
scheduling control, the application dynamically molds itself to the
changing conditions. Not all application classes will be able to achieve
high-performance levels using global resources. For those applications
that require coarse-grained, loose synchronization and can migrate state
efficiently, EveryWare is an appropriate option.

## Globus: The Globus Grid Computing Toolkit

**What is Globus?** Globus is a research and development project that
targets the software infrastructure required to develop usable
high-performance wide area computing applications. Globus *research*
targets key challenges that arise when developing innovative
applications in wide area, multi-institutional environments, such as
communication, scheduling, security, information, data access, and fault
detection. Globus *development* is focused on the Globus toolkit, a set
of services designed to support the development of innovative and
high-performance networking applications. These services make it
possible, for example, for applications to locate suitable computers in
a network and then apply them to a particular problem, or to organize
communications effectively in tele-immersion systems. Globus services
are used both to develop higher-level tools (e.g., the CAVERNsoft
teleimmersion system, the WebFlow problem solving environment) and
directly in applications (e.g., collaborative data analysis).

**What is the Globus Toolkit?** The Globus toolkit provides services for
security, resource location, resource allocation, resource management,
information, communication, fault detection, network performance
measurement, remote data access, and distributed code management. These
services are implemented by a set of servers that run on (typically
high-end) computing resources and client-side application programming
interfaces (APIs). Globus services are designed to hide low-level
details of resource characteristics (e.g., architecture, scheduler type,
communication protocols, storage system architecture) while allowing
applications to discover and exploit low-level information when this is
important for performance.

**How does this relate to seamless computing?** Globus client-side APIs
can be used to construct desktop applications that authenticate once,
then locate resources in a network, determine properties of those
resources, request allocations on those resources, transfer data among
those resources, initiate computations on those resources, communicate
with those computations, and monitor their execution. These desktop
applications may be written in C or C++ or, thanks to the development of
Java versions of many Globus APIs, in Java.

**Who is involved in Globus?** Globus research and development is
centered at Argonne National Laboratory and the University of Southern
California's Information Sciences Institute, but also includes many
partner institutions. Many partners form part of the Globus Ubiquitous
Supercomputing Testbed Organization, an informal consortium of
institutions interested in high-performance distributed computing.

For more information see [www.globus.org](http://www.globus.org/) or
contact <info@globus.org>

## Globus^J^

Globus J is a collection of reusable Java components which allow access
to a selected set of Globus services including Job submission, remote
file staging. A simple graph based editor allows creating a dataflow
graph of jobs submitted to the Globus metacomputing toolkit. These
components are not distributed with the Globus metacomputing toolkit due
to their experimental nature. A small subset of components is expected
to be released after SC98.

## Habanero 

Ed Grossman, Terry McLaren, Larry Jackson

jackson@ncsa.uiuc.edu tmclaren@ncsa.uiuc.edu egrossma@ncsa.uiuc.edu

NCSA Habanero is a Java-based framework for synchronous collaboration.
Habanero makes it possible for scientists who are not physically
co-located to work on projects together in real time. They may access,
analyze, and visualize scientific data, discuss issues, view documents
and images, and run scientific computation and analysis tools
collaboratively. Habanero also provides the ability for instructors to
conduct classes, run help sessions, or distribute pre-recorded classes
for students to take over the Internet.

The Habanero package includes a server, a client, several collaborative
applications (Hablets), and persistence support modules. When Habanero
is running, the server component keeps track of the active collaborative
sessions under its control, maintains information about active
participants, tracks the active Hablets, and manages event traffic in
the system, and enforces each Hablet\'s \"rules of operation\". All
Habanero clients display the same thing to all participants in a given
session, all at the same time (synchronously). Habanero sessions may be
recorded by any participant and played back. Third party developers may
construct Hablets for any purpose by using the Habanero Developer\'s
API. Current and future development centers on

1)  adding persistence to Habanero,

2)  blending in asynchronous collaboration,

3)  supporting collaborative session replay,

4)  enabling Habanero to use Jini services and become a service itself,
    and

5)  helping 3rd party developers create or customize hablets.

Persistence: Persistent sessions may be created, used, stored, searched,
suspended, and resumed from their previous state. Participant
information becomes persistent also. Both session and participant
information may be accessed from a directory service (e.g., LDAP). New
sessions can be constructed from subsets of existing sessions
(branching) or created from the intersection of portions of existing
sessions (merging).

Blended Asynchronous Collaboration: This work includes asynchronous
session membership, event filtering to external destinations such as
email and Automated Assistant Agents, event receipt and handling from
approved external Automated Assistant Agents, and notification.

Collaborative Distributed Session Replay: This provides the capability
to play back captured sessions from an active session.

Jini Services: This includes the construction of Jini Services and
service framework useful to the NCSA Habanero project, and the extension
of the Habanero framework to use the Jini services. Useful services
include persistence, directory/lookup services, event monitoring with
notification, and email/ftp/news services.

3rd Party Developer Aid: Applet-to-Hablet construction, hablet
customizing, and hablet bean (Java Bean) construction wizards will be
developed.

## Harness: Dynamic Reconfiguration and Virtual Machine Management in the Harness Metacomputing System

Mauro Migliardi, Jack Dongarra, Al Geist, and Vaidy Sunderam

<om@mathcs.emory.edu>

Harness is an experimental metacomputing system based upon the principle
of dynamically reconfigurable networked computing frameworks. Harness
supports reconfiguration not only in terms of the computers and networks
that comprise the virtual machine, but also in the capabilities of the
VM itself. These characteristics may be modified under user control via
a Java based on demand \"plug-in\" mechanism that is the central feature
of the system.

The overall goals of the Harness project are to investigate and develop
three key capabilities within the framework of a heterogeneous computing
environment:

-   Techniques and methods for creating an environment where multiple
    distributed virtual machines can collaborate, merge or split. This
    will extend the current network and cluster computing model to
    include multiple distributed virtual machines with multiple users,
    thereby enabling standalone as well as collaborative metacomputing.

-   Specification and design of plug-in interfaces to allow dynamic
    extensions to a distributed virtual machine. This aspect involves
    the development of a generalized plug-in paradigm for distributed
    virtual machines that allows users or applications to dynamically
    customize, adapt, and extend the distributed computing
    environment\'s features to match their needs.

-   Methodologies for distinct parallel applications to discover each
    other, dynamically attach, collaborate, and cleanly detach. We
    envision that this capability will be enabled by the creation of a
    framework that will integrate discovery services with an API that
    defines attachment and detachment protocols between heterogeneous,
    distributed applications.

Early experience with small example programs show that our system is
able:

-   to adapt to changing user needs by adding new services via the
    plug-in mechanism;

-   to safely add or remove services to a distributed VM;

-   to locate, validate and load locally or remotely stored plug-in
    modules;

-   to cope with network and host failure with a limited overhead;

-   to dynamically add and remove hosts to the VM via the dynamic VM
    management mechanism.

## IceT

Paul Gray, gray@mathcs.emory.edu

Math/Computer Science Department, Emory University, Atlanta, GA

150 North Decatur Building

1784 N. Decatur Rd.

Atlanta, GA 30322

<http://www.mathcs.emory.edu/~gray>

At the present, the respective programming models, tools and
environments associated with Internet programming and parallel,
high-performance distributed computing have remained detached from one
another. The focus of the IceT project has been to bring together the

common and unique attributes of these areas, the result of which is a
confluence of technologies and a parallel programming environment with
several novel characteristics. The resulting combination of technologies
provides users with a parallel, multi-user, distributed programming
environment; upon which processes and data are allowed to migrate and to
be transfered throughout owned and unowned resources, under security
measures imposed by owners of the local resources.

The IceT environment provides users the ability to dynamically configure
a distributed environment to suit the specific needs of the application,
not the other way around. Process management is provided using IceT\'s
unique soft-installation abilities which give native codes significant
Java-like portability and dynamism.

The traditional paradigms associated with message-passing have been
extended in IceT to include object- and process-passing. As a result,
the environment is able to support nomadic processes and is able to
dynamically load components into the environment to support the
particular needs of the application.

In IceT, individual environments of multiple users are able to be merged
together to form larger resource pools, over which processes may be
mutually installed using IceT\'s soft-installation mechanism. Several
examples which have shown proof of concept include the soft-installation
of C-based MPI processes on remote environments (along with the
supporting MPI library calls) and the dynamic installation of
Fortran-based PVM computations running cooperatively across distinct
networks and filesystems, supported by IceT\'s process management and
message-passing API.

## JINI

<http://java.sun.com/products/jini>

Overview of the SUN Jini Technology & its Application in PSEs

Jini is a platform-independent, Java-based mechanism for providing
services to clients over the network. Services are components for
accessing and utilizing hardware and software

resources over a network. A service can correspond to a network device
such as a computer or printer, a software resource such as a database,
or a higher-level composite functionality.

Jini uses and extends the existing Java programming language base. It
extends the scope of Java from a single machine to a network of
machines.

Jini is a componentized system. Its components function outside the
scope of Jini, but together, they provide a platform for distributed
computing. The components include

-   Jini Lookup & Discovery

```{=html}
<!-- -->
```
-   Jini Schema

```{=html}
<!-- -->
```
-   Distributed Events

```{=html}
<!-- -->
```
-   Distributed Leasing

```{=html}
<!-- -->
```
-   Distributed Transactions

```{=html}
<!-- -->
```
-   JavaSpaces

The Jini Lookup Service, Discovery Protocols, and Schema together allow
services to describe themselves, advertise their existence, and make
themselves available for use over the network. Each Jini service
registers with a Jini lookup service and provides a proxy. Later, when a
client makes a service request, the Jini lookup service will determine
whether it has a matching service available. If a match is found, the
Jini lookup service sends a copy of the matching service\'s proxy to the
client. The client then uses the proxy to access the service.

The Event handling interface extends the JavaBeans event model for use
in a distributed computing environment.

Leasing allows resource allocation and other operations to occur on a
timed basis. If the \"timer\" is allowed to expire, the resource is
released, or the operation is cancelled.

The transaction interface ensures that either all of the operations in a
given operation set occur atomically, or none of them occur. It uses a
two-phase commit mechanism.

JavaSpaces supports the flow of objects between participants in a
distributed system, and in doing so, supplies distributed object
persistence. Clients of a JavaSpace export objects and events for other
clients to use and consume as needed.

The Jini technology is potentially very useful in the construction of
scientific workbenches and other problem solving environments (PSEs).
First, Jini is runs on any platform that supports a Java VM. Second,
Jini\'s service-based architecture can give PSEs great flexibility. A
PSE could use any service it could discover and access, so its
functionality is easily made dynamic. Then, services developed for one
purpose could be used elsewhere, so redundant development is reduced.
Finally, Jini could be used to make existing legacy programs visible and
usable over the network.

A Java-based PSE framework could be developed that supports the
development of PSE services and provides a bridge to other distributed
computing environments such as Globus. A Jini-to-Globus bridge would
allow the use of both Globus and Jini services in the same PSE. An
workbench-service construction kit (Java packages) would provide
abstractions of different kinds of workbench services and service
components. The workbench construction kit would also include components
for interfacing with non-Java code. And, the PSE framework would contain
generic services useful in PSE development, such as Visualization,
Notification, Sequencing/Scripting, Data Format Translation,
Collaboration, and Persistence.

## Legion System Architecture

Legion is an object-based system that empowers classes and metaclasses
with system-level responsibility.

Philosophy

Legion users will require a wide range of services in many different
dimensions, including security, performance, and functionality. No
single policy or static set of policies will satisfy every user, so,
whenever possible, users must be able to decide what trade-offs are
necessary and desirable. Several characteristics of the Legion
architecture reflect and support this philosophy.

-   ***Everything is an object:*** The Legion system will consist of a
    variety of hardware and software resources, each of which will be
    represented by a *Legion object*, which is an active process that
    responds to member function invocations from other objects in the
    system. Legion defines the message format and high-level protocol
    for object interaction, but not the programming language or the
    communications protocol.

-   ***Classes manage their instances:*** Every Legion object is defined
    and managed by its *class object*, which is itself an active Legion
    object. Class objects are given system-level responsibility; classes
    create new instances, schedule them for execution, activate and
    deactivate them, and provide information about their current
    location to client objects that wish to communicate with them. In
    this sense, classes are *managers* and *policy makers*, not just
    definers of instances. Classes whose instances are themselves
    classes are called *metaclasses*.

-   ***Users can provide their own classes:*** Legion allows users to
    define and build their own class objects; therefore, Legion
    programmers can determine and even change the system-level
    mechanisms that support their objects. Legion 1.4 (and future Legion
    systems) contains default implementations of several useful types of
    classes and metaclasses. Users will not be forced to use these
    implementations, however, particularly if they do not meet the
    users' performance, security, or functionality requirements.

-   ***Core objects implement common services:*** Legion defines the
    interface and functionality of a set of core types that support
    basic system services, such as naming, binding, creation,
    activation, deactivation, and deletion. Core Legion objects provide
    the mechanisms that classes use to implement policies appropriate
    for their instances. Examples of core objects include *hosts*,
    *vaults*, *contexts*, *binding agents*, and *implementations*.

The Model

Legion objects are independent, logically address- space-disjoint active
objects that communicate with one another via non-blocking method calls
that may be accepted in any order by the called object. Each method has
a signature that describes the parameters and return value, if any, of
the method. The complete set of method signatures for an object fully
describes that object's interface, which is determined by its class.
Legion class interfaces can be described in an *interface description
language* (IDL), several of which will be supported by Legion.

Legion implements a three-level naming system. At the highest level,
users refer to objects using human- readable strings, called *context
names*. Context objects map context names to *LOIDs* (Legion object
identifiers), which are location-independent identifiers that include an
RSA public key. Since they are location independent, LOIDs by themselves
are insufficient for communication; therefore, a LOID is mapped to an
*LOA* (Legion object address) for communication. An LOA is a physical
address (or set of addresses in the case of a replicated object) that
contains information to allow other objects to communicate with the
object (e.g., an \<IP address, port number\> pair).

Legion will contain too many objects to simultaneously represent all of
them as active processes. Therefore, Legion requires a strategy for
maintaining and managing the representations of these objects on
persistent storage. A Legion object can be in one of two different
states, *active* or *inert*. An inert object is represented by an *OPR*
(object persistent representation), which is a set of associated bytes
that exists in stable storage somewhere in the Legion system. The OPR
contains state information that enables the object to move to an active
state. An active object runs as a process that is ready to accept member
function invocations; an active object's state is typically maintained
in the address space of the process (although this is not strictly
necessary).

![](media/image1.wmf)Core objects

Several core object types implement the basic system-level mechanisms
required by all Legion objects. Like classes and metaclasses, core
objects are replaceable system components; users (and in some cases
resource controllers) can select or implement appropriate core objects.

-   ***Host objects***: Host objects represent processors in Legion. One
    or more host objects run on each computing resource that is included
    in Legion. Host objects create and manage processes for active
    Legion objects. Classes invoke the member functions on host objects
    in order to activate instances on the computing resources that the
    hosts represent. Representing computing resources with Legion
    objects abstracts the heterogeneity that results from different
    operating systems having different mechanisms for creating
    processes. Further, it provides resource owners with the ability to
    manage and control their resources as they see fit.

-   ***Vault objects***: Just as a host object represents computing
    resources and maintains active Legion objects, a vault object
    represents persistent storage, but only for the purpose of
    maintaining the state, in OPRs, of the inert Legion objects that the
    vault object supports.

-   ***Context objects***: Context objects map context names to LOIDs,
    allowing users to name objects with arbitrary high-level string
    names, and enabling multiple disjoint name spaces to exist within
    Legion. All objects have a current context and a root context, which
    define parts of the name space in which context names are evaluated.

-   ***Binding agents:*** Binding agents are Legion objects that map
    LOIDs to LOAs. A \<LOID, LOA\> pair is called a binding. Binding
    agents can cache bindings and organize themselves in hierarchies and
    software combining trees, in order to implement the binding
    mechanism in a scalable and efficient manner.

-   ***Implementation objects***: Implementation objects allow other
    Legion objects to run as processes in the system. An implementation
    object typically contains machine code that is executed when a
    request to create or activate an object is made; more specifically,
    an implementation object is generally maintained as an executable
    file that a host object can execute when it receives a request to
    activate or create an object. An implementation object (or the name
    of an implementation object) is transferred from a class object to a
    host object to enable the host to create processes with the
    appropriate characteristics.

Summary

Legion specifies functionality and interfaces, not implementations.
Legion 1.4 provides useful default implementations of class objects and
of all the core system objects, but users are never required to use our
implementations. In particular, users can select (or build their own)
class objects, which are empowered by the object model to select or
implement system-level services. This feature of the system enables
object services (e.g. creation, scheduling, security) to be appropriate
for the object types on which they operate, and eliminates Legion's
dependence on a single implementation for its success.

This work is partially supported by DARPA (Navy) contract #N66001 96-
C-8527, DOE grant DE-FD02-96ER25290, DOE contract Sandia LD- 9391,
Northrup-Grumman (for the DoD HPCMOP/PET program), DOE D459000-16-3C and
DARPA (GA) SC H607305A.

## NCSA Workbench Project

Mary Pietrowicz, Duane Searsmith, Ed Grossman, Larry Jackson

maryp@ncsa.uiuc.edu, d-sears1@uiuc.edu, egrossma@ncsa.uiuc.edu,
jackson@ncsa.uiuc.edu

The NCSA Workbench project proposes to provide a system that is capable
of specifying, finding, and running useful software components and
services from the desktop. Our proposed solution will utilize Java-based
object encapsulation technology developed by SUN (JavaBeans and Jini) to
provide a platform-independent, consistent Java interface to a
time-varying set of resources and services on the Grid.

The Jini technology works as follows:

1)  A Jini service registers with a Jini Lookup Service and provides a
    proxy.

2)  When a client requests a service, the Lookup Service returns the
    proxy.

3)  The client uses the proxy to communicate with the service.

Jini is a componentized system. Its components function outside the
scope of Jini, but together, the parts form a platform for distributed
computing. Its main components include Jini Lookup & Discovery, Jini
Schema, Distributed Events, Distributed Leasing, Distributed
Transactions, and JavaSpaces.

NCSA Workbenches currently are implemented with Web Servers and CGI
scripts. While CGI technology has been very helpful in making scientific
computation codes available via the web, CGI is not a dynamic,
object-oriented approach to the problem. Each individual workbench is
static, and the scripts are hand-maintained. The CGI approach does not
support networked services and does not allow a convenient mechanism of
sharing resources and services among different workbenches. Jini can
help provide dynamic access to resources over the network.

We plan to build an interface to Globus (front-end extensions to the
Globus system), workbench framework that is needed to support the needed
services, and a set of generic services useful in the development of
workbenches. Then, we plan to use the resulting framework and services
in one or more testbeds.

The purpose of the Jini-Globus interface is to provide
platform-independent access to Globus services and resources from the
desktop. A bridge between the Jini Lookup Service and the Globus
resource management subsystem will allow Globus services to register
with Jini. Then, a desktop client can request a service from Jini, and
the proxy returned will interact with Globus to provide the service.
Globus will require front-end APIs so that Jini proxies (written in
Java) can communicate with Globus services easily. A Globus interface
toolkit will provide a generic class hierarchy for building interfaces
to Globus services. We will explore using this toolkit to build specific
interfaces to other existing Globus services such as Security,
Information, Health and Status, etc. The Workbench framework would
provide abstractions of different kinds of workbench services and
service components. The framework would include components for
interfacing with non-Java code and would contain generic services useful
in the development of workbenches. Some of the services we plan to
explore include visualization, notification, sequencing/planning, data
format translation, collaboration, and persistence.

This project is in the early stages and its continuation is contingent
upon the availability of sufficient funding.

## Northrhine-Westphalian Metacomputer Taskforce

Joern Gehring, <joern@uni-paderborn.de>

<http://www.uni-paderborn.de/pc2/nrw-mc/> (currently mostly in german)

Abstract

Combining high-speed networks and high-performance supercomputers offers
great potential for new solutions both in research and development. The
concept of distributed supercomputing (metacomputing) can be employed to
combine forces in order to improve competitiveness of industry and
research. However, there is still much to be done and many new concepts
have to be invented for a working metacomputer. Therefore, in 1995 eight
research

institutions in Northrhine-Westphalia have founded the metacomputer task
force in order to develop a county-wide metacomputer. Since 1996 the
ministry of science and research supports the group to achieve its goal
of providing the power of connected supercomputers to a broad variety of
researches and developers.

One Page Description:

Multimedia, telecommunication, and metacomputing are ey-technologies of
the future. Their availability will be critical for the competitiveness
of local research and industry. These technologies represent a general
trend of synergy between communication, information technology (hard-
and software), entertainment, and mass media. The concept of
Metacomputing continues the idea of making availability of resources
independent from the consumers location. It offers the chance to use the
available hardware more economically and to extend accessibility to a
wider range of users. The Northrhine-Westphalian Metacomputing Task
force was founded in 1995 to support ongoing work and to find new
solutions in this promising field. Up to know, the consortium consists
of the universities of Aachen, Bochum, Dortmund, Cologne, and Paderborn
plus the research institutes GMD (St. Augustin), DLR (Cologne), and FZJ
(Julich). The group focuses on cooperative, multi-site, and
multi-location research on the field of metacomputing within the county
of Northrhine-Westphalia (NRW). We expect major advances in research
through the combined efforts of researches from engineering, natural
science, mathematics, and computer science.

Among the main tasks of the initiative are:

-   performing coordinated research activities

-   support of cooperation between universities, national research
    institutes, and industry

```{=html}
<!-- -->
```
-   providing infrastructure for the Northrhine-Westphalian
    metacomputer.

-   organization of periodic workshops

We explicitly emphasize on the idea of coordinated simultaneous use of
the available computer hardware. This means, that the NRW-metacomputer
not only provides a

Homogeneous user interface for all available resources, but also
supports scheduling and execution of multi-site applications. In 1996
five projects have been started to work on this goal. Each project is a
cooperation of at least two partners and regular meetings were held to
ensure smooth fitting of the developed parts.

The core project aims at developing an infrastructure for
high-performance computer management (HPCM). This is the skeleton of the
metacomputer that links its subcomponents together. The fundamental idea
of HPCM architecture is to define a kind of a three-tier model,
consisting of: a graphical user interface, one or more management
daemons, and coupling modules on the compute servers

Access to the metacomputer is established by a lightweight client based
on a WWW browser. The Java applet loaded while accessing the
metacomputer\'s HTTP address is generating a context specific graphical
interface by using user related informations, e.g. his authorization, or
the state of his transactions.

The central component of the HPCM architecture is the management daemon
that creates the view of a virtual computer. This demon executes on the
HPCM server machines with the task to receive the user\'s requests from
the Java applet, to interpret their semantics, and to submit them to the
related computing instances. To implement this functionality, the demon
needs a global view of the metacomputer\'s components, i.e. joined users
and compute servers. Consequently the MD is the administrative instance
of the metacomputer which is responsible to maintain the

metacomputer related data. Due to the fact that the management demon is
accessing resources on behalf of the user, there is a need for a
security policy. The authentication scheme must also support a single
sign-on environment, to encapsulate the computing instances from the
user.

A coupling module interfaces with each compute server. The operating
system of each participating platform needs to be adapted to the
specified communication protocol and its semantics. This is done as a
daemon process on the compute server. It translates the abstract
management daemon requests to the underlying management software, e.g.
NQS, NQE, DQS, CCS, LSF or CODINE. The advantage of this architecture is
the high degree of system independence.

The infrastructure developed in HPCM is embedded in a DCE/DFS
environment which has been defined and setup by another project. This
environment tackles the problems arising with increasing security
demands and distributed management of a large number of
metacomputer-users and -projects. Additionally it ensures that input and
output data of metacomputer jobs can move freely between the
participating sites without having the users to take extra care of the
current location of their data. The architecture of this system was
designed according to the results of a preceding feasibility study that
was performed as a stand-alone project.

Efficient use of the available resources is ensured by a dedicated
scheduling module that has been developed in the fourth project. This
scheduler cooperates with the HPCM

infrastructure for determining best resources and execution time for
every job that is submitted to the metacomputer. A dedicated resource
description language and a special query syntax have been defined in
order to allow complex resource requests to be optimally fulfilled by
the metacomputer.

The progress and quality of the developed software is continuously
verified by a couple of end-user applications that form the fifth
project. These are real world applications with

Different communication demands. Therefore we can assure that the
metacomputer is no academical experiment but meets the needs of a wide
variety of users.

**References:**

A. Reinefeld and J. Gehring and M. Brune, \"Heterogeneous Message
Passing and a Link to Ressource Management\", Journal of Supercomputing
Special Issue, Vol 11, 1997

V. Sander, \"A Metacomputer Architecture Based on Cooperative Ressource
Management\", HPCN 97, Vienna, Austria V. Sander, \"High-Performance
Computer Management\", HPCN \'98, Amsterdam, The Netherlands

D. Paschek and A. Geiger, \"Molecular Dynamics Simulations of Liquid
Crystals: Examples, Perspectives, Limitations\", Symposium on
Freestanding Smetic Films 97, Paderborn, Germany

## UCLA Java Effort For Collaborative Computing

UCLA Department of Mathematics

CAM (Computational and Applied Mathematics)

Chris Anderson (<http://www.math.ucla.edu/~anderson>)

**Purpose of the effort:** Develop infrastructure to support
collaborative *research* computing

**Goals:**

-   Enable the rapid development of applications composed of components
    created by different individuals and running on different platforms.

-   Enable rapid development of client-server applications for
    scientific computing

**Approach:**

We are using Java to create an infrastructure for distributed computing
as well as to construct tools that assist in creating wrappers for C++
and Fortran based components.

**Results:**

Reports/documents associated with our use of Java for
scientific/technical computing are available electronically at
<http://www.math.ucla.edu/~anderson/JAVAclass/JavaSTC.html>

-   *Putting a Java Interface on your C++, C or Fortran Code*

-   *Creating Distributed Applications in Java Using cam.netapp Classes*

-   *NetApp Wrappers : Higher level construction of distributed
    applications using the cam.netapp package*.

Software is available at
<http://www.math.ucla.edu/~anderson/JAVAclass/CAMJava.html>

## UNICORE: Uniform Access to Computing Resources

<http://www.fz-juelich.de/unicore>

e-mail: D.Erwin@fz-juelich.de

**UNICORE functions**: UNICORE is designed to provide seamless and
secure access to distributed computing resources using the World Wide
Web. It offers the following

-   Intuitive access to all functions through a graphical user interface

-   Platform independent creation of batch jobs

-   Full support for existing batch applications

-   Creation of interdependent jobs to be executed at different sites

-   Secure job submission to any participating UNICORE site

-   Sophisticated job control and monitoring

-   Transparent and secure file transfer between UNICORE sites and to
    the user\'s local system.

The **UNICORE architecture**: UNICORE has a three tier architecture.

A web browser on the user's Unix or Windows desktop supporting Java
Applets and X.509 certificates constitutes tier one. A signed applet,
the Job Preparation Agent (JPA), creates an Abstract Job Object (AJO).

Each UNICORE site operates a gateway running an https server and a
security servlet where the user's certificate is authenticated and
mapped to the local Unix userid. Sites may specify an additional
Security Object to meet more stringent security requirements. The AJO is
interpreted by a Network Job Supervisor (NJS) which incarnates the job
for the local Resource Management System (RMS) or forwards sub-jobs to
other UNICORE sites. NJS synchronizes the execution of interdependent
jobs at multiple sites and manages data transfers between sites.

Tier three, the Resource Management Systems at each execution server and
the local user administration remains unchanged.

The **UNICORE job model**: The Abstract Job Object (AJO) is the basis
for the uniform specification of a job as a collection of interdependent
operations to be carried out on different platforms at collaborating
sites. The object oriented structure of the AJO provides a specification
which is independent of hardware architecture, system interfaces, and
site specific policies. The object oriented design makes the AJO fully
extensible to incorporate additional functions over time. It also allows
for multiple implementations of UNICORE.

The **UNICORE project and partners**: UNICORE is funded as a two year
project by the German Ministry for Education and Research (BMBF). The
target is to develop a prototype by July 1999. The project is structured
in three overlapping phases: Phase one defines the architecture and
implements job creation and submission to one UNICORE site and one
execution platform. Phase two implements job control and data staging
and adds support for additional execution platforms. Phase three
includes distribution of parts of a jobs to different sites, the
synchronization of the interdependent jobs and the automatic transfer of
data between sites. Phase one has been successfully completed and
demonstrated.

The implementation of UNICORE is primarily done by two German software
companies Genias GmbH and Pallas GmbH. German HPC centers and leading
German Universities together with the German weather bureau (DWD), ECMWF
and fecit in the UK, are responsible for design, test, and operation of
UNICORE. Major HPC vendors, Fujitsu, IBM NEC, SNI, SGI support UNICORE
and provide know-how and manpower. Hitachi and Sun are joining the
UNICORE consortium.

## WebSubmit: A Web Interface to Remote High-Performance Computing Resources

Ryan McCormack, John Koontz, and Judith Devaney

Information Technology Laboratory

National Institute of Standards and Technology

{john.koontz, judith.devaney, ryan.mccormack}@nist.gov

<http://www.itl.nist.gov/div895/sasg/>

<http://www.itl.nist.gov/div895/sasg/websubmit/websubmit.html>

WebSubmit is a Web browser-based interface to heterogeneous collections
of remote high-performance computing resources. It makes these resources
easier to use by replacing a constantly changing range of unfamiliar,
command-driven queuing systems and application environments, with a
single, seamless graphical user interface based on HTML forms. To do
this WebSubmit provides what is essentially a Web-based implementation
of telnet: direct access over the Web to the individual users\' accounts
on

the systems in question.

To secure these accesses against unauthorized use we use a strong form
of authentication based on the Secure Sockets Layer (SSL) protocol and
Digital Certificates. This lets certified users registered with a
WebSubmit server connect to the server over SSL encrypted lines, and,
when authenticated by the server, interact with a set of application
modules. Each of these application module is implemented as an HTML
form, generated dynamically with a CGI script. The application module
form is filled out and submitted to the WebSubmit server, where it is
processed by a second CGI script. This second script processes the
request and executes the desired tasks in the user\'s account on the
specified remote system. For this it uses the Secure Shell protocol,
which provides an encrypted line from the server to the user\'s account
on the remote system. The processing script also generates a Web page
reporting the results of the immediate interaction. However, if the task
was to submit a job, the user must use additional modules to follow the
progress of the job and retrieve its output.

The combined system is secure, flexible, and extensible. It does not
require the Web server to be located on the high-performance computing
resources. Its modularity facilitates developing and maintaining
interfaces. And, since the application modules for similar tasks on
different computing resources use the same interface (as much as
possible), they present a uniform aspect that facilitate usage.

Two different classes of application modules are currently available
under WebSubmit:

-   system-independent modules, useful for all resources connected via
    WebSubmit, and

-   system-dependent modules, supporting generic job submission and
    queriesto particular resources, and access to applications specific
    to these resources.

The system-independent modules available are a UNIX command facility, a
simple file editor, and an interface for file transfer. System-dependent
application modules are currently available for three major batch
queuing systems (LoadLeveler, LSF, and NQS). The more generic modules
allow users to submit jobs and monitor them. There are also some
specialized submission modules for some of these systems. These support
particular kinds of submitted jobs, e.g., MPI jobs or runs with the
commercial Gaussian application.

To aid users in repeating tasks and deriving new ones, we provide a
session library facility that allows users to save their module
parameters in named sets. There is also an on-line help facility to
provide explanations of elements in each module\'s interface.

Although our application is access to high-performance computing
resources, plainly WebSubmit can be adapted to other forms of Web-based
remote execution of user-owned tasks.

WebSubmit is written in the open source scripting language Tcl, by
Scriptics. Our own Tcl code consists of the set of CGI scripts plus a
collection of supporting libraries. We also use the cgi.tcl library, by
NIST\'s Don Libes. We currently support execution from Unix-based
browsers to Unix computing resources.

## WebFlow: Web Based Metacomputing

Tomasz Haupt, Erol Akarsu, Geoffrey Fox

Northeast Parallel Architectures Center at Syracuse University

Programming tools that are simultaneously sustainable, highly
functional, robust and easy to use have been hard to come by in the HPCC
arena. Following our High Performance commodity computing (HPcc)
strategy that builds HPCC programming tools on top of the new software
infrastructure being developed for the commercial web and distributed
object areas. This leverage of a huge industry investment naturally
delivers tools with the desired properties with the one (albeit
critical) exception that high performance is not guaranteed. Our
approach automatically gives the user access to the full range of
commercial capabilities (e.g. databases and compute servers), pervasive
access from all platforms and natural incremental enhancement as the
industry software juggernaut continues to deliver software systems of
rapidly increasing power. We add high performance to commodity systems
using multi-tier architecture with GLOBUS metacomputing toolkit as the
backend of a middle tier of commodity web and object servers.

More specifically, we developed WebFlow - a platform independent,
three-tier system. The visual authoring tools implemented in the front
end integrated with the middle tier network of servers based on the
industry standards and following distributed object paradigm, facilitate
seamless integration of commodity software components. The high
performance backend tier is implemented using GLOBUS toolkit: we use MDS
(metacomputing directory services) to identify resources, GRAM (globus
resource allocation manager) to allocate resources including mutual, SSL
based authentication, and GASS (global access to secondary storage) for
a high performance data transfer. Conversely, the WebFlow can be
regarded as a high level, visual user interface and job broker for
GLOBUS.

The visual HPDC framework delivered by this project offers an intuitive
Web browser based interface and a uniform point of interactive control
for a variety of computational modules and applications, running at
various places on different platforms and networks. New applications can
be composed dynamically from reusable components just by clicking on
visual module icons, dragging them into the active WebFlow editor area,
and linking by drawing the required connection lines. The modules are
executed using GLOBUS optimized components combined with the pervasive
commodity services where native high performance versions are not
available. For instance today one links GLOBUS controlled programs to
WebFlow (Java connected) Windows NT and database executables. This not
only makes construction of a meta-application much easier task for an
end user, but also allows combining this state of art HPCC environment
with commercial software, including packages available only on
Intel-based personal computers.

Our prototype WebFlow system is given by a mesh of Java enhanced Web
Servers \[Apache\], running servlets that manage and coordinate
distributed computation. This management is currently implemented in
terms of the three servlets: Session Manager, Module Manager, and
Connection Manager. These servlets are URL addressable and can offer
dynamic information about their services and current state. Each of them
can also communicate with each other through sockets. Servlets are
persistent and application independent. Although our prototype
implementation of the WebFlow proved to be very successful, we are not
satisfied with this to large extend custom solution. Pursuing HPcc
goals, we would prefer to base our implementation on the emerging
standards for distributed objects, and takes the full advantage of the
possible leverages realized by employing commercial technologies.
Consequently, we plan to adopt CORBA as the base distributed object
model.

This short note describes only the major design features of the WebFlow.
For more detailed information, please refer to the WebFlow home page at

<http://www.npac.syr.edu/users/haupt/WebFlow/demo.html>