CS TR
The Sp eci cation of
Dynamic Distributed Comp onent Systems
Thesis by
Joseph R Kiniry
In Partial Ful llment of the Requirements
for the Degree of
Master of Science
California Institute of Technology
Pasadena California
Submitted May
ii
c
Joseph R Kiniry
All Rights Reserved
DRAFT NOT FOR DISTRIBUTION July
iii
Acknowledgements
Sp ecial thanks go to my wonderful advisor Dr K Mani Chandy Thanks also to Infospheres
group memb ers and fellow graduate students Dan M Zimmerman Adam Rifkin and Roman Ginis
Comp ositional Computing group member EveScho oler and p ostdo cs and past Comp group memb ers
Dr Paolo Sivilotti Dr John Thornley and Dr Berna Massingill
Dan Zimmerman was particularly helpful in his motivation to develop elegantandpowerful soft
ware frameworks Adam provided the inspiration of a Web yogi and Paul is the student theoretician
in whose fo otsteps I walk Thanks also go to Diane Go o dfellow for her administrative supp ort
Finally I d like to thank my long term partner and b est friend Mary Baxter you ll always b e
an inspiration in my life
This work was sp onsored by the CISE directorate of the National Science Foundation under
Problem Solving Environments grant CCR the Center for ResearchinParallel Computing
under grant NSF CCR and byParasoft and Novell The formal metho ds and adaptivity
reliability mobility security parts of the pro ject are sp onsored by the Air Force O ce of Scienti c
Research under grantAFOSR F
DRAFT NOT FOR DISTRIBUTION July
iv
DRAFT NOT FOR DISTRIBUTION July
v
Abstract
Mo dern computing systems are terribly complicated so complex that most system designers and
develop ers can only hop e to understand their small piece of the larger pro ject The primary technolo
gies that help system builders manage this complexity are ob ject oriented and or comp onent centric
and the primary tools are those that assist in system mo deling and sp eci cation
It is my b elief that the next stage in managing system complexity comes in the form of system
speci cation through formal methods Only with precise complete and consistent descriptions of
our systems and their comp onents can we hop e to understand the hyp er complex engineering that
has b ecome prevalent in computing to day
But only through the intro duction of some middle ground semi formal technique can mo deling
and sp eci cation break through into the mainstream Such a sp eci cation metho dology can t b e to o
hard to use but need to be formal enough that it will help system designers and to ols check the
consistency and completeness of the system and its comp onents
This thesis is the rst step on the road toward formal sp eci cation of dynamic emergent dis
tributed comp onent systems and addresses all of the requirements mentioned ab ove I intro duce
DESML a set of new mo deling constructs which can b e used as a thin layer on top of most mo deling
languages
DESMLisavariant of the Uni ed Mo deling Language UML not an extension Ihave rede ned
the the core metamo del thus the new language is no longer compatible at the meta level with UML
Note that such a mo di cation is not necessary it is only a convenience in the de nition of our new
language
The reader should be familiar with the Uni ed Mo deling Language and at least one formal
sp eci cation language Suggested references include and Chapter for UML and
Chapter for a sp eci cation language in this case Z
DRAFT NOT FOR DISTRIBUTION July
vi
Contents
Acknowledgements iii
Abstract v
List of Figures ix
List of Tables x
Intro duction
Motivation Tackling Complexity
Terminology
Thesis Roadmap
Sp eci cation
Formal Sp eci cation A Brief History
Current Leading Metho dologies
Informal System Sp eci cation Metho dologies
Formal Comp onent Sp eci cation Languages
Examples From the Informal to the Formal
Use Case Mo deling
The Z Sp eci cation Language
The Utility of Sp eci cation
New Challenges in Sp eci cation and Mo deling
Framework for Exp erimentation Infospheres
The Dynamic Emergent System Mo deling Language
The Comp onent Description Language
Examples
Mo deling Dynamic Distributed Systems
Background
Historical Opp osites Booch and Shlaer Mellor
Current Mo deling Languages
UML The Uni ed Mo deling Language
Catalysis
OOCL Ob ject Oriented Change and Learning
DRAFT NOT FOR DISTRIBUTION July
vii
Mo deling Extensions for Dynamic Systems
The Interface Behavioral Element
The Comp onent Element
Partial Interface Sp eci cation Stereotyp e
Re nements for Asso ciations
Ob ject Network Diagrams
The Kind Stereotyp e and Role
The Infospheres Infrastructure
Infospheres Infrastructure History
The Infospheres Infrastructure Requirements Analysis
Opaque Distributed Software Comp onents
Dynamic Interfaces and Interactions
Mo des of Collab oration
Persistence
The Infospheres Infrastructure Design
Infospheres Framework
Conceptual Mo del Pro cesses
Conceptual Mo del Personal Networks
Conceptual Mo del Sessions
The Infospheres Infrastructure Sp eci cation
The Messaging Subsystem
The Djinn Master
The Core PersistentCommunicating Comp onent The Djinn
The Infospheres Infrastructure Implementation
Implementation Supplementary Comp onents
Implementation Size
Hindsight Design and Implementation Improvements
Infrastructure Impact
Infrastructure Uses
Examples
Distributed Systems Built with Infospheres
Archiving Distributed States
The Global Snapshot Algorithm
Rep eated Snapshots
Replaying a Distributed Computation
AWorld Wide Web of Distributed Spaces
Conclusion
Contributions
Future Work
Bibliography
DRAFT NOT FOR DISTRIBUTION July
viii
List of Figures
An example Use Case diagram a co ee house
An example class diagram
An example statechart diagram
A more complex statechart diagram
An example activity diagram a print server
An example sequence diagram aprint server
An example collab oration diagram a print server
An example comp onent diagram
An example deployment diagram a p ortion of the Infospheres lab
An example package diagram the Infospheres core packages
An example note
An example typ e a p ortion of an editor with a dictionary
An example collab oration
An example framework applying a framework twice
OOCL elements
Current UML core metaclass backb one
New UML core metaclass backb one
Old class centric metamo del
New class centric metamo del
The sp eci cation of a class that has all four kinds of BehavioralElements
New BehavioralElement syntax
Extending the UML metamo del with the SoftwareComp onent element
The EventMessageBean sp eci ed in UML
Using fontchanges to denote prop erties
An example of using stereotyp es to denote the full interface of a comp onent
Using eventbehavioral elements to denote the full interface of a comp onent
An example partial class sp eci cation using ellipses
An example partial class sp eci cation using the partial stereotyp e
Two example class diagrams featuring the su cient stereotyp e
The basic forms of asso ciation
Summary of new representational entities for ob ject network diagrams
New representational entities for ob ject network asso ciations and relationships
Three new annotation constructs for asso ciations
DRAFT NOT FOR DISTRIBUTION July
ix
An example ob ject network a standard Web client server system
An example p ersonal network
info net use case diagram top level
info net use case diagram initialization
info net use case diagram manipulation
info net use case diagram sending and receiving
info net use case diagram shutdown
info net class diagram messages
info net class diagram mailb oxes
info net class diagram core classes
info master class diagram
High level info djinn class diagram
info djinn class diagram djinn base classes
info djinn class diagram service subsystems
info djinn class diagram messages
info djinn class diagram names
info djinn class diagram exceptions
info djinn class diagram core
info djinn class diagram UI and session management
info djinn ob ject network diagram
The Infospheres Infrastructure Summoner GUI version
DRAFT NOT FOR DISTRIBUTION July
x
List of Tables
A partial summary of the Z language op erators
A summary of the II implementation size and internal do cumentation
DRAFT NOT FOR DISTRIBUTION July
Chapter
Intro duction
Mo dern computing systems are terribly complicated so complex that most system designers
and develop ers can only hop e to keep track of their small piece of the larger pro ject The pri
mary technologies that help system builders manage this complexity are ob ject oriented and or
comp onent centric and the primary tools are those that assist in system mo deling and sp eci cation
Motivation Tackling Complexity
But nearly years after their intro duction these technological approaches only
partially solve the complexity problem They are not the nal solution b ecause large systems have
hundreds or even thousands of entities classes comp onen ts ob jects les computers databases
etc and orders of magnitude more asso ciations dep endencies and relationships
It is my b elief that the next stage in managing system complexity comes in the form of system
speci cation through formal methods Only with precise complete and consistent descriptions of
our systems and their comp onents can we hop e to understand the hyp er complex engineering that
has b ecome prevalent in computing to day
Although the use of development to ols from IDEs to exp ert systems can help lower the usage
cost of a sp eci cation metho dology this trend that of avoiding complex sp eci cation metho dologies
to tackle complex systems design cannot continue Complex system development has reached the
normal user s desktop witness the Windows op erating system with its multi tens of millions
of lines of co de
Only through the intro duction of some middle ground semi formal technique can mo deling and
sp eci cation break through into the mainstream Such a sp eci cation metho dology can t be to o
hard to use but need to be formal enough that it will help system designers and to ols check the
consistency and completeness of the system and its comp onents
Before we can explore the problem of system sp eci cation and mo deling in more detail weneed
ve a common ontology for the rest of this thesis to review our terminology so weha
Terminology
We distinguish b etween a sp eci cation language a mo del a metho dology and a pro cess
DRAFT NOT FOR DISTRIBUTION July
A language is the means bywhichwe describ e a comp onent or a system A sp eci cation language
can b e realized as a well de ned natural language grammar a mathematical notation or can b e a
well de ned graphical language either ideogrammic logogrammatic or pictographic We use one
or more languages to describ e a system and its comp onents
A model is an abstraction a system with base constructs rules and op erators Mo dels like
formal theories are fo cused on a small set of core entities The Actor mo del has of course the actor
construct Z has its schemas Demeter has its propagation patterns predicate calculus has pro of
rules etc
A methodology is a language and mo del coupled with a set of rules heuristics suggestions
patterns etc A metho dology is the full conceptual and descriptivepackage but it is not complete
without the b ehavioral description of how to use the metho dology
A process is just that description It is the set of rules and heuristics that are provided as a
guide for building the sp eci cation of the system with a metho dology Some pro cesses are sp eci c
to a particular metho d others are generic
Thus for a complete sp eci cation metho dology we need a formally de ned language with well
de ned semantics a model that is fo cused on the prop er abstraction s and a methodology coupled
with a process that bring the language together with the mo del in a complete package
Thesis Roadmap
This thesis is the rst step on the road toward formal sp eci cation of dynamic emergent distributed
comp onent systems
The reader should be familiar with the Uni ed Mo deling Language and at least one formal
sp eci cation language Suggested references include and Chapter for UML and
Chapter for a sp eci cation language in this case Z
In Chapter I will discuss the general problem of systems and comp onent sp eci cation in more
detail Next in Chapter I will describ e some of our extensions to an existing system level sp eci ca
tion metho dology Then in Chapter I will describ e the requirements design and implementation
of the Infospheres Infrastructure a dynamic emergent comp onent based framework I will pro
vide the sp eci cation of some of this framework in Chapter In Chapter I will review several of
the distributed systems built with this infrastructure I will then wrap up in the conclusion to the
thesis in Chapter summarizing the contributions of this work and its future directions
DRAFT NOT FOR DISTRIBUTION July
Chapter
Sp eci cation
It is our b elief that the next stage in managing system complexity comes in the form of system
speci cation through formal methods Only with precise complete and consistent descriptions of
our systems and their comp onents can we hop e to understand the hyp er complex systems that are
b ecoming prevalent in computing to day
In this chapter I will review the problem of system and comp onent sp eci cation and discuss some
of the challenges of sp ecifying complex systems
Formal Sp eci cation A Brief History
Formal sp eci cation techniques have b een used in computer science and other disciplines for over
thirtyyears Many of the abstract mo dels haveevolved from a formal grounding in mathematical
and temp oral logics
Sp eci cation languages have been develop ed for a variety of abstraction levels domains and
goals These axes considerably in uenced the design and evolution of sp eci cation languages and
systems
Abstraction Levels System sp eci cation has manylevels of granularity At one end of the sp ec
trum what I ll call the microscopic level there are sp eci cation languages for describing
very static precise systems like the gates in a CPU e g VDM At the macroscopic
end of the scale there are sp eci cation languages for describing entire huge dynamic and
complex systems like corp orate entities e g OOCL
This granularity of sp eci cation the abstraction level in uences the kinds of things that can b e
describ ed A language that attempts to cover to o manylevels is likely to b e overly ambiguous
or complex A language that is used for a very sp eci c abstraction level will not b e used very
often and won t grow or b e extended b ecause of its restricted initial domain
Domains Most sp eci cation languages are develop ed for sp eci c problem domains For example
VDM is a sp eci cation language primarily used in designing digital circuits predicate calculus
is used for the sp eci cation and pro of of computational algorithms and Concurrent Sequential
Pro cesses CSP and UNITY were develop ed to assist in the sp eci cation and pro of
of concurrent systems Thus the systems for which sp eci cation languages are develop ed
in uence their application exibility and usability
DRAFT NOT FOR DISTRIBUTION July
Likewise some languages are develop ed for a particular system paradigm IBM s Ob ject
Constraint Language OCL was designed primarily for ob ject oriented systems thus it has
inherent supp ort for ob ject oriented constructs like features attributes inheritance etc Most
sp eci cation languages all mentioned thus far but for OCL were not develop ed with ob ject
oriented systems in mind Therefore while they can often b e applied to such systems the t
is imprecise and the resulting usage is strained and often ad hoc
Goals Finally languages are often designed with their primary user in mind either a human b eing
or a computer If a language is solely develop ed for the mathematician or computer scientist
enco ding and manipulating it with to ols such as theorem provers is often di cult or imp ossible
Conversely some formal sp eci cation techniques are entirely designed for a computer While
e ciently enco ded and eminently parsable they are often nearly imp ossible for a human b eing
to understand For example one mightlike to read a such a sp eci cation to help debug the
to ols that use the original information
It is my belief that a successful sp eci cation technique must be usable by both the human
designer and the computational supp ort infrastructure
While many sp eci cation languages are meant to help an algorithm or system designer prove
the correctness of their artifact many of the most p opular languages to dayhave nothing to do with
formally assisting in the development of correct and complete systems In fact unsurprisingly the
widespread utilization of a sp eci cation language muchlike a normal computer language seems to
be inversely prop ortional to the language s complexity i e the simpler the language the more
system builders will use it
Current Leading Metho dologies
There are several current leading metho ds for sp ecifying systems and system comp onents These
metho dologies are either very formal or fairly informal there are few metho ds that ride the
middle ground b etween usability and formalism
Informal System Sp eci cation Metho dologies
First Generation Metho dologies The leading rst generation informal and semi informal sys
tem metho dologies include Bo o ch Coad Yourdon Martin Odell OOSE
tropy and Wirfs Bro ck Ob jectory Rumbaugh Shlaer Mellor Syn
These metho dologies fo cused primarily on building small to medium scale up to hundreds of classes
ob ject oriented systems Some are not integrally tied to the ob ject oriented paradigm they are ei
ther pro cess oriented or data oriented But uniformly all do not have the constructs necessary to
describ e very large and or distributed systems
Second Generation Metho dologies The second generation metho dologies that are generally
more formal and complete include Fusion Meyer and the Uni ed Mo deling Language
Designers of these new mo deling techniques incorp orated constructs that assist in the
sp eci cation of large scale and or distributed systems Additionally these metho ds are capable of a
DRAFT NOT FOR DISTRIBUTION July
more formal sp eci cation of system comp onents Sp eci cally all encourage the use of pre conditions
and p ost conditions in comp onent sp eci cation all prop ose the use of side e ect less constraint
sp eci cation and all can sp ecify lo osely coupled dynamic systems
Third Generation Metho dologies Finally third generation languages now emerging from the
mo deling community show further re nement They incorp orate ideas and terminology from cog
nitive science knowledge engineering and representation and information theory These new tech
niques include Catalysis Demeter and Ob ject Oriented Change and Learning OOCL
Due to the integration of ideas from these domains these new techniques are very p owerful and ex
ible
Cataysis Catalysis from Desmond D Souza and Alan Wills is the most normal of the third
generation languages It is an extension of UML that incorp orates diagrams techniques and
abstractions to sp eci cally handle to day s software architecture asp ects such as comp onents
patterns and frameworks
Demeter The Demeter metho dology from Northeastern University fo cuses on the problem of adap
tive software It is used both for sp eci cation and implementation at the meta level more
often than it used at the architecture level A designer and programmer is left to deal with
programming at a more semantic higher schematic level Predictably thisproves to b e b oth
di cult and p owerful
OOCL Ob ject Oriented Change and Learning is a new metho dology from Ed Swanstrom of Agilis
Corp oration Swanstrom has incorp orated numerous ideas from cognitive science and arti
cial intelligence sp eci cally knowledge representation to create a metho dology that is more
capable of mo deling general organizations as well as software systems
All of these sp eci cation metho dologies are fo cused on three things the language used in
the sp eci cation of a system rather than system comp onents the process of iteratively building
the system mo del and binding the mo del to the implementation What they do not help with
to day is any formal mo del or system correctness checking That is the domain of the formal
system sp eci cation languages
Formal Comp onent Sp eci cation Languages
Some of the leading formal mo dels and languages for comp onent sp eci cation include the Actor
mo del Actor Algebras the Larch language and system OCL Predicate
Calculus Pro cess Algebras CCS CSP SDL UNITY VDM
and Z
These mo dels and their complementary languages are for the most part domain sp eci c In
particular Actors and UNITY have b een prop osed as a general purp ose mo dels for the sp eci cation
and validation of concurrent and distributed systems Dijkstra s predicate calculus is a self contained
theory of predicate transformer semantics primarily used for the sp eci cation and developmentof
general pro cedural programs Similarly Z pronounced zed is a logic centric mo del and language
also for the sp eci cation of pro cedural programs
DRAFT NOT FOR DISTRIBUTION July
These languages are all equally p owerful p ermitting the user to completely sp ecify system b ehav
ior and prove prop erties of the system The two primary problems with these mo dels and languages
are
They are not equal ly expressive Each sp eci cation language has a di erent abstraction level
Some like OCL can not denote side e ects Predicate calculus and UNITY in fo cusing on
program semantics deal with extremely low level constructs like program statements The
Actor mo del s primary abstractions are single threaded active pro cesses that communicate
using messages
All these sp eci cation languages are Turing complete thus they can all are equally p owerful
But it is clear that the sp eci cation of a large message passing system in a reasonable task in
the Actor mo del or CSP butwould b e horrendously complex in Z
They ignorethemodels of modern system design and development None of these mo dels take
into account ob ject orientation comp onent centric software or meta programming While
expressing higher abstraction levels with new constructs is p ossible it leads to a mo del that
is overly complex and fo cused on the wrong levels of abstraction and core entities Examples
of retro tted or ill targeted mo dels include Ob ject Z Mo oZ OOZE Z VDM
Seuss and Actors
These problems necessitate the creation of a new sp eci cation language and system Such a
system must inherit most of its formalism from the traditional languages like Z and others but it
must also b e grounded in mo dern system design and development I will discuss these requirements
in more detail after providing an example of the range of formalism in use to day
Examples From the Informal to the Formal
For an example I ll consider the general sp eci cation technique Use Cases and the formal
sp eci cation language Z Use Cases is extremely simple to learn and use thus it is widely
adopted in industry Z complex and formal thus is rarely used anywhere even in academic circles
Use Case Mo deling
Use Case mo deling is a sp eci cation technique for describing a system at a very high abstraction
level Use cases are primarily utilized to informally do cumen t the interactions between a system
and its users and to generalize a more detailed sp eci cation construct Because of their simplicity
and customer end user fo cus use cases have received a great deal of attention in the development
of second generation mo deling techniques like the Uni ed Mo deling Language
The primary comp onents of a use case mo del are use cases actors andthesystem b eing mo deled
The system is a black b ox that implements some set of functions eachofwhich is represented bya
use case The external agentthatisinteracting with the system whether it b e a human b eing a
second part of the system or another system altogether is mo deled as the actor
An actor is represented by the classical stick gure lab eled with its role The system is
diagrammed as a simple b ox Each use case is mo deled as a lab eled ellipse and is connected to all
other related actors and use cases by a solid line
DRAFT NOT FOR DISTRIBUTION July
Order Coffee
Make Coffee
Customer Coffee Salesperson
Deliver Coffee
Figure An example Use Case diagram a co ee house
For a simple example of a use case diagram see Figure In this diagram the actors are the
Customer and the Co ee Salesp erson the system is the b ox the caf e and the use cases are
the three actions ordering making and delivering co ee Note that the Customer actor is not
connected to the Make Co ee use case since the customer do es not make his own co ee
Use cases are primarily utilized as an informal means of do cumenting system functionality
a leading abstraction for other more formal and complete system sp eci cation metho ds For
example in UML a set of use case diagrams can b e linked to sequence collab oration and activity
diagrams three kinds of more detailed diagrams in UML Likewise in Catalysis use cases represent
an abstraction of a new mo deling construct called a col laboration
A use case must by de nition deliver value to the actor In Ob jectory and UML all actors
are classes and most actors represent system elements like customers users and other real world
entities Thus these same entities i e a paying client see the real world tangible b ene ts of
developing and re ning use cases in system mo deling
Use cases are a low cost low complexity means of p erforming informal system description that
keeps the customer happy b ecause they can understand and a ect the design pro cess Due to this
p ositive b ene t to complexity ratio use case diagrams are often seen in customer fo cused system
mo deling more than any other diagram typ e
A go o d summary of use case mo deling is found in
The Z Sp eci cation Language
At the other side of the complexity and completeness sp ectrum we nd the Z system sp eci cation
language
The Z language is a mathematical notation used to describ e complex computing systems It is
based on set theory and logic and its core constructs are indep endent of sp eci cation domain or
implementation abstraction
One goal of the Z designers is the ability to prove global prop erties of the system directly
from the sp eci cation Two of the most imp ortant system prop erties that can often be proven
are the consistency there are no contradictory sp eci cation elements and the completeness of the
system the system mo del matches the real system b eing sp eci ed Additionally with a Z system
sp eci cation we can test the truth value of certain system sp eci c predicates like Can situation X
ever arise In general this is not a decidable problem but under the restrictive domain of system
mo deling we can gain utility for such predicates Finally sometimes we mightwant to b e able to
DRAFT NOT FOR DISTRIBUTION July
Op erator Symbol Example Usage
Powerset P P A
c c
Universal Closure A
Unique Counting Summation Quanti ers x S P x
x S P x
x S P x
Bag Collection Typ e
Sequence Collection Typ e h i h i
a a
Sequence Concatenation A B
Naturals starting with N a N
Sp ecial Schema Symbols
Incremental Inclusion message
Identity Inclusion message
Free Typ e De nition MESSAGE yes j no
Schema De ne b schema b s t
Schema Predicate pred pred message
Identi er Renaming NewName OldName
Identi er Hiding n nOldName
Pre Condition pre pre message nil
Post Condition p ost p ost message nil
o o
Schema Comp ose schema schema
Schema Pip e u s t
Table A partial summary of the Z language op erators
generate source co de for the system directly from the sp eci cation
A Z sp eci cation for a system is a set of units called schemas Eachschema has a declaration
part where a scop e is de ned and a logical or predicate part which sp eci es a set of predicates
whichmust b e true in the system
Z s notation is a combination of op erators from set theory mathematical logic functional pro
gramming collection typ es predicate calculus number theory and some sp ecial symb ols reminiscent
of knowledge representation languages See Table for a partial list of some of Z s more interesting
op erators and constructs
It is clear that b efore one can use Z one needs some formal training Ausermust understand
basic mathematical logic and set theory Additionally Zintro duces new op erators not found in the
core mathematical training of most professionals whichmust b e incorp orated into a user s rep ertoire
These requirements imp ose a substantial learning curve on system designers that wish to use Z
Z is formal for a very go o d reason In essence the use of the Z language is less about the
sp eci cation than it is ab out the facts one can prove from the sp eci cation This goal highligh ts
the tradition of speci cation towards proof There are several implications in this pro of oriented
tradition
Sp eci cation Towards Pro of First formalism implies a certain degree of rigor in use Many
users do not have the discipline necessary to fully takeadvantage of such a formal system
Second as mentioned previously there is a steep er learning curve in the use of Z than in a visual
system metho dology even one as comprehensive as UML This fact mightchange when I consider
some of the more formal third generation metho ds mentioned previously Therefore users take
DRAFT NOT FOR DISTRIBUTION July
longer to learn the language and must work harder to take full advantage of the system and its
to ols This ramp up time and cost mean that often designers never get the chancetolearnasystem
like Z b ecause of their deadline fo cused management
Third while many to ols exist to assist in the validation of formal sp eci cations and related pro ofs
most of the formal workatthislevel is p erformed bya human exp ert Often this human exp ert is
the designer Thus not only must one b e a go o d designer but one must b e a go o d mathematician
to takeadvantage of the b ene ts of such a system
These three implications mean that only some small p ortion of the designers capable of using an
informal metho dology have the resources to take full advantage of such a formal system I ll consider
the implications of this statement in the next section
For the interested reader an excellent concise overview of Z is available in Chapter
The Utility of Sp eci cation
Over the years I have observed the genesis evolution and adoption of many sp eci cation and
mo deling languages Based up on this exp erience I ha ve come up with the following set of principles
of sp eci cation These principles havehadan enormous impact on mywork in the form of this
thesis related pap ers to ol building etc
Language does matter While I nd the development and use of research and out of
mainstream languages interesting and challenging I will not pursue the creation or use of
such a language
I consider the following interesting research languages Beta CLOS
and Chapter Dylan ML the Pascal Mo dula family
Ob eron Obliq Self Simula
and Squeak The following are the out of mainstream pro duction languages I b elieve are
worthwhile Ei el Ob jective C the b est short intro duction can b e found
in the b est b o ok on the language is Smalltalk and Python
The adoption of a more main line programming language that ful lls most of our needs will
result in a b o dy of work that can p otentially in uence a large numb er of practicianers Ichose
to use the Java language and XML representation format for exactly these reasons
The support of modeling tools is very important Di erent languages have di erentlevels of to ol
supp ort Some e g Actors have no to ol supp ort they are used as by hand mathematical
languages useful for sp eci cation and pro of Others e g UNITY predicate calculus OOCL
and OCL have partial to ol supp ort a veri er like UV the UNITY Veri er or theorem
prover or pro of checker might be available to assist an exp ert in system sp eci cation e g
Isab elle LOTOS
Finally some UML Demeter the VDM family the Z family and the Larch family have
excellent to ol supp ort They include generators parsers reusable libraries compilers pro of
checkers etc and thus are excellent sp eci cation languages from a to ols oriented p oint of
view More users will b e inclined to try out a sp eci cation language if it includes a to ol that
helps them get their job done Examples include Rational Rose the Demeter To ols
DRAFT NOT FOR DISTRIBUTION July
IFAD VDM SL To olb ox Cogito LP the LarchProver LSL the Larch Shared
Language and LCLint a to ols used for statically checking annotated C programs
built with Larch
Moreover if one can insinuate the use of a formal sp eci cation language via a commonly
used to ol without the user knowing a priori that they are using such a system we will gain
accidental converts Once users realize the impact that such a system can have on their
design and programming e ciency and their system s reliability we sp eculate that they will
b ecome true evangelists for the system
Inclusion of innovative boundary research areas is necessary but not su cient for a method s
adoption Some metho ds have fo cused on sp eci c b oundary researchareas thinking that
their innovation will b e enough to make an impact This highly fo cused work while imp ortant
within the sp eci c area of research is often not communicated fully to and appreciated by
a wider audience It is very di cult to present atightly fo cused highly sp ecialized b o dy of
work to a general audience
Consider the Demeter metho d a fo cused summary of Demeter s core concepts can b e found
in Chapter an annotated version of Its fo cus is exclusively on adaptive ob ject
oriented software through the use of propagation patterns Because of this tight fo cus and the
fact that the metho d uses metalevel architectures it has not had much impact in the mo deling
and design communities
To quote Ralph Johnson In my opinion the entire vo cabulary of the re ective programming
community is an unmitigated disaster That community has succeeded in taking an extremely
imp ortant topic and making it so hard to understand that it is ignored by most of the p eople
who need to knowit
This generated complexity that is prevelant in many of the elds that this work is based
up on metaob ject proto cols knowledge representation re ection semantics representation
etc I hop e to avoid though a conscious e ort to keep our vo cabulary and concepts clear and
to the p oint
The proper ground technologies must be chosen A prop er foundation for such a complex and
comprehensive body of work must b e carefully chosen This will help reduce the amountof
work provide a solid base up on which to build and help regulate and order the development
of new constructs and to ols
I have chosen UML as the base system mo deling language up on which to build and XML
as our ground representation language UML is the de facto standard for system mo deling
and has a fairly well de ned but not well tested mechanism and pro cess for extending the
core language XML is the emerging de facto representation format for arbitrary data and
has many constructs namespaces linking and pointing and instantiations
RDF CKML and OML and to ols which lend themselves to our use
To summarize I believe that next generation work in formal sp eci cation must use the right
language s provide to ols include interesting and relevant b oundary research ideas and use the
prop er ground technologies and standards I aim to ful ll all of these requirements in this b o dy of
work
DRAFT NOT FOR DISTRIBUTION July
I will next consider in more detail some of the new challenges in system s design and architectures
that in uence this work
New Challenges in Sp eci cation and Mo deling
The last ingredient necessary for a successful sp eci cation metho dology is the ability of the metho d
to handle the challenges techniques and abstractions in mo dern software architectures I b elieve
that the most imp ortant asp ects that must b e captured by the sp eci cation metho dology are
Dynamism Mo dern system comp onents change over time they are replaced they change b ehavior
they change lo cation etc Additionally the system changes over time as it resp onds to the
changing demands The forces b ehind the dynamism muchlikeWegner s interactive systems
stimuli are placed up on it by other systems users customers etc
Emergence Systems not only change over time but can exhibit b ehaviors that were not originally
part of the system s original design Such emergent b ehavior is unsurprising in some systems
Corp orations intentional non deterministic or random systems and arti cially designed evolv
able simulations likeTom Ray s Tierra commonly exhibit surprising b ehavior
But a system lik e the World Wide Web very simple at its core but complex in its scop e
application and degree of growth is not exp ected to evidence suchevolving b ehavior
Meta Levels Meta levels of system design and development are gaining attention for their
expressive and descriptive power Such constructs and theories include metaob ject proto
cols asp ects sub ject oriented programming and re ection Acom
plete metho dology must b e able to capture all of the meta levels of the system b eing mo deled
Comp onents Comp onentarchitectures are at the ro ot of most software developmenttoday The
comp onent as a base level of abstraction is the appropriate core construct for the language
mo del metho dology pro cess and complementary theory No existing metho dology and theory
has the comp onent as its core construct a serious de ciency from our standp oint
Knowledge Representation Sp eci cation is all ab out capturing information and knowledge ab out
tation can b e a system and its comp onents Constructs and theory from knowledge represen
applied to the problem of software system sp eci cation A metho dology must incorp orate
these ideas and to ols
As mentioned previously the goals of this work are more than just the evolution of an existing
metho dology or the creation of a new sp eci cation language Wemust also provide the to ols pro cess
mo del and theory to supp ort this broad collection of work Therefore such a framework will unify
the generalism breadth and informalism of metho dologies like UML and take advantage of the
formalism of a sp eci cation language like Z or Larch and package it all in a cohesivebodyofwork
To realize these ideas and goals an implementation framework for dynamic active ob jects needed
to b e created Iwas a key gure in the creation of just such a framework the Infospheres Infras
tructure version A next generation framework version iscurrently under development It
incorp orates even more innovative ideas from the ob ject and Web communities
Additionally the system level and comp onent level keystones of this work the DESML and CDL
sp eci cation languages are b eing develop ed
DRAFT NOT FOR DISTRIBUTION July
Framework for Exp erimentation Infospheres
The Infospheres Infrastructure version I will use II for short is a rst pass design and im
plementation of a comp onent based dynamic active ob ject framework It was built to explore
the use of the Java language in building such a system and to facilitate the development of
high level systems and to ols to reify the theoretical and mo deling work of the Infospheres group at
Caltech I will describ e this framework in more detail in Chapter
The Dynamic Emergent System Mo deling Language
DESML the Dynamic Emergent System Mo deling Language is a formal variantof UML for dy
namic emergent distributed systems It is sp eci ed with the standard extension mechanisms of
UML Stereotyp es Tagged Values and Constraints and a slight mo di cation to the UML metamo del
It provides several new graphical constructs to extend the visual language of UML DESML also
incorp orates many of the ideas that are part of the third generation mo deling languages particularly
OOCL and Catalysis
Some of the foundation constructs in DESML are describ ed in Chapter of this do cument
The Comp onent Description Language
The other fundamental half of the sp eci cation architecture is CDL the Comp onent Description
Language CDL is a new sp eci cation language that incorp orates ideas from several of the other sp ec
i cation mo dels and languages previously mentioned OCL Z and VDM variants Larch UNITY
pro cess algebras and predicate calculus in particular CDL s core mo del and complementary the
ory is comp onent centric and based on ob ject calculus CDL will b e describ ed in full detail as
part of my PhD dissertation It is not describ ed here
Examples
Anumb er of distributed systems have b een built with the II Several of them will b e describ ed in
Chapter
DRAFT NOT FOR DISTRIBUTION July
Chapter
Mo deling Dynamic Distributed
Systems
This chapter presents the core of this thesis a set of mo deling constructs that are the foundation
of DESML These constructs ful ll the challenges and requirements discussed in Section of the
last chapter
Background
I will provide the reader with some background in the domain of system mo deling so that they have
su cientcontext to understand the contributions of these new mo deling constructs
System mo deling languages with visual constructs have b een used for decades The eld gained
attention in the s with the emergence of ob ject oriented languages and systems into the main
stream
The original system mo deling languages were not ob ject oriented theywere either data oriented
or behavior oriented Languages from both domains evolved and were incorp orated into ob ject
oriented mo deling languages Understandably the bias of their origins can b e seen in this transition
Historical Opp osites Bo o ch and Shlaer Mellor
The Booch and Shlaer Mellor ob ject oriented metho dologies are the historic archetyp es of
behavior and data oriented metho dologies Boochisabehavior oriented mo del Shlaer Mellor is a
data oriented mo del
Data oriented techniques fo cus on describing the data that is at the core of all computational
systems b ehavior oriented techniques concentrate on describing the activities of a system inde
p endent of the data representation Data oriented mo deling techniques primarily originate in the
database and information pro cessing communities Behavior oriented techniques on the other hand
originated with the traditional computational oriented practicianers
In some sense b oth data oriented and b ehavior oriented languages are the right source from
whichtoevolve an ob ject oriented language Ob ject orientation is ab out ab out understanding the
behavior of a system as applied to the data thus the uni cation of b oth domains is appropriate
DRAFT NOT FOR DISTRIBUTION July
Thus b oth Bo o ch and Shlaer Mellor signi cantly in uenced the development of to day s lead
ing mo deling languages Booch and other leading b ehavior oriented metho dologies of the late
s provided many of the b ehavior fo cused constructs Shlaer Mellor and the other data oriented
metho dologies in uences the data oriented asp ects
Current Mo deling Languages
The bulk of to day s mo deling community has settled down on a single syntax and semantics for a co de
mo deling language This core language is called the Uni ed Mo deling Language UML
UML was jointly develop ed by many companies but leading the e ort are three of the ma
jor researchers in the mo deling community Grady Bo o ch James Rumbaugh and Ivar Jacobson
Each of these individuals brought their own p ersp ective and mo deling language and pro cess to the
table Booch dev elop ed the previously mentioned Booch metho d Rumbaugh s language is
called the Ob ject Mo deling Technique OMT and Jacobson s language and pro cess are called
OOSE Ob jectory
Additionally several other companies individuals and metho ds in uenced the developmentof
UML One of the most in uential metho ds is called Catalysis and is considered one of the leading
edge metho ds available to day
Finally there exist some new metho ds that are outside the mainstream While they often
use UML as a syntactic base they intro duce new concepts constructs and techniques to system
mo deling One of these new generation languages is OOCL
We ll brie y discuss these three leading metho ds highlighting their strengths and weaknesses
Then I will intro duce a set of new mo deling constructs and diagrams which can be added to any
mo deling language to improve its expressiveness and capabilit y
For the reader interested in an overview history description and comparison of the primary
metho dologies of the late eighties and early nineties see
UML The Uni ed Mo deling Language
As previously mentioned UML primarily originates from the workofBooch Rumbaugh and Ja
cobson Bo o chand Rumbaugh b egan working on UML together in when Rumbaugh joined
Bo o ch s company Rational Software Corp oration Their goal was to unify the Bo o ch and OMT
metho ds and thus unify their user bases Jacobson later joined in when Rational purchased
his company Ob jective Systems Atthispoint in time the three realized that they were doing more
than unifying their own metho ds they were creating a standard mo deling language for the entire
mo deling community
As they worked on UML Rational provided preliminary sp eci cations via the Web Feedback
from the mo deling communityprovided many ideas and suggestions for incorp oration into the lan
guage Simultaneously the OMG issued a CFP for a standard mo deling language for ob ject systems
The UML develop ers were instrumental in the issuance of this RFP and realized the value in making
UML an industry wide standard with the OMG s stamp of approval
In fact this author was the reviewer of the new Addison Wesley Catalysis book Objects Components and
Frameworks with UML The Catalysis Approach by Desmond D Souza and Alan Wills
DRAFT NOT FOR DISTRIBUTION July
Even though the core of UML comes from Bo o ch OMT and OOSE Ob jectory ideas were
incorp orated from several other mo deling languages as well For example Harel s work on state
charts Coleman et al work on numb ering op erations in Fusion and Gamma et al
work on do cumenting patterns were all rolled into the UML nal release
UML is a mo deling language designed by a committee Thus it cannot b e exp ected to solve the
challenges presented in the last chapter In particular UML do es not handle emergent systems and
knowledge representation at all Its supp ort for dynamism is limited to the standard set of diagrams
used to describ e dynamic systems
The UML Diagrams UML is de ned by a metamo del This metamo del consists of a set of
standard constructs and de nes a number of diagrams used to describ e the static dynamic and
interactive asp ects of a system The eight diagrams de ned by the UML standard are group ed into
four classes
System Interaction
Use Case Diagram Ihave already discussed use case diagrams in Section Brie y a
use case diagram shows the relationship among actors activeentities including software
elements and human users and use cases usage scenarios in a system An example
use case diagram was presented as Figure
Static System Structure
Class Diagram A class diagram is a graph of classi er elements connected by their
various static relationships A classi er is one of many static system constructs suchas
classes interfaces packages relationships and even instances of ob jects and links An
example class diagram can b e seen in Figure
An object diagram is an instance of a class diagram indicating the static relationship
between ob ject instances frozen in time
The stereotyp es see b elow type and implementation class can b e used to indicate that
classi er elements are either ob ject typ es see Section for the de nition of typ e in
this context or implementations The previously mentioned class diagram uses several
stereotyp es as an example
System Behavior Diagrams
Statechart Diagram A statechart diagram shows the sequences of states that an ob ject
or interaction go es through during its life cycle in resp onse to stimuli It also do cuments
the ob ject s resp onses and actions The semantics and notation of statechart diagrams is
basically identical to David Harel s statechart diagrams as mentioned previously A
simple example statechart is provided in Figure A more complex statechart can b e
seen in Figure
Several gures in this do cument are adopted from or mo di cations of a variety of sources including
DRAFT NOT FOR DISTRIBUTION July
<
<
<
isEqual(String): Boolean
hash(): Integer
Figure An example class diagram
(start state) go up On first floor Moving up arrived
Moving to first floor arrived go up
arrived Moving down Idle
go down
time-out
Figure An example statechart diagram
DRAFT NOT FOR DISTRIBUTION July
Install Software
OS Running Restart OS
Create()
(start state) Install Start InstallShield entry/Ask installing questions do/Install Software
H
[alternative = try again] Disk Error() Out of memory()
Disk Error Memory low [alternative = stop] entry/fix disk entry/Show question dialog do/Show question dialog do/Ask alternative do/Ask alternative
[alternative = stop]
Figure A more complex statechart diagram
Activity Diagram An activity diagram is a variation of a state machine in which the states
are activities representing the execution of op erations and transitions are triggered by
the completion of op erations Figure is an example of an activity diagram
Interaction Diagrams A pattern of interaction among ob jects is shown on an interaction
diagram Interaction diagrams come in two avors
Sequence Diagram A sequence diagram represents an interaction in which messages
are exchanged among a set of ob jects to e ect a desired result An example sequence diagram is included as Figure
Show MessageBox [disk full] "Disk full" on screen PrintFile()
(start state) Show [free disk space] MessageBox "Printing" on screen
Create Remove ^Printer.Print(file) Postscript MessageBox
file
Figure An example activity diagram a print server
DRAFT NOT FOR DISTRIBUTION July
Print(file) :Computer :PrinterServer :Printer :Queue
Print(file) [printer free] Print(file)
[printer busy]
Store(file)
Figure An example sequence diagram a printserver
:Computer :Queue [printer busy] 1.2: Store(file)
1: Print(file)
[printer free] 1.1: Print(file)
:PrinterServer :Printer
Figure An example collab oration diagram a print server
Col laboration Diagram A col laboration diagram shows interaction among ob jects as
well as their relationship with each other Unlike a sequence diagram time is not
do cumented in a collab oration diagram so the sequence of messages and concurrency
must b e indicated with sequence numb ers Figure is an example of a collab oration
diagram
Implementation Diagrams
Component Diagram Component diagrams are meant to do cument the structure of the
co de itself Note that the notion of a comp onent in UML has little to do with component
software one of the primary challenges presented in Section An example comp onent
diagram is provided as Figure
Deployment Diagram Deployment diagrams show the con guration of the real pro cessing
systems on which a system is to run Elements included in deployment diagrams include
computers network elements pro cesses ob jects networks etc The example deployment
diagram shown in Figure do cuments the Infospheres lab here at Caltech
UML also provides a number of general mechanisms for annotating and ex Extending UML
tending system sp eci cations These constructs include
DRAFT NOT FOR DISTRIBUTION July
Header File Header File (stdio.h) (math.h)
Main File (main.c)
Main File (main.o)
Executable File
(a.out)
Figure An example comp onent diagram
ClientA: Info.cs <
File Server: <
ClientB: <
Plato.cs
Figure An example deployment diagram a p ortion of the Infospheres lab
DRAFT NOT FOR DISTRIBUTION July
info.util
info.djinn info.net
info.master
Figure An example package diagram the Infospheres core packages
Packages A package is a collection of mo del elements Packages can b e nested and inherited
and are used to highlight high level system dep endencies The semantics of a package are only
one of collection E g There is no necessary relationship b etween the UML package element
and the package construct of Javaora module from Ada or Mo dula though this would b e
the reasonable binding An example of a package diagram can b e seen in Figure
Stereotypes A stereotype is a new class of mo deling element that is intro duced at mo deling
time Stereotyp es are intro duced by sp ecializing existing mo deling elements Generally a
stereotyp e indicates a usage or semantic extension
Stereotyp es are represented by attaching a keyword string to an existing mo del element within
guillemets as in the following examples
abstract actor djinn
Constraints A constraint is a semantic relationship among mo del elements that sp eci es
conditions and prop ositions that are invariant Constraints are sp eci ed by including text in
braces next to mo del elements For precision the text is usually some formal sp eci cation
language like OCL or Z or a mathematical expression
Several examples of constraints are provided as follows
fmessage oclIsTypeOf SummonRequest g
f n N n n even g
Properties and TaggedValues Anyvalue attachedtoamodelelement attributes asso ciations
hed to tagged values etc is a property A tagged value is a keyword value pair that can b e attac
any mo del element Tagged values p ermit arbitrary annotation of mo dels and mo del elements
Such annotation is considered an extension when the tagged values are precisely de ned
Prop erties are sp eci ed as a comma delimited sequence of sp eci cations in braces much like
constraints
DRAFT NOT FOR DISTRIBUTION July
This model was built by
Joe Kiniry in May of 1998.
Figure An example note
Here is an example of several prop erties
message priority HIGH
self ref other ref
Djinn allInstances forAll p p p p p name p name
Notes A note is a graphical symbol containing information normally textual but p ossibly
graphical or programmatic It is the notation used for rendering various kinds of textual
information for a mo del or metamo del such as constraints comments program co de or
tagged values An example note is included in Figure
UML Limitations and State UML do es b egin to handle comp onent software with comp onent
diagrams insofar as comp onents are ob jects and co de UML has no notation for representing the
intricate relationships that comp onents can have with one another neither can it truly represent
a comp onent s inb ound and outb ound interface prop erly I will present extensions to handle just
these problems in the next section
UML has an extensible metamo del and thus can describ e the meta asp ects of a system but
only as long as such asp ects are representable in the core mo deling language Realistically mostof
the asp ects of meta systems are not captured by UML at the non meta level thus they certainly
cannot b e captured at the metalevel In particular asp ects re ective comp onents and metaob ject
proto cols are p o orly handled by UML
UML is now at revision and its core sp eci cation is publicly available on the Web at http
www rational com uml A brief intro duction to the language is providedin and Chapter
Catalysis
Catalysis is a mo deling language and pro cess that takes the next step in scalable rigorous comp onent
based development As D Souza and Wills put it Catalysis is A next generation standards aligned
metho d for op en distributed ob ject systems that is constructed from comp onents and frameworks
that re ect and supp ort and adaptiveenterprise Section
The main constructive elements to system mo deling that Catalysis contributes are called types
col laborations re nements and frameworks In short types describ e the external behavior of an
ob ject col laborations sp ecify b ehavior of a group of ob jects re nements relate di erentlevels of de
scription of b ehavior and map from realization to abstraction and frameworks provide sp ecializable
reusable recurring patterns of collab orations typ es designs etc
DRAFT NOT FOR DISTRIBUTION July
type-model = vocabulary Editor Type Specification type specification usually in separate Editor <
contents * Element operations specified in terms preferredSize * of the type model position
dictionary * Word Composite layout() and spellCheck() are every word in contents is tightly coupled spellCheck() correct by the dictionary layout() addElement() every element is positioned delElement() so that its preferred size can
be accomodated
Figure An example typ e a p ortion of an editor with a dictionary
More sp eci cally
Types Catalysis s choice of terminology with resp ect to typ es is unfortunate A Catalysis type
is a a description of the inbound interface of an ob ject a list of its op erations with their
complementary safety conditions preconditions and p ost conditions A Catalysis typemodel
is the dictionary used to sp ecify a typ e An example typ e and typ e mo del are provided in
Figure
Col laborations A collection of comp onents that satis es a typ e sp eci cation is called a col lab
oration A collab oration is essentially a well de ned comp osition of several typ es An example
collab oration can b e seen in Figure
Re nements Re nements provide a variety of means by which one can abstract sp eci cation
For example typ es are re ned to classes in Catalysis Re nements in Catalysis di er from
sp ecialization and generalization in other mo deling techniques b ecause re nements can be
applied to more than just system elements like classes and interfaces E g Re nements can
also b e applied to business pro cesses and sp eci cations See Section for a detailed
re nement example
Frameworks Almost all mo deling reveals reccuring patterns of typ es classes attributes
op erations and re nements Manysuch patterns are captured by existing mo deling constructs
like asso ciations constraints generalization etc
However there are many patterns usually at a higher level of abstraction which are not
captured by these built in constructs Catalysis fr ameworks provide a means by which to
do cument these general reccuring patterns The notation provides a means bywhich an ab
stract framework can b e instantiated to a particular instance complete with parameterization
of sub elements An example framework sp eci cation is provided in Figure
DRAFT NOT FOR DISTRIBUTION July
Editor Internal Design
Editor maximum size next word replace word resize children E-Core spellCheck() layout() addElement() delElement() Spell Checker Layout Manager
dictionary spellCheck() layout()
internal design in a separate words
package from the specification
Figure An example collab oration
two applications of the same framework
Seminar Scheduling
RoomFacility InstructorSkill Topic * skills
Certification ResourceAlloc ResourceAlloc * certs
Room Instructor SeminarSession inv capability == certs.skills
when: DateRange
Figure An example framework applying a framework twice
DRAFT NOT FOR DISTRIBUTION July
The Uni ed Mo deling Language and metamo del have adopted signi cant mo deling constructs
from Catalysis including typ es b ehavior sp eci cation re nements collab orations and frameworks
Since Catalysis is the primary motivator in the intro duction of typ es re nements and collab orations
to the UML core mo del the same comments on the capability of the language hold for Catalysis as for
UML Meaning Catalysis takes the rst steps in the representation of comp onents and comp onent
groups but do es not provide enough constructs to b e as expressive as necessary in complex systems
OOCL Ob ject Oriented Change and Learning
Ob ject Oriented Change and Learning OOCL is a mo deling language and pro cess designed for
p eople based systems Such systems are organic in the sense that grow develop evolve mu
tate learn metamorphose and adapt As mentioned previously these typ es of systems often defy
traditional mo deling and measurement techniques OOCL in its fo cus on mo deling understanding
managing and accelerating the growth and learning capabilities of p eople based business systems
mightpotentially b e the leading metho dology in tackling the problems mentioned in Section
OOCL is primarily used for mo deling business pro cesses strategies complex adaptive systems
and system dynamics I e OOCL is not used to design just software systems it is used to design and
understand business systems holistically software is only one comp onent of a complex business
system
OOCL as a metho dology has extended the ob ject oriented approach to supp ort JayForrester s
as well as the Systems Thinking approach Systems Dynamics mo deling approach
develop ed by MIT The newest version of OOCL version is a ma jor metho d up date with new
features including the ability to mo del self organizing complex adaptive systems CAS For more
information on the work underlying the OOCL metho d see For a quick
summary of OOCL see
OOCL intro duces a number of new mo deling constructs to help sp ecify such dynamic system
These elements include
Agent An agent is an entity resp onsible for a set of tasks
Organization An organization is a group of agents working toward a common goal
Constel lation A constel lation is a group of organizations working toward a common goal
Resource Agen ts organizations and constellations consume use and create resources Re
sources are things like money materials information etc
Process A process is a set of agents and resources interacting to deliver a particular service
Each of these new mo deling constructs intro duces new symb ols to the base mo deling language
These elements are summarized in Figure
OOCL combines techniques from complex adaptive system studies of Santa Fe Institute cognitive
science organizational learning ob ject technology business pro cess engineering agile manufactur
ing and others Essentially it attempts to unify those practices and techniques that are concerned
with organizational agility
OOCL adds several diagrams and graphs to a UML base as well as intro duces new steps to the
standard software engineering pro cess Each of these diagrams or graphs intro duces a number of
DRAFT NOT FOR DISTRIBUTION July
Agent Organization
Resource Process
Figure OOCL elements
new constructs to the language The diagrams and graphs are organized b elowby the stages of the
OOCL pro cess
De ne Boundaries During this rst phase of the OOCL pro cess the rules assumptions and
presupp ositions that in uence the mo del are de ned This information is summarized in a
Microworlds Diagram Microworlds havetwo main hierarchies one based up on generalization
and the other up on meta levels
Scanning the Environment and Envisioning In this phase the system mo deler attempts
to capture the vision and goals of the organizational comp onents of the microworld This
information is captured in several diagrams
Vision Diagram A vision diagram do cuments the shared vision goals and missions
of agents across groups organizations and constellations This shared vision is what
motivates agents within these contexts
Concept Mapping Diagram Concept maps are used to identify and capture organizational
concepts from discussions do cuments etc
Metaphor Diagram A metaphor is a sp eci c story that can b e generalized to t many
situations
Stakeholder Diagram A stakeholder diagram do cuments how di erent stakeholders will
utilize the business
Business Analysis This phase presents an external view of the business system p ersp ective
The emphasis is more on what the business will do than how the business do es it There is no
fo cus on implementation at this stage This stage builds a Business InterfaceModel using the
following diagrams
Business Scenario Diagram The business scenario diagram captures the interactions
between actors and the business system from a high level blackbox p oint of view
Organization Interface Diagram This mo del shows the input and output of the business
system
Business Schemata Model The business schemata model describ es the semantics of each
business stim ulus in the business interface
DRAFT NOT FOR DISTRIBUTION July
Business Class Diagram A business class diagram do cuments the business ob jects that
provide the logic for the business rules of an organization Business ob jects are rei cations
of the concepts describ ed in the concept mapping diagrams of a system
Business Design During this stage several diagrams are develop ed to re ne the business class
mo del of the last stage Design is concerned with assigning op erations to the classes de ned
in the business class mo del determining how ob jects communicate and what the inheritance
relationships are b etween these classes
Several graphs and diagrams are develop ed at this stage
Business Object Interaction Graph The business object interaction graph describ es the
dynamic business b ehavior of an organizational unit
Activity Graph Each activity graph shows the activities that take place inside each pro cess
step in the business ob ject interaction graphs
Business Class Descriptions These descriptions describ e the precise sp eci cations of the
business classes
Business Transformation During this phase all the mo dels created during the previous de
sign phases are implemented in simulation walk throughs or actual changes to the business
structure Two diagrams supp ort this stage
State Diagram State diagrams are used to do cumentthesimulations necessary to trans
form the business structure
Project Diagram Finally project diagrams are used to track and test pro cesses during
the development of the business
Continuous Change and Learning During and after the initial phase of the OOCL pro cess
acontinuous cycle b egins where observations and insights are learned and incorp orated into
the mo del Lessons learned are enco ded and stored in the level two metalevel knowledge
rep ository There are also level three and four knowledge and pro cesses related to improving
the team division or organization
Providing examples of each of the ab ove diagrams and graphs would takeuptoomuch space for
this b o dy of work We suggest for summaries and examples of all of the diagrams
OOCL also evolves and intro duces new concepts to system mo deling The primary evolved
traditional concepts at the heart of OOCL is the business ob ject dictionary anevolution of the data
and class dictionaries of other metho ds The primary new concept central to OOCL is the so called
Corp orate DNA The Corp orate DNA is the sp eci cation of the resources motivations goals and
aspirations of an organizational unit primarily a corp oration or pro ject
OOCL is fo cused primarily on describing complex systems that change over time thus intro duces
esomeofthechallenges mentioned in the previous anumb er of imp ortant concepts that help solv
section In particular OOCL incorp orates metamo dels knowledge representation and dynamism
as rst class entities for representation Thus OOCL is the only mo deling language that p otentially
deals with these three challenges
DRAFT NOT FOR DISTRIBUTION July
On the other hand OOCL do es not extend the mo deling language with resp ect to core soft
ware engineering problems that of comp onent representation and interaction It exhibits the same
limitations as Catalysis and UML
OOCL is not yet available in full for public review is still under development When the full
language de nition b ecomes available I will evaluate the capability and appropriateness of OOCL
as a ground mo deling language Iwillcomebacktothispointattheendofthischapter
Mo deling Extensions for Dynamic Systems
This section will intro duce a small set of mo deling extensions that help solvethechallenges discussed
in Section
Several mo deling problems are discussed Each problem is brie y intro duced often with an
example Then the corresp onding construct is presented that assists in solving the problem The
construct s syntax b oth graphical and symb olic is then explained Finally its semantics are fully
sp eci ed
Brie y the problems discussed here are as follows
Core Interface Behavior Representation How can a comp onent s interface b e sp eci ed
and how can we unify these interface sp eci cations into a single mo del
Core Comp onent Representation Howcanrealsoftware comp onents b e completely and
prop erly sp eci ed
Partial Comp onent Interface Sp eci cation What are the problems inherent in ob ject
and comp onent sp eci cation and how can ob jects and comp onents be partially and totally
sp eci ed
Comp onent Asso ciations What kinds of asso ciations exist b etween comp onents and how
can these asso ciations b e mo deled
Dynamic and Emergent Structures of Comp onents How can dynamic and emergent
structures of comp onents b e mo deled What are the core representational elements
Tying Knowledge Semantics to Comp onents How can we relate information knowl
edge and semantics to comp onent sp eci cation
The Interface Behavioral Element
Problem One Core Interface Behavior Representation UML has several core constructs
the explicit Operation that explicitly and implicitly sp ecify the interface of an ob ject Sp eci cally
and related metaclasses are indep endent in the UML metamo del all sp ecializing from Behavioral
Feature Event the implicit metaclass is currently not asso ciated with Behavioral Feature
I intro duce two new sp eci cation elements Channel and Tuple which will be used to sp ecify
alternate interfaces for comp onents Additionally IbelievethattheEvent metaclass should also b e
used asso ciated with Operation so that it can b e used to sp ecify the interface of a comp onent
The core metaclass backb one for UML is shown in Figure Our mo di cations result in the
new structure seen in Figure Only the relevantpartofthemodelareshown
DRAFT NOT FOR DISTRIBUTION July
Element
ModelElement
Feature
StructuralFeature BehavioralFeature
1
Attribute Operation * Method
Figure Current UML core metaclass backb one
Element
ModelElement
Feature Tuple
StructuralFeature BehavioralFeature Channel
Attribute Event
Operation Method
Figure New UML core metaclass backb one
DRAFT NOT FOR DISTRIBUTION July
Interface ModelElement
AssociationRole Class Generalization
Association
Attribute Method Operation
Figure Old class centric metamo del
Interface ModelElement
AssociationRole Class Generalization
Operation
Association Attribute Tuple
Method Event Channel
Figure New class centric metamo del
This change impacts several asp ects of the UML metamo del
First I haveintro duced two new metaclasses Channel and Tuple These metaclasses must b e
fully de ned as p er the UML metamo del de nition See the semantics de nition provided in
OCL later in this section
Second the Event metaclass used to b e a part of the State Machines package which is within
the Behavioral Elements package Since the Behavioral Elements package was dep endentupon
the Foundation package in which all core elements reside but not vice versa the moveof
Event from Behavioral Elements to Foundation will not adversely a ect the metamo del
Thus the part of the metamo del related to the Class metaclass can now b e rewritten from its
existing structure as see in Figure to the new structure as seen in Figure
DRAFT NOT FOR DISTRIBUTION July
Rectangle
p1: Point p2: Point
<
ownershipChange(old: Owner, new: Owner)
Figure The sp eci cation of a class that has all four kinds of BehavioralElements
Op erations and Interface Sp eci cations Note that Event Tuple and Channel are all still
related to Operation in exactly the same manner that Method was More precisely all are an
implementation of an Operation sp ecifying the algorithm or pro cedure that e ects the results of an
op eration Eachhasa body attribute that is the implementation of the element represented as a
ProceduralExpression Additionally eachhasa speci cation asso ciation that designates an op eration
that the element implements
When I say an element implements an Operation I mean that an instance receiving a message
of the typ e of the BehavioralElement will cause the implementation to re For the various Behav
ior alElement typ es this implementation is interpreted in di erentways For a Method a metho d is
invoked on the ob ject in question For an Event either a metho d is invoked in most event mo dels
or a signal is raised in older systems For a Channel either a message is inserted into a queue or a
read action completes Finally for a Tuple element either an ob ject is inserted into the tuplespace
or a read action on the space completes
Representation of Behavioral Elements Each of these b ehavioral elements should b e repre
sented in the same manner since they are all analogous in a mo del diagram The standard means
for sp ecifying metho ds on an ob ject is simply listing them in the op eration part of the class element
as in our previous examples of class diagrams
Each of our new BehavioralElements also has a signature In each case there is a destination
asp ect of the message and a set of typ es of messages that can b e accepted I will designate this with
a signature similar to that of a Method but lacking in the implicit order found in the parameters
the implicit of a Method Additionally I suggest sp ecifying Methods in the same manner with
assumption that the parameters are ordered and necessary unless otherwise sp eci ed More on this
point in Sections and
An example generalized sp eci cation of a class that accepts all four kinds of messages can be
seen in Figure Note that I have used stereotyp es to designate the typeofeach set of Behav
ioralElements
DRAFT NOT FOR DISTRIBUTION July
! event Example Class channel
tuple method
Figure New BehavioralElement syntax
While this uni cation of syntax is elegant it do es not provide a representational advance In fact
such a sp eci cation is longer and less clear than the original diagram So an alternative sp eci cation
syntax is necessary for each of the four BehavioralElement typ es Our suggested syntax can b e seen
in Figure
Finally Imust sp ecify the sp eci c semantics of the new metaclasses This only requires us to
widen the scop e of the current semantic de nition for Method to include Event Tuple andChannel
as follows in OCL
Channel Event Metho d Tuple
self specification exists op op isQuery implies self isQuery
self specification forAll op self hasSameSignature op
self specification forAll op self visibility op visibility
This completes the summary of our mo di cations to the UML metamo del to supp ort new b e
havioral interface sp eci cations
The Comp onent Element
Problem Two Core Comp onent Representation Comp onents are fundamentally di erent
than the standard classes and ob jects of ob ject oriented and ob ject based programming Surpris
ingly no existing mo deling language provides the appropriate core construct for describing the
software engineering comp onent
In fact the Component element of UML has very weak semantics when it comes to sp ecifying
comp onent based software More sp eci cally aComponent metaclass in UML is de ned as a
reusable part that provides the physical pac kaging of mo del elements This means that the UML
designers in trying to create a comp ositional metalevel architecture one that identi es things and
how they can b e plugged together they ignore comp onentarchitectures at the base non meta
level
Missing Features in Comp onent Sp eci cation
The primary features necessary in mo deling comp onents missing in current mo deling languages are
Outbound Interface All ob ject oriented mo deling languages fully supp ort the sp eci cation of
the inbound interface of an ob ject sometimes called the has side of the interface Surpris
DRAFT NOT FOR DISTRIBUTION July
Classifier
** Node Component deployment
** ModelElement SoftwareComponent
implementation
Figure Extending the UML metamo del with the SoftwareComp onent element
ingly no language p ermits the user to sp ecify the opp osite outbound interface sometimes
called the needs interface
Only Meyer s Design by Contract metho d and pro cess supp ort this two way sp eci cation
at its core UML can b e extended to supp ort such a description and I will provide just such
an extension
Properties and Attributes Comp onents that are ob jects have attributes that have sp ecial
semantic value These attributes are often called properties Examples of prop erties and their
related semantics can be seen in the JavaBeans comp onent mo del UML do es have
prop erties de ned as base constructs they are used to extend the language
These prop erties can be mapp ed to the prop erties of comp onent software but lack the ad
ditional semantics that standard prop erties havein comp onent software I will de ne these
additional semantics and apply them appropriately
Events and Methods Comp onent architectures use primarily use events to connect comp o
nents together Events are simply sp ecially named metho ds in the JavaBeans mo del but
b ecause they are events they have extra semantics that metho ds do not have I will make
the corrections to the representational mo del s semantics to accountforevents in comp onent
mo dels
Dep endencies and Associations Comp onents can have subtle dep endencies and asso ciations
not captured by the standard generalization and asso ciation constructs of UML I will do cu
ment some of these subtleties and provide the corresp onding extensions to UML primarily in
Section
I will represent a comp onent in the sense of a software comp onent from a comp ositional software
architecture by extending the existing UML metamo del element Component I will sp ecialize the
Component metaclass to a new SoftwareComponent metaclass that has additional semantics in order
to deal with the issues mentioned ab ove
Before I can sp ecify the additional semantics of SoftwareComponent I must discuss how to
visually represent this new construct
DRAFT NOT FOR DISTRIBUTION July
EventMessageBean Summonable remoteListenerTable: Vector sendQueue: Hashtable Runnable <
+setRemoteListenerTable(Vector)
Figure The EventMessageBean sp eci ed in UML
Visual Representation of SoftwareComponent
The new SoftwareComponent metaclass has in addition to the standard set of attributes and meth
ods a set of outb ound b ehavioral elements These are the b ehavioral elements on which the
comp onent depends in order to op erate prop erly
There are two parts to the sp eci cation of the needs elements of a comp onent K The rst
part is the macro level sp eci cation a list of the comp onents C fc c c g up on which
k
K dep ends The second part is the micro level sp eci cation a list B fb b b g where
k
b B j b c of the sp eci c behavioral elements of the comp onents up on which C
i i j
dep ends
These new needs elements are sp eci ed in one of three ways Most simply two new lower
divisions of the standard Class b ox can b e used Optionally the new elements can b e sp eci ed
through the use of a new stereotyp e The synonymous outbound needs or dependson are
suggested Cho osing between the alternatives dep ends up on your pro ject s terminology Finally
dep endency asso ciations can be denoted with real asso ciation links This last option is the most
illustrative but dep ends up on extensions to UML presented in the next subsection so I will defer
the example until then
Prop erties are attributes with sp ecial semantic value dep ending up on your comp onent archi
tecture I suggest using the same syntax for sp ecifying prop erties as one denotes attributes only
changing the font s style or weight Iusebold text to denote prop erties that are read only italic
text to denote prop erties that are write only and bold italic text to denote prop erties that are
read write
An Example The EventMessageBean
I will present a b ean called the EventMessageBean as an example of these mo deling techniques
First the standard UML diagram for EventMessageBean can b e seen in Figure
In the next illustration Figure the same bean is presented now with new class boxes
for outb ound interface dep endencies and sp eci cation as well as annotated prop erties Note that
the class names sp eci ed in the needs divisions of the illustration are abbreviated If there are
duplicate class names within a development scop e full class names would b e used instead
DRAFT NOT FOR DISTRIBUTION July
Note that the getRemoteListener() and setRemoteListener() methods are implicitly specified because the remoteListenerTable attribute is defined as a read-write property (since it is rendered in a bold-italic font). EventMessageBean
remoteListenerTable: Vector Summonable sendQueue: Hashtable Runnable <
PostThread.start()
Figure Using fontchanges to denote prop erties
EventMessageBean
remoteListenerTable: Vector Summonable sendQueue: Hashtable Runnable <
PostThread.start()
Figure An example of using stereotyp es to denote the full interface of a comp onent
DRAFT NOT FOR DISTRIBUTION July
EventMessageBean
remoteListenerTable: Vector Summonable sendQueue: Hashtable Runnable <
PostThread.start()
Figure Using event b ehavioral elements to denote the full interface of a comp onent
Next in Figure the same comp onent will be sp eci ed with the use of stereotyp es Note
how the comp onent s presentation is more cluttered
As mentioned ab ove events are used in many comp onent mo dels as the primary comp ositional
mechanism I have already discussed how to representevents with the Event element Using the
graphical event based syntax as discussed ab ove this same comp onent would be sp eci ed as in
Figure
Comp onent Asso ciations Finally comp onents exhibit subtle dep endencies and asso ciations
not captured with normal asso ciation mo dels UML s metamo del provides an Association meta
class which is sp eci ed as de ning a semantic relationship between classi ers An Association
has at least two AssociationEnds and an instance of an Association is a Link Additionally an
AssociationClass metaclass is de ned that is a multiple sp ecialization of b oth an Association and a
Class
I can create new asso ciation typ es for our purp oses with a stereotyp e applied to the Link instance
of an Association or the instance of an AssociationClass I prefer the second option b ecause it means
that asso ciations the relationships b etween comp onents are now rst class entities
Our new asso ciation typ es will b e fully describ ed b elow in Section
Partial Interface Sp eci cation Stereotyp e
Problem Three Partial Comp onent Interface Sp eci cation A comp onent K dep ends
up on a p otentially empty set of other comp onents C fC C C g K dep ends up on in
n
turn only some of the interface of each of these C comp onents I wish to describ e and exploit this
i
partial dep endency in comp onent sp eci cation
More sp eci cally each comp onent C that K dep ends up on has an interface sp eci cation I I
i
is comp osed of a set of b ehavioral elements I fB B B g But within the sp eci cation and
k
i
DRAFT NOT FOR DISTRIBUTION July
implementation of K only some subset I I is utilized Only I is necessary and su cientforK
to op erate safely and correctly Thus we need a mechanism for sp ecifying the partial interfaces of
comp onents
UML provides no such explicit mechanism What s worse UML provides no means bywhich one
can sp ecify whether a given construct is complete or not Meaning just b ecause a class diagram of
class k shows metho ds fm m g do es not mean that k has only those metho ds de ned up on it
n
So while we can p erform partial sp eci cation in UML indeed it is done all the time the semantic
ground of such a sp eci cation is incorrect
Catalysis provides types as previously discussed whichgoalongwaytoward solving this prob
lem Types p ermit the intentional partial sp eci cation of an interface b ecause typ es are only a
representational abstraction i e they are indep endentofarchitecture and engineering constraints
It must b e noted that UML has incorp orated the type construct through the use of a type
stereotyp e but the semantics of this stereotyp e are ill de ned This is likely the case b ecause
Catalysis was still in its infancy when UML was de ned and thus the formal de nition of Catalysis
derived elements in UML are as of yet ill de ned
Catalysis s typ e diagrams provide a means of sp ecifying ob ject state snapshots Meaning a typ e
diagram sp eci es a p otential ob ject instance its p otential legal and illegal states and its relationships
with other ob jects These diagrams are the rst step toward the ob ject network diagrams whichI
will discuss in Section
What is still missing from typ e diagrams is completeness semantics The completeness of the
sp eci cation of an ob ject in a typ e diagram is as ill de ned as in UML This convenience leads to
sloppy sp eci cation and the p otential for large errors in design due to asso ciation and state oversight
The Complete Partial and Su cient Stereotyp es
Iintro duce three new stereotyp es complete partial and su cient which will help sp ecify
partial interfaces for comp onents Before de ning these new elements I m ust mo dify the semantics
of the base metaclass Classi er See pg for the full details of the semantics of Classi er
up on which the following discussion is based
The metaclass Classi er has four asso ciations feature participant realization andspeci cation
Each of these asso ciations refers to a set of mo del elements some of which are realized in the
graphical representation of the Classi er sp ecializations Class Interface and others including our
SoftwareComponent
A number of metaop erations are de ned on Classi er which provide access to these lists of
and al lMethods I will use the related metaclasses Examples include al lFeatures al lOperations
metaop erations to de ne our two new stereotyp es
Classi er s semantics must b e mo di ed by conjoining a new predicate which describ es the default
state of the sp eci cation S of a Classi er with resp ect to our new stereotyp es
Default Completeness of Sp eci cation
The default state of any description of a classi er s asso ciations is complete More precisely let
S fs s s g is a sp eci cation for classi er C Each s is a sp eci cation of a single b ehavioral
n i
DRAFT NOT FOR DISTRIBUTION July
EventMessageBean
remoteListenerTable: Vector OutputChannelManagementInterface MessageSendingListener <
! InfoNetOutputChannel RemoteListener EventMessage ......
InfoNetOutputChannel(Vector) InfoNetOutputChannel.send(EventMessage) InfoNetOutputChannel.destroy()
......
Figure An example partial class sp eci cation using ellipses
EventMessageBean <
remoteListenerTable: Vector OutputChannelManagementInterface <
InfoNetOutputChannel(Vector) ! InfoNetOutputChannel.send(EventMessage) RemoteListener
InfoNetOutputChannel.destroy() EventMessage
Figure An example partial class sp eci cation using the partial stereotyp e
element from one of the four asso ciation sets of C feature participant realization andspeci cation
mentioned ab ove
If an asso ciation set A has at least one behavioral element sp eci ed then by default al l b ehavioral
elements of A must b e sp eci ed within S The default complete stereotyp e is implicitly applied
to the sp eci cation It can b e explicitly presented on a sp eci cation for clarity but it is unnecessary
Partial and Su cient Sp eci cation
If a sp eci cation fails to ful ll this requirement the it falls into one of two categories it is either
intentionally partial e g an example or is a su cient sp eci cation
If a sp eci cation is intentionally incomplete it should b e tagged with the partial stereotyp e
or should use some other means of indicating that b ehavioral elements are missing e g ellipses or
the like can b e used Two examples of such a sp eci cation can b e seen in Figures and
A sp eci cation that is su cient is one that is intentionally do cumenting exactly those behavioral
elements that are su cient in the speci cation context Such a sp eci cation should b e tagged with
the su cient stereotyp e An example of a partial sp eci cation can b e seen in Figure Note
that in the left diagram the Hashtable class dep ends up on the Comparable interface whereas in the
right diagram it dep ends only up on the partial sp eci cation of Element namely the compareTo
DRAFT NOT FOR DISTRIBUTION July
Hashtable <
Object.hashcode()
Figure Two example class diagrams featuring the su cient stereotyp e
AB Association
Dependency Generalization CD
Aggregation
Figure The basic forms of asso ciation
metho d
Through the rigorous use of these new stereotyp es we can now de ne partial dep endencies
between comp onents Such stereotyp es can be applied not only to all instances of the metaclass
Classi er to all ModelElements within UML The same application holds true for Catalysis and
OOCL
Re nements for Asso ciations
Problem Four Comp onent Asso ciations The asso ciation related metaclasses in the UML
metamo del supp ort the sp eci cation of several di erent kinds of relationships b etween mo del ele
ments The two base classes of asso ciations are Association and AssociationClass
An asso ciation is de ned as a semantic relationship between classi ers The most com
monly used asso ciations see Figure are references where a class A hasaninstancevariable
that refers to class B and aggregations where a class C contains and a class D Several extra
relationship typ es are also shown In particular C dep ends on A and B is a generalization of D
All of these asso ciations and relationships have re nements There are several re ned versions
of aggregation in UML including shared aggregation where elements can b e memb ers of several con
tainers and compositional aggregation in which containers own their parts Generalizations have
default constraints de ned so that overlapping disjoint complete and incomplete generalizations
can b e represented
All of these asso ciation and generalization re nements are de ned through the use of stereotyp es
and constraints Most of the basic relationships for ob ject oriented systems are covered by the
core standard elements of UML On the other hand some of the more comp onent and network
oriented relationships that exist in comp onentarchitectures esp ecially distributed ones can not b e
mo deled in UML
DRAFT NOT FOR DISTRIBUTION July
Relationships in Distributed Comp onentArchitectures
I will identify several kinds of relationships exhibited in distributed comp onentarchitectures Each
will b e denoted with the use of a stereotyp e when applied to an asso ciation link Alternatively an
asso ciation link s graphical representation could b e mo di ed line thickness color style etc I only
suggest using this approach with ob ject asso ciations within sp eci c diagrams b ecause I b elievethat
there are already enough suchstyles in the core of UML Adding manymorewould only increase
the p ossibility for diagram misinterpretation and steep en the UML learning curve
The following is a list of all the asso ciation typ es I haveidenti ed
Standardlocal reference no stereotyp e necessary
A standard lo cal reference is the normal reference typ e as de ned in UML E g a p ointer in
C or a reference in Java are legitimate standard lo cal references
Garbage Col lector ReferenceTypes e g Java
Guardedreference guarded
A guarded reference is the strongest typ e of reference ob ject If the garbage collector
determines at a certain p oint in time that the referent of a registered guarded reference
is no longer strongly reachable then at some later time the collector will enqueue the
guarded reference
Weak reference weak
A weak reference is a reference ob ject that do es not prevent its referent from b eing
made nalizable nalized and then reclaimed If the garbage collector determines at a
certain p oint in time that an ob ject is no longer strongly reachable and has no guarded
references then at that time it will clear all weak references to the ob ject simultaneously
and atomically from the standp oint of the program
Phantom reference phantom
A phantom reference is a reference ob ject that remains valid after the collector determines
that its referent is otherwise eligible for reclamation If the garbage collector determines
at a certain p oint in time that the referent of a registered phantom reference is no longer
strongly reachable has no guarded or weak references and has been nalized then at
some later time the collector will enqueue the reference
Soft referenc e soft
As the amount of memory available to the Java heap decreases an instance of this class
may be cleared automatically if its referent is reachable only via soft references and
p erhaps via some guarded weak or phantom references Soft references are cleared in
approximate least recently used order A best e ort is made to clear all soft references
b efore the virtual machine throws an OutOfMemoryError
Indirect association indirect
All of the following de nitions are taken directly from the JDK b eta javado cs for the java lang ref package
See the do cumentation on java lang ref Reference for the de nition of strongly reachable The de nitions are
c
Copyright Sun Microsystems Inc
DRAFT NOT FOR DISTRIBUTION July
An indirect asso ciation is exactly that a asso ciation which is obtainable via one or more levels
of indirection Typical examples of indirect asso ciations include a the standard p ointer to
pointer or ref to ref in C and C resp ectively b areferencetoanentry in a data store of
some kind a database a Web page element etc c a reference to an active ob ject which
when queried will resp ond with the asso ciation in question Indirect asso ciations are usually
only do cumented if the obtainable resource is reachable with a single level of indirection and
is directly relevant to the construct b eing sp eci ed i e not extraneous
Renewable association renewable
A renewable asso ciation is a weak reference by name to an entitywhichmay not b e immedi
ately accessible Such asso ciations are used for cached ob jects and services transient network
links and the like The semantics of the renewal op eration are such that the renewable en
tity can b e retrieved in nite time by some system service Examples of renewable asso ciations
include DNS names URLs URNs etc
Mobile association mobile
A mobile asso ciation is a reference to a mobile entity Suchanentity mightbeasoftware agent
as a mobile phone an automobile or even a battleship Such asso ciations are often renewable
well
Constant association const
A constant asso ciation is a reference whichisimmutable
Channel association channel
A channel asso ciation is a asso ciation b etween two comp onents through a channel b ehavioral
element See Section for more information on channels An example of a typical channel
asso ciation is any middleware layer that uses a connection oriented mechanism
Event association event
A event asso ciation is a asso ciation b etween two comp onents through a event b ehavioral el
ement See Section for more information on events An example of a typical event
asso ciation are the asso ciations connecting comp osed JavaBeans
Method association method
A method asso ciation is a asso ciation b etween two comp onents through a metho d b ehavioral
element See Section for more information on metho ds Note that some ob ject oriented
languages e g Java do not have metho d references Others e g C and CLOS use them
frequently
Tuple association tuple
A tuple asso ciation is a asso ciation b etween two comp onents through a tuple b ehavioral ele
ment See Section for more information on tuples
Re ective association re ective
DRAFT NOT FOR DISTRIBUTION July
A re ective asso ciation is a asso ciation b etween twoentities obtained at runtime via a re ection
mechanism Relationships b etween JavaBean comp osition to ols and the b eans that they con
tain are re ective asso ciations Examples of re ective asso ciations are those used throughout
the CLOS runtime
Meta association meta
A meta asso ciation is a asso ciation obtained via one or more op erations at a meta layer of an
architecture Many of the asso ciations in the implementation of CLOS are meta asso ciations
Semantic association semantic
A semantic asso ciation is an asso ciation b etween entities that is obtained and supp orted by
some kind of semantic information I will discuss such asso ciations in a bit more detail in
Section An example of such an asso ciation is two ob jects sharing knowledge whichis
utilized to realize a communication mechanism such as Sims SDOs
Persistent association persistent
The persistent asso ciation is an asso ciation which lasts across life cycles of the participating
entities
Note that if an ob ject A has any lo cal asso ciation with another ob ject B it implicitly has a
standard local reference Thus the syntax of the language a standard asso ciation is visually
represented by a solid line
Ob ject Network Diagrams
Problem Five Dynamic and Emergent Structures of Comp onents Comp onents are con
nected together in a large number of ways as discussed in the previous section Collab orative
collections of comp onents when viewed at a high level have inherent structure physical and virtual
patterns in a visual sense are exhibited by complex systems
ct or component networks I will describ e these ob ject networks in I will call these patterns obje
a new diagram typ e called an Object Network Diagram
To e ciently describ e these ob ject networks we need new representational constructs for com
p onents and asso ciations Existing constructs that of the class boxes for classes ob jects and
comp onents and the annotated directed line segments for asso ciations are to o large and unwieldy
for the large scale structures we wish to describ e
The constructs that I am going to describ e are primarily inspired by the mo deling constructs
used bychemists and biologists to describ e molecular structures and reactions
New Mo deling Constructs for Ob ject Network Diagrams
My new constructs for the entities that make up an ob ject network are summarized in Figure
The novel constructs are de ned as follows
Agent An agentisany instance that has an autonomous thread of control and is acting toward
the accomplishment of a particular goal An entity that contains a thread as in the agent
example means that the entity has its own thread of control i e is not solely reactive
DRAFT NOT FOR DISTRIBUTION July
Class Object Type
Metalevel
Agent
Component Kind
Figure Summary of new representational entities for ob ject network diagrams
Type A type is a metaclassi er for classes and ob jects as p er typ e theory see
In some languages like C typ e and class are equivalent
Kind A kind is a semantic metaclassi er for typ es See Section for more information on
kinds
Metalevels Metalevel sp eci cation are denoted with the ghosting annotation as seen in
Figure The numb er of ghosts indicate the metalevel of the construct
The new constructs for asso ciations are based up on the asso ciation typ es describ ed in Sec
tion Because I want these diagrams to be as compact and informative as p ossible I will
denote the typ es of asso ciations with sets of line segments or curves or varying thickness and color
These new relationship asso ciation constructs are shown in Figures and Note that the
constructs shown in Figure are annotations that can b e applied to all of the asso ciations de ned
in the mo deling language
All of these asso ciation typ es were summarized in Section
Ob ject Network Diagram Semantics
An Object Network Diagram do cuments the asso ciations b etween collections of comp onents primar
ily in distributed comp onentarchitectures
The comp ositional units in an ob ject network diagram are recursive i e comp onents are p o
tentially comp osed entities with aggregations collections etc Normally these comp ositions would
b e hidden with encapsulation simplifying the mo del and the resulting design When rendering an
ob ject network diagram these reusable subunits are often rendered in full detail Maintaining this
level of detail p ermits the designer to represent and recognize p otential reuse within the system
Typical subunits in standard systems are subsystems of reusable packages like collections algo
rithms and data structures Subunits in distributed systems come in many forms system services
UI client comp onents mid tier business ob jects data stores etc
Each ob ject network diagram has a focus The fo cus of an ob ject network diagram are those
ob jects that are the primary ob jects b eing describ ed in the diagram The only elements that are
necessarily represented in an ob ject network diagram are only exactly those objects directly associated
DRAFT NOT FOR DISTRIBUTION July
standard reference channel association
! !
guarded reference event association
weak reference method association
phantom reference tuple association
indirect association reflective association
renewable association mobile association
semantic association
Figure New representational entities for ob ject network asso ciations and relationships
DRAFT NOT FOR DISTRIBUTION July
constant association persistent association
meta association
Figure Three new annotation constructs for asso ciations
with the focus objects All other ob jects are extraneous and while not necessary mightbeusefulin
recognizing reuse patterns etc
Entities within ob ject network diagrams can also b e annotated with component valences The
valency of a comp onent is the numb er of asso ciations unsp eci ed in a given mo del The valency of
a comp onent is indicated by annotating the entity name or construct with a small k where k is
the valency of the entity is shorthand for
Example Ob ject Network Diagram The Web Architecture
An example ob ject network diagram describing a typical Web client server scenario is seen in Fig
ure The fo cus ob jects are the Web browser and the web server browser core and server
core resp ectively
Through the rigorous use of ob ject network diagrams and their related constructs the sp eci ca
tion of dynamic distributed comp onent systems can b e more e cient clear comprehensive and
exible
The Kind Stereotyp e and Role
Problem Six Tying Knowledge Semantics to Comp onents One of the next ma jor steps
in our research agenda is developing the theory and means by which formal semantics can b e related
to a knowledge representation and software instantiation of a system and its elements
The semantic asso ciation typ e mentioned previously and the hints at future work in Sections
and b egin to touch on the issues surrounding the need to attach precise and extensible semantics
to knowledge based comp onent software
The core elementinourinvestigations in this domain is a new metaclass called Kind A kind is
the next level of abstraction ab ove type twolevels ab ove class Two comp onents are of the same
kind if they are semantically compatible given a semantic context This topic is within our primary
research direction for the next several years
In the short term I will de ne a new stereotyp e kind that can b e applied to arbitrary mo deling
elements to denote semantic compatibility or interop erability I will not provide any examples of
et fully realized and it is premature such usage b ecause the formal underpinnings of kinds are not y
to provide concrete examples
DRAFT NOT FOR DISTRIBUTION July
Persistent Agent Store Security
CGI SHTML Interface Parser
Server HTML Core Cookie Parser Server
+6 Java Runtime HTTP Handler
Agent Servlets
<
HTTP Handler
XML Parser Security
SGML HTML Browser Parser Parser Core
HTML UI Persistent Renderer Store Forms Cache Presenter !
..... ! Image Renderer Input Handler cached objects
! +7 Java ! Runtime Java Agents
....
Java Applets
Figure An example ob ject network a standard Web client server system
DRAFT NOT FOR DISTRIBUTION July
This concludes our rst set of extensions to current mo deling languages that constitutes the base
extension elements of DESML In the next chapter I will describ e the Infospheres Infrastructure a
framework we built to demonstrate comp onent based dynamic autonomous ob ject systems
DRAFT NOT FOR DISTRIBUTION July
Chapter
The Infospheres Infrastructure
The rst version of the Infospheres Infrastructure II for short is a rst pass design and implemen
tation of a comp onent based dynamic autonomous active ob ject infrastructure The II provides
a framework for building dynamic distributed systems comp osed of active Java ob jects that
communicate using messages
The II is an extensive framework Since this do cument is meant to fo cus sp eci cally on
mo deling dynamic distributed systems I will only brie y describ e the core and relevant asp ects of
II here The II is do cumented in full in the Infospheres Infrastructure User s Guide and
is available for download via the group s Web site at http www infospheres caltech edu
Infospheres Infrastructure History
The II was designed and built in late th us exclusively used the Java language and
technologies Its initial version the alpha release was built by a group of undergraduates managed
bymyself The infrastructure was then redesigned and completely rewritten but for the info net
package by this author Other groups memb ers also contributed a great deal of help with late design
work some implementation and bug tracking and xing
A new infrastructure II is being designed and built at this time mid We have
taken what wehave learned in building II added in new features found in Java and
App endix C and incorp orated a new ob ject mo del that synthesizes the standard dynamic
distributed system s ob ject mo del with the Web ob ject mo del More information on II can b e
foundin and
The Infospheres Infrastructure Requirements Analysis
Our research goals dictate an infrastructure that must supp ort the comp osition of distributed p er
sistent opaque comp onents with dynamic interfaces Additionally these comp onents must b e able
b oth synchronous and asynchronous collab orations I will brie y discuss these to participate in
requirements here then describ e the system design
Portions of this chapter mightbetaken from previously published material including
DRAFT NOT FOR DISTRIBUTION July
Opaque Distributed Software Comp onents
The only visible asp ects of an opaque comp onent are i its external interface so that other comp o
nents can connect to it and ii a sp eci cation of the comp onent In a distributed system comp onent
interfaces are sp eci ed in one of four ways
Remote Invo cation The most prevalentinterface sp eci cation metho d is pro cedure or metho d
based Remote pro cedure call RPCs have b een used as a simple interface sp eci cation
technique for manyyears Remote metho d invo cation RMI essentially ob ject
technology centric RPCs as a ob ject sp eci cation technique has gained p opularitywith the
rise in use of ob ject oriented languages esp ecially Java
Events Events are messages with extra system semantic meaning Events are gaining p opular
ity as a general purp ose communication framework esp ecially in publish subscrib e and push
technologies
Message Passing Sp eci cation with resp ect to a comp onent s sending and receiving messages is
an alternative technique
A more unusual but equivalent sp eci cation technique is to describ e State Space Op erations
comp onents with resp ect to the ways in which they can access and mo dify their environment s
state space p erhaps via Z coupled with Linda as in Most non ob ject oriented sp eci
cation languages fall into this category b ecause encapsulation is not a ground concept of the
sp eci cation language
Each approach has advantages and disadvantages but the sp eci c form of the interface is less
imp ortant than the fact that the comp onent implementation is hidden The infrastructure must
supp ort at least one of these metho ds of interface sp eci cation
Dynamic Interfaces and Interactions
A comp onentmust be able to adapt to changing conditions in a computation These include the
addition of new comp onents to the computation temp orary unavailability of communications re
sources and other common situations which arise in Internet based distributed systems One wayto
deal with the dynamic environmentistoallow a comp onenttochange its interface and connections
to other comp onents during the course of a computation so we require that the infrastructure allow
comp onentinterfaces and interconnections to b e completely dynamic
Mo des of Collab oration
All comp onents participating in a synchronous collab oration must b e active concurrently By con
trast comp onents participating in an asynchronous collab oration need not b e active concurrently
any given comp onent may be quiescent and show activity only when necessary e g a message
arrives for it The advantage of asynchronous collab oration is that the participating comp onents
need not hold resources concurrently since they use resources only when they are computing The
disadvantage is that handling an incoming communication can b e exp ensive b ecause the commu
nication must b e handled by a daemon that activates the quiescent comp onent and then forwards
DRAFT NOT FOR DISTRIBUTION July
the communication Because of this tradeo we require the infrastructure to supp ort b oth syn
chronous and asynchronous interactions allowing individual comp onent application develop ers to
cho ose whichever mo de is appropriate for their application
Persistence
Comp onents must be p ersistent because a collab oration involving a set of comp onents may last
for years Rather than requiring a comp onent to stay active for the life of its collab orations it is
advantageous to design the comp onent system such that the life cycle of a comp onent is a sequence
of active phases separated by quiescent phases In such a system when a comp onent is quiescent its
state is serialized and can for example b e stored in a le and the comp onent uses no computing
resources
When a comp onent is active it executes in a pro cess slot or thread and listens for communi
cations Comp onents designed in this way are often quiescent for most of their lifetimes so the
fact that quiescent comp onents use no computing resources allows many more comp onents to exist
in the network and system simultaneously than would otherwise be p ossible The infrastructure
must supp ort the storage of p ersistent state information by individual comp onents In addition it
is desirable for it to provide some metho d of e ciently up dating p ersistent state information such
as bysaving only incremental changes
The Infospheres Infrastructure Design
In this section I will brie y describ e the Infospheres Infrastructure version and
showhow it satis es the requirements identi ed in section
Infospheres Framework
personal networks enable long term col The II framework employs three structuring mechanisms
lab orations b etween p eople or groups sessions provide a mechanism for carrying out the short term
tasks necessary within p ersonal networks and infospheres allow for the customization of pro cesses
and p ersonal networks
As an illustration of these structuring mechanisms consider a consortium of research institutions
working on a common problem This consortium has a p ersonal network comp osed of pro cesses that
b elong to the infospheres of the consortium members This p ersonal network provides a structured
way to manage the collection of resources communication channels and pro cesses used in distributed
tasks such as determining meeting times and querying distributed databases Each session of this
p ersonal network handles the acquisition use and release of resources pro cesses and channels for
the life of one sp eci c task
Infospheres are discussed in detail as part of the user s guide to our framework Here I will
fo cus on the conceptual mo dels for pro cesses p ersonal networks and sessions
DRAFT NOT FOR DISTRIBUTION July
Conceptual Mo del Pro cesses
Pro cesses are the p ersistentcommunicating comp onents which manage interfaces and devices In
our framework we call these pro cesses djinns
Pro cess States
Agiven pro cess can b e in one of three states active waiting and frozen An active pro cess has at
least one executing thread it can change its state and p erform any tasks it has p ending including
communications Awaiting pro cess has no executing threads its state remains unchanged while it
is waiting and it remains in the waiting state until one of a sp eci ed set of input p orts b ecomes
nonempty at which p ointit b ecomes active and resumes execution Activeand waiting pro cesses
are collectively referred to as ready pro cesses
Ready pro cesses occupy either i thread groups within a Java virtual machine or ii pro cess
slots in the OS pro cess table Both can make use of other resources provided by the op erating
system By contrast pro cesses in the frozen state do not o ccupyany active system resources and
cannot make use of any other resources provided by the op erating system The only resource used
by a frozen pro cess is the storage space such as a small le or a database entry which holds pro cess
state information
Freezing Summoning and Thawing Pro cesses
Each pro cess has a freeze metho d whichsaves the state of the pro cess to a p ersistent store and a
thaw metho d which restores the pro cess state from the store Atypical pro cess remains in the frozen
state nearly all the time and therefore consumes minimal system resources In our framework only
waiting pro cesses can be frozen and they can be frozen only at pro cess sp eci ed p oints Except
for its p ersistent store all system resources held by a pro cess are yielded when its freeze metho d is
invoked
A ready pro cess can summon another pro cess If a pro cess is frozen when it is summoned
the summons instantiates the frozen pro cess causes its thaw metho d to be invoked and initiates
a transition to the ready state If a pro cess is ready when it is summoned it remains ready In
either case a summoned pro cess remains ready until either it receives at least one message from its
summoner or a sp eci ed timeout interval elapses
Conceptual Mo del Personal Networks
A p ersonal network consists of an arrangement of pro cesses and a set of directed typ ed secure
communication channels connecting pro cess output p orts to pro cess input p orts Its top ology can
b e represented by a lab eled directed graph where each no de is a pro cess and eachedgeisa commu
nication channel lab eled with its typ e and the input and output p orts connected bythatchannel
Since pro cesses can freely create input p orts output p orts and channels the top ology of a p ersonal
network is completely dynamic
DRAFT NOT FOR DISTRIBUTION July
buyer1: Buyer Company A seller: Seller Company B bid: Money bid: Money
buyer2: Buyer licenser: Business
seller: Seller licensee: Business
retailer: Retailer Individual C Enterprise D
chain: Seller
Figure An example p ersonal network
Communication Structures
Pro cesses communicate with each other by passing messages Each pro cess has a set of inboxes and
outboxes collectively called mailboxes Every mailb ox has an asso ciated typ e and access control list
b oth of which are used to enforce p ersonal network structure and security
A connection is a rst in rst out directed secure error free broadcast channel from the outb ox
to each connected inbox In our framework connections are asymmetric a pro cess can construct
a connection from any of its outb oxes to any set of inboxes for which it has references but cannot
construct a connection from an outb ox b elonging to another pro cess to any of its inboxes
Comp onents also communicate with each other by sending and receiving servicerequests Each
comp onent has the option of implementing a service channel A service channel is a single p ointof
contact for the comp onent We exp ect that the one service p er comp onent mo del wehave witnessed
in comp onent software to date will continue
k Example services include a word check for a sp elling checker comp onent a date query for a clo c
comp onent a database lo okup for a query comp onent attached to a database etc
Message Delivery
Our framework s communication layer called info net works by removing the message at the head
of a nonempty outb ox and app ending a copy to each connected inbox If the communication layer
cannot deliver a message it raises an exception in the sender containing the message the destination
inbox and the sp eci c error condition The system uses a sliding window proto col to manage the
messages in transit
The communication layer eventually handles every message at the head of an outb ox The
conceptual mo del uses asynchronous messages rather than remote pro cedure calls b ecause the range
of message latencies across the Internet makes message passing with synchronous remote pro cedure
calls impractical However the structure of our communication layer allows us to consider message
delivery from an outb ox to inboxes as a simple synchronous op eration even though the actual
implementation is complex and asynchronous
DRAFT NOT F OR DISTRIBUTION July
Dynamic Structures
A pro cess can create delete and change its mailb oxes in addition to as mentioned ab ove b eing able
to create and delete connections b etween its outb oxes and other pro cesses inboxes The op eration
of creating a mailb ox returns a global reference to that mailb ox that can then b e passed in messages
to other pro cesses Since a pro cess can change its connections and mailb oxes the top ology of a
p ersonal network can evolveover time as required to p erform new tasks
When a pro cess is frozen all references to its mailb oxes b ecome invalid This invalidation of
mailb ox references allows frozen pro cesses to move and then b e thawed atwhichpoint the references
to its mailb oxes can b e refreshed via a summons
Conceptual Mo del Sessions
A session encapsulates a task carried out by the pro cesses in a p ersonal network It is initiated
by some pro cess in the p ersonal network and is completed when the task has b een accomplished A
work consists later session with the same pro cesses may carry out another task Thus a p ersonal net
of a group of pro cesses in a sp eci ed top ology interacting in sessions to p erform tasks
The Session Constraint
Weadopttheconvention that every session must satisfy the twopartsession constraint
As long as any pro cess within the session holds a reference to a mailb ox b elonging to another
pro cess within the session that reference must remain valid
A mailb ox s access control list cannot b e constricted as long as any other pro cess in the session
holds a reference to that mailb ox
The session constraint ensures that during a session information ows correctly b etween pro
cesses An imp ortant corollary to the session constraint is that b ecause no valid references to their
mailb oxes exist frozen pro cesses cannot participate in sessions
A session is usually started by the pro cess initially charged with accomplishing a task This
pro cess referred to as the initiator creates a session by summoning the pro cesses that will initially
participate It then obtains references to their mailb oxes passes these references to the other
pro cesses and makes the appropriate connections between its outb oxes and the inbo xes of the
participating pro cesses
There are many ways of satisfying the session constraint One simple way is to ensure that
every pro cess participating in a given session remains ready until that session terminates and that
once a pro cess sends a given mailb ox reference to another pro cess in the session it leaves that
mailb ox unchanged for the duration of the session Another approach is to have the initiating
pro cess detect the completion of the task using a di using computation or other common termination
detection algorithm after which it can inform the other session memb ers that the session can safely
b e disbanded
DRAFT NOT FOR DISTRIBUTION July
Example of a Session
An example of a session is the task of determining an acceptable meeting time and place for a
quorum of committee members Each committee memb er has an infosphere containing a calendar
pro cess that manages his or her app ointments A p ersonal network describ es the top ology of these
calendar pro cesses A session initiator sets up the network connections in this p ersonal network
The pro cesses negotiate to nd an acceptable meeting time or to determine that no suitable time
exists The task completes the session ends and the pro cesses freeze Note that the framework
do es not require that pro cesses freeze when the session terminates but that this will usually b e the
case
Communication Within Sessions
During a session it is vital that the pro cesses receive the quality of service required to accom
Therefore communication is routed directly from pro cess to pro cess rather than plish their task
through ob ject request brokers or intermediate pro cesses as in client server systems Once a session
is constructed our framework s only communication role is to cho ose the appropriate proto cols and
channels A session can negotiate with the underlying communication layer to determine the most
appropriate pro cess to pro cess mechanism While the current framework supp orts only UDP and
nativeJava messaging layers like RMI the incorp oration of alternativecommunication layers like
Ub ernet iBus JavaACE or JSDA is straightforward
The Infospheres Infrastructure Sp eci cation
Iwill provide a detailed sp eci cation of only one core subsystem info djinn of II here due
to space considerations I will informally describ e several of the other system comp onents of II to
provide the reader with su cientcontext for the details in Section
The Messaging Subsystem
The messaging subsystem is contained in the package info net It provides a asynchronous
mailb ox based messaging system muchlik e the CSP mo del built on top of UDP
The use case and class diagrams for info net are provided The use case diagrams are Fig
ures
The partial class diagrams for info net are found in Figures and I only include
a partial class diagram b ecause the info net package has thirty eight classes All core classes are
included in these gures Also rather than show all the asso ciations b etween the classes of info net
I am only presenting the generalization relationships and full ob ject sp eci cations
Main Classes
info net has nine main classes
Broadcastbox Broadcastbox is a single Mailbox that maintains a set of destination places
see the de nition of Place below The user can add or remove places and send messages to
all of the places at once
DRAFT NOT FOR DISTRIBUTION July
Initialize
Manipulate
Send and Receive info.net programmer
Shutdown
Figure info net use case diagram top level
Initialize MailDaemon
Construct Outbox (Broadcastbox, Multicastbox, Sendbox)
Construct Inbox (Receivebox) info.net programmer
Construct and Specify Filter
Construct ReceiveSet
Figure info net use case diagram initialization
Check Inbox (for messages and metadata about messages)
Bind Outbox
info.net programmer
Construct Place
Figure info net use case diagram manipulation
DRAFT NOT FOR DISTRIBUTION July
Send Message
Receive Message
info.net programmer
Construct Message
Figure info net use case diagram sending and receiving
Destroy Mailbox
info.net
programmer Shutdown MailDaemon
Figure info net use case diagram shutdown
DRAFT NOT FOR DISTRIBUTION July
Figure info net class diagram messages
DRAFT NOT FOR DISTRIBUTION July
Figure info net class diagram mailb oxes
DRAFT NOT FOR DISTRIBUTION July
Figure info net class diagram core classes
DRAFT NOT FOR DISTRIBUTION July
Broadcastbox ensures that no Place is duplicated in the set Rep eated adds will silently fail
On a send command each Place in the set receives exactly one copy of the message
The di erence b etween a Broadcastbox and a Multicastbox see b elow is the proto col used
for message transfer unicast for the former multicast for the latter
Filter The Filter class is used by inboxes to check messages b efore accepting them into
the queue Filters can be used in many ways For example one can ensure there are only
NumberMessages in the queue or one might make the queue only accept messages from a
sp eci c Place To install a Filter in an inbox use its setFilter metho d and pass to it
the Filter you want to use
The CheckMessage metho d do es the actual ltering It takes a Message and the place that
sent it decides whether to accept or deny it and returns a b o olean based up on that decision
Thus to install new b ehavior a develop er overrides the CheckMessage metho d By default
CheckMessage calls SendDenial to send a DenyMessage to the sending mailb oxofany message
do es not pass the Filter
Each Filter can be asso ciated with one and only one Inbox If you attempt to use the
same Filter on more than one Inbox either by using setFilter or by construction all
DenyMessages generated bythe Filter will have the most recent Inbox to which the Filter
has b een assigned as a source
MailDaemon The MailDaemon is the ob ject that manages the mailb oxes of a djinn It p erforms
reliable ordered message passing and mailb ox management on b ehalf of the djinn
Mailb oxes in a djinn are registered with its maildaemon with mailb ox constructors The
maildaemon then listens on a p ort for messages addressed to its incoming mailb oxes and
pro cesses those messages by putting them in the inb ound queues of the appropriate incoming
mailb oxes It also delivers messages from the outb ound queues of outgoing mailb oxes to the
appropriate destination mailb oxes which are often on a di erent host
Message Message is the abstract class that is the parent of all ob jects sent through the
mailb oxes To create a new message class a develop er inherits from this base class to create a
new public child class The public metho ds writeData and readData mustbeoverridden
so that the new message is serialized and deserialized prop erly In addition the class needs a
public default constructor that takes no arguments
Any message class can have a URL asso ciated with it These URLs are sent along with the
messages to serve as a globally unique ID This ensures that if a message arrives at a lo cation
it is either recognized correctly or is recognized as b eing an unknown message typ e
If a message of unknown typ e arrives a remote class loader is invoked by the maildaemon
the class asso ciated with the message and URL is loaded remotely if p ossible Before and
such drastic actions are taken however the URL is checked with the Message class s static
URLStringSecurity ob ject
Multicastbox Multicastbox is a single Mailbox that maintains a set of destination places The
user can add or remove places and send messages to all of the places at once Multicastbox
DRAFT NOT FOR DISTRIBUTION July
ensures that no Place is duplicated in the set Rep eated adds will silently fail On invo cation
send each place in the set receives exactly one copy of the message
As mentioned ab ove the di erence b etween a Broadcastbox and a Multicastbox is the pro
to col used for message transfer unicast for the former multicast for the latter
Place The Place ob ject serves as a unique name for mailb oxes of all sorts Its main use is to
uniquely name inboxes agiven mailb ox has a unique Place
A Place has three comp onents a machine address i e an InetAddress ob ject like frankie
cs caltech edu a p ort numb er and a mailb ox name a String ob ject There are many
di erent constructors for a Place given the variety of contexts in which it will be used A
Place ob ject is immutable
ceivebox Receivebox receives messages from a maildaemon and inserts them in a queue Re
Messages can b e removed from the inb ound queue using the receive metho d If there are
no messages in the queue receive blo cks until there are There are other metho ds that allow
greater control over the receiveb ox suchasthe empty metho d that checks whether the queue
is currently empty and the waitForMessage metho d that waits for a message to arrivein
the queue
In addition two other variables are asso ciated each Message the lo cal time stamp which
allows for complete ordering of all messages received lo cally by time of arrival and the return
address which is the address of the mailb ox that sent the message Use the time and
from metho ds which act on the oldest message in the queue to access these twovariables
ReceiveSet ReceiveSet collects m ultiple inboxes in a set One can wait for a new message
on the entire set or get the oldest message in the set of queues asso ciated with the inboxes
in the receiveset Mailb oxes can b e added and removed from this set allowing for a dynamic
collection of receive mailb oxes
Sendbox A sendb ox class is an outb ound channel endp oint exclusively supp orting p oint to
point communication Once connected to a receiveb ox using the bind metho d a sendb ox
can send messages to the b ound receiveb ox Atany p oint a program can dynamically re bind
to another receiveb ox using the bind metho d Any messages sent from that p ointonward will
be sent to the newly b ound inbox Bindings are accomplished by passing the bind metho d a
Place ob ject that has the address of the desired inbox
In summary info net p ermits our comp onents to exhibit dynamic communication interfaces
app ear disapp ear and change their b ehavior over time Note that the Mailb oxes which can
mo deling the semantics of mailb oxes and arbitrary messaging layers requires the use of the new
comp onentinterface sp eci cation stereotyp e as describ ed in Section
For the reader interested in more information ab out the info net package please see Chap
ter
The Djinn Master
The Djinn Master is the p ersonal mini ORB that is at the core of the II run time It is a djinn like
any other comp onent in the II and is resp onsible for several services
DRAFT NOT FOR DISTRIBUTION July
Instantiation When djinn A wishes to communicate with djinn B it sends a summons message
to the Djinn Master DM resp onsible for B DM is resp onsible for determining if the
B B
summons is valid p erforming a lo okup on the summoned djinn s implementation and metadata
instantiating initializing and starting the djinn
The metadata asso ciated with B consists of its implementation rep ository lo cation its
implementation name its run time instantiation mo de and its run time con guration
mo de
B s run time instantiation mo de has two p ossible states B can run either as a set of
threads organized in a Java ThreadGroup within DM called thread mo de or it can run
B
as an indep endent pro cess within the host machine s op erating system appropriately called
process mo de Because all communication between A B and DM is accomplished with
B
messages there are no shared memory segments references etc these two execution mo dels
are indistinguishable at the co de level
B s run time con guration mo de can b e in one of three states
InstanceMode B can run in instance mo de In instance mo de eachandevery summons
message arriving at DM causes DM to instantiate a new instance of B This is imple
B B
mented in the natural manner if the djinn is in thread mo de a new threadgroup and set
of threads are constructed and started otherwise a new pro cess is executed by DM
B
Server Mode The second mo de is called server mo de In server mo de new summons
arriving at DM for djinns of the same name as B causes DM to virtually instantiate
B B
a new thread of control within B
This virtual instantiation is accomplished by either forwarding the summons message
to B whether it is running in thread or process mo de The info djinn package handles
this forwarded message and instantiates a new thread within the context of B to handle
the invo cation
Server mo de is primarily used for those ob jects which provide a sp eci c and usually
singular service to one or more other ob jects Its threads of control can share state and
resources b ecause they are all within the same threadgroup
Mutual Exclusion Mode This mo de which we call MUXL for short provides a dis
tributed monitor like capability for our djinns If a MUXL djinn B is running when a
summons message arrives for it either via DM or directly to B it is rejected with a
B
djinn is busy lo cked message
With these six degrees of freedom for the life cycle and base b ehavior of the djinn wehave
b een able to implement a tremendous variety of distributed ob jects and services
Persistence When a djinn b ecomes quiescent its threads of control go idle or exit the djinn
ved to p ersistent store The Djinn Master is not resp onsible for initiating is automatically mo
this freeze but is resp onsible for identifying the store to the djinn when it is instantiated and
knowing when a djinn is frozen or ready
Message Forwarding As mention previously there are instances when messages come in for
a djinn B via its Djinn Master DM Summons and service see the next item messages
B
DRAFT NOT FOR DISTRIBUTION July
need not have their destination djinn fully sp eci ed A partial sp eci cation is valid only if it
uniquely determines a djinn within the context of the receiving Djinn Master
More precisely a djinn s identity indep endent of instantiation is designated by a unique
DjinnTrueName and each instance is uniquely named bya DjinnName
A DjinnTrueName DTN is a tuple
DTN hDTN DTN DTN DTN DTN DTN DTN DTN DTN i
E N O D U d l V v
with the following elements
DTN Author Email Address DTN sp eci es the contact address for the author s
E E
DTN Author Name DTN sp eci es the name of the author
N N
DTN Author Organization DTN denotes the organization that the author s worked
O O
for when they wrote this djinn Example organizations include scho ols research groups
companies divisions private foundations self etc
DTN DjinnName DTN is the name bywhich the organization and authors know
D D
the djinn This name do es not have to b e asso ciated with the actually name of the djinn s
class The djinnname is usually a unique name within the organization a pro duct name
and is slightly self descriptive
DTN Djinn URL DTN lists the URL asso ciated with this particular djinn author
U U
or organization whatever is more appropriate
DTN Release Date DTN is the date that this djinn is released for use
d d
DTN Release Level DTN is the release level of this djinn A release level is usually
l l
a su x that indicates ab ove and beyond the version number exactly how stable this
comp onent is considered Example release levels include alpha b eta gamma nal fcs
a b etc
DTN Major Version The ma jor version numb er for this djinn is stored in DTN
V V
DTN Minor Version The minor version numb er for this djinn is stored in DTN An
v v
example version numb er for a djinn would b e where DTN and DTN
V v
A DjinnName DN is a tuple
DN hDN DN DN DN DN DN i
d DTN l m n o
with the following elements
DN Summoning Date DN is the date and time at which this particular instance of
d d
the djinn was initially instantiated
DN DjinnTrueName DN is a reference to the full DjinnTrueName for this
DTN DTN
instance
DN InstanceLocation DN refers to a Place on which this djinn is running
l l
DRAFT NOT FOR DISTRIBUTION July
DN Master Location A djinn is asso ciated with exactly one Djinn Master the one
m
that instantiated the djinn DN holds the lo cation of that Djinn Master s instance
m
lo cation so the child djinn can contact its parent master
DN Instance Name Each djinn is named lo cally by the user that installs and uses
n
the djinn These lo cal generally agreed up on names help summons succeed from sources
that have little or no information ab out the djinns that they are summoning
For example a user might b e running as their scheduling djinn a pro duct called MySched
uler version from the company ScheduleIt Ob jects attempting to contact this
scheduler need not knowits version number pro duct name etc in order to communi
cate with it E g each user in the network lo cally names the ob ject that is resp onsible
for scheduling app ointments Scheduler so that communicating ob jects need not have a
priori knowledge in order to interop erate
DN Instance Owner DN is the username of the owner of the djinn
o o
If a djinn A attempts to summon a djinn B with DjinnName DN and DjinnTrueName DTN
B B
but only sp eci es an incomplete DjinnName DN and or DjinnTrueName DTN as part of
the summons S the following conditions are checked
If
DN DN DN DN DN DN
n B m B o B
n m o
i e the instance name master lo cation and instance owner of the summons is equal to
the same of a running djinn AND
DN DTN DN DTN
DTN V DTN v
V v
i e the version of the comp onentin the rep ository is more recentthan the one b eing
requested AND
the pairwise comparison b etween the E N O D U d and l elements of DN and
DTN
DTN are su cient to uniquely identify the same instance B THEN
B
then
B is considered to b e the djinn that A was attempting to contact with incomplete information
Likewise summoning relies on a similar weak lo okup sp eci cation so as to provide a kind of
simple trader within each Djinn Master
Service Invocation Service requests destined for a djinn but delivered to its Djinn Master are
also resolved with the ab ove algorithm If a match is determined the request is forwarded on
to the running djinn
Since the Djinn Master is itself a dynamic p ersistent active ob ject it can be summoned and
manipulated likeany other djinn The partial class diagram for the info master package is included
in Figure
For the reader who is interested in more information please see Chapters and
DRAFT NOT FOR DISTRIBUTION July
Figure info master class diagram
DRAFT NOT FOR DISTRIBUTION July
The Core Persistent Communicating Comp onent The Djinn
I will describ e the core subsystem that of info djinn in greater detail In particular I will use
DESML our extension to UML as describ ed in Chapter to sp ecify the high level architecture of
this package given its complexity I will not provide a detailed comp onent level sp eci cation e g
an Ob ject Z sp eci cation b eyond providing class and ob ject diagrams b ecause of space restrictions
info djinn Overview
The full ten thousand fo ot class diagram for the info djinn package is provided in Figure
It is evidentthatthepackage is tightly coupled and attempting to describ e the myriad of interde
p endencies is not useful This gure is has intentionally blank class b oxes b ecause the snapshot is
taken at such a high level
A closer view of p ortions of the package is available in Figures Note that two classes
are to o large to t on a single page in a readable font so I havechosen to crop the lower part of the
sp eci cation whichshows less useful information in particular the class s parent s metho ds The
small b ean image indicates that the annotated class has b een identi ed as a p otential JavaBean
via re ection
Several base classes for the Summonable interface are provided Djinn DjinnBean DjinnServlet
and DjinnApplet Each provides a base class from which a djinn develop er should sub class dep ending
up on the demands of their application Note that Djinn sp ecializes Message thus some groundwork
for adding mobility to the II is already in place
There are several classes which inherit from info net s Message base class and they are or
ganized in three groups Summon Service and Dispel l Each group contains the messages and
exceptions which are used to implement the group s functionality as well as the core class which
contains the logic to implement the functionality of the subsystem named appropriately Summon
Service andDispel l
As mentioned previously there are two classes which provide the naming service for the II
DjinnName and DjinnTrueName Note that b oth are sp ecialized from Message
Finally there are several service subsystems each encapsulated in a few interrelated classes
These subsystems include Persistence made up of AbstractPersistence AppletPersistence Persis
tence PersistenceException Djinn Services consisting of Service ServiceException Background
Thread User Interface including AWTThread IIWelcomeDialog Session Management made up
of OutboxAssociation OutboxAssociationTable and Core Djinn Functionality consisting of Back
ad DjinnThread Lamp LampThread whichprovide the core of the framework groundThre
The Persistence Subsystem
The Persistence service subsystem is resp onsible for helping save the state of a djinn to p ersistent
store This subsystem is made up of four classes AbstractPersistence AppletPersistence Persis
tence and PersistenceException
I have b egun to add supp ort for p ersistent djinns that are both normal ob jects Djinns and
DjinnBeans aswell as ob jects that have sp ecial securitymodels DjinnServlets and DjinnApplets
This distinction inspired the creation of the abstract class AbstractPersistence that provides the
DRAFT NOT FOR DISTRIBUTION July
Figure High level info djinn class diagram
DRAFT NOT FOR DISTRIBUTION July
Figure info djinn class diagram djinn base classes
DRAFT NOT FOR DISTRIBUTION July
Figure info djinn class diagram service subsystems
DRAFT NOT FOR DISTRIBUTION July
Figure info djinn class diagram messages
DRAFT NOT FOR DISTRIBUTION July
Figure info djinn class diagram names
DRAFT NOT FOR DISTRIBUTION July
Figure info djinn class diagram exceptions
DRAFT NOT FOR DISTRIBUTION July
Figure info djinn class diagram core
DRAFT NOT FOR DISTRIBUTION July
Figure info djinn class diagram UI and session management
DRAFT NOT FOR DISTRIBUTION July
base class for the sp eci c p ersistence mechanisms for the sub classes of Djinn that we do supp ort
All base classes but DjinnServlet are either completed or under development
Aside Abstract Classes vs Interfaces We chose to make AbstractPersistence an abstract
base class b ecause wewanted it to have non public metho ds This is a typical trade o we rep eatedly
hadtocho ose b ecause of Java s restrictions of what typ es of features can go in interfaces Almost
all of the abstract base classes of the II do not contain base co de the primary reason in using an
abstract class instead of an interface in almost all other ob ject oriented languages
AppletPersistence and Persistence both sp ecialize from AbstractPersistence As their names
would indicate AppletPersistence provides p ersistence services for DjinnApplets and Persistence
provides p ersistence for Djinns and DjinnBeans and DjinnServlets with the prop er security access
en a unique ID within the p ersistent le store When Persistence Each djinn instance is giv
a djinn is constructed and initialized for the rst time its corresp onding Persistence ob ject is
constructed and initialized via the initPersistence metho d The Persistence ob ject determines the
djinn s unique ID at this time
From that p ointonward any time the djinn wishes to store its p ersistent state it simply calls the
checkpoint metho d checkpoint p erforms some safetychecks on the data store and if appropriate
calls the djinn s freeze metho d piping the djinn s frozen state through an output stream and into
the data store
When a djinn shuts down or is garbage collected its Persistence ob ject is nalized Thus the
last snapshot of the djinn is complete and correct and the data store is closed prop erly
AppletPersistence The proto col b etween AppletPersistence and DjinnApplet is identical to that
of the standard Persistence ob ject as describ ed ab ove
A DjinnApplet obtains its p ersistent store via the Web server from which its co de was down
loaded The stream to whichaDjinnApplet s state is sentisaPUT metho d on the originating Web
server at the prop er unique ID as ab ove Likewise obtaining p ersistent state for the DjinnApplet
is accomplished via a GET metho d applied to the same server
PersistenceException is the exception thrown bythe p ersistence subsystem if there is an error
during the initialization or action of the subsystem In many cases a djinns can continue to op erate
if its data store is temp orarily unavailable but such decisions are left up to the djinn s designer
The Summoning Disp elling Subsystems
Adjinn A can cause a second djinn B to b e instantiated via a remote Djinn Master M by summoning
B The summonDjinn metho d of the Summon class is used to instantiate and obtain a reference
to the summoned djinn If the summoned djinn B is already running and in server mo de describ ed
previously then the summon op eration will simply return a new reference to B
Likewise when A is done interacting with B A should dispel l B The semantics of the disp ell
op eration are unde ned it is up to the designer of each djinn to decide what a disp ell message
means to that djinn These semantics should b e do cumented in the sp eci cation of the djinn For A
to disp ell B it should invokethe dispel lDjinn metho d of the Dispel l class Note that in general
DRAFT NOT FOR DISTRIBUTION July
only the original summoner of a djinn D has the right to p ermanently disp ell D but again these
semantics are up to D s designer
The Service Subsystem
The service subsystem is resp onsible for handling b oth outb ound and incoming service requests If
a djinn A has a reference to another djinn B either via summoning B directly or obtaining the
reference through a third party itcaninvoke a service call up on B
For A to make a service request it invokes the serviceDjinn metho d of the Service class When
the service request completes or fails a result with b e returned to the djinn or an exception will b e
raised
When B receives the service request its service metho d on its base class will be invoked by
h concurrency as a BackgroundThread This means that each djinn can permit or restrict as muc
appropriate for its service and capability
Note service requests are synchronous on the sending side but asynchronous on the receiving
side unless the djinn implementer decides otherwise
The Session Management and User Interface Subsystems
The session management service provides the supp ort for the session construct describ ed in Sec
tion When a djinn is summoned a sp eci cation of its mailb ox bindings can b e provided via
the OutputAssociationTable class If such a sp eci cation is provided then the infrastructure auto
matically p erforms the sp eci ed binds on the djinn s mailb oxes Thus this mechanism provides
a simple means of constructing sessions Our djinn initiator describ ed in Section used this
mechanism
The user interface subsystem is resp onsible for determining if a djinn has access to a display
device It also displays a w elcome dialog and copyright information Such a display only takes place
once in the lifetime of a Java virtual machine thus copyright displays don t keep p opping up all
over your display as djinns are summoned and disp elled
A djinn is not informed if it has access to a legal display device it has to attempt to instantiate
a frame and see if an exception is raised
The reason for the existence of the AWTThread class is to work around several bugs and design
aws in the JDK and AWT systems Essentially neither provide any means of actually
shutting down a virtual machines background AWT threads once they are started Thus to detect
when a djinn go es quiescent requires some subtle manipulation of threads and threadgroups within
the VM by AWTThread We are hoping these issues are remedied in JDK
This completes the summary of the info djinn package
As an example of the expressiveness of DESML I will provide a partial sp eci cation of info djinn
in an ob ject netw ork diagram in Figure
The Infospheres Infrastructure Implementation
I will make a few notes ab out the implementation of the II Please see our releases Web page
at http www infospheres caltech edu releases for more information or to download the
DRAFT NOT FOR DISTRIBUTION July
IIWelcomeDialog LampThread
constructor() constructor(ThreadGroup, init() String) start() initLampThread(Lamp, dispose() OutboxAssociationTable) start()
Runnable ThreadGroup constructor(String) ThreadGroup Summon AWTThread awtGroup constructor(String) constructor(Lamp) lampGroup summonDjinn(DjinnName, DjinnName, String [], start() OutboxAssociationTable, BackgroundThread Lamp long) notify() getMainLampThread() getSummonable() Summonable getDjinnName() Service getPersistence() constructor(Lamp) ServiceRequest serviceDjinn(ServiceRequest, long) getTarget() DjinnMaster getSource() djinnGroup AbstractPersistence <
DjinnThread Persistence AppletPersistence DjinnBean
constructor(ThreadGroup, OutboxAssociationTable String) start()
DjinnServlet
DjinnApplet
Figure info djinn ob ject network diagram
DRAFT NOT FOR DISTRIBUTION July
framework
Implementation Supplementary Comp onents
The II comes with several supplementary to ols and packages to help a user take advantage of the
II and build their own djinns
A to ol called the Djinn Initiator orInitiator for short was included in early versions of the II
The initiator was a to ol that supp orts the graphical comp osition of sessions
In the Initiator djinns are represented as icons eachofwhich had a set of assignable attributes
These attributes help the Initiator user describ e which djinn each icon is meant to represent Djinns
are visually wired together or more precisely their mailb oxes are wired together and the session
can be instantiated with the push of a button We had hop ed to add a djinn palette to the
initiator but the pro ject was not continued when wemoved to adding more functionality to the core
of the framework
The Djinn Summoner is the primary to ols used to summon arbitrary djinns and demonstrate the
framework The Summoner provides b oth a command line and a graphical interface to summoning
requesting services from and disp elling arbitrary djinns A screen snapshot of the summoner can
b e seen is Figure
Finally we also supply a comprehensive debugging package with the II info util Debug pro
y and logging of several di erent classes and levels of debugging messages Such vides for the displa
apackage was quite useful as we develop ed and debugged the II
From the exp erience we gained in using this debug package we designed and this author imple
mented a new general purp ose distributed debugging package for Javawhich is b eing used exten
sively in the developmentof II and Dan Zimmerman s Ub erNet
Implementation Size
For such a comprehensive framework the implementation of II is surprisingly small Ta
ble shows the summary of the implementation size and comment ratios as provided by the
CommentCounter to ol written by this author
If this same framework were to b e reimplemented with Java I estimate that wewould see a
reduction in size This di erence is primarily due to the fact that we had to implement ob ject
RMI p ersistence in II whereas the use of JDK would p ermit us to replace that co de with the
Serialization mechanism Additionally the use of new collection classes in JDK would reduce
the co de size by a few hundred lines
Hindsight Design and Implementation Improvements
Our ma jor design realization concerns indirect comp onent coupling Wenow recognize that the use
of individual classes p er message typ e while a nice mo del is not e cient or necessary In fact it is
now our opinion that this was a p o or design decision This kind of message design indirectly couples
the distributed comp onents to o tightly If the implementation of a single message is changed a
potential trickle down e ect can impact all comp onents that use that message
CommentCounter is one of a set of to ols designed and built by this author that assist in the development testing
and evaluation of Javasoftware
DRAFT NOT FOR DISTRIBUTION July
Figure The Infospheres Infrastructure Summoner GUI version
DRAFT NOT FOR DISTRIBUTION July
info net package
Total numb er of lines of co de
Total numb er of lines of comments
Ratio comments co de
info djinn package
Total numb er of lines of co de
Total numb er of lines of comments
Ratio comments co de
info master package
Total numb er of lines of co de
Total numb er of lines of comments
Ratio comments co de
Total number of lines of corecode
Total number of lines of comments in corecode
Total ratio comments code
info util package
Total numb er of lines of co de
Total numb er of lines of comments
Ratio comments co de
info demo package
Total numb er of lines of co de
Total numb er of lines of comments
Ratio comments co de
Grand Totals
Grand total number of lines of suppliedcode
Grand total number of lines of suppliedcomments
Grand total ratio comments code
Table A summary of the II implementation size and internal do cumentation
DRAFT NOT FOR DISTRIBUTION July
To uncouple these dep endencies I suggest the use of a semantic messaging infrastructure similar
to that prop osed by Sims in
Sucha change would not only decouple the communicating comp onents but would again reduce
the co de size by another few thousand lines
Infrastructure Impact
Versions of the II have b een downloaded byscho ols companies research labs and others To date
May just over one thousand downloads of just the last four software releases b eta b eta
nal candidate and nal release have taken place Collab orators haveusedthe II at the University
of Florida Indiana University and Trinity Collage for research and teaching
Additionally it has come to our attention that several companies havedownloaded the package
and incorp orated ideas into their internal research and developmentwork as well as pro duct devel
opment In particular Sun Microsystems Ob jectSpace Digital Novell IBM Hewlett Packard and
Microsoft haveshown considerable interest
Infrastructure Uses
Several distributed systems have b een built with the II ov er the past sixteen months I will brie y de
scrib e several of these in the next chapter Also I will prop ose an algorithm for archiving distributed
states in a dynamic comp onent distributed system with the II
In fact this author has such a package called Semantic Data Objects under development at this time
DRAFT NOT FOR DISTRIBUTION July
Chapter
Examples
Distributed Systems Built with Infospheres
The II has b een used to build several distributed systems We will brie y mention a few of them
here
Autonomous poker playing objects The II is b eing used in our CS Distributed Computa
tion Laboratory course here at Caltech The class used the package extensively in November
writing autonomous p oker playing djinns that comp eted in a gaming tournament This
test pitted several dozen djinns against each other interacting in up to vesimultaneous ses
sions games Students recommendations help ed us make our packages substantially smaller
faster more reliable and more consistent than the previous releases See the class s home page
at http www cs caltech edu cs for more information
Global resource reservation tool A global resource reservation to ol was built that integrates
a Tk Tcl front end with a Java II back end to provide the user with an interactive inter
face for reserving slots on geographically distributed sup ercomputers with individual resource
reservation schemes See for more information
JEDI A research framework for developing client server systems The JEDI system lets a
develop er build client server systems without having to go through the pro cess of stub skeleton
compilation See for more information
SimulEdit A peer to peer distributed editor SimulEdit is an editor that lets users join and
leave an editing session dynamically and is fault tolerant See for more information
DALI A distributed arti cial life simulator infrastructure This system lets the user construct
an distributed asynchronous simulation system for simulating arti cial life systems genomes
sp ecify behavior sp eciation pack b ehavior etc The system scales extremely well given
Infospheres s prop erties i e hundreds of thousands to millions of interacting agents are
p ossible See for more information
Virtual Swap Meet A distributed agent marketplace This pro ject is a p eer to p eer autonomous
agent auctioning system This system lets the user sp ecify a set of items that they are interested
in purchasing and a set of items that they are interested in selling The example application
DRAFT NOT FOR DISTRIBUTION July
uses compact discs or used b o oks The user also sp eci es howmuch they are willing to pay
for get for the items and what sort of strategies to employ in buying or selling the items rst
hit highest bid after atime window etc The system then autonomously p osts the selling
information to a varietyofcommunication venues organized NetNews groups Web servers
and multicast addresses are in the current design and spawns agents to autonomously search
through these same sources for items of interest Once a p ossible match is found bartering
agents then attempt to makethe purchase sale according to the user s preferences See the
group s pro ject summary for more information
Distributed Games A clone of the game Diplomacy was develop ed using II but could not
b e released due to licensing restrictions imp osed bytheowner company Additionally several
and the classic entertaining client server games the card game Spit TRON light cycles
Pong were constructed with the info net package See for more information
Further example system implementation will take place on top of II exp ected to b e available
in third quarter of My remaining distributed system s implementation work to complete the
Ph D will all use II
Archiving Distributed States
Wehavenow describ ed our prototyp e software infrastructure next we describ e an algorithm that
canbeusedby the infrastructure to archive distributed states This is a variant of the global snapshot
algorithm inwhich a clo ck or sequence numb er is stored with the snapshot state Within the
snapshots these logical clo cks can b e used for timestamping Note that this algorithm has not
b een implemented this is just a sp eci cation of the algorithm
The Global Snapshot Algorithm
If all comp onents recorded their complete states including the states of their mailb oxes at a sp eci ed
time T then the collection of comp onent states would b e the state of the distributed system at time
T The problem is that the clo cks of the comp onents can drift and as illustrated by the following
example even a small drift can cause problems
Two comp onents P and Q share an indivisible token that they pass back and forth between
them P s clo ck is slightly faster than Q s clo ck Both pro cesses record their states when their
clo cks reachapredetermined time T Assume that the token is at Q when P s clo ck reaches T
so so P s recorded state shows that P do es not have the token Then after Q has sent the token
to P Q s clo ck reaches time T Q s recorded state then shows that Q do es not havethe token
Therefore the recorded system state the combined recorded states of P and Q that shows that
no token is anywhere in the system is erroneous The basic problem arises b ecause Q sends a
message to P after P records its state but b efore Q records its state
We describ e our algorithm in terms of taking a single global snapshot In practice we will need to
take a sequence of global snapshots and extending the single snapshot algorithm to take sequences
of snapshots is straightforward
DRAFT NOT FOR DISTRIBUTION July
Initially some comp onent records its state the mechanism that triggers this initial recording is
irrelevant Perhaps a comp onent records its state when its lo cal clo ck gets to some predetermined
time T and the comp onent with the clo ck that reaches T rst is the rst to record its state
Each message sentbyacomponent is tagged with a single b o olean whichidenti es the message
as b eing either i sent b efore the comp onent recorded its lo cal state or ii sent after the comp onent
recorded its lo cal state In our infrastructure every message is acknowledged so eachacknowledg
ment is also tagged with a b o olean indicating whether the acknowledgmentwas sent b efore or after
the comp onent recorded its state When a message tagged as b eing sent after the sender recorded its
state arrives at a receiver that has not recorded its state the infrastructure causes the receiver s state
to b e recorded b efore delivering the message Acknowledgments are also tagged and are handled in
the same way Thus the algorithm maintains the invariant that a message or acknowledgmentsent
after a comp onent records its state is only delivered to comp onents that havealsorecorded their
states
The issue of acknowledgments is somewhat subtle so I will describ e it in more detail Consider
a comp onent P sending a message m to a comp onent Q The message m is at the head of an
outb ox of P The message passing layer sends a copy of m to Q s inbox to which that outb ox
is connected Note that m remains in the outb ox while the copy of m is in transit to Q s inbox
When the acknowledgment for m arrives at P then and only then is message m discarded from
P s outb ox If the acknowledgment is a p ost recording acknowledgment then P s state is recorded
b efore the acknowledgment is delivered and therefore P s state is recorded as still having message
m in its outb ox
Rep eated Snapshots
The algorithm for taking a single snapshot of an entire distributed system requires each comp onent
to have a b o olean indicating whether that comp onent has recorded its state Also each message and
acknowledgment has a b o olean eld indicating whether that message or acknowledgmentwas sent
b efore or after the sender of that message or acknowledgment had recorded its state For rep eated
snapshots the b o olean is replaced by a date represented by a sequence of integers for year month
day time in hours minutes seconds milliseconds and so on to the appropriate granularity level
The date eld of a comp onent indicates when the comp onent last recorded its state and this date
eld is copied into messages and acknowledgments sentby the comp onent If a comp onent receives
a message or acknowledgment with a date that is later than its currentdate eld it takesalocal
snapshot up dates its date eld to the date of the incoming message and if necessary moves its
clo ck forward to exceed the date of the incoming message
Replaying a Distributed Computation
There is a distinction b etween having the saved state of a distributed computation and b eing able
to replay the computation An archived snapshot helps in a varietyofways but b ecause some dis
tributed computations are nondeterministic it do es not guarantee that the distributed computation
can b e replayed
Our comp onents are blackboxes so we cannot tell whether a comp onent is deterministic Re
executing the computation of a nondeterministic comp onent from a saved state can result in a
DRAFT NOT FOR DISTRIBUTION July
di erent computation even though the comp onent receives a sequence of messages identical to the
sequence it received in the original computation Replaying precisely the same sequence of events
requires each comp onent to execute events in exactly the same order as in the original sequence so the
replay has to b e deterministic For example if there is a race condition in the original computation
then the replay must ensure that the race condition is won by the same event as in the original
Since comp onents are blackboxes the II cannot control events within a comp onent Therefore we
rely on the designers of the comp onents to have a record replaymechanism for recording the event
that o ccurs in each nondeterministic situation and playing backthisevent correctly during replay
During replay the II ensures that messages are delivered to a comp onent in the same order as
in the original computation provided all comp onents in the computation send the same sequences
of messages If the comp onents have deterministic replay the computation from the saved state will
b e an exact replay a sequence of events identical to those of the original computation
The II guarantees that messages are delivered in the same order as in the original computation
in the following way a maildaemon executes on each computer that hosts comp onents logging the
outb ox inbox and message id for each incoming message Because the contents of the messages
are not necessary to prop erly deal with nondeterminism in the message passing layer they are not
recorded by the maildaemon During replay the maildaemon holds messages that arrive in a di erent
order delivering them to the appropriate inboxes only after all previous messages in the original
computation have b een delivered
A World Wide Web of Distributed Spaces
The existing Infospheres Infrastructure supp orts saving the states of comp onents and summoning
comp onents from these archived states to form new sessions When a comp onent is summoned
from an archived state it resumes computation from that state It is convenient to treat each
archived comp onent as b eing unique for instance there may be a solid mechanics computation
comp onent that is p ersistent and for practical purp oses lives forever but an exp erimenter may
have a sequence of related comp onents corresp onding to states of that comp onent used at di erent
times in di erent exp eriments Our intentistoprovide access to these archived comp onents through
aWeb browser using the standard summoning mechanism
DRAFT NOT FOR DISTRIBUTION July
Chapter
Conclusion
Ihave describ ed some of the problems inherent in the sp eci cation of complex systems b oth at the
macro system and micro comp onent level Additionally Ihaveprovided several contructs that
begin to solve these system sp eci cation problems at the macro level
Contributions
DESML is an evolving layer for system mo deling languages Note that I have only describ ed a few
constructs that b egin to solve the dynamism and comp onent related problems sp eci ed in Section
As de ned here DESML is a variant of UML not an extension Ihave rede ned the its meta
mo del thus the new language is no longer compatible at the meta level with UML
Future Work
The problems that DESML set out to solve have b een sp eci ed by this author for several years
But during that interval in its attempt to mo deling emergent systems metalevels and knowledge
I b elieve that OOCL has b egun to handle the balance of the problems sp eci ed in Section
System mo deling is no longer in our core research agenda Once the full OOCL metho d b ecomes
publicly available I will evaluate its constructs and incorp orate appropriate elements into DESML
Or put more appropriately OOCLmight b ecome the new base on which to put the thin layer that
is DESML
Knowledge representation and comp onen t sp eci cation are still in our research agenda The
problem of tying knowledge to sp eci cation esp ecially at the metalevel are topics to b e addressed
in the next phase of our research program
DRAFT NOT FOR DISTRIBUTION July
Bibliography
Martin Adabi and Luca Cardelli ATheory of Objects Springer Verlag
O Agesen L Bak C Chamb ers B W Chang U H olzle J Maloney R B Smith D Un
gar and M Wolczko The self programmer s reference manual Technical rep ort Sun
Microsystems
Gul Agha Actors A Model of Concurrent Computation in Distributed Systems The MIT
Press
Gul Agha and Carl Hewitt Research Directions in Object Oriented Programming chapter
Actors A Conceptual Foundation for Concurrent Ob ject Oriented Programming pages
The MIT Press
Agilis corp oration web site Available as http www agiliscorp c om
Jonathan Aldrich James Do oley Scott Mandelsohn and Adam Rifkin Providing easier access
to remote ob jects in distributed systems In Hawaii International Conference on System
Sciences IEEE Computer So ciety January
Peter Andrews A Trans nite Type Theory with Type Variables North Holland Publishing
Company
Peter Andrews An Introduction to Mathematical Logic and Type Theory ToTruth Through
Proof Academic Press
Apple Computer Eastern ResearchandTechnology Center Dylan an ob ject oriented dy
namic language Technical rep ort Apple Computer Cambridge MA
ond Edition Addison Wesley Publishing Ken Arnold The Java Programming Language Sec
Company
J C Bicarregui J S Fitzgerald P A Lindsay R Mo ore and B Ritchie Proof in VDM A
Practitioner s Guide Springer Verlag
G M Birtwistle O J Dahl B Myhrhaug and K Nygaard SIMULA begin Studentlitteratur
A Blo esch E Kazmierczak P Kearney andO Traynor Cogito A metho dology and system
for formal software development International Journal of Software Engineering and Know l
edge Engineering December
DRAFT NOT FOR DISTRIBUTION July
Daniel G Bobrow Linda G Demichiel Richard P Gabriel Sonya E Keene Gregor Kiczales
and David A Mo on Common Lisp Object System Speci cation X J Committee do cument
r edition June
Grady Bo o ch Object OrientedAnalysis and Design with Applications Addison Wesley Pub
lishing Company
Grady Bo o ch Object Solutions Managing the Object Oriented Product Addison Wesley
Publishing Company
Grady Bo o ch Jim Rumbaugh and Ivan Jacobson Uni ed Modeling Language User Guide
Addison Wesley Publishing Company
Tim Bray Dave Hollander and Andrew Layman Namespaces in XML Technical rep ort
R WD xml names World Wide Web Consortium http www w org T
Tim Bray Jean Paoli and C M Sp erb erg McQueen Extensible Markup Language XML
Technical rep ort World Wide Web Consortium http www w org TR REC xml
Edmund Burke and Eric Foxley Logic and its Applications Prentice Hall Inc
Rich Burridge Java Shared Data Toolkit User Guide Sun Microsystems Inc edition
April
P Butcher A b ehavioral semantics for Linda Software Engineering Journal
July
Luca Cardelli Obliq a language with distributed scop e Technical rep ort DEC Systems
ResearchCenter
Luca Cardelli A language with distributed scop e Computing Systems
CCITT Sp eci cation and Description Language SDL recommendation z Technical
rep ort CCITT
K Mani Chandy Joseph R Kiniry Adam Rifkin and Daniel M Zimmerman Webs of archived
distributed computations for asynchronous collab oration Journal of Supercomputing
K Mani Chandy Joseph R Kiniry Adam Rifkin Daniel M Zimmerman Wesley Tanaka and
LukeWeisman A framework for structured distributed ob ject computing California Insti
tute of Technology Technical Rep ort Caltech CS TR California Institute of Technology
February
K Mani Chandy Joseph R Kiniry Adam Rifkin Daniel M Zimmerman Wesley Tanaka and
LukeWeisman A framework for structured distributed ob ject computing crp c tr CRPC
California Institute of Technology February
K Mani Chandy and Leslie Lamp ort Distributed snapshots Determining the global states
of distributed systems ACM Transactions on Computing Systems
DRAFT NOT FOR DISTRIBUTION July
K Mani Chandy and Jayadev Misra Paral lel Program Design AFoundation Addison Wesley
Publishing Company
K Mani Chandy and Adam Rifkin Systematic comp osition of ob jects in distributed Internet
applications Pro cesses and sessions In Hawaii International Conference on System Sciences
pages IEEE Computer So ciety January
K Mani Chandy Adam Rifkin and EveScho oler Using announce listen with global events to
develop distributed control systems In ACM Workshop on Java for High Performance
Network Computing February
K Mani Chandy Adam Rifkin Paolo Sivilotti Jacob Mandelson Matt Richardson Wesley
Tanaka and LukeWeisman Aworldwide distributed system using Java and the Internet In
International Symposium on High Performance Distributed Computing pages
Conceptual Knowledge Markup Language CKML DTD http asimov eecs wsu edu
WAVE Ontologies CKML CKML DTD html
eter Coad and Edward Yourdon OOA Object OrientedAnalysis nd Edition Prentice Hall P
Inc
Peter Coad and Edward Yourdon OOD Object Oriented Design Prentice Hall Inc
Derek Coleman et al Object Oriented Development The Fusion Method Prentice Hall Inc
COMP LANG ML Frequently Asked Questions and Answers http www cis ohio state
edu hypertext faq usenet meta lang faq faq ht ml
S Co ok and J Daniels Designing Object Systems Object OrientedModel ling with Syntropy
Prentice Hall Inc
Rational Software Corp oration et al UML Notation Guide version The UML Con
sortium Septemb er
Rational Software Corp oration et al UML Semantics version The UML Consortium
Septemb er
Rational Software Corp oration et al UML Summary version Technical rep ort The UML
Consortium Septem b er
Brad Cox Superdistribution Objects As Property on the Electronic Frontier Addison Wesley
Publishing Company
Brad Cox and Andrew Novabilsky Object OrientedProgramming An Evolutionary Approach
Addison Wesley Publishing Company
O Dahl and K Nygaard Simula an Algol based simulation language Communications of
the ACM
DRAFT NOT FOR DISTRIBUTION July
Edsger W Dijkstra and Carel S Scholten Predicate Calculus and Program Semantics
Springer Verlag
Desmond D Souza and Alan Wills Objects Components and Frameworks with UML the
Catalysis Approach Addison Wesley Publishing Company
R Duke G Rose and G Smith Ob ject Z A sp eci cation language advo cated for the de
scription of standards Technical Rep ort Software Veri cation Research Centre Scho ol
of Information Technology The University of Queensland Decemb er
E H Durr and J van Katwijk VDM a formal sp eci cation language for ob ject oriented
designs In Bertrand Meyer Georg Heeg and Boris Magnusson editors Proceedings of Tech
nology of Object oriented Languages and Systems TOOLS Europe pages Prentice
Hall Inc
Hans Erik Eriksson and Magnus Penker UML Toolkit John Wiley Sons Inc
David Evans John V Guttag James J Horning and Yang Meng Tan Lclint A to ol for
using sp eci cations to check co de In Proceedings of the Symposium on the Foundations of
Software Engineering December
G Florijn Ob ject proto cols as functional parsers In Proceedings of the European Conference
on Object Oriented Programming n umber in Lecture Notes in Computer Science pages
USGS NSDI formal metadata information and to ols http geochange er usgs gov pub
tools metadata
JayW Forrester Industrial Dynamics Pro ductivity Press
JayW Forrester Urban Dynamics Pro ductivity Press
JayW Forrester World Dynamics Pro ductivity Press nd edition
JayW Forrester Col lectedPapers of Jay W Forrester Pro ductivity Press
Svend Fr lund Coordinating Distributed Objects AnActor BasedApproach to Synchroniza
tion The MIT Press
DovM Gabbay Ian Ho dkinson and Mark Reynolds Temporal Logic Mathematical Founda
tions and Computational Aspects Oxford University Press
R P Gabriel J L White and D G Bobrow CLOS Integrating ob ject oriented and functional
programming Communications of the ACM
Erich Gamma Richard Helm Ralph Johnson and John Vlissides Design Patterns Elements
of Reusable Object Oriented Software Addison Wesley Publishing Company
Stephen J Garland and John V Guttag A guide to LP the LarchProver Technical Rep ort
Digital Equipment Corp oration Systems ResearchCenter
DRAFT NOT FOR DISTRIBUTION July
Mauro Gaspari and Gianluigi Zavattaro An algebra of actors Technical Rep ort UBLCS
Department of Computer Science University of Bologna May
Jean Yves Girard Proofs and Types Cambridge University Press
Adele Goldb erg and David Robson Smal ltalk The Language and its Implementation
Addison Wesley Publishing Company
Adele Goldb erg and K S Rubin Smal ltalk The Language edition Revised publisher
pub aw year
Martin Goldstern and Haim Judah The Incompleteness Phenomenon A New Course in
Mathematical Logic A K Peters
James Gosling Bill Joy and Guy Steele The Java Language Speci cation Addison Wesley
Publishing Company
The Infospheres Group The Infospheres Infrastructure version User s Guide The Infos
pheres Group California Institute of Technology Aug
The Infospheres Group The Infospheres Infrastructure version Tutorial The Infospheres
Group California Institute of Technology
The Infospheres Group The Infospheres Infrastructure version User s Guide The Infos
pheres Group California Institute of Technology
Carl A Gunter and John C Mitchell editors Theoretical Aspects of Object Oriented Pro
gramming Foundations of Computing The MIT Press Cambridge MA USA
John Guttag James J Horning et al editors Larch Languages and Tools for Formal
Speci cation Texts and Monographs in Computer Science Springer Verlag
D Harel and E Gery Executable ob ject mo deling with statecharts In Proceedings of the th
International Software Engineering Conference pages IEEE Press March
D Harel and A Naamad The STATEMATE semantics of statecharts In ACM Transactions
on Software Engineering and Methodology volume Octob er
David Harel Statecharts A visual formalism for complex systems Science of Computer
Programming
W Harrison and H Ossher Sub ject oriented programming a critique of pure ob jects In
ACM Conference on Object Oriented Programming Systems Languages and Applications
ACM SIGPLAN Notices pages ACM SIGPLAN ACM Press and Addison Wesley
Richard Hayton Jean Bacon John Bates and Ken Mo o dy Using events to build large scale
an Workshop distributed applications In SIGOPS Europe
Matthew Hennessy Algebraic Theory of Processes The MIT Press
DRAFT NOT FOR DISTRIBUTION July
C Hewitt P Bishop and R Steiger A universal mo delar ACTOR formalism for AI In
Proceedings Third International Joint ConferenceonArti cial Intel ligence
C A R Hoare Communicating sequential pro cesses Communications of the ACM
C A R Hoare Communicating Sequential Processes Prentice Hall Inc
John H Holland Hidden Order How Adaptation Builds Complexity Addison Wesley Pub
lishing Company
John J Holland Adaptation in Natural and Arti cial Systems AnIntroductory Analysis with
Applications to Biology Control and Arti cial Intel ligence University of Michigan Press
Walter L Hursc h User s guide to the Demeter To ols C C Demeter System Do cumen
tation May
A Hutt Analysis and Design Comparison of Methods John Wiley Sons Inc
A Hutt Analysis and Design Description of Methods John Wiley Sons Inc
IBM et al Object Constraint Language Speci cation version The UML Consortium
Septemb er
IFAD IFAD VDM to ols http www ifad dk products vdmtools html
Darrel C Ince An Introduction to Discrete Mathematics Formal System Speci cation and Z
Oxford University Press
Dan Ingalls Ted Kaehler John Maloney Scott Wallace and Alan Kay Back to the future The
story of squeak a practical smalltalk written in itself In ACM Conference on Object Oriented
Programming Systems Languages and Applications Apple Computer and Walt Disney Imag
ineering ftp st cs uiuc edu Small talk Squeak docs OOPSLA Squeak html
Ivar Jacobson Grady Booch and Jim Rumbaugh The Uni ed Process A Software Engi
neering Process Using the Uni edModeling Language Addison Wesley Publishing Company
Ivar Jacobson M Christerson P Jonsson and G Overgaard Object Oriented Software En
gineering Addison Wesley Publishing Company
Ivar Jacobson et al Object Oriented Software Engineering A Use Case Driven Approach
ACM Press Addison Wesley
homepage http www cs wustl edu Prashant Jain and Douglas Schmidt Java ACE
schmidt JACE html
Ralph Johnson Personal email communication dist ob j Mailing List http www
infospheres caltech edu mailing lists dist obj msg html May
DRAFT NOT FOR DISTRIBUTION July
Cli B Jones Systematic Software Development Using VDM Prentice Hall Inc
Markus Kaltenbach Mo del checking for UNITY Technical rep ort Department of Computer
Sciences The UniversityofTexas at Austin
Stewart Kau man The Origins of Order Self Organization and Selection in Evolution Ox
ford University Press
Stewart Kau man At Home in the Universe The Search for Laws of Self Organization and
Complexity Oxford University Press
Sonya E Keene Object OrientedProgramming in Common Lisp A Programmer s Guide to
CLOS Addison Wesley Publishing Company
Gregor Kiczales Jim des Rivieres and Daniel G Bobrow The Art of the Metaobject Protocol
The MIT Press
Gregor Kiczales John Lamping Anurag Mendhekar Chris Maeda Cristina Lop es Jean
Marc Loingtier and John Irwin Asp ect oriented programming Technical Rep ort SPL
P XEROX Corp oration February
Joseph R Kiniry Alexander Nicolson and Donald Pinkston DALI A distributed arti cial life
simulator infrastructure WWW Available at http www cs caltech edu kiniry
projects alife index html
Balachander Krishnamurthy and David S Rosenblum Yeast A general purp ose event action
system ACM Transactions on Software Engineering and Methodology Octo
b er
Bent B Kristensen Ole L Madsen Birger M ller Pederson and Kristen Nygaard The BETA
Programming Language pages The MIT Press
Leslie Lamp ort Time clo cks and the ordering of events in a distributed system Communi
cations of the ACM
Don Larkin and Greg Wilson Ob ject oriented programming and the Ob jective C language
Technical rep ort NeXT Software Inc now Apple Corp
Description Framework RDF Mo del and Syn Ora Lassila and Ralph Swick Resource
tax Technical rep ort World Wide Web Consortium http www w org TR
WD rdf syntax
Doug Lea Design for op en systems in Java In Proceedings of the Second International
ConferenceonCoordination Models and Languages Berlin Germany September
Karl J Lieb erherr Adaptive Object Oriented Software The Demeter Method with Propagation
Patterns PWS Publishing Company
Mark Lutz Programming Python O Reilly Asso ciates Inc
DRAFT NOT FOR DISTRIBUTION July
Ole L Madsen Birger M ller Pedersen and Kristen Nygaard Object OrientedProgramming
in the Beta Programming Language Addison Wesley Publishing Company
Pattie Maes and Daniele Nardi editors Meta Level Architectures and Re ection North
Holland
Silvano Ma eis iBus the Java intranet software bus Technical rep ort SoftWired AG
Switzerland
Eve Maler and Steve DeRose XML Linking Language XLink Technical rep ort World Wide
Web Consortium http www w org TR WD xlink
Eve Maler and Steve DeRose XML Pointer Language XPointer Technical rep ort World
Wide Web Consortium http www w org TR WD xptr
James Martin and James J Odell Object Oriented Methods Pragmatic Considerations
Prentice Hall Inc
James Martin and James J Odell Object Oriented Methods A Foundation Prentice Hall
Inc
Elise Matefy and Jessica Walton Virtual swap meet A distributed agent marketplace August
http www infospheres caltech edu papers vsm paper html
Bertrand Meyer Object Oriented Software Construction Prentice Hall Inc nd edition
Bertrand Meyer Ei el The Language Prentice Hall Inc
R Milner Communication and Concurrency Pren tice Hall Inc
Robin Milner Mads Tofte Rob ert Harp er and Dave MacQueen The De nition of Standard
ML Revised The MIT Press
Jayadev Misra A Discipline of Multiprogramming Published via the web Available as
ftp ftp cs utexas edu pub psp seuss discipline ps Z
P Naur and B Randell editors Proceedings NATO Conference on Software Engineering
Brussels Belgium Octob er NATO Science Committee Published as a b o ok in
G Nelson editor Systems Programming with Modula Prentice Hall Inc
Inc Ob eron microsystems Comp onent pascal language rep ort Technical rep ort Ob eron
ailable at http www oberon ch docu language microsystems Inc September Av
report html
Ob ject Management Group OMG The Common Object Request Broker Architecture and
Speci cation CORBA revision Ob ject Management Group OMG edition
Ontology Markup Language OML DTD http asimov eecs wsu edu WAVE
Ontologies OML OML DTD html
DRAFT NOT FOR DISTRIBUTION July
Andrew Paep cke editor Object Oriented Programming The CLOS Perspective The MIT
Press
Jens Palsb erg Cun Xiao and Karl Lieb erherr E cient implementation of adaptivesoftware
ACM Transactions on Programming Languages and Systems
Lawrence C Paulson Isabel le A Generic Theorem Prover Numb er in Lecture Notes in
Computer Science Springer Verlag
Lawrence C Paulson ML for the Working Programmer nd Edition Cambridge University
Press
L L Peterson and B S Davie Computer Networks A Systems Approach Morgan Kaufmann
L J Pinson and R S Wiener Objective C Object OrientedProgramming Techniques Addison
Wesley Publishing Company
Ben P otter Jane Sinclair and David Till An Introduction to Formal Speci cation and Z
Prentice Hall Inc
Ravi Ramamo orthi Adam Rifkin Boris Dimitrov and K Mani Chandy A general resource
reservation framework for scienti c computing In Proceedings of the First International Scien
ti c Computing in Object Oriented Paral lel Environments ISCOPE Conference December
Rational Software Corp oration Rational ROSE http www rational com products
rose
Tom S Ray An evolutionary approachtosynthetic biology Zen and the art of creating life
Arti cial Life
M Reiser and Niklaus Wirth Programming in Oberon Steps Beyond Pascal and Modula
Addison Wesley Publishing Company
James Rumbaugh and Stephen Blaha Object OrientedModeling and Design Prentice Hall
Inc
Jim Rumbaugh Michael Blaha William Premerlani Frederick Eddy Bill Lorensen and
William Lorenson Object OrientedModeling and Design Prentice Hall Inc
Jim Rumbaugh Ivar Jacobson and Grady Bo o ch Uni ed Modeling Language Reference
Manual Addison Wesley Publishing Company
Douglas C Schmidt and Steve Vinoski OMG event ob ject service SIGS February
y Peter Senge The Fifth Discipline The Art and PracticeofLearning Organization Doubleda
Peter Senge et al The Fifth Discipline Fieldbook Doubleday
DRAFT NOT FOR DISTRIBUTION July
Sally Shlaer and Steven Mellor Object Oriented Systems Analysis Modeling the World in
Data Prentice Hall Inc
Sally Shlaer and Steven Mellor Object Life Cycles Modeling the World in State Prentice Hall
Inc
Oliver Sims Business Objects Delivering Cooperative Objects for Client Server McGraw Hill
Brian C Smith Re ection and semantics in LISP In ACM Symposium on Principles of
Programming Languages pages ACM
J M Spivey Understanding Z A Speci cation Language and its Formal Semantics volume
of Cambridge Tracts in Theoretical Computer Science Cambridge University Press
J M Spivey The Z Notation AReference Manual Prentice Hall Inc
G Starovic V Cahill and B Tangney An event based ob ject mo del for distributed pro
gramming Technical rep ort Department of Computer Science University of Dublin Trinity
College Decemb er
Guy Steele Common Lisp The Language Digital Press nd edition
W R Stevens TCP IP Il lustrated Volume Addison Wesley Publishing Company
Thomas Streicher Semantics of TypeTheory Correctness Completeness and Independence
Results Birkhduser
Sun Microsystems Inc Java Remote MethodInvocation Speci cation Sun Microsystems Inc
b eta edition Octob er
Sun Microsystems Inc JavaBeans API sp eci cation version Tec hnical rep ort Sun
Microsystems Inc July
Edward Swanstrom OOCL Workbook Agilis Corp oration
Edward Swanstrom Creating Agile Organizations with the OOCL Method John Wiley
Sons Inc See http www agiliscorp com ooclforum html and http www
agiliscorp com oocldraft
Clemens Szyp erski Component Software Beyond Object Oriented Programming Addison
Wesley Publishing Company
PLATINUM technology Veronica Bowman Edward Swanstrom et al Paradigm Plus Meth
ods Manual Addendum OOCL PLATINUM technology edition
Louis Thomas Sean Suc hter and Adam Rifkin Developing p eer to p eer applications on the
Internet The distributed editor SimulEdit Dr Dobb s Journal
Simon Thompson Type Theory and Functional Programming Addison Wesley Publishing
Company
DRAFT NOT FOR DISTRIBUTION July
Kenneth J Turner editor Using Formal Description Techniques An Introduction to Estel le
LOTOS and SDL Wiley Series in Communication and Distributed Systems John Wiley
Sons Inc
D Ungar C Chamb ers B W Chang and U H olzle Organizing programs without classes
Lisp and Symbolic Computation
D Ungar and R B Smith Self The p ower of simplicity Lisp and Symbolic Computation
P H J van Eijk C A Vissers and M Diaz editors The Formal Description Technique LO
TOS Elsevier Science Inc
Guido van Rossum Python reference manual Technical Rep ort Corp oration for National
Research Initiatives Decemb er Available at http www python org doc ref
Aaron Watters Guido van Rossum and James C Ahlstrom Internet Programming with
Python IDG Bo oks
Peter Wegner Interactive foundations of computing http www cs brown edu people
pw papers finaltcs ps
R S Wiener Programming with ob ject pascal pascal from b orland international SIGSnet
Journal of Object OrientedProgramming July August
Reb ecca Wirfs Bro ck Brian Wilkerson and Lauren Wiener Designing Object Oriented Soft
ware Prentice Hall Inc
Niklaus Wirth The programming language PASCAL Acta Informatica
Niklaus Wirth Programming in Modula Springer Verlag
Niklaus Wirth and J Gutknecht Project Oberon The Design of an Operating System and
Compiler Addison Wesley Publishing Company
Jim Woodcock and Jim Davies Using Z Speci cation Re nement and Proof Prentice Hall
International Series in Computer Science Prentice Hall Inc
J H Wright A reference mo del for ob ject oriented distributed systems British Telecom
Technology Journal
Daniel M Zimmerman A preliminary investigation into dynamic distributed work ow Techni
cal Rep ort CS TR Department of Computer Science California Institute of Technology
Daniel M Zimmerman Brian Rothstein Yevgeniy Kaganovich and Khai Pham Constructing
client server multi player asynchronous games using a single computer mo del In Proceedings
of IASTED International Conference on Software Engineering November
DRAFT NOT FOR DISTRIBUTION July