Jini Exposed: Can Jini provide an Infrastructure for Parallel Applications?

1. Jini Exposed: Can Jini provide an Infrastructure for Parallel Applications? Mark Baker University of Portsmouth, UK Mark.Baker@Computer.org http://www.dcs.port.ac.uk/~mab/Talks/ Mark.Baker@Computer.Org

2. “But what ... is it good for?” – Engineer at the Advanced Computing Systems Division of IBM, 1968, commenting on the microchip. Mark.baker@Computer.Org

3. Contents • Motivation – an infrastructure for a Java message-passing system. • Jini – a brief overview. • MPJ: required infrastructure. • Jini exposed – how Jini can potentially fulfill our needs. • Summary and future work. Mark.baker@Computer.Org

4. Background – HP Java and Jini • The Message-Passing WG of the Java Grande Forum was formed in late 1998 as a response to the appearance of several prototype Java bindings for MPI-like libraries. • An initial draft for a common API specification was distributed at Supercomputing '98. • The present API is now called MPJ. Mark.baker@Computer.Org

5. Background • No complete implementation of the draft specification. • mpiJava, is moving towards the “standard” - version 1.3 will implement the new API. • mpiJava wrappers rely on the availability of platform-dependent native MPI implementation for the target computer. Mark.baker@Computer.Org

6. MPIprog.java Import mpi.*; JNI C Interface Native Library (MPI) mpiJava - Software Layers Mark.baker@Computer.Org

7. Problems with mpiJava • Wrapper approach has some disadvantages. • 2-stage installation: • Get/build native MPI then install/match the Java wrappers. • Tedious/off-putting to new users. • Problems – conflicts between the JVM and the native MPI runtime behaviour. • mpiJava now runs on most combinations of JVM and MPI implementation. • Strategy simply conflicts with the ethos of Java – write-once-run-anywhere. Mark.baker@Computer.Org

8. MPJ – the Next Generation of Message Passing in Java • An MPJ reference implementation could be implemented as: • Java wrappers to a native MPI implementation; • Pure Java; • Principally in Java – native methods to optimize operations (like marshalling arrays of primitive elements) that are difficult to do efficiently in Java. • We are aiming at pure Java to provide an implementation of MPJ that is maximallyportable and that hopefully requires the minimum amount of support effort. Mark.baker@Computer.Org

9. Benefits of a pure Java implementation of MPJ • Highly portable – assumes only a Java development environment. • Performance may be moderate –need to use JNI inserts for marshalling arrays. • Network speed limited by Java sockets. • Good for education/evaluation. • Vendors provide wrappers to native MPI for ultimate performance? Mark.baker@Computer.Org

10. MPJ • We envisage that a user will download a jar-file of MPJ library classes onto machines that may host parallel jobs. • Parallel java codes are compiled on one host. • An mpjrun program invoked on that host transparently loads the user's class files into JVMs created on remote hosts and the parallel job starts. Mark.baker@Computer.Org

11. Design Criteria for the MPJ Environment • Need an infrastructure to support groups of distributed processes: • Resource discovery; • Communications (not discussed here); • Enabling and registering remote hosts; • Spawn processes on remote hosts; • Monitoring software and hardware on remote hosts; • Handling failure and fault tolerance; • ... Mark.baker@Computer.Org

12. High Level MPI Collective Operations Process Topologies Base Level MPI All pt-to-pt modes Groups Communicators Datatypes Isend, irecv, waitany, … Physical PIDs Contexts & Tags Byte vector data MPJ Device Level Java Socket and Thread API All-to-all TCP Connect Input Handler Threads Synchronised methods, wait, notify… MPJ Daemon Lookup, Leasing (Jini) Exec java MPJLoader Serializable objects Process Creation and Monitoring Layers of an MPJ Reference Implementation Mark.baker@Computer.Org

13. Jini Technologies Mark.baker@Computer.Org

14. Jini Architecture Mark.baker@Computer.Org

15. Lookup service • Repository of available services. • Stores each service as an extensible set of Java objects. • Service objects may be downloaded to clients as required. • May be federated with other lookup services. • Lookup service interface provides: • Registration, Access, Update, Search, Removal. Mark.baker@Computer.Org

16. Jini Lookup Mark.baker@Computer.Org

17. Leasing protocol in Jini • Protocol for managing resources using a renewable, duration-based model. • Contract between objects. • Resources can be shared or non-shared. • Provides a method of managing resources in an environment where failures can, and do, occur. Mark.baker@Computer.Org

18. Distributed events in Jini • Enables Java event model to work in a distributed network. • Register interest, receive notification. • Allows for use of event managers. • Can use numerous distributed delivery models: • Push, pull, filter... • Uses leasing protocol. Mark.baker@Computer.Org

19. Transaction model in Jini • Designed for distributed object coordination: light weight, object-oriented. • Supports: • Nested transactions; • Various levels of ACID properties (Atomicity, Consistency, Isolation, Durability). • Uses leasing protocol. • Implemented in Transaction Manager service – another Jini service (mahalo). Mark.baker@Computer.Org

20. Object Activation • The RMI Activation Daemon (rmid) allows us to register servers (objects). • The daemon starts servers on an as-needed basis. • The servers terminate themselves when they are idle. • This reduces the resources required since it only runs active objects. Mark.baker@Computer.Org

21. Activation Problems • Want to reduce the resources used on each MPJ-capable host by making the daemon inactive and then waking it when needed – like INET with the FTP daemon. • Activation needs: • RMID – wake up (activation) daemon; • norm – provide proxy leasing renewal; • HTTP Server – for client/RMID to access Daemon stubs. • So to reduce resources we de-activate the MPJ daemon and then run three other daemons… • Poor practice – resort to other a more practical solutions… Mark.baker@Computer.Org

22. Security in Jini • Security for Jini is based on the JDK 1.2 security model. • In Java a Security Manager is used to grant or deny access to resources. • The security manager makes use of a security policy. • This is typically given in a policy file, which is stored in some default location or specified at runtime. Mark.baker@Computer.Org

23. A probable Jini Infrastructure for MPJ Daemon MPJ Process mpjrun … Mark.baker@Computer.Org

24. MPJ – Implementation • The role of the MPJ daemons and their associated infrastructure is to provide an environment consisting of a group of processes with the user-code loaded and running in a reliable way. • The process group is reliable in the sense that no partial failures should be visible to higher levels of the MPJ implementation or the user code. Mark.baker@Computer.Org

25. Handling failures with Jini • We will use Jini leasing to provide fault tolerance. • If any slave dies, a client generates a Jini distributed event, MPIAbort – all slaves are notified and all processes killed. • Other failures (network, client chrash, death of controlling daemon, …) client leases on slaves expire in a fixed time, and processes are killed. • It is likely there will be a hierarchy of leases – consequently this area needs to be carefully designed. Mark.baker@Computer.Org

26. Security • A client is vulnerable it is downloads code that fulfils a request for a service, and then executes that code. • There are essentially no checks as to if the service is genuine; the service only needs to implement the requested interface, and perhaps satisfy conditions attributes - if the service passes these, then it can do anything on the client. • It is not necessary to actually call a method on the downloaded service object – the act of downloading it can do the damage as the object can override the deserialization method. Mark.baker@Computer.Org

27. Security • The JDK 1.2 security model sanctions a number of ways in which secure interaction may take place: • Grant permission for only certain activities, for example such as socket access at various levels on particular ports, or access to certain files for reading, writing or execution; • Grant access only to particular hosts, sub-domains or domains; • Require digital signatures to be attached to code. Mark.baker@Computer.Org

28. Describing A Service Using Attributes • Want to somehow let clients know recent MPJ node status. • Typical information may be: • Machine information – processor and memory utilisation, OS type, Jini services running, etc. • Daemon information – number of MPJ tasks it is already handling, JDK/Jini versions, etc. • Every node has an MPJ daemon that is registered with LUS (s). • We can use Jini attributes to describe a service. Mark.baker@Computer.Org

29. Describing A Service Using Attributes • A service creates and publishes in the Lookup service an object called a ServiceItem that contains information about the service. • The ServiceItem contains: • The proxy object for the service; • The service’s unique ID; • Attributes that may describe the service itself. Mark.baker@Computer.Org

30. Describing A Service Using Attributes • There are sets of standard attributes that both a client and server will understand: • It is possible for a service developer to produce a customised set of attributes also. AttributePurpose Address The geographical location of a service Comment A free form comment on the service Location The location of a service within an organisation Name A human readable service name ServiceInfo Information about a services manufacturer model, serial number, etc ServiceType A human readable description of the service Status Information about the current operating state of a service. Mark.baker@Computer.Org

31. Describing A Service Using Attributes import net.jini.entry.AbstractEntry; import net.jini.lookup.entry.ServiceControlled; public class FreeMemory extends AbstractEntry implements ServiceControlled { public Integer maxMemory; public Integer BeingUsed; public Integer freeSpace; public FreeMemory() { maxMemory = new Integer(0); BeingUsed = new Integer(0); freeSpace = new Integer(0); } public FreeMemory(int max, int used) { maxMemory = new Integer(max); BeingUsed = new Integer (used); freeSpace = new Integer(max - used); } } Figure 1. Example Custom Attribute Mark.baker@Computer.Org

32. Describing A Service Using Attributes • It appears to be two ways of providing dynamic information about a service (such as the MPJ daemon): • Directly, via the lookup service (s). • Indirectly, via a broker which pulls status from individual daemons, which in turn is queried by clients that require the services. Mark.baker@Computer.Org

33. Describing A Service Using Attributes • Current view is that we should use the direct method: • The MPJ daemons can be instructed to push their status out a frequent intervals to the LUS; • Good Points: • Minimise the additional infrastructure that needs to be design, developed, implemented and tested; • Appears to be using the LUS the way that it was designed. • Bad Points: • Unsure how much pushing status will be impact performance of the MPJ Infrastructure. • This model will not “fit in” with an activatable MPJ daemon. Mark.baker@Computer.Org

34. Scheduling • You can create a status flag for each service and then filter on the flag during discovery. • Or create a scheduling service (a broker) and then MPJ jobs are queued with the scheduling service, which then handles allocating jobs onto the available MPJ hosts. • The former is a simple solution as many users will probably prefer to choose their hosts with geographic location even if it means waiting rather than finding the next available host. Mark.baker@Computer.Org

35. Checkpointing • Checkpointing and restarting of interrupted jobs may be quite useful. • Checkpointing would not happen without explicit invocation in the user-level code, or that restarting would happen automatically. • A serialized (marshalled) object can be saved to disk and restarted. Mark.baker@Computer.Org

36. MPJ - Implementation • Once a reliable cocoon of user processes has been created through negotiation with the daemons, we have to establish connectivity. • In the reference implementation this will be based on Java sockets. • Recently there has been interest in producing Java bindings to VIA - eventually this may provide a better platform on which to implement MPI, but for now sockets are the only realistic, portable option. Mark.baker@Computer.Org

37. Slave 1 Slave 2 Slave 3 Slave 4 Host Mpj Deamon Mpjrun myproggy –np 4 rmid http server Mark.baker@Computer.Org

38. Summary • It appears that Jini has the capability to provide the functionality that we require to support a robust distributed environment. • Some key Features: • Leases – Hierarchical levels of fault-tolerance; • LUS – Provide dynamic information for clients; • Events – Assist in percolating administrative information to rest of MPJ environment. • Transactions – Potential means of synchronising MPJ environment. Mark.baker@Computer.Org

39. MPJ – Future Work • On-going effort – UoP/FSU. • Infrastructure being developed in parallel with MPJ. • Currently working on components of MPJ infrastructure, e.g, looking at the ability of the LUS to support dynamic information! • Concerned about Jini Security – will be reviewed deeply! • Starting to also looking at the means of integrating Jini with Grid systems (Globus/Grid Forum). Mark.baker@Computer.Org

40. Mark.baker@Computer.Org