Information Technology Reference
In-Depth Information
can omit the extra components, since it is clear they will never be needed, and
costs can be reduced by their exclusion. However, if in the future the server
is redesigned so that it does become mobile, the transparency schema for the
application is still on record, and so the infrastructure supporting it can then
be modified to include the recovery mechanisms needed.
This approach of separating the assumptions about the infrastructure from
the way they are satisfied is particularly useful when a widely distributed
application needs to operate in many different kinds of environment. For
example, a user interface client may operate on a desktop or within a mobile
phone. It has the same failure transparency requirements in either case, but
the complexity of providing them differs considerably, with more mechanisms
needed to compensate for the wider range of threats and failure modes in the
mobile case. This is not just a basic communications issue, as the mechanisms
needed to safeguard the persistent state in the client might be quite different in
the two cases, requiring completely new communication paths for the mobile
client to log its transactions at a base location; the static desktop could be
much simpler while providing the same quality of service.
This last example hints that figure 9.1 is an over simplification. Many of
the supporting mechanisms need some additional parameterization; for exam-
ple, transaction transparency mechanisms are likely to need to add transac-
tion identifiers to interactions under their control. Others need to transform
existing parameters; one example is location transparency, which will need
to transform naming parameters from a location-independent to a location-
specific form. In general, adding a transparency will involve the analysis and,
potentially, the modification of the parameters of any interaction for which the
transparency is responsible; this is equivalent to a set of interaction rewriting
rules applied by the supporting virtual machine.
It should be clear from these examples that there is a close relationship
between provision of transparency and virtualization, which is one of the basic
techniques for the support of cloud computing. Transparency aims to simplify
the virtual machine a designer sees, in terms of its management and failure
behaviour; virtualization does the same thing by providing a virtual machine
that offers a slice of some shared resource as if it were provided by a physically
separate platform, independent of other users. Both of these may involve pro-
viding software support that guarantees a particular user view of the services
or resources oered, simplifying the designer's life.
9.2
Types of Transparency
There can be many types of transparency, some of them being domain-
specific or applicable to general aspects such as security. The RM-ODP itself
