CORBA includes specifications for services that may be required by distributed objects. In particular, the Naming Service is an essential addition to any ORB. The CORBA services include the following:
Event Service and Notification Service:
In contrast to the Naming Service which allows CORBA objects to be located by name, the Trading Service [OMG 2000a] allows them to be located by attribute – that is, it is a directory service. Its database contains a mapping from service types and their associated attributes onto remote object references of CORBA objects. The service type is a name, and each attribute is a name-value pair. Clients make queries by specifying the type of service required, together with other arguments specifying constraints on the values of attributes, and preferences for the order in which to receive matching offers. Trading servers can form federations in which they not only use their own databases but also perform queries on behalf of one anothers’ clients.
Transaction service and concurrency control service:
The object transaction service [OMG 2003] allows distributed CORBA objects to participate in either flat or nested transactions. The client specifies a transaction as a sequence of RMI calls, which are introduced by begin and terminated by commit or rollback (abort). The ORB attaches a transaction identifier to each remote invocation and deals with begin, commit and rollback requests. Clients can also suspend and resume transactions. The transaction service carries out a two-phase commit protocol. The concurrency control service [OMG 2000b] uses locks to apply concurrency control to the access of CORBA objects. It may be used from within transactions or independently.
Persistent state service:
An persistent objects can be implemented by storing them in a passive form in a persistent object store while they are not in use and activating them when they are needed. Although ORBs activate CORBA objects with persistent object references, getting their implementations from the implementation repository, they are not responsible for saving and restoring the state of CORBA objects.
Life cycle service
The life cycle service defines conventions for creating, deleting, copying and moving CORBA objects. It specifies how clients can use factories to create objects in particular locations, allowing persistent storage to be used if required. It defines an interface that allows clients to delete CORBA objects or to move or copy them to a specified location.
CORBA Naming Service
The CORBA Naming Service is a sophisticated example of the binder described in Chapter 5. It allows names to be bound to the remote object references of CORBA objects within naming contexts.
a naming context is the scope within which a set of names applies – each of the names within a context must be unique. A name can be associated with either an object reference for a CORBA object in an application or with another context in the naming service.
The names used by the CORBA Naming Service are two-part names, called Name Components, each of which consists of two strings, one for the name and the other for the kind of the object. The kind field provides a single attribute that is intended for use by applications and may contain any useful descriptive information; it is not interpreted by the Naming Service.
Although CORBA objects are given hierarchic names by the Naming Service, these names cannot be expressed as pathnames like those of UNIX files.
CORBA Event Service
The CORBA Event Service specification defines interfaces allowing objects of interest, called suppliers, to communicate notifications to subscribers, called consumers. The notifications are communicated as arguments or results of ordinary synchronous CORBA remote method invocations. Notifications may be propagated either by being pushed by the supplier to the consumer or pulled by the consumer from the supplier. In the first case, the consumers implement the PushConsumer interface which includes a method push that takes any CORBA data type as argument. Consumers register their remote object references with the suppliers. The supplier invokes the push method, passing a notification as argument. In the second case, the supplier implements the PullSupplier interface, which includes a method pull that receives any CORBA data type as its return value. Suppliers register their remote object references with the consumers. The consumers invoke the pull method and receive a notification as result.
The notification itself is transmitted as an argument or result whose type is any, which means that the objects exchanging notifications must have an agreement about the contents of notifications. Application programmers, however, may define their own IDL interfaces with notifications of any desired type.
Event channels are CORBA objects that may be used to allow multiple suppliers to communicate with multiple consumers in an asynchronous manner. An event channel acts as a buffer between suppliers and consumers. It can also multicast the notifications to the consumers. Communication via an event channel may use either the push or pull style. The two styles may be mixed; for example, suppliers may push notifications to the channel and consumers may pull notifications from it.
CORBA Notification Service
The CORBA Notification Service extends the CORBA Event Service, retaining all of its features including event channels, event consumers and event suppliers. The event service provides no support for filtering events or for specifying delivery requirements. Without the use of filters, all the consumers attached to a channel have to receive the same notifications as one another. And without the ability to specify delivery requirements, all of the notifications sent via a channel are given the delivery guarantees built into the implementation.
The notification service adds the following new facilities:
Notifications may be defined as data structures. This is an enhancement of the limited utility provided by notifications in the event service, whose type could only be either any or a type specified by the application programmer.
Event consumers may use filters that specify exactly which events they are interested in. The filters may be attached to the proxies in a channel. The proxies will forward notifications to event consumers according to constraints specified in filters in terms of the contents of each notification.
Event suppliers are provided with a means of discovering the events the consumers are interested in. This allows them to generate only those events that are required by the consumers.
Event consumers can discover the event types offered by the suppliers on a channel, which enables them to subscribe to new events as they become available.
It is possible to configure the properties of a channel, a proxy or a particular event. These properties include the reliability of event delivery, the priority of events, the ordering required (for example, FIFO or by priority) and the policy for discarding stored events.
An event type repository is an optional extra. It will provide access to the structure of events, making it convenient to define filtering constraints.
A structured event consists of an event header and an event body. The following example illustrates the contents of the header:
The following example illustrates the information in the body of a structured event:
Filter objects are used by proxies in making decisions as to whether to forward each notification. A filter is designed as a collection of constraints, each of which is a data structure with two components:
A list of data structures, each of which indicates an event type in terms of its domain name and event type, for example, "home", "burglar alarm". The list includes all of the event types to which the constraint should apply.
A string containing a boolean expression involving the values of the event types listed above. For example:
("domain type" == "home" && "event type" == "burglar alarm") && ("bell" != "ringing" !! "door" == "open")
CORBA Security Service
The CORBA Security Service [Blakley 1999, Baker 1997, OMG 2002b] includes the following:
Authentication of principals (users and servers); generating credentials for principals (that is, certificates stating their rights); delegation of credentials is supported
Access control can be applied to CORBA objects when they receive remote method invocations. Access rights may for example be specified in access control lists (ACLs).
Security of communication between clients and objects, protecting messages for integrity and confidentiality.
Auditing by servers of remote method invocations.
Facilities for non-repudiation. When an object carries out a remote invocation on behalf of a principal, the server creates and stores credentials that prove that the invocation was done by that server on behalf of the requesting principal.
CORBA allows a variety of security policies to be specified according to requirements. A message-protection policy states whether client or server (or both) must be authenticated, and whether messages must be protected against disclosure and/or modification.
Access control takes into account that many applications have large numbers of users and even larger numbers of objects, each with its own set of methods. Users are supplied with a special type of credential called a privilege according to their roles.
Objects are grouped into domains. Each domain has a single access control policy specifying the access rights for users with particular privileges to objects within that domain. To allow for the unpredictable variety of methods, each method is classified in terms of one of four generic methods (get, set, use and manage). Get methods just return parts of the object state, set methods alter the object state, use methods cause the object to do some work, and manage methods perform special functions that are not intended to be available for general use. Since CORBA objects have a variety of different interfaces, the access rights must be specified for each new interface in terms of the above generic methods.
In its simplest form, security may be applied in a manner that is transparent to applications. It includes applying the required protection policy to remote method invocations, together with auditing. The security service allows users to acquire their individual credentials and privileges in return for supplying authentication data such as a password.