Self-Organising Software Architectures for
Distributed Systems
Ioannis Georgiadis, Jeff Magee and Jeff Kramer
Department of Computing
Imperial College of Science, Technology and Medicine
180 Queen’s Gate, London SW7 2BZ, UK
{jnm,i.georgiadis,jk}@doc.ic.ac.uk
ABSTRACT
A self-organising software architecture is one in which
components automatically configure their interaction in a way that
is compatible with an overall architectural specification. The
objective is to minimise the degree of explicit management
necessary for construction and subsequent evolution whilst
preserving the architectural properties implied by its specification.
This paper examines the feasibility of using architectural
constraints as the basis for the specification, design and
implementation of self-organising architectures for distributed
systems. Although we focus on organising the structure of
systems, we show how component state can influence re-
configuration via interface attributes.
Keywords
Software Architecture, self-configuring, constraints.
1 INTRODUCTION
Software Architecture [21; 23] describes the high-level structure
of a system in terms of components and component interactions.
In design, architecture is widely recognized as providing a
beneficial separation of concerns between the gross system
behaviour of interacting components and that of its constituent
components. Similarly this separation is also beneficial when
considering deployed systems and evolution as it allows us to
focus on change at the component level rather than on some finer
grain.
For instance, previous work described some of the issues involved
in specifying a limited form of dynamic software structure for
distributed systems in which the set of components and their
interaction change as execution progresses and the system evolves
[16]. A change to the software architecture could occur either as
the result of some computation performed by the system or as a
result of some external management action such as to insert a new
component and to change those connections within the system to
accommodate the new component. Management actions are
performed by a configuration manager[4] which maintains an
overall view of the structure of a system in terms of components
and their interconnections and performs changes in the context of
that view. In essence, the configuration manager is responsible for
ensuring that an executing system conforms precisely to its
architectural specification. This approach can however be too
restrictive for current dynamic, open systems.
In this paper we consider systems in which it is neither necessary
nor desirable to explicitly manage structure. For example, in large
open distributed systems components may appear dynamically as
the result of individual user action and disappear as the result of
user action or failure. There is no overall management control of
the system, which may span many organisational boundaries.
Components must bind to the services they require as a result of
their own actions without the help of explicit configuration
(structure) management. They are expected to be self-organizing.
Why an architectural approach? In addition to the autonomy
inherent in self-organizing systems, we wish to retain the benefits
of an overall software architecture specification so that, despite
the introduction and removal of components, the system will
remain well-formed with respect to its specification. In this way
the system can be made to preserve the architectural properties
implied by its specification. The architectural specification of a
self-organising system is not a precise description of component
instances and their interconnection but rather a set of constraints
on the way components may be composed. In this sense,
constraints can be considered akin to an architectural style [5],
and can be used to generate and/or check a specific architectural
instance for conformance. Furthermore, if a disturbance occurs,
correcting changes could be generated.
This paper discusses the feasibility of using architectural
constraints as the basis for the specification, design and
implementation of self-organising architectures for distributed
systems. In section 2, we address the problem of ensuring that the
architecture specification constrains the system to have the
required set of structures. Although we focus on organising the
structure of systems, we indicate how component state can
influence re-configuration via interface attributes. In section 3, we
present a runtime architecture that ensures that after component
introduction or failure, the system stabilises with a structure that
satisfies the specified constraints. We also present some results
from our initial Java implementation of this architecture. In
section 4, we discuss related work and in section 5, conclude with
an evaluation of the current work and present a research agenda of
unresolved issues.


Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. To copy otherwise, or republish, to post on servers or to redistribute to
lists, requires prior specific permission and/or a fee.
WOSS '02, Nov 18-19, 2002, Charleston, SC, USA.

© 2002 ACM 1-58113-609-9/02/0011...$5.00

2 ARCHITECTURE SPECIFICATION
In specifying the architecture of self-organising systems, we retain
the structural view embodied in the Darwin ADL [15]. System
architecture is a directed graph in which the nodes are component
instances and the arcs specify bindings between a service required
by one component and the service provided by another. However,
to enable analysis of architectural specifications, we have chosen
not to use Darwin directly but to model Darwin components in
Jackson’s Alloy language [9] and express structural constraints
directly in Alloy. This has the advantage that the Alcoa tool [10]
can then be used to generate, explore and analyse the
specifications. It has the further advantage of allowing us to
explore the semantics and features required of an ADL for self-
organising systems without the burden of syntax design. At the
current stage of our research, we feel language design would be
premature although this is clearly a future direction. Alloy has
successfully been used in analysing the properties of COM [11]
systems.
In the following, we present the Alloy specification for Darwin
components and bindings and use in determining the structural
constraints for a simple pipeline architecture. We use this simple
example to explain the approach, however we have both specified
and implemented a much more complex replicated file system
architecture [6].
2.1 Darwin Component Model
A component in Darwin, is a container of provided and required
services. Services are provided and required via ports. Ports are
typed with the interface used to access the service. In Figure 1
below, the component C has two provided ports {P0, P1}, the
filled in circles and three required ports {P2, P3, P4}, the empty
circles. Each port has an interface type e.g. P0 has type T0.

C
P0:: T0
P1:: T1
P2:: T0
P3:: T1
P4:: T2

Figure 1 – Component
Model Elements
The basic elements of the Alloy model of Darwin are the
components (Comp), service ports (Port) and interface types
(Type):
domain {Port, Comp, Type}
Components and ports denote instances, not types. Components
are implicitly associated with a type through set membership. A
port (i.e. port instance) is associated directly with a port type
(interface) and indirectly with all its supertypes.
Ports
Every port instance is associated with exactly one port type – the
port’s interface. Port types may inherit from other port types. A
port type may have multiple immediate base types, i.e. multiple
inheritance is supported.
type (~inst): Port -> static Type!
baseType: static Type -> static Type
Ports come in two flavours - provided and required:
partition Prov, Req: static Port
Components
A component is always associated with the same fixed number of
ports during its lifetime. Conversely, ports should always be
contained by the same simple component during their lifetime.
The set of ports of a component is the union of its provisions and
requirements. Thus port derives from the prov and req
relations.
prov: static Comp! -> static Prov
req: static Comp! -> static Req
port: static Comp! -> static Port
Bindings
By definition a requirement can be bound to at most one
provision. Required ports may be bound to different provided
ports at different times. The model supports rebinding semantics
by making all binding relations non-static.
reqBind (~provBind): Req -> Prov?
A provision can be bound to a requirement of the same type or a
super type.
all p:Prov | p.provBind.type in p.type.*baseType
Although, we have a complete model for Darwin that includes
hierarchical component composition, the above definitions are
sufficient for the following constraint based which we have
implemented as a self organising system.
2.2 A Pipeline Architecture
In the following, we outline the Alloy constraints for a pipeline
architecture. Each component in a pipeline has exactly one
provision and one requirement and the components are bound
together to form a single chain. A binding constraint on the left
end of the pipeline prevents it from becoming a ring. This
restriction extends implicitly to the right side of the pipeline due
to the cardinality constraint on ports and bindings.
Every component has one provision and one requirement:
all c:Comp | (one c.prov) && (one c.req)
Cardinality constraint: a provided port has at most one
required port bound to it and vice-versa:
all c:Comp | sole c.prov.provBind
The pipeline forms a single chain:
some c:Comp | c.*connected = Comp
The pipeline does not form a ring, i.e. the provided port of the
left end of the pipeline should not be connected to any
component of the pipeline chain. The left end can be
unbound.
some leftEnd:Comp
| no (leftEnd.prov.bind.~port & Comp)
The last two constraints require global knowledge of the system.
We will see that these global constraints are more difficult to
enforce in a self-organising system than local constraints that can
be enforced by a component with no knowledge of the rest of the
system. For example, the cardinality constraint is local.