| Previous | Table of Contents | Next |
The ORB Services used are determined by:
• Static properties of both client and server objects; for example, whether a server is replicated.
• Dynamic attributes determined by a particular invocation context; for example, whether a request is transactional.
• Administrative policies (e.g., security).
Within a single ORB, private mechanisms (and optimizations) can be used to establish which ORB Services are required and how
they are provided. Service selection might in general require negotiation to select protocols or protocol options. The same
is true between different ORBs: it is necessary to agree which ORB Services are used, and how each transforms the request.
Ultimately, these choices become manifest as one or more protocols between the ORBs or as transformations of requests.
In principle, agreement on the use of each ORB Service can be independent of the others and, in appropriately constructed
ORBs, services could be layered in any order or in any grouping. This potentially allows applications to specify selective
transparencies according to their requirements, although at this time CORBA provides no way to penetrate its transparencies.
A client ORB must be able to determine which ORB Services must be used in order to invoke operations on a server object. Correspondingly,
where a client requires dynamic attributes to be associated with specific invocations, or administrative policies dictate,
it must be possible to cause the appropriate ORB Services to be used on client and server sides of the invocation path. Where
this is not possible - because, for example, one ORB does not support the full set of services required - either the interaction
cannot proceed or it can only do so with reduced facilities or transparencies.