Information Technology Reference
In-Depth Information
visible anywhere in the application, without worrying about its actual loca-
tion, which may change as the phone concerned is shipped between depots
or departments. The application designer simply marks this object as having
migration transparency by creating a corresponding transparency schema for
that object type, perhaps in the computational viewpoint, because, in this
case, the information type concerned is a supertype, which deals with a wider
range of task types. Note, however, that at this stage UML4ODP does not
support the specification of transparency schemata on individual objects or
types.
This results in the selection of a corresponding engineering template suit-
able for the platforms in use. It provides for the checkpointing, passivating
and reactivating of the object at a different location. It also requests the es-
tablishment of relocation mechanisms for each of the object's interfaces, so
that existing clients do not see errors if they attempt to access the object
while it is moving or after it has moved. In addition, it may be necessary to
update registry or directory entries with the new location if the object was
offering published services.
Another example is the provision of persistence transparency. The
PhoneMob designers may decide that the state of a user dialogue in their
web interface should persist across session failures. This can be achieved by
asking for transparent persistence of this state, resulting in the recording of
the dialogue state to nonvolatile storage at each step and restoration of the
state at the start of any new session.
However, there may be a need for some additional computational design
features as a result. There may have been an implicit assumption that the
application starts in its initial state at the start of a session and that session
restart is the way to escape from consistency problems. If so, some addi-
tional interactions will be needed to allow for the explicit cancellation of the
dialogue to prevent the user being trapped in a neverending series of failed
sessions, in which some incorrect state is restored on every new attempt. Sim-
ilarly, if persistence across processor failure is provided by checkpointing, it
will be necessary to have some process that allows faulty checkpoints to be
abandoned.
Finally, we might ask whether there is really a need for the marking in
the computational specification. Migration transparency sounds like a useful
thing to have, so why not make it mandatory for all objects? Life would be
simpler. The answer is that there is no free lunch. Adding the additional
mechanisms has an associated cost, and so including these mechanisms every-
where, including between objects that are strongly interdependent, may result
in an unacceptable performance hit. By marking only those objects that the
designer can conceive of as moving at some stage, we can reduce cost, since
we can leave out a lot of expensive activity where it is not really needed.
