Skip to main content

Object adapter and CORBA invocation

Short answer

An Object Adapter (POA) sits between the ORB and servant, hiding the ORB, creating references and dispatching requests. CORBA offers static invocation via IDL-generated stubs/skeletons (fast, compile-time known) and dynamic invocation (DII/DSI) that discovers operations at runtime. Modes: synchronous (block until reply), one-way (no reply) and deferred synchronous (poll later, DII only).

Define Object Adapter. Explain the invocation methods in CORBA.

Object Adapter

An Object Adapter is the CORBA component between the ORB core and the object implementation (servant). It hides the ORB from the implementation by creating object references, registering and activating objects on demand, and dispatching each incoming request to the right servant through its skeleton. The standard form is the Portable Object Adapter (POA); the older one is the Basic Object Adapter (BOA).

Invocation methods in CORBA

1. Static invocation The IDL compiler generates a client stub and server skeleton. The client calls the stub as a local method; the stub marshals the arguments, the ORB delivers the request (using GIOP/IIOP) and the skeleton calls the servant. It is type-safe and fast, but the interface must be known at compile time.

2. Dynamic invocation (DII) The client discovers an operation at run time from the Interface Repository, builds a Request object with operation name and parameters, and sends it through the Dynamic Invocation Interface. The server can accept it through the Dynamic Skeleton Interface (DSI). It is flexible but slower.

Calling modes (both methods):

  • Synchronous: client blocks until the reply arrives.
  • One-way: no reply, best effort.
  • Deferred synchronous (DII only): client sends, continues work, and later polls or gets the reply.
 Client -> stub/DII -> ORB -> Object Adapter -> skeleton/DSI -> Servant

✓ Answer checked by Claude Opus 5.5 (high effort)

Related questions

All Distributed System chapter 4 questions →