Introduction to Jini & JavaSpaces Source references: JGrid project

Agenda Jini SOA Jini intro Jini detailed view Summary

Introduction to Jini

What Is Jini Java Based SOA Platform Designed as a native extension of the J2SDK Project in Sun First announced in 1998 Positioned for dynamic networking

Web Services - SOA Web Services UDDI Registry Find Publish WSDL Client Bind/Invoke WSDL Web Services

Jini SOA Jini Lookup Service Publish Find Java Interface Jini Service Client Publish Bind/Invoke Java Interface Find Jini

Jini Components

How does it work Find Publish Bind/Invoke Jini Client Service Registry Lookup Service Jini Service Publish in both LUS and UDDI Service Proxy Bind/Invoke

Jini – A Detailed view Discovery Registration Lookup Events Leasing Proxies

Unicast discovery LookupLocator lookup = null; ServiceRegistrar registrar = null;   lookup = new LookupLocator(“jini://hostname”); registrar = lookup.getRegistrar(); Lookup Service registrar LUS proxy download Discovery request Service A The service program should perform a unicast discovery to discover the lookup service and obtain a proxy (registrar) for it. Using the registrar proxy we can register a service proxy with the lookup service. A successful registration will return a registration object. The registration object can be used to manage the service proxy within the lookup service, eg to add or modify attributes, get the lease associated with the proxy.

Multicast discovery Discovery is initiated by class LookupDiscovery LookupDiscovery discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS); Asynchronous responses are handled by a listener object (implementing the DiscoveryListener interface) discover.addDiscoveryListener(listener); Registration public void discovered(DiscoveryEvent e){ //Lookup service discovered – register } multicast request Lookup Service N Unlike in the unicast discovery case, the constructor of the LookupDiscovery class will perform multicast discovery. How to handle asynchronous responses? We do not know how many responses we receive and when. Multicast discovery uses a separate thread – a Listener object – to handle incoming responses from lookup services. The parameter LookupDiscovery.ALL_GROUPS specifies that we are interested in all lookup services of all communities. If you specify a different name, only the lookup service(s) of the community with the matching name will respond. Lookup Service … Discovering entity Lookup Service 2 Lookup Service 1

Main steps Discovery Registration Lookup Events Leasing Proxies

Service registration Once we have a proxy to the lookup service, can register the service ServiceRegistration registration = null; //create serviceItem (no ID, no attributes) Lookup Service Service Proxy registration ServiceItem serviceItem = new ServiceItem(null, new GreetingServiceProxy(), null); download Service A register( ) try{// register for 100 seconds registration registrar.register( serviceItem, 100000L); } catch (java.rmi.RemoteException e){} registrar Service Registration The service proxy is uploaded to the lookup service using the register method of the registrar object. The input parameters are a serviceItem object and an initial lease value specified in milliseconds. The ServiceItem class The ServiceItem object contains the service ID of the service, the service object itself that is being registered, and a set of attributes describing the service. The serviceID of a new service (that was not registered previously) is null. The lookup service will assign a unique service ID to the service. This serviceID must be used in subsequent operations.   REMEMBER: The service object must be serializable. The object will be exported and moved around over the network using RMI. The register() method The object returned by the register() method is an implementation of the ServiceRegistration interface. This object will run in the JVM of the service and, as mentioned earlier, can be used to manipulate the service item registered with the lookup service. Manipulation includes the modification of service attributes, the lease and access to the serviceID using methods addAttributes(), modifyAttributes(), setAttributes(), getLease() and getServiceID(). LUS proxy

Main steps Discovery Registration Lookup Events Leasing Proxies

The client side // create template for service search ... GreetingServiceInterface returnedService = null; try{ returnedService = (GreetingServiceInterface) registrar.lookup(template); }catch (java.rmi.RemoteException e){ } returnedService.hello(); Lookup Service Client 1 Found proxy lookup( ) Interface Template registrar On the client side we first perform a unicast discovery to obtain a proxy for the lookup service. This process is identical to the one on the service side. Then, to be able to perform a service search, we create a template object that describes the type of service we want to find. This description can use the type of the service (in form of a well-known interface) and/or a set of attributes). When the template is constructed, we invoke the lookup() method on the registrar object with the template as input parameter. The lookup will perform a template-matching search of all registered services based on the search rules described earlier. The successful lookup will return one or more services depending on which of the two lookup methods has been used. Note that the lookup in Jini by default performs exact matching. For instance, if you are interested in services with larger than 500 GFlops computing performance, you need to download all computing services and examine their performance attribute individually. This is because the matching is based on serialised objects (ie the proxies).

Main steps Discovery Registration Lookup Events Leasing Proxies

Remote Events Jini provides remote events to make a Jini system dynamic Services coming and going State changes The event mechanism is based on Event registration Event handling through an event listener’s notify() method Events that are routinely used in interactive programs running in a single JVM are very useful in distributed systems too. Distributed systems, however, are different in many ways: the underlying network transport can be unreliable and/or slow events may not arrive in their original order parts of the system run in different JVMs, and on physically different machines event notification should be delayed or transferred to a different object The Jini distributed event model Jini technology extends the notion of event notification to distributed systems and introduces the concept of remote distributed events. The central concept is that an object can register its interest of some state change in another object, and receive notification when that event has happened. This model is deliberately very simple. It does not guarantee reliability and correct timing; it is left to the objects involved to provide correct behaviour in the event notification mechanism.

Main steps Discovery Registration Lookup Events Leasing Proxies

Obtaining a Lease The lease grantor is usually the lookup service and the leaseholder usually is the service.   ServiceRegistration reg = registrar.register(); Lease lease = reg.getLease(); Visually this can be represented as Service A Lookup Service registrar The lease is returned to the service through the ServiceRegistration object (as the result of the registration) using its getLease() method. getLease() registration lease

Main steps Discovery Registration Lookup Events Leasing Proxies

Jini service proxy models There are several ways (patterns) of creating service proxies. A proxy can: Run entirely in the client JVM Be an RMI stub Be a proxy with local logic using RMI to the back end service Be a proxy with local logic using its own communication protocol (e.g. socket) to the back end service Be a wrapper to legacy code (e.g. CORBA)

Introduction to JavaSpaces

What is JavaSpaces? A JINI service that provides distributed shared memory capabilities A simple yet powerful service that can be used for solving distributed programming issues such as: Collaboration WorkFlow Synchronization Distributed Computing

JavaSpaces model Write Read, Take, Notify Read, Take, Notify Write Write –writes a data object. Read – reads a copy of a data object. Take – reads a data object and deletes it. Notify – generates an event on data updates. Write Read, Take, Notify Read, Take, Notify Write

Clustered JavaSpaces

JavaSpaces Methods (Space Operations) JavaSpaces provides a basic API for storing and reading data objects in a shared resource (a space). The methods are: Write –writes a data object. Read – reads a copy of a data object. Take – reads a data object and deletes it. Notify – generates an event on data updates.

Example Entry This shows a minimal entry: package hello; import net.jini.core.entry.Entry; public class Message implements Entry { public String content; public Message() } Must Implements Entry interface Entry Filed need to be public Must include a constructor

Write/Read Operations Instantiate an Entry Set its fields as necessary Write the entry to the space Read an Entry Message msg = new Message(); msg.content = "Hello World"; JavaSpace space = (JavaSpace)SpaceFinder.find( “jini://*/*/JavaSpaces” ); Lease l=space.write(msg, null, Lease.FOREVER); Message template = new Message(); Template.content = “data to match”; Message result = (Message)space.read(template, null, Long.MAX_VALUE);

Notify Operation Registering for notifications // Register a notification template = space.snapshot(new Message()); EventRegistration reg = space.notify( template, null, //TX SpaceEventListener() , // The listener 60000 , // Lease null); // handbag System.out.println( "Notification registered. Registration id: " + reg.getID() + “Sequence number: " + reg.getSequenceNumber());

Parallel Batch Processing Grid engine for parallel processing

Monte Carlo Simulation Details 18,000 Securities, 20 Scenarios, 2,000 Paths/Scenario 1 run = 18K x 20 x 2K (720M) theoretically separate tasks 1 run = 18K x 20 (360k) tasks in reality due to granularity These larger tasks are separable Computation time per task ranges from 20-2000 ms Total computation time in sequence ~100 H Setup for run takes 1-5 minutes First pass attempts with threading on 8-way box used 56 H of elapsed time Using the space with 50 units ~2 H (Source-Invesco)

Scalability & Performance Source: Dr. Alexander Gebhart - Development Architect SAP – JavaOne presentation 2003

Parallel Parsing Grid

Provisioning & Monitoring Using the RIO project

RIO Project - SLA based deployment

Monitoring

Thank You! natis@gigaspaces.com