Importance of IDL in RMI; static RMI

Importance of IDL in RMI

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).

• It is the contract between client and server. Client programmers only need the interface.
• The IDL compiler generates stubs and skeletons, so no network code is written by hand.
• It gives language and platform independence (in CORBA, a C++ client calls a Java object).
• It supports type checking of parameters and exceptions at compile time.
• It makes marshalling to a common format possible, and makes interfaces publishable for openness.
• In Java RMI the remote interface plays the same role.

Operation of static RMI

In static (compile time) RMI the stubs and skeletons are generated at compile time from the interface (by the IDL compiler or rmic) and linked into the client and server. The client knows the interface in advance. (Dynamic invocation, DII, builds requests at run time instead.)

 1. Define IDL/remote interface
 2. Compile -> stub (client), skeleton (server)
 3. Write & start server: create object, register
 4. Client: look up -> proxy -> call method

1. The server creates the remote object and binds it to a name in the registry/naming service.
2. The client looks up the name and receives a stub (proxy).
3. The client calls a method on the stub. The stub marshals the arguments and sends them.
4. The server's skeleton receives the request, unmarshals, and calls the method on the object.
5. The result is marshalled and returned, and the stub gives it to the client (or throws an exception).

Advantages: fast and type-safe. Disadvantage: the interface must be known at compile time and a change needs recompilation.