Digital Technical Journal, Volume 6, Number 4 Dtj_v06 04_1994 Dtj V06 04 1994

dtj_v06-04_1994 dtj_v06-04_1994

User Manual: dtj_v06-04_1994

Open the PDF directly: View PDF .
Page Count: 108

Download
Open PDF In Browser	View PDF

•
•
•

RAID Array Controllers

Workflow Models
PC LAN and System Management Tools

Digital Technical Journal
Digital Equipment Corporation

Volume 6

Number 4
Fall 1 994

Editorial
Jane C. Blake, Managing Editor
Kathleen M. Stetson, Editor
Helen L. Patterson, Editor

Circulation

Catherine M. Phillips, Administrator
Dorothea B. Cassady, Secretary

Production
Terri Autieri, Production Editor
Anne S. Katzeff, Typographer
Peter R. Woodbury, Illustrator

Advisory Board
Samuel H. Fuller, Chairman

Richard W Beane

Donald Z. Harbert
William R. Hawe

Richard]. Hoi I ingsworth
Richard F Lary
Alan G. Nemeth
Jean A. Proulx
Robert M. Supnik
Gayn B. Winters

The Digital Technicaljournal is a refereed journal published quarterly by Digital
Equipment Corporation, 30 Porter Road '"102/D 10, Littleton, Massachusetts 01460.
Subscriptions to the journal are $40.00 (non-U.S. $60) for four issues and $75.00
(non-U.S. $115) for eight issues and must be prepaid in U.S. funds. University and
college professors and Ph.D. students in the electrical engineering and computer
science fields receive complimentary subscriptions upon request. Orders, inquiries,

and address changes should be sent to the Digital Technicatjournal at the published­
by address. Inquiries can also be sent electronjcally to dtj@digital.com. Single copies
and back issues are available for $16.00 each by calling DECdirect at 1-800-DIGITAL

(1-800-344-4825). Recent back issues of thejou·rnal are also available on the Internet
at http://www.digital.com/info/DTJ/home.html. Complete Digital internet listings can
be obtained by sending an electronic mail message to irtfo@digital.com.
Digital employees may order subscriptions through Readers Choice by entering

vrx

PROFILE at the system prompt.
Comments on the content of any paper are welcomed and may be sent to the managing
editor at the published-by or network address.
Copyright© 199 5 Digital Equipment Corporation. Copying without fee is permitted
provided that such copies are made for use in educational institutions by faculty mem­
bers and are not distributed for commercial advantage. Abstracting with credit of
Digital Equipment Corporation's authorship is permitted. All rights reserved.
The information in the journal is subject to change without notice and should not be
construed as a commitment by Digital Equipment Corporation or by the companies
herein represented. Digital Equipment Corporation assumes no responsibility for any
errors that may appear in the journal.
ISSN 0898-901X
Documentation Number EY-Tll8E-TJ
The following are trademarks of Digital Equipment Corporation: AXP,

Cl,

DEC, DEC OSF/1,

DECmcc, DECmodel, DECnet, DECwindows, Digital, the DIGITAL logo, HSC, HSC50,
HSC60, HSC70, HSC90, HSJ, HSZ, InfoServer, KDM, ManageWORKS, Object Flow, OpenVMS,
PATHWORKS, POLYCENTER, StorageWorks, ULTRIX, VAX, VAXcluster, VAXstation, VMS,
and VMScluster.
Apple and AppleShare are registered trademarks of Apple Computer, Inc.
dBase IV is a registered trademark of Borland International, Inc.

Cover Design
Our cover design is inspired by a system man­

agement topic in this issue. Manage WORKS

software is a system and network manage­
ment tool that presents an object-oriented,
graphical view of a heterogeneous LAN envi­
ronment. The multi color circles on the cover
represent the diverse objects, or entities, on
the networks among which a system adminis­
trato-r "navigates" using the integrated com­
ponents of the tool.
The cover was designed by Lucinda O'Neill

Hewlett-Packard is a registered trademark of Hewlett-Packard Company.
i960 is a trademark of Intel Corporation.
IBM

and NetView are registered trademarks of International Business Machines
Corporation.

Knowledge Craft is a registered trademark of Carnegie Group, Inc.
Microsoft and Visual C++ are registered trademarks and Windows and Windows NT
are trademarks of Microsoft Corporation.
NFS is a registered trademark of Sun Microsystems, Inc.
NetWare and Novell are registered trademarks of Novell, Inc.
OSF/ I is a registered trademark of the Open Software Foundation, Inc.
Sun M icrosystems is a registered trademark of Sun Microsystems, Inc.
UNIX is a registered trademark in the United States and other countries, licensed
exclusively byX/Open Company Ltd.

andjoe Pozerycki,jr:, of Digital's Design

X Window System is a trademark of the Massachusetts Institute ofTechnology.

Group.

Book production was done by Quantic Communications, lnc.

I

Contents
RAID Array Controllers

5

The Architecture andDesign of HS-series
StorageWorks Array C ontrollers
Stephen ]. Sicola

Workflow Models

26

Policy Resolution in Workflow Management Systems
Christoph ]. BuBier

50

TheDesign ofDECmodel for Windows

Stewart V Hoover and Gary L. Kratkiewicz

PC LAN and System Management Tools

63

TheDesign of ManageWORKS: A User
Interface Framework
Dennis G. Giokas and Joh n C. Rokicki

75

The Structure of the OpenVMS Management Station
James E. Johnson

89

Automatic, Network-directed Operating System
Software Upgrades: A Platform-independent Approach
John R. Lawson , Jr.

I

Editor's Introduction
explain the reason i ng behind the creati o n of a pre­
sentation layer in DECmoc.l el that provides a graphi­
cal view of the business process while h iding the
technical details of the mode l . The authors also
cover i m plementation detai ls, i n c l u ding the deci­
sions to move from the original !.IS!' environment to

a C:++ program m i ng environment and to i mple­
ment the knowledge base for DECmodel in ROCK,
a frame-based .knowledge representation .
We t hen shift the focus to ManageWORKS and
POLYCENTER tools that have been developed to

Jane C. Blake

Managing Editor

simp l i fy the increasingly compl icated job of system
management. The first of three papers describes
the development of the ManageWORKS Workgroup
Administrator software. Dennis Gio kas ami John

Three computing topics are presented in this issue

Rokicki d iscuss the design principles adopted for

of the journal: a storage array controller for open

this product that enables system and network man­

system environments, workflow architectures and

agement of heterogeneous L.A Ns from a single PC

tools, ancl PC andlAN system management products.
The ope n i ng paper, by Steve Sico l a, describes

Digital's new HS series of StorageWorks array con­

running Microsoft W i ndows. Key design elements
are plug-in ,

customizable

modu les for system

navigation ancl management, ami the user i n ter­

tro l lers. Designed for open systems, the con trol­

face framework, w hich controls the flow between

lers i nterface to host computers by means of the

modu les. The authors offer scenarios to i l l ustrate

i ndustry-standard SCSI-2 i n terconnect, as wel l as

interactions between components.

Digi tal's CI and OSSI host i ntercon nects. Equal ly

Managing OpenVMS systems from a PC runn ing

i mportant to designers as openness were con troller

the Microsoft Windows operating system can be

availab i l i ty and performance. I n novative features

accomplished with the OpenVMS Management

were i ntroduced, i nclud ing dual - redundant con­

Station, of which ManageWORKS is a key compo­

trol lers and Parity RAID firmware to ensure high

nent. Jim Johnson defines the need for this scalable

availability, and a wri te-back cache that significantly

and secure cl ient -server tool in OpenVMS envi­

improves performance. The paper concludes with

ronments, which can be clustered, d istributed ,

a description of the com mon controller processing

expanded, and networked extensively. After a d is­

core for the SCSI, CI, and DSSI contro l ler variants.

cussion of design alternat ives, Jim describes the

Workflow is the subject of two papers w ith d i f­
fering perspectives. Christoph BuBier opens his

fu nctions of the Stat i on's c l ient, communication,
and server components.

paper with introd uctory defi n i t i o ns and i m p I ica­

The fi nal paper is abo u t an in iti a l system load

tions of workflow concepts. He argues that a \ovork­

(ISL) capabil i ty for automatic, network-directed.

flow t hat uses roles fo r task assignment is l imited,

operating system software upgrades. John Lawson

especial ly i n large. i nternational enterprises. He

reviews goals for the POLYCENTER Software Distri­

states that by adding the d i mensio n of organiza­

bution layered product, compares the POLYCENTER

t io nal dependencies for task assignment a complex

ISL process with the OpenV:VIS ISL p rocess. and

workflow is more precisely expressed . Using the

steps through the requirements for expanding the

example of a travel expense rei mbursement work­

l'OLYCENTER Sofnvare Distribution capab i l i ty to

flow, Christoph shows how the Pol icy Resolution

other platforms and operating systems.

Architecture design principles support en terprise­

Our next issue w i ll celebrate the Journ a l's tenth

level workflow deployment-reusab i l ity, securi t y,

ann iversary of publ ishing the technical ach ieve­

general ity, dynamics, and d istribution . He also d is­

ments of Digi tal 's engineers and partners. The issue

cusses the Pol icy Defi n i t i o n Language that formal ly

will feature database technol ogies and new Alpha

describes workJlow elements.

workstations ancl h igh-end server systems.

A second paper about workflow presents a tool,
cal led DECmodel for W indows, for the development
of business p rocess models and their graph ical
presentat i o n . Stew Hoover and Gary Krat k iewicz

2

I

Biographies

Christoph J. BuBier

Christoph BuGler is a fac u lty member at the Technical

University of Darmstadt, Germany, where he is pursuing a Ph.D. degree. His
research is in workflow and organization modeling, with a focus on organizational
embec.l cling of workflow management, ancJ i n architectures for enterprise-wic.le
deployment of workflow management systems. While at Digital from 1991 to 1994,
Christoph developecJ the Policy Resolu tion Architecture and its prototype imple­
mentation. He ho lds an M .C.S (1990) from the Technical University of Mu nich ancJ
has published many papers o n workflow management and enterprise modeling.

Dennis G. Giokas

Dennis Giokas is currently a senior associate with

Symmetrix, Inc. W hile at Digital from 1984 to 1995, he was a consulting engineer
in the PATHWORKS group. He co-led PA1HWORKS VS.O and archi tected the user
interface ami system m anagement tools. He was a lso architect and m anager for
the PC DECwindows program. Previously, Dennis worked at Arco Oil & Gas and
The Foxboro Company developing process control software. He holds a Bachelor
of Music from the University of Massachusetts at Lowell, a Master of Music from
the New England Conservatoq', and an M.S.C.S. from Boston U niversity.

Stewart V. Hoover

EmployecJ at Digital Equipment Corporation between

1984 and 1994, Stew Hoover is currently a n i ndepenc.Jent consu ltant specializing
in modeli ng ancJ simulation. Before j o ining Digital, he was an associate professor
of i ndustrial engineering ancJ inform ation systems at Northeastern University.
Stew contribu ted to the deve lopmen t of the DECalc-PLUS appl ication, Statistical
Process Control Software (SPCS), and the DECwindows version of Symmod. He
has written many papers and articles o n simu lation and i s coau thor of

Simulation, A Problem-Soluing Approach, publ ished by Addison-Wesley.

James E. Johnson

A cons u l ting software engineer, J i m Johnson has worked

in the Open VMS Engineering Group since joining D igital in 1984. He is currently
a member of the OpenVMS Engineering team i n Scotland, where he is a technical
consu ltant for transaction processing and file services. His work bas spanned
several areas across OpenVMS, i ncluc.l ing RMS, the DECc.ltm transaction services,
the port of Open VMS to the Alpha architecture, and Open VMS system m a nage­
ment. Jim holds one pate n t on com m i t protocol optimizations. He is a member
of the ACYl.

3

Biographies

Gary L. Kratkiewicz

Gary Kratkiewicz is currently a scientist in the I n tel li­

gen t Sy s te m s R&D Group at Bolt Beranek and Newman Inc. As a principal engi­
neer in Digita l 's DECmodel engineering group from 1991 to 1994, Gary
coordinated the architecture and high-level design specifications, and c.lcvel­

oped the knowledge base, script engine, API, and several user interface modu les.
Earlier at Digit a l , be developed an expert system fo r shipping and was project
leader for a knowledge-based logistics system. Gary holds a n S. B . M . E. from ,\'liT
and an M.S. in manufacturing systems engineering from Stanford University.

john R. Lawson, Jr.

John Lawson joined D igital in 1984. He has been a mem­

ber of the OpenWns.

resources across shared device ports.
The storage fault-tolerance goal was to develop
firmware support for controller-based redundant

Another approach to reduce latency was to
develop

controller-based

disk

striping,

i.e.,

implement the HAU) level 0 technology.2 Specific

array of inexpensive disks (RAID). 2 The initial

goals were to achieve parallel access to all RAID

Parity RAID implementation incorporated the

level 0 array members for read and write opera­

best attributes of RAJD levels .3 and ). The design

tions ancl to streamline firmware to increase

provided the basis for later implementations of

RAJD level 0 pert()rmance.

other forms of RAJD technology, notably mirror­
ing. Parity RAJD supports the goal of storage fault

tolerance by providing tor continued l/0 service
from an array of several disks in the event that
one disk fails. StorageWorks packaging that pro­
vides redundant power supplies and cooling
should be combined with the Parity RAJD tech­
nology to extend storage fault tolerance.

.3. High performance. The goals for high perfor­
mance were to specify controller throughput
(the number of I/O operations per unit of time),
latency (responsiveness). and data transfer rate
(controller bandwidth) for each of the three con­
troller platforms: Cl, DSSI, and SCSI. The through­
put was specified in the maximum number of
read and write requests executed per second.
The controllers had to speed up the response
time for host I/O operations and thus clel.iver data

The Parity RAID performance goal was to over­
come the well-known weaknesses of RAID level

3 (i.e., poor transaction throughput) and RAID
level 5 (poor small-write performance) and to
approach RAID level 0 striped array performance
for both small and large read and write requests.2
A combination

of

hardware-assisted

parity

computations and write-back caching helped
achieve this goal. Parity calculations in hardware

reduced firmware overhead to complete RAID
level 5 write operations. Write-back caching
minimized the effects of the RAID level ) small­
write penalty.; To meet the needs of customers
who require high data transfer rates \Vith RAID,
RAID level 3-style algorithms must be added for

the Parity RAID design.
A common controller processing core had to
be architected and designed to meet the perfor­

with lower command latency than the HSC con­

mance nee(ls of all the planned StorageWorks

trollers. StorageWorks controllers had to achieve

controllers (based on host interface capabili­

the highest possible data transfer rate and were

ties). The platform had to execute the same base

to do so on a common platform.

firmware, coupling new host interface firmware

The platform-specific controller throughput
goals were as follows. The initial goal for the Cl­
to-SCSI controller was 1,100 read requests per
second; the long-term goal was 1,500 to 1,700

to the specific platforms. A common platform
was believed to ease product development and
to maximize reuse of firmware for the same
"look and feel" in all products.

read requests per second. The initial goal for the
D SSI-to-SCSI controller was 800 read requests per
was

I ,300 read

For Storage Works controllers to enter the open sys­

requests per second. The initial goal for the SCSI­

tems market, product designers had to consicler

second; the long-term goal

to-SCSI controller was 1,400 read requests per

the following aspects of open systems in the con­

second; the long-term goal was 2,000 read

troller definition: the use of industry-stanJarc.l

requests per second. The controller throughput

device interconnects and industry-standard devices

t()r write operations was slightly lower.

attached to the control ler, and the use of incl. ustry­

To reduce latency, the controller hardware and
firmware implemented controller l/0 rel lowing sectio n . The main issue is to con­

both controllers. The cache LOCK sig n a l s are

tion with Parity RAID operations for the reasons

tinue to provide as much data protection as possi­

exclusive access to a specific cache modu le to

ble for Parity RAID disk configurations when the

ensure data i ntegrity. LOC K signa ls from a con­

battery on the write-back cache is low or bad.

trol ler that has been " kil led" by its dual-redundant
partner are reset so t hat the partner m ay fail over
any unwritten cache data in the write-hack cache.

•

The contro l ler is u n able to commu nicate with
the devices to which it is currently a l located for
host operations. 'T'his situation c a n occur if

Failouer

Con trol ler faiJover is a feature of the

a device port on a contro l ler fails.

dua l - redu ndan t configuration for Sto rageWorks
con tro l lers. Failover of a control ler's devices and
cache to the other con trol ler occurs when
•

A control ler fails to send the keep a l ive message.
This situation can occur because of a control ler
failure in the dual UART (DlJART)

or

in any other

non-fau lt-tolerant portion of the contro l ler mod­

Storage Fault Tolerance
Storage fau lt tolerance is achieved by ensuring t hat
power or e nvironmental factors do not cause
devices to be u navail able for host access a nd by
using firmware to prevent a device fail u re from
affecting host accessibi l ity.

u le. In this scenario, the surviving contro l l er uses
Enuironmenta/ Factors

com m unicates to the failed con tro l ler's devices.

provide for optional redundant power supplies and

and then serves the failed contro l ler's devices to

cooling fans to prevent power or fan failures from
making devices u navai l a b l e . The SCSI-2 cables that

hosts.
The failover of a control ler's cache occurs only if
write-back caching was in use before t he con­
tro l ler fail ure was detected . In this cas e . the sur­
viving control ler uses the failed contro l ler's
cache to write a n y previously u nwritten data to

the failed control ler's disks before serving these
dis ks to hosts. When the surviving control ler has
written the data to disks (i.e. , f l ushed the data),
it releases the cache to await the failed c o n­
tro l ler's return to the dual-redu ndant con figura­
tion through reinitialization
•

or

rep l acement.

A customer desires to change the load balance of
one or more devices at tached to one co ntro l ler

to the other contro l ler. This specia l ized use

of failover provides a load-ba l a ncing feature

12

StorageWorks enclosures

the K I Ll. s ignal to disable the other controller,

con nect device shelves to the con trol ler shel f carry
extra signa l s to a lert the control ler to power supply
or fan fail ures so that t hese conditions may be
reported to host com p u ters. 'T'he enclos u res must

contain l ight -em i t ting d i odes (LEOs) to a llow a con­
trol ler to iden tify failed devices. In addition, a
cache m od u l e can fail , and the con troller wil l con­
tinue to O]Jerate.
RA ID Technology

Tb prevent a device fai l ure

from a ffecting host access to dat a , the designers
i ntroduced a combined firmware and hardware
implement a tion of RAID technology. 2 The designers
had to decide which RAID level to choose and what
tvpe of hardware (if any) was required fo r the
implementatio n .

llri/.

6

;Vu. i

/-{Iff !')') 1

Dip
, ita/ Tecbuica / journal

The Architecture and Design of HS-series StorageWorks Array Con trollers

The designers considered RAJD levels 1 through 5

be protected i mpl ies an i n herent cost of one

as opti ons fo r solv ing the problem of disk fai l ­

add itional housed , powered , and attached d isk.

ures t h a t affect data ava ilabil ity. RAID level 1 (disk

RAID level 1 was a l so discounted because software­

mirroring, which is depictecJ in Figure Sa) was

based solutions were available for many of the

rejected because of its higher cost, i . e . , the cost of

hosts for which the HS-series control lers were i n i­

parts to i mplement the mirroring 2 Each d isk to

tially targeted .

DATA DISKS

CHECK DISKS

(a) Mapping fur a RAID Level

1

A rray

(c) Mapping for a RAID Leve/ 3 A rray

(e)

(d) Mapping for a RAID Leue/ 4 Array

A Typical Mapping for a RAID Level 5 A rray

Figure 5

D igital Technical journal

(b) Mapping for a RA ID Level 2 A rray

Vol. 6 No. 4

Mappingfor RAID Levels

Fal/ 1994

1

through 5

13

RAlD Array Controllers

RA I D levels 2 through 4, i l l us t rated in Figures 5 b

•

t h rough 5d, were rejected because t hey do not pro­

A co n tro l ler fa i l u re occurs with a host's write
request o u tstand i n g .

v i d e goo d performance over t he e n t ire range of

•

1/0 workJoads for which the c o n t ro l l e rs were tar­

E i ther t h e u p d a ted data or the u p dated p a r i t y t()r
the host's write request bas been wri t te n to d is k

get e d . 1 In gen eral , these RAID leve l s prov ide h i g h ,

b u t not both .

s ingle-stream data transfer rates b u t relative l y p o o r
transact i o n processing performance.

•

RAID level 5 i n its p u re for m was rejected because

A fa i l u re of a d i fferent d isk occurs after t he con­
t ro l ler fa i l ure has been re paired .

o f its poor write perfo r m ance, espec i a l ly for s m a l l

To e l i m i n are t h i s w r i te h o l e , designers bad to

write opera t i o n s . ! T h e designers u l ti m a t e l y chose

develop

RAID level 5 data mapp i n g (i . e . , data striping w i t h

i n terleaved parity, a s i l l us t rated i n Figure 5 e ) cou­

a

method of preserving i n fo r m a t i o n about

o ngo i n g RA I D w r i te operations across power fa i l ­

pled with d y n a m i c update a lgo r i t h m s and wri te­

u res s u c h t ha t i t co u l d be c onveyed between p a rt ­

back cac h i ng to overcome t he sm a l l -w r i te pena l t y.

n e r contro l lers i n a d u a l - re d u nd a n t configura t io n .
Designers decided to use n o n vo l at i l e caching of

Th is i mp l e m e n t a t i o n is cal led Parity RAI D .

IWD write opera t i on s i n progress 5 Three a lterna­

An HS-series P a r i t y RAID array appears t o hosts as
an

eco n o m i c a l , fau l t - toler a n t v i r t u a l

disk

tives were consid ered :

u n it .

A Parity RAID v i r t u a l d isk u n i t w i t h a storage capac­
i ty equ iva l e n t to that of n d isks requ i res
ical

d isks

to

i mplement .

Data

n+ 1

and

1 . An u n interr u p t i b l e power supply (UPS) fo r the

phys­

parity

control ler, cache, a n d a l l a ttached d isk dev ices.

are

This choice was d eemed to be a costly a n d

d istri buted (s tri ped) across a l l d i s k members in the

u nwieldy s o l u t i o n bec<�use of t h e range of possi­

array, primari ly to equal ize the overbe r Parity RAID firmware

40

wou l d speed u p RAI D pari t y c a l c u l a t i o ns and th u s

0
0
w

fur ther i mprove P a r i t y RAID l atency a n d t h rough­

� 30

p u t . The firmware also supports FX compare opera­
t i o n s , w h i c h e l i m in a tes t he need fo r SCSI-2 devices
that have impl e mented compare com mands and fo r
speeding up compare requ ests from hosts.

WORKLOAD 1

WORKLOAD

2

WORKLOAD

3

KEY

R E A D CACH E
WRITE-BACK CAC H E

Figure 8

To prod u ce a h igh-perfo r m a n ce c o n t ro l l e r i n a l l
t h ree perfo r m ance d i mensions-latency, t h rough­

J BO D ARRAY M O D E L

D
0

Cmnmon Hardware Platform

PARITY R A I D ARRAY M O D E L

•
0

R E A D CAC H E
W R I TE-BACK CAC H E

H�/40 Art'C�J' Latenq Comparisons

put,

and

clara

transfer

ra t e - t he

d esigners

of

Sto rageWorks c o n t ro l l e rs faced the c h a l lenge of
crea ting a new c o n t ro J ie r arch i tectu re ami u sing
new techno logy. I n a d d i t io n , t hey bad to do so at
a reasona b le cost.
A l though each has i t s own specific host i nterface

and Parity RAID u n i ts ( i n a five-pl u s - o n e con figu ra­
t ion) . The p e r fo r m a nce measu re m e n t s were t a k e n
from a versi o n 2.0 I-JSJ40 array contro l l e r.
Wor k load 1 has a read/write ratio of 70/30. i . e . ,
70 percent o f t h e requests were read req uests a n d
:)0 percent were write req uests. Wo r k l oa d 2 has
a read/write ratio o f 84/ l(>. Workload

3 has a ratio of

20/80 I n al l workloa(IS, the l a tency for i nd iv i d u a l
devices a n d fo r Parity RAm u n i t s i s lower when
write-back caching is enabled than when only read
cac h i ng is enabled. I n fact, when write operations

d o m i nate the 1/0 m i x , l a tency for Parity RAJD u n its
is the same as for the workloads i n which read oper­
ations are predom i n a n t '

RAID/Compare Hardware

hardware, t he Cl, DSS!, a m i SCSI c o n t ro l le r variants
share a com m o n h a rdware core. Com m o n a l i t y
was d esired to c o n t ro l the llevelopment costs and
sched u les for such l arge e ng i n eeri ng projects. To
del iver h i g h p e r formance a n d c o m m o n a l i t y, the
designers inves t igated seve ra l c o nt ro l le r archi tec­
t u re al terna tives. T he first a rc h i tectu re consid ered

was s i m i l a r to D igita l 's HSC'iO-':)'i con trol l e r, i ncor­
porat i ng s i m i l a r bus s t r u c t u res, processing ele­
ments,

and

memories,

but

newer

Figure ':) shows the HSC a rch i tec t u re . 0

technology.

T h e HSC architecture is a t r u e m u l t iprocessor sys­

tem . It contains a private memory for its pol icy pro­
cessor, w h i ch m a n ages the work t h a t is coming

from t h e host p o rt i n terface ami queues t h is wo r k

to the device i n terface m o d u les. Data t he n fl ows
between the host p o rt and d e v ice m o d u les to ami

Storage Works control lers contain a hardware Parity

from

RAI D ami data compare accelerator called FX, a gate

( b uses) fo r access to co m m and process ing and data

array that performs o n - the-fly XOR operations on

data buffers. Parity RA I D ami data compare firm­

hosts.

The m o d u les have two i n t e rfaces

movement. These buses are ca l led the control mem­

ory i n terface a mi the data memory i n terface. The

ware use t h is gate array to accelerate Parity R A I D

p o l i c y processor queues work to the host port a n d

parity calcu l at i o n s ami host data compare req uests.

device m o d ules through the c o n t ro l m e m o r y i n ter­

(1) observe the bus,
(2) " s n oo p " t he bus for specifi c add resses, (3) p e r­

face, and t he n the m o d u les process the clara over

'T'he FX chip is progra m med to

the data mem ory i nte rface.

fo rm the XOR o p e ra t i o n to compare the associated

Using this arch itecture wou l d have been too

data o n - t he-fly w i t h data in a private memory called

expensive. The c o n t rol ler cost had to be competi­

XBliF m e m o ry, a n d (4) w rite the data back i n to

t i ve w i t h other p ro d ucts in the i nd u s try, most

the X BUF memory.

o f w h ich c u r re n t l y cost considera b l y l ess t h a n t he

XOR operations can take p l ace as d a t a is moving

HSC c o n t ro l ler. The HSC b u s arch itecture requ i red

from bu ffe r o r cache mem ory to d ev i ce ports o r

t h ree d i ffe re n t memory i n t erfaces, which wou ld

vice ve rsa . T h e FX can a l s o p e rform d i rect memory

access ( D i'vlA) opera t i o n s to move t h e contents of
b u ffe r o r cache mem o ry to o r from XBUF memory.

20

requ ire t h ree d iffere n t , poten t i a l lv large mem ories.
The designers h a d to p u r s u e other options t h a t
m e t the c o s t goals b u t d i d n o t significa n t ly reduce

\1J/ G No. 4

/·all 1')94

D igital Tee/mica/ jourua/

The Architecture and Design of HS-series StorageWorks Array Controllers

CONTROL BUS (6.6 MB/S)

CONTROL
MEMORY

<

CI BUS

HOST INTERFACE

POLICY
PROCESSOR

8

8

L

DISK INTERFACE
OR
TAPE INTERFACE
(UP TO 8 TOTAL)

TERMINAL

8

>

DATA
MEMORY

I

LOAD
DEVICE

r--

r--

. ·· I

DATA BUS (1 3.3 MB/S)
Figure 9

1....:...

I

SOl OR STl
{4 PER
INTERFA CE)

Block Diagram of the HSC Architecture

performance. They considered single internal bus

icy processor to access one memory whi le a device

architectures, but during simul ation , these options

or host port processor accesses the other memory.

were unable to meet either the initial or the l o ng­

The architecture achieves a lower overa l l cost
than the HSC architecture yet ach ieves similar

term cost goals.
10 shows the controller architecture

performance. The new architecture, with fewer

option that became the common hardware base for

memories, does not significantly reduce the perfo r­

Figure

StorageWorks control lers. This architecture con­

mance, while the newer technology chosen to

tains three buses ami two memories. A third s m a l l

i m p lement the contro l ler enhances performance.

memory is used for Parity RAJD a n d d a t a compare
operations but does not drastically increase con­

The bus bandwidth of the new controller is much

trol ler cost. The architectural design aJ Jows the pol-

quentl y, a more cost -effective solu tion that uses

higher than that of the HSC control ler. Conse­

,.-------, ,-------, ,.------, ,.-----..., ;---

32-KB
32-KB
INSTRUCTION
AND DATA CACHE NV RAM

I

i960
MICROPROCESSOR

PCMCIA
PROGRAM
CARD (2 MB)

I

I

I

DUAL
UART

IBUS BUS

TIMER
HARDWARE

CONTROL
REGISTERS

I

I

1 6- OR 32-MB
READ OR
CACHE
BUS )C===C=D=A=L=B=U=S=::::)I DR AB BATTER
Y
EXCHANGER
BACKED UP MODULE
WRITE-BACK
CACHE

BUFFER
MDAL BUS
MEMORY DRAB
(8 MB)
NBUS BUS

I

DEVICE PORT
HOST PORT
0
{CI, DSSI, SCSI) 53C71
PROCESSOR

I

DEVICE PORT
53C71 0
PROCESSOR
Figure

D igital Teclm icaljournal

Vol.

6 Nn. 4

10

Fall 1994

DEVICE PORT
53C710
PROCESSOR

I

DEVICE PORT
53C710
PROCESSOR

I

DEVICE PORT
53C710
PROCESSOR

I

DEVICE PORT
53C71 0
PROCESSOR

HSx40 Controller Architecture

21

RAID Array Controllers

a less-cost ly arch i tecture can attain s i m i l a r to better

m o d u l e , the designers fel t t h a t the benefits o f such

performance.

a design o u t weighed the addition a l cost.

large- scale i ntegration (VLSI) level a l lowed for a

fir m w a re image on the program card and cop ies the

The extreme i n tegra tion of hardware to the very

On each initia lizatio n, the c o n tro l ler reads t he

much smaller enclosure than that of the HSC control­

i m age to t h e s h a red memory. The fi rmware exe­

ler, even with a dual- redundant controller configura­

cu tes from t he shared b u ffer m e m o ry.

t io n (see Fig ure 3).

A

StorageWorks d u a l - controller

co nfig ura tio n measures 56.5 by 20.9 by 43.2 centi­

Dual UART (IJUART)

meters (22 by 8 by 17 i nches), which i s approxi­

reasons:

mately one-tenth the size of the HSC: control ler.

Common Controller Platform

1. M a i n tenance term i n a l connec t i o n . The m a i n­

The common con­

t rol ler platform consists of the con t rol ler withou t
the associated host port. The common core of hard­
ware consists of the pol icy processor hardware, the

SCSI-2 device port hardware, and the cache module.
The control ler-specific host port i n terface hardware
i ncludes either the CI, the DSSI, o r the SCSI in terface.

PoliLy Processor Hmdware

The DUART i s u s ed for two

The Sto rageWorks

contro l ler pol icy processor i s I n t e l 's 2)-MHz i960CA
m icroprocessor, which contains an i n ternal instruc­

ten a nce t e r m i n a l is a m eans of e n t e ri n g con­
t ro l ler system m a nagement commands (with the
com m a n d l i ne i n terpreter, which i s the user
i n t e rface fo r con t ro l ler configuration m a n age­
m e n t) and is a l s o a status and error report ing
i n terface. Designers made extensive use of this
i n terface fo r debugging control l e r hardware and
fi r m ware. Use o f t he m a i n te n ance term i n a l con­
necti o n i s optional. The i nt e rface rem a i ns o n the
contro l l e r so that users can d irect control l.er
man agement and status repo rti n g , if desired .

t i o n cache a n d is augmented by a secondary cache

2. Failover com m u nication between two con tro l­

external to the processor. The secondary cache

lers in a d u a l - redundant configuration . The com­

re l ieves the potential bo t t leneck created by shared

m u nication path is u sed to share configu ration

memory between the p o l i c y p rocessor and host/

and status i n fo r m a t i o n between the contro l lers.

device port processors.
The designers had to m a ke trade- offs i n two

areas: the m emory speed/cost and the n u mber of

Shared Buffer and Ca che ;ll/emOIJ'

The dyna m ic

random-access memory ( D RAM) b u ffe r (or shared

b u s es . After simu lation, t h e external instruction

memory) has a t its heart the ( l y n a m i c RANI and arbi­

and data cache showed a significant p er formance

t r a t i o n (DRAB) c h i p . This ch i p supports the b u ffe r

i m p rovement, given the chosen shared-memory

and cache mem ory accesses from the policy pro­

architecture. The cache covers the fi rst 2 M B of

cessor and from the host and device ports. The data

bu ffer memo ry, where p o l icy processor inst ruc­

t ransfer rate supported by the shared memory is

t io ns and local processor data s t r uctures reside and

approx i m ately :)') megabytes per second (MB/s)

where most of t he performance gain fo r the p o l i cy
processor wou l d be ach ieved .
The pol icy processor uses the J BUS exc l usively to
fe tch inst ructions and t o access t he program stor­

age card, the NVRfu\1 , the DUART, and the t i mers.

The D RAB chip c o n t a i n s error-correct i n g code

(ECC) hardware to correct s i ngle- b i t memo rv, to
detect m u lt i b i t errors, a n d to check and gen erate

bus p a r i t y. This fea t ure a l lows the control ler to
s u rv ive partial memory fa i l ures, w h i c h w r q u ick code

design rather than static random-a ccess memory

Program Storage

upgrades and to e l i m i n ate the need for a boot re a d­

(SRA1Vl ) chips led to the use of ECC. DRA.i\'ls were

o n l y memory (ROM) on the controller. The program

chosen because of t h e i r cost and power savi ngs

card is a PCMCIA, 2-MB flas h electric a l ly erasable,

over

p rog ra m m able read-only memory ( EEPROM) card

d e s igners expected l a rge a m o u n ts of DRAM (as

that contains the firmware i m age . Designers chose

much as 40 MB) to be present o n a contro l ler and i t s

,

equ i va l en t

SRA M .

However,

because

the

the PCMCIA card to fac i l i t ate code u p dates in the

associated cache modu l e , the s t a t is t ic a l e rror prob­

fi e l d ,

abi l i t i e s were h igh enough to warrant t he use of

where

host- based

down l i ne

loading

of

firmware was not s u pported . Although the PC:MCIA

card cost m o re than EEPR0.\1 chips a t t ached to the

22

ECC on the mem ory. The combination of DRAM and
ECC was less costly than an equivalen t amount of

Vol.

(>

No. 4

hill

I'.I'J4

Digital Tecbuical journal

The Architecture and Design of HS-series StorageWorks Array Con trollers

more reliable SRAM. The use of pari ty on the buses

Microelectronic Products D ivision of AT&T G lobal

is a standard feature in all Storage Works controllers.

Information Solutions Company) 53C710 SCSI-2

The bus parity feature provides further error detec­

processor chips. The SCSI-2 processor chips reside

tion capabi l ity ou tside the bou nds of the memory

on the NBLJS and access the shared-memory cache

because it covers the path from memory to or from

for data structure and data buffer access. These pro­
cessors receive their work from data structures in

external host or device interfaces.
The DRAB chip also controls access to the cache
mod u le in conj unction with sl ave DRAB chips on

buffer memory and perform commands on their
specific SCSI-2 bus for read or write operations.

the cache module associated with the control l er.

The Sym bios Logic chip provided the most pro­

These DRAB chips p rovide refresh signals for the

cessing power, when compared to the other chips

DRAM buffer or cache memory that they control;

available when the control lers were designed. The

whereas, the master DRAB o n the controller module

designers felt that direct control of SCSJ-2 in terfaces

provides arbitration for cache accesses that origi­

by the poli cy processor or a separate processor

nate from the various sources on the contro l ler

was too costly in terms of processor utilization

mod u le . Slave DRAB chips can also be accessed by

ancl capital expense. The Symbios Logic chips do

the d u a l-redundant partner control ler, depending

require some pol icy processor u t i l ization, but the

on the two contro ller LOCK signal states.

designers considered this acceptable because high­

The controller firmware uses 8 MB of shared

performance architectural features i n the pol icy

buffer memory to execute the program i mage, to

processor hardware compensated for the extra pro­

hold the firmware data structures, and to read and

cessor util ization.

write-through cache data (if no cache modu le is

The SCSJ-2 device port supports the SCSI fast,

present). The i960CA pol icy processor and the host

single-ended , 8-bit interface. t The data transfer

and device data processing elements on the N BUS

rate supported by this interface is 10 M B/s.

can all access buffer memory.

Host Port Hardware

The host port hardware

module

is ei ther a Cl, a DSSI , or a SCSI interface imple­

contains one slave DRAB chip and 16 or 32 M B of
DRAM , and also two ports into the module (one
from each control ler) for use i n failover. Each cache
modu le optionally contains batteries to supply
power to the DRA..l\1 chips in the event of power
failure for write-back caching and Parity RAID use.
The cache modu les are interchangeable between
contro l ler types.

mented with gate arrays or Symbios Logic 53C720

Cache Jl!lemory

Each cache

memory

Parity RAID XOR and Compare Hardware

The

Parity RAID XOR and compare hardware consists of

the FX gate array and 256 kilobytes (KB) of fast

SRAM . The FX al lows concurrent access by SCSI-2
device port hardware and the policy processor. The
FX compares the XOR of a data buffer (512 bytes of
data) that is entering or exiting an attached device
with the XOR buffers i n the fast SRA..M . The pol icy
p rocessor uses the FX to perform compare opera­
tions at the request of a host and perform DMA
operations to move data to and from memories.
This hardware is common across a l l the contro l l e r
platforms for Parity RAID and compare firmware.

SCSI-2 processors. The host port hardware, the only
noncom mon hardware on a Sto rageWorks con­
troller, requires a separate platform to support each
host interface.
The CI interface is made up of a gate array and
CI interface hardware that perfo rms DJVIA write
or read operations from sha red memory or cache
mem ory over the NBLJS. The maximum data transfer
rate supported by the Cl hardware is approximately
8 MB/S.
Tbe DSSI i nterface util izes a Symbios Logic
53C720 chip coupled with a gate array and DSSI
drivers to receive and transmit data to or from the
DSSI bus. The DSSI interface is 8 bits wide, and the
maximum data transfer rate supported by the DSSI
hardware is 4.5 M B/s.
The SCSI interface also uses a Symbios Logic
53C720 chip couplecl with differential drivers to
provide a SCSJ-2, fast-wide (i. e . , 16 -bit) d ifferential
interface to hosts. The maximu m data transfer rate
suppo rted by the SCSI-2 in terface is 20 MB/s for
fast-wide operations.

The device ports

Table 3 shows tl1e current (version 2.0) maxi­

(three or six, dependi ng on the controller model)

m u m measured (at the host) data transfer rate per­

are control led by Symbios Logic (the former NCR

fo rmance numbers for StorageWorks control lers.

SCSI-2 Device Port Hardware

Digital Tecbn icaljourrwl

Vol. 6 No. 4

Fall 19')4

23

RAJD Array Controllers

Table 3

SCSI-2 Host I nterface Performance

Contro l ler

Write D a t a Tra nsfer Rate

( Megabytes per Second)

( M egabytes per Second)

6.7

HSJ30/HSJ40*

4.4
2.8

3.2

HSD30

14

HSZ40**
'

Read Data Tra nsfer Rate

8.0

I n a m u l t i host e n v i ro n m e n t

" Measured for t h e H S Z 4 0 - B controller

i n the e v e n t of a fa i l u re and u t i l i zes spare device

Summary
The Storage\XIorks H S-series array contro l lers were

des igned to m e e t the storage subsystem needs of
both Digital and non-Digi t a l systems. t h e reby ente r­
ing the wo rld of open systems. The a rch i tect ure for
t h e HSJ:)O, HS]40, HS D30, and HSZ40 c o nt rol l e rs has

1. Open systems capabil ity A SCS!-2 de vice interface
a l lows many types of disk, tape, and optical
devices t o h e a t t ached to the H SJ;){), HSJ40. and

fJSD30 cont ro l le rs . The HSZ40 control l e r. wh ich is

curren t ly a d is k- o n l y control ler, provides a scsr-2
host i nterface t h a t al lows the cont ro.l ler to be

attached to Digi t a l a nd non-Digi t a l compu t e r s .

2. High ava i l a bi l i t y. C o n t ro l l e r fau lt tole r a n ce a n d

firmware

y ie lded

highly

a

avail able

StorageWo r ks storage s u bsys tem .
T h e d ua l - red u ml a nt

a l lows each of a p a i r of active c o n t ro l le r s t o
operate i ndepende n t l y with host sys t e m s . w h i l e
s h ar i ng device ports, configuration i nfo r m a t i o n ,

a n d s t a tu s . Th is ( l esign a l lows b o t h c o n t rol lers
to a c h i eve m a x i m u m p e r fo r m a nc e . T h e d ua l­
also

provides

fa u l t

tolerance i f o n e c o n t ro l l e r fa i ls, beca use t h e
surviving c o n t r o l ler se rves t h e fa i l e d c o n t ro l ­

i m p l ement a t i o n

Board ti > r R A I D ava i l ab i l i ty features.

HSZ 'iO

c o nt ro l

l e r s achieved t he respective i n i t i a l

perfor m a nce goa l s o f 1 , 100, HOO, a n d 1 ,400 r;os
per sec o n d . The c o n t ro l lers m e r t h e l ow requ est

l a te n cy go a l s by stre a m l i n i n g firmware \vhere

possi bl e ami by i n tro d u ci ng write-back cach i ng.
Wr i te-back

cac h i n g

fi r m ware

d ra m a t i cal l y

red u ces la tency on a l l write requests, a nd write­
back cache hardware pro v i d es bat tery backup for
d a t a i n tegrity across power fa i l u res. Furthe r­
more . the wri te-back cache overcomes the RAI D

rate i ne fficiencies ancl thus prov ides high perfor­
mance w i t h Pa r i t y RAI D d is k configurat i on s.

Sto rageWo rks Parity RAID f i r mwMe i m p le m e n t s

many of t he l{r\ 1 1 ) Ad v i s o ry Bo�ml opriona I perfor­
mance fea t u res to prod uce a h igh-p e r fo r m a nce

RA ID s o l u t i o n .

com mon

c o n t ro l le r

success fu l l y

A

deve loped

p ro c e s s i n g

fo r

l he

c o re was

f iSJ 50/J l SJ40,

H S D :�O. and HSZ40 c o n t ro l lers. ,VI o re t h a n H5 per­

l e r s d e vi ces t o t h e host compu ters. T h e d u a l ­

cent ot t he fi r m ware is com m o n to ;i l l t h ree con­

con t ro l l e r

t rol l e r p l a t fo r ms ,

'

configura t i o n ,

com binnl

with

w h i c h a l lows

fo r ease

ot

Sto rageWo rks c o n t ro l ler packaging, resu l t s in

m a i ntenance a n d fo r t he same look and feel for

a hig h l y ava i l a b l e c o n t ro l l e r configu r a t i o n w i t h

c u s to m e rs . The arch i t e c t u re a n d t he t ec h nolog y

bu i l t - i n fa u l t t ol e r a n c e , e rror recovery, a n d bat­

used res u l ted i n a core c o n t ro l l e r clesign t h a t

tery back u p fea tures.

s u p po rt s

Parit y RAID control ler firmware, combined w i t h

S to ragcWorks c o n t ro l ler p l a t fo r m s

a

h igh

clara

t r a n s f er

rate

fo r

all

StorageWorks device pa c kagi g , a l lows t< H· h ig h l y

These ach in-crnenrs repre s e n t t h e l a rge e n g i ­

ava i l able d i s k co n figura t i ons t h a t a re l e s s cos t l y

neering i n ve:; t m<:: nt t h a t D igi t a l has m acle to move

n

FurtiH:rm orc.

into the o p e n s,·stems market with new te c h n o l ogy

Parity lWD firmwan: p e rfor m s a u to m a t i c Parity

for i t s sto rage sol u t ions. These contro l ler p l a t fo r m s

m ana ge m en t and e rror recovery fu nctions

a re t h e b a s i s fo r fu t ur e co n t ro l l e r a rc h i tectures and

than
RAID

24

RAID

Parity

exceeds the requ i rements of t h e HAll) A d v i s o ry

level ') s m a l l-write p en a l t y a mi h igh data transfer

c o n t ro l l.er configur a t i o n

red u n d a n t c o n figura t i o n

RAID c o n fi g u r a t i o n m a n a ge m e n t p o l i cie s . The

Sro rageWorks

3. H igh p e r fo r m ance . The HSJ30/HS.J40, HSD:)O, a n d

ach ieved the i n i t ia l pro ject goa l s a n d prov ides

RAID

pools in conj u nc t i o n with u s e r-defined Paritv

m irrored

config urations.

l!rJ/.

(,

,\'u.

i

!-it// !')':)4

Di,�ital Tecllllica/ journal

The A rchitecture and Design of HS-series StorageWo1·ks Array Con trollers

platforms that u t i l i ze the knowledge and experi­
ence

acquired

d u ring the

4. P Massigl ia , ed . , The RAJDbook: A Source Book
for Disk Array Technology, 4th ed. (St. Peter,

deve l o p ment of the

Minnesota: The RAID Advisory Board, September

Storage Works l-IS-series array controllers.

1994)

Acknowledgments
The StorageWorks array controller project was the

5. P Biswas, K . Ramakrishnan, D. Towsley, and
C.

coop erative effort of a large n u m ber of engineers
who

sacrificed

considerable

personal

time

Krishna,

" Performance

Analysis

of

Dis­

tribu ted F i le Systems with Non-Vo l a t i le Caches,"

to

ACM Sigmetrics (1993).

achieve the project goa ls. The fol lowing people and
groups contribu ted t o the success of the product:

6. Parity !W D unit reconstruction of data and parity

Bob B l ack ledge, D iana S l1en , Don Anders, Richard

from a failed array member means regenerating

Woerner, El len Lary, J i m Pherson, Richard Brame,

the data block-by-block from the rem a ining array

Jim jackson , Ron McLean, Bob E l l is, Clark Lubbers,

members (see Figure 6) and writing the regen­

Susan E l k ington, Wayne U m l a n d , Bruce Sardeson,

erated data onto a spare disk. Reconstruction

Randy Marks, Randy Robers o n , Diane Edmonds,

restores data redundancy i n a Parity RAID unit.

Roger Oa key, Rod L i lak, Randy Fu ller, joe Ke ith,
Mary

Ruden,

lVl ike

Richard,

Tom

Lawlor, jim

Pu lsipher, Jim Va gais, Ray Massie, Dan Wat t, Jesse
Ya nde l l , Jim Zahrobsky, M i ke Wa l ker, Tom Fava,
Jerry Vanderwa a l l , Dave Mozey, Brian Schow, Mark
Lyon , Bob Pem berto n , Mike Leavitt, Brenda Lieb er,
Mark Lewis, Reuben Martinez , J oh n Panneton, Jerry

7

Metadata is information written i n a reserved
area of a disk. The information, wh ich takes up
approximately 0.01

p ercent of the total disk

capacity, describes the d i s k 's configuration and
state with respect to its use i n a Parit y IWD unit.

8. P. Biswas and K. Ramakrishnan, "Trace Driven

Lucas, Richie La ry, Dave Clark, Brad Morgan, Ken

Analysis of Write Caching Pol icies for Disks,"

Bates, Pau l Massigl i a , Tom Adams, J i l l Graml ich,

AC.M Sigmetrics (1993).

Leslie Rivera, Dave Dyer, Joe Krantz, Kel l y Ta ppan,
Charl i e

Zu l lo , Keith Woestehoff,

Rachel

Zhou,

Kathy Meinzer, and Laura Hagar. Thanks to the CAD
team, the Storage Works packaging and manufactur­
ing tea m , the software verifica t i on team, and the

9. R. Lary and R . Bean, "The Hierarchical Storage
ControJJer, A Tigh t l y Coupled Multiprocessor
as Storage Se rver," Digital Technical jo urnal,
vol. 1 , no. 8 (February 1989): 8-24.

problem management tea m. A fi nal thanks to our
OpenVNIS and DEC OSt/1 operating system partners
and to the corporate test groups, a l l of w h o m
worked with our engineering t e a m to ensure i nter­
operabi l i ty between the operating systems and the
control lers.

References and Notes
1 . information Systems-Small Computer Systems

lnteJface-2 ('>C�1-2), A.t'ISI X1 .131-1994 (New York:
American National Standards Institute, 1994).

2. D. Patterson, G. G i bson, and R. Katz, "A Case for
Red un dant Arrays of Inexpens ive Disks (RA I D) ,"
Report No. UCB/CSD 87/391 (Berkeley: University
of California, December 1987).

3. The RAI D level 5 s m a l l-write penalty re sults
when a small write operation does not write a l l
t h e blocks associated with a parity block. This
situation requ ires disk reads to reca lculate parity
that must then be written back to the RAID level
5 unit to achieve data redunda ncy.

Digital Techuica/ ]ounwl

V!Jf. () No. 4

Fall I'J'J4

25

Cbristopb J Bufller

Policy Resolution in Workflow
Management Systems
One crucial Junction of a Ll'orkflow management .�)'Stem (W/�11.\) is to assign tasks
to users wbo are eligible to cany them out. Except in simple u•orkjlou· scenarios,
roles such as secretary and nwrwger are not a sujficient basisfor determining eligi­
bility AdditionallJ; wr,I!Ss are deployed not only in group settings by small compa­
nies but also worldll'ide by large ente1}Jrises. Since local lau·s and business policies
bave to befollowed, task assignmentpoliciesfor tbe same tasl? geueml�J' differfrom
country to counti�J' and, therej(Jre, must be specified locally The Policy Resolution

A rchitecture (PRA) 1nodel provides more generality and e:xpressil'eness than role
models do and at the same time supports the independent .ljJeufication of task
assignment policies in different parts of an enterprise. PRA can be used to model
arbitrary organization structu res and to define realistic task assignment (eligibil­
ity) rules by means ofprecise�v defined OJganizational policies. Tlm�� PRA provides
real-world organizations witb a precise, silnple means of e"ipressing tbeir complex
task assignment policies.

A workflow m a n a gement system (W F;\1S) i s a soft­

success ful c o m p l e t i o n o f a t a sk. however, often

of work

requ ires that cr ucia l , irreversi ble decisions be made

between p a r t i cipa n t s or u sers accord i ng to h > r m a J

by a person who is resp o n s i bl e fo r t h e task . Making

ware

system

that

m a n a ges

the

flow

speci fi c a t i o n s of b u s iness p ro ce ss e s c a l led work­

t h e right d ecisions and then carefu l l y a n d resp onsi­

flows. A workflow specifies tasks to be pe rformed

bly carrying out t h e task i s ess e n t i a l t o c o n d u c t i n g

ami t heir exec u tion order. A d d i t i o n a l ly, a work flow

busi ness successfu l ly.

of d a t a

The criteria used to deter m i ne an el igible user t< >r

between t a s k s as wel l as a l l appl ications req u i red t o

a task are m a n i t< > l d . A user m u st have a specific s e t

specification

defi nes t h e i n t e rn a l

flow

c a r r y o u r the t as ks. F o r example, a travel exrense

o f capa b i l i t ies t o h e able t o carry o u t t he task .

re i m bursement workflow specifies the tasks of fi l l ­

A d d i t i ona l l y, the p o s i t i o n of a u s e r in t h e orga n iza­

i n g , checking and signing a for m . a n d re i m b u rs i n g

t i o n h i erarchy an d/or the reporting s t r ucture of the

a n a m o u n t . This wo rkJlow specifies that the fo rm

orga n i z a t i o n can dete r m i n e i f the user is resronsi­

m u st be signed before an a m o u n t i s rei mbursed .

ble for t h e task. f u rt h e r m o re , l i m i t s r l aced on

The workflow specific a t i o n a l s o t l efi nes the flow o f

a u s er's tlecis i o n - m a k i n g a u th o r i t v can a ffe c t e l igi­

t h e e x p e n s e form between tasks a nd the req u ired

b i l ity. For example, not every salesperson is au t h o­

spreadsheet app l ic a t i o n . F i n a l l y, for each t a s k o f a

r i zed to accept an o rder t h a t leads to a sign i fi c a n t

workflow, some ru l e bas to be i n p l a c e t h a t s p e c i­

in crease in m a n u fa c t1 1 r i ng o u t p u t . S u c h an order

fies the users who are el igi b le to carry o u t the tas k .

requires speci a l

T h i s s e t o f e l igible u sers is deter mined at ru n t i m e ,

nation

and t h e t a s k i s subsequ e n t l y assigned to them.

cost -optimized

One of the key issues in succ es s fu l l y d e p l oy i n g

attention

by a sen ior sales

and

i n ternal

repre s e n t a t i ve .

coord i­
When

task ass ignments are made,

the

experience o f t h e u s e r as wel l a s the use r's s k i l l set

WFtviSs i n a n enterprise is the correct ass i g n m e n t

has to be t a ke n i nto consid erat i o n . Hig h l y ex peri­

of a given t a s k to e l igible us ers. An e l igible user i s

enced users are in most cases expensive resou rces,

o n e who is capab.le o f a n d respo n s i b l e fo r carryi ng

hut usu a l l y they can com plete tasks faster t h a n

out a n assigned task.

This d is t i n c t i o n is impor­

users w i t h average ex perience . A l t h o u g h u s e rs

t a n t because not every u s e r who is capable of per­

w i t h e i t her level of experi ence may h ave sufficie nt

fo r m i ng a task is necessari l y respo n s i bl e fo r i t . The

experience t o carry out a s p eci f i c task, if d ea d l ines

Vol.

(,

No. 4

!'off f'J'J4

Digital Tecbuical journal

I

Policy Resolution in Workflow Management Systems

are involved or extreme caution with respect to
qua l i ty is necessary, a highly experienced user

Before explaining PRA i n detail and providing the

ratio nale for its development, the paper i ntroduces

might be appropriate. ln such cases, the additiona l

the key concepts of workflow management. This

cost would be justified .

introduction presents a seemingly simple workflow

The previous discussion demonstrates the neces­

that specifies travel expense reimbursement, which

sity of a precise defin ition of el igible users for a

is later used to i ntroduce the design objectives of

given task. Such a definition, i . e . , set of task assign­

PRA. Note that a real travel expense reimbursement

ment rules, should contain a l l the criteria used to

workflow for production is by far more complex

determine eligible users for the tas k . Early in the

than the example used in this paper. A large dis­

development of Digital's Objectflow WFMS prod­

tributed enterprise endeavors to reuse the same

uct, the concept of roles was considered sufficient

workflow i n all of its parts because reuse faci l itates

t o model the assignment of tasks to users . 1 How­

administration and

ever, an analysis of distributed enterprise-wide pro­

investment. At the same time, such an enterprise

leverages the

development

duction workflows clearly showed that using roles

probably sponsors numerous business trips, which

as the only assignment mechanism has l i m i ted

m akes the travel expense reimbursement workflow

value i n determ ining e ligibil ity 2 The need for a far

an excellent candidate to use as an example.

more expressive, general, and flexible approach
became obvious. The analysis also revealed that

Workflow Management

workflows are often reused in d ifferent parts of

This section introduces a model of workflow man­

an enterprise. A prom inent example i s the travel
expense reimbursement workflow, which is d is­

agement. The discussio n begins with a survey of

cussed throughout this paper. Although a work­

tion for workflow m anagement and enumerates

flow is reused, however, the task assignment

some areas in which workflow management is

prel i m inary work. The survey suggests the motiva­

policies may differ greatly in the various parts of an

deployed. The key concepts of the workflow model

enterprise. This difference is due to the need to

are then used to model a workflow example, i . e . ,

adhere to local laws and/or to business-related devi­

t h e travel expense reimbursement workflow. The

ations from the general ru les.

section concludes with a definition of workflow

Based on the requirements derived from several

management systems.

case studies of complex workJiows, the Pol icy
Resol ution Architecture (PRA) was developed to

Historical Survey

provide a comprehensive way of specifying task

Looking back i n history reveals that workflow man­

assignment rules. 2 To support the fact that d i.fferent

agement has many roots. The most important are

parts of an organization may require different

office automation, software process management,

assignment rules, PRA and i ts implementation were

manufacturing, and transaction processing. The fol­

designed as separate components. PRA incorpo­

lowing short su rvey of achieved resu lts is given

rates three major elements and thus provides

to help the reader u nderstand the motivation

•

Concepts that enable the model i ng of any orga­
n ization structure (not just roles and groups)
without prescribing structures that are applica­
tion dependent.

•

Task assign ment rules as entit ies in themse lves,
separate from a workflow specification. This
makes it possible for each of the d ifferen t parts
of an enterprise to have its own set of task assign­

•

for workflow management. The discussion also
exp l ains the choice of workflow management con­
cepts. The l ist of previous and related works indi­
cates the range of literature that exists.

Office Automation
workflow

One of the primary roots of

ma nagement

is

u ndoubtedly

office

automation. Early research led to the development
of models and tools to support office workers.

:1-Y

mem rules for the same workflow.

What emerged were not o n ly desktop applications

A l a nguage that enables the expl icit specification

fo rms, and documents but also models of the pro­

of organization schemas and task assignment

cedures that the office workers fol low while doing

rules. Specifications are processed by a compo­

their jobs. 1o· 1 1 Furthermore, systems were devel­

that imitate concepts such as in basket, out basket,

nent cal l ed the policy reso lution engine during

oped that execute the office procedures to actively

workflow execution.

manage the flow of work within offices. Il. l�

D igital Techllicaljournal

Vol 6 No. 4

Fa/1 1994

27

Workflow Models

A s eco nd m a jor root

m o del i ng l a nguage . a n d execu t i o n mechani s m , or

of wor kf low m a n agem ent is so ft wa re process m o d ­

is it p os s i b l e to IJrov ide general concepts t h a t need

eling anll exec u t i o n . 1� - 25 Th e fo cus of research in this

to be customi zed o nl y fo r a specific area of a p p lica­

Software Process fl!lodeling

area is the a u to m ated support of software d eve lo p­

tion' T h is q u e s t i o n triggered t h e devel opment of

m e n t processes. Concepts co m p r i se process m o d­

the co n c e p t o f w or k f low , whose go a l it is to serve

els l i ke the waterfa l l m ode l or t h e s pir a l model,

as the ge neral and cust om izable c o n c e p t .

del iverable colle, i nstallation and opera t i o n m a n u­
a l s , r equ i re me n t s doc u m en ts, a nd test cases 21•.r

JV!anufactu ring

Workflow Management Concepts

Trad it i o na ll y, fo r m a l i zed proce­

(l ures t h a t are e xe cu ted re p eated ly are i n l1ere n t to
m a n u fact u ri n g , another roo t o f workflow m a n a ge­
m e n t . M a n u facturing i nvolves n o t o n ly p ro d u ct io n
processes b u t a lso preprodu ct i o n proc e d u res start­
ing fro m , for exa m p l e , the release o f c o m p u ter­
a ided d es ign (CAD) d r aw ings t o t h e p rep a r a ti on of

s h o p f l oo r sch e d u l e s . 2K- 

e nt er prise t h a t d rives the enter prise processes. T h e

ried ou t by one perso n . progra m , or mach i n e .

s peech act t h eory is an a t t e m p t t o m o d e l the con­

For b re v i t y. e l e m e n t a ry workflows a re c a l led

vers a t i o n between h u m a ns. '" Some research fo l ­

steps.

lows the direc t i o n t h a t a workflow i s a n i n terwoven

element ary

cha i n of s pe ec h acts. '1

Ear�J' AjJjJiication -indej>e nde n t Appmachcs

Co m pos i te

workflows

workflows

or

bu nd l e

other

e i t her

co mp os i t e

workflows t o h i g her- level t ask s . I n t h i s way.
a re use h ie r a rc h y is bu i l t . s i n c e the b u nd led

In

a d d i t i o n to the a p p l i ca t i o n - sp ecific roo t s o f work­

wo rkflows m ay very well stand by themse lves.
Gene ra ll y. these h igh er- level tasks can no l o nge r
a ch i e ve d

by

a

s i ngl e

person,

progra m .

flow m a n age m e n t , ear l y a pp ro ac h es th a t m o d e l e d

be

p ro cesses i n de pe n d e n t of a p p l ica t i o n a reas pro­

or m a c h i n e h ut re q u i re severa l such e n t ities.

v i d ed m o tivation fo r workflow m a nage m e n t . '�-'

A w orkf l ow that h u n d les other wor kf l ow s refer­

i

The term process a p pears in a l l the areas of work

ences t h e m . As a n a m i ng convention, a work­

m e n t i oned above. Al so, a l l th ese res ea rc h areas d e a l

flow tha t is refe renced by some other workflow

w i t h d a t a , e . g . , do c u m e n t s , C r\ D d raw i n gs, a n d

i s c a l led a s u b w o r kf l ow. The r efe r e n c in g work­

orders. M o s t a p pr oa ch es h ave s o m e n o t i o n of s u b­

f low is ca l le d the sup e rwo rk f l ow. The topmost

ject or age n t . The question arose amon g researchers,

workflow of a reuse hie ra r c hy is called the top ­

Does each area need its own defi n i t i on of terms.

level wo r k f l ow.

2H

l'rJ/.

(, No. i

1-ii/1 I')'J

i

Digital Tecbuicnl jou rnal

Policy Resolution in Workflow Management Systems

•

Behavioral

aspect.

The

behavioral

aspect

describes the execution order of the subwork­
flows of a workflow. Constructs that describe

•

a simpl ified workflow for the reimbursement

the order include sequence, conditional branch­

of travel expenses. ( E xamples of workflow lan­

ing, parallel branch ing, ami the looping and/or

guage can be found in the l iterature. '''(') The work­

joining of parallel or conditional execution paths.

f low consists of four steps: ( 1 ) fi l l , (2) check,

Informational aspect. The informational aspect
i s twofold: first, it descri bes the local variables of
a workflow and the external data referenced;
second, it describes the flow of data fro m sub­
workflow to subworkflow.

•

Travel Expense Reimbursement Worliflow
Figure 1 shows the graphical representation of

(3) sign, and (4) reimburse. The graphical represen­
tation shows the fu nctional aspect (task strucmre)
as ovals and the behavioral aspect (control flow) as
solid arrows. The informational aspect (data flow)
is d isplayed as forms; dotted arrows i n dicate the
direction of the flow of data. The organizational

Organizational aspect. The organizational aspect

aspect is omitted since the paper will focus later on

describes who is eligible tO carry out a step. The

t h is topic. The technological aspect is represented

"who" can be a human (e .g. , an office worker) ,

by icons of the software appl ications that are avail­

a program (e.g. , a compiler in a software pro­

able to carry ou t the steps. The historical aspect is

cess), or a mach ine (e . g . , a cell in a shop floor).

represented by icons that symbolize logs in wh ich

The term user was chosen to represent all three.

information must be recorded.

Most available W FMSs offer the concept of roles to

Step 1 of the travel expense reimbursement

model the organizational aspect. A role usually

workflow, the fil l step , enables a user to enter the

groups a set of users. A t run time, tasks are

relevant expenses incu rred d u ring a business trip

assigned to roles and all users grouped by these

into an electronic travel expense for m . After a user

roles are assigned the task. Although this method

has finished entering the data, validation must take

of task assignment is adequate fo r certain work­

place. The check step enables a user to look at the

flows such as departmental workflows, as shown

contents of the travel expense form . This user is

later in the section Task Assignment in a Travel

prompted to val idate the contents but cannot

Expense Reimbursement Workflow, roles are not

change entries. If the user who checks the form

sutficient to hand le workflows that are deployed

detects an error, the form is sent back to the user

in an enterprise-wide or i nternational setting.

who in itially filled it out, with a note that explains

The l i terature discusses additional aspects, e . g . ,
a historical aspect and a technological aspect.""
The h istorical aspect is used to specify the kind of
inform ation to be stored in a historical database
dur i ng the execution of a workflow, e.g. , starting
ti mes or val ues of variables. Instead of h aving the
default strategy of saving a l l data, the workflow
specifies in the historical aspect only the important
data that must be stored . The technological aspect
a l lows the definition of which application program
or programs are available to carry out a step. At run
time, these appl ication programs are made avail­
able to the user. In pri nciple, it is not possible to
enu merate all necessary aspects completely in
advance. Dep ending on the appl ication area to be
modeled, add itional aspects m ight appear and

the reason fo r rejection. Otherwise, the form is for­
warded to the next user who has to sign the form to
approve the amount. After the sign step is com­
plete, the amount can be reimbursed. The last step,
reimburse, enables a user to add the amount spent
to the next paycheck of the user who requested
reimbursement.
Th is sample workflow is intentionally kept sim­
ple because beginning with the next section, the
paper focuses solely on task assignment ru les. In
a real organ izational setting, the workflow would
involve more steps and additional execution paths.
For example, a user who has to sign the form m ight
detect an error. In this case, as in the checl< step, the
fo rm would be sent back to the user who initially
filled i t out.

require support.
The paper now shows how the key concepts
of workflow management can be appl ied, i . e . , cus­

Workflow Management Systems
Managing the flow of work among users is done by

tomized, to model a specific workflow type. The

a software system cal led a workflow management

example used is a sample travel expense reimburse­

system ( WFMS). A WFMS contains a l l the specifica­

ment workflow.

tions of the workflow types (e. g . , a travel expense

Digital Teclmicaljournal

Vol. 6 No. 4

Fall 1994

29

Workflow Models

n�OTE
: - - - - - - - - -u-- - - - - - - -:

'

'

'
Q

'

TASK
CONTROL FLOW
DATA FLOW

[[§]
Q

l '" i o C J
'
Q

KEY

C)

Travel Expense Reimbu rsemenl

ELECT R O N I C FORM

S P R EA D S H E E T
A P P L I CATION

l ooi o C J
'
Q

MONEY TRANSFER
AP PLICATION

I N FO R MATION LOG

Figure 1

Travel E\pense Reimbursement Workflow

rei m b u rsemen t or a capital equ ipment order) that
are modeled and released for productio n . If a user
issues a request to start a workflow (e . g . , if, after
a business trip, a traveler starts a travel expense
reimbursement workflow), the WFJVIS creates an
i nstance of the requested workflow type. Of course,
more than one i nstance of the same workflow type
can exist simul taneously. A WFMS assigns the steps
of a workflow to users according to the specified
order of the behavioral, fu nctional, and orga n i za­
tional aspects.
In genera l , a WFJVIS performs the fol lowing
act ions to execute a workflow instance:
•

Determ ine the next steps to be execu ted .

•

Determine the el igible users for these steps.

•

Assign steps to el igi ble users.

•

Wai t for the result of each step.

•

Transfer the resu l t back to the step's superwork­
flow and record the step as complete.

The WFMS repeats these actions u n t i l all steps of
a workflow are executed . "' ''-)� This l ist of actions
has to be sl ightly modified if. in addition to steps,
a workflow contains composite workflows in its
l ist of subworkflows. In this case, the su bworkflow

30

' '
Q Q

is not assigned to users and the I ist of actions is
appl ied to each of the subworkflows.
Each user who can potentia l ly be i nvolved i n
a workflow i s connected to a WFMS b y a private
work I ist, which is a graphical representation of
a I ist of steps assigneel to the user. Each en t ry i n a
user's workl ist represents a task the user is el igible
to carry out. A user can participate i n more than
one workflow at the same t ime. Normal ly, the user
is free to choose from the workl ist any i tem on
which to start. In wel l-designed systems, the WFMS
automatica l ly starts the appl ication programs that
the user will requ i re to accompl ish the work. In
t h is way, t he user can begin work i m medi a tely.
Al most a l l prototype i mplementations or prod­
u c t developments a l low the modeli n g of t he four
main aspects described previously. The J ist of work­
flow management systems is growing rapid ly, and
references to releva n t l i terature are read i ly avail­
able. 17'7-!' 1 References to l iterature that describes
the deployment of workflow management systems
i n an application area are rare, however.'J .(,J .(, )- (,"
The rem inder of the paper focuses on t he orga­
nizational aspect of workflow m anagement. The
paper d iscusses the derivation of the requ i rements
that concepts of this aspect m ust meet and then
introduces PRA as the model whose concerts

\In/. 6 Nn. 4

Fall 1994

Digital Teclmical journal

Policy Resolu tion in Wo rkflow Management Systems

norm ally has to approve spe n d i ng by subordi­

address the requirements. An analysis of the travel

nates. Usual ly, there is only one user to whom

expense reimbursement workflow i l l ustrates some
of these requirements. Add itional requirements are

the applicant reports and who is able to play the

also described to prov ide a more complete set.

role of man ager. If there are two such users,

Task Assignment in a Travel Expense
Reimbursement Workflaw

and onJy one has to sign it.
The overall task assignment ru le is: Everyone

The requirements that must be fu l fi l led by the con­

who is able to play the rol.e of manager and

either can be responsible for signing the form

cepts of the organi zational aspect were de rived

to whom the appl icant reports is el igible to exe­

from the travel expense reimbursement workflow

cute the sign step.

example, the author's project work experiences,
and

Marshak's " Characteristics of a Workflow

•

System- Mi nd Your P's and R's."68 Tbe fol lowing

the grou p to which the applicant belongs.

list describes task assignment rules fo r each step of
the travel expense reimbursement workflow:
•

The overa l l task assignment rule is: Everyone
who is able to play the role of financial clerk and

F i l l. The fi l l step can be executed by anyone i n

who is responsible for the applicant's group is

an organization w h o h a s t h e potential t o travel.

el igible to execute the reimburse step .

This assignment rule enables an emp loyee to fil l
in a travel expense rei m b u rsement fo rm after

a business trip. (An employee who did not travel

can also fil l i n a form and claim expenses; how­
ever, the check and sign steps are intended to

The requ irements thus far derived from the
example are
•

The user who fil l s in the form is referred to as

the role of secretary reporting to a user playing

the applicant and is known at run t i me.

the role of manager) requires describing the
users, the roles, and the dependencies (relation­

Check. The check step must be executed by

ships) . This description i s cal led a n organi zation
structure. An organization structure contains a l l

a user who is able to play the role of secretary.
To be able to va lidate the contents of the fo rm, a

organ izati onal object types l ike " user," "group,"

user i n t h is role is expected to know how a travel

or " role," and the relati onships among them l ike

expense rei m bursement form is structured and

" reports to" or " supervises." Given such a struc­

how to correctly fill in the form. This user is also

ture, users can be selected based on their rela­

expected to know the destination and the travel

tionships to others. Users can also be selected

<.lates, and if the travel actual ly took place. Not a ! J

based on attribu tes such as their absence status

secretaries in an enterprise have this knowledge,

( i . e . , whether they are on vacation or on a busi­

but the secretary of the applicant's manager can

ness trip) or their workload .

be expected to know the i nformation. This sec­
retary usual ly plans the trip and often the meet­

•

H istorical access. In some cases, the el igible user
for a step cannot be <.leterminecl local ly, and his­

i ngs of the traveler. If the user who is able to play
the role of secretary <.letermines that the con­

torical information is required. For example,

tents of the travel expense reim bu rsement form

determ i n i ng the user who can p lay the role of

are sound, the form is fo rwarded to the next

manager i n one step m ight require knowing

step ; otherwise it is sent back to the applicant.

which user started the workflow. Therefore, it
m ust be possible to query a log of the h istory of

The overal l task assignment rule is therefore:

a workflow to derive the i nformation necessary

Everyone who is able to play the role of secretary

to make task assignments.

and reports to the same manager as the appl icant

The fol lowing are a d d itional requirements:

is eligible to execute the check step . (Note that
the term manager means a user who is able to
play the role of manager.)
•

Organization structure dependencies. To select
one user relative to another (e. g . , a user playing

detect such misbehavior and to reject the form.)

•

Rei mburse. The reimburse step must be exe­
cuted by a fi nancial c lerk who is responsible for

•

Data depende ncy. I n the travel expense reim­
bursement example used in this paper, the man­

Sign. The sign step has to be executed by a man­

ager to whom the sign step is assigned can sign

ager of the applicant because the manager

for any amou nt. In other cases, however, this

Digital Technical journal

Vnl. G No. 4

Fall

1994

31

Workflow Models

signatory

•

power

may

have

l i m i ta t i o ns.

For

t h e deve lopme n t p l a n , w h i ch is based o n a m a r­

i nstance, i f the amou n t exceeds a certain val u e , a

ket a na lysis. A manager or a vice presi d e n t is usu­

vice pres i d e n t and n o t the m a n ager of the appl i­

a l ly respons ible for these t h ree complex tasks

c a n t m ust sign the travel expense rei m bursement

(market ana lysis, devel opmen t p la n , i nvestment

fo rm . As this l as t example shows, task assignment

plan) but not i nvolved i n the d e ta i l e d work. I n

may depend o n data in the workfl ow.

a W FM S , this s i t u a t i o n wo u ld b e modeled a s a
workflow c a l led P ro d u c t Devel opment Start,

Delega t i o n . A manager who is o u t of the office

w h i c h c o n t a i ns t he t h ree complex tasks as s u b­

m ay w a n t to d e l egate h is/her tasks to keep busi­

workflows.

ness operations r u n n i ng smoot hly. The appro­
priate task assign m e n t rule wo u l d then have to
tasks. Dep e n d i ng o n the status of the m a n ager

m u s t acknow l edge the start of the assigned
for i t . T h e assignment d o e s n o t i m p l y t h a t the

However, task assign m e n t ru les t ha t

user has to perfo r m the cl e t a i led work. Thus.

i ncorporate delegation c a n be complex. Con­

a WFMS must be able to assign n o t o n ly steps

siller t he situation i n which a ma nager l eaves

where a m a n ager has a n excessive a m o u n t of
work to acco m p l ish), the m a nager m us t be able
to dynamically delegate some o r a l l of the a l ready
assigned tasks. F u r t her consider that a ma n ager
may want to d e l egate d ifferent types of t:Jsks not

to the same user but t o d i ffe re n t users . depend­

i ng on the type of t a s k . To avoid leaking i n fo r m a­
t i o n or m a king an i n ex p ed i e n t assignm e n t , the
task assign ment r u l e m us t m a ke sure that the t ar­
get users are e l igible to receive the d e l egated
task assign men t .
•

•

to

users b u t a l s o composite workflows.
•

Early/ l ate

;� ! locat i o n .

Often ,

the

a p p l ication

semantics c l e a r l y i n d ica tes the s i ngle user who
s ho u ld execute a t a s k . I n su c h cases, the related
task assignment r u l e (e . g . , the role of m anager

of applicant) passes to t h i s user a t ru n t i m e . I n

o t her scenarios . hO\vever, s u ccessfu l exe c u t i o n
of a task requ ires s o m e capabi l i t v t h a t m o re t h a n
one user possesses. This capa b i l i t y i s often
expressed t h rough a role (e . g . , f i n a n c i a l clerk,
w h i c h is a ro l e usua l l y p l ayed by more t h a n one
user in l a rge e n terprises). In the si ngle-user case.

the task is ass igned to t ha t user regard less of the
u s e r's wo rkload ; this process is c a l led early a l lo­

Separation o f d u ty. Some scenarios requ i re a sep­

cat i o n . The user must carry out the task u n less i t

aration of d u t y, i . e . , two tasks must be per­

is feasible to d e l egate i t . I n t h e m u .l tip.lc-user

fo rmed by d i ffer e n t users. For exa m p l e , in the

case, the task appears on t he wo rk l i s t of a l l users

transfe r of a l a rge a m o u n t of m o n ey, two m a n­

able

agers m u s t sign the transfer fo rm to d o u b le­

most cases, this user wou ld not have t be bighest

check t he

workload . Therefore, the fi nal a l location of t he

transa c t i o n .

Rega rd i n g

the

travel

to p l av the ro.lc . O ne user starts the tas k ; in

expense rei mbursement workflow, a user who

task is m a d e not by the Wf\!S b u t by t he set of

fi l l s o u t the c l a i m fo rm shou l d not a l s o sign it.

el i g ible users themselves. This p rocess is c a l led

Task assig n m e n t r u l e s m u s t ensu re that there i s

l a te a U oc a r i o n . I n t h i s case. if o n e user starts

a separation of d u t y.

wor k o n a ste r . t he other u sers are no l o nger

Responsibil ity. As previous.ly stated , a s u bwork­
flow can be e i t h e r a step o r a gro u p of steps that
m ay be a reuse of b u i l d i ng blocks fo r larger
workflows. A second use of a com posite work­
flow is to ex p l i c i t ly express responsi b i l i t y tRA, which are then d iscussed .

Vol. (i No. -i

f·i1ff f')'l!

Digital Technical journal

Policy Resolution in Workflow Management Systems

Roles As Task Assignment Rules
As stated earl ier, roles have l i mi ted use as task
assignment ru les. Applyi ng the role concept to the
task assignment rules i ntroduced above i l lustrates
t he limitations. Certain ly, the term role has m an y
definitions. I n this paper, a role is a n abstraction o f
a set o f users. T h e abstractio n criteria are t h e set
of capabilities of a user. Whether or not a particular
u ser belongs to the set of users abstracted by a role
is defi ned by a n explici t relationship between
a u ser and a role cal led the " p lays " relatio nship. A
user who has a plays relationship w i t h a role has the
capabil i ties defined by that role, i . e . , the user is able
to play the role. For example, i f both Ann and Joe
are users who are able to play the role of clerk, t hen
each one has t he capabil i t ies defined by t h is role
and each is capable of exec u t i ng the task. A user
m ight have a wide range of capabi lities and be able
to play several roles at the same time. For example,
a user might be able to play the role of employee
and the role of manager simu l taneously. Although
this defi nition of role is not the only one, it is very
' o2.626un.ct
common and often applied (, 1 " .H
For each task assignment rule that was i ntro­
duced in the travel expense reimbursement exam­
ple, a d iscussion foJ l ows about the exten t to which
roles support the requ irements.
•

Fi l l . The task assignment rule for the f i l l step is
the only rule of the example that can be modeled
completely with a role. Assume that every user is
able to play the role of employee. If the fil l step
is assigned to the role of employee, every user
can execute the step, thus modeling exactly the
task assignment ru le of the fill step.

•

Check. Assigni ng the check step t o t he role of
secretary does not model the fu l l semantics
of the desired task assignment ru le. Such an
assignment models o n ly the requ irement t hat
a user has to be able to play the role of secretary
to carry out the step. The assignment does not
model the additional requirement that o n ly
those users who report to t he same manager as
the appl icant are el igible.

•

Sign. Analogous to the situation i n the check
step, assigning the sign step to the role of man­
ager does not model that only a user to whom
the appl icant reports is el igible but that any man­
ager is el igible.

•

Reimbu rse. Assigning the rei m b u rse step to the
role of financi a l clerk ensures only that the step

Digital Technical journal

Vol. 6 No. 4

Fall 1994

i s assigned to a capable user. The assignment
does not fu l fi l l the additional requ iremen t that
this u ser must a lso be respo nsible for the group
to which the applicant belongs.
The discussion of the l ast three task assignment
rules demonstrates two tightly coupled l imitations
of using roles to model requirements.
1. The concept of roles cannot express organiza­

tional dependencies, such as relationsh ips
between users (e. g . , " reports to" and " responsi­
ble for"). I t o n ly relates users to roles by a plays
relationship. F u rthermore, roles do not provide
a means of i n trod ucing add itional objects of
organization structures l ike "group" and "depart­
ment." The o n ly t wo objects the concept of
roles provides are " role" and " user."
2. The concept of roles, therefore, does not p ro­
vide a sufficiently soph isticated language to
express, for i nstance, that a user n o t only has
to play a certain role but a lso h as to relate to
some o ther user i n a particular way (e . g . ,
" reports to" a particu lar user).
In addi t ion, the other requ irements l ike h istorical
access, delegation, and separation of d u ty cannot
be modeled at all using roles.
To overcome these l i m i tations, PRA i ntroduces
the concepts of organization schema and organ iza­
tional pol icy and the Pol icy Defi n i tion Language.
A brief introduction fol lows. Details are presentee!
i n the section Po licy Resolution Arc h i tecture.

Organization Schema
One of the fundamental concepts of PRA is a freely
definable organization schem a . An organization
schema contains aU types of orga n i zational objects
and re.l at ions h ips t ha t are availab1e for m o de l i ng
a particular organ i zation. Figure 2a gives an exam­
ple of an organi zation schema . Jf a defined schema
is i nstan t iated , i t contains an o rganization struc­
ture. Since o ther objects besides roles are requ i red
to model an orga n i zation, rel ationships other than
" plays" must be ava i l able. Some necessary addi­
tional relationsh ips are " reports to," which relates
two users, and "is responsible for" a nd " belongs to,"
which relate a user and a group. A freely definable
organ ization schema , such as the one provided by
PRA, a l lows designers to define roles as required
by the workflow application .
Such a freely definable organization schema m ay
seem to be a luxu ry, and a fixed organ i zation

33

Workflow Models

ROLE

PLAYS
R E PORTS

TO

/ / -

- -',

RESPONSIBLE
FO R

(, 6•
I

',

_ _ _

\

D

GROUP

- - B E LONGS
TO

,

I

USER

(a) Sample Organization Schema

SALES

AL

M A N U FACTU R I N G

NINA

KEN

ENGINEERING

SUSAN

CHARLES

MATT

88

A D M I N I STRATION

MIKE

8

(b) Sample Orga n iza tio n Structure

Figure 2

Sample Organization Schema and Organization Structure
for the Travel Expense Reilnbursement Example

schema t h a t provides t h e m o s t relevant objects and

relationships may seem s u fficient. An analys is of

seman t i cs

completely.

Consequen tly,

such

a

schema does not meet enterprise-specific needs.

va rious orga n i zation structures i n different enter­

Figure 2a shows a graph ical represen tation of a

prises c l early shows, however, tha t a si ngle organi­

sample schema for t h e travel exp ense reim burse­

zation schema is not adequate for all situatio ns

ment example. Although this schema may appear

i n which WFMSs can be dep loyed. An e n terprise

ge neral and a n adequate alternative tO an a l l ­

that deploys a schema i n w hich the semantics of

embracing schema, i t does n o t conta i n requi red

the mode led objects are fixed has to fo l l ow the

o rganizational objects such as task fo rces w i t h

34

Vol. 6 No. 4

Fall 1994

D igital Tee/mica/ jourrml

Policy Resolution in Workflow Management Systems

a l imited l ife span, comm i ttees, and departments.

Figure 3a shows an example of an informal orga­

Also, this sample schema does not consider objects

n izational pol icy for the sign step. This organiza­

or relationships necessary for modeling delegation

tional pol icy specifies that if the WFMS is to assign

and relocation of employees. F igure 2b d isplays a

the sign step, it wil l assign the step to the manager

superficial organization structure, i. e . , an instantia­

of the appl icant if the amount is less than $ 1 ,000.

tion of the schema. Objects l ike user and role are

Otherwise, it will assign the step to the vice presi­

depicted as icons, and relationships are depicted as

dent respo nsible for the applicant's group . A more

arcs and solid, dashed, and dotted l i nes between

advanced rule woul d not fix the amount at $ 1 ,000
but wou l d make this amount dependent on the

the icons.

au thorization level of the manager, as i l lustrated i n

Approaches that go beyond using roles as a basis

Figure 3 b .

for task assignment commo n.ly prov ide organiza­
tional objects in addition to roles and users, usually

The Policy Defin ition Language is PRA's formal

group and/or department objects U•.S o9.n The l i tera­

l anguage for specifying organizational pol icies.

ture contains evidence that the schemas and the

Policies written in t h is language are precise and

task assignment ru les are fixed and have to be used

executable by an execution engine cal l ed the pol­

as they are . Additional ly, these approaches do not

icy resolu tion engine. Each t i me the WFMS is about

separate the workflow from the workflow specifi­

to assign a step, the system evaluates the corre­

cation, which makes the reuse of a workflow in a

sponding organ izational policy to determine the

different organizational setting very d ifficu lt.

set of users who can execute the task.

Organizational Policies As Task
Assignment Rules

Policy Resolution Architecture

A second fundamental PRA concept is that of an

environments and in group, department, enter­

\VFMSs operate in global, open, and distributed

organ izational policy, which up to this point has

prise,

been cal led a task assignment ru le. An organiza­

enterprise- level deployment of workflows is pos­

and

m u ltiple-enterprise

settings.

The

tional pol icy specifies a l l the eligibl e users for a

sible o n ly if the u nderlying concepts and sys­

task by stating the criteria a user must meet. These

tems are developed appropriately. PRA is therefore

criteria can include a role or roles that a user has

based on several design principles that ensure a

to be able to play and relationships that a user has to

general approach that supports enterprise-level

.have with other users or groups.

deployment .

(a}
WORKFLOW TravelExpenseReimbursement
STEP

sign

CRITERIA IF amount <

1000

THEN manager o f applicant

ELSE VP responsible

for applicant ' s group

ENDIF

(b)
WORKFLOW TravelExpenseReimbursement

sign

STEP

CRITERIA IF amount < authorizat ion leve l of applicant ' s manager
THEN manager of

applicant

ELSE VP responsible

for applicant ' s group

ENDIF

Figure 3

Digital Technicaljow·nal

Informal Organizational Policiesfor the Sign Step of the
Travel Expense Reimbursement Workflow

Vol. 6 No. 4

Fa/1 1994

35

Workflow Models

Design Principles

to m a k e o rga n i z a t i o n a l p o l i cies objects i n them­

The PRA des ign p r i n c ip les are reusability, sec u r i t y.

s e l ves, i n dependent of a workflow speci fica t i o n .

genera l ity, dynam ics, ami d is t r i b u t i o n .

Orga n i z a t i o n a l p o l icies name n o t o n l y t h e s t e p in
which t h ey are used but a lso the su rro u n d i ng work­

Reusability

I n the travel ex pense reimbu rsement

flow. The design o f organizational p o l icies fo r a

exa m p l e , t h e sign step was modeled to approve

step depends on the context in which the step is to

travel expenses.

he re used .

Other workflows, l i k e capital

equipment orde rs, can reuse the sign step for s i m i­

As m e n t ioned earl ier, m a k in g organ izational p o l i­

l a r tasks, e . g . , to a pprove an o rd e r. I f an orga n i za­

c i es i nd e p e n d e n t objects a l lows d i ffe ren t orga ni­

t i o n a l p o l icy were a t tached t o the s tep t yp e i t se l f,

zation s t n � c t u res to reuse a workflow. To ach ieve

this assign ment ru l e wo u ld serve to determine eJ igi­

such reuse, each organ izational s e t t i n g has its own

ble users i n dependent o f the workflow in wh ich

set of o rgan ization a l p o l icies for the workflow to he

the step is re used . Viewed from an organ izationa l

re used . These orga n i z a t i o n a l p o l icies are t a i l ored

p e rspective, however, the reuse of steps in d i ffer­

to the specific needs and circumstan ces o f the orga­

ent wo r kflows req u i res several pol icies. For exam­

n i z a t i o n a l s e t t ing.

ple, the signing of a t ravel expense reimbu rseme n t

Organizational pol icies can them selves be reu sed .

for m is carr iecl o u t b y a m a n ager o f the appl icant.

D i ffe re n t steps m ay requ ire t he same set of el igible

w h e reas t h e s igning of a c a p i t a l equ ipment order

u s e rs, and, therefore, one p o l icy wou ld be s u ffi­

for an a m o u n t that exceecls a certain v a l u e i s carried

cient fo r more t h a n one k i nd of step ( e . g . , sign ami

out hy a n appropriate vice pres i d e n t . Therefo re ,

fi l l ) o r t( J r more than one u s e of t he same k i n d of

the sign step in t h e con text o f a travel expense reim­

step. For exa m p l e , a m anager signs not o n l y trave l

b u rsement workflow has a n organiza t i o n a l p o l icy

expense fo rms b u t a l so c a p i t a l eq u ip m e n t o rders.

t h a t defines the m a nager of the appl icant to be el igi­

I n bot h workfl ows, the orga n i za t i o n a l pol icy t h a t

ble, whereas t he sign step in the context of the cap­

defines t h e m a nager of t h e a p p l ica n t d e p e n d s o n

i t a l equipment o rd e r workflow has a d i ffe re n t

t h e a u t horization leve l . B o t h w o r kflows can re use

p o l i cy, one that defines a n appropriate vice presi­

t h e sign step, as c a n be seen in the policy s h own

dent as e l igible fo r the task.

in Pigu re 4a . If the a u t h o r i z a t i o n l e ve l d epends on

'T"he observa t i o n that a p o l i c y for a step depends

the wo rkflow, the p o l icy c h a nges to take i n to con­

not o n l y o n the step itself b u t a l s o o n the workfl ow

sicle ration t h e spec ific k i nd o f workflow, as s h own

in w h ich t he step is re used led to t he d ec i s io n

i n Figure 4b.

(a)
WORKFLOW TravelExpenseReimbursement
STEP

I

CapitalEquipmentOrder

sign

CRITERIA IF amount < authorization level of appl icant ' s manager
THEN manager of app licant
ELSE VP responsible for appl icant ' s group
ENDIF

(b)
WORKFLOW TravelExpenseReimbursement
STEP

I

CapitalEquipmentOrder

sign

CRITERIA IF amount < authorization level of applicant ' s
manager depending on workflow type
THEN manager of applicant
ELSE VP responsible for applicant ' s group

ENDIF

Figure

4

Informal Organ izational Policies Showing Reuse of the Sign Step

l '<1l. (> .Vo.

.:f

Fall

1')')4

Digital Tecbuical jourual

Policy Resolution in Workf!o·w Management Systems

Because changing an organ izational pol­

Fo l lowing this ge neral approach, it is apparent

icy may affect daily business operations, aJ I users

that a fixed set of assignment ru les is also inade­

should not be able to make changes a t wil l . For

quate. The PRA design hence provides a language

Security

exa mple, a user (appl icant) should not be able to

that enables users to define task assignment ru les

approve h is/her own travel request. Organ izational

(organ izational policies) as required by the work­

pol icies are therefore objects that m us t be properly

flows of an enterprise.

secured to prevent users from perfo r ming u nau­
thorized tasks. The decision to design organiza­

Dynamics

tional pol icies as objects m a kes it easier to secure

sons, e.g. , employee nu mbers fluctuate, restructur­

the pol icies, because secu rity mechanisms such as

ing takes place, groups j o i n or split because of new

Organ izations change fo r many rea­

access control l ists (ACLs) can be applied d i rect ly

product stra tegies, etc. Business operations and

to objects. '5

the refore workflows, however, must cont i nue unin­

Designers considered and rejected the a lter­

terrupted. To do so, the organization structure and

nat ive approach of sec uring the workflow specifi­

the organizational pol icies of a WFMS must cha nge

cation

to reflect the changes in the real organization. The

and ,

consequ ently,

the

organ izational

policies included in the specification. Wo rkflow

decision to separate workflows from organization

types do have to be secured to prevent unautho­

structu res and organizational pol icies enables users

rized changes; however, securing the workflow

to change versions independent ly. For exa mple, an

specification wou ld al low those who are e ligible

organiza t ional pol icy can change while a workflow

to change the workflow type to a lso change the

that uses i t is running. If the change takes place

associated organizational po.l icies. Such an a l l ­

before the WFMS assigns the step to a user, the

encompassing security design i n hibits t h e separa­

WFMS wi l l use the new version of the organiza­

tion of d u ty between workflow designers who care

tional policy instead of the old version . Policy

about how a busi ness p rocess is i mplemented by

changes result i n neither the shu tting down of the

a workflow and organization designers who care

WFMS nor the stopping and restarting (from the

about the organ ization structure and the user capa­
bilities and responsibi l ities. Protecting workflows

beginning) of the workflow. This independence
al lows WFMSs to deal with the dynam ics of an orga­

independently of organ izational pol icies al lows

nization and make correct task assignments whi le

users to modify a workflow without al lowing them

changes are taking place .

to mod ify organizational policies and thus gain or
grant unauthorized e l igibi l i ty. Simi larly, organiza­
tion schemas a nd organization structures must be
secured

independent ly to prevent users

from

changing roles or relationships to gain or grant
unau thorized authority.

Distribution

Not only are enterprises becom­

ing more distribu ted, but they are also increasing
their worldwide operation. Nations have d i fferent
local

Jaws and

pol icies

because they decide

autonomously on these issues. A local subsidiary
has to ad here to local law, even though it belongs

Although several standard orga ni za­

to a com pany that operates worldwide. for exam­

tion structures prevail-strong hierarchical, matrix­

ple, U.S. compan ies have a posi tion called vice

shaped, function-oriented, and networked-hybrid

presid ent. A U.S. company may have the rule

organ ization structures exist, which contain a myr­

that contracts with external suppl iers of m anu­

Generality

iad of anomal ies and exceptions. Independent of

facturing parts m ust be signed by the vice presi­

their organ ization structure, most enterprises have

dent of manufactu ring. If the U. S. company has a

business processes that are potential candidates for

German subsidiary, by German law, t h is subsidiary

a WFiviS implementation. A WFMS that claims to be

is a company in itself and must have a person cal led

able to implement business processes in a l l kinds of

Geschdftsfiihrer who is responsible for the opera­

enterprises must therefore be able to support a l l

tions of the company. If the subsidiary wa nts to

possible organ izat ion structures. A fixed organiza­

enter into a contract with a supp l ier, German law

tion schema is inadequate fo r such a u n iversal

requires the Geschdftsfiih-ret· to sign the contract

PRA

even though the U.S. corporate organizational pol­

implementation

capabi l i t y.

Consequen t.ly,

supports the modeling of arbitrary organ i zation

icy requires the vice president of manufacturing

schemas and a l lows WFMSs to i m plement any orga­

to sign. Al though the same type of workflow is

nization that m ight exist.

running in both countries, e.g., the contract with

Digital Tecfmicaljounwl

Vol. 6 No. 4

Fall

1994

37

Workflow Models

externa l suppl ier workflow, the organ i zational
pol icies for the approval step d iffer. The U.S.
version of the o rga n i zational pol icy specifies the
vice president of manufacturing is the only el igible
user, and the German version specifies that the
Geschdftsfiihrer is the only el igible user.
Domains were i n troduced to deal with the issue
of au tonomous pol icies. A domain is an abstract
entity of managemen t . Organizational p ol icies as
wel l as workflows are related to domains. The pre­
vious example might i nvolve t wo domains: " USA"
and " G ERMANY." ( The domains could be fu rther
subdivided.)
The p r i nciples just discussed gu ided the PRA
design. As mentioned i n the previous section,
P RA defines the concepts of organization schema,
organizational pol icy, and a fo rmal language to
model pol icies. In add i t i o n , I ' RA defines i n terfaces
for an exec u t i o n engine and their use by a WF!VIS. A
detailed d iscussion of the PRA components fo llows.

Organization Schema and
Organization Structure
The PRA organization schema is a set of objects and
rel ationships that can be freely defi ned, thus
enabl i ng users to model arbitrary orga n i zations.
Each member of t he set can be i nstantiated to popu­
l ate an organization schema, that is. to p roduce an
organization structure. PRA al lows users to define
constraints on the organization structur e to avoi d
erroneous structures. For example, if an enterprise
has the p o licy that an employee m ust not report
to more than two people, PRA enables the user to
define a constrai n t that specifies that one person
can be related to only two others through a " reports
to" relationsh ip . If a modeler adds a third reporting
I ine, the system detects the violated constraint.

Organizational Policy
An

organizational pol icy specifies a set of el igible
users for a given workflow, which can be either ele­
mentary (a step) or composite. A set of users is not
stable and therefore fixed but speci fied through an
expression cal led an organizational expression. An
organizational expressi o n specifies t ile selection of
users with particular p roperties from an o rga n i za­
tion structure. For example, an expression might
enumerate users, select all users able to play a p a r­
ticular role, or select a user related to some other i n
a specific way. A d d i t ional ly, orga nizational expres­
sions can refer to the h istory of a workflow or to its

:38

i nternal data, such as local variables, and thus be
dependent on the workflow state. Consequently,
the set of users for the same step in two different
instances of the same workflow m ight be d i ffer­
ent. Consider, for example, the travel expense reim­
bu rsement workflow, with the user selection for
the sign step depen dent on the authorization level .
I n two i nstances o f the workflow, t he amou n ts to
be reim b ursed m ight differ such that different peo­
ple , e.g. , t he m anager ami t he vice p resident, m ust
execute the t wo sign steps.
To provide a general mechanism for determ in i ng
a set of el igible users for a workflow, PRA organ iza­
tional pol icies accom modate operations in addi­
tion to exec u ti ng a step or taking responsi b i l i t y for
a composite workflow. Delega ting a workflow and
undoing a workflow are two examples. To delegate
a workflow, an orga n i zational pol icy has to ensure
that both the person who delegates the workflow
and the person to whom t he wor kflow is assigned
are el igible users. The o peration of undoing a work­
flow ( i . e . , to u ndo the resu l t s ach ieved thus far) a nd
starting aga i n can result in wasted effort a n d u nre­
coverable work. Therefore, a WFMS m u st carefu l ly
choose el igible users for this operation.
To deal with various workflow operations, a P RA
o rganizational p ol i cy relates a workflow t ype and
one of its opera t ions in a given tlom a i n tO an organi­
zat i o n a l expressi o n . An orga n i zational pol icy is
defined as t l1e tuple . For example,
the orga n i zational pol icy for the fi l l step in
the t ravel expense rei m b u rsement example is
 . Since
an appl icant shou ld be able to undo the step and
start aga i n , the WFMS m ust also specify the organ i­
zational pol icy  . ( The next
section describes PRA's for m a l language for specify­
ing organizational policies.)
When a WFMS dete r m i nes that a workflow in
a particular domain is to be executed, i t cal ls
the policy resolut i o n engine, which looks for the
appropriate o rga n i zational policy and evaluates
its organizational expressi o n . 'fhe engine returns
the results of the evaluation, i . e . , the set of el igible
users, to the WFMS, which subsequently assigns the
workflow to those users. One organizational policy
can be reused for several workflow types, domains,
etc . , by entering a set in tlw appropriate element
of the tuple. For example, if the orga n i zational

Vol. 6 No. 4

Fall /')')4

Digital Technical journal

Policy Resolu tion in Workflow Management Systems

pol icy for the fi l l step of the travel expense reim­

tiona! expressions. Final ly, the third part supports

bursement workflow is the same i n the U.S.

the definition of organizational policies.

as it is i n Europe, the policy cou ld be modeled as

The fol lowing figures illustrate the POL for a sam­

.

bu rsement workflow. Figure 5 shows the POL for

Policy Definition Language

the organization schema displayed in Figure 2a. The

From the organizational viewpoint, the fol lowing

POL for the instantiation d isplayed i n Figure 2b

elements are necessary to run a workflow: an organi­

appears i n Figure 6.

zation schema together with its instantiation, the

The organization schema defin i t ion part of the

organizational policies for this workflow, and the rel­

POL looks like a d ata definition language (DOL) i n a

evant organizational expressions. To describe these

relational database. Two differences exist, though:

elements in a formal way, PRA defines a language

(1 ) PDL d istinguishes organizational object types

cal led the Policy Definition Language (PDL), which

from organizational relationship types, and (2) POL

consists of several parts. The first part enables the

al lows complex data types (e.g. , sets as attributes).

definition of an organization schema and its popu la­

If a pol icy resolution engine is bu i l t on top of a rela­

tion. The second part is concerned with organiza-

tional database, a compi ler or a translator within

ORGANIZATION_TYPE Role
ATTRIBUTES name :

String

authorization_level :

set ( task,

amount ) ;

KEYS name;
ORGANIZATION_TYPE Group
ATTRIBUTES name :

String

KEYS name;
ORGANIZATION_TYPE User
ATTRIBUTES name :

String

office_tel_# :
e_mail :

String

String

absence :

{vacation,

ill,

busine s s ,

avai labl e}

KEYS name ;
RELATIONSHIP_TYPE Reports_to
FROM User
TO

User

ATTRIBUTES kind :

{ l ine ,

functional ,

none }

RELATIONSHIP_TYPE Plays
FROM User
TO

Role

ATTRIBUTES duration_from:
duration_to :

date

date

RELATIONSHIP_TYPE Responsible_for
FROM User
TO

Group

RELATIONSHIP_TYPE Belongs_to
FROM User
TO

Figure 5

Group
for simplicity,

we assume user names to

be

Note

that ,

this

is not the case and the modeling must deal with nonunique names .

unique .

In reality,

Policy Definition Language for the Sample Organization Schema Shown in Figure 2a

Digital Technical journal

Vol. 6 No.

4

Fall 1994

39

Workflow Models

Role "Employee" ,

{}

"Manager" ,

{ ( TravelExpenseReimbursernent . Sign,
( Capi talEquipmentOrder. Sign,

"Financ ialClerk" ,
"Secretary" ,

{}

"Engineer" ,

{}

"VP " ,

100 0 ) ,

5000 ) }

{}

{ ( TravelExpenseReimbursement . Sign,
( CapitalEquipmentOrder . Sign,

*),

*) }

Group "Sales"
"Manufacturing"
"Engineering"
"Administration"
" [1)

125-5589",

"al@center . com" ,

avai lable

" [1)

125-5590",

"nina@center . com" ,

avai lable

125-5601",

"ken@center . corn" ,

avai lable

"Susan" ,

" [1)

125-5609",

"susan@center . com" ,

business

"Matt " ,

User "Al " ,
"Nina" ,
,
"Ken' ,

" ( 1]
" ( 1]

125-4499 " ,

"matt@center . com" ,

avai lable

"Charles" , " [ l ]

125-4580" ,

"charles@center . com" ,

available

"Mike" ,

125-0101",

"mike@center . com" ,

avai lable

" [1)

Repcrts_to "Al " ,

"Nina " ,

line

"Ken" ,

"Nina" ,

line

"Nina " ,

"Mike " ,

line

"Susan " ,

"Matt'' 1

line

"Charles " ,

"Matt" ,

l i ne

"Mat t " ,

\\Mike " ,

Plays "Al " ,

line
none

"Mike " ,
"Employee" ,

01-02-88,

"FinancialClerk" ,

"Al " ,

0-0-0

01-02-88,

"Nina " ,

"Employee" ,

0 1 - 02 - 9 0 ,

0-0-0

"Nina" ,

"Manager" ,

01-02-90,

0-0-0

"Ken" ,

"Employee" ,

01-02-91,

0-0-0

"Ken" ,

"Secretary" ,

01-02-91,

0-0-0

" SUsan" ,

"Employee" ,

01-02-92 ,

0-0-0

"SUsan" ,

"Secretary" ,

0 1- 0 2 - 9 2 ,

0-0-0

"Matt " ,

"Employee" ,

01-02-88,

0-0-0

"Mat t " ,

"Manager" ,

01-02-88,

0-0-0

( * open ended . )
0-0-0

"Charles " ,

"Employee" ,

01-02-88,

0-0-0

"Charles" ,

"Engineer" ,

0 1- 0 2 - 8 8 ,

0-0-0

"Mike " ,

"Employee" ,

01-02-90,

0-0-0

01-02-93 ,

12 - 3 1 - 9 7

"'fPII ,

"Mike " ,

"Sales"

Respons ible_for "Al " ,
"Al " ,

"Manufacturing"

"Al " ,

"Engineering"

"Mike " ,

"Sales"

"Mike " ,

"Manufacturing"

"Mike" ,

"Engineering"

Belongs_to "Al " ,
"Nina " ,

"Administration"
"Engineering"

"Ken" ,

"Administration"

"SUsan" ,

"Administration"

"Matt " ,

"Engineering"

"Charles" ,

"Engineering"

"Mike" ,

Figure 6

...j ()

Policy Definition Language.: fo r the Sample Organ ization

Structure (Instantiation) Sbott'J I in fl�r.;ure

l fJI.

()

.\'u. 4

2b

Tall 199-1

Digital Tecbuical journal

Policy Resolution i n Workflow Management Systems

the engi ne translates the organization schema defi­

role of secretary and who report to the same user

n i tion part of PDL into a set of DDL statements.

as the app l icanr.

expressions

Independent from the travel expense reimburse­

required to for m u l ate the orga n izational pol icies

ment example are the sample separation of d u t y

for the travel expense re imbursement workflow.

and delegation pol icies shown in F igures 9 a n d 10.

F igure 7 l i sts the

organizational

Note that the organizational expression for employ­

The organ izational pol icy that specifies separation

ees selects a l l users who p l ay the role of employee.

of duty ensures that the user who signs the expense

The R ETURNS statement ind icates the search for

for m is d ifferent from the user who fi l l s out the

users. The defini tion of the p lays re lationship type

for m . The policy that models the delegation opera­

i n Figure 5 ind icates that the emp l oyee is of the

t i o n contains a parameter that specifies to which

type rol e . This i n formation is sufficie nt to formu­

person the sign step is t o be delegated. Only the

late

a

query to the un derlying database system in an

manager of the applicant can ca l l t h is operation
and then o n l y i f the p arameter specifies either the

implementation of a pol icy resolu tion engi n e .
The PDL for the organ izatio n a l p o l icies for the

next higher m a nager or the responsi ble vice presi­

travel expense rei m b u rsement example appears in

dent. The step can be delegated only to one of these

F igure 8. The WFMS applies the first orga n i zationa l

two users.

pol icy when assigning the fil l step in a travel expense

Since the PDL is wel l defined, it can be used not

re i m b u rsement workflow. The p o l icy is val i d i n

only by designers to model organizations and p o l i­

three dom ains, USA, EUROPE, and ASLA, for t h e exe­

cies bm also by developers of graphics-oriented

c u te operat i o n , which has no parameters. The pol­

tools. Such too ls could present graphical symbols to

icy engine returns a set of all users who are able to

users to be m a n ipu lated . When a user decides to

play the role of employee. The second pol icy l isted

com mit the changes, the tool generates a PDL script,

in Figure 8 returns a set of al I users who play the

which is fed into the pol icy resolution engine.

ORGANIZATIONAL_EXPRESSION employees ( )
RETURNS User :

user

user plays employee
ORGANIZATIONAL_EXPRESSION secretaries ( )
RETURNS User:

user

user plays secretary
ORGANIZATIONAL_EXPRESSION rnanager_of (User :
RETURNS User:

a_user)

user

a_user reports_to user
ORGANIZATIONAL_EXPRESSION subordinates_of ( User :
RETURNS User:

a_user)

user

user report s_to a_user
ORGANIZATIONAL_EXPRESSION group_of ( User :
RETURNS Group :

a_user)

group

a_user belongs_to group
ORGANI ZATIONAL_EXPRESSION VP_responsible_for_group_of ( User:

a_user)

RETURNS User : user
user plays VP
INTERSECTION
user responsible_for group_of ( a_user)
ORGANI ZATIONAL_EXPRESSION executing_agent (Workflow:

a_workflow)

RETURNS User

(*

Figure 7

provided by the

historical

services

of WFMS

*)

Orga nizational Expressions for the Travel Expense Reimbursement Example

Digital Technicaljourual

Vol. 6 No. 4

Fall 1994

41

Workflow Models

ORGANIZATIONAL_POLICY
WORKFLOW

TravelExpenseReimbursement . Fill

OPERATION Execute ( )
DOMAIN

USA,

EUROPE ,

ASIA

ORGANIZATIONAL_EXPRESSION employees ( )
ORGANIZATIONAL_POLICY
WORKFLOW

TravelExpenseReimbursement . Check

OPERATION Execute ( )
DOMAIN

USA,

EUROPE ,

ASIA

ORGANIZATIONAL_EXPRESSION
secretaries ( )
INTERSECTION
subordinates_of (
manager_of (
executing_agent (
TravelExpenseReimbursement . Fil l ) ) )
ORGANIZATIONAL_POLICY
WORKFLOW

TravelExpenseReimbursement . S ign

OPERATION Execute ( )
DOMAIN

USA,

EUROPE,

ASIA

ORGANIZATIONAL_EXPRESSION
manager_of (
executing_agent (
TravelExpenseReimbursement . Fi l l ) )
ORGANIZATIONAL_POLICY
WORKFLOW

TravelExpenseReimbursernent . Reimburse

OPERATION Execute ( )
DOMAIN

USA,

EUROPE ,

ASIA

ORGANIZATIONAL_EXPRESSION
f inancial_clerks ( )
INTERSECTION
User :

user responsible_for

group_of (
executing_agent (
TravelExpenseReimbursement . Fi l l ) )

Figure 8

Organizational Policiesjor t!Je

Tremel Expense

Reimbursement Exanzple

ORGANIZATIONAL_POLICY
WORKFLOW

TravelExpenseReimbursement . Sign

OPERATION Execute ( )
DOMAIN

USA,

EUROPE,

ASIA

ORGANIZATIONAL_EXPRESSION
manager_of (
executing_agent (
TravelExpenseReimbursement . Fi ll ) )
DIFFERENCE
execut ing_agent (
TravelExpenseReimbursement . Fi l l )

Figure 9

Organizational Polhy for the Separation of Duty

Approaches l i ke the ones mentioned earlier in

users fo r a workflow. None of these approaches

the paper provide a fixed set of types fo r model ing

provides a language l i ke PDL that can freely define

an organi zation or a fixed set of functions, such as

tbe organ izationa l aspect as the appl ication seman­

·' role play e r or '·supervisor," from which to select

tics requires.

"

42

Vol. 6 No. 4

Fall 1994

D igital Tee/mica/ journal

Policy Resolu tion in Workflow Management Systems

ORGANIZATIONAL_POLICY
WORKFLOW

TravelExpenseReimbursement . S ign

OPERATION Delegate
OOMAIN

USA,

{User:

EUROPE,

a_user)

ASIA

ORGANIZATIONAL_EXPRESSION
IF a_user IN
{manager_of {
manager_of {
executing_agent {
TravelExpenseReimbursement . Fil l ) ) )
OR
VP_responsible_for_group_of {
executing_agent (
TravelExpenseReimbursement . Fi ll ) ) )
THEN

manager_of (
executing_agent (
TravelExpenseReirnbursement . Fil l ) )

F(f?ure

10

Organizational Policy for the Delegate Operation

Policy Resolution Engine

set of resu lts, the conform to operation returns the

The p o l icy resol ution engine is a mechanism that

va lue " true " ; otherwise it returns the va lue " fa lse."

evaluates organizational policies for a WFMS. Serving
as

a

base service, the policy resoi ution engine

manages organizational pol icies and organ izational
expressions, as wel l as the organization schema and
its populatio n . The engine also provides i nterfaces
for the defin ition, m o d ification , and evaluation
of these objects. The interfaces are distinguished
by the kind of service they prov ide. There are basi­
cal ly two k i nds of i n terfaces: evaluation i n terfaces
and management interfaces.

Evaluation Inte1jaces

Pol icy resolution engine clients use this operation
to validate a request by a user to execute a certain
task of a workflow.
The resolve and conform to operations for o rga­
n i zational expressions work analogously. Instead
of a workflow reference, the operations expect
the name of an organ izational expression as input.
The operations evaluate the named organizational
expression and return the set of resul ts, which
is used if the resolve operation is called . The con­
form to operation returns true and false values as

Policy resolution engine

described in the previous paragraph.

cl ients use evaluation interfaces to evaluate organ i­
Management interfaces

zational policies or organ izational expressions

Management Interfaces

when necessary. The engine provides fou r evalua­

are used to define, mod ify, or delete orga nizational

tion i nterfaces: two for organizational policies

policies, organizational expressions, o r organiza­

( " resolve" and "conform to") and two for organi­

tion schemas and their popu lations. These inter­

zational expressions (also "resolve" and "conform

faces look like the fol lowing operations that are

to"). The reso lve operation for organizational poli­

provided for organizational policies: create, delete,

cies expects a workflow reference and one of its
operations as input values. This operation selects

modify, l ist, get. The create operation creates an

an appropriate organizational policy, evaluates i t ,

a policy; the modify operation a l lows users to

and returns a set o f users el igible t o execute t h e

change an organizational pol icy to adjust to new

given task o f t h e workflow. T h e conform t o opera­
tion for organizational pol icies expects a workflow

fiers of all pol icies; and the get operation returns

reference, one of its operations, and a user as input

the complete description of a policy.

values. This operation resolves the appropriate

organizational policy; the delete operation deletes

requirements; the l ist operation returns the identi­

Designers do not cal l these management inter­

organizational pol icy for the workflow and checks

faces

whether the user is contai ned in the set of results

changes through user-friendly interfaces or tools.

for that organizational pol icy ( i . e . , if the user con­

These tools are either graphics oriented or language

forms t o the pol icy). If the user is conta ined i n the

D igital Techuical]ou1·nal

Vol. 6 No. 4

Fall 1994

directly,

since

they

communicate

their

oriented. In a graphics-oriented tool, a designer

43

Workflow Models

m a n i p u lates icons and gra p h ical symbols, w h i c h i n

I f the releva nt d a t a is s tored i n several d atabases,

tu rn re s u l ts in ca l l s to t h e app ro priate management

the query i ng i n terface must be b u i l t in such a way

i n t e rfaces. Al ternatively, a grap h ics tool can ge n e r­

t h a t the pol icy res o l u t i o n e n g i n e can issue the nec­

ate a PDL script accord ing to the ma n i p u l a t i o n s of a

essary queries, w h i c h m i g h t span several databases.

user and subm i t t h i s s c r ip t to t h e pol icy reso l u t i o n

Fu rthermore, sem a n t ics i ssues have t o be dea l t

e n g i n e . I n t h i s c a s e , the e n g i n e i n t e r p rets t h e s u b­

w i t h i n he t e roge neou s environments_ -,_-(,

m i t ted scri p t and cha nges its i n t e rn a l state accord­
i ngly. Language-oriented tools e nable a designer to

Arcbitec tuml Considemtiolls - Clients of a PoliLy

d i rectl y express cha nges using PDI.. These tools take

Resolution Engine

specifica t i o ns and translate them i n t o ma nage m e n t

F ro m an arc h itectural p o i n t of

view, there are two possible ways to design a pol icy

i n t e rface cal l s . O f c o u r s e , t hey c a n also s u b m i t t h e

reso lutio n e n g i n e :

l a nguage specifi c a t i o n s d i rec t l y as Ill ) ! . s c ripts t o

1. I n c o r p o r a t e the p ol i c y re s o l u ti on engine i n to

t h e po l i cy reso l u t io n e n g i n e , as descri bed above.

L egeny Databases

Many l a rge en terprises have

developed da tabases t h a t c o n t a i n some o r a l l of the
orga n i za t i o n a l data the p o l i cy reso l u t i o n engi n e
needs t o eva l ua te orga n i za t i o n a l p o l i c ies

.

These

dat abases, c a l led legaqr databases, m ig h t he s e l f­

a \VF,\1S T he engine wou ld be a m o d u l e, wh ose
o p erat ions are h i dden by the exported i n t e r­

faces of t h e WFMS. Al l c a l l s to t h e engine o p e ra­
t i o ns wo u ld he made t h rough the i n terface o f
the WI'NJS.

2. M a ke the p o l icy resol ut ion engine a n i n depen­

i m p l e m e nted or based on stan dards efforts like

d e n t COI11[1 0 n e n t . The engine wou l d be a se r ver

t h ose re la ted t o prov id i ng d i rectory services on

w i t h a W F �IS system as one of i t s cl i e n t s . Al l

X.500.-' In ge neraL o rgan iza t i on s

c l ients of the engi n e , i n c l u d i ng the WF�I S , wou l d

n e t works, i e .
.

,

m u s t deal w i t h one of the fol lowing scenarios:
•

be a b le to d i rec t l y access t h e exported o p e ra­

No legacy d a t abase exists. No existi ng d at abas e
h a s t o h e consi dere d and the p ol i c y res o l u t i o n
,

•

PRA rec o m mends t he i m p l e m e n t a t i o n o f a p o l icy

engine can u s e i ts own database t o b u i ld u p orga­

reso l u t i o n eng i ne as an i n dependent base se r v i c e

n i zationa l knowledge .

whi ch can be used by c l ie nt s o t h e r t h a n a WF.\1S

Legacy databases c o n t a i n a l l re levan t d a t a . To
use t h e pol iq' reso l u t i o n engi n e , t h e d a t abase
m us t prov i d e a s u ffi c i e n t l y ex p ressi ve query
i n terfa c e , on top of w h i c h queries issued from

tile e ngi n e can be eval uated . The o n ly add i t i o n a l
i n format i o n t h a t has to be s to red is orga n iza­
t i o n a l p o l i c i es and orga n i z a t i o n a l exp re ss io ns
The

orga n i zation

extend

the

has to choose

legacy

da tabases

or

.

whether to
to

use

the

da tabase w i t h i n t h e pol icv resol u t i o n engine.
•

t i o n s of the engi n e .

A legacy data base conta i ns some rele vant data.

For exampl e

,

.

an electro n i c m a i l system c a n be

a c l i e n t of t h e po l i cy reso l u t i o n engi n e . Since e lec­
tronic m a i l is sem to use rs r a t h e r t h a n enu merate
,

the electro n ic mail add resses o f the rec i p i e n t s hy
h a n d , orga n izati o n a l expressi ons can prov ide t h e
addresses. For e x a m p l e , a m a n ager c o u l d send an
electro n ic m a i l message to " a l l my subordi n ates

"

or

an e n g i neer c o u l d send a n electronic m a i l message
to ·' a l l m y col leagues who are engineers." The sam­
p l e op era t i o n a l express i o n shown in

Figure

11

retu rns a l l elec tr on ic m a i l add resses of aJI sub ord i­
n ates o f a given user.

l n a d d i t i o n to o rga n i zat i o n a l p o l icies a n d o rga­

Another possible c l i e n t i s a t ra nsaction procl' ss­

n i zatio n a l expressi o ns, orga n i z a t i o n a l objects

ing m o n i to r, w h i c h in corporates workflow ma n­

and rel ations h i ps m u s t be stored in e i t her the

age ment.-- Dayal er a l . refe re n c e a service ca l l ed

legacy d atabase o r t h e database of the pol icy res­

role resol u t i o n , w h i ch is an earl i e r development of

o l u t i o n engin e .

p o l icy resol u t i o n . -x

ORGANI ZATIONAL_EXPRESSION subordinates ( User :
RETURNS String:

a_user)

user . e_mail

user reports_to a_user

Figure 11

44

0Jgwzizationa/ £.\pression for Electmnic .liuil

�bl. (i No. -1

hli/ I'J'J4

Digital Technical journal

Policy Resolution in Wo rkflow Management Systems

Figure 12 shows a schematic represen tation of

pap er. Su san Thomas assisted me by i m proving my

a pol icy resolution engine with three cl ients-a

Engl ish and thus m a k i ng the paper more readable.

WFMS, a transaction processing monitor, and an

Kathy Stetson was always very helpful in coordinat­

electronic mail system.

ing the writing and revision processes.

Summary

References

The sample workflow d iscussed in this pap er, that

1.

is, the travel expense rei m bu rsement workflow,
i l l ustrates that roles are sufficient as task assign­
ment rules for only the simplest scenarios. Si nce

(Ju ly 1994).

2.

T. Krei felts a n d P Seu ffert, "Add ressing in

an Office Procedure System," Message Hand­

workflow management systems are deployed in sit­

ling Systems, State uf the Art and Future
Directions: Proceedings lf1P WG 65 Working
Conference on Message Handling Systems,

uations where complex workflows are modeled
and executed, a more general and powerful model

cal led the Pol icy Resolution Architecture (PRA) was

R. Speth, ed . (Amsterdam: North-Hol land,

developed. PRA provides the concept of an organi­

1987)

zational policy. An organ izational policy is more
general than a role in that it relates a workflow type

T. May, " Know You r Wo rk-Flow Tools," BYTE

3.

S.

W

Chang and

Chan ,

"Transformation

and Ve rification of Office Procedures," IEEE

to a n organizational expression that determi nes the
set of el igible users for the workflow. Because they

Transactions on Software Engineering, vo l.

state a l l criteria a user has to fu l fi l l and do not l im i t

SE-1 1 , no. 8 (August 1985).

the selection based o n t h e i r properties or interrela­
tionships, organ izational pol icies specify a l l el igible

4.

Office System," ACM Transactions on Of
fice
Information Systems, vol. 2, no. 3 (July 1984).

users. S ince an organ izational expression is related
to a workflow type by an organizational poli cy, task
assignment through organ izational policies is a very

5.

C . E l l is and G . Nutt, " Office I nformation Sys­
tems and Computer Science," Comjmting
Surveys, vol. 12, no. 1 (March 1980).

general approach. Organ i zational policies are eval­
u ated based on orga n i zation schema and their
populations (organization structures). Since P RA

W Croft and L . Lefkowitz, "Task Support in an

6.

C. E l l is and M . Berna l, " Officetalk-D: An

provides a way to model arbitrary complex organi­

Experimental

zation schemas, arbitrary organiza t ions can be mod­

First SIGOA Conference on Office Informa­
tion Systems (1982).

eled and subsequently popu lated. This general i ty,
i n conjunction with organizational pol icies, pro­
v ides a powerful and flexible approach to task

7

Office

Information System;·

C. E l l is, " Formal and Informal Models of
Office Activity," /nfonnation Processing 83,

assignment in workflow management.

R. Mason, eel . (Amsterdam: North-HoJland,

1983).

Ackrwwledgments
I want to thank the anonymous referees whose

8.

B . Karbe and N. Ramsperger, " Concepts and
I m plementation

remarks helped me a great deal in revising this

of Migrating Office

Pro­

cesses," Verteilte Kii.nstlicbe Jn telligenz und

WORKFLOW
MANAGEMENT
SYSTEM

TRANSACTION
PROCESSING
MONITOR

Kooperatives A rbeiten: 4. Jnternationaler
GI-Kongt-ejs Wissensbasierte Systeme, lnfor­
matik Fachberichte 291, W Brauer and

ELECTRONIC
MAIL SYSTEM

D. Hernandez, eds. ( Munich : Spri nger-Verlag,
October 1991 ).

9.

Vol. 6 No. 4

" Coordination of Distributed

i zable

Activities,"
Verteilte Kunstliche
Jntelligenz und Kooperatives Arbeiten: 4.
Jnternationaler GT-Kongrejs Wissensbasierte
Systeme, 1nformatik Fachberichte 291,

Client-server Structure
uf a Puli<-J' Resolution Engine

Digital Technical journal

Kreifelts,

Wo r k : From Office Procedures to Custom­

POLICY
RESOLUTION
ENGINE
Figure 12

T.

Fall 1994

W Brauer and D. Hernandez, eds. ( Munich:

Springer-Verlag, October 1991) .

45

Workflow Models

10.

C. Cook, "Strea m l in ing Office Proced ures­
An Analysis Using the I nformation Control
Net Model," A f"'PS Conference Proceedings of
the 1980 National Computer Conference,
Anahei m , Cal ifornia ( May 1980).

11.

I . Lacld and D Tsi chrit is, ''An Office Form F low
Model," A F!PS Conference Proceedings of the
1980 National Computer Conference, Ana­
heim, Cal ifornia ( May 1980).

12.

L

Bau m a n n and R . Coop, "Au tomated Work­
flow Control : A Key to Office Productivity,"
AF!PS Conference Proceedings of the 1980
National Computer Conference, Anahei m ,
Cal i fornia ( May 1980).

13.

M. Zisman, " Represen tation, Specification
and Automation of Office Procedu res," Ph . D.
d issertation (Philadelph ia: Un iversity of Penn­
sylvania, Wharton School, 1977)

14.

B . Curt is, M. Kel lner, and J Over, " Process
Model i ng," Commun ications of the AC!H, voL
35, no. 9 (September 1992).

15.

W Deiters and V Gruhn, "The Funsoft Net
Approach to Software Process Managemen t,"
Internationaljournal ofSojtware Engineer­
ing and Knowledge Engineering, vol . 4, no. 2

Kataya m a , "A H ierarchical and Functional
Software Process Descriptio n a n d Its Enac­
tion,'' Proceedings of the E/e"enth Interna­
tional Conference on Sojhuare Engineering
( May 1989).

21.

P M i and W Scacch i , Operational Seman tics
of Process Enactrnent and Its Prototype
Implementations ( Los Angeles: U n iversity
of Southern Ca l i fornia, Com puter Science
Department, April 1991).

22.

P

Mi and W Scacchi, Modeling A rticulation
Work in Software Engineering Processes ( Los
Angeles: U niversity of Southern Ca l i fornia,
Computer Science Department, Apri l 1991 )

23.

P

Mi and W Scacch i , "A K nowledge-Based
Env i ronmen t for Mode l i ng a n d Simu lating
Software Engi neering Processes," 1/:.I::t:: Trans­
actions 011 Knowledge and Oatu Engineer­
ing, voL 2, no. 3 (Se ptember 1990).

24.

L. Osterwe i l , "Software Processes Are Soft­
ware Too," Proceedings of the Nin th lnternct­
tional Conference on Softll'are Engineering
(March/April 1987).

25.

L Wil l i ams, "Software Process Model ing:
A Behav ioral Approach," Proceedings of the
Tenth International Conference on Software
Engineering (1988).

26.

W Royce. " Ma naging the Deve lopment of

( 1994)
16.

W Deiters, V Gru hn, and H. Weber, ''Software

Process Evo l u ti o n i n M ELMAC," The Impact of
Technology on Software Processes
Series on Software Engineering and Knowl­
edge Engineering, voL 3, D. Cooke, ed . (Singa­
pore: World Scientific Publ ishing, 1994) .
CA SE

17.

18.

D. Harel et a l . , " STATE!YIAT E : A Working E nvi­
ronment for the Development of Complex
Reactive Systems," Proceedings of the Tenth
International Conference on Sojtware Engi­
neering (1988).

19.

46

Large Software Systems," Proceedings of the
Ninth in ternational Con/erence on Software
Engineering ( March/Apri l l987 ).
27.

B. Boehm, "A Spiral Model of Software Devel­
opment and Enhancement ," A<:i11 Sojtware
Engineering Noles, voL 11, no. 4 (August 1 986) .

28.

C. Hegarty and L. Rowe, " Con t ro l Loops ami
Dynamic Run M o difications Using t he Berke­
ley Process-Flow Language ," Proceedings of
the Third International Conference on Data
and Knowledge Systems jiJr klanufacturing
and Engineering, Lyons, France ( 1992).

29.

S. Jablonski, " Data F l ow Management in D is­
t ributed OM Systems;· Proceedings of the
Third International Conference (111 Datcl
and KnouAedge Systerns for Jlthmufacturing
and Engineering, Lyons, France ( 1992).

W H u mphrey and M. Kel l ner, "Software Pro­

cess Model ing: Princi ples of E n tity Process
Models," Proceedings of the Eleven th Inter­
national Conference on Software Engineer­
ing ( May 1989).
M. Jaccheri and R. Conrad i , "Tech n i ques for
Process Model Evolution in EPOS," fEEt. Trans­
actions on Software Engineering ( December
1993)

T

20.

Vol. 6 No. 4

Fall 1994

D igital TecbnicalJournal

Policy Resolution in Workfl(YW Management Systems

30.

Proceedings of the Third International Con­
ference on Data and Knowledge Systems for
Manufacturing and Engineering, Lyo ns,

41 .

T. Malone, K . Crowston, J. Lee, and B. Pentland,

"Tools for Inventing Organizations: Toward a
Handbook of Organizational Processes," CCS
WP # 14 1 , Sloan School WP #3562-93 (Cam­

France (1992).

bridge: M assachusetts Institute of Technology,

31 .

H . Yoshikawa and ). Goossenaerts, eds. , Infor­

mation Infrastructure Systems for Manufac­
tu ring (Amsterdam: North-Hol land, 1993).
32.

42.

Database

Recovery,"

ACM ComjJuting Surveys, vol.

15, no. 4

H i lton Head, South Carolina (June 1992).

Harder and

A.

Reuter,

" Pr inciples

of

(December 1983).

43.

"Specifying and Enforcing Intertask Depen­

Proceedings of the Nineteenth
International Conference on Very Large
Databases (VLDB), Dubl i n , Ireland (1993).
Y.

Bre i tbart,

G.

Wei k u m ,

and

A.

Deaco n ,

H.

Schek,

Singapore ( November 1994)

44.

Data-centric Approaches

and

ings of the First International Conference on
En tetprise In tegration Modeling Technology

to Support

Multi-system

(ICEIMT), H ilton Head , South Carol ina Qune

Work­

1992).

flows," S!Gtl'IOD Record, vo l. 22, no. 3 (Sep­
tember 1993).

35.

45.

U. Daya l , M. Hsu, and R. Laclin, "A Transac­
tional Model for Long-Runn ing Activities,"

Proceedings of the Seventeenth Interna­
tional Conference on Very Large Databases

H . Garcia-Molina and K . Sale m , ·'Sagas," Pro­
ceedings of the 1993 ACM SIGL'viOD Interna­
tional Conference on Management of Data

46.

38.

47.

mali zing the Framework for Information Sys­

31 , no. 3 (1992).

Bulletin of the Technical Committee on Data
Engineering, vol. 16, no. 2 (June 1993).

48.

F Vernadat, "Business Process and Enterprise

Activity Model l i ng: CIMOSA Contribution to
a General Enterprise Reference Architecture

S. Jablonski, "Transaction Support for Activity

ancl Methodology (GERAM) ," Proceedings
of the International Conference on A u toma­
tion, Robotics and Computer Vision (JCARCV

on High Perforrnance Transaction Processing
Systems (HPTS), Asilomar, California (1993).
H . W�ichter and A. Reuter, "The ConTract

'94), Singapore (November 1994).
49.

Mode l ," in Transaction Models for Advanced

T.

Williams, "Architectures fo r Integrating

Manufacturing Activities

Database Applications, A. Elmagarmid, ed.

40.

) . Sowa and ]. Zachm a n , " Extending and For­
tems Architectu re," IBM Systems journal, vol.

Management," Proceedings of the Workshop

39.

R. Katz, " Bu s iness/en terprise Model ing," IBM

Systemsjournal, vol. 29, no. 4 (1990).

(1987).
37.

Proceedings of the First International Con­
ference on Enterprise Integra tion Modeling
Technology (ICElt'vlT), Hilton Head, South Car­
olina ( June 1992).

(VLDB), Barce lona, Spain (September 1991 ) .
36.

M. Fox , "The TOVE Project: Towards a Com­
mon-Sense Model of the Enterprise," Proceed­

" Mergi ng Appl ication-centric

Transaction-o riented

C. BuGler, " Enterprise Process Modeling and
Enactment in GERAM," Proceedings of the
International Conference on A u tomation,
Robotics and Computer Vision (ICARCV '94),

P At tie, M. Singh, A. Shet, and M. Rusinkiewicz,
dencies,''

34.

R. Burkhart, " Process-based Defin ition of
Enterprise Models," Proceedings of the First
International Conference on Enterprise Inte­
gration 1\llodeling Technology (ICEIMT),

T.

Tra nsaction-oriented

33.

Center for Coordination Science, May 1993).

and

Enterprises,"

(San Mateo, Cal ifornia: Morgan Kaufma nn,

Information Infrastructure Systems for Man­
ufacturing, H . Yoshikawa and J. Goossenaerts,

1992).

ells. (Amsterdam: North-Holland, 1993).

T. Malone and K. Crowston, "The I n terd isci­

pl inary Study of Coord ination," ACM Comput­

ing Surveys, vol. 26, no. 1 ( March 1994).

Digital Tecb11.ical journal

Vol. 6 No. 4

Fall 1994

50.

F Flores and T. Winograd ,

Understanding
Computers and Cognition ( Reading, .MA:

Addison-Wesley, 1987).

47

Workflow Models

51.

R . Medi na-Mores, R . Wi nograd , T. Flores, and
F Flores, "The Action Workflow Approach to
Workflow Management Tech nology," Proceed­

6 3.

S. Sari n , K. Abbot, and D. McCarthy, "A Process
Model and System for Supporting Col labora­
t ive Wo rk," Proceedings of the AOH SIGWS
Co nfe re n ce on Organ iza tional C01npu ting
Systems ( November 1991 ) .

64.

M. Shan, " Pegasus Architecture and Design
Princip les," Proceedings of the 1993 ACM SJG­

ings of the AC!l-'1 i992 Conference on Com­

(C'\CW),
Toronto, Ontario, Canada ( November 1992) .

p u ter Supported Cooperatil'e Wo rk

52.

53

T.

Danielsen and U. Pankoke-Babatz, "T'he
Amigo Acti v ity Model," i n Research in to Net'
works and Distribu ted Applications, R. Speth,
ed. ( M u nich: North-Hol land, E lsevier Science
Publ ishers B.V , 1988).

MOD interna tional Conference on lVian age­

65.

R . Fehl ing, K. Joerger, and D. Sagalowicz,
Knowledge Systems for Process Mmwgeme n t

( Palo Alto, C A : Teknowledge I n c . , 1 986) .
54.

C.

BuSier and S. Jablons ki, "An Approach to
In tegrate Workflow Model ing and Organ iza­
t i o n Model ing in an Enterprise," Proceedings

( WLT JCT;), Mor­
gantown, West Virginia (Apr i l 1 994).
Collaborative En teJ1Jrises

66.

67

wijkerhout, Netherlands (September 1994}
57.

M. Hsu, A. Ghoneimy, and C. Kleissner, "An
Execu tion Model for an Activity M anagement
System," Proceedings of the Wo rk�shojJ on High
Perfornumce Transaction s:vstems ( 1 9 9 1 ) .

59.

60.

Business

Opportunity

(Ovum

The

69.

C. Bu gler ami S. Jablonski, " I m ple m entin g
Agent Coord i na t ion for Workflow lvianage­
ment Systems Using Active Database System s,"
Proceedings of the Fou rth in tenz ationol
·worl<.s/.JojJ on Research Issues in Da ta Engi­

neering: Actit•e Database S)'stems (RIDE-ADS

'94), Housto n , Texas ( February 1994).
70.

Reports,

December 1991 ) .
(Jl .

62.

T. W h i te and L. F ischer, " New 7()()/s for New
Times: The Workflow Paradigm (Alameda:
Future Strategies I nc . , Book Div i s i o n , 1994 ) .

71 .

C. EJ J is, S. G ibbs, and G. Rei n , " G roupware­
Some Issues and Experiences," Com m u n ica­
tions of the ACM, vo l. :'l4, n o . 1 (January 199 1 )
L. Lawrence, " The Role of Roles,'' Cmnpu ters
vol . 12, no. l ( 1993).

and Securit_g

72.

L. Aiel lo, D. Nard i . and v
i i . Panti, "Modeling

J Ba i r. " Con trasting Workflow Models: Get­

the Office Structure: A First Step towards the

t i ng to the Roots of Three Vendors," Proceed­
i ngs of the Group ware '93 Co nfe re nce San
_lose, Cal ifornia ( 1993).

Cm�terence 0 1 1

,

48

and

R. Mars h a k , " Characteristics of a Wor kflow
Syste m - M i nd You r P's a n d R 's," Proceedings
of the Groupware '93 Conference, San Jose ,
Ca l i fornia ( 1 99 3) .

Leymann and W AJ tenhuber. " Managi ng Busi­
ness Processes as an Int()rrnation Resource,"
IBM .�ystetnsjournal, vo l. 33. no. 2 ( 1994 ).
Soflwa re:

Robotics

(ICA RCV '94), Singapore

68.

F

Mmwgem e n t

A u to m ation,

on

( November 1 994)

M . Hsu and .M . Howard . " Work-Flow and
Legacy Systems," B YTE (Ju l y 1994).

Wo rkflow

D. Sng, "A National Information InJrastructure
for the 2 1 st Cen t ur y Col laborative En ter­
prise." Proceedings of the Intern ational Con­
Comp u ter Vision

.

58

D. Evans, " Pu t t i ng E lves to ·work: Workflow
Technology in a Law Firm," Proceedings of
the Groupware 93 Conferen ce, San Jose,
Cal ifornia ( 199:3)

ference

Fou rth Wo rking Conference on Dynmnic

Noord­

British

'

S. Jablonsk i , " ;\•I OBI LE: A Mod u lar Workflow
Model a nd Archi tecture," Proceedings of the
Jl!iodelling and Information .�)'stems,

Very Lmge

Vancouver,

Col umbia, Canada ( 1992).

011

Enabling Techn ologies: infrastru cture fo r

( VI.IJR).

Databases

J Guyot, "A Process Model t()r Data Bases," SJ G­

of the Third IEEE international Workshop

56.

M . Ansa r i . L. Ness, M. Rusinkiewicz, and
A. Sheth , " Using Flexible Transactions to Sup­
p ort M u l t i-System Te lecom m u n i cation Appl i­
cations," Proceedings of the Eigh tee n th
Intern a t ional Conference on

MOD Record, val. 17, no. 4 ( December 19R8) .

55.

Was hi ngton , D.C. ( May 1993)

Jne n t of Data.

Office Expert System," Second AC\1 S!GOA

Ojjice information .S) •stem s

(AC.II S/C,OA). vol . 5, n os. 1 and 2 ( l9R4)

ViJ/. (J No. ·I

hill !')')

1

Digital Technical journal

Policy Resolution in Workflow Management Systems

D.

73.

Den n i ng, Cryptography and Data Security
( Reading, MA: Add ison-Wesley, 1983).

74.

Blue Book, Volume Vl!I, Fascicle VJIJ. 8, Data
Communication Networks: Directory, Rec­
ommendations X. 500-X.521 (Study Group
VII), Comite Consu l ta t i f l nterna tiona le de
Tell·graphique et Te�lephonique.

7).

7(J.

S. Ceri and .J. Wido m , '' Managing Semant ic
Heterogeneity with Production Ru les ami Per­
sistent Queues." Proceedings of the Nine­
tee 1 l tb Conference on Very Lorge Databases
( VUJN), Dublin, Ireland ( 1993).
W Kent, "Solving Domain Mismatch a nd
Schem a M ismatch Problems with a n Object-

Digital Technical jou rnal

Vul. (j No. 4

hill 1')<)4

Oriented Database Program m i ng Language ,"
Proceedings of the Seventeenth In terna­
tional Conference on Very Large Databases
(VLDB), Barcelo na , Spain (September 1991 ).
77.

U. Day a l et a l . , "Third Generation TP Moni­
tors: A Database Chal lenge," Proceedings of
tb e 1993 ACM S/G/'vJOD International Confer­
ence on Nlanagernen t of Data, Was hington,
D.C. ( May 1993).

78.

C . BuBier, "Capab i l i t y Based Model i ng,"
Proceedings of the First International Con­
ference on En te11Jrise Integration Modeling
Technology (JCEIMT), H i lton Head, Sou t h
Carol i n a ( J u ne 1992).

49

Stewart V. Hoover
Gary L. Kratkiewicz

The Design ofDECmodel
for Windows
The DECmodel for Windou•s softlmre tool represents a significant admnce in the
development of business process models. Tbe DECmodel tool allows rapid devel­
opment of models and graphical representations of business processes by prot•id­
ing a laborator)' enl 'ironment for testing processes before propaga ting t!Jem into
workflows. Such an appmach can significantly reduce tbe risk associated u·itb
large inuestments in inform a tion technology The DECIJ lodel dest�f{ll i11corporates
knowledge-based, simulation, and graphical user intetjace technology on a PCplat­
form based on the L'vficrosoft Windml's operating �Tstem. Unique to the design is the
manner in whicb it separates the model of the business processesFum tbe uiews or
presentations of the model.

M a n y approaches have been developed for u n d er­

base compo n e n t aml t he p rese n t a t i o n componen t

stan d i ng, specifying, testing, and val i d a t i ng busi­

as s e p arate processes. A pri m i t ive m a i l box system

ness processes. In t h e l a t e 1980s, D i g i t a l began ro

was used fo r i n t e r p rocess com m u n i catio n . To serve

reengineer some of its most comp lex and m i ssion­

the needs of n o n tech n ical b u s i n ess users and to

critical b u s i ness processes. I t soon became a p p a r­

achie ve t he necessary pro d u c t qu a l i t y, Sym mod

e n t t h a t mod e l i n g methodologies and too l s were

needed to be com pletely redesigned a n d rebu i l t .

needed t o docu m e n t , test, ami va I idate t h e reengi­

I n early

1 9 9 1 . the Model i ng and Visu a l ization

n eered processes before they were i m p l e m e n ted ,

Group decided to bu i l d a pro d u c t versi o n of the

as wel l as to prov ide a hi gh-level specifi cation fo r

Sym mod applicati o n , w h i c h wo u l d be released as

their design and i m p lementa t i o n . Consequently,

the DECmoclel too l . The team d rafted requ iremen ts,

Digi tal decided to provide the b u s i n es s process

specific a t i o n s , a mi an architecture. The DECm odel

engi neer w i t h tools similar to those used by archi­

produ c t was i n i t ia l l y t a rgeted a t two p l a t fo r m s :

tects, mechanical designers, and c o m p u te r a n d soft­

VAXstat ion

ware e n g i n eers.

DECwindows operating system and perso n a l com­

The first i m p l e m e n t a t i o n o f D i g i t a l \ d r n a m i c

works t a t i o n s

r u nn i n g

u n der

t he

p u ters (PCs) r u n ni n g u n der the Windows NT oper­

b u s i n ess m o d e l i n g techn o l ogy, Sym b o l i c Mode l i n g ,

ating

was developed a t Digita l 's A r t i f i c i a l I n tel l igence

req u i r e m e n t s were accu m u l.a ted . i t became clear.

sys t e m .

As

u s e rs

were

i nt e r v iewed

and

Tec hno logy Cen ter. The techn ology was emb od ied

however. that by far the m o s t i m portan t p l a t form

i n an a p p l i c a t i o n cal led Sym m o d . wh ich in 1991 ran

for DEC m o u e l users was the PC pl a t form based

o n l y on a VA Xstation syste m . 1 Sym m ()(J's k nowledge

on the Wi n dows opera t i ng syste m . Consequent ly,

base and
using

the

s i m u l a t i o n engine were i m p lemen ted

LISP progra m m ing l a nguage and t h e

the D ECmodel deve l o p m e n t eftort shifted to this
p l a t form .

K n owledge Craft prod u c t , a fra me-based k nowl­

D u r i ng 1 9 9 1 , the team en hance(! the exi s t i ng ver­

edge represe n t ation package with model i n g a nd

s i o n of Sym m o d so t h a t i t wo u l d meet user needs

s i m u l a t i o n fe ature s . l Because models were written

u n t i l the release of the pro(l uct vers i o n for l'Cs. The

in LISP code, users had to be c o m p u t e r program­

most s ign ifica n t e n h a n c e m e n t was the develop­

mers as we l l as b u s i ness c o ns u l t a n ts . The appl i ca­

ment of an X W i nd ow System in terface for building

t i o n contai ned a graphical pres e n t a t i o n bui lder a n d

and e d i t i ng m o d e l s . A second important en han ce­

\'iewer im p l e m e n ted i n t h e C progra m m i ng l a n ­

men t was a gra p h i ca l she l l program t h a t tra ns­

up

guage t h a t u s ed a relat ional database fo r p res e n t a­

parent ly

t i o n storage . The user h a d to start the k n o wledge

presen t a t i o n components to r the user.

')()

started

Vol. o No. 1

t he

h1ll 1')')4

k n owledge

base

and

Digital Tecbnical journal

The Design of DECmodelfor Windows

In March 1992, Digital officially announced Phase

Designers believed that while simulating the

0 (the strategy and requirements determination

business, the user should be able to interact with

phase) of the DECmodel for Windows product.

the model and thereby select and test more than
one scenario. The DECmodel tool was intended to

Design and Development Goals
The DECmodel product design team had the fol low­
ing goa ls:
•

•

Provide a model ing tool that maps d irectly to

put as a fu nction of resource constraints nor pro­
vides i nfor mation through statistical reports. The
DECmodel product was designed to provide a slow,

Allow the model ing of both the static and the

del iberate simulation of the business, not to com­

dynamic characteristics of the business process

press weeks or years of activities into a few sec­

Allow m u l t iple views of the busi ness process
model by separating the model from the presen­
tation of the business process during simulation

•

work as different choices were made. The tool, by
design, neither predicts congestion and through­

business processes
•

be a working scale model of the business, giving the
user a sense of how the business process wou ld

Allow the user to i nteract with the tool and to

onds, leaving behind only a statistical sum mary.
The team 's development goals for the DECmodel
product were to
•

pl atform used by business consultants

make decisions while the business process is
being simu lated in order to let the user " test­

•

drive" the business process
•

Provide a tool that runs on a popular hardware

Achieve a short t ime-to-market, i . e . , delivery
within one year

Provide a tool that is easy to use for business con­
sultants and that requires no programm ing

•

Util ize a widely accepted software base technol­
ogy (for maintainabil ity)

Note that the designers intentionally omitted the
fol lowing goals from the DECmodel design:
•

Include resource constraints and queuing

•

Al low the user to perform a statistical analysis
of the behavior of the business process
By far the most important goal for the DECmodel

The DECmodel World Vlew
Every m odel ing and simulation tool is based on
a predefined view of the world 5 In the DECmodel
world view, a business process is composed of
aggregate centers capable of perform ing one or
more tasks or work steps. Each aggregation is

design was the first one l isted, an obvious mapping

referred to as a process, and the tasks that can occur

between elements of the model and busi ness p ro­

in a process are called activities. Processes commu­

cesses. The antici pated users of the DECmodel tool

nicate through the exchange of messages, which

were business analysts and consultants, not system

are sent by activities and received by another pro­

designers and software engineers. The designers

cess or other processes or by the same process that

felt that add ing levels of abstractions to a modeli ng

contains the activity.4

tool would make i t less acceptable to the intended

This view differs significantly from the one taken

users. A notable coro l l ary to providing an obvious

by the typical workflow model in which work steps

mapping was modeling both the static and the

are directly l inked. In the DECmodel model, an

dynamic characteristics of the business process.

activity that sends a message to a process has no

To engage the user in interacting with the model

knowledge of what work steps w i l l occur next. For

and test-driving the busi ness process required

example, when a customer (a process) sencls an

a graphical interface that was separate from the

order (a message) to a supplier (another process),

model. This " p resentation" layer of the DECmodel

the customer does not know what work steps

tool provides a layout and graphical appearance

(activities)

that has the look and feel of the actual business pro­

receives the order. It is invisibl e to the customer

the suppl ier will

initiate

when

it

cess, hiding the irrelevant technical details of the

whether or not the supplier decides to change its

model. The presentation enables the user to step

work ru les, for instance, by sendi ng the order to a

through the business, watching information and

second source because material s are not available.

material flows occur, and thus see where the

Simi larly, when the suppl ier's activities have been

dependencies and concurrencies exist.

completed and the material that was ordered has

Digital Technict,l]ournal

Vol.

6 No. 4

Fall 1994

51

Workflow Models

been sent to the customer, the suppl ier has neither
knowledge of nor dependencies on t he work steps
that t he customer u n dertakes next. In cont rast, i n
a workflow model each task i s d irectly l in ked to
another task. Changes in the sup pi ier's way of clo i ng
business force changes i n how the customer's tasks
connect to the supp l ier's tasks. More succinctly, the
DECmodel tool e ncapsulates the behaviors and
work ru les of each i nd iv i d u a l process in t he larger
business process. This d i fference between the pro­
cess a nd workflow models is shown in Figu re 1 .

Processes, Activities, and Messages
As described above, the DECmodel model repre­
sents a business p rocess as a col lection of smal ler
encapsul a ted processes. The behavior of each pro­
cess is defined by the activities that it contains. The
DECmodel tool provides three general types of
activities: generating activi ties, processing activi­
t ies, and terminating activit ies. Genera t i ng and ter­
m i na t i ng activit ies represent the boundaries of the
model; processi ng activi ties represent the work
steps i n t he business process.
An activ i t y is characterized by ( 1 ) a receive r u l e ,
w h i c h defines the messages t h a t t he act ivity neecls
for i n i t iation, ( 2) a duration, and (3) a send rule,
wh ich d efines the messages that the activity semis
out at the end of its duration. Generating activ i t ies
have o n l y send ru les, and term i n a t i ng activ i t i es
have o n ly receive ru les.
PROCESS

PROCESS A

(a )

( b)

Figure I

Process Jl!Jodel

Workjlou • ii!Jodel

Tbe Process ;Hodel uersus

8

Activities can send messages to processes on l y.
The receiving process m akes the message known to
every activity that uses t he message in i ts receive
rule. Messages are u niversal to the model, and the
same message type can be sent by activities in d i t�
feren t p rocesses.
Processes can have state knowledge (attribu tes)
that can be assigned values as a side effect of an
activity being completed . 'The activity can use
a process attribute value to decide what messages
to send o u t ancl where to send them. 'That is, pro­
cesses have a state that can be a ltered to change the
behav i or of the model.
Like processes, messages can con t a i n i n for­
mation, which is stored i n their attribu tes. When
a process receives a message and passes i t on to
an activit y, i n formation in the message can be used
in both the receive r u le a n d the send ru le of the
activity. Acl d i t i o n a l ly, t he i n formation i n a received
message can be copied i n to the attributes of
any message that an activity sends. In this way, the
DECmodel tool supports i n formation propagation.
The DECmoclel representation of busi ness bor­
rows heavi l y from both the stochastic-timed Petri
net (STPN) model and the object parad igm fou nd in
object -oriented design. ' 1'
TIJe Stochastic- timed Petri Net Model uersus the

An STPN model represents a
system as a col lection of pl aces, transitions, arcs.
and tokens. Places con t a i n tokens and act as inputs
to tran s it io ns. A t ransition results in t he movement
of a token to another p lace i f an arc exists between
t he t ransition ancl the p lace. Before a t ransition can
occur, a token must be present at each place that is
connected to t he t ra nsition by an arc. Associated
with each transi t ion is an exponenti a l l y d istributed
random variable that expresses the d e l ay between
the enab l i ng of the t ra nsi t i o n and the firing of the
transition.
The DECmodel model welds the STPN place, t ra n­
sition, a n cl arc elements i n to a s i ngle object ca l led
a n activity. The analogous elements of the ST'PN and
DECmodel models are
DECrnodel ;lJodel

STPN

DECmodel

Pl ace
Transition
Token
Arc

Activity receive r u le
Activity d u ra t i o n
Message
Activity send rule
Process

the Workj?ou• Model

52

Vii/.

6

;\(). cj

Fall

I 'J' ) 1

Digital 1ecbuical journal

The Des(f.!.11 ofDECmodelfor Windows

5. Not restricting durations to being exponentially

The DEC:model mode.l goes beyond the STPN

disrribllted random variables.

model by

Like an STPN mode l , a DECmodel model does not

l. Adding the process object between the activity

send rules (arcs) and the activity receive ru les

expl icitly have resources but can represent the

(pl aces). Each process can have mu ltiple activ ity

avai labi l i ty of a resource by sending a message to

send ru les. As the process object receives mes­

process when the resource is available.
Figure 2 s hows the workflow system from

sages (tokens), it dispatches them to the appro­

Figure 1 as both an STPN model and a DECmodel

priate activity receive rule (place).

model with the process receiving messages from

2. Al lowing more than one type of message (token)

the activit ies.

to exist.

The DECmodel !Vlodel and Object-orie n ted Design

:;. Storing information in bo th the processes and

The elements of object- o r iented design that the

the messages (tokens).

DECmodel model fu l l y draws upon are encapsu la­
tion of information and the message-method para­

4. Using AND, OR, and message-m atching receive

d igm . Information is encapsu l ated within DECmodel

ru les in the activity receive ru les (places).

ACTIVITY

1

ACTIVITY

2

ACTIVITY 3 ACTIVITY

4

V-UVl

KEY:

'

J ARC

0 PLACE

TRANSITION

•

TOKEN

(a) Stochastic-timed Petri Net Model of a Four-acti uiz) Workflow
'

KEY:

JACTIVITY SEND RULE

c==::> PROCESS

0 ACTIVITY

ACTIVITY RECEIVE RULE

•

MESSAGE

(b) A DECmodel Model of a Four-activiZJ' Workflow w ith a Process
Dispatching Messages between A ctivities

Fip,ure 2

The Stocbastic-tirned Petri Net Nlode/ versus the DECm ode/ Process-activity J\1/odel

Digital Technical journal

a

Vol. ()

No.

Fa(( J'J94

Workflow Models

objects and is not avai lable g loba l l y. However, an
i mportant d ifference exists between DECmodel sys­
tems and object-orien ted systems. Tn DEC:moclel
systems, a number of messages may by requ ired to
trigger a behavior; whereas, in classical object­
oriented systems, each m essage triggers a method.
The DECmodel tool supports polymorp h is m , in
that the same message can be sent to d i fferent pro­
cesses, which can res u l t in different behaviors.
Developers investigated goi ng beyond standard
polymorphism by using one message to trigger d i f­
ferent activ i t ies within the same process. The
approach considered was to use process " fi l ters" to
examine the information in a message and then
decide which activity or activities in the process
should receive i t. This feature was not completely
developed because of time constra ints a nd a less­
than-clear mapping between t he concept and the
actua l practices i n most business. Further, using
activity send ru les that util i ze the i nt<>rmation con­
tai ned i n messages can provide a similar capabil i ty.
The DECmodel tool does not su pport inheri­
tance, but the u nderlying techno logy of the prod­
uct does support this feature. As in the case of
nonstandard polymorph ism , time-to-m arket pres­
sures and the lack of clear evidence that the feature
woul d be used i n business processes drove the
decision not to i nclude i nheritance support. Also,
the DECmodel prod uct does not cu rrently support
class types beyond the bui l t - i n classes of the rro­
cess and the three activity types.

Process Hierarchies
Tb

address the goa l of havi ng a strong mapping
between the model ami rea l business processes, t he
DEC:model model supports processes within pro­
cesses. Processes can receive messages in two ways:
h ierarchical rou ting ami peer-to-reer rout ing.
I n a business process, a message sent to a h igh­
level process should travel through the process h ier­
archy to the activity that is to act upon the message.
For example, an activity in the sales process should
be able to send a message to the manufacturing pro­
cess and not be concerned that m a n u facturing con­
tains several subprocesses. The knowledge of how
to relay a message shou ld be in the receiving pro­
cess, not the send i ng process.
In business, however, much com munication
occurs o n a peer-to-peer basis, with information
seldom routed up and down the orga n i zation hier­
arc hy. For exa mple, the results of a m arketing
research activity go directly to the manufacturing

'5 4

planni ng fu nction without traveling down through
the various levels of the manufacturing orga niza­
tion. In a DECmodel model, as in most businesses,
when an activity is completed, a message can be
sent directly to any process in the business.
The DECmodel design feature that a llows pro­
cesses to receive messages ami then pass them on to
subprocesses and activ ities can resu l t in m u ltiple
message receipts h>r a single send operation. That
is, one activity can send a single message that is
received by every activity in the model that includes
the message in its receive ru le. Model ing experts d is­
agree about bow well this phenomenon maps to
rea l business processes. The DECmodel user can
avoid this effect, if desired, by using uniquely named
messages in the send ru les of activities.

The Presentation
The first DECmoclel design goa l was supported by the
modeling parad igm of processes, activities, and mes­
sages. The presentation aspect of the DECmode l tool
supports the goa ls of a strong separation between
the model and the graphical representation of the
busi ness process and the need to support user inter­
action ami decisions during moclel simu lation.
The presentation of the model is based on v iews
that contain networked nodes. Each node in a view
can represent zero or more processes i n the model ;
however, no process can be represented by more
than one node in a si ngle view. This mapping
between the processes i n the model and the nodes
i n a v iew a l l ows the user to develop a ncl a n i mate
m u l tiple v iews of the model simu l taneously. For
example, one view m ay show the model at its low­
est level of deta i l , with each process in the model
m apped to a si ngle node. Another view m ay show
a h igher level of ma pping, with m u l tiple processes
m apped to the same node. A third view may map
processes based on attri bu tes such as geographic
location, the organizational chart, or technology.
T he construction of the v iews is left to the creativ­
ity of the analyst b u i ld ing the model.
D uring model s i m u l ation, the DECmoclel tool
uses a n imation to show the movement of messages
from one process to another. The user can also
v iew the messages and their attribu tes.
To accom modate user interaction, the D ECmodel
tool provides a menu send ru le in the defi n ition of
an activity. If an activ ity uses the menu sencl rule,
just before t he activ ity fires, a menu appears t hat
a l lows the user to make a choice that determ ines
what messages are to be sent by the activity and
Vol. 6 No. 'l

Fall

I') 'Yi

Digital Tecbnical jou rnal

The Design ojDECmodelfor Windows

which processes are to receive them. The user is

builder. The user inte rface is designed as a set of

unaware of the actual send rule; the choice m ade

classes specialized from the Microsoft Foundation

forces one of a set of send ru les to be selected. The

Classes.

use

ach ieved with an internal application progra m m ing

of menus,

a n i mation

of messages

moving

between processes, and user-control led stepping
through the simula tion gives the user the feeling of

Interaction

between the two layers is

interface (API).

This arch itecture was chosen for both technical

and pragmatic organizational reasons. The parti­

test-driving the business process.

tion ing i n to two layers al lowed the i n ternal engine
t o be b u i l t using sta te-of- the-art k n owledge repre­

Architecture and Development Process
The overal l DECmodel architecture, shown in Figure

3, contains two layers. The inner l ayer of the archi tec­
ture is the internal engine, which provides the means
for repres enting, storing, and executing (simulating)
models. The internal engine is designed using ROCK,
a frame-based , object-oriented knowledge repre­
sentation system, and AMP, a model ing and sim ula­
tion frame-class l ibrary implemented in ROCK 7 The
outer layer of the architecture is the user inte rface ,
w h i c h provides t h e means fo r a l l user interaction
with the DECmodel model and has two major com­
ponents: the m odel builder and the presentation

sentation tech nology and the user in terface to be
built using sta te-of-the- art graph ical user i n terface
technology. The d isadvantages in this separa t i o n
were t h e necessity of design ing an internal API a n d
the n e e d to dupl icate s o m e data (nomina l l y stored
in the knowledge base) in the user interface.
The partition i ng m apped well to the human
resources avail able in the DECmodeJ tea m . The
DECmodeJ engineers had strong skills i n developing

LISP, knowledge-based, and X Window System appli­
cations but l i t t le experience in developi ng C++,
ROCK, or Microsoft Windows applications. With the
arch itectural separati o n , one team was able to
focus o n the i nternal engine using C++ a nd ROCK

r

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

,

a n d , t herefore, did not h ave to learn m u ch about
Windows program m ing. The other team was able to

MODEL
BUILDER

I

focus on the user i nterface using C++ and Windows

PRESENTATION
BUILDER

progra m m ing tools and did not have to learn any­
th ing about ROCK. The engineering team fe lt that

��"''

INTERFACE CLASSES

G E N E R I C USER

I

M I C ROSOFT

the efficient use of human resources in the develop­
ment process overcame the technical disadvan­

FOUNDATION CLASSES

tages of the approach .
USER

INTERFACE

DECmodel development proceeded w i t h the two
tea ms. Since the bu l k of their devel opment work

SCRIPT E N G I N E

(A�

was completed first, the members of the knowl­
edge base team also worked on the user in terface
team toward the end of the development process.

SI MULATION
ENG I N E

KNOWLEDGE BASE

Design and Implementation
ANALYSIS

I

This
AMP

l

ROCK

r

-

-

-

-

-

-

I
l

_

the

design of the

two

interface.

1- - - - - - - - - - -

-

-

-

-

-

-

-

-

I

REPORT
FI LES

Internal Engine

-

-

-

-

-

-

-

-

-

_

_

_

_

Figure 3

_

_

The internal engine represents models of dynamic
business processes in a knowledge base and exe­

-

cutes these models using di screte event simulation.

DECMODEL
MODELING LANGUAGE
FI LES

This layer provides a set of services for i n teracting

PERSISTENT STORAGE
_

describes

I NTERNAL E N G I N E
D E C M O D E L APPLI CATION

-

secti o n

DECmodel layers: the i nternal engine and the user

_

_

_

_

_

_

_

_

_

_

_

l

with

the

knowledge bas e .

These

services

are

accessed through the DECm odel t o o l 's i nternal API .
The i n ternal engine contains t he DECm o del knowl­
edge bas e , simu lation engine, and means of persis­

DECmodel Architecture

Digital Tecbnicaljournal

Vol. 6 No. 4

Fal/ 1994

tent storage. Using the DECmodel methodology to

55

Workflow Models

represent and execute busi ness p rocess models,
the i nternal engine
•

Represents the structure, attributes, and behavior
descriptions of the busi ness p rocesses in a knowl­
edge base. (This representation is the model.)

•

Represents the structure, attri b u tes, and behav­
i o r descriptions of the a n i mated visu a l i zation
of t he model in a knowledge base . (This repre­
sentation is the p resentation.)

•

Represents the connections between the model
and the p resentation i n a knowledge base.
(This represen tation is the model- presentation
mapping.)

•

Represents the dynamic behav ior of the busi ness
p rocesses by al lowing fo r d iscrete event simu la­
tion of the knowledge base .

The DECmodel knowledge base
cont a ins the frame-based , object-oriented rep­
resentation of t he model, the presentation, and
the connections between them . It also m a i n­
t a i ns the model relat ions, attribu tes, and methods.
The knowledge base contains both cl asses and
instances. The classes specify DECmodel objects;
sets of i nstances make up specific models and pre­
sentations. In addition to con t a i n i ng a l l the i n for­
mation abou t model and presen tation behavior and
structu re, the k nowledge base contains all t he
graphical information usecl by t he model bu i l der
ami the presentation b u i lder. This i ntr frame classes.
Both frame classes and frame i nstances are objects.
ancl both can be dynamically created, operated o n .
and deleted d u r i n g run time. With respect to the
C++ language, al l frames appear to have the same
data type. Slots are objects, whose behav ior is
defined independent of the frames.
Portions of the k n owledge base are b u i l t using
AMP, a model i ng and simulation frame-class l ibrary
imple mented in HOC K . A!YJ I' contains objects for
representing process models that contain ent ity
flow, for constructing ami r u n n ing (I iscrete-even t
s i m u lations, and for gen e rating, col lect i ng, and
red ucing statistical data.
The DECmodel frame classes are subclasses of
ROCK and AMP classes ami conta i n re lat ions,
a t tr i b u tes, and methods that describe the content
and behavior of DECmodel objects. Some DECmollel
frame classes are abstract classes used o n l y as
a basis for m o re specific su bclasses; others are used
for instantiation of D ECmodel objects. The
DECmodel tool contains three types of h·ame
classes: model objects. presentation objects. and
project objects. A speci fi c DECmodel project is rep­
resented within the k nowledge base :1s a set of
model. presenta t i o n , and project instances. These
i nstances are created in the knowledge base by
load i ng a DECmodel modeli ng language (DM L) fi le
or through i nte raction with t he model b u i lder or
the presentation bu dder.

Persistent Storage The D M J . is a subset of the
ROCK frame defi n i t i o n l anguage and is used by
the knowledge base for p ersistent sto rage .
A DEC:model project is stored as A SC I I text i n three
files that contain the model, present ation. and map­
p i ng objects. The language em ploys ROCK syntax
but uses o n ly the frame classes and slots defi ned in
the DECmodel knowledge base.
The DECmodel tool utilizes the ROC K frame defi­
nition interpreter as the DML i nterpreter. Since the
ROCK in terpreter was not intended to he u sed for
p e rsistent storage . the D ECmodeJ developers made
several m inor modifica t i o ns to obtain the desired

I vi.

6 ,\o. 4

Foii i'J'J· I

Digital Teclmical journal

The Design of DECmodelfor Windows

error hand I ing capabi lities. The DECmodel tool

A nazysis and Reporting Services

The knowledge

base contains services that al low the user to ana­

contains its own DML code generator.

lyze models and presenrations in the knowledge

Simulation Engine

The simu lation engine exe­

base and to generate reports.

cu tes a discrete event simu lation of the model in

The consistency advisor checks models, presenta­

the knowledge base. This simu lation can be per­

tions, and mappings for inconsistencies and poten­

formed either in teractively or in a batch mode. The

tial problems at any point in the model development

simul ation engine was designed to be so robust

process. This check is analogous to the syntax check

that a model can be simul ated a t any stage of its

performed by a compiler. The consistency advisor

develop ment,

check is the primary model-building debugging aid

regard less

of inconsistencies

or

undefined elements.

for users. I n consistencies i n the model do not pre­

The simulation engine interacts with the presen­

vent a model from being simu lated.

tation b u i lder to control simu lation, animation, and

The model description report l ists the descrip­

graphics. The user con trols simu lation through

tion, messages sent, and messages received for each

the presentation bu i lder. The presentation bu ilder

activity and process. The model table report con­

cal l s simulation engine API fu nctions to perform

tains the basic model information in a table format

the requested actions, such as starting,

for easy access by another application, database, or

step­

ping through, pausing, ending, and reinitial izing

spreadsheet. The simulation s u m mary report con­

the sim u l ation .

tains information on simu l ation perfo rmance.

Script Engine and CmnjJiler

Scripts provide

a means of specifying user-defined actions to cus­

Design and Implementation Decisions

The inter­

nal engine for the first DECmodel product release,

tomize model anim ation and to p erform spe­

DECmodel for Windows version 1 .0, was imple­

cial presentation actions during simu lation. The

men ted as a Windows dynamic l i nk l i brary (DLL)

DECmodel tool contains a language for defi n i ng

using the Windows version of ROCK version 1 .0, the

scripts, a script compi ler, and a script engine for

Windows version of AMP version 1 .0, and M icrosoft

executi ng the scripts. Although the DECmodel team

C!C++ version 70. For DECmodel for Windows

wanted to avoid requ iring any progra m m i ng i n the

version 1 .1 , developers ported the internal engine

tool, developers decided that a script language was

to Microsoft Visual C++ version 1 .0.

the only way to i m plement these features in the
The script la nguage contains fu nctions for
•

Annotating, h id ing, showing, flashing, moving,
highl ighting, and seal ing p resentat ion icons

•

•

Several options existed for implementing the
DECmodel knowledge base. The knowledge base of

available time frame.

the Symmod application, the precursor to the
DECmoclel product, was implemented in a LISP envi­
ronment. The DECmodel engineering team wanted
to move to a more standard progra mming environ­
ment and, therefore, focused on C++ and C++-based

Playing sounds and sound loops

tools. However, a straight C++ implementation

Animating connections between nodes

would have required the reimplementation

of

knowledge represent ation, simu lation, a nd model­
•

Showing, h id ing, and cleari ng certain kinds of
windows

ing technology available in other tools.
Another model ing and simu lation technology,

•

Starting other applications

the Model i ng and S i m u l ation System (MSS), had
been developed for Digital's Artificial I ntel l igence

•

Temporarily stopping execution

Techno logy Center by the Carnegie Group, Inc.

•

Loading a new project

(CGf ) H This graphical tool was designed at a lower

level than Sym mod . I t used a model ing simu lation

•

Starting and pausing the simu lation

•

Displaying files

•

version of Symmod. However, the MSS model i ng
paradigm was not compatible with that of the
DECmodel tool.

Displaying a list of DECmodel development team
members

Digital Tee/mica/ ]ou rual

la nguage and was developed to im plement t he next

IMKA had also been recently developed by
CGl, fu nded by a consortium of companies, as a

l,bl. o No. 4

Fall I'J'Yi

57

Workflow Models

re p l a ceme n t for the

K n o w l e d ge C raft p rodu c t .

J M KA 's i m p l e me n t a t i o n , ROC K , l acked some of t h e

c l a ss l i braries i n c l u ded i n Kn o wl e d ge Craft fo r s i m­
u l a t i o n a n d process m o d e l i ng b u t ran s i g n i fi c a n t l y
fa s te r t h a n Kn ow l e dge Craft. The e n gi nee r i ng tea m
decided to use ROC K to i m pl e m e n t t h e k now l e d ge
base beca use of i ts k n o w led ge r e p rese n ta t i o n
power and its C++ compa t i b i l i t y D i g it a l contracted
with CGl t o port the c l ass li brar ies to ROCK . The
team , therefore, had a head start in designing ancl
i mplementing the imernal engine. The p o rta b i l i t y

of ROCK was a l so a n ad va n t a ge ; sw i t c h i n g to t h

�

Windows p la t fo rm from the DECwimlows p l a t for m

caused no d i s ru p t i o n in d e ve l o p m e n t .

The o r i g i n a l i n te n t of t h e engineering team was
to i m p l e me n t the DECmodel tool as a s i ngle exe­
c u t a b l e file. The kn ow l e d ge base c o n t a i ns m u ch
g lo b a l d a t a , however, and res t r i c ti o n s on t h e
n u mber o f data s eg m e n t s re qu i r e d d e velo p e r s t o
i mp l em e n t t h e i n t er n a l e n gi n e as a D LL. Th is encap­
s u l a t i o n o f the i n ternal e ng i n e a l lows i t to b e used
in othe r a pp l i c a t i o n s a n d e n a b l es ea sy por t i n g to
ot h e r p l a t fo r m s . The DECmodel tea m d e ve l oped
a set of i n t e rn a l API f u n c t io n s and structures to
al low i nteractions between the DLL-based internal

engine and th e executable-based user i n terface.
Th e

Sy m m o d

app l i c a t i o n

l a n g u age based on liSP

for

had

a

m o d e l i ng

p e r s i s t e n t storage of

models and used a rel a t i o n a l database f(>r pe r s i s tent
storage of p re s e n t a t i o n s . Consideration was g ive n
to d e velo p i ng a m o d e l in g l a nguage sp e c i fic

to

the D ECmodel tool. Instead, the engineering team
d ec i d e d to use t he ROCK frame d e fi n it i o n l a n ­
guage, s i nce i t was a l r e ady c o m p l ete l y d e f i n ed a n d
d e bu gge d and h a d a n i n t e rp ret er. 'fhe t e a m u s e d
t h i s l a n g u a ge for p e r s i s t e n t storage of both m o d e l s
a n d p rese n t a t i on s t o a l l o w e a s y s ha r i n g of pro j e ct s
betwe e n users a n d to s i m p l i fy debugging b y u s e rs
a n d DECmorced the team to postpone plans fo r

q u e n t ly, when d ev e l o p e r s deci ded to fo cus s o l e l y

graphical editors i n favor of d i a log boxes, which
were faster to i m ple m ent. for example. t h e team had

Windows

i n te rface

Window a n d h a d parri a l .l y developed i t . This window

d o n e a s ignifican t a m ou n t of design w o r k toward

a l low graph i c a l e d i t i ng of i t s i nforma t i o n . Sched u le

u n d e r t he Windows NT opera t i n g syste m . Conse­

o n t h e l ' C p l a tform r u n n ing under t h e st:mdard
operating syste m ,

t he

user

development effort was d is r u p ted . Engineers h a d

achieving a DEC:wi n clows i m plem e n t a t i o n .
The

DECmodel

engineering

team

considered

initia l lv plan ned to i m plemen t a n Ac t iv i t y Edi t i n g
was to provide a c o m p lete v iew of an activ i t y a n d

constra i n t s required t h e ream to abandon t h i s p l a n
a n d to develop a set of d i a log boxes t h a t were n o r as

other cl ass .l i braries and user i nt e rface i m plemen ta­

easy to use but were faster to i mplement.

c i e n t i n W i ndows fea t ur e s o r i n t h e look a n d feel .

com m i t ted to storyboards i n a n y detail a t t he begin­

p l a t form fo r the foreseeable fu ture, t h e e n g i n e e r i ng

the disru p t i o n s in the deve l o p m e n t work.

t i o n packages (s u ch as A.'VT), but most were d e fi­
S i nce the W i n dows op e rating system was t h e o n l y

The user i n terface design was not specifi ed o r

n i ng of the project, p a r t i a l ly to s ave t i me after

Th is deci­

team fel t t h a t u s i n g Microsoft Fo u n d at i o n C l asses

sion J e d to more lost t i m e l a ter i n the project,

s i o n a fter they had pe rformed a s i g n i fi c a n t amount

designed q u i ck l y and someti mes incomp a t i b l y. ami

was the best c hoice . However. t hey m ade t h is deci­
of

development

work with one of the to o l s. M u c h

th o ugh ,

use

r i nt e r face

consequ e n t l y req u i red

r ewo r k i n g.

bec ause

f ea t u re s

were

J n a d d i t i o n , the

of rhe work had to be redone. w h i ch c o n t r ibu ted to

resu l t i n g u s e r i n t t>rface was nor as easy to use as it

the sched u l e d e l av.

c o u l d have been i f bett e r p l a n n e d .

60

l'r;/

{>

.\'u. i

hill I'J'N

Digital Technical journal

The Design of DECmodelfor Windows

External review of the user interface design was

goal of requ iring no programming, and some users

not performed until late in the project. The review

found scripts hard to use. However, many users have

yielded some ideas that would have resulted in

requested that a future DECmodel version provide

a more usable product; however, there was not

more script functions and extend the script language

enough time left in the schedule to implement them.

to be more like the BASIC p rogramming l anguage.
Also, to en hance the use of the DECmodel tool i n
the design of business processes, a futu re version

Delivery
A discussion of the released product and the team's
success in achieving the design and development

should support classes to make generic processes
available as b u i ld ing blocks of a business p rocess.

goals fol lows.

Development Successes and Lessons
The

Release
Digital released version 1 .0 of the DECmodel for
Windows product in November 1993 and version
1.1 in April 1994. Version 1 .0 contained the basic
capabil ities for building models and p resentations
of business processes; version 1 .1 added a set of
minor enhancements and bug fixes. Because of its
small, focused market and the large cost savings
that can result from its use, the DECmodel tool was
in troduced as a low-volume, h igh-priced product.
The product includes the software, example mod­
els, documentation, and a week of hands-on train­
ing. The DECmodel tool is an integral part of Digital
Consu lting's reengineering practice.

DECmodel

engineering

team

released a software product on

successfu lly
the M ic rosoft

Windows platform, the one most popu l ar with busi­
ness consu l tants. This achievement was significant
because the group of engineers began the project
with no PC experience. The team did not meet its
one-year del ivery goal , and the goal s lipped to one

a n cl one-h a l f years after the Phase 0 annou ncement.

However, this time frame was sti l l extremely short
for developing a complex PC product from scratch.
The product retained the ex isting Symbol ic
Mod e l i ng parad igm ( i . e . , a p rocess-activity-message
model a nd a strong distinction between model and
presentation) and exhibited performance an order
of magnitude better than that of the Sym mod prod­
uct, which it replaced. The product uti lized the

Success of Design Choices

most widely accepted modern programm ing tech­

The separation of the model from the presentation

nology base (C/C++ ), which simp lified maintain­

is the single most i mportant element of the prod­

ability and reduced the need for special train i ng

uct's success. This feature, along with animation,

of maintainers.

d istingu ishes the DECmodel tool from its competi­

Splitting the development team into two sub­

tion. Some users have even requested the capability

teams worked wel l . It distribu ted the amount of

of b u i lding the presen tation first and then gener­

learning about new technologies requ ired by the

ating the corresponding model. Such capabil ity

engineers and minimized the overall development

would require considerable investigation.

time. Key factors in the success of this app roach

The paradigm of process-activity encapsu lation

were the detailed object and i nternal API specifica­

is diffic ult for some users to become accustomed

tions that were kept up-to-date throughout devel­

to. Many st i l l p refer to build a model using a work­

opment and thus provided a rei iable interface

flow approach, wh ich the DECmodel tool can sup­

between the two parts of the project.

port, rather than by defi n i ng each process and i ts

After the product was released, the DECmodel
team identified certain factors that cou ld have

behavior i ndependently.
The exclusion of resource constraint s has l i m i ted

made the team and the product even more success­

the appl ication of the DECmodel tool to system

fu l . The entire engineering team would have bene­

design, thus preventing its use in mode ling sys­

fited from Windows training at the onset of the

tem performance. AJthough the capability was orig­

project. The Windmvs design of the user interface

inally not a product goa l , many users would l ike

shou ld have been specified and committed to story­

a fu ture version of the D ECmodel prod uct to pro­

board in mu ch greater detail much earl ier in the

vide this feature.
To perform special user-defined actions during

project. In addition, the team shou ld have arranged
for Windows experts to review the design . These

the simulation, a script language was i ncluded in

changes in the engineering process would have

the DECmodel tool . This design feature violated the

helped the team produce a cleaner, easier-to-use,

D igital Tecbuicnl]ourual

1-b/.

6 No. 4

Fall I'J')4

61

Workflow Models

more maintainable user interface and would have

Laurel Drummond, Peter Floss, Amal Kassatly, Mike

reduced implementation time. The project sched­

Kiskiel, Kip Landingham, and Janet Rothstein.

u le should have been created using a bottom-up
rather than a top-down process. The initial one-year

References

schedule was based on an unrealistic, management­

1 . Symmod User's Guide ( Maynard, MA : Digital

imposed release date. W11en the engineering team
revised the schedule and calculated a release date
based on their detailed estimates, the team met the
new date.

Summary
Modeling and simulating business processes is an
important part of business process reengineering.
Digital developed the DECmodel tool specifica!Jy
for this type of simulation. Although it borrows
many ideas from other discipl ines of model ing and
simulation, as wel l as from object-oriented design,
the DECmodel product is unique in the way it mod­
els business processes, separates the model from
the presentation, and represents the model as

frames in a knowledge base.

Acknowledgments
The authors would l ike to acknowledge the follow­
ing people who also contributed to the design of
the DECmodel product: Ty Chaney, David Choi,

62

Equipment Corporation, 1990).

2. Knowledge Craft Reference Manual (Pittsburgh,
PA: Carnegie Group, 1988) .

3. S. Hoover and R. Perry, Simulation, A Problem
Solving Approach (Reading, MA: Addison­
Wesley, 1989).

4. DECmodel for Windows: Modeler's Guide (May­
nard, MA: Digital Equipment Corporation, 1994).

5. ]. Peterson, Petri Net Theory and Modeling of
Systems (Englewood Cl iffs, N.J : Prentice-Hall,
1981).

6. G. Booch, Object Oriented Design (Redwood
C ity, CA: Benjamin-Cummings, 1991).
7. ROCK

Software Functional Specification, Ver­
sion 2. 0 (Pittsburgh, PA: Carnegie Group, 1991).

8. Modeling and Simulation System User's Guide
(Pittsburgh, PA: Carnegie Group, 1991).

Vol. 6 No. 4

Fall 1994

D igital Technical journal

Dennis G. Giokas
john C. Rokicki

The Design ofManageWORKS:

A User Interface Framework
The Manage lf!ORKS Workgro up Administrator for Windows software product is
Digital's in tegration platform for system and network management of heteroge­
neous local area networks. The Manage WORKS product enables multiple, heteroge­
neous network operating system and network interconnect device management
from a single PC running under the Microsoft Windows operating system. The
NfanageiVORKS software is a user interface fra mework; that is, the services it pro­
vides are primarily targeted at the integration of the user interface elements of
management applications. It manifests the organ izational, navigational, andJunc­
tio nal elements of system and network ma nagement in a cohere nt whole. Viewers,
such as the hierarchical outline viewer and the topological relationships viewer
that are components of the Manage WORKS softwa·re, provide the organ iza tional
and navigational elements of the system. Management applications developed by
Digital and by third parties through the Manage WORKS Software Developer's Kit
provide the functional elements to manage network entities. This paper discusses
the user intetface desig n that implements these three elements and the software sys­
tem design that supports the user intetface framework.

The ManageWORKS Workgroup Adm in istrator for

This paper focuses on how the ManageWORKS

Windows software product is D igital's strategic

software presents and integrates its fu nctiona l ity

tool for prov iding system and network manage­

to the end user. Specifical ly, the paper presents

ment of heterogeneous local area networks (LANs) .

details of the user i n terface paradigm and d iscusses

It serves as Digital's p l atform for the integration

the design

of PC LAN management. From the perspective

employed . The paper also d iscusses the design of

of the end user, i . e . , the LAN system administrator

Man ageWORKS software in support of the user

and network manager, the Man ageWORKS p roduct

interface framework.

comprises a suite of modules

that

rationale and

the design methods

integrates

a diverse set of ma nagement activi ties into one
workspace. From the perspective of tlJe developer
of system and network management applications,
the Ma nageWORKS prod uct is an extensible and
flexible software framework fo r the rapid develop­
ment of integrated management modules, a l l of
which presents a consistent user int erface.
The design of the management system was u ser

Driving Forces behind the Design
The ManageWORKS software was first released
as a component of the PATHWORKS version 5.0
for DOS and Windows product. The foc i for
that PATHWORKS release set the tone for the
ManageWORKS design. The PATH\'VORKS version 5.0
design objectives were to

centric, i .e . , usabi l ity was the top priori ty. Thus,
we began the design work without any precon­

l. Enhance the usability of the PATHWORKS prod­

ceived notions about the management software sys­

a command line-based u s e r i n terface, t h e goal

tem design. The design that emerged and that is

was to develop a graphical user interface for the

documented in this paper was driven solely by the

system that was based on the Microsoft Windows

uct. Since the PATHWORKS system was rooted i n

user interface paradigm developed and tested with

operating system. Such a user inte rface would be

our customers.

contemporary, easier to learn, and easier to use.

D igital Teclmicaljournal

Vol. 6 No. 4

Fall 1994

63

I

PC LAN and System Management Tools

2. Enhance the m anageabi l i t y of the PATH\VORKS

The team employed software usabi l ity testing

product. The goal was to reduce the cost of own­

throughout the development l ife cycle. Two usabil­

ersh ip by improving the insta ll a t ion, configura­

ity tests were performed w i th early design proto­

tion, and administration of the system.

types; the fin a l test was p erformed with our first

The ManageWORKS design team used two voice­
ot�the-customer techniques to provide more depth
and detail for the two h igh- leve l p roduct design
objectives. First, the team used Contextual I nquiry
to determine a customer profile and to develop
a c l earer statement of the user's work . ' The n , the
team tested user interface prototypes with cus­
tomers by means of formal usab i l i t y testing. From
15 to 20 customers and users pa rticipated i n each
of three rou nds of usabil i ty testi ng.
Early in the investi ga t i o n , Contextual l nqu iry
revealed that the profile of the PATHWORKS system
a d min istrator had changed drasti c a l l y d u ring the
five years since the PATH\X'ORKS product was first
released. A typical system admi n istrator in the era

of PATHWORKS version 1 .0 had been a VA X/VMS sys­
tem m anager who inherited the responsibil i t y of

install i ng a nd m anaging a PC file and print -sharing
product. The i n terface into the system was a VT-class

pass at a d e t a i led concept design. We performed
the usabi l i ty testing with customers to test user
i nterface and fu nctional element design co ncepts
that we developed as a resu l t of the Contextual
I nqu iry. The user thus served as a design partici­
pant. W i th each i teration of the formal testing, we
tested specific functional concepts i n three key
areas: (1) mechan isms to navigate among the m a n­
aged e nti ties , (2) mechanisms to o rganize these
e n ti ties, and (3) the fllnctional capabi li t y i nherent
i n the management d i rectives supported. (Note
that, i n this paper, the servers, s ervices, and
resources m anaged by means of the ManageWORKS
software are c o llectively referred to as m a naged
en t i ties.) The m ajor lessons that we learned from
t h is testing effort and then appl ied to the user i n ter­
face and software designs are as fol lows:
1 . The M a nageWORKS software had to p rovide

mechanisms to navigate among a d iverse set of

term i n a l running command l in e - based u t ilit ies.

m anaged entit ies o n the LAN or in some user­

Tod ay, a system administrator is usu a l ly a PC user

defined m anagement d o m a in . Users want to be

who is qu ite fam i l iar with graphical user i n terfaces.

able to v iew and thus " d iscover" the entities that

Such an administrator is more l ikely to be trainee! in

are to be m a n aged . The system had to present

the installation, configurat i o n , and management of

the m anaged entities i n graphical d isplay formats

PCs and PC networking software than his/her pre­

that were fam i li a r ami e n ticing to users. Users

clecessors. This change in the profile encour aged

welcome the abi l i ty to support d ifferen t styles

us to shift the PATHWORKS focus from using host­

of presentation . Final ly, users need easy mecha­

basecl command l i ne utilities to m a n age the system

nisms to navigate t h rough the h i erarchy of

to using client-based graphical u t i l i ties.

an entity.

We also profi led the customer network configu­
ration . During the same five years, i t changed from
a very s i mp le and homogeneous environment with
just a few PATI-fW'ORKS servers to a med ium-to-large

heterogeneous PC LA N . At presen t , configurations
comprise n etwork operating systems that consist
of Nove l l NetWare, Microsoft LAN M anager, and

Apple AppleShare file and print serv ices, as wel l
as other services that are emerging in the PC LAN
environment. The network operating systems are

2. Navigati o n mechanisms, as j ust d escribed , work
well for novice users but become ted ious and
constra i ning for more experi enced users, as we
could attest to after our experience with the pro­
totypes. The solu tion that we presented to users
al lowed them to create custom views of their
managed entities, i . e . , to organ ize their manage­
m e n t domains. This concept was wel l received
by users d u ring usabi l i t y testing.

deployed on their native platforms and by Digital

3. The M anageWORKS prod uct had to provide

tem has its own tools to manage the c l ients and

functions that were com mon among a d iverse

on the OpenV M S a n d DEC OSF/ 1 platforms. Each sys­
the servers. Each has a d iffere nt user i nte rfac e that

mechanisms that consistently p erformed the
set of m anagement applications. The product

resll lts i n a long learning curve and thus high tra i n­

design presents users with an object-oriented

ing costs or low productivity for system administra­

view of the m anaged environment. The b u i lding

tors. Customers reported that they desired too l s

block of this design is the object, a n abstraction

w i t h a cons istent user i n terface t o manage this

of a m anageable entity such as a server o r a net­

diversi ty.

work router. Each object is a m ember of a single

64

Vol.

(,

No. 4

fall 1994

Digital Tecbuical journal

The Design ofJIIJcm age WONKS: A User Interface Fra mework

object class t h a t descri bes t h e set of object

The M a n ageWORKS team adopted the concept of

i nstan ces w i t h i n it. The M a n ageWO H KS appl i­

p l u g- i n modu les, a software design that is supported

cation renders objects to the user as icons i n a

by the W i ndows D y n a m ic L i n k L i brary ( D LL) archi­

v iewer. Fo r exa m p l e , fo r a LAN that con t a i n s

tectu re . " The design is also i n co m mo n use by m a n y

three NerWare servers, t he object class c a l led

Windows

NerWare Servers wou l d c o n t a i n three objects,

Con trol P a n e l , t he u t i l ity that m a n ages the local

each of which represents one of t he t h ree i mli­

cl eskto p 's configura t i o n and user prefere n ces. 1

vidual Ne tWare servers o n the LAN. W h e n users
focus on

an object,

the tool

reve a l s w h i c h

a c t i o n s a r e val id i n t h e object's cu rre n t contex t .

appl ications

i ncl u d i ng

t l1e

W i n d ows

The next ch a l le nge was to decide h o w m u c h
constra i n t

to

i m pose

on

the

design

of

the

M a nageWORKS' pl ug- i n modules a n d h o w consis­

T h i s approach d i ffe rs from the trad i t i o n a l com­

t e n t t h e modu les m ust he. Digi t a l 's exten s i b l e enter­

mand l i n e approach

the user first

p r i s e m a nage m e n t d i rector, the DECmcc product,

selects the u t i ! ity (act i o n) and then specifies

incorporated some exc e l l e n t concepts. ' I n parti cu­

in

which

the objects upon wh ich to act. Interesti ngly,

l a r, our design was i n f l uenced by the way in w h i c h

whereas novice users fou n d t h is object - focused

DECmcc l ayered the m a n age m e n t respons ibi l ity

concept easy to grasp, t hose w h o considered

i n to prese n t a t i o n modu les. fu n c t i o n a l m o d u les,

themselves strong users of the trad i t i o n a l com­

a n d access modu les. Early i n the design process, we

m a n d l i ne m a n agemen t u t i l i t ies ex perie nced d i f

decided to separate the nav igat i o n and presen t a­

ficu l t y i n gras p i ng the n e w concept .

t i o n of m a n aged e n t i t ies from t h e access a n d func­

4 . T h e typical customer h a s a d iverse a nd la rge
(200 to 1 ,000) n u m be r of e n t i ties to m a nage. To
add ress t h i s need , the pro totype testing pre­
sented users wi t h the abi l i ty w m a nage m o re

than one e n t i t y at the same t i m e a n d the abi l it y
t o m a nage m a n y e n t i t ie s a s o n e . Users l i ked

being able to view and m od i fy the properties

o f m u l t i p l e e n t i t i e s a t the s a m e t i me as we l l as
being able to m o d i fy the same property across
a set o f l i ke e n t i ti e s .

t i o n a l m a n age ment o f the e n ti ties.
Another DECmcc concept, w h i c h is used, for
example, in the access m o d u l e layer, was the pre­
s e n t a t i o n o f a consistent view to the l ayers above . '
This concept, however, was not s u i t abl.e for the
Man ageWORKS design because i t wou ld have pl aced
constra i nts on the user i n terface design , i n particu­
l a r, o n the presentation o f t he a t t ri bu tes of m a n­
aged e n t i t ies. The design team was not w i l l i n g to
comprom ise o n t h is aspect of the des i g n .
Thus, we decided on a ManageWORKS design that

'5 . I n a d d i t i o n to prov i d i ng a c o n s i s t e n t user i n ter­

can best be described as a user i n terface frame­

face, the ManageWORKS product should i n tegrate

work. The i n i t i a l release, w h ich was a component

the m anagement tools i n to one workspace . User

o f PATHWORKS ve rsion '5.0 for DOS a n d W i ndows,

feedback Jed to the design of the user i n terface

offered few serv i ces other t h a n to tie together t h e

framework as the del ivery ve h i cle fo r a d iverse

user i n terface elements req u i red for system and

set of man agement appl ications.

network man agemen t . The user inte rface serv ices

The Key Software Design Principles
At t h i s p o i n t i n the developm ent cyc l e , the design
focus s h i fted

from deve l o p i ng and tes t i n g user

needed were d i ctated by the five user i n t e rface
requ i rements previously described.
The Ma nage WORKS design incorporates two types
of p l u g- i n m o d u les: naviga t i o n mod ules, referred to

i n terface a n d fu n c t i o n a l i t y concepts to design i ng

in the M a n ageWO R KS product as Object Naviga t i o n

t he M a nageWO R KS software i t s e l f. W i t h what we

Mod u l es (ONMs), and appl ication modul es, referred

cons idered to be a good u ndersta n d i ng of the user's

to as Object M a nageme n t Modu les (OMMs) . The

needs, we proceeded to design a software archi tec­

M a nage\VORKS

ture to support those req u i rement s.

flow a n d messaging between the m o d ules.

framework c o n t ro l s

the

control

Prior architectures that were fa m i l iar to t he

ONMs a l l ow fo r a ny number of navigation models

design tea m served as starting p o i n ts fo r the desig n .

to be s u p ported a n d used s i n g l y or s i m u l t aneously

The fo l lowing two examples represent sources o f

by the user. Al though, by d e s ig n , ONMs possess no

design concepts that we e m p loyed and ada pted t o

k n owledge of t he m a n aged entities o r entity rela­

s u i t o u r objectives. E a c h re presents a n o p p o s i n g

t i o n s h i p s they d ispl ay, they d o possess the a b i l i t y

end of the spectru m w i t h respect to d e s i g n objec­

to d isplay e n t i t ies w i t h t h e re l a t i o n s h i p s i n h erent

t ives and i mpleme n t a t i o n .

in them . O N I'< ls a l so prov i d e the mechanisms fo r

Digital Tecbuical jou rnal

�'Ill. 6 No. ·

Fall I'J94

6 '5

PC LAN and System Management Tools

browsing and navigating through the m anagement

can develop new ONMs and OMMs and simply enro l l

hierarchy. I n addition to navigation capabi l ities,

them into the system . Users have the additional

ONMs provide the user i n terface for organ izing enti­

benefit of being able to customize the p roduct to

ties i n to a user-defined m anagement domain.

support only the ONMs a n d OMMs that are usefu l i n

The OMMs are responsible for m anaging the enti­

t h e i r environment.

t i es. The OMM design has three key components.
l . OMMs provide the methods usecl to m a nage the

entities. These methods include the fu nctions of
discover, create, view, modify, and delete. The
OMMs also have the option of presenting to the
user add itional methods. That is, since each O M M
knows b o w to m a n age t h e entities for which it i s
responsible, i t knows which actions c a n b e
a p pl ied to an e n t i t y based on t h e entity's current
state and the user's context.

The User Interface ofONMs and OMMs
G iven the key software design elements presented
in the previous section, the focus of the paper now
returns to the user i nterface. This section describes
what was implemented to support the customer
requ i rements and the design framework.
The user i nterface framework man ifests the orga­
nizational, navigational, and functional elements of
system a n d network management i n a coherent

2. orv!Ms provide access to the m anaged e n t i t ies.

whole. For example, the first t h ree menus on the

An OMM can use any interprocess com m u n ica­

ManageWORKS menu bar-Viewer, Edit Viewer, and

tion mechanism to access or to manage an entity

Actions-are all the tools the user needs to m anage

Examples include the task- to- task, remote pro­

entities. A d iscussion of the Viewer and Edi t Viewer

cedure call , and object request broker mecha­

menus fol lows.

n isms. Since a PC LAN environment affords n o

By means of the ManageWORKS Viewer menu,

common way for a management d irector t o com­

ONMs present d isplay e l em ents, c a l led viewers, to

m u n i cate with al l the types of devices presen t ,

the user. Each instance of a window that a n ONM

the design t e a m decided to leave t h e choice of

creates is considered a viewer. A Man ageWORKS

access mechanism up to the OMM.

viewer is one of the organization a l elements for the

3. OMMs provide the user i n terfaces required for
managing the e n t i t ies. This design component
a l lows developers to presen t an interface that
best suits the needs of the user and best m aps
to the entity being manage d . I t also al lows for
flex i b i l ity, evol u t i o n , and i n nova t i o n in the user
interface of OM.Ms. The ManageWORKS design
team did not want to i mpose a user i nterface
style or present a user i nterface that was com­
promised by the d iversity of appl ications that we
envisioned running within the context of the
framework, e . g . , by being the least common
denominator. Even though o n e of the key prod­
uct design goa l s was a consistent user i n terface,
we felt that it was i mportant to a l low the O M M s
to control t h e u s e r interfaces. F irst, w e thought
the design benefits outweighed the risk of any
i nconsistency. Second, we encouraged, b u t d id
not enforce, consistency by means of a user
i nterface style guide and com m o n l ibraries that
i mplemented those guidel i nes.".r'

user and is the root-level object fo r navigation. Each
viewer is a viewport into a set of m anaged entities
that the user may be browsing and n avigating
through. A viewer is analogous to

a

word proces­

sor's document, i . e . , a v i ewer is a ManageWORKS
" document." Just as you can create new documents
and open , close, or edit existing documents when
you use a word processing appl ication, you can per­
form the same functions on viewers when using the
ManageWORKS software.
ManageWORKS ONMs are responsible for the nav­
igational and organ i zatio n a l d isplay properties. The
current M a nageWORKS release comes w i t h two
ONMs. One ON;YI supports a h ierarchical d isplay of
m a naged entities. This d isplay is rendered i n a s i n­
gle viewer window p,.raphical ly as a tree or textu a l ly
as an outl ine. The other available ONM supports the
relational d i sp l ay of m anaged entities, rendered as
a map. The map ONM can also support a h i erarchy;
each map is rendered in a new viewer instance.
Figure 1 shows M a nageWORKS with two hierarchi­
cal viewer styles and a map viewer. The hierarchical

The p l ug-i n modules a lso have a residual benefit.

views are the O u t l i ne view (shown i n the Browser

Because these modules can easily be added to or

viewer) and the Outl ine Tree v i ew (shown in the I P

removed from the environment,

they provide

Hierarchical View viewer). In aclc!ition t o the map

an easy way to extend and to customi ze the

viewer (shown i n the II' D iscovery viewer), note the

M a nageWORKS product. D igital and third parties

navigation w indow for the map v iewer (shown in

66

Vol. (i Nu. 4

Fal/ 1994

D igital Technical journal

Tbe Design ofManage WORKS: A User Interface Framework

LARRYAUG
'!li! M OSAIC
-!li! MWORKS

�

16 1 24 1 4 4 1 3

--·

lG 124 . 1 4 4 . 1 67

�

1l(j

16 1 2 4 1 44 1 611

CD RIVE
1liO CLIENTS
� DOWNLOAD
II!!J EDRIVE

16 124

144 0

�

I(

1 6 1 2 4 1 44 250

II>
c::>

I CI

·

-

·

·

A

c:>

-

Figure 1

'
C>

I(
til

I(

'

ManageWORKS Viewers

the IP Discovery (Navigator) viewer). This view

user interfaces and in bow the user interfaces inter­

shows a sca led map; the entire contents of the map

relate to the ONMs.

viewer appears in a rectangu lar outl ine, which rep­

The consistency starts with the ManageWORKS

resents the user's current viewport into the data.

Actions menu. The basic management directives on

The user can use the PC point ing device to drag and

managed entities originate from this menu. The
major chal lenge in designing this menu was to avoid

reposition the viewport.
Because the ONM maintains context when the

using too many menu items, menu items that would

user " e d its," i.e . , mod ifies, the contents of a viewer,

change constantly (i . e . , by addition or d e letion) ,

the user can customize or organize the managed

menu items t h a t b a d three or fou r levels of h ierar­

entities as desired . By means of the Edit Viewer,

chy, and menu items that were not context sensitive

ONMs allow user customization within a v iewer

to what the user was doing. The objective was to

with the support of user-definable hierarchies. For

find a small set of words that conveyed the manage­

example, each instance of a viewer can represent

ment functions the user would most often perform.

a different management domain for the user. The

We felt that these words should always be present

benefit is that the user can find objects and then

in the Actions menu, but to el iminate confusion for

arrange them into hierarchies that are most useful.

the user, they should be rendered inactive when

As stated earlier, OMMs control the user inter­

not val id . On the other hand, we real ized that this

faces for d isplaying and m o difying managed entity

small set of menu choices could never fu l l y support

properties. The ManageWORKS framework p ro­

the actions on managed entities; therefore, the soft­

vides for consistency in how the OMMs invoke the

ware had to provide an extensibility mechanism.

Digital Techt�icaljournal

Vol. 6 Nu. 4

Fall 1994

67

PC LAl'l and System Management Tools

We began the design process by developi ng a n

select m u l t iple objects of the same c l ass from

enti ty/action matrix. O n e axis contained a l ist o f

a viewer ami to i nvoke an O M M method . The list of

the enti ties that w e envisioned being managed

selected objects is contained w i t h i n this drop­

from the M a nageWORKS software. The o ther a x is

down l ist box. The user can easily v iew the

contai ned a l ist of the actions that cou ld be per­

a t tributes of d i fferent objects from the same d i alog

formed on t he entit ies. We marked the i ntersec­

box. The d i a log box d isp lays various sets of m a n­

tions of the axes. I n for m i ng the l ist of actions, we

aged entity properties. The user can select the

chose words t hat were used i n existing products

desired set of properties from the View or Modify

that managed the same ent ities , words that we

drop-down I ist boxes.

thought should be considered in a good user i nter­

Figure 2 dem onstrates that two d i a l og boxes can

face, and final ly, synonyms to those words a l ready

be active at the same time. This feature supports the

l isted . This approach gave us a clear picture of the

ManageWORKS design requirement t hat the user be

common action s and also p rovided a thesaurus of

able to m anage more than one entity at a time. The

words from which to choose . The common actions

ManageWORKS product supports, in effect, threads

o n managed enti t i es that emerged from this exer­

of execution to al low mu l t iple OMivls to be active

cise were

simu ltaneous ly. Support for the design principle
of m anaging many e n t i t ies as eas i ly as one is not

I . Make a new entity of some typ e .

a function of the ManageWORKS software but of
the OMMs, since OM.Ms control the methods used to

2 . D isplay a l l t h e managed entities.
3. View and modify the entity's properties.

4. E l imi nate the entity.
The M a nageWORKS software supports these
common actions through the fol lowi n g Action
menu choices:

manage entities.

The Software System Design
ofManageWORKS
The

focus

of the

paper

now

shifts

to

the

M a nageWOHKS i nternals that support the design
principles and user i n terface just described.

1. Create. Choose Create to make a new enti ty.
2. Expand. Choose Expand to view a l l the e n t i ties
that the lVIanageWORKS software is managing.
3. Properties. Choose Properties to d isplay a d ia log

The Application Framework
As an app lication , the ManageWORKS product is
merely a software framework for i ntegrating i ts top­
level user in terface with the user interfaces of the

box that manifests a l l the entity's properties. The

OMMs and ONMs. The ManageWORKS application

user can then v iew the properties and make

consists of two main components: ( 1 ) the user i nter­

mod ifications, as appropriate.

face shel l and (2) the d ispatcher. Figure 3 depicts

4. Delete. Choose Delete to eliminate the entity.
The design of the Properties d i a log box is one

the relationship between these ManageWORKS com­
ponents and the OMMs and O NMs.
The user interface shel l is a standard Microsoft

of the key user i nterface sty le eleme n ts of the

Windows application that supports the top- level

M a nageWORKS product: however, ManageWORKS

Windows user interface componen ts-the m a i n

does not enforce or p rovide for this element.

appl ication window a n d i t s m e n u bar, t o o l ribbo n ,

Rather, the consistency is a function of a user i nt e r­

a n d status bar. T h e user interface shel l translates a l l

face style guide for OMMs and some com mon

user i n teraction by means o f t h e menus, tool rib­

l ibrary routines that support this user i n terface

bon, and mouse actions i nto OMM ami ONM appli­

style . o C• Figure 2 shows the d i alog boxes of t wo

cation programming i n terfaces (AP!s) to perform

of the three OMMs that come with the current

work for the end user. The she l l i s also responsible

ManageWOHKS

for i n i t ia l iz i ng and terminating the appl ication,

prod uct:

the

Simple

Network

Management Protocol (SNM P) Manager OMM a n d

includ i ng the d ispatcher.

the LAN Manager (LM) server m anageme n t OMM.

The d ispatcher is responsible for m a i n tammg

(The third OMM, for NetWare servers, is not shown.)

a l i n k between the user i n terface shell and a l l

Note the Selected Objects field in the SNM P <.J i a l og

t h e OMMs, a s wel l a s for providing service routi nes.

box. The ManageWORKS software al lows the user to

The d ispatcher loads and i n i ti a l izes a l l OMMs

68

ViJI. 6 No. 4

Fall 1')5J4

Digital Tecbuicaljourual

TIJe Design of Manage WORKS: A u,·er lntetjace Framework

j

ManageWO RKS Workgroup Adnlinls1rator

[16.121.1 11.251

l!J I
l!l l

111!

Selected Objecls:
Properties:

llltl

System Cont8ct

Description;

Is�contca.ct not s pecilied

:t:es

co

Pullin�

(sees)

OK
Cancel
Apply

I OECNIS 600 software version V2.3-4

Group·

Poll I nterval:

-1

.tiel

l!J I

SNt.AP Aouler.IP

Allow modifice.tion by IP Auto-discovery

Time out

'!'l'indow

IGene ral l nforma•ion

Typ e:

System

ons

r

]'io

Redirector

2ttil

60

·W59Zicl
107'i2fiJtJ

10

(sees)

Monitor this node via polling:

Protocol used to monitor this host

Connections
,� ICt.AP

10 SNt.AP

Mode:

SNt.AP Community Nome•

Foiled:

,------·----

Set:

Get:

B uffers

Help

Big:

t.AIB ...

�

----

-

SeiVlocal user

AUTHORIZE

DECnet proxy mappings
VMS$MAIL_PROFILE. DAT

User's mail profile

MAIL

QUOTA.SYS (per disk)

User's d i s k quota

D ISKQ UOTA

Login d i rectory

User's home d i rectory

C R EAT E/D I R ECTORY

User's location, phone n u m ber,



proxy file (NET$PROA.'Y . DAT). Prior to the OpenVMS

deployed to users who need dedicated processing

Management Station product, these files were man­

power or graphics support, and personal compu ters

aged by a col lection of low-level u t i l i ties, such as

are deployed i n other departments for data access

AUTHOIUZE. Although these u t il i ties provide the

and storage. F i naUy, the table lists some groups of

abil ity to manipu late the individual user attributes,

users who need access to m ul tiple systems, some­

they offer l it t le support for ensuring t hat t he overal.l

times with changed attributes. The system m a nager

collection of user attributes is consistent. For

for th is type of configu ration would repeated l y per­

instance, none of these u ti l i ties wou ld detect that

form many tasks across several targets, such as sys­

a user's accou n t had been created with the user's

tems or users, with smal l variations from target to

home d i rectory located on a disk to which the user

target. The OpenVMS Management Station prod uct

had no access.

was designed to operate wel l in configurations

A l l of these factors create additional complexity

such as this.

for a n OpenVlVIS system m a nager. This complexity is

A distributed system is clearly necessary to sup­

compounded when a number of loosely related

port effective and efficient systems management for

Open VMS systems must be managed at various sites.

configurations such as the one shown in Figure 1 .

The user account management features of the

A d istributee! system shou ld support para l lel execu­

Open VMS Management Station product are designed

tion of requests, leverage the clllsterwide attribu tes

to al leviate or remove these additional complexi­

of some system management operations, and pro­

ties for the Open VMS system manager.

OpenVMS System Configurations

vide for wicle area support . These characteristics
are expanded in the remainder of this section.

rll1e OpenVMS operating system can be used in many

Supporting Parallel Execution

ways. The features of the VMScluster method a llow

Support of parallel execu tion has two d ifferent

systems to expand by increment a l l y adding storage

impl ications. First, the execution time shou ld rise

or processing capacity. In addition, the OpenVMS

slowly, or preferabl y remain constant, as systems

operat i ng system is frequently used i n networked

are added. This i mp l ies that the execution against

configurations. Its i n herent richness leads to a large

any given target system should be overlapped by

and diverse range in the possible Open VMS configu­

the execu tion against the other target systems.

rations. The s ki l l and etfort requ ired to m anage the

Second, for parallel execution to be usable in a wider

larger configurations is considerable.

range of cases, it shou ld be easy and straightforward

For instance, Figure 1 shows a possible customer

to make a request that wi l l have similar, b u t not iden­

a

number of VMScl uster

tica l , behavior on the target systems. For instance,

systems extend across a primary and a backup site.

consider adding a user for a new member of the

configuration, i n which

Each cluster has a somewhat different purpose, as

developmen t staff i n the configuration shown in

given i n Table 2 . Here OpenVMS workstations are

F igure 1 . The new user woul d be privileged o n the

76

Vol. 6 No. 4

Fall 1994

Digital Technical Journal

The Structure of the Open VMS Management Station

ETH E R N ET

DISK

DISK

DISK

CLUSTER A
DISK

DISK

CLUSTER C

DISK

DISK

DISK

CLUSTER B

Figure 1

Distribu ted OpenVMS System Configuration

development VMScluster syste m , b u t u nprivileged

Jn the first case, the scope of the resource

on the production cluster. It shou ld be straightfor­

extends throughout the VMScluster system. Here, it

ward to express this as a single request, rather than

is desirable (ancl when the operation is not idempo­

as two disparate ones.

tent, it is necessary) for the operation to execu te

Leveraging VMScluster Attributes

case, the operation must execute against every sys­

once within the VMScluster system . In the latter
OpenVMS

system

management

tasks

operate

tem within the cluster that the system m anager

against some resources and attributes that are

wants to affect. Also, the set of resources that fal l s

shared cl usterwide, such as modifications to the

into t h e first case or the second is n o t fixed. I n the

user au thorization file, and some that are not

OpenV1viS operating system releases, the ongoing

shared, such as the system parameter settings.

trend is to share resources that were node-specific

Table 2

Usage a n d User Community for Sample Configuration

Name

Usage

User Commun ity

A

Main prod uction c l u ster

Operations g roup
Production g ro u p
Development g roup (unprivi leged)

B

Development c l u ster

Operations g ro u p
Development g roup
(fu l l development privi leges)

c

Backup production c l uster and

Operations g roup

mai n accounting c l u ster

Development g ro u p (unprivi leged)
Prod uction g ro u p
Accounting g ro u p

Workstations

Workstation owner
Some of operations g ro u p

Digital Teclmicaljourual

Vol. 6 No. 4

Fall 19':)4

77

PC LAN and System Management Tools

throughout a VMScluster syste m . The OpenVMS

components were specified i n the design, but were

Management

unnecessary for the i n i tial release.

Station

software

must

hand le

resources that have different scopes on d i fferent

The

cl ient

software

on

the

PC

uses

the

systems that it is m anaging at the same time.

ManageWORKS

Wide Area Support

framework provides hierarchical navigation and

Digital's

Management of a group of Open VMS systems is n o t
necessarily l i mited t o one site or t o one local area
network (LAN). Frequently there are remote backup
systems, or the development site is remote from the
production s ite. Almost certainly, the system m an­
ager needs to be able to perform some management
tasks remotely (from home). Therefore, any solu­
tion m ust be able to operate outside of t h e LAN
environment . It should also be able to function rea­
sonably in bandwidth- l i mited networks, regardless
of whether or not the slower speed l i nes are to
a few remote systems, or between the system man­
ager and all the m a n aged systems.

management

PATHWORKS

framework

product.

This

from

extensible

presentation support, as wel l as a local configura­
tion

database. 2 The

framework

d ispatches

to

Object Management Modules (OMMs) to manage
i nd ividua l objects. OpenVMS Management Station
has three OMMs that are used to organize the system
manager's view of the m anaged systems. These are
Management Domains, VJV!Scluster Systems, and
OpenVMS Nodes. In add ition , two OMMs manage
user accoun ts: OpenVMS Accounts and OpenVMS
User. The first OMM is used to retrieve the user
accoun t s and to create subord i nate OpenVMS User
objects in the ManageWORKS framework h ierarchy.
The second contains the c lient portion of the
OpenVMS

user account m a n agement

support.

Underlying the last two OMMs i s the client commu­

OpenVMS Management
Station Structure

nications layer. This provides authenticated com­
m unications to a server.

The resul ti ng structure for the OpenViviS Man­

The server software on the OpenVMS systems

agement Station software is shown in Figure 2 . The

consists of a message-dispatch i ng mechanism and

components contained within the dashed box are

a collection of server OMMs that enact the various

present in the final version 1 .0 product. The other

m anagement requests.

I

NETV I EW
SYSTEM

\

I
I

I
I
I
I
I

PROXY

d ispatcher is

also

� - - - - - - - - - - - - - - - - - - - - - - - - - - -

I

AGENT

The

I
I
I
I
I

I �
I

API

l

r- - -

�:;;

-

LOCAL
CONFIGURATION
DATA

USER
OMM

I

I
I
I

H J

MANAGEWORKS FRAMEWORK

I

LOCAL
CLIENT

- - - -

PC C L I E N T

C O M M U N ICATION LAYER

I

S E RV E R I N FRASTRUCTURE

UASERVER
OMM

I
FORWA R D I NG C O M M U N ICATION LAYER

I

v

S E RV E R I N FRASTRUCTURE

UASERVER
OMM

FORWA R D I N G COM M U N I CATION LAYER

L - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1

Figure 2

78

OpenVMS Management Station Structure

Vol. 6 No. 4

Fall 1994

D igital Tecbnicaljournal

The Structure of the OpenVMS Management Station

m anagement

the system m anager is remotely located across

request to a l l target VMScluster systems and i nde­

slower speed lines from the managed systems.

responsible

for

forwarding

the

pendent systems, and for gathering the responses

Final ly, they require that the client u nderstand the

and returni ng them to the c l ient. The version 1 .0

scope of a m anagement resource for all possible tar­

server contains two OMMs: UAServer and Spook .

get OpenVMS systems that i t may ever manage.

The former implements the server support for both

These various difficulties led the project team to

the OpenVMS Accounts and OpenVMS User OMMs.

place the data gathering, reduction, and display

The Spook OMM implements the server component

logic in the client. The client com m unicates to one
of the managed systems, which then forwards the

of the authentication protocol.
Other c l ients were not b u i l t for version 1 .0 but

requests to all affected independent systems or

were planned into the design. Specifically, these

VMScluster systems. Similarly, repl ies are passed

items are (l) a local client to provide a local applica­

through the forwarding system and sent back to the

t ion program mi ng interface (API) to the functions

c l ient. The chosen system is one that the system

in the server, and (2) a proxy agent to provide

manager has determined is

a mapping between Simple Network Management

a forward ing h u b .

a

reasonable choice as

Note t h a t t h e forwarding system sends a request

Protocol (SN\11') requests and server functions.

to one system i n a VMSc luster. That system m ust

Design Alternatives

determine i f the request concerns actions that

Before this structure was accepted, the designers

occur throughout t he VMScluster or if the request

considered a nu mber of alternatives. The two areas

needs

with many variables to consider were the place­

VMScluster. In the second case, that node then

ment of the com m u nications layer and the use of

acts

as

to

be

forwarded

further

within

the

a n intermediate forwarding system.

This structure a llows the cl ient to scale rea­

a management protocol.

sonably with i ncreasing numbers of managed sys­
first

tems. The nu mber of active comm u nication l inks

major structural question concerned the place­

is constant, although the amount of data that is

ment of the comm u n ications layer in the overal l

transferred on the replies increases with the num­

appl ication.

ber of targeted managed systems. The amount of

Communications Layer Placement

The

At one extreme, tl1e client could have been a dis­

local state i nformation increases similarly. Although

play engine, with al l the application knowledge i n

i t is not a general routing system, its responsiveness

t h e servers. T h i s design is simi.lar to t h e approach

used for the X Window System and i s sufficient for

is affected less by either a system manager remote
from all t he managed systems, or by the manage­

the degenerate case of a s i ngle managed system.

ment of a few systems at a backup site. Final ly, i t

Without appl ication knowledge in the client, how­

al lows the managed VMScluster system t o deter­

ever, there was no opportunity for red u ction of

m ine wh ich management requests do or do not

data, or for the simpl ification of i t s d isplay, when

need to be propagated to each i n d ividual node.

attempting to perform m anagement requests to
several target systems.

Use of Standard Protocols

The second m ajor

At the other extreme, the appl ication knowl.edge

structural question concerned the use of de facto or

could have been whol l y contai ned within the

de j u re standard enterprise management protocols,

clien t . The server systems wou ld h ave provided

such as SNMP or Common Management Information

simple file or disk services, such as Distribu ted

Protocol (CMIP).-14 Both protocols are sufficient

Comput i ng Environment (DCE) distributed fi le

to name the various management objects and to

server (DFS) or Sun's Network F i le Service (NFS).

encode their attribu tes. Neither can direct a request

Since appl ication knowledge would be in the

to m u ltiple managed systems. Also, neither can han­

c l ient, these services would provide m anagement

d le the complexities of determining if management

requests to either a single managed system or to

operations are inherent ly clusterwide or not. The

m u ltiple systems. However, they scale poorly. For

project team could have worked arou nd the short­

instance, in the case of user acco u n t management,

comi ngs by using additional logic within the man­

seven active file service connections wou l d be

agement objects.

required for each m anaged syste m ' Fu rthermore,

reduced the management software's use of either

these services exhibit very poor responsiveness if

D igital Technical Journal

Vol. 6 No. 4

Fal/ 1994

This alternative

wou ld

have

protocol to l ittle more than a message encoding

79

PC L'\N and System Management Tools

scheme. However, i t was n o t clear that the result

Note that these hierarchies do not i mply any

wou ld have been useful and m a nageable to clients

form of close coupl ing. Their only purpose is to aid

of other m anagement systems, such as NetView.
On a pu rely pragmatic level, an SNMP engine was

the system m a n ager i n organization . Several d iffer­
e n t hierarch ies m ay be used . For a given set of sys­

not present on the Open V MS operating system . The

tems, a system ma nager m ay have one hierarchy

CMIP-basecl extensible agent that was available

that reflects physical location and another that

exceeded the management software's l im i ts for

reflects organization bou ndaries.

resource consumption a n d responsiveness. For

Figure 3 shows a typical hierarchy. In the figure,

i nstance, with responsiveness, a simple operation

the system m a n ager has grouped the VMScluster

using AUTHORIZE, such as "show account attribu tes,"

systems, PSWAPM and PCAPT, i nto a domain cal led

typical l y takes a second to l ist the first user accoun t

!Vly M a n agement Dom a i n . The display also shows

a n d is then limited b y display bandwidth. F o r suc­

the results of a " l ist users" request at the domain

cessful adoption by system m anagers, the project

level of the hierarchy. A " l ist users" request can a lso

team felt that any operation needed to be close to

be executed against a single system. For instance, to

that level of responsiveness. Early tests using the

obtain the l ist of users on the PCAPT VMScluster sys­

CMIP-based common agent showed response times

tem, the system manager need only expand the

for equivalent operations varied from 10 to 30 sec­

''OpenV MS Accoun t s " i tem directly below it.

onds before the first user was displayed. Remaining
user accounts were also displayed more slowly, but
not as noticeably.
In the fin a l analysis, the project engineers could
have either ported an SNMP engine or corrected
the resource and responsiveness issues with the
CMIP-based common agent. However, either choice
would have required d iverting considerable project
resources for questionable payback. As a resu lt, the
prod uct developers chose to use a simple, private
request-response protocol, encod i ng the man­
agement object attributes as

type-length-value

sequences (TLVs).

Client Component
With the OpenVMS Management Station, the cl ient
is the component that d irectly interacts w i th the
system manager. As such , it is primarily responsible
for structuring the display of management i n for­

m ation and for gathering input to update such m an­
agement i n formation . This specifically i ncludes
capabi l i t ies for grouping the various OpenVMS
systems according to the needs of the system man­
ager, for participati ng i n the authentication pro­
tocol, and for displaying and updating user accou nt
information .

Participation in the
Authentication Protocol
It was an essential requ irement from the start for
the OpenVMS Management Station software to be at
least as secure as the tradi tional OpenVMS system
m a n agement tools. Furthermore, due to the rela­
tively insecure nature of PCs, the product could not
safely store sensitive data on the cl ient system. For
usab i l i ty, however, the product had to l im i t the
amount and

frequency of authentication data

the system m anager needed to present.
As a resu l t , two OMMs, the VMScl uster ami the
OpenVMS Node, store the OpenVNIS username that
the system m a n ager wishes to use when access­
ing those systems. For a given session within the
lVlanageWORKS software, the first com m u n ication
attempt to the m a n aged system resu lts in a request
for a password for that username. Once the pass­
word is entered , the client and the server perform
a challenge-response protocol. The protocol estab­
l i shes that both the client and the server know the
same password without exchanging it i n p la i n text
across the network. Only after this au thentication
exchange has successfully completed , does the
server process any management requests.
The hashed password is stored in memory at the

Grouping OpenVJ.l15 Systemsfor
Management Operations

the server connection fai ls, the c l ient attempts to

The system m anager is able to group i nd ividual sys­

silently reconnect at the next request (if a request is

tems and VMScluster systems i n to loose associa­

outstanding when the failure occurs, that request

tions cal led domains. These dom ains themselves

reports a failure). This reconnection at tempt also

client a nd used for two further purposes. First, if

may be grouped together to produce a h ierarchy.

undergoes the same au thentication exchange. If the

The system manager uses hierarchies to ind icate

hashed password is still valid, however, the recon­

the targets for a request.

nection is made withou t appare n t i nterruption or

80

vh/. 6 No. 4

Fall l'J(J4

Digital Technical journal

The Structure of the Open VMS Management Station

Ia

aa

ManageWORKS

-@ My m a n a g ement domain
-,:.» OpenVMS Accounts

®

DANA o n SYSMGT

,:.'1/4 DAVIDSON o n SYSMGT

® DCESSERVER on PCAPT
® D E FAULT on PCAPT
® D E FAULT on SYSMGT
tin� DEVARAJAN on SYSMGT
,:i:(� DFSSFS_RESD on SYSMGT
,&;1ft DNSSSERVER on SYSMGT
® DPLSSERVER on SYSMGT
,:n'Vft DQSSSERVER on PCAPT
,lfJt DOSSSERVER on SYSMGT
� DUTKO o n PCAPT
� DUTKO on SYSMGT
,:n"¥¥ DZIEDZIC on SYSMGT
tin� DZIEDZIC_N on SYSMGT

· � SYSMGT
-� PCAPT
•

A living legend [at l east in his mind) [DANA)
Stu Davidson
[DAVIDSON]
D C E Services
[DCESSERVER)
O p e nVMS provided a ccount template (USER)
OpenVMS provided account template (DE FAULT)
R. Devarajan
[DEVARAJANJ
DFS server access
[DECNET)
DNSSSERVER
[DNSSS E RVER)
DECplan Server
[DPLSSERVERJ
DOSSSERVER default a ccount
[DOSSSERVER)
DQSSSERVER d efault a ccount
[DOS SSE RVER)
Nestor Dutko [CLIENT meister)
[DUTKO)
Nestor Dutko (CLIENT meister)
[DUTKO)
Tony Dziedzic
[DZIEDZIC)
Tony Dziedzic

[DZIEDZIC_N]

,:.!} OpenVMS Accounts

Figure 3

Management Domain View

requests for inpu t from the system manager.

For instance, a l l the mail profile information is i n

Secon d , the hashed password is used as a key to

o n e window.

encrypt particu larly sensitive data, such as new

The first window to be d isplayed is the character­

passwords for user accounts, prior to their trans­

istics d isplay, which is shown in Figure 4. This w i n­

m ission to the server.

dow contains general i nformation about the user

The resu lting level of security is quite high. It cer­

that was found duri ng usability testing to be needed

tainly exceeds the common practice of remotely

frequently by the system manager. Occasional ly,

logging in to Open VMS systems to manage them.

i nformation was needed i n places that did not

Display and Update of User
Account Information

mail count" was fou nd to have two w indows: the

The OpenVMS Management Station version 1 .0

attributes, and the mail profile display.

match its internal structure . For instance, the "new
user flags d isplay, wh ich l1ad the logi n d isplay

cl ient software primari ly supports user accoun t

The OpenVMS User O M M and the zoom display

m anagement. This support is largel y contained i n

organize the attribu tes i n to logical groupings,

the OpenV MS User O M M . T h i s m o d u l e presents the

si mpl ify the d isplay and modification of those attri­

OpenVMS user account attribu tes i n a consistent,

bu tes, and provide fairly basic attribute consistency

u n ified view.

enforcement. The project team did encounter one

The main view from the OpenVMS User OMM is

case in which no standard text display proved suffi­

ca l led the zoom d isplay. This series of related win­

ciently usable. This was in the area of access time

dows d isplays and a l lows modification to the u ser

restrictions. All a ttempts to list the access times

accoun t attribu tes. The displ ays are organized so

as text proved too confusing du ring usability test­

that related attributes appear in the same window.

ing. As a resul t , the project developers produced

Digital Technical jou rnal

Vol. 6 No. 4

Fa/1 1991

81

PC LAl'l/ and System Management Tools

.!!se.name:
A!llibute(s):

r

jJJOHNSON on PSWAPhl liJ
Jr:haracteristics

I

OK
!;ancel

liJ

I

APPIJ

I

l!elp

I

IA!UIIll to AnJ
I

· contact I nformation

0)!rler:
Location:

jJim Johnson

r-----

II!;
Phone:
i �-------�����--�--�:-

1

r

s tate--

1_ @ f.nabled
0 Oisa_b_led
Account Expiration
E xpife_ On: ro lo I io

[

. ·

j200 . j4ii0

-

fHome $USERS:

I Login disk

lARGUSJ

P!iority.

I.....J

I

Advanced._ .

IX: No el!Jiiration

Accounting §.roup:
Di� I

I

Direclorv; [

f4 �

I

jJJOHNSON

I
d b
s_
Jo
_
__
o_
nt
_
._
�_
uo
_�
ta_
:_
_o
_
o_
o_
o______��
S_
P_
�
__
u�
l_
m
_c
_
k_
l :_
9_
�
l_I_
_1�----�
l __
__
Jl
_%
_

�

j

Fl�r;;;ure 4

�

User Characteristics Display

a specialized screen control that d isplayed the time

m anager cbanges these setti ngs is to accommodate

range directly, as shown i n the Time Restrictions

a new version of an application that needs increased

section of Figure 5. Later, system m a nagers who

values to fu nction correctly. Prior to the develop­

participated in the usability testing fou nd this to be

ment of t he OpenViVIS Management Station tool, the

very usable.

system manager had to locate all the users of this

The display and presentation work for the

appl ication, examine each account, and i ncrease

Open VMS User OMM was necessary for usabi l it y.

the resource quotas if they were below the appli·

However, this does not d i rectly address the need

cation's needs. Conversely, w i t h the Open VMS

to support requests against m u l tiple s i m u l t aneous

Management Station product, the system manager

targets. For the OpenVMS User O M tvl , these targets

selects the users of the application in the domain

may be either m u ltiple VMScJuster systems or inde·

display (Figure 3), and requests the zoom d isplay

pendent systems, m u l t i ple users, or a combination

for the entire set.

of either configuration with m u ltiple users.

proceeds to the user quota display and selects the

At its simplest, this support consisted of simply

triggering a request to have mul tiple targets. This is

The system

m anager then

quotas to change . The selection takes the form of
a cond i t ional request-in t h is case an At Least

done through the Apply to Al l button on any of the

condition-and the value to set. The system man­

zoom windows. By pressing this button, the system

ager then presses the Apply to All b u t ton, and

manager d i rects the updates to be sent to a l l user

the changes are carried out for all selected u sers.

accounts

Figure 6 shows the user quota display.

on

all

target systems

I isted

in

the

user name field. This action is sufficient if the sys­
tem manager is performing

a

straightforward tas k ,

Communications Component

such a s " set t hese users' accounts t o disabled." It i s

The communications component is responsible for

not sufficient in a number o f cases.

managing com munications between the client and

For example, one i n teresting case i nvolve:; user

servers. It provides support for transport-indepen­

account resource quotas. One reason a system

dent, request-response com munications, automated

82

Vol. 6 No. 4

Fall 1994

Digital Technical journal

The Structure of the OpenVMS JV/anagement Station

IJJOHNSON on PS\IIAPM l!J
ITi'!'e Restrictions
liJ

ll.serna-:
Altribute(s):

Cancel

I AllJ)Iy to Alii
I
I
11�

S-econdary Days

PriiRart. Days

Saturday
Sunday

Monday
Tuesday
Wednesday
Thursday
Friday

r- R estricrrona-- ---------·-·----..·---·- ..----·--- -Primary Day Acces:s
Processing Mode - .

�)

....

0 Jl.atch
0

I

;f"''"'!�:l
-=..;.=!!"i''
� �-+
�! ���

.!..ocal

fletwork

S.a.condary Day Accen:

Djalup

I

3AM

0 Remote

I

Figure 5

I

$AM

I

9AM
I

I

Noon

I

3PM
I

I

6PIVI

9PM

.

I

User Time Restrictions Display

jJJOHNSON on PS\IIAPM L!J
jQuotas

Albilute{s):

I

IA
I

y

li

wl to A i
l!elp

I

Quota Calegoor.

Virtual Memory

lEqual to
liJ (
l.uffered 10:
1���ual t()
liJ J
lEqual to
Bt.tta
l!J J
1 12_irect 10: IEqu�l to
liJ I
�Equal to
EM.Q. Lillit:
liJ J
Open file Lilllil: JEqual to
l!J I
I
lob Logicals: 1 Equal to
t!J I
qu_a_
l_
to--..;:l!J
Jr-E::::; j
TQE Limit:
A£T Linlit:

i'

Figure 6

D igital Teclmicaljourual

Vol. 6 No. 4

Fal/ 1')94

11
1 00 : 11
955 36 11
1 00 11
2ooo 11
200 11
4096 · 11
1 2a 11
325 ·

Use1· Quota Display

83

PC LAN and System Management Tools

reconnection on failure, and support routines for

updates the collection of systems that are to receive

formatting and decoding attribu tes in messages.

any fu ture management requests. Assuming this

Because of the request-response nature of the

was successful, the OMM then begins the request

com m u n ications, the project tea m 's first approach

processing by retrieving the version number for the

was to use remote proced u re cal l s for comm u n ica­

current forwarding server. Based on that, the OMM

tions, using DCE's remote procedure cal l (RPC)

then formats and issues the request. Once the

mechanism . 5 This matches the message traffic for

request has been issued , the OMM perioclically

the degenerate case of a single managed syste m .

checks to see if either the response has arrived or

Management o f mul tiple systems can easily be mod­

the system manager has cance led the request. Upon

eled by adding a continuation routine for any given

arrival of the response, it is retrieved and the mes­

management service. This routine returns the next

sage data decoded.

response, or a "no more" indication .
The RPC mechanism a lso hand les m u ch of the

To perform this messaging sequence, the OMM
uses a pair of interfaces. The first i s used to estab­

basic data type encoding and clecocl ing. A form of

l ish and maintain the collecti o n of systems that are

version support a l lows the services to evolve over

to receive any management requests. The second

time and sti l l i n teroperate with previous versions.

i nterface, which is compatible with X/Open 's XTI

The project team's eventual decision not to use

standard, is used to issue the request, determine if

DCE's RPC was not due to techn ical concerns. The

the response is available, and to retrieve it when

technology was, and is, a good match for the needs

it is 6 A third interface that supports the encodi ng

of the OpenVMS Management Station software.

and decodi ng of message data is described i n a fol­

Instead, the decision was prompted by concerns

lowing section.

for system cost and project risk. A t the time, both
the Open VMS Management Station product and the
OpenVMS DCE port were u nder development . The
DCE on Open VMS product has since been del ivered,
and many of the system cost concerns, such as
the l icense fees for the RPC run time a nd the need
for non-OpenVMS name and security server sys­
tems, have been corrected.
In the end, the OpenVMS Management Station
software contained a com m u n ications l ayer that
h i d many of the details of the underlying implemen­
tation, offering a simpJe request-response para­
digm. The only d ifference with an RPC-style model
is that the data encodi ng and decoding operat ions
were moved into support routines called directly
by the sender or receiver, rather than by the com­
mun ications layer itsel f. In future versions, the goal

for this l ayer is to support add itional transports,

such as simple Transmission Control Protocol/
I nternet Protocol (TCP/ l P) messages o r DCE's RPC.

An i nvestigation i n to providing additional trans­

ports is currently u n der war
The remainder of this section describes the com­
munications layer in more deta i l , includ ing the
mechanisms provided to the cl ient OMMs, how
reconnection on fail u re operates, and the message
encoding and decoding support routines.

Reconnection on Failure
The

OpenVMS

Management

Station

product

a t tempts to recover from com m unications fai l ures
with l i t t le d isruption to the system m a nager
through the use of an au tomated reconnection
mechanism . This mechanism pl aces constraints on
the behavior of the request and response messages.
Each request must be able to be issued after a recon­
nection. Therefore, each request is marked

as

either

an initial request, which does not depend on server
state from previous requests, or as a continuation
request, which is used to retrieve t he second or
later responses from

a

m u ltiple target request and

does depend on existing server state.
If an existing com mun ications link fai ls, that l i n k
is marked as u nconnected. If a response were
outstan ding, an error would be returned instead of
a response message. \Vhen the com munications
l ayer is next called to send a request across the
u nconnected l in k, an automated reconnection is
attempted. This i nvolves establishing a network
connection to a target system in the request. Once
the connection has been established, the au thenti­
cation protocol is execu ted, using the previously
supplied au thenticat i o n data. If au thentication
succeeds, the request is sent. If i t is a continu at ion
request, and the target server has no existing state

Client Request-response Mechanisms

for that request, an error response is returned .

The OMMs in the c l ient system c a l l the com m u n ica­

At most, the resu lting behavior for the system

tions layer directly. To make a request, an OMM first

manager is to return an error on a management

84

Vol. G No. 4

Fall 1994

D igital Tecbnicaljournal

The Structure of the OpenVMS Management Station

request, i nd icating that com m u nication was lost

a status code indicating if the attribute was present

d uring that request's execution . I f n o request was

in the message buffer. The client uses t h is routine

in progress, then there is no apparent disruption of

to locate data i n a response. The third routine takes
a message buffer, a table l isting the attribute codes

service.

that are of i nterest to the cal ler, and an action rou­

Message Encoding and Decoding
Messages from the OpenVMS Management Station
tool are d ivided i n to three sections. The first sec­
tion contains a message header that describes the

tine that is called for each message item that has an
attribute code fou n d i n the table. The server OMMs
use this rout i ne to process incoming requests.

length of the message, the protocol version number

Handling of Complex Data Types

i n use, and the name of the target OMM. The second

I n general, the i nterpretation of data between the

section contains the col lection of target systems for

client and server systems did not pose a s ignificant

the request. The third secti o n contains the data

concern. There was no floating-point data, and the

for the OMM. This last section forms the request and

integer and string data types were sufficiently simi­

is the only section of the message that is visible to

lar not to require special treatment. However, the

the OMMs.

OpenVMS Management Station software did need

The OMM data for a request is typicall y con­

a few data types to process that were not simple

structed as a command, fol lowed by some numbe r

atomic values. These required special processing to

o f attributes a n d com mand qualifiers. For instance,

a request to l ist all known users on a system, return­

hand le. This processing typically consisted of for­
m a t ting the data type into some i ntermediate for m

i ng their usernames and last login t i me , could be

t h a t b o t h client a n d server systems could d e a l with

described as this:

equ a l l y wel l .

COMMAND
MO D I F I E R
ATT R I BU T E S

stamp. In the OpenVMS operating system, times
are stored as 6 4-bit quadword values that are

L I ST USERS
USERNAME =
USERNAME,
LAST LOG I N

For instance, one such d a t a t yp e is t h e time­
"*"

TIME

100 -nanosecond offsets from m id n ight, November

The OMM data for a response is typically a status
code, the l ist of attributes from the request, and the
attri butes' associated values. There may be many
responses for a single request. Using the LIST_USERS
example from above, the responses wou l d each
look l ike a sequence of:
STATUS
ATTRI BUTES

SUCCESS
U S E R N A M E (  )
L A S T LOG I N T I M E (  )

There are many possible attributes for an OpenVMS

18, 1858. This is not a natural format for a Microsoft
Windows client. Date and time display formats vary
greatly dependi ng on local ization options, so the
data needed to be formatted on the local c l ient. The
developers used an approach that decomposed the
native OpenVMS time into a set of components, sim­
i lar to the output from the $ !\TlJMTIM system or the
UNIX tm structure . This decomposed time struc­
ture was the format used to transmit t imestamp
i nform a tion between the client and server.

user. To m ake later extensions easier and to limit

Server Component

the number of at tributes that must be retrieved

With the OpenYMS Management Station product,

or updated by a request, the OMM data fields are

the server component is responsible for enacting

self-describing. They consist of a sequence of mes­

management requests that target its local system.

sage i tems that are stored as attribute code/item

The server also must forward requests to a l l other

length/item value. The base data type of each

VMScluster systems or independent systems that any

attribute is known and fixed.

incoming request may target. The server is a m u lti­

Message encod ing is supported by a set of rou­

threaded, privileged application running on the

tines. The first accepts an attribute code and its

managed OpenVMS systems. I t consists of an i nfra­

associated data i tem. I t appends the appropriate

structure layer that receives incoming requests and

message item at the end of the currem message.

dispatches them, the server OMMs that enact the

This is used to encode both requests and responses.

management requests for the local system, and a for­

The second rou tine takes a message b u ffer and an

warding layer that routes management requests to

attribute code, returning the attribute's value and

other target systems and returns their responses.

Digital Teclmicaljournal

Vol. 6 No. 4

Fall 1994

85

PC LAN and System Management Tools

Server Infrastructure

development and testing p h ases of the project, a n d

The server i nfra s t r u c tu re, shown in Figure 7, is

t h e n u m ber o f wo rker t h reads w a s kept at five.

responsible for d i s p a t c h i n g i ncom i ng requests to

In a d d i t i o n to the basi c t h read s t r u c ture , t h e

the server O M M s and the fo rward i ng layer. I t has a

i n fras tructu re is respo nsible fo r participating i n the

set of t h reads, one fo r each i n bo u n d connec t i o n , a

a u t h e n t ic a t i o n exchange fo r i n b o u n d c o n n e c t i o n s .

p a i r of wo r k qu eues t h a t b u ffe r i n d i v i d u a l re quests

T h i s is acco m p l i shed t h rough t h e use of a speci al­

and resp o nses, and a l i mited set of wo rker t h reads

i zed server OMM, cal led S p o o k . The Spook OMM

that e i t h e r call the a p p ropriate Oi\'I M or fo rward the

uses t h e basic s erver i n frast r u c t u re to e ns u re t h a t

request.

a u t h e nt i c a t i o n requests a r e fo rwarded t o t h e appro­

The i n b o u n d connection t h reads are responsible

p ri a te target system . This m e c h a n i s m reduced t h e

fo r ensuring t hat t h e request i d e n tifies a known

a m o u n t of s p e c i a l ized logic n e e d e d fo r t h e a ut h e n ­

OMM and meets i t s message requ i rem e n t s . The

tica t i o n p rotocol : fo r t h i s reason, t h e server O M M s

connec t i o n t h reads m u st a l so e ns u re t h a t t h e OM M

m ust declare i f they requ ire an a u t h e n t icated l i n k
before accept i ng a n i n c o m i n g request.

version n u m be r is w i t h i n a n acceptable range and
t hat t h e l i n k

is s u ffi c i e n t l y a u t h e n t i cated .

i n b o u nd threads are then

The

Server OMM Structure

resp o nsible fo r re pli­

cating the request and placing requests t h a t have

The s e rver o:vi:VJs a re at the heart of the server.

o n ly one target system in the requ est wo r k q u e u e .

These Oi'vl. 'vls are loaded d y n a m i c a l ly w h e n t h e

O n c e a response appears i n t h e response wo rk

server i n i t i a l izes.
Figure H shows the structure of the liAServer 0;\1 i'vl

queue, these t h reads ret u rn the response to the

i n Openv:vJS Management Station version 1 .0. 'fhe

c l i e n t syste m .

A fixed n u mber o f worker t h reads are res p o n s i ­

server OMM consists of the m a i n a p p l ication m od­

ble fo r t a k ing messages from t h e r e q u e s t work

u l e, t he preprocessing rou t i ne, and the postprocess­

q u e u e and either fo rwarding them o r cal l ing the

i ng routi n e . The i nte rfaces are synchronous, passing

a p p ropriate local O M M . Each resu l t i s pl aced i n t h e

OMi'vl (la ta sections from t he request and response

response q u e u e a s a response m essage. A fixed

message bu ffers. I n a d d i t i o n , the m a i n appl ica t i o n

n u m be r o f five worker t h reads was chosen to

m o d u l e executes i n t he s e c u r i t y context, c a l led a

ensur e t h a t messages wi t h m a n y t a rgets co u ld n o t

persona, of the authent icated c a l l er. Th i s a l lows n o r­

exh a u s t the server's resources. Responsiveness and

m a l access chec k i ng a n d a u d i t i ng i n the O p e nVMS

re so urce u s age were acce ptable throu g h o u t the

operating system to work transpare n t ly.

OUTGOING
REO� =�T-

I
I

_ _ _

I
I
I

FORWARD
__R_EQ
ES_T _
U_
_ IS TARGET
_
LOCAL?
'\ REQUEST WORK QUEUE
/
YES

WAIT FOR
RESPONSE

_ _ _ _

INCOMING
RESPONSE I

T

_..

OMM

REQUEST

_

_

_

_

_

_

_

_

_

_

Figure 7

R

J

1

I

I
I

WAIT FOR
NEXT
R

/I llll llll l � REQUEST
MATCH RES>O NSE TO

FIVE WORKER THREADS

[

I ---""'11[ - -

STALL
THREAD

_______.., / RESPONSE WORK QUEUE

I

L

/

1 111111111 I l

r---,/
"'
SERVER
GET NEXT

I

[ INCOMING
REQUEST

LOOK UP OMM NAME
ATIACH AUTHENTICATION
CONTEXT TO REQUEST
E
L T
��� ��� iA���� iJi�M

_

�::::

O,NG
- - rI RESPONSE
- - - .I

SEND RESPONSE

I

ONE THREAD PER CONNECTION
_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

[

_

_

j

Seruer Infrastructure and il1essage Flou•

H>i. (j

No. 4

Fall /')';)4

Digital Tecbuical jo urnal

The Structure of the Open VMS Management Station

YES
NO

RESOURCE
MANAGERS

APPLICATION
LL
(/)
w
...J
u::

>X
0
rr:
a..

w
u
z


.Vo. 4

F(ll/ 199 1

97

PC LAN and System Management Tools

Ta ble 2

Na ming Conventions Used by ISL Resou rces

Name
RSM$1SL_INSTALL-opera. EXE

Description
Shareable image conta i n i n g the ISL D i rector routines, w h i ch runs on
the POLYC ENTER Software Distribution server (running OpenVMS).

RS M$1SL_LAA-opera. EXE

Shareable image conta i n i n g t h e load assist agent, which runs on
the POLYC ENTER Software Distri bution server (ru n n i n g OpenVMS).

RS M$FETC H-opera . DSK

Container f i le conta i n i n g t h e fetch toolkit, which resides on the
POLYCENTER Software Distri bution server syste m (ru n n i ng OpenVMS)
but is read o n l y by the c l i e nt system.

RSM$F ETCH_server-opera

LAD service name for the fetch toolkit, which i s served by the
POLYC ENTER Software Distribution server (ru n n i n g OpenVMS)
to the client.

RSM$1SL_BO OT-opera. COM

Command proce d u re responsi ble for actua l l y perfo r m i n g the save
of t h e operating system software from the client's system d isk to
the virtual d i sk, which runs on the c l i e n t system.

RSM$SDS_OS_LIBRARY:
[opsys.OPERSYS]SYSO. DS K

Container file for the fetched operating system, which resides on
t h e PO LYC ENTER Software Distribution server system (ru n n i ng
Open VMS).
(T his d i rectory may also be used to store the bytes of the processor­
specific bootstrap i mage so t h e load assist agent has easy access.)

RSM$1SL_server-opsys

LAD service name of the te mporary system disk conta i n i ng the
fetched operating system i mage, which is served from t h e
POLYC ENTER Software D i stribution server syste m (ru n n i n g
OpenVMS) t o t h e cl ient syste m.

RSM$1SL_STARTUP-opera.COM

Command proc edure responsi ble for actually del ivering the operat­
ing system software from the temporary system d i s k to t h e target
system d isk. It runs on the c l ient system but is booted from t h e
tem porary system d i sk.

RSM$1SL_CLEANU P-opera .COM

Command proce d u re for removing custom i zations specific to t h e
i n i tial system load from a tem porary system d i sk. I t runs on the c l i ent
system but is booted from the temporary syste m d isk.

RSM$1SL_server

LAD service name of the VAX "boot container'' for operati ng systems
fetched prior to version 3.0, which is served from the POLYCENTER
Software Distribution server system (ru n n i ng OpenVMS) to the client
system (which i n this case must be ru nning OpenVMS VAX or VAX VMS).

RSM$1SL_server_EVMS

LAD service name of the AXP "boot container" for operating systems
fetch e d pri o r to version 3.0, wh ich i s served from the POLYCENTER
Software Distribution server system (ru n n i ng OpenVMS) to the c l ient
system (wh ich in t h i s case must be ru n n i n g OpenVMS AXP).

system , and the term opsys identifies the user­
defi ned pseudonym for the fetched operating sys­

The pertinent fields of the QENTRY data structu re
passed to RSM$ISL_FETCH are

tem i mage.

T h e ISL Director

char

p s e udonym [ 6 4 J ;

c h a r

c l i e n t_n o d e [ 1 2 8 J ;

char

L i b r a r y _n o d e [ 1 2 8 J ;

char

o p e r a_h o u s e [ 8 J ;

The ISL D irector is a shareable i m age activated by

LIB$FIND_IMAGE_SYJVIBOL; therefore i t need not
have transfer vectors, as long as the two requ i red
entry poi nts are declared UNIVERSAl. These two
routines are c a l led in user mode. They are passed
a s ingle parameter, the address of a data structure
called the QENTRY.

98

Vol. 6 No. 4

Fall 1994

D igital Tec!Jnical journal

Automa tic, Network-directed Operating System Software Upgrades

and the pertinent fields of the QENTRY data struc­

store the bytes of the operati ng system 's primary

ture passed to RSMSISL_INSTALL are

bootstrap i m age for fu ture access by the LA A.

cha r

e t herne t [ 1 9J ;

T he Load Assist A gent

char

c l i e n t _n o d e [ 1 2 8 J ;

The LA A delivers the bytes of the processor- specific
primary bootstrap image to the c l ient system. The
MOM process activates this shareable image dynam­
c h a r

L i b r a r y_no d e [ 1 2 8 J ;

ically,

but

not using LIB$FIND_IMAGE_SYMBOL.

Therefore, the one requ ired entry point to this
char

o p e r a_ h o u s e [ 8 J ;

image must occur a t offset 0000 in the image. (The
name of the entry point is unimportant.) This is

In both rout ines, the field cal led opera_house con­
tains the symbolic name of the operating system
(e.g. , AVMS).
RSM$ISL_F ETCI-I is

responsible fo r copying a

bootable snapshot of the client's system disk i nto
the LAD container fi le SYSO. DSK. The LAD virtual
d isk should be organized into the n a t ive format of
the operating system being fetched. The server sys­
tem w i l l never attempt to read these files. To the
server system, tbis container is simply a large series
of bytes, whose meaning (to the c l ient system) is
unimportant. This routine is responsi ble for obtain­
ing the size of the con tainer file to be created,
creating that container file, and then serving it,
writeable, to the LAD. Once the fetch operation has
concluded, the container shou ld be served again i n
read-only fo rmat.
RSMSISL_INSTALL is responsible for enabling the
LAA for the new c l ient system . Si nce the LA A ru ns
under the MOM process, which is a non-POLYCENTER
Software Distribution environ ment, this routine
should a lso col lect any and all i n.formation (such
as the DECnet node name and address of the server
system) needed by the LAA, and store that infor­
m ation in the file RSJ'-•1$SDS_WORK:ISL_cl ient. DAT.
The conten.t of this file is shared only between
RSM $!SL_INSTALL and the LAA; therefore, the format

best accompl ished using a single transfer vector.
This rou ti ne is caJJed in user mode with three
parameters, the addresses of three data structures:
the MOMIDB, the MOMARB, and the MOMODB.
The offset MOMI D B$A_PARAM_DSC contains any
text from the NCP load assist parameter field . T h is
field contains arbitrary text that RSM$JSL_!NSTALL
placed there. Normal ly, this field contains a handle
used to

retrieve

the file

RSM$SDS_WORK: ISL_

client.DAT. A good handle is the DECnet node name
of the client system.
The offset MOMARB$A_SEND_DATA is the address
of a routine to deliver data to the cl ient. The LAA
need only col lec t and/or generate the data to be
del ivered to the c l ient; t h is cal l back routine del iv­
ers i t to the client. Its two parameters are a string
descriptor identifying which and how many bytes
are to be del ivered, and the relative address in the
client's memory to place these bytes. T h is ca l l back
routine may be ca.l led repetitively.
The offset MOMODB$ L_TRANSFER_ADORESS must
be fil led with the relative transfer address of the pro­
cessor-specific bootstrap image that was loaded into
the c lient's memory by MOMARB$A_SEND_DATA. For
OpenVMS VAX , this offset is trad itionally zero,
because certain older VAX processors are not capa­
ble of using any other value. That is one reason why

of the file is implementation-dependent.

the transfer address for ISL_SVAX.SYS is always zero.

T h e Fetch Toolkit

Summary

The fetch toolkit is a lso a LAD virtual disk organized

The

in a format that is native to the cl ient's operating

upgrades operating system software. These simple

system. Again, the server system wi l l never read

descriptions provide the framework for expaneling

ISL

mechanism

i nstal ls,

maintains,

and

this virtual volume. This virtual vol u me contains

the ISL process i mplemented i n the POLYCENTER

the native operating system pieces necessary to

Software D istribution version 3.0 product to plat­

save a snapshot of the model system disk, make i t

forms other than Open VMS VAX and OpenVMS AXP

bootable as the temporary system disk, and restore

operating systems. This expansion can m ake work

it to its original state These are usually three sepa­

easier for system m anagers of m u l t iple plat forms

rate com mand procedures. The com mand proce­

and may even start a de facto standard for perform­

dure that saves the system d isk image must also

ing operating system upgrades.

D igital Tee/mica/journal

Vol. 6 No. 4

Fall 1994

99

PC LAN and System Management Tools

Acknowledgments

product. The installed software continues to use

I wou ld l i ke to t hank Richard Bishop and CharJ ie

its traditional acronym RSM .

Hammond in the OpenVMS AXP Development
Group for al lowing me to un ify the POLYCENTER
Software Distribution version 3.0 ISL and the PCST­
based Open VMS AXP version 6.1 upgrade.

Note and References
I . POLYCENTER Software Distribution is the new

name for Digital 's Remote System

1 00

Manager

2. POLYCENTER Software Distribution Manage­

ment Guide (Maynard , MA: D igital Equipment

Corporation, Order No. AA-JG05E-TE, May 1994).

3. POl.YCENTER Software Distribution Command
Reference (Maynard, MA D igital Equipment
Corporation, O rder No. AA-JG03E-TE, May 1994).

Vol. 6 No. 4

Fall 1994

Digital Tecbnical jourual

I

Further Readings

The fol lowing technical p a pers were written by

A. john, " Dynamic Vnodes: Design and Imple­

Digital au thors:

mentation," USENIX 1995 Technical Conference

R. Abugov and K. Zin ke, "Wafer Level Tracking

(January 1995).

on UNIX and Advanced Comp uting Systems
Enhances Particle Source Isolation i n a Manu­
facturing Environment,'' Fifth A nnual IEEE!SEMI

D. jones and V Murthy, "Ad vancing Re liabi l i ty

Advanced Semiconductor klanujacturing
Conference and Workshop (November 1994).

with State of the Art Software Tools," University

.J. Card, A. McGowan , and C. Reed, " Neural Network

(December 1994) .

of Manchester School of Engineering Third
Reliability Software Seminar and Workshop

Approach to Automated Wirebond Defect Classifi­
cation," ASJlt!E Proceedings of the Artificial Neural

N. Khalil, ). Faricel li, and D. Bell, "The Extraction

Networks in Engineering (ANNIE '94) Conference

of Two-Di mensional MOS Transistor Doping via

(November 1994).

Inverse Modeli ng,'' IEEE Electron Device Letters
(January 1995).

S. Cheung, D. jensen , and G. Mooney, "Ul tra-High
Purity Gas D istribution Systems fo r Sub O.Su m ULSI
Manufacturing," Fifth A n nual iEEE/SEMI Advanced

Semico nductor Manufacturing Conference and
Wo rkshop (November 1994).
R. Col lica, B. Cante l l , and J Ramirez, "Statistical
Analysis of Particle/Defect Data Experiment Using
Poisson and Logistic Regression," IEEE Interna­
tional Wo rkshop on Deject and Fault Tolerance
in VLSI Systems (October 1994).
B. Doyle, K. Mistry, and C-L. Huang, ·'Analysis of
Gate Oxide Th ickness Hot Carrier Effects in Surface
Chan nel P-MOSF ETs;· iEEE Transactions on

Electron Devices (January 1995).

A. Labun, " Profile Simu lation of Electron Cyclotron
Resonance Planarization of an Interlevel Dielectric,"

journal of Vacuum Science and Technology B
(JVST B) (November/December 1994).
K. M istry and B . Doyle, " How Do Hot Carriers

Degrade N-Channel MOSFETs? ," IEEE Circuits and

Devices (January 1995).
C. Ozveren , R. Simcoe , and G. Varghese, " Rel iable
and Efficient Hop-by-Hop Flow Contro l ," AC111 SIG­

COJHM 94 (October 1994).

R . Razdan and M. Smith, "A H igh-Performance
Microarchitecture with Hardware-Progra mm able

). Edmondson, "Internal Organization of the Alpha
2 1 164," iEEE First International Symposium on

High-jJelt'ormcmce Computer Architecture (HPCA)
(January 1995).

Functional Units," Proceedings of the Twenty­

seventh Annual International Symposium on
Microarchitecture (MIG"R0-27) (December 1994).
R. Rios and N. Arora, "Determ i nation of Ultra-Thin

L. Ell iott, D. Paine, and ). Rose, "The Microstructure
and Electromigration Behaviour of AJ-0. 35%Pd
Interconnects,'' Materials Research Society
SymjJosium Proceedings: Materials Reliability
in Microelectronics IV Symposium (April 1994).

Gate Oxide Thickness for CMOS Structures Using
Quantum Effects," IEEE International Electmn
Devices Meeting/IEDM Technical Digest
(December 1994).
N. Sul livan, "Semiconductor Pattern Overlay,"

C. Gordon and K. Roselle, "An E fficient and Accu­
rate Method for Estimating Crosst a l k in M u l ticon­
ductor Coupled Transmission Lines," IEEE Third

Topical Meeting on the Electrical Performance
of Electronic Packaging (November 1994).

Proceedings of the International Society of
Photo-Optical Instrumen tation Engineers (SPIE)
Microelectronic Processing: Integrated Circuit
Metrology and Process Control (Critical Review)
(September 1994).

D. Heimann , " Using Complexity-Tracking in the

B. Thomas, "OpenV M S I/O Concepts: CSR Access;'

Software Development Process,'' Thirty-second

Digital Systemsjournal (November/December

Annual Spring Reliability Symposium (April 1994)

1994).

Digital Techllical]ow-nal

VrJI. 6 No. 4

Fal/ 1994

101

I

Recent Digital US. Patents

Thefollowing patents were recent�v issued to Digital Equipment Corporation. Titles and names supplied
to us by the US. Paten t and Trademark Office are reproduced exactly as they appear on the originalpub­
lishedpatent.
5,208,692

D. McMahon

H igh Bandwidth Network Based on Wavelength Division
M u ltiplexing

5,208,768

E. Simoudis

Expert System Including Arrangement for Acquiring Redesign
Knowledge

5,210,854

A. Beaverson and T. H u n t

System for Updating Program Stored i n EEPROM by Storing
New Version i n to New Location and Updating Second
Transfer Vector to Contain Star t i ng Address of New Version

5,210,865

S. Davis, W Goleman, and
D. Thiel

Transferring Data between Storage Media While Main taining
Host Processor Access for 1/0 Operations

5,217, 198

V Samarov, W Paupl is, and

Uniform Spatial Action Shock Mou n t

G. Doumani

5,218,678

B. Kelleher and S-S. Chow

System a n d Method for Atomic Access t o an I npu t/Ou tpu t
Device with Direct Memory Access

5,220,661

]. Wray, A. Mason, P Karger,
P Robinson, W-M . H u , and
C. Kahn

System and Method for Reducing Tim i ng Channels in D igital
Data Processing Systems

5, 224, 206

E. Simoudis

System and Method for Retrieving .Justifiably Relevant Cases
from a Case L ibrary

5,224,884

M . Singer, R . Noffke, and
D. G i lmour

High Current, Low Vol tage Drop Separable Connector

5, 233,684

R. Ulichney

Method and Apparatus for Mapping a Digital Color I m age from
a First Color Space to a Second Color Space

5,235,697

S. Steely and ]. Zurawski

Set Prediction Cache Memory System Using Bits of the Main
Memory Address

5,239,634

B. Buch and C. MacGregor

Memoqr Control ler for Engineering/Dequeu ing Process

5, 239,637

S. Davis, W Goleman, and
D. Thiel

D igital Data Management System for Maintaining Consistency
of Data in a Shadow Set

5,241 , 564

J. Tang and J.L. Yang

Low Noise, High Performance Data Bus System and Method

5,242, 761

Y Uchiyama

Magnetic Recording Medi u m and Method of Manufacture
Thereof

5,243, 241

C-H. Wang

Tota lly Magnetic F i ne Tracking Min iature Galvanometer
Actuator

5, 247,464

R. Curtis

Node Location by D i fferential Time Measurements

5,247,618

S. Davis, W Goleman , D. Thiel,
R . Bean , and ]. Zahrobsky

Transferring Data i n a D igital Data Processing System

5,251 , 147

]. F i nnerty

Minimizing the Interconnection Cost of E lectronically Linked
Objects

5,251 , 2 27

T. Bissett, W Bruckert,
]. Munzer, D. Kovalci n , and
M. Norcross

Resets for a Fau l t Tolerant, D u a l Zone Compu ter System

5,253, 249

]. F itzgerald and D. Shuda

Bid irectional Transceiver for H igh Speed Data System

5,253,353

].C. Mogul

System and Method for Efficiently Supporting Access to 1/0
Devices through Large Direct-mapped Data Caches

5,257,264

H . Yang and
K . K. Ramakrishnan

Automatically Deactivated No-owner Frame Removal
Mechanism for Token Ring Networks

5, 261 ,077

J . R . D uval, K . R . Peterson,
and T. E. H u n t

Configurable Data Path Arrangement for Resolving Data Type
Incompatibility (This case is related to PD89-0300.)

1 02

Vol. 6 No 4

Fall 1994

D igital Technical journal

I
') , 26 1 ,OH'5

LB. Lamport

Fau lt- tolerant System and Method fo r Implementing a
Distributed State Machine

'5, 26'5,092

S. R. Soloway, A . G. Lauck, and
G. Ve rghese

Synchronization Mechanism for Link State Packet Routing

'5,26'5, 2'57

R .J. Simcoe aml R. E. Thomas

Fast Arbiter Having Easy Sca l i ng for Large Numbers of
Requesters, Large Numbers of Resource Typ es with Mu ltipl.e
Instances of Each Type and Selectable Queueing Discipl ines

'),274 ,H l l

A. Borg and D.W Wal l

Method for Quickly Acquiring and Using Very Long Traces
of M ixed System and User Memory References

'5, 276, 7 1 2

] . D. Pearson

Method and Apparatus for Clock Recovery in D igital
Com mu nication Systems

'5, 276,809

.f. K . Grooms, R . L. Sites,
L.A. Chisvin , and OW Smelser

Method and Apparatus for Capturi ng Real-t ime Data Bus
Cycles in a Data Processing System

5, 276,828

J Dion

Methods of Maintaining Cache Coherence and Processor
Synchronization in a M u lt iprocessor System Using Send ami
Receive Instructions

'5, 276, 8 5 1

C. Thacker and D. Conroy

Automatic Writeback and Storage Limit in a High-performance
Frame Bu ffer and Cache Memory System

'5, 276,874

R.G. Thomson

Method for Creating a Directory Tree in Main Memory Using
an Index F i le in Secondary Memory

5, 278,974

R. Ramanujan, PJ Lemmon ,
and .J.C. Stickney

Method and Apparatus for the Dynamic Adjustment of Data
Transfer Timing to Equa l i ze the Bandwidths of Two Buses i n
a Computer System Having Different Bandwidths

5,2H0.47H

H . Yang, PW C iarfella,
K.K Ramakrishnan

No-owner Frame and Mul tiple Token Removal Mechanism for
Token Ring Networks

'), 280, ')75

C . A . Young and N.F jacobson

Arraratus for Cel l Format Control i n a Spreadsheet

5, 280,'582

H. Yang, K . K . Ramakrishnan.
and A. Lauck

No-owner Frame and Multiple Token Removal fo r Token Ring
Networks

'5,280,627

j. E. Flaherty and A . Abrahams

Remote Bootstrapping a Node over Com munication Link by
Initially Requesting Remote Storage Access Program Which
Emu lates Local Disk to Load Other Programs

'),28:1,857

E. Simou d is

Expert System Including Arrangement for Acquiring Redesign
Knowledge

S.C. Steely and D.J Sager

Next Line Prediction Apparatus for a Pipeli ned Computer
System

'),287, 1:)8

B .iVI. Kel leher

System and Method for Drawing Anrial iased Polygons

5, 287,48')

L. Umina and R. Anse lmo

Digital Processing System I ncl.uding Plural Memory Devices
and Data Transfer C i rcuitry

5, 287, 5:)4

T Reuther

Correcting Crossover D istortion Produced When Analog
Signal Thresholds Are Used to Remove Noise from Signal

T. Bissett, W Rruckert, and

Method of Hand l ing Errors in Software

W Barabash and

Method and Apparatus for Sched u ling Tas ks in Repeated
Iterations in a D igital Data Processing System Having Multiple
Processors

'),291 ,494

'5, 293,620

.J. Melvin

WS. Yerazunis

'5, 296,:)92

'5, 297. 269

G.J. Gnl l a ancl W.C. Metz
D. Donaldson , M. Howard ,
D. Orbi ts, ). Parchem,
D. Robinson, and D. WiLliams

Digital Technical journal

Vol. 6 No. 4

Fall 1994

Method for Forming Trench Isolated Regions with Sidewa l l
Doping
Cache Coherency Protocol fo r M u l t i Processor Computer
System

1 03

Recent Digital US. Patents
5,298,464

RW Doe, R . D. Gates,
D.P. Goddard, S.C. Hsu, and
R.L. Schlesinger

Method of Manufacturing Tap e Automated Bonding
Semiconductor Package

5,301 , 327

W McKeeman and S. Aki

Virtual Memory Management for Source-code Development
System

5,303,382

B. Buch and C. MacGregor

Arbi ter with Program mable Dynamic Request Prioritization

5,303,391

R . .J. Simcoe and R.E. Thomas

Fast Arbiter Having Easy Scal i ng for Large Numbers of
Requesters, Large Numbers of Resource Types with M u ltiple
Instances of Each Typ e and Selectable Queueing Disciplines

5,313,387

WM. McKeeman ami S. Aki

Re-execution of Edit -compile-run Cycles for Changed Li nes of
Source Code, with Storage of Associated Data in Buffers

5,313,464

F.H . Reiff

Fau lt To lerant Memory Using Bus Bit AJ igned Reed-Solomon
Error Correction Code Symbols

5,313,641

R.]. Simcoe and R . E. Thomas

Fast Arbiter Having E asy Scaling for Large Numbers of
Requesters, Large N u mbers of Resource Types with M u l tiple
I nstances of Each Type and Selectable Queueing Disciplines

5,315,480

V Samarov, G. Doumani, and

Conformal Heat Sink for Electronic Module

R. Larson

5,317,708

R . Edgar

Content Addressable Memory

5,319,651

R . Hel liwel l, R. Lary, B. Edem,
and J.Johnston

Data Integrity Features for a Sort Accelerator

5,32 1 , 724

B. Long and M .]. Hynes

I nterference Suppression System

5,321 ,841

M.C. Ozur, S.M. Jenness,
).W Kel ly, J). Wal ker, and
).A. East

Server Impersonation of C l ient Processes in an Object-based
Compu ter Operating System

5,325,531

WM. McKeeman and S. Aki

Incremental Compiler for Source Code Development System

5,327, 368

R . A . Eustace and ].S. Leonard

Chunky Binary M u l t iplier and Method of Operation

5,327,557

J.P. E m m ond

Single-keyed Indexed File for TP Queue Repository

5,330,881

A. Sidman and S. Fung

Microl ithographic Method for Producing Thick Vertically
Wal led Photoresist Patterns

5,337,404

P. Beaudelaire, M. Gangnet,
J Herve, T. Puder, and
J.V Thong

Process for Making Computer-aided Drawings

5,339.449

P.A. Karger, A. H. Mason,
JC . R . Wray, P.T. Robinson ,
A.L. Priborsky, C . E. Kahn,
and T. E. Leonard

System and JVIethod for Reducing Storage Channels in Disk
Systems

5,345,587

L . G. Fehskens, C. Stru tt,
S. Wong, J. F. Callander,
P. H . Burgess, K.J Nelso n ,
M .]. Guerti n , D.L. Smith,
M W Sylor, K W Chapman,
R.C. Schuchard , S. I . Goldfarb,
R . R. N. Ross, LB. O 'Brien,
P.). Trasatti, D.O. Rogers,
B . M . England, ].L. Lemm o n ,
R.L. Rosenbau m , and
additional i nventors

Extensible Entity Management System Includ ing a Dispatch ing
Kernel and Modu les Which Independently I n terpret and
Execute Commands

5,345,588

R . Peterson, B . Schreiber,
and S. Greenwood

Thread Private Memory Storage for M u ltithread Digital Data
Processing

1 04

Vol. G No. 4

Fall 1994

D igital Technical journal

Call for Authors
from Digital Press
Digital Press has become an imprint of Butterworth-Heinemann, a major inter­
national publisher of professional books and a member of the Reed E lsevier
group . Digital Press remains the authorized publisher for Digital Equipment
Corporation: the two companies are working in partnership to identify and pub­
lish new books under the Digital Press imprint and create opportunities for
authors to publish their work.
Digital Press remains committed to publishing high-quality books on a wide
variety of subjects. We would like to hear from you if you are writing or thinking
about writing a book.
Contact:

Frank Satlow
Publisher
Digital Press

313

Washington Street

Newton, MA 02158

Tel : (617) 928-2649
Fax: (617) 928-2640
fps@world.std.com

ISSN 08 98-9 0 l X
Prin ted in U.S. A.

1 4. 5
EY-T l l 8E-Tj/95 0 4 1 4

rved.
ion. A l l Righ ts Rese
Equ ipm ent Corporat
Copyright © Dig ital



File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.6
Linearized                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26
Create Date                     : 2006:04:13 12:16:23+01:00
Creator Tool                    : Adobe Acrobat 7.05
Modify Date                     : 2013:01:11 04:07:40Z
Metadata Date                   : 2013:01:11 04:07:40Z
Producer                        : Adobe Acrobat 10.1.4 Paper Capture Plug-in with ClearScan
Format                          : application/pdf
Title                           : Digital Technical Journal, Volume 6, Number 4: RAID Array Controllers; Workflow Models; PC LAN and System Management Tools
Creator                         : 
Document ID                     : uuid:c5a6b83e-3e6b-4fd6-8fbd-1cc9c545359b
Instance ID                     : uuid:2c68dd26-4733-4054-b6d6-bd7b83745968
Page Layout                     : SinglePage
Page Mode                       : UseOutlines
Page Count                      : 108