Information Technology Reference
In-Depth Information
the constraints on these behaviours. In other words, a policy can be seen as
a constraint on a system specification foreseen at design time, whose details
can be modified to manage the system to meet particular (and changing)
circumstances. More details are given in chapter 10.
Policies are defined in terms of rules. A rule is a constraint on a system
specification. Rules are normally expressed as obligations, permissions, au-
thorizations or prohibitions. For instance, one rule may say that any phone
user associated with a customer can place an order to have a mobile phone
repaired (permission ), while another rule may dictate that the repair cen-
tre must repair the handset or provide a substitute phone within 48 hours
(obligation ); a further rule may state that VIP customers are entitled to get
substitute phones immediately (authorization ); a fourth rule may say that,
for security reasons, a SIM memory must not be returned to any customer
other than the one who placed the original repair order (prohibition ).
1.4 Useful Building Blocks
One of the aims of the reference model is to promote the use of common
terminology for describing distributed architectures, particularly with regard
to the functional elements needed to support and manage distributed appli-
cations. Many vendors have their own names for these functions, making it
more dicult to draw parallels between different solutions, and to find vendor-
neutral terms to describe interworking mechanisms.
The reference model therefore provides a catalogue of architectural func-
tions needed to support distribution. This vocabulary can be used in any of
the viewpoints, but it concentrates on giving full coverage of the engineering
viewpoint and many of the functions identified are normally contained within
the system's infrastructure. However, some may be available as services for
use in the computational specification, and others may be exploited in a more
abstract form, for example when modelling repositories in the enterprise spec-
ification.
The catalogue covers four main areas. The first is the management
of different groupings of engineering objects, providing control of resourcing,
protection and activation. Then it categorizes synchronization mechanisms,
followed by various repository functions, together with different specialized
features to aid resource discovery and interworking. Finally, it identifies im-
portant building blocks for the provision of a range of distributed security
functions.
Use of this taxonomy helps different teams to understand the functions
offered by existing components and so aids reuse. The functions can be used
as keywords to index catalogues of components or collections of higher-level
technical design patterns, aiding design. This provides a common vocabulary
