Information Technology Reference
In-Depth Information
Management functions: the node management, object management,
cluster management and capsule management functions.
Coordination functions: the event notification, checkpoint and recovery,
deactivation and reactivation, group, replication, migration, transaction,
ACID transaction and engineering interface reference tracking functions.
Repository functions: the storage, information organization, relocation,
type repository and trading functions.
Security functions: access control, security audit, authentication, in-
tegrity, confidentiality, non-repudiation and key-management functions.
This topic cannot deal with the detailed denition of the full set of func-
tions, so we restrict the description to a selection of them, which we use to
illustrate how they can be combined together to provide useful composite
functions to the application designer.
Let's take a look rst at the transaction function. Note that this function
is more general than the ACID transaction function that is normally used
in most bank account management systems. In a real distributed processing
environment (think, for instance, of any system built over the Internet), parties
involved in a transaction may be spread over different cities or countries, and
the transaction may be a long-running process, lasting for days or even weeks.
An object providing this function, therefore, will need to communicate with
all the participating objects or parties involved in the transaction to monitor
the relevant actions and to check for possible inconsistencies.
If an inconsistency is detected, the object will schedule the initialization
of some compensation actions, which are usually local transactions at each
node to remove the changes and effectively bring each object back to its ini-
tial state. For instance, if some money is withdrawn from an account in a
transaction, the compensation action means explicitly depositing the same
amount back into the account, which is different from the typical implicit roll-
back action defined in an ACID transaction. With this approach, the states
of the objects may become temporarily inconsistent but will eventually be-
come consistent again. This function has been defined in detail in several
subsequent standards including a part of the CORBA specifications called
Additional Structuring Mechanisms for the OTS Specification [39] and OASIS
standards called Business Transaction Protocol [42] and Web Services Coor-
dination Framework [43].
Another relevant example is the ODP trading function. This function orig-
inated from the idea of a Yellow Pages service provided by telephone operators;
it allows service providers to export their services to a trader (representing
the set of objects providing the ODP trading function). The consumer objects
can then look up the service, based on a given set of constraints, to get refer-
ences to the objects providing it. This function will sound familiar to many
readers because it has since been at the heart of the SOA architecture and
is the basis for the Web Services specification for UDDI. The ODP trading
