Q.5.

Explain CORBA Interface Definitions

Languages.
Ans… CORBA – Common Object Request Broker Architecture
 CORBA is a standard by OMG (Object Management Group) that
allows programs written in different languages and running on
different computers to work together over a network.
 It allows objects in a network to communicate with each
other as if they are located on the same machine, even if
they are not.

Architecture of CORBA (Reference Model)

1. ORB (Object Request Broker) – The Center/Heart

 Think of the ORB as a middleman or manager.
 It helps different programs (called objects) talk to each other.
 It doesn’t matter where the programs are or what language they’re written
in—ORB makes the communication happen smoothly.
 This is shown as a big horizontal arrow in the middle, sometimes called
the Object Bus.
2. Application Interface
 These are the actual user applications—the programs you create to do a
task (e.g., a shopping app or a banking app).
 These apps use the ORB to request services or data from other programs
or servers.
 It connects to the ORB to send and receive information.

3. Common Facilities
 These are pre-made, shared services that many apps can use.
 Example: Printing service, sending email, file handling, etc.
 Instead of writing these again and again, CORBA gives ready-made tools
here.
 These also connect to the ORB to share their functions.

4. Domain Interface
 These are services made for specific industries or domains.
 Example: A hospital system may need patient records or appointment
services. A bank may need a transaction or account check service.
 These are custom services that fit a certain field.

5. Object Interface
 This is the actual interface of the object (like a class with functions) that
defines what the object can do.
 It’s written in IDL (Interface Definition Language) so that any language
(Java, C++, Python) can understand and use it.
 The ORB uses this to find and call the right function on the right object.

🔄 How Everything Works Together:

 1. A user application (like a banking app) sends a request (e.g., check
balance).
2. The request goes to the ORB.
3. ORB checks the Object Interface and finds where the function is located.
4. If it’s in the Common Facilities, ORB calls it.
5. If it’s in Domain Interface, ORB accesses it.
6. ORB delivers the result back to the application.

🌐 What is CORBA IDL?

CORBA IDL (Interface Definition Language) is a special language used in CORBA
to define the interfaces of objects.
These interfaces describe:
 What methods (functions) an object provides
 What parameters these methods take
 What values they return

IDL acts as a bridge between different programming languages like Java,

C++, Python, etc., so they can all work together in a distributed system.

✅ Why is IDL Needed?

In distributed systems:
 Different parts of the system may be written in different languages.
 They may run on different operating systems.
 CORBA needs a common way to describe how objects should behave.
➡️ So, IDL provides a standard way to define the interface, and then tools
convert it into a language-specific code (Java, C++, etc.).

📦 Features of CORBA IDL

1. Language-Independent
 o You write interfaces once in IDL.
o CORBA tools then generate language-specific "stubs" and
"skeletons".
2. Supports Object-Oriented Concepts
o Like interfaces, inheritance, modules, etc.
3. Strict Syntax
o Similar to C++ or Java, but much simpler and only for defining
interfaces—not for logic.
4. Maps to Many Languages
o CORBA compilers generate code for Java, C++, Python, etc., from a
single IDL file.

Components of IDL
1. Module
 A container used to group related interfaces together.
 Similar to packages in Java or namespaces in C++.
 Helps avoid name conflicts.
2. Interface
 Defines the object and the services (methods) it offers.
 It’s like a class that only has function declarations, not the logic.
3. Operations (Methods)
 These are the functions or services that the object provides.
 Defined inside the interface.
 Can have input (in), output (out), or inout parameters.
4. Parameters (in, out, inout)
 Define how data flows through the method.
5. Data Types
IDL supports both:
 Basic types: short, long, float, double, char, boolean, string
 Complex types (custom-made):
o struct
o enum
o typedef
o sequence
6. Exceptions
 You can define custom error types.
 Used for error handling
7. Attributes
 Like variables or properties.
 You can define them with get/set automatically.

Basic Structure of an IDL File

interface BankAccount {

float getBalance();

void deposit(in float amount);

void withdraw(in float amount);

};

Explanation:

 interface BankAccount: Defines an object called

BankAccount.

 getBalance(): Returns a float (balance).

  deposit(in float amount): Takes a float as input to deposit
money.

 withdraw(in float amount): Takes a float to withdraw

money.

 in keyword: Means data is coming into the function (input

parameter).

IDL Compilation
 After writing the interface in IDL, it is compiled using an
IDL compiler.

 This compiler generates:

o Client-side stub – lets the client call the remote

method like a normal function.

o Server-side skeleton – receives the call and forwards it

to the actual server method.

Ques…. Consider two CORBA systems, each

with their own naming service. Outline
how the integration may be performed

Ans….
The CORBA Naming Service helps different programs in a distributed system
find each other by name, just like how we use domain names (like google.com)
instead of IP addresses.
The Naming Service acts like a telephone directory or contact list:
 Each service or object has a name.
 The Naming Service maps that name to the actual location of the object.

1. bind (by Server)

The server registers a service with a name in the Naming Service, like saving a
contact in a phonebook.
2. resolve (by Client)
The client asks the Naming Service for the service by name, like looking up a
contact to get their number.
3. invoke (by Client)
Once the client gets the service reference, it starts using the service, like calling
the contact.

How to Integrate Two CORBA Naming

Services (Simple Steps)
✅ 1. Share Object References (IORs)
 Each object in CORBA has a unique reference called an IOR.
 We can export an object reference from one system and use it in the other
system.
 This lets clients from System A access objects in System B.

✅ 2. Use a Bridge Object

 Create a bridge (helper) object that connects both naming services.
 This object can forward requests from one system to another.
 It acts like a middleman.

✅ 3. Re-register Remote Objects

 Take an object from System A and register it in System B’s naming service.
 Now, clients in System B can use it like it’s a local object.

✅ 4. Federated Naming Context

 CORBA allows naming services to be connected in a hierarchy.
 One naming context can contain another remote context.
 This makes it look like one big naming system.

✅ 5. Access Remote Naming Context

 A client in System A can directly connect to System B’s naming context.
 It can then look up and use objects from that system.

Q.1. Explain the need of Distributed system and

also explain its characteristics with example.
Characteristics of Distributed Systems

1. Resource Sharing
 Users can access hardware, software, or data from anywhere in the
system.
 You can use files, printers, or databases from other computers in the
network.
 No need to have everything on your own system.
 It saves cost and improves efficiency.

2. Openness
 The system supports extensions and improvements, and its components
can be openly developed and shared.
 Anyone can add or upgrade parts of the system easily.

3. Concurrency
 Multiple users can perform tasks at the same time, even from different
locations, each with their own system.
 Improves performance and productivity

4. Scalability
 The system can grow by adding more machines or users without losing
performance.
 Still works fast and smoothly even at a large scale.

5. Fault Tolerance
 Even if hardware or software fails, the system keeps running properly with
minimal impact.
 The system can recover from errors automatically.
 It ensures the system is always reliable.
6. Transparency
 The system hides complexity from users, making it appear as a single,
unified system.
 All resources appear as if they’re from one system.
 Makes the system easier and safer to use.

NEED OF DISTRIBUTED SYSTEM

1. Resource Sharing
 Allows multiple users to share files, printers, software, or data over a
network.
 Useful in organizations where resources are spread across departments.
 Reduces hardware and software duplication.

2. Speed and Performance

 Tasks can be divided across multiple computers, making processing faster.
 Parallel processing helps complete large tasks more quickly.
 Improves response time for users (low latency).

3. Scalability
 Easy to add more machines or users without redesigning the entire
system.
 Suitable for growing businesses or apps with increasing users.
 Can scale horizontally (add more nodes) or vertically (upgrade nodes).

4. Fault Tolerance
 Even if one part fails, the rest of the system keeps working smoothly.
 Backup systems can take over automatically.
 Minimizes downtime and ensures high availability.
5. Cost-Effective
 Uses low-cost computers connected together instead of buying one
powerful machine.
 Saves money on hardware and energy.

 Maintenance and upgrades are also cheaper.

6. Location Independence
 Users can access resources and services from anywhere in the system.
 Helpful in systems like cloud computing and online banking.
 Supports remote work and global access.

7. Concurrent Access
 Multiple users can access the system at the same time without conflict.
 Ensures consistency when many users read/write data.
 Essential for collaborative tools like Google Docs.

Challenges of Using Distributed Systems

1. Consistency and Coherency
o It’s hard to make sure all systems have the same updated data.
o Example: When multiple users update the same file at the same
time.

2. Complexity
o Distributed systems are complicated to build and manage.
o Developers have to handle things like communication, failure, and
data splitting.
 3. Security
o More nodes mean more chances for attacks like hacking or data
leaks.
o Needs strong encryption, passwords, and access controls.

4. Synchronization
o Keeping actions and data in sync across different computers is tough.
o Example: Making sure two users don’t book the same seat in a ticket
system.

5. Resource Management
o Hard to efficiently manage CPU, memory, or servers across the
network.
o Needs good load balancing and scheduling.

Ques.. Explain client-server communication

model on RPC
Ans..
 Remote Procedure Call (RPC) is a method used in distributed systems to
allow a program on one computer (called the client) to call and run a
function or procedure on another computer (called the server) as if it were
a local function.
 It is commonly used in client-server systems to communicate between
client programs and server services.

🛠️ How RPC Works – Step-by-Step Process:

1. Client Calls a Local Stub Function
 The client program calls a function (called a client stub) just like a normal
local function.
 But this stub doesn't contain the real logic — it acts as a placeholder.
2. Client Stub Marshalls (Packs) Parameters
 The stub collects and packs the input values (called marshalling) into a
message format that can be sent over the network.
 It converts parameters into a standard format that both client and server
can understand.
3. Send Message to Server
 The message is passed to the transport layer (like TCP/IP), which sends it
over the network to the remote server.
4. Server Receives the Message
 The server’s transport layer receives the message and sends it to the
server stub.
5. Server Stub Demarshalls (Unpacks) the Data
  The server stub unpacks the parameters (called demarshalling) from the
message.
 It then calls the actual server procedure (function) using these parameters.
6. Server Executes the Function
 The server runs the requested function and produces the result/output.
7. Server Stub Marshalls Return Data
 After the function runs, the result is sent back.
 The server stub packs the result into a message and sends it back via the
transport layer to the client.
8. Client Receives Result
 The client’s transport layer receives the result and sends it to the client
stub.
9. Client Stub Demarshalls and Returns Result
 The client stub unpacks the result and returns it to the original calling
code.

How to Make a Remote Procedure Call? Working of

RPC
✅ How to Make a Remote Procedure Call (RPC)?
1. A program (client) makes a function call as if it's calling a local procedure.
2. The system suspends the calling environment (it waits).
3. The function parameters are transferred across the network to the remote
machine (server).
4. The server receives the request and executes the procedure on its side.
5. Once the procedure is done, results are sent back to the client.
6. The client receives the result, and execution resumes like a normal
function return.

📂 Types of RPC:
🔁 1. Callback RPC
 Both client and server can act as each other.
 Server can call back a function in the client.
 Used in interactive or event-driven applications.
 Handles deadlocks that may occur during callbacks.
 Allows peer-to-peer interaction between processes.
📣 2. Broadcast RPC
 The client’s request is sent to all servers in the network.
 All servers that can handle the request respond.
 Reduces the need for the client to contact each server individually.
 Useful when the response can come from any server, not just one.
 Can reduce load on the network if used properly.
📦 3. Batch-mode RPC
 Multiple RPC requests are collected on the client side.
 They are sent together in one batch to the server.
 Reduces network overhead (fewer messages).