IDL, middleware and RMI approach

Role of IDL

An Interface Definition Language (IDL) is a language-neutral notation that specifies the operations (names, parameter and return types, exceptions) that a remote object or server offers, without implementation. An IDL compiler generates the client stub/proxy and server skeleton in the chosen programming language (CORBA IDL, Sun XDR/rpcgen, Java remote interface).

• Gives a language independent contract between client and server.
• Lets stubs and skeletons be generated automatically.
• Hides heterogeneity: different languages and platforms use the same interface.
• Allows interface checking, versioning and publishing in an interface repository.

Role of middleware

Middleware is a software layer between the application and the operating system/network of each node that hides heterogeneity and gives a uniform programming model (RPC, RMI, message queues, ORB, transactions). Examples: CORBA, Java RMI, DCOM, web services.

Its role:

• hides differences in hardware, OS, network and languages (heterogeneity), via IDL and standard data formats;
• provides distribution transparency (location, access, replication, failure);
• gives common services: naming, security, transactions, events, persistence;
• makes application development easy (programmers write application logic, not network code) and promotes openness and interoperability.

RMI approach in distributed object based systems

Remote Method Invocation (RMI) is the object-oriented extension of RPC. An object in one process invokes a method of an object in another process (possibly on another host) through a remote object reference. In Java, RMI is built into the language; CORBA does the same for many languages.

Architecture

 Client                         Server
 +-------------+                +-------------+
 | Client obj  |                | Remote obj  |
 | Proxy (stub)|                | Skeleton    |
 | Remote ref  |<-- network --->| Dispatcher  |
 | module      |                | Remote ref  |
 | Comm module |                | Comm module |
 +-------------+                +-------------+
        ^        Remote reference module: translates local <-> remote refs
        +--- Object registry / naming service: look up by name

• Proxy (stub): local representative of the remote object; marshals arguments and sends the request.
• Skeleton / dispatcher: unmarshals the request, selects the method and calls the object, then marshals the reply.
• Remote reference module: converts between local and remote object references.
• Communication module: carries request-reply messages with a chosen invocation semantics.
• Registry / binder: the client finds the remote object by name.

Approach: the application is a set of objects on different machines. A server creates a remote object and registers it in the registry. The client looks it up, receives a proxy, and invokes methods as if the object were local. The proxy and skeleton marshal, send and dispatch the calls, so that the remote call appears as a local one (location and access transparency). Parameters of remote type are passed by reference, others by value (serialisation). Failures are reported as exceptions, and unused remote objects are collected by distributed garbage collection.