Smartzworld.com Smartworld.

asia
UNIT-2

TIME AND GLOBAL STATES

Failure model:

In a distributed system both processes and communication channels may fail – that
is, they may depart from what is considered to be correct or desirable behaviour.
The failure model defines the ways in which failure may occur in order to provide
an understanding of the effects of failures. Hadzilacos and Toueg provide a
taxonomy that distinguishes between the failures of processes and communication
channels. These are presented under the headings omission failures, arbitrary
failures and timing failures.

Omission failures • The faults classified as omission failures refer to cases when a
process or communication channel fails to perform actions that it is supposed to do.

Process omission failures: The chief omission failure of a process is to crash.

When, say that a process has crashed we mean that it has halted and will not
execute any further steps of its program ever. The design of services that can
survive in the presence of faults can be simplified if it can be assumed that the
services on which they depend crash cleanly – that is, their processes either function
correctly or else stop. Other processes may be able to detect such a crash by the fact
that the process repeatedly fails to respond to invocation messages. However, this
method of crash detection relies on the use of timeouts – that is, a method in which
one process allows a fixed period of time for something to occur. In an
asynchronous system a timeout can indicate only that a process is not responding –
it may have crashed or may be slow, or the messages may not have arrived.

Communication omission failures: Consider the communication primitives send

and receive. A process p performs a send by inserting the message m in its outgoing
message buffer. The communication channel transports m to q’s incoming message
buffer. Process q performs a receive by taking m from its incoming message buffer
and delivering it. The outgoing and incoming message buffers are typically
provided by the operating system.

process p process q

send m receive

Communication channel
Outgoing message buffer Incoming message buffer

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Arbitrary failures The term arbitrary or Byzantine failure is used to describe the
worst possible failure semantics, in which any type of error may occur. For
example, a process may set wrong values in its data items, or it may return a wrong
value in response to an invocation. An arbitrary failure of a process is one in which
it arbitrarily omits intended processing steps or takes unintended processing steps.
Arbitrary failures in processes cannot be detected by seeing whether the process
responds to invocations, because it might arbitrarily omit to reply. Communication
channels can suffer from arbitrary failures; for example, message contents may be
corrupted, nonexistent messages may be delivered or real messages may be
delivered more than once. Arbitrary failures of communication channels are rare
because the communication software is able to recognize them and reject the faulty
messages. For example, checksums are used to detect corrupted messages, and
message sequence numbers can be used to detect nonexistent and duplicated
messages.

Timing failures :

Timing failures are applicable in synchronous distributed systems where time limits
are set on process execution time, message delivery time and clock drift rate.
Timing failures are listed in the following figure. Any one of these failures may
result in responses being unavailable to clients within a specified time interval. In
an asynchronous distributed system, an overloaded server may respond too slowly,
but we cannot say that it has a timing failure since no guarantee has been offered.
Real-time operating systems are designed with a view to providing timing
guarantees, but they are more complex to design and may require redundant
hardware.
Most general-purpose operating systems such as UNIX do not have to meet real-
time constraints.

Masking failures: Each component in a distributed system is generally constructed

from a collection of other components. It is possible to construct reliable services
from components that exhibit failures. For example, multiple servers that hold
replicas of data can continue to provide a service when one of them crashes.
Knowledge of the failure characteristics of a component can enable a new service to
be designed to mask the failure of the components on which it depends. A service
masks a failure either by hiding it altogether or by converting it into a more
acceptable type of failure. For an example of the latter, checksums are used to mask
corrupted messages, effectively converting an arbitrary failure into an omission
failure. The omission failures can be hidden by using a protocol that retransmits
messages that do not arrive at their destination. Even process crashes may be
masked, by replacing the process and restoring its memory from information stored
on disk by its predecessor.
The term reliable communication is defined in terms of validity and
integrity as follows:
Validity: Any message in the outgoing message buffer is eventually delivered to
the incoming message buffer.

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
Integrity: The message received is identical to one sent, and no messages are
delivered twice. The threats to integrity come from two independent sources: Any
protocol that retransmits messages but does not reject a message that arrives twice.
Protocols can attach sequence numbers to messages so as to detect those that are
delivered twice. Malicious users that may inject spurious messages, replay old
messages or tamper with messages. Security measures can be taken to maintain the
integrity property in the face of such attacks.

Security model:
The sharing of resources as a motivating factor for distributed systems, and in
Section 2.3 we described their architecture in terms of processes, potentially
encapsulating higher-level abstractions such as objects, components or services, and
providing access to them through interactions with other processes. That
architectural model provides the basis for our security model: the security of a
distributed system can be achieved by securing the processes and the channels used
for their interactions and by protecting the objects that they encapsulate against
unauthorized access. Protection is described in terms of objects, although the
concepts apply equally well to resources of all types

Protecting object: Server that manages a collection of objects on behalf of some

users. The users can run client programs that send invocations to the server to
perform operations on the objects. The server carries out the operation specified in
each invocation and sends the result to the client.
Objects are intended to be used in different ways by different users. For example,
some objects may hold a user’s private data, such as their mailbox, and other
objects may hold shared data such as web pages. To support this, access rights
specify who is allowed to perform the operations of an object – for example, who is
allowed to read or to write its state.

Access rights Object

invocation

Client
result Server

Principal (user) Network Principal (server)

Securing processes and their interactions: Processes interact by sending

messages. The messages are exposed to attack because the network and the
communication service that they use

The enemy To model security threats, we postulate an enemy (sometimes also

known as the adversary) that is capable of sending any message to any process and
reading or copying any message sent between a pair of processes, as shown in the
following figure. Such attacks can be made simply by using a computer connected
to a network to run a program that reads network messages addressed to other
computers on the network, or a program that generates messages that make false
requests to services, purporting to come from authorized users. The attack may
come from a computer that is legitimately connected to the network or from one
that is connected in an unauthorized manner. The threats from a potential enemy
include threats to processes and threats to communication channels.

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Defeating security threats:

Cryptography and shared secrets: Suppose that a pair of processes (for example, a
particular client and a particular server) share a secret; that is, they both know the
secret but no other process in the distributed system knows it. Then if a message
exchanged by that pair of processes includes information that proves the sender’s
knowledge of the shared secret, the recipient knows for sure that the sender was the
other process in the pair. Of course, care must be taken to ensure that the shared
secret is not revealed to an enemy.

Cryptography: is the science of keeping messages secure, and encryption is the

process of scrambling a message in such a way as to hide its contents. Modern
cryptography is based on encryption algorithms that use secret keys – large
numbers that are difficult to guess – to transform data in a manner that can only be
reversed with knowledge of the corresponding decryption key.

Authentication: The use of shared secrets and encryption provides the basis for the
authentication of messages – proving the identities supplied by their senders. The
basic authentication technique is to include in a message an encrypted portion that
contains enough of the contents of the message to guarantee its authenticity. The
authentication portion of a request to a file server to read part of a file, for example,
might include a representation of the requesting principal’s identity, the identity of
the file and the date and time of the request, all encrypted with a secret key shared
between the file server and the requesting process. The server would decrypt this
and check that it corresponds to the unencrypted details specified in the request.

Secure channels: Encryption and authentication are used to build secure channels
as a service layer on top of existing communication services. A secure channel is a
communication channel connecting a pair of processes, each of which acts on
behalf of a principal, as shown in the following figure. A secure channel has the
following properties: Each of the processes knows reliably the identity of the
principal on whose behalf the other process is executing. Therefore if a client and
server communicate via a secure channel, the server knows the identity of the
principal behind the invocations and can check their access rights before performing
an operation. This enables the server to protect its objects correctly and allows the
client to be sure that it is receiving results from a bona fide server. A secure
channel ensures the privacy and integrity (protection against tampering) of the data
transmitted across it. Each message includes a physical or logical timestamp to
prevent messages from being replayed or reordered. Communication aspects of
middleware, although the principles discussed are more widely applicable. This one
is concerned with the design of the components shown in the darker layer in the
following figure.

Applications, services

RMI and RPC

request-reply protocol Middleware

This
layers
chapter
marshalling and external data representation

UDP and TCP

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

The application program interface to UDP provides a message passing abstraction–

the simplest form of interposes communication. This enables a sending process to
transmit a single message to a receiving process. The independent packets
containing these messages are called datagrams. In the Java and UNIX APIs, the
sender specifies the destination using a socket – an indirect reference to a particular
port used by the destination process at a destination computer. The application
program interface to TCP provides the abstraction of a two-way stream between
pairs of processes. The information communicated consists of a stream of data
items with no message boundaries. Streams provide a building block for producer-
consumer communication. A producer and a consumer form a pair of processes in
which the role of the first is to produce data items and the role of the second is to
consume them. The data items sent by the producer to the consumer are queued on
arrival at the receiving host until the consumer is ready to receive them. The
consumer must wait when no data items are available. The producer must wait if the
storage used to hold the queued data items is exhausted.

DISTRIBUTED SHARED MEMORY

Distributed shared memory (DSM) is an abstraction used for sharing data between
computers that do not share physical memory. Processes access DSM by reads and
updates to what appears to be ordinary memory within their address space.
However, an underlying runtime system ensures transparently that processes
executing at different computers observe the updates made by one another.
The main point of DSM is that it spares the programmer the concerns of message
passing when writing applications that might otherwise have to use it. DSM is
primarily a tool for parallel applications or for any distributed application or group
of applications in which individual shared data items can be accessed directly. DSM
is in general less appropriate in client-server systems, where clients normally view
server-held resources as abstract data and access them by request (for reasons of
modularity and protection).

Message passing cannot be avoided altogether in a distributed system: in the

absence of physically shared memory, the DSM runtime support has to send
updates in messages between computers. DSM systems manage replicated data:
each computer has a local copy of recently accessed data items stored in DSM, for
speed of access.
In distributed memory multiprocessors and clusters of off-the-shelf computing
components (see Section 6.3), the processors do not share memory but are
connected by a very high-speed network. These systems, like general-purpose
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
distributed systems, can scale to much greater numbers of processors than a shared-
memory multiprocessor’s 64 or so. A central question that has been pursued by the
DSM and multiprocessor research communities is whether the investment in
knowledge of shared memory algorithms and the associated software can be
directly transferred to a more scalable distributed memory architecture.
Message passing versus DSM
As a communication mechanism, DSM is comparable with message
passing rather than with request-reply-based communication, since its
application to parallel processing, in particular, entails the use of
asynchronous communication. The DSM and message passing
approaches to programming can be contrasted as follows:
Programming model:
Under the message passing model, variables have to be marshalled from one
process, transmitted and unmarshalled into other variables at the receiving process.
By contrast, with shared memory the processes involved share variables directly, so
no marshalling is necessary – even of pointers to shared variables – and thus no
separate communication operations are necessary.
Efficiency :
Experiments show that certain parallel programs developed for DSM can be made
to perform about as well as functionally equivalent programs written for message
passing platforms on the same hardware – at least in the case of relatively small
numbers of computers (ten or so). However, this result cannot be generalized. The
performance of a program based on DSM depends upon many factors, as we shall
discuss below – particularly the pattern of data sharing.
Implementation approaches to DSM
Distributed shared memory is implemented using one or a combination of
specialized hardware, conventional paged virtual memory or middleware:
Hardware:
Shared-memory multiprocessor architectures based on a NUMA architecture rely
on specialized hardware to provide the processors with a consistent view of shared
memory. They handle

memory LOAD and STORE instructions by communicating with remote

memory and cache modules as necessary to store and retrieve data.

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
Paged virtual memory:
Many systems, including Ivy and Mether , implement DSM as a region of
virtual memory occupying the same address range in the address space of
every participating process.
#include
"world.h"
struct
shared { int
a, b; };
Program
Writer:
main()
{
struct shared *p;
methersetup(); /* Initialize the
Mether runtime */ p = (struct
shared *)METHERBASE;
/* overlay structure on METHER
segment */ p->a = p->b = 0; /*
initialize fields to zero */

while(TRUE){ /* continuously update

structure fields */ p –>a = p –>a + 1;
p –>b = p –>b - 1;
}
}
Program Reader:
main()
{
stru
ct
sha
red
*p;
met
her
setu
p();

jntuworldupdates.org p = (struct shared *)METHERBASE; Specworld.in

Smartzworld.com Smartworld.asia
while(TRUE){ /* read the fields once
every second */ printf("a = %d, b =
%d\n", p –>a, p –>b);
sleep(1);
}
}
Middleware:
Some languages such as Orca, support forms of DSM without any hardware or
paging support, in a platform-neutral way. In this type of implementation, sharing is
implemented by communication between instances of the user-level support layer in
clients and servers. Processes make calls to this layer when they access data items
in DSM. The instances of this layer at the different computers access local data
items and communicate as necessary to maintain consistency.
Design and implementation issues
The synchronization model used to access DSM consistently at the application
level; the DSM consistency model, which governs the consistency of data values
accessed from different computers; the update options for communicating written
values between computers; the granularity of sharing in a DSM implementation;
and the problem of thrashing.
Structure
A DSM system is just such a replication system. Each application process is
presented with some abstraction of a collection of objects, but in this case the
‘collection’ looks more or less like memory. That is, the objects can be addressed in
some fashion or other. Different approaches to
DSM vary in what they consider to be an ‘object’ and in how objects are addressed.
We consider three approaches, which view DSM as being composed respectively of
contiguous bytes, language-level objects or immutable data items.
Byte-oriented
This type of DSM is accessed as ordinary virtual memory – a contiguous array of
bytes. It is the view illustrated above by the Mether system. It is also the view of
many other DSM systems, including Ivy.It allows applications (and language
implementations) to impose whatever data structures they want on the shared
memory. The shared objects are directly addressible memory locations (in practice,
the shared locations may be multi-byte words rather than individual bytes). The
only operations upon those objects are read (or LOAD) and write (or STORE). If x
and y are two memory locations, then we denote instances of these operations as
follows:
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
Object-oriented
The shared memory is structured as a collection of language-level objects with
higher-level semantics than simple read / write variables, such as stacks and
dictionaries. The contents of the shared memory are changed only by invocations
upon these objects and never by direct access to their member variables. An
advantage of viewing memory in this way is that object semantics can be utilized
when enforcing consistency.
Immutable data
When reading or taking a tuple from tuple space, a process provides a tuple
specification and the tuple space returns any tuple that matches that specification –
this is a type of associative addressing. To enable processes to synchronize their
activities, the read and take operations both block until there is a matching tuple in
the tuple space.
Synchronization model
Many applications apply constraints concerning the values stored in shared
memory. This is as true of applications based on DSM as it is of applications
written for sharedmemory multiprocessors (or indeed for any concurrent programs
that share data, such as operating system kernels and multi-threaded servers). For
example, if a and b are two variables stored in DSM, then a constraint might be that
a=b always. If two or moreprocesses execute the following code:

then an inconsistency may arise. Suppose a and b are initially zero and that process
1gets as far as setting a to 1. Before it can increment b, process 2 sets a to 2 and b to
1.
Consistency model
The local replica manager is implemented by a combination of middleware (the
DSM runtime layer in each process) and the kernel. It is usual for middleware to
perform the majority of DSM processing. Even in a page-based DSM
implementation, the kernel usually provides only basic page mapping, page-fault
handling and communication mechanisms and middleware is responsible for
implementing the page-sharing policies. If DSM segments are persistent, then one
or more storage servers (for example, file servers) will also act as replica managers.

Sequential consistency

A DSM system is said to be sequentially consistent if for any execution there is

some interleaving of the series of operations issued by all the processes that satisfies
jntuworldupdates.org the following two criteria: Specworld.in
Smartzworld.com Smartworld.asia
SC1: The interleaved sequence of operations is such that if R(x) a occurs in
the sequence, then either the last write operation that occurs before it in the
interleaved sequence is W(x) a, or no write operation occurs before it and a is the
initial value of x.
SC2: The order of operations in the interleaving is consistent with the
program order in which each individual client executed them.

Coherence

Coherence is an example of a weaker form of consistency. Under coherence, every

process agrees on the order of write operations to the same location, but they do not
necessarily agree on the ordering of write operations to different locations. We can
think of coherence as sequential consistency on a locationby- location basis.
Coherent DSM can be implemented by taking a protocol for implementing
sequential consistency and applying it separately to each unit of replicated data –
for example, each page.

Weak consistency
This model exploits knowledge of synchronization operations in order to relax
memory consistency, while appearing to the programmer to implement sequential
consistency (at least, under certain conditions that are beyond the scope of this
book). For example, if the programmer uses a lock to implement a critical section,
then a DSM system can assume that no other process may access the data items
accessed under mutual exclusion within it. It is therefore redundant for the DSM
system to propagate updates to these items until the process leaves the critical
section.
While items are left with ‘inconsistent’ values some of the time, they are not
accessed at those points; the execution appears to be sequentially consistent.
Update options
Two main implementation choices have been devised for propagating updates made
by one process to the others: write-update and write-invalidate. These are applicable
to a variety of DSM consistency models, including sequential consistency. In
outline, the options are as follows:
Write-update: The updates made by a process are made locally and multicast to all
other replica managers possessing a copy of the data item, which immediately
modify the data read by local processes. Processes read the local copies of data
items, without the need for communication. In addition to allowing multiple
readers, several processes may write the same data item at the same time; this is
known as multiple-reader/multiple-writer sharing.
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Write-invalidate: This is commonly implemented in the form of multiple-reader/

single-writer sharing. At any time, a data item may either be accessed in read-only
mode by one or more processes, or it may be read and written by a single process.
An item that is currently accessed in read-only mode can be copied indefinitely to
other processes. When a process attempts to write to it, a multicast message is first
sent to all other copies to invalidate them and this is acknowledged before the write
can take place; the other processes are thereby prevented from reading stale data
(that is, data that are not up to date). Any processes attempting to access the data
item are blocked if a writer exists.
Granularity
An issue that is related to the structure of DSM is the granularity of sharing.
Conceptually, all processes share the entire contents of a DSM. As programs
sharing DSM execute, however, only certain parts of the data are actually shared
and then only for certain times during the execution. It would clearly be very
wasteful for the DSM implementation always to transmit the entire contents of
DSM as processes access and update it.
Thrashing
A potential problem with write-invalidate protocols is thrashing. Thrashing is said
to occur where the DSM runtime spends an inordinate amount of time invalidating
and transferring shared data compared with the time spent by application processes
doing useful work. It occurs when several processes compete for the same data
item, or for falsely shared data items.
The system model
The basic model to be considered is one in which a collection of processes shares a
segment of DSM. The segment is mapped to the same range of addresses in each
process, so that meaningful pointer values can be stored in the segment. The
processes execute at computers equipped with a paged memory management unit.
We shall assume that there is only one process per computer that accesses the DSM
segment. There may in reality be several such processes at a computer. However,
these could then share DSM pages directly (the same page frame can be used in the
page tables used by the different processes). The only complication would be to
coordinate fetching and propagating updates to a page when two or more local
processes access it. This description ignores such details. Paging is transparent to
the application components within processes; they can logically both read and write
any data in DSM. However, the DSM runtime restricts page access permissions in
jntuworldupdates.org order to maintain sequential consistency when processing reads and writes. Paged
Specworld.in
Smartzworld.com Smartworld.asia
memory management units allow the access permissions to a data page to be set to
none, read-only or read-write.
The problem of write-update
The previous section outlined the general implementation alternatives of write-
update and write-invalidation. In practice, if the DSM is page-based, then write-
update is used only if writes can be buffered. This is because standard page-fault
handling is unsuited to the task of processing every single write update to a page.
Write invalidation
Invalidation-based algorithms use page protection to enforce consistent data
sharing. When a process is updating a page, it has read and write permissions
locally; all other processes have no access permissions to the page. When one or
more processes are reading the page, they have read-only permission; all other
processes have no access permissions (although they may acquire read
permissions). No other combinations are possible.
Invalidation protocols
Two important problems remain to be addressed in a protocol to implement the
invalidation scheme:
How to locate owner(p) for a given page p.
Where to store copyset(p).

For Ivy, Li and Hudak [1989] describe several architectures and protocols that take
varying approaches to these problems. The simplest we shall describe is their
improved centralized manager algorithm. In it, a single server called a manager is
used to store the location (transport address) of owner(p) for every page p. The
manager could be one of the processes running the application, or it could be any
other process. In this algorithm, the set copyset(p) is stored at owner(p). That is, the
identifiers and transport addresses of the members of copyset(p) are stored.

Using multicast to locate the owner

Multicast can be used to eliminate the manager completely. When a process faults,
it multicasts its page request to all the other processes. Only the process that owns
the page replies. Care must be taken to ensure correct behaviour if two clients
request the same page at more or less the same time: each client must obtain the
page eventually, even if its request is multicast during transfer of ownership.

A dynamic distributed manager algorithm

The owner of a page is located by following chains of hints that are set up as
ownership of the page is transferred from computer to computer. The length of the
chain – that is, the number of forwarding messages necessary to locate the owner –
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
threatens to increase indefinitely. The algorithm overcomes this by updating the
hints as more upto- date values become available. Hints are updated and requests
are forwarded as follows: The first three updates follow simply from the protocol
for transferring page ownership and providing read-only copies. The rationale for
the update when forwarding requests is that, for write requests, the requester will
soon be the owner, even though it is not currently. In fact, in Li and Hudak’s
algorithm, assumed here, the probOwner update is made whether the request is for
read access or write access.

OTHER CONSISTENCY MODELS

Models of memory consistency can be divided into uniform models, which do not
distinguish between types of memory access, and hybrid models, which do
distinguish between ordinary and synchronization accesses (as well as other types
of access).
Other uniform consistency models include:
Causal consistency: Reads and writes may be related by the happened-before
relationship . This is defined to hold between memory operations when either (a)
they are made by the same process; (b) a process reads a value written by another
process; or (c) there exists a sequence of such operations linking the two operations.
The model’s constraint is that the value returned by a read must be consistent with
the happened-before relationship.
Processor consistency: The memory is both coherent and adheres to the pipelined
RAM model (see below). The simplest way to think of processor consistency is that
the memory is coherent and that all processes agree on the ordering of any two
write accesses made by the same process
– that is, they agree with its program order.

Pipelined RAM: All processors agree on the order of writes issued by any
given processor In addition to release consistency, hybrid models include:
Entry consistency: Entry consistency was proposed for the Midway DSM system. In
this model, every shared variable is bound to a synchronization object such as a
lock, which governs access to that variable. Any process that first acquires the lock
is guaranteed to read the latest value of the variable. A process wishing to write the
variable must first obtain the corresponding lock in
‘exclusive’ mode – making it the only process able to access the variable.
Several processes may read the variable concurrently by holding the lock in
nonexclusive mode. Midway avoids the tendency to false sharing in release
consistency, but at the expense of increased programming complexity.
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
Scope consistency: This memory model [Iftode et al. 1996] attempts to simplify the
programming model of entry consistency. In scope consistency, variables are
associated with synchronization objects largely automatically instead of relying on
the programmer to associate locks with variables explicitly. For example, the
system can monitor which variables are updated in a critical section.
Weak consistency: Weak consistency [Dubois et al. 1988] does not distinguish
between acquire and release synchronization accesses. One of its guarantees is that
all previous ordinary accesses complete before either type of synchronization
access completes.

Common Object Request Broker Architecture (CORBA)

CORBA is a middeware design that allows application programs to
communicate with one another irrespective of their programming languages, their
hardware and software platforms, the networks they communicate over and their
implementors.
Applications are built from CORBA objects, which implement interfaces
defined in
CORBA’s interface definition language, IDL. Clients access the methods in the IDL
interfaces of CORBA objects by means of RMI. The middleware component that
supports RMI is called the Object Request Broker or ORB.
Introduction
The OMG (Object Management Group) was formed in 1989 with a view to
encouraging the adoption of distributed object systems in order to gain the benefits
of object-oriented programming for software development and to make use of
distributed systems, which were becoming widespread. To achieve its aims, the
OMG advocated the use of open systems based on standard object-oriented
interfaces. These systems would be built from heterogeneous hardware, computer
networks, operating systems and programming languages.
An important motivation was to allow distributed objects to be implemented in any
programming language and to be able to communicate with one another. They
therefore designed an interface language that was independent of any specific
implementation language. They introduced a metaphor, the object request broker(or
ORB), whose role is to help a client to invoke a method on an object. This role
involves locating the object, activating the object if necessary and then
communicating the client’s request to the object, which carries it out and replies.
In 1991, a specification for an object request broker architecture known as CORBA
(Common Object Request Broker Architecture) was agreed by a group of
companies. This was followed in 1996 by the CORBA 2.0 specification, which
jntuworldupdates.org defined standards enabling implementations made by different developers Specworld.in
to
Smartzworld.com Smartworld.asia
communicate with one another. These standards are called the General Inter-ORB
protocol or GIOP. It is intended that GIOP can be implemented over any transport
layer with connections. The implementation of GIOP for the Internet uses the TCP
protocol and is called the Internet Inter-ORB Protocol or IIOP [OMG 2004a].
CORBA 3 first appeared in late 1999 and a component model has been added
recently.
The main components of CORBA’s language-independent RMI framework are the
following: An interface definition language known as IDL,
The GIOP defines an external data representation, called CDR. It also defines
specific formats for the messages in a request-reply protocol. In addition to request
and reply messages, it specifies messages for enquiring about the location of an
object, for cancelling requests and for reporting errors. The IIOP, an
implementation of GIOP defines a standard form for remote object references,
CORBA RMI

Programming in a multi-language RMI system such as CORBA RMI requires more

of the programmer than programming in a single-language RMI system such as
Java RMI.
The following new concepts need to be learned:
the object model offered by CORBA; the interface definition language and its
mapping onto the implementation language.
CORBA's object model
The CORBA object model is similar to the one described in , but clients are not
necessarily objects – a client can be any program that sends request messages to
remote objects and receives replies. The term CORBA object is used to refer to
remote objects. Thus, a CORBA object implements an IDL interface, has a remote
object reference and is able to respond to invocations of methods in its IDL
interface. A CORBA object can be implemented by a language that is not
objectoriented, for example without the concept of class. Since implementation
languages will have different notions of class or even none at all, the class concept
does not exist in CORBA. Therefore classes cannot be defined in CORBA IDL,
which means that instances of classes cannot be passed as arguments.

CORBA IDL
These are preceded by definitions of two structs, which are used as parameter types
in defining the methods. Note in particular that GraphicalObject is defined as a
struct , whereas it was a class in the Java RMI example. A component whose type is
a struct has a set of fields containing values of various types like the instance
variables of an object, but it has no methods.
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
Parameters and results in CORBA IDL:
Each parameter is marked as being for input or output or both, using the keywords
in , out or inout illustrates a simple example of the use of those keywords

The semantics of parameter passing are as follows:

Passing CORBA objects:
Any parameter whose type is specified by the name of an IDL interface, such as the
return value
Shape in line 7, is a reference to a CORBA object and the value of a remote object
reference is passed.
Passing CORBA primitive and constructed types:
Arguments of primitive and constructed types are copied and passed by value. On
arrival, a new value is created in the recipient’s process. For example, the struct
GraphicalObject passed as argument (in line 7) produces a new copy of this struct
at the server.
Type Object :
Object is the name of a type whose values are remote object references. It is
effectively a common supertype of all of IDL interface types such as Shape and
ShapeList.

Exceptions in CORBA IDL:

CORBA IDL allows exceptions to be defined in interfaces and thrown by their
methods. To illustrate this point, we have defined our list of shapes in the server as
a sequence of a fixed length (line 4) and have defined FullException (line 6), which
is thrown by the method newShape (line 7) if the client attempts to add a shape
when the sequence is full.
Invocation semantics:
Remote invocation in CORBA has at-most-once call semantics as the default.
However, IDL may specify that the invocation of a particular method has maybe
semantics by using the oneway keyword. The client does not block on oneway
requests, which can be used only for methods without results.

The CORBA Naming service

It is a binder that provides operations including rebind for servers to register the
remote object references of CORBA objects by name and resolve for clients to look
them up by name. The names are structured in a hierarchic fashion, and each name
in a path is inside a structure called a
NameComponent . This makes access in a simple example seem rather complex.
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

CORBA pseudo objects

Implementations of CORBA provide interfaces to the functionality of the ORB that
programmers need to use. In particular, they include interfaces to two of the
components in the ORB core and the Object Adaptor
CORBA client and server example
This is followed by a discussion of callbacks in CORBA. We use Java as the client
and server languages, but the approach is similar for other languages. The interface
compiler idlj can be applied to the CORBA interfaces to generate the following
items:

The equivalent Java interfaces – two per IDL interface. The name of the first Java
interface ends in Operations – this interface just defines the operations in the IDL
interface. The Java second interface has the same name as the IDL interface and
implements the operations in the first interface as well as those in an interface
suitable for a CORBA object.

The server skeletons for each idl interface. The names of skeleton classes end in
POA , for example ShapeListPOA.

The proxy classes or client stubs, one for each IDL interface. The names of these
classes end in Stub , for example _ShapeListStub\

A Java class to correspond to each of the structs defined with the IDL interfaces.
In our example, classes Rectangle and GraphicalObject are generated. Each of
these classes contains a declaration of one instance variable for each field in the
corresponding struct and a pair of constructors, but no other methods.

Classes called helpers and holders, one for each of the types defined in the IDL
interface. A helper class contains the narrow method, which is used to cast down
from a given object reference to the class to which it belongs, which is lower down
the class hierarchy. For example, the narrow method in ShapeHelper casts down to
class Shape . The holder classes deal with out and inout arguments, which cannot be
mapped directly onto Java.

Server program
The server program should contain implementations of one or more IDL interfaces.
For a server written in an object-oriented language such as Java or C++, these
implementations are implemented as servant classes. CORBA objects are instances
of servant classes.
When a server creates an instance of a servant class, it must register it with the
POA, which makes the instance into a CORBA object and gives it a remote object
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
reference. Unless this is done, the CORBA object will not be able to receive remote
invocations. Readers who studied Chapter 5 carefully may realize that registering
the object with the POA causes it to be recorded in the CORBA equivalent of the
remote object table.

The client program

It creates and initializes an ORB (line 1), then contacts the Naming Service to get a
reference to the remote ShapeList object by using its resolve method (line 2). After
that it invokes its method allShapes (line 3) to obtain a sequence of remote object
references to all the Shapes currently held at the server. It then invokes the
getAllState method (line 4), giving as argument the first remote object reference in
the sequence returned; the result is supplied as an instance of the
GraphicalObject class.

Callbacks
Callbacks can be implemented in CORBA in a manner similar to the one described
for Java RMI For example, the WhiteboardCallback interface may be defined as
follows:
interface
WhiteboardCallback {
oneway void
callback(in int version);
};
This interface is implemented as a CORBA object by the client, enabling the server
to send the client a version number whenever new objects are added. But before the
server can do this, the client needs to inform the server of the remote object
reference of its object. To make this possible, the ShapeList interface requires
additional methods such as register and deregister, as follows:
int register(in
WhiteboardCallback callback);
void deregister(in int
callbackId);

After a client has obtained a reference to the ShapeList object and created an
instance of
WhiteboardCallback, it uses the register method of ShapeList to inform the server
that it is interested in receiving callbacks. The ShapeList object in the server is
responsible for keeping a list of interested clients and notifying all of them each
time its version number increases when a new object is added.
jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
The architecture of CORBA
The architecture is designed to support the role of an object request broker that
enables clients to invoke methods in remote objects, where both clients and servers
can be implemented in a variety of programming languages. The main components
of the CORBA architecture are illustrated in Figure

CORBA provides for both static and dynamic invocations. Static invocations are
used when the remote interface of the CORBA object is known at compile time,
enabling client stubs and server skeletons to be used. If the remote interface is not
known at compile time, dynamic invocation must be used. Most programmers
prefer to use static invocation because it provides a more natural programming
model.
ORB core ◊ The role of the ORB core is similar to that of the communication
module . In addition, an ORB core provides an interface that includes the following:
operations enabling it to be started and stopped;
operations to convert between remote object references and strings;
operations to provide argument lists for requests using dynamic invocation.
Object adapter
The role of an object adapter is to bridge the gap between CORBA objects with
IDL interfaces and the programming language interfaces of the corresponding
servant classes. This role also includes that of the remote reference and dispatcher
modules. An object adapter has the following tasks:
it creates remote object references for CORBA objects;

it dispatches each RMI via a skeleton to the appropriate servant;

it activates and deactivates servants.
An object adapter gives each CORBA object a unique object name, which forms
part of its remote object reference. The same name is used each time an object is
activated. The object name may be specified by the application program or
generated by the object adapter. Each CORBA object is registered with its object
adapter, which may keep a remote object table that maps the names of CORBA
objects to their servants.
Portable object adapter
The CORBA 2.2 standard for object adapters is called the Portable Object
Adapter. It is called portable because it allows applications and servants to be
run on ORBs produced by different developers [Vinoski 1998]. This is achieved
by means of the standardization of the skeleton classes and of the interactions

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia
between the POA and the servants. The POA supports CORBA objects with two
different sorts of lifetimes:
those whose lifetimes are restricted to that of the process their servants are
instantiated in;
those whose lifetimes can span the instantiations of servants in multiple
processes.
Skeletons
Skeleton classes are generated in the language of the server by an IDL compiler. As
before, remote method invocations are dispatched via the appropriate skeleton to a
particular servant, and the skeleton unmarshals the arguments in request messages
and marshals exceptions and results in reply messages.
Client stubs/proxies
These are in the client language. The class of a proxy (for object oriented
languages) or a set of stub procedures (for procedural languages) is generated from
an IDL interface by an IDL compiler for the client language. As before, the client
stubs/proxies marshal the arguments in invocation requests and unmarshal
exceptions and results in replies.
Implementation repository
An implementation repository is responsible for activating registered servers on
demand and for locating servers that are currently running. The object adapter
name is used to refer to servers when registering and activating them. An
implementation repository stores a mapping from the names of object adapters to
the pathnames of files containing object implementations.
Object implementations and object adapter names are generally registered with the
implementation repository when server programs are installed. When object
implementations are activated in servers, the hostname and port number of the
server are added to the mapping.

jntuworldupdates.org Specworld.in