UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

MODULE IN NAS 5: DISTRIBUTED SYSTEMS

Effective: 1ST Semester, 2020-2021

Distributed Systems
CHAPTER 4:
DISTRIBUTED HETEROGENEOUS

Wilbert P. Umadhay
Instructor email:
[email protected]

CHAPTER GOALS

In this chapter the student should learn:

1. Heterogeneity in Distributed Systems
2. Middleware
3. Objects in Distributed Systems
4. The CORBA Approach
5. Components of a CORBA Environment
6. CORBA Services

Wilbert P. Umadhay P a g e 1 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

Heterogeneity in Distributed Systems Distributed

applications are typically heterogeneous:
-Different hardware: mainframes, workstations, PCs, servers, etc.
-different software: UNIX, MS Windows, IBM OS/2, Real-time OSs, etc.
-Unconventional devices: teller machines, telephone switches, robots, manufacturing
systems, etc.
-Diverse networks and protocols: Ethernet, FDDI, ATM, TCP/IP, Novell Netware, etc.

Why are distributed application heterogeneous?

-Different hardware/software solutions are considered to be optimal for different parts of
the system.
-Different users which have to interact are deciding for different hardware/software
solutions/vendors.
-Legacy systems.

Middleware
A key component of a heterogeneous distributed client-server environment is middleware.
Middleware is a set of services that enable applications and end users to interact with each
other across a heterogeneous distributed system. Middleware software resides above the
network and below the application software.

Middleware should make the network transparent to the applications and end-users, users
and applications should be able to perform the same operations across the network that
they can perform locally.

Wilbert P. Umadhay P a g e 2 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

Middleware should hide the details of computing hardware, OS, software components
across networks.
Different kind of software qualifies, to certain extent, as middleware: File-transfer packages
(FTP) and email; Web browsers; CORBA

Objects in Distributed Systems

A distributed application can be viewed as a collection of objects (user interfaces,
databases, application modules, customers).

A distributed application can be viewed as a collection of objects (user interfaces,

databases, application modules, customers).

Object: data surrounded by code; has its own attributes and methods which define the
behavior of the object; objects can be clients, servers, or both.

Object broker: allows objects to find each other and interact over a network; they are the
backbone of the distributed system.

Object services: allow to create, name, move, copy, store, delete, restore, and manage
objects.

Wilbert P. Umadhay P a g e 3 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

RMI: Object in Distributed Systems

Wilbert P. Umadhay P a g e 4 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

Wilbert P. Umadhay P a g e 5 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

Interface Definition Language

An interface specifies the API (Application Programming Interface) that the clients can use
to invoke operations on objects:
-the set of operations
-the parameters needed to perform the operations.

Interfaces are defined by using an interface definition language (IDL). CORBA IDL is an
example of such a language.

IDLs are declarative languages; they do not specify any executable code, but only
declarations.

Middleware products (such as CORBA) provide interface compilers that parse the IDL
description of the interface. Such a compiler produces the code which represents:
-classes corresponding to the proxies (in the language of the client).
-classes corresponding to the skeletons (in the language of the server).

Language mappings have to be defined which allow to generate proxies and skeletons in the
implementation languages of the clients and of the server respectively.

Wilbert P. Umadhay P a g e 6 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

CORBA

Object Management Group (OMG): a non-profit industry consortium formed in 1989 with
the goal to develop, adopt, and promote standards for the development of distributed
heterogeneous applications.

One of the main achievements of OMG is the specification of a Common Object Request
Broker Architecture (CORBA).

- specifies middleware functions which allow objects to communicate with one

another no matter where they are located, who has designed them, and in which language
they are implemented.

- OMG only provides a specification; there are several products which, to a certain
extent, implement the OMG specification.

Key concepts:
CORBA specifies the middleware services used by application objects.

An object can be a client, a server or both.

Object interaction is through requests: the information associated with a request is

1. an operation to be performed
2. a target object
3. zero or more parameters.

CORBA supports static as well as dynamic binding; dynamic binding between objects uses
run-time identification of objects and parameters.

The interface represents the contract between client and server; an IDL has been defined
for CORBA; proxies and skeletons (client and server stubs) are generated as result of IDL
compilation.

CORBA objects do not know the underlying implementation details; an object adapter maps
the generic model to a specific implementation.

Wilbert P. Umadhay P a g e 7 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

Interface Repository
-Provides a representation of interfaces for all server objects in the system. It corresponds
to the server objects’ IDL specification.
-Clients can access the repository to learn about server objects, the types of operations
which can be invoked and the corresponding parameters. This is used for dynamic
invocation of objects.

Wilbert P. Umadhay P a g e 8 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

Wilbert P. Umadhay P a g e 9 | 12
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

Implementation Repository
Implementation details for the objects implementing each interface are stored in the
implementation repository:
- the main information is a mapping from the server object’s name to the file name
which implements the respective service;
- the implementation repository is used by the object adapter to solve an incoming
call and activate the right method (via a skeleton).

The Object Request Broker (ORB)

The ORB, through its interfaces, provides mechanisms by which objects transparently
interact with each other.
-Issuing of a request can be dynamic or static; it is performed through the proxies (client
stubs) or the dynamic invocation interface.
-Invocation of a specific server method is performed by the server skeleton which gets the
request forwarded from the object adapter.
-The ORB interface can be accessed directly by application objects for services like directory,
naming, manipulation of object references.

Wilbert P. Umadhay P a g e 10
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

| 11

Static and Dynamic Invocation

CORBA allows both static and dynamic invocation of objects. The choice is made depending
on how much information, concerning the server object, is available at compile time.

Static Invocation
-Static invocation is based on compile time knowledge of the server’s interface specification.
This specification is formulated in IDL and is compiled into a proxy (client stub),
corresponding to the programming language in which the client is encoded.
-For the client, an object invocation is like a local invocation to a proxy method. The
invocation is then automatically forwarded to the object implementation through the ORB,
the object adapter and the skeleton.
-Static invocation is efficient at run time, because of the relatively low overhead.

Dynamic Invocation
-Dynamic invocation allows a client to invoke requests on an object without having
compiletime knowledge of the object’s interface.
-The object and its interface (methods, parameters, types) are detected at run-time; The
dynamic invocation interface allows to inspect the interface repository and dynamically
construct invocations corresponding to the server’s interface specification.
-Once the request has been constructed and arguments placed, its invocation has the same
effect as a static invocation.
-The execution overhead of a dynamic invocation is huge.
-From the server’s point of view, static and dynamic invocation are identical; the server does
not know how it has been invoked. The server invocation is always issued through its
skeleton, generated at compile time from the IDL specification.

Reference: George Coulouris, Jean Dollimore, Tim Kindberg, Gordon Blair: "Distributed
Systems - Concepts and Design", Addison Wesley Publ. Comp., 5th edition, 2011.

Wilbert P. Umadhay P a g e 11
UA –Main Campus-BS Information Technology NAS 5: Distributed Systems

| 11

Wilbert P. Umadhay P a g e 12