Information Technology Reference
In-Depth Information
stream interfaces that describe the nature of the data exchanged. This is done
by declaring a collection of flows, each with an associated direction of transfer.
This means that a conversational audio application could be described using
stream interfaces in each of which there is a pair of flows, one in each direction.
ODP distinguishes three different kinds of communication pattern, each
consisting of a pair of matched roles. In the first, the initiator is an object
causing the communication, while the responder is an object that communi-
cates with the initiator in consequence. Next, the producer is an object that
is the source of the information conveyed, while the consumer is the sink for
that information. Finally, the client is an object that requests that a service
be performed by another object, while the server is an object that performs
some service on behalf of a client object. Selecting the appropriate pattern
lets us emphasize the most important properties of the communication being
described.
4.5 Environment Contracts and Transparencies
The computational language also allows the specification of non-functional
properties of computational objects and their interactions. Examples of such
non-functional properties include quality of service (QoS) requirements, usage
or management constraints, service level agreements (SLA) and so on. These
requirements are specified using environment contracts.
The way to specify and represent environment contracts depends on their
nature and on the notation available for this task. For instance, in UML,
environment contracts can be specified in various ways, ranging from timing
constraints associated with object interactions to more sophisticated require-
ments expressed using any of the existing UML profiles for specifying QoS
and real-time properties. One example is the UML profile for MARTE: Mod-
elling and Analysing Real-Time Embedded Systems [35] proposed by the OMG.
In addition, transparency schemata let us express quality of service require-
ments for objects. RM-ODP defines different kinds of transparency, including
access transparency, failure transparency, location transparency, migration
transparency, persistence transparency, relocation transparency, replication
transparency and transaction transparency. Each of these allows the masking
from the computational specification of the problems arising from the aspect
named while still placing a requirement that these concerns should be ad-
dressed somewhere else in the system specifications. In ODP, the engineering
viewpoint is the main place that provides the appropriate mechanisms for
implementing them, and therefore it is normally responsible for clearly spec-
ifying how the requirements imposed by the transparencies selected in the
computational view are fulfilled. Two of the set of transparencies defined by
RM-ODP (the access and location transparencies) are always implied in every
