Communication in Java

The standard Java API provides a simplified interface to Internet sockets and RMI, an object-oriented Java version of Remote Procedure Call (RPC).

The Java socket interface hides much of the ugly detail involved in socket-programming at the traditional C/Unix level. The java.net interfaces provides less flexibility than using the system calls directly. On the other hand, Java's built-in support for threads adds some flexibility in scheduling communications that is missing from raw C.

We will give an example of socket programming in Section 2.2.1, but traditionally this has not been a popular paradigm in the parallel processing world. Scientific programmers have expected to program inter-process communication at a higher level, if at all. More successful schemes include

• Message-passing through language-level support [#!OCCAM!#,#!FortranM!#] or higher-level library interfaces [#!MPIFORUM!#].

• Data parallelism, which we take to mean the style of programming in which parallelism is achieved through operations on distributed arrays, with synchronization typically limited to bulk synchronization occurring naturally through collective array operations.

• Communication through shared memory or shared objects, involving some more or less intricate mechanism for inter-process synchronization.

As observed in the previous section, communication through true shared memory is already implicit in the Java thread model. Communication through remote objects (i.e RMI) is undoubtedly a natural and important paradigm in Java, especially for access to remote services. However, it suffers from a significant startup time and marshaling/unmarshaling of data is more costly than in the socket method.

An orthogonal issue is whether the high-level libraries used to implement these paradigms (presuming class-library implementations) should be written in Java on top of the standard API, or whether they should be implemented as direct interfaces to native code.