next up previous contents
Next: Applications and Performance Up: Implementations Previous: Implementation issues   Contents


Jini Implementation

Current distributed implementations of our mpjdev rely on the availability of a platform-specific native underlying communication interfaces, like MPI and LAPI, for the target computer (although we have the pure Java multithreaded implementation, this implementation is not useful for distributed programming). While this is a reasonable basis in many cases, the approach has some disadvantages. For one thing the two-stage installation procedure--get and build a native underlying communication interface then install and match Java wrappers--can be tedious and discouraging to potential users. The situation has improved, and mpjdev now runs with several combinations of JVM and MPI implementation, but portability is still a problem.

The authors of [9] have outlined a design for a pure-Java reference implementation for MPJ (see section 2.1.2). Design goals were that the system should be as easy to install on distributed systems as one can reasonably make it, and that it be sufficiently robust to be usable in an Internet environment. This proposed design can be naturally adapted to the mpjdev library. A system like this may be an important component in a future HPJava system.

The paper referenced above suggests that Jini may be a natural foundation for meeting the requirements. Jini is Sun's Java architecture for making services available over a network. It is built on top of the Java Remote Method Invocation (RMI) mechanism. The main additional features are a set of protocols and basic services for ``spontaneous'' discovery of new services, and a framework for detecting and handling partial failures in the distributed environment.

A Jini lookup service is typically discovered through multicast on a well-known port. The discovered registry is a unified first point of contact for all kinds of device, service, and client on the network. This model of discovery and lookup is somewhat distinct from the more global concept of discovery in, say, the CORBA trading services, HP's e-speak [32], or JXTA. The Jini version is a lightweight protocol, especially suitable for initial binding of clients and services within multicast range.

The ideas of Jini run deeper than the lookup services. Jini completes a vision of distributed programming started by RMI. In this vision partial failure is a defining characteristic, distinguishing distributed programming from the textbook discipline of concurrent programming [53]. So in Jini remote objects and RMI replace ordinary Java objects and methods; garbage collection for recovery of memory is replaced by a leasing model for recovery of distributed resources; the events of, say, AWT or JavaBeans are replaced by the distributed events of Jini. Finally, the synchronized methods of Java are mirrored in the nested transactions of the Jini model. Concurrent programming exactly identical to scalable parallel programming, but we need analogous sets of abstractions for the parallel case.

The installation script can start a daemon on the local machine by registering a persistent activatable object with the rmid daemon. The mpjdev daemons automatically advertise their presence through the Jini lookup services. The Jini paradigms of leasing and distributed events are used to detect failures and reclaim resources in the event of failure. These observations lead us to believe that a pure Java distributed reference implementation of mpjdev should probably use Jini technology [7,24] to facilitate location of remote mpjdev daemons and to provide a framework for the required fault-tolerance.

Figure 5.17: Layers of a proposed mpjdev reference implementation
\begin{figure}\centerline{\psfig{figure=Figs/tower.eps,height=3in}}\end{figure}

Figure 5.18: Independent clients may find mpjdevService daemons through the Jini lookup service. Each daemon may spawn several slaves.
\begin{figure}\centerline{\psfig{figure=Figs/MPJ-Jini.eps,height=3in}}\end{figure}

A possible architecture is sketched in Figure 5.17. The base layer--process creation and monitoring--incorporates initial negotiation with the mpjdev daemon, and low-level services provided by this daemon, including clean termination and routing of output streams (Figure 5.18).

One emphasis for the future work will be on researching links between parallel message-passing programming and Jini-like systems. Moreover we will also investigate newer ideas coming from projects like JXTA.


next up previous contents
Next: Applications and Performance Up: Implementations Previous: Implementation issues   Contents
Bryan Carpenter 2004-06-09