CORBA

Distributed Object Models — CORBA

1. What is CORBA?

CORBA (Common Object Request Broker Architecture) is the OMG's (Object Management Group) vendor-neutral standard for distributed objects — it lets a client call methods on an object living in another process, another machine, another language, another OS, transparently over the network.

2. Architecture (OMG Reference Model)

  CLIENT                         SERVER (object implementation)
 +--------+  IDL stub   +--------+  ORB  +--------+  IDL skeleton +----------+
 | Client | ----------> | ORB    | <---->| ORB    | ------------> | Object   |
 | program|             | (core) |  GIOP | (core) |               | Impl.    |
 +--------+             +--------+ IIOP  +--------+               +----------+
     |   Object Request Broker (ORB) — the middleware "bus"             |
     |   ORB services: naming, transactions, security, events (CORBAservices/CORBAfacilities)

ORB (Object Request Broker) — the core: locates the target object, marshals parameters, activates the server object, delivers the request, returns results/exceptions.

GIOP / IIOP — General Inter-ORB Protocol over TCP/IP = the wire protocol that makes different vendors' ORBs interoperate.

3. IDL — Interface Definition Language

Language-neutral contract compiled to stubs (client) and skeletons (server):

interface BankAccount {
  readonly attribute string owner;
  void deposit(in double amount);
  void withdraw(in double amount) raises (InsufficientFunds);
  double balance();
};

in / out / inout parameter modes, raises for exceptions; mappings exist for Java, C++, Python, Ada, COBOL, etc.

4. How a Call Flows

1. Client obtains an object reference (from the Naming Service — like a phone book of objects, or the Trading Service).
2. Client invokes a method through the IDL stub.
3. Stub marshals parameters into a GIOP/IIOP message → ORB → network.
4. Server-side ORB demarshals, calls the skeleton, which dispatches to the servant (implementation class).
5. Result/exception travels back the same way.

5. CORBAservices (key ones)

Naming Service, Event Service, Transaction Service (OTS), Security Service, Persistence, Life Cycle, Concurrency, Query, Properties, Time — a standard set of facilities every ORB vendor must/can provide.

6. Advantages and Limitations

Advantages

• True language and platform independence (a Java client can call a C++ server object).
• Mature, rich standard: naming, transactions, security, events out of the box; vendor-neutral, many ORBs.
• Strong typing via IDL; supports inheritance of interfaces; scalable to huge enterprise systems.

Limitations

• Complex to learn and deploy; heavyweight deployment (IDL compilation, ORB configuration).
• Binary proprietary-ish marshalling; debugging across ORBs is hard; firewalls block IIOP (port issues).
• Development momentum moved to web services (SOAP/REST) — CORBA is now mostly legacy.

7. Exam Points

• Explain the CORBA architecture with a diagram (ORB, stub, skeleton, GIOP/IIOP) — 10 marks (very frequent).
• Explain IDL with an example and how stubs/skeletons are generated — 5-7 marks.
• Role of the Naming Service — 3-5 marks.
• Compare CORBA with DCOM/RMI — 5 marks.