RMI - JRMP vs IIOP

Question

I know that JRMP opens a new socket for every invocation request. Also that IIOP can share a single opened socket for multiple requests.

As stated by Wikipedia:

Usage of the term RMI may denote solely the programming interface or may signify both the API and JRMP, whereas the term RMI-IIOP (read: RMI over IIOP) denotes the RMI interface delegating most of the functionality to the supporting CORBA implementation.

One of the questions in my paper where I had to say whether the statement was true/false said:

RMI Servers share a single socket for multiple invocation requests.

At this point,there was ambiguity whether the question was probed considering it was a JRMP or an IIOP server. Is it safe for me to assume that if the questions states only RMI , then in that case it would imply it was a JRMP server and not an IIOP server?

I hope I've made myself clear.

Answer 1

I know that JRMP opens a new socket for every invocation request.

No it doesn't. The RMI client uses connection pooling.

As stated by Wikipedia:

Usage of the term RMI may denote solely the programming interface or may signify both the API and JRMP, whereas the term RMI-IIOP (read: RMI over IIOP) denotes the RMI interface delegating most of the functionality to the supporting CORBA implementation.

I consider that statement misleading and I've corrected it. The new wording says that the term 'RMI' could refer to the API or any implementation, including JRMP, IIOP, JERI, JBoss Remoting, ..., whereas 'RMI-IIOP' specifically refers to RMI over IIOP.

RMI Servers share a single socket for multiple invocation requests.

The statement is ambiguous, misleading, and implementation-dependent.

Is it safe for me to assume that if the questions states only RMI , then in that case it would imply it was a JRMP server and not an IIOP server?

No. But in this case it doesn't make any difference.

Answer 2

No, RMI can share sockets or create them as needed depending on the RMI client implementation. Such a sweeping statement wouldn't be true.