Chapter - 4

DISTRIBUTED HETEROGENEOUS
APPLICATION AND CORBA
4.1 Heterogeneity in Distributed System
4.2 Middleware
4.3 Objects in Distributed System
4.4 Interface Definition Language (IDL)
4.5 The CORBA Approach and Services
 4.1 Heterogeneity in Distributed
System
●
If someone says “heterogeneous distributed computing”, they mean two or more computers with
different hardware being used together to solve a problem.
●
Distributed system is made up of many different types of hardware and software that work
together to solve problems.
●
Some distributed system components may have different capabilities than others. Faster clock
cycles, more memory capacity, larger disk farms, printers and other peripherals and new
services could all be among them.
●
Distributed applications are typically heterogeneous.
– Different hardware: mainframes, workstations, personal computers, real time OS etc
– Different software: UNIX, windows, LINUX, MAC
– Unconventional device: Telephone switch, teller machines
– Diverse network: Ethernet, ATM
 What do you mean by
heterogeneous application?
●
A heterogeneous application refers to an application or system that is composed of
multiple different components or technologies that are diverse or dissimilar in nature. In
other words, it consists of various elements that are not uniform or homogeneous.
●
The heterogeneity in a heterogeneous application can manifest in several ways:
1. Programming Languages: The application may be developed using different
programming languages. For example, some components may be written in Java, while
others may be written in Python or C++. Each component may have its own set of libraries,
frameworks, and syntax.
2. Platforms and Operating Systems: The application may run on different platforms or
operating systems. For instance, some components may be deployed on Windows
servers, while others may run on Linux or macOS. This requires managing the differences
in system configurations and dependencies.
3. Communication Protocols: The application may involve communication between components
using different protocols or messaging systems. For example, one component may use HTTP for
communication, while another may use message queues or CORBA (Common Object Request
Broker Architecture) for inter-component communication.
4. Data Formats and Structures: The application may handle data in different formats or structures.
For instance, one component may use JSON for data exchange, while another may use XML or a
custom binary format. This necessitates data transformation and mapping between the different
formats.
5. Hardware and Infrastructure: The application may utilize diverse hardware or infrastructure
components. This could include servers with different specifications, databases from different
vendors, or cloud services from multiple providers. Managing and integrating these disparate
elements requires careful coordination.
Q. Why heterogeneity in Distributed
System?
●
Different hardware/software solutions are
considered to be optimal for different parts of
the system.
●
Different users have to interact and decide for
different hardware/software solutions/ vendors.
 what do you mean by distributed
heterogeneous application?
●
A distributed heterogeneous application refers to an application or system that is both
distributed and heterogeneous in nature. It combines the concepts of distribution and
heterogeneity, meaning that it consists of multiple components or subsystems that are
dispersed across different physical or logical environments, and these components exhibit
diversity or dissimilarity.
●
In a distributed heterogeneous application:
1. Distribution: The application's components are deployed across different nodes or machines
that are connected over a network. These nodes can be located in different geographic
locations, data centers, or cloud environments. The distributed nature allows for scalability,
fault tolerance, and load balancing.
2. Heterogeneity: The components of the application exhibit heterogeneity in terms of
programming languages, platforms, communication protocols, data formats, hardware, or
infrastructure. Each component may have its own characteristics and requirements based on
specific functionalities or system constraints.
●
Combining distribution and heterogeneity in an application introduces additional challenges and
complexities. Some key considerations include:
1. Interoperability: Since the components of a distributed heterogeneous application may use
different programming languages, communication protocols, or data formats, ensuring seamless
interoperability becomes crucial. Appropriate mechanisms, such as standardized APIs, data
transformation techniques, or middleware technologies, need to be employed to facilitate
communication and data exchange between the heterogeneous components.
2. Security and Authentication: With distributed components residing in different environments,
securing the communication and data becomes essential. Authentication, authorization, and
encryption mechanisms must be implemented to protect sensitive information and prevent
unauthorized access.
3. Scalability and Performance: The distributed nature of the application allows for scaling
individual components independently, which can help handle varying workloads. However,
managing the performance and ensuring efficient communication between the heterogeneous
components, considering factors like network latency and data serialization/deserialization, is
important for achieving optimal performance.
4. Fault Tolerance and Resilience: Distributed systems are susceptible to failures and network
disruptions. Therefore, building fault-tolerant mechanisms, such as redundancy, replication, and
distributed error handling, is essential to ensure the resilience of the heterogeneous application.
 4.2 Middleware
●
Middleware is a software layer situated between applications and
operating systems.
●
Middleware is used in DS where it simplifies software development by
doing the following:
– Hides the intricacies(very complicated or detailed) of distributed applications.
– Hides the heterogeneity of hardware, operating system and protocols.
– Provides uniform and high-level interfaces used to make inter operable, reusable
and portable applications.
– Provides a set of common services that minimizes duplication of efforts and
enhances collaboration between applications.
●
Middleware is a set of services that enable applications and end users to
interact with each other across heterogeneous distributed system.
●
Middleware software resides above the network and below the applications
software.
●
Middleware should make the network transparent to the applications and end
users.
●
Middleware should hide the details of computing hardware, OS, software
components, across networks.
●
Different kind of software qualifies, to certain extend as middleware: FTP,
CORBA, Web Browser.
 user application user

middleware middleware middleware

Network
 4.3 Objects in Distributed System
●
In a distributed system, various objects play important roles to enable communication, coordination, and
data sharing among different components. Here are some key objects commonly found in distributed
systems:
1. Nodes: Nodes represent individual computing entities within the distributed system. They can be
physical machines or virtual instances that are connected through a network. Each node typically has its
own processing power, memory, and storage capabilities.
2. Communication Channels: Communication channels provide the means for nodes to exchange
information and messages. These channels can be implemented using various networking technologies,
such as TCP/IP, message queues, publish-subscribe systems, or remote procedure calls (RPC).
3. Messages: Messages are packets of information that are sent between nodes in the distributed
system. They contain data or instructions to be processed. Messages can be used for various purposes,
including coordination, data transfer, or signaling.
4. Remote Objects: Remote objects, also known as distributed objects, are objects that exist on one
node but are accessible and usable by other nodes in the distributed system. Remote objects enable
interaction and communication between different parts of the system by providing remote method
invocation mechanisms.
5. Middleware: Middleware refers to the software layer that sits between the network and the
applications in a distributed system. It provides a set of services and abstractions to facilitate
communication, coordination, and resource management. Examples of middleware include
message brokers, distributed databases, transaction managers, and distributed file systems.

6. Distributed Data Structures: Distributed systems often require data structures that can be shared
and accessed by multiple nodes. Examples include distributed hash tables (DHTs), distributed
queues, distributed caches, and distributed logs. These data structures are designed to handle the
challenges of distributed environments, such as data replication, consistency, and fault tolerance.

7. Distributed File Systems: Distributed file systems allow nodes in a distributed system to access
and share files as if they were stored locally. Examples include the Hadoop Distributed File System
(HDFS) and the Google File System (GFS). Distributed file systems provide mechanisms for data
partitioning, replication, and distributed file access.

8. Coordination Objects: Coordination objects help in achieving coordination and synchronization

among nodes in a distributed system. Examples include distributed locks, semaphores, barriers,
and distributed coordination frameworks like Apache ZooKeeper. These objects ensure that multiple
nodes can coordinate their actions and avoid conflicts.
 4.4 Interface Definition
Language(IDL)
●
Interface Definition Language (IDL) is a language or specification used to define interfaces in a
platform-independent and language-independent manner.
●
It is commonly used in distributed systems, where different components written in different
programming languages need to communicate and interact with each other.
●
IDL provides a structured and standardized way to describe the interfaces, data types, and
operations that can be accessed by components across different programming languages and
platforms.
●
It acts as a contract or agreement between the communicating entities, ensuring that they
understand and adhere to a common set of rules for communication.
●
IDL is commonly used in middleware technologies such as CORBA (Common Object Request
Broker Architecture) and Microsoft's Component Object Model (COM) and Distributed Component
Object Model (DCOM). It allows for language independence, interoperability, and easy integration of
distributed components, making it an essential part of building distributed systems.
●
The key features and purposes of IDL include:
1. Interface Specification: IDL allows developers to specify the interfaces of software components
in a language-agnostic manner. It defines the operations, parameters, and return types of remote
procedure calls (RPCs) or method invocations that can be made on the component.
2. Data Types and Structures: IDL provides a way to define data types and structures used in the
interfaces. It includes primitive data types (e.g., integers, strings) as well as complex data
structures (e.g., arrays, records, enumerations).
3. Language Independence: IDL is designed to be independent of any specific programming
language. It provides a neutral and platform-agnostic representation of the interfaces, allowing
different components implemented in various languages to communicate with each other.
4. Code Generation: IDL compilers or code generators can take IDL specifications as input and
automatically generate the corresponding stubs and skeletons in different programming
languages. These generated components provide the necessary plumbing code to handle the
communication and data marshaling between the distributed components.
5. Interoperability: By using a common IDL, components written in different languages can
communicate and interact seamlessly. The IDL specification acts as a bridge between the various
components, ensuring that they understand each other's interfaces and can exchange data and
messages correctly.
 4.5 The CORBA approach and
services
What is CORBA?
●
CORBA is a platform which supports multiple programming language to
work together successfully.
●
It is a mechanism in software for normalizing the method call semantics
between application objects residing either in the same address space or
remote address space.
●
The ORB enables clients to invoke methods in a remote object.
●
It is a technology to connect to objects of heterogeneous types.
●
Types of objects in CORBA:there are two types of object in CORBA
– Service provider object
– Client object
 a. service provider object: object that includes functionalities
that can be used by other objects.
b. client object: object that requires services of other objects.
Q. Why CORBA?
●
Whenever software is developed the biggest problem is that
particular software is developed in different languages.
●
So it creates a problem of incompatibility, it means whenever
we connect the two system for any data transfer or say any
type communication between these two systems then these two
systems are found not to be compatible with each other which
each other which lead to robustness.
 How CORBA works?

Implementation
repository

Request server
client
Client Proxy
Proxy ORB ORB Object Servant
program for AA
For core core adaptor skeleton A

Reply

Interface
repository
●
Client sends request to the server.
●
Server receives a request from the client.
●
Server sends a reply to the client.
●
Client gets reply from the server.
This is how CORBA works
ORB Core:
-It carries out the request- reply protocol between client and servers.
- It provides operation that enables process to be start and stop.

Object Adapter(server):
- Bridges gap between the CORBA object and programming language interfaces of the slave
class.

Skeleton(Server):
- IDL compiler generates skeleton classes in the server’s language.

Client Proxies(Stub):
-Generated by IDL compiler in the client language.

Implementation repository:
- activates register servers in demand and locates servers that are currently running.

Interface repository:
-Provides information about register IDL interfaces to the client and server that requires it.
 CORBA services
●
CORBA services are pre-defined sets of functionality and capabilities that can be accessed and utilized
by CORBA-compliant applications.
●
These services provide common functionality that is required by many distributed applications, such as
naming and directory services, event services, security services, and transaction services.
●
Some commonly used CORBA services include:
1. Naming Service: This service provides a centralized directory for registering and locating objects in a
distributed system. It allows clients to find and access objects by their names, regardless of their
physical location.
2. Event Service: The event service enables asynchronous communication between objects by allowing
them to publish and subscribe to events. It provides a mechanism for objects to notify each other of
changes or occurrences without requiring explicit polling.
3. Transaction Service: This service ensures that a set of operations on distributed objects is performed
as an atomic unit, either all succeeding or all failing. It provides the ability to define and manage
transactions across multiple objects and resources, ensuring data integrity and consistency.
4. Security Service: The security service provides mechanisms for authenticating and
authorizing users, ensuring data confidentiality and integrity, and enforcing access control
policies in a distributed environment. It helps protect the CORBA infrastructure and the objects
it manages from unauthorized access and malicious activities.

5. Notification Service: This service enables the asynchronous delivery of notifications to

subscribed clients. It allows objects to send notifications about specific events or conditions,
and interested clients can receive these notifications and take appropriate actions.

6. Persistence Service: The persistence service provides mechanisms for storing and
retrieving object state persistently. It allows objects to be saved to a persistent storage
medium, such as a database, and later restored to their previous state.

These services, along with other features of the CORBA specification, provide a standardized
and interoperable way of building distributed systems and integrating software components
written in different languages and running on different platforms.
 CORBA Services and Description
●
CORBA, which stands for Common Object Request Broker Architecture, is a
middleware technology that enables communication and interaction between
distributed objects across different platforms and programming languages. It
provides a standardized approach for building distributed systems by defining a
set of interfaces and protocols.

●
In CORBA, services play a crucial role in facilitating various aspects of
distributed computing. Services in CORBA are pre-defined components that
provide specific functionalities and features to enhance the capabilities of
distributed applications. These services are built on top of the CORBA
infrastructure and can be accessed and utilized by CORBA-based applications.
Here are some commonly used CORBA services:
1. Naming Service: The Naming Service provides a centralized repository for
registering and looking up object references. It allows clients to locate objects
by their names instead of directly referencing their network addresses. The
Naming Service enables dynamic discovery and binding of objects in a
distributed environment.
2. Event Service: The Event Service enables the publication and subscription
of events among distributed objects. It allows objects to communicate
asynchronously by publishing events and subscribing to events of interest.
This service facilitates loose coupling and event-driven architectures in
CORBA applications.
3. Transaction Service: The Transaction Service provides a mechanism for
managing distributed transactions across multiple resources or objects. It
ensures atomicity, consistency, isolation, and durability (ACID properties) for
coordinated operations involving multiple participants. The Transaction
Service enables distributed systems to maintain data integrity in the presence
of failures or concurrent access.
4. Security Service: The Security Service offers authentication, authorization,
and encryption capabilities to secure CORBA-based applications. It provides
mechanisms for user authentication, access control, data confidentiality,
integrity, and non-repudiation. The Security Service helps protect sensitive
information and ensures secure communication between distributed objects.
5. Persistent Object Service: The Persistent Object Service allows objects to
be stored persistently in a distributed system. It provides mechanisms for
creating, storing, retrieving, and deleting persistent objects. This service
enables objects to survive system restarts and provides transparent access
to persistent data.
6. Notification Service: The Notification Service enables objects to send
notifications or alerts to interested subscribers. It supports the asynchronous
delivery of notifications, allowing decoupled communication between objects.
The Notification Service is useful in scenarios where real-time updates or
event-driven communication is required.
 Difference between CORBA and Difference between CORBA and
IDL
1. Purpose:
●
CORBA: CORBA is a middleware technology that provides a framework and infrastructure for
building distributed applications. It defines the standards, protocols, and runtime environment for
enabling communication and interoperability between distributed objects.
●
IDL: IDL, on the other hand, is a language-independent specification language used to describe
the interfaces of software components in a distributed system. It provides a standardized way to
define the operations, parameters, and data structures used for communication between
components.
2. Scope:
●
CORBA: CORBA encompasses the entire architecture and infrastructure for building distributed
systems. It includes specifications for the Object Request Broker (ORB), object adapters, naming
services, and other components that facilitate communication and interoperability.
●
IDL: IDL, on the other hand, focuses solely on defining the interfaces and data structures used for
communication between components. It is a language-agnostic way to describe the contracts or
agreements between components.
3. Language Independence:

-CORBA: While CORBA is designed to be language-independent at the architectural level, it

provides language bindings or mappings that allow components written in different
programming languages (such as Java, C++, Python) to interoperate within the CORBA
framework.
-IDL: IDL is explicitly language-independent. It is designed to provide a neutral and platform-
agnostic representation of interfaces and data structures, allowing components implemented
in various programming languages to communicate with each other seamlessly.

4. Usage:

-CORBA: CORBA is used as a middleware technology for building distributed systems in

various domains, such as telecommunications, finance, healthcare, and more. It provides the
infrastructure and runtime environment for managing distributed objects and enabling
communication between them.
-IDL: IDL is used as a specification language for describing interfaces in distributed systems.
It allows developers to define the operations, parameters, and data structures used for
communication between components, regardless of the programming languages being used.
In summary, CORBA is a middleware technology that provides a comprehensive infrastructure
for building distributed systems, while IDL is a language-independent specification language
used to define the interfaces and data structures for communication between components.
IDL is often used within the CORBA framework to describe the contracts between CORBA
objects.
 Components of CORBA
●
environment
CORBA (Common Object Request Broker Architecture) is a middleware specification that enables communication and
interaction between software components distributed across different platforms and written in different programming
languages. The CORBA environment consists of several key components that work together to facilitate this
communication. Some of the main components of the CORBA environment include:
1. Object Request Broker (ORB): The ORB is the central component of the CORBA environment. It acts as a
middleware layer between distributed objects, handling the communication between clients and servers. The ORB is
responsible for locating objects, marshaling and unmarshaling parameters, invoking remote methods, and managing
the exchange of messages.
2. Interface Definition Language (IDL): IDL is a language-neutral specification used in CORBA to define the interfaces
of objects. It provides a standardized way to describe the operations, attributes, and data types that objects expose.
IDL serves as a bridge between different programming languages, allowing objects written in different languages to
interact seamlessly.
3. Object Adapter: The Object Adapter provides a bridge between the CORBA environment and the application
objects. It is responsible for receiving requests from the ORB, locating the appropriate object implementation, and
invoking the requested operations on the objects. The Object Adapter also manages the lifecycle of objects, including
object activation and deactivation.
 4. Object Services: CORBA provides a set of standard Object Services that offer additional
functionality and features to distributed objects. These services include Naming Service for object
name resolution, Trading Service for object registration and discovery, Event Service for asynchronous
event notifications, and Transaction Service for coordinating distributed transactions.

5. Interface Repository: The Interface Repository is a central repository that stores the IDL definitions
of objects in a CORBA environment. It allows clients and servers to dynamically discover and access
object interfaces at runtime. The Interface Repository provides a way to query and retrieve interface
information, including the operations, attributes, and types supported by objects.

6CORBA Services: In addition to Object Services, CORBA also defines a set of common services that
address various aspects of distributed computing. These services include Security Service for
authentication and access control, Concurrency Control Service for managing concurrent access to
objects, Persistence Service for object persistence, and Query Service for querying objects based on
their attributes.

●
These components work together to provide a robust and flexible environment for distributed
computing using CORBA. They enable interoperability between heterogeneous systems and facilitate
the development of distributed applications by providing standard interfaces and services.