CORBA SERVICES
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:
Naming Service:
Event Service and Notification Service:
Security service:
Trading 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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.