Parallel Computing using JavaSpaces

-Presented by Shilpi Basak

Advisor: Prof: Dick Steflik

Traditionally, operating systems have been designed with the assumption that a computer will have a processor, some memory, and a disk. Nowadays trend in the hardware environment is from disk-centric to network-centric This will affect how we organize our software -- and that's where JINI comes in.

Given the rising importance of the network and the proliferation of processors in devices, that are from many different vendors makes the network very dynamic -- devices and services will be added and removed regularly.

JINI provides mechanisms to enable smooth adding, removal, and finding of devices and services on the network. In addition, JINI provides a programming model that makes it easier for programmers to get their devices talking to each other.

JINI is a set of APIs and network protocols that can help you build and deploy distributed systems that are organized as federations of services

Federation in JINI view is a network- Does not involve a central controlling

authority- Group composed of equal peers. - JINI API and runtime infrastructure provides

a way for clients and services to find each other

- Once services locate each other, they are on their own.

- Client and its enlisted services perform their task independently of the JINI runtime infrastructure.

Document and object metaphor

While we can have server side scripting that execute code depending upon client request, it assumes that the result are going to be viewed in context of a web page hence send it as HTML /XML

While JINI doesn’t assume anything as to how is it going to be delivered. It basically brings all the possibilities what we can do with standalone OO Java Programs to be done over the network in a distributed fashion.

An object can perform services for clients because objects embody behavior. An object uses its state to decide how to behave when its methods are invoked.

The key difference between a network-mobile object and a network-mobile document, therefore, is that when you send a document across a network, you're sending data, but when you send an object across the network, you're sending data plus code -- a combination that yields behavior.

Remote method Invocation (RMI)

All the features of OO programming as compared to only limited programming capabilities as available for the document model.

RMI transferring local computation to multiple machines by distributing objects

RMI allows definition and implementation are separate, can run on separate JVM

Used to invoke methods on remote objects that can be looked up in the RMI registry

The service provider registers the remote object

Interface for the Service extends “java.rmi.Remote”

Server MachineClient Machine

Object A : STUB for the Remote Object B

OBJECT B implements interface “IService”

RMI Layer managing connectivity between the stub (proxy) and the remote object + Transport layer stack

The objects that can be transferred across networks are remote objects that does

- extends Remote interface

- each method does declares java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions

Compared to a normal object, when a remote object is passed a stub is created in the receiver, that acts as a proxy to the remote object and acts as remote ref. to the caller.

Internally this local stub on which remote methods are invoked have a Remote Ref in the RMI layer that manages the whole network connection with the actual remote object

Only the methods defined in the Remote interface are allowed to be called by the client via the stub. The remote object may also implement other interfaces that do not extend java.rmi.Remote, these would not be available to the client.

RMI code

Main Advantages of RMI

- Dynamic class loading: bytecode can be downloaded from a remote machine, meaning we can introduce new types in an existing system and make application extensible.

- Separation of interface from implementation: Clients program to remote interfaces, not to the implementation classes of those interfaces

Limitations :- Need to coded in Java.

- Client needs to know the exact location and name of the service to locate them using the RMI registry.

- Does not offer much flexibility to configure using the policy files

Steps in designing an RMI application:

Declare the remote interfaces being implemented

Define the remote object, implementation for the remote methods as well as local methods

The server needs to create and install the remote objects, load RMISecuritymanager and bind the remote object to the registry.

Implement the client object, lookup for the remote object.

When we pass remote objects as method parameters, they are passed by reference meaning a stub is passed and any changes made via method invocation are available at the original remote object.

Local objects are passed by value( a copy is created in the receiving VM), all fields are serialized except one declared static or transient.

The java.rmi.Naming interface is used as a front-end API for binding, or registering, and looking up remote objects in the registry. Once a remote object is registered with the RMI registry on the local host, callers on any host can look up the remote object by name, obtain its reference, and then invoke remote methods on the object.

JINI

• Runtime infrastructure of Jini consists of

- Lookup service (central organizing mechanism)- Clients- Services

• Communication between the three requires following

- Discovery protocol (to locate a lookup service)- Lookup (client lookups a service) - Join (service registers itself with the lookup)

Discovery process:

When a service connects to a network, it broadcasts a presence announcement by dropping a multicast packet onto a well-known port. Included in the presence announcement is an IP address and port number where the disk drive can be contacted by a lookup service.

Lookup services monitor the well-known port for presence announcement packets. When a lookup service receives a presence announcement, it opens and inspects the packet.

If it decides to contact the service , it makes a single dedicated connection to the service using the IP address and port from the muticast announcement packet

Using RMI the lookup service sends an object, called a service registrar, across the network to the originator of the packet. The purpose of the service registrar object is to facilitate further communication with the lookup service.

Using the Service registrar object, the service provider does a join to register itself with the JINI federation so that clients can then use its services.

The Service Registrar object implements a set of interface that allow client and services to do joins and lookups

Figure 1: Querying for a service locator

Figure 2: Registrar returned

Figure 3: Service uploaded

Service object.

Register() method

ServiceRegistration object returned from register

Service Proxy Object

public class PrintServer implements DiscoveryListener {

public PrintServer() {

LookupDiscovery discover = null; discover.addDiscoveryListener(this);

}

public void discovered(DiscoveryEvent evt) {

ServiceRegistrar registrar = evt.getRegistrars()[0]; //discovered a lookup service

// Create information about a service ServiceItem item = new PrintService (null, new PrintService(), null);

// Export a service ServiceRegistration reg = registrar.register(item, Lease.FOREVER); }

}

Join To do a join the service provider

- Invokes the register() method on the Service Registrar

- Passes an object called a service item describe the service.

- The register() method sends a copy of the service item up to the lookup service

- The service item is stored. Once this has completed, the service provider has finished the join process

- The service gets back the handle to the object the reference is maintained at the lookup

ServiceRegistration register(ServiceItem item, long leaseDuration)

Lookup

To find a service, clients query lookup services via a process called lookup.

The client needs to create a ServiceTemplate object that has the following fields

public Entry[] attributeSetTemplates;public ServiceID serviceID; public Class[] serviceTypes;

The lookup() method on a service registrar object., returns an Object object that represents the service item.

•  ServiceMatches lookup (ServiceTemplate tmpl, int maxMatches)           

Returns at most maxMatches items matching the template, plus the total number of items that match the template

• The client - Passes a service template

- The service template can include a reference to an array of Class objects. These Class objects indicate to the

lookup service the Java type (or types) of the service object desired by the client.

• The service template can be an exact matching service ID

• The service template can also contain wildcards for any of these fields. A wildcard will match any service ID.

• The client gets a reference to the matching service objects as the return value of the lookup() method.

public class PrintClient {public PrintClient() { LookupLocator lookup = null;

ServiceRegistrar registrar = null; FileClassifier classifier = null; // Prepare for discovery

lookup = new LookupLocator(“<URL>"); //Discover a lookup service registrar = lookup.getRegistrar();

// Prepare a template for search ServiceTemplate template = new ServiceTemplate(null, printserv ,

null);

printservice = (PrintService) registrar.lookup(template);

// Call the service object methods;printservice.method1();

}

}

Figure 6: Querying for a service locator

Figure 7: Registrar returned

Figure 9: Service returned

In addition to the two lookup() methods, the ServiceRegistrar has three methods called browsing methods that let clients get information about registered service items. These three methods -- getServiceTypes(), getEntryClasses(), and getFieldValues() –

package net.jini.core.lookup;

public Class ServiceItem {

public ServiceID serviceID;

public java.lang.Object service;

public Entry[] attributeSets;

public ServiceItem(ServiceID serviceID,

java.lang.Object service,

Entry[] attrSets);

}

Division of work

The object can actually represent the entire service, which is downloaded to the client during lookup and then executed locally.

Or the service object can serve merely as a proxy to a remote server. When the client invokes methods on the service object, it sends the requests across the network to the server, which does the real work.

The local service object and a remote server can each do part of the work as well.

As the client communicates with the server’s proxy stub, the network protocol or the othre underlying implementation details of the service are hidden from the client, could be RMI, CORBA or DCOM

Typically a Jini application should be designed with separation of UI from the functionality. This enables to use the service from clients that are not capable to display an UI as well as allows different UIs to be attached to one service

The client talks to the service through a well-known interface

Space Based programming

• Typically in distributed applications involves passing messages between processes and invoking methods on remote objects like in RPC, RMI.

• Space is like a shared memory that processes physically located on different machines can communicate with each other

• Dr. David Gelernter developed a tool called Linda for creating distributed applications. Linda consists of a small number of operations combined with a persistent store called a tuple space .

• While JavaSpaces inherited the space model from Linda, the designers of JavaSpaces have updated the model in significant ways, leveraging the power of Java objects, JINI, RMI, and object serialization.

Space

Process B

Process C

Process A

Space containing Entry Objects

Write

Read

Read

TakeProcess D

Waiting

Properties of spaces:

Spaces are shared: Multiple processes physically located on same or different machines can interact with a space concurrently with the sapce handling all the protocol of concurrent access

Spaces are persistent: Objects can be stored reliably in a space for a lease time or indefinitely until they are removed. Also lease time can be extended by renewing the lease

Spaces are associative: Objects in a space are retrieved located via associative lookup, meaning we can prepare a template of one /multiple fields representing the query and get result back. This allows a lot of advantages to query using simple expressions rather than remembering object Id or the name

Spaces are transactionally secure: JavaSpaces transactions have the inbuilt ACID properties. Every operation in the space is atomic. Transactions are supported for single operations on a single space, as well as multiple operations over one or more spaces.

Spaces let you exchange executable content: While in

a space, objects are just passive data -- you can't modify them or invoke their methods. However, when you read or take an object from a space, a local copy of the object is created. As with any other local object, you can modify its public fields and invoke its methods, even if you've never seen an object like it before. This coupled with associative lookup offers advantages as compared to RMI.

Javaspaces is a set of API that provides a special kind of service to a JINI federation. It can operate as part of a bigger JINI federation or be in a single federation on its own.

Every object in the space is of type ‘Entry’ which is a interface in net.jini.core.entry package

For example, we have to write a Task object in space, its definition would be

public class Task implements Entry {        public String content;       // a no-arg constructor        public Task() {        }    }

It’s a no-marker interface, all members of the class should be public as this lets to lookup objects in space using associative lookup, should have a no argument constructor to facilitate serialization to transfer objects in and out of space

Conventions that our entries

- An entry must have a public constructor that takes no arguments

- Another convention is that fields of an entry should be declared public

- A third convention is that fields of an entry must contain references to objects, rather than primitive types

API

write: Places one copy of an entry into a space. If called multiple times with the same entry, then multiple copies of the entry are written into the space.

read: Takes an entry that is used as a template and returns a copy of an object in the space that matches the template. If no matching objects are in the space, then read may wait a user-specified amount of time until a matching entry arrives in the space.

take: Works like read, except that the matching entry is removed from the space and returned as the result of the take.

In addition, the JavaSpace interface supplies the following methods, which can be useful in many applications:

notify: Takes a template and an object and asks the space to notify the object whenever entries that match the template are added to the space. This notification mechanism, which is built on Jini's distributed event model, is useful when you want to interact with a space using a reactive style of programming.

snapshot: Provides a method of minimizing the serialization that occurs whenever entries or templates are used; you can use snapshot to optimize certain entry usage patterns in your applications. We will cover this method in detail in a later article.

Project involved developing a computation server for carrying out parallel computation of computation intensive problems

Task entry computes the Fourier transform of a given set of input numbers.

Also made some other task entries like matrix multiplication of really huge matrices, or arithmetic functions of large numbers

MASTER – Creates tasks, writes to space and waits for results

WORKER: Takes tasks, calls its execute() method, writes results

WORKER

WORKER

SPACE containing TASK and RESULT entries

Writing Entries to space

Reading Entries from space

Application Design: Uses Command pattern: client publishes code

or implementation for any particular task entry. Service picks up the task entry and executes code provided by clients

Server need not have any knowledge of implementation details of task, just needs to have the computation capability

Can easily be extended to include new tasks as and when required provided they adhere to some simple rules

FTT of a given set of real numbers

Examples of systems using Space Based programming:

a) Chat Systems: A JS represents the chat room, objects within the space can represent buddy list members, messages or any other information needed to maintain the chat room

b) Broker System