522 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 9
As we have stated, to a client there is no difference between an object group and any other type of CORBA object. To create an object group, a client simply invokes the normal create�object operation as offered, in this case, by the replication manager, specifying the type of object to create. The client remains unaware of the fact that it is implicitly creating an object group. The number of replicas that are created when starting a new object group is normally determined by the system-dependent default value. The replica manager is also responsible for replacing a replica in the case of a failure, thereby ensuring that the number of replicas does not drop below a specified minimum.
The architecture also shows the use of message-level interceptors. In the case of the Eternal system, each invocation is intercepted and passed to a separate replication component that maintains the required consistency for an object group and which ensures that messages are logged to enable recovery.
Invocations are subsequently sent to the other group members using reliable, totally-ordered multicasting. In the case of active replication, an invocation request is passed to each replica object by handing it to that object’ s underlying ORB. However, in the case of passive replication, an invocation request is passed only to the ORB of the primary, whereas the other servers only log the invocation request for recovery purposes. When the primary has completed the invocation, its state is then multicast to the backups.
9.1.8 Security
CORBA security has a long history. The initial versions of the CORBA specifications hardly touched upon the subject for the simple reason that several attempts to specify a security service failed. In CORBA version 2.4, the security services take over 400 pages to specify and to make clear how security should fit into CORBA systems. Let us now take a closer look at CORBA security. An overview of these matters can be found in( Blakley, 2000), which was written by one of the authors of the original CORBA security specifications.
An important specification issue for security in CORBA is that services should provide an appropriate collection of mechanisms that can be used to implement a variety of security policies. What complicates matters is that these services should be offered at different points in time and space. For example, if a client wants to securely invoke an object, we need to decide when security mechanisms are to be used( e. g., at binding time, invocation time, or both), and where these mechanisms should be used( e. g., at the level of an application, inside an ORB, or during message transfer).
The heart of CORBA security is formed by the support for secure object invocations. The underlying idea is that application-level objects should be unaware of the various security services that are used. However, if a client has specific security requirements, the client should be allowed to specify those requirements so that they can be taken into account when an object is invoked. An analogous