Jini an Infrastructure for Dynamic Service Networks

Peer Hasselmeyer IT Transfer Office (ITO) Darmstadt University of Technology - Java Intelligent Network Infrastructure - Jini Is Not Initials

http://www.ito.tu-darmstadt.de

Jini – an Infrastructure for Dynamic Service Networks

Overview

– overview

– leasing – distributed events

• RMI/Serialization • Jini infrastructure • Jini services – lookup service – discovery & join protocols – programming example – more details

– transactions – JavaSpaces

• Summary

Jini: Talk Outline

• Jini, what’s that? • Jini programming model – motivation

Jini

– facilitates writing / deploying distributed applications

Jini: Motivation

• Infrastructure (“middleware”) for dynamic, cooperative, spontaneously networked systems

Jini

– facilitates writing / deploying distributed •framework of APIs with useful applicationsfunctions / services •helper services (discovery, lookup,...) •suite of standard protocols and conventions

Jini: Motivation

• Infrastructure (“middleware”) for dynamic, cooperative, spontaneously networked systems

Jini

– facilitates writing / deploying distributed applications •services, devices, … find each other automatically (“plug and play”) •added, removed components •changing communication relationships •mobility

Jini: Motivation

• Infrastructure (“middleware”) for dynamic, cooperative, spontaneously networked systems

Jini – may use RMI (Remote Method Invocation) – typed (object-oriented) communication structure – requires JVM / bytecode everywhere – code shipping

• Strictly service-oriented

Jini: Motivation

• Based on Java and implemented in Java

Service Paradigm

– like object-orientation: “everything” is an object – e.g. persistent storage, software filter, help desk, …

• Services are defined by interfaces and provide their functionality via their interfaces – services are further characterized by their attributes (e.g. “600 dpi”, “version 21.1”)

Jini: Motivation

• Everything is a service (hardware / software / user)

Service Paradigm Jini: Motivation

• Jini’s run-time infrastructure offers mechanisms for adding, removing, and finding services • Services (and service users) “spontaneously” form a system (“federation”)

A Jini Federation Picture storage service

Network

Camera 1 (client)

Camera 2 (client)

Print service

Jini: Motivation

Picture mailing service

What Kind of Services? – printer, fax machine, ... – storage, persistency, configuration, ... – computation, ...

• Software: – spell checking, format conversion, ... – online banking, stock trading, ... – tourist guide, local maps, hotels, restaurants, ...

Jini: Motivation

• Devices:

Spontaneous Networking

– cooperation, service usage, …

• Problem: no a priori knowledge about existence, interface, functionality, and trustworthiness of services – “traditional” client/server model: server knows nothing about its clients, but client knows the server, its interface (API, protocol) and its functionality

Jini: Motivation

• Objects in an open, distributed, dynamic world find each other and form a transient community

Spontaneous Networking

me who else? • But: what for?

X

Jini: Motivation

• Objects must be able to find each other • Must be fast, easy, and automatic

What Does Tomorrow Look Like? Jini: Motivation

• Increasing number of internet users • Powerful PDAs and notebooks • Increasing mobility • New wireless information devices • Numerous mobile networked devices

What Does Tomorrow Look Like?

– e.g. software updates for your washing machine, internet-ready microwave, ...

• Trend towards ubiquitous networks and spontaneous networking / service access – high bandwidth, wireless, cheap

Jini: Motivation

• Numerous processors in embedded systems

Middleware

– components to help build and deploy distributed applications (development-time vs. run-time) – located between the application logic and the underlying physical network and operating system

Jini: Motivation

• Approach from a different direction: “middleware”

Middleware Application

Application APIs

Service Service

Service

Middleware

Service Platform interface

Platform • OS • network

Platform • OS • network

Jini: Motivation

Application

Middleware

– problem: data encoding (e.g. big/little endian, integer size, array storage layout, ...)

• Components for recurring problems (e.g. naming service, security service, ...)

Jini: Motivation

• Abstraction from tedious network programming wanted • Abstraction from differing machine architectures wanted

Problems with Current Middleware – programmers don’t have to deal with the network and its inherent problems (unreliability, latency, bandwidth, ...) – no exception handling

• Data is moved to the computation – “classical” client/server paradigm – not always most efficient solution – problem: different data formats (byte-order) – but: program code is usually not available everywhere (different system architectures, installation, ...)

Jini: Motivation

• Systems hide network from programmer

Middleware: Partial Failure Jini: Motivation

• Difference between local and remote call: total vs. partial failure • Components might be unreachable: server crash, broken network connection, ... • Problem: how to distinguish unreachable from slow server

Middleware: Partial Failure

– e.g. Internet: server crash does not affect other servers

• Jini offers mechanisms to deal with partial failure

Jini: Motivation

• Components / middleware have to be able to deal with partial failure • Unreachability of one component should not (or only minimally) affect other components

Some Fallacies of Common Distributed Computing Systems – the network is reliable – latency is zero – bandwidth is infinite – topology doesn’t change – there is one administrator

• …isn’t true in reality – Jini addresses some of these issues – at least it does not hide or ignore them

Jini: Motivation

• The idealistic view…

Bird’s-Eye View on Jini Jini: Overview

• Jini consists of a number of APIs • Is an extension to the Applications Services Java 2 platform dealing Jini technology with distributed Java technology computing Operating system Network • Is a layer of abstraction between application and underlying infrastructure (network, OS) → “middleware” • Extension of Java in three dimensions

Jini’s Extensions to Java Infrastructure Programming Services model • Swing • Transaction Java • JVM • RMI • Beans Service • Enterprise •… •… JavaBeans •… Jini • Discovery • Transactions • JavaSpaces • Lookup • Leasing • Transaction Manager • Join • Distributed Events

• Distinction may seem blurred

Jini: Overview

• Extensions regarding networked systems

Jini’s Use of Java Jini: Overview

• Jini requires JVM (as bytecode interpreter) and (currently) RMI

Able to perform discovery & join; have a JVM; ...

– homogeneity in a heterogeneous world – is this realistic?

• But: devices that are not “Jini-enabled” can be managed by a software proxy which resides at some place in the net – e.g. “Device Bay”

• Safety of Java applies to Jini as well – type safety, array bounds, sand box, ...

Jini vs. Mobile Agents – most mobile agent platforms are based on Java – Java bytecode often used as a universal machine language – applets are working instances of the mobile code paradigm

• Jini uses the mobile code paradigm – service proxies are sent to the client (via the lookup service)

Jini: Overview

• Jini is Java-based

Jini vs. Mobile Agents – Jini is an infrastructure for highly dynamic distributed systems – Jini provides elementary services and functionality • e.g. agent coordination with JavaSpaces

• But: Jini is not a mobile agent platform! – further services required – however: Jini (and similar systems) are of general interest to computer scientists (→ ubiquitous computing, distributed systems)

Jini: Overview

• Mobile agents need an infrastructure

Overview

– overview

– leasing – distributed events

• RMI/Serialization • Jini infrastructure • Jini services – lookup service – discovery & join protocols – programming example – more details

– transactions – JavaSpaces

• Summary

Jini: Talk Outline

• Jini, what’s that? • Jini programming model – motivation

RMI: Introduction RMI: Introduction

• RMI: “Remote Method Invocation” • Java’s native middleware • “Regular” Java: method invocation within one Java VM • By using RMI objects can call methods of objects running in a different Java VM • Java VMs can be distributed among multiple machines in a network

Remote Invocation

Client

Java VM Method invocation Result Network

Server

RMI: Introduction

Java VM

What To Use RMI For?

– partial failure possible – larger latency

RMI: Introduction

• Server objects offer their functionality (“services”: data, computation) to clients • Clients can access them via a network • RMI offers mechanism to bring clients and servers together • Goal: clients can use remote server objects in (almost) the same way as they use local objects

How Does RMI Work?

– so-called “stub” – signatures of methods are identical to methods in remote server object – handles communication with remote object

• “Skeleton” in server is counterpart to stub – forwards parameter to “actual” server object – returns result to stub

RMI: Introduction

• Basic difference between local and remote objects: different Java VMs • Idea: create a proxy for the remote object in the local Java VM

How Does RMI Work? Java VM

Client

Server Network

Stub

Method invocation Result

Skeleton

RMI: Introduction

Java VM

More Details

Server Program

Stub

Skeleton

Remote Reference Layer

Remote Reference Layer

Transport Layer

Network

Transport Layer

RMI: Introduction

Client Program

Programmer's view

RMI Details RMI: Introduction

• Client: invokes methods of an object • Stub: implements “remote interface” of server object, passes on parameters • Remote Reference Layer: maps object references to machines and objects • Transport Layer: manages connections between machines and handles data transfer • Skeleton: passes data to server object • Server: implements functionality

Getting Access to Objects

– mapping name (string) → object – location of registry (machine name and port number) must be known – name of server object must be known – e.g. “//server.tud.de:2222/HelloServer” – usually reference to first object only; grants access to further objects (“factory pattern”) – e.g. root: database object, access to entries

• Jini

RMI: Introduction

• Clients must get stubs for remote objects • RMI registry: naming service

Example: Remote Interface

public interface Hello extends java.rmi.Remote { String sayHello() throws java.rmi.RemoteException; }

• Methods can always throw RemoteExceptions – server or network may fail

• Interfaces are marked as remote by extending tag interface java.rmi.Remote

RMI: Example

• Remote methods are defined by “remote interfaces”:

Example: Server Object

public class HelloImpl extends java.rmi.server.UnicastRemoteObject implements Hello { public HelloImpl() throws java.rmi.RemoteException { super(); // UnicastRemoteObject } public String sayHello() throws java.rmi.RemoteException { return “Hello World!”; } }

RMI: Example

• Server implements remote interface and extends UnicastRemoteObject

Example: Server Object

• UnicastRemoteObject handles RMI related work (make object known to RMI, relay calls) • Server has to realize interface’s functionality

RMI: Example

public HelloImpl() throws java.rmi.RemoteException { super(); // UnicastRemoteObject } public String sayHello() throws java.rmi.RemoteException { return “Hello World!”; }

Example: Server Startup

• Create server object • Register it with RMI registry – address/port of registry must be known – name for object must be supplied

RMI: Example

public class HelloStart { public static void main(String args[]) { try { HelloImpl obj = new HelloImpl(); java.rmi.Naming.rebind( “//server.tud.de/HelloServer”, obj); } catch (Exception e) {} [...wait and unregister object on exit...] } }

Example: Client

• Security manager enables class download • Get server’s stub from RMI registry • Use the server

RMI: Example

public class HelloClient { public static void main(String args[]) { System.setSecurityManager( new java.rmi.RMISecurityManager()); try { Hello obj = (Hello) java.rmi.Naming.lookup( “//server.tud.de/HelloServer”); System.out.println(obj.sayHello()); } catch (Exception e) {} }}

Example: Deployment

– creates classes HelloImpl_Stub and HelloImpl_Skel – no skeletons needed in Java 2 (option -v1.2)

RMI: Example

• Naming Service must be running: rmiregistry • Stub has to be created: rmic HelloImpl

Example: Deployment

– java -Djava.security.policy=policy HelloStart – java -Djava.security.policy=policy HelloClient

• For non-local environments classes (here: HelloImpl_Stub) have to be put onto an HTTP server and server’s codebase has to be supplied

RMI: Example

• Security policy needed to access sockets:

Serialization

– all referenced objects have to be recursively serialized (“transitive closure”)

RMI: Serialization

• Parameters and return values (arbitrary objects) have to be transferred between client and server • Copy of object has to be sent to remote JVM • Solution: transform objects into stream of bytes (“serialization”) • Problem: objects may contain references to other objects

Serialization

Byte stream

...

Network

Deserialization

Serialization

Destination JVM

RMI: Serialization

Source JVM

Serialization RMI: Serialization

• Transforming an object into a stream of bytes • Object consists of its code and its (data) state (values of variables) • Code is stored in class files • State is dynamic and only available at runtime • Take a “snapshot” of this state

How Does Serialization Work? RMI: Serialization

• Realized by Java’s introspection facilities • All non-transient, non-static fields are recursively written to a byte-stream • Simple types have predefined storage functions • Objects’ types (full class names, e.g. java.util.List) and signatures are written

How Does Serialization Work?

– calculated from the signature of a class – can be overridden manually to mark compatible class evolution

• Objects have to implement tag interface java.io.Serializable • Predefined serialization semantics can be overridden by implementing certain functions (writeObject(), readObject())

RMI: Serialization

• Objects are only written once, even if referenced multiple times • “Serial version UID” to control versions

What Can Be Serialized? RMI: Serialization

• All primitive types (int, boolean, etc.) • “Remote objects” (by sending serialized stubs) • Base types (String, Integer, ...) that implement java.io.Serializable • Most container classes (Hashtable, Vector, ...) if and only if they only contain serializable objects • Some AWT and Swing classes • Your classes, if they implement java.io.Serializable

What Cannot Be Serialized?

– “wrapper classes” possible (by inheritance)

• “Low level” classes: – input and output streams – threads – peer classes

• Objects that reference non-serializable objects

RMI: Serialization

• Base types that do not implement Serializable

What To Use Serialization For? – configurations – (Enterprise) Java Beans – to continue working on the same state later

• Write to socket: – to transfer objects to another JVM – parameter passing – mobile agents

RMI: Serialization

• Write to file: make objects persistent

Code Mobility – code (in Java class files) – state (values of attributes, execution pointers)

• RMI transfers only data state • Problem: code is usually not locally available at recipient (i.e. not listed in its classpath) • Solution: code can be downloaded at run-time (e.g. from an HTTP server)

RMI: Code Mobility

• Objects consists of two parts:

Code Mobility State a=5 b=7

Reconstructed object a=5 b=7

Implementation a=? b=?

Code from (web) server

RMI: Code Mobility

Data from source JVM

Codebase

– directory containing the class tree – JAR file containing the classes

• Codebase is set as a property when starting a JVM

RMI: Code Mobility

• Code can be downloaded, but: where from? • Location of code is transferred together with its state (“codebase”) • Codebase is a list of URLs • URL might point to

Security

– fine-grained control of local resources (especially storage, network) possible – rights are granted based on • where code came from (network, local file) • who signed code grant signedBy “sysadmin”, codeBase “http://server.tud.de/-” { permission java.net.SocketPermission “*:1024-”, “connect”; };

RMI: Code Mobility

• Unknown objects are executed on local machine (like applets) • Access restrictions desired; specified by security policies

Overview

– overview

– leasing – distributed events

• RMI/Serialization • Jini infrastructure • Jini services – lookup service – discovery & join protocols – programming example – more details

– transactions – JavaSpaces

• Summary

Jini: Talk Outline

• Jini, what’s that? • Jini programming model – motivation

Jini Infrastructure – lookup service as repository / naming service / trader – protocols based on TCP/UDP/IP • discovery, join, lookup

– proxy objects • transferred from service to clients • represent the service locally at the client

Jini: Infrastructure

• Main components are:

Jini Infrastructure Jini: Infrastructure

• Goal: spontaneous networking and formation of federations without prior knowledge of local network environment • Problem: How do service providers and clients get to know their local environment?

Lookup Service

– registration of services (“advertising”) – distribution of services (clients find services)

• Main component of every Jini federation • May be redundant and hierarchically organized (similar to DNS)

Jini: Lookup Service

• Similar to RMI registry and CORBA naming service • Repository of service providers • Tasks:

Jini Federation Jini: Lookup Service

Client

er is t

loo

reg

ku p

Lookup Service

use

Service

Lookup Service

– required: objects must be able to migrate through the net

• Not only name and address of a service are stored (as in traditional naming services), but also set of attributes – e.g.: printer (color: true, dpi: 600, ...) – attributes may be complex classes • e.g.: user interface(s)

Jini: Lookup Service

• Reference implementation uses Java RMI for communication

Discovery: Finding a LUS

– to advertise (register) a service – to find (look up) an existing service

• Discovery protocol: – multicast to well-known address/port – lookup service replies with a serialized object (interface ServiceRegistrar) • proxy object of lookup service gets loaded to discovering entity • communication with LUS via this proxy

Jini: Protocols

• Goal: Finding a lookup service without knowing anything about the network

Discovery

Where is the lookup service?

Lookup Service

??? Multicast Request Lookup Service Lookup Service

Proxy

Lookup Service

Proxy

Reply Lookup Service

Proxy

Communication

That’s me!!!

Lookup Service

Jini: Protocols

foreign network

Join: Registering a Service

• Provider sends the lookup service – its service proxy – attributes that further describe the service

• Provider can now be found and used in this Jini federation

Jini: Protocols

• Service provider already received a proxy of the lookup service • Provider uses this proxy to register its service (register())

Join

Entry 1 Entry 2 ... Entry n

Proxy atio Registr

Service proxy

atio Registr

n

n Service proxy

Entry1Entry2...Entry n

...

Lookup Service

Lookup Service

Service database in LUS

Jini: Protocols

Service

Lookup: Searching Services

– in form of a “service template” – matching by service type and/or attributes and/or registration number of service – wildcards possible

Jini: Protocols

• Client knows lookup service (e.g. via discovery protocol) • Looking for certain (type of) service • Creates query for lookup service

Lookup: Searching Services Jini: Protocols

• Lookup service returns one or more matches (or zero) • Selection usually done by client • Service use by calling functions of service proxy • Any protocol between proxy and service provider possible

Lookup

Proxy

?

Lookup

n tio i ca un mm Co

Service proxy

? ?

Entry1Entry2...Entry n

Service proxy Service proxy

Entry1Entry2...Entry n

...

Lookup Service

Lookup Service

Entry1Entry2...Entry n

Service database in LUS

Jini: Protocols

Client

Jini Programming Example Jini: Protocols

• How is a service implemented? • How does a client get access to a service? • How is a service described?

The “Running Example” Printer proxy

Printer proxy Printer proxy

Office application

Any protocol

Communication between application and printer via function calls of proxy

Jini: Protocols

Lookup Service

The “Running Example”

public interface Print extends java.rmi.Remote { public PrinterParams readPrinterParams() throws java.rmi.RemoteException; public SuccessCode print(Document doc) throws java.rmi.RemoteException; [...etc...] }

Jini: Protocols

• Printer registers itself with the office’s lookup service • Printer provides print interface as its service

The “Running Example” Jini: Protocols

• Implementation of service consists of provider and proxy • Proxy is stored in the lookup service and will be transferred to clients upon request • Protocol between proxy and service provider depends on implementation and is not stipulated by Jini • Example uses RMI

Implementing Service Provider Jini: Protocols

public class PrintImpl extends UnicastRemoteObject implements Print { [...] public PrinterParams readPrinterParams() throws RemoteException { // something should be done here no There’s } Jini in here! public SuccessCode print(Document doc) throws RemoteException { // something else should be done here } [...] }

Registering a Service Jini: Protocols

public class PrintRegistration { public static void main(String[] args) { System.setSecurityManager( new RMISecurityManager()); [...] Print service = new PrintImpl(); Entry[] attribute = new Entry[1]; attribute[0] = new ServiceInfo( “Print Service”, “HyperClear”, “Shiny Inc.”, “2000”, “”, “08/15”); JoinManager jmgr = new JoinManager(service, attribute, (ServiceIDListener) new Listener(), new LeaseRenewalManager()); [...] }}

Multicast Discovery Client Jini: Protocols

public class MCExample implements DiscoveryListener { public static void main(String[] args) { [...Security Manager etc...] LookupDiscovery ld = new LookupDiscovery(LookupDiscovery.ALL_GROUPS); ld.addDiscoveryListener(new MCExample()); [...] } public void discovered(DiscoveryEvent ev) { ServiceRegistrar[] regs = ev.getRegistrars(); ServiceRegistrar reg = regs[0]; Class[] cl = new Class[] { Print.class }; ServiceTemplate tmpl = new ServiceTemplate(null, cl, null); Print proxy = (Print) reg.lookup(tmpl); } public void discarded(DiscoveryEvent e) {} }

Overview

– overview

– leasing – distributed events

• RMI/Serialization • Jini infrastructure • Jini services – lookup service – discovery & join protocols – programming example – more details

– transactions – JavaSpaces

• Summary

Jini: Talk Outline

• Jini, what’s that? • Jini programming model – motivation

Discovery

– client asks for local lookup services – no prior knowledge of local network necessary

• Unicast request protocol – used to contact known lookup services – works across subnet boundaries and over the Internet

Jini: More Details

• Protocols to find lookup services • Multicast request protocol

Discovery – protocol for lookup services to announce their presence

• Example: printer registers with the office via multicast, but gets service for software updates from a dedicated lookup server via unicast discovery

Jini: More Details

• Multicast announcement protocol

Multicast Request Protocol

– IP-centric – multicast address for discovery is 224.0.1.85 – default port number of lookup services is 4160 • hexadecimal subtraction: CAFE16BABE16=416010

Jini: More Details

• No information about the host network needed • Active search for lookup services • Discovery request is multicast packet

Multicast Request Protocol – recommended time-to-live is 15 – usually does not cross subnet boundaries

• Discovery reply is establishment of a TCP connection – port for reply is included in multicast request packet

Jini: More Details

• Discovery request is multicast packet

Multicast Request Protocol

Multicast response server

JavaVM client/service

Multicast request UDP packet

TCP

Service registrar

Multicast request server Multicast response client

JavaVM lookup service

Jini: More Details

Multicast request client

Multicast Request Packet

max. 512 bytes

Jini: More Details

Protocol version (int) Reply port (int) Number of known LUSes (int) LUS 1 (ServiceID) ... LUS n (ServiceID) Number of groups (int) Group 1 (String) ... Group m (String)

Unicast Discovery Protocol

Establish TCP connection

JavaVM client/service

Unicast request Service registrar Unicast response

JavaVM lookup service

Jini: More Details

• Used to contact lookup services with known locations • Uses TCP (unicast) connections to port 4160 • Simple request-response protocol

Unicast Packets

Protocol version (int)

• Unicast Response (lookup service → client) LUS proxy (MarshalledObject) Number of groups (int) Group 1 (String) ... Group m (String)

Jini: More Details

• Unicast Request (client → lookup service)

Multicast Announcement Protocol

– recommended: every 120 seconds

• Receivers listen for announcements on well-known port • If not yet known, receiver starts unicast discovery of this service

Jini: More Details

• Used by lookup services • Announces the availability of lookup services • Based on multicast UDP • Announcements are sent periodically

Multicast Announcement Packet

max. 512 bytes

Jini: More Details

Protocol version (int) Host for unicast discovery (String) Port for unicast discovery (int) Service id (ServiceID) Number of groups (int) Group 1 (String) ... Group m (String)

Lookup Service Details

Service usage

Client

Regis

tratio n

Lookup Service L ook

up

Jini: More Details

Service

Groups

– group name: simple text identifier – clients/services always announce interest in certain group(s) – unwanted groups are ignored – services do not explicitly register for certain groups, rather with LUS that carries group

• e.g. one lookup service per department: accounting, production, research, ...

Jini: More Details

• There may be lots of lookup services in a large Jini system • Idea: split lookup services into groups

LUS: Proxy Interface ServiceRegistrar { public ServiceRegistration register(ServiceItem item, long leaseDuration) throws RemoteException; public java.lang.Object lookup(ServiceTemplate tmpl) throws RemoteException; public ServiceMatches lookup(ServiceTemplate tmpl, int maxMatches) throws RemoteException; [...]

}

Used by clients

Jini: More Details

Used by service publicproviders interface

Join: More Features ServiceItem(Object service, ServiceID id, Entry[] attributes)

– its proxy – its ServiceID (if previously assigned; “universally unique identifier”) – set of attributes – set of groups (or ALL_GROUPS) – (possibly empty) set of specific lookup services to join

Jini: More Details

• To join, a service supplies:

Join: Service IDs ServiceItem(Object service, ServiceID id, Entry[] attributes)

• Service-ID is a 128 bit “universally unique identifier” – generated by the lookup service when registering for the first time – service has to reuse it for all later registrations – service has to make it persistent

Jini: More Details

• To join, a service supplies:

Join: More Features

– prevents packet storm after restarting a network segment

• Registration with a lookup service is bound to a lease – service has to renew its lease periodically

• Discovery and join can be handled by objects of class JoinManager

Jini: More Details

• Service waits a random amount of time after start-up

Lookup: More Features

– ServiceID – service type – certain attributes

Jini: More Details

• Client looks for service(s) registered with a lookup service • Any combination of search criteria possible:

Lookup: More Features ServiceTemplate(ServiceID serviceID, java.lang.Class[] serviceTypes, Entry[] attrSetTemplates)

• Template filled with interfaces, entries and/or ServiceID • Wildcards possible, represented by null • Attributes: only exact matching possible (no “larger-than”, ..) • No query language

Jini: More Details

• Client creates ServiceTemplate

Entries

– set of attributes • e.g.: PrinterParams (dpi: 600, type: color, …)

– every serializable data type is possible – data and methods – complex classes possible • e.g. different user interfaces (AWT, Swing, speech, ...)

Jini: More Details

• Difference to “traditional” naming services • Not only a name for a service • Properties:

Entries (Examples)

public class AWTGUIEntry extends AbstractEntry { public Panel panel; [...] public GUIEntry() {} public GUIEntry(Panel panel) { this.panel = panel; [...] } }

public class PrinterEntry extends AbstractEntry { public PrinterType type; public Integer pagesPerSecond; [...] public PrinterEntry() {} public PrinterEntry(PT type) { this.type = type; [...] } }

Jini: More Details

public class Name extends AbstractEntry { public String name; public Name() {} public Name(String name) { this.name = name; } }

Entries (Examples)

public class AWTGUIEntry extends AbstractEntry { public Panel panel; [...] public GUIEntry() {} public GUIEntry(Panel panel) { this.panel = panel; [...] } }

public class PrinterEntry extends AbstractEntry { public PrinterType type; public Integer pagesPerSecond; [...] public PrinterEntry() {} public PrinterEntry(PT type) { this.type = type; [...] } }

Complex data structures

Jini: More Details

public class Name extends AbstractEntry { public String name; public Name() {} public Name(String name) { this.name = name; } }

Lookup Service vs. Naming Service

Identified by (static) address; clients need to know address groups can be modeled by addresses

Lookup service Description by ServiceItems • type & attributes • arbitrary search dimensions Type is explicit Standardized interfaces Services have to renew their entries in the lookup service periodically (leasing) Discovery; no network information necessary group concept

Jini: More Details

Naming service Description by name (text) only • e.g. /devices/printers/ → printers • search by name only Name implies type Standardized naming conventions Usually no expiration of entries (heartbeat, keep-alive)

Proxy: Features Jini: More Details

• All communication between clients and services is handled by service’s proxy • Proxy object is stored in the lookup service upon registration • Serialized object • Implements one or more service interfaces • Service type is defined by the type of the interface(s)

Proxy: Features

– class location is stored in codebase (URL)

• Client communicates with service provider via service proxy: client invokes methods of the proxy object • Client only needs to know interface • Proxy implementation hidden from client

Jini: More Details

• Upon request, stored object is sent to the client as a local proxy of the service • If needed, client retrieves necessary classes

Proxy: Implementation

Client Client Proxy Proxy Communication

Service Service

Client Client Proxy Proxy Comm ication

Service Service

Jini: More Details

• Implementation of service functionality is independent from service interface • Partition of service functionality depends on service implementer’s choice • Parts of or whole functionality may be executed by the client (within the proxy)

Proxy: Implementation Jini: More Details

• When dealing with large volumes of data, it usually makes sense to preprocess parts of or all the data – e.g.: compressing video data before transfer

Client Client Proxy Proxy Communication

Service Service

Client Client Proxy Proxy Comm ication

Service Service

Jini 1.1

– JoinManager, LeaseRenewalManager – Discovery utilities, protocol utilities – ServiceDiscoveryManager & LookupCache

• Helper services – LookupDiscoveryService – EventMailbox – LeaseRenewalService

Jini: More Details

• More classes belong to standard Jini (i.e. net.jini.*), e.g. JoinManager • Helper classes

ServiceDiscoveryManager

– states of LUSes are mirrored: increased communication and memory use – immediate access to available services – usefulness depends on usage scenario, especially useful for frequent and lowlatency queries

Jini: More Details

• Eases handling of multiple lookup services • Supports different access patterns: on-demand, cached, reactive • LookupCache

LookupCache Example

new RMISecurityManager());

Jini: More Details

public class LCExample { public static void main(String[] args) { System.setSecurityManager( Groups, locators, ...

Lease renewal manager [...] ServiceDiscoveryManager sdm = new ServiceDiscoveryManager(null, null); Class[] cl = new Class[] { Print.class }; ServiceTemplate tmpl = Item Filter new ServiceTemplate(null, cl, null); Listener LookupCache cache = sdm.createLookupCache(tmpl, null, null); [...] Print proxy = (Print) cache.lookup(null); [...] } Item Filter }

Overview

– overview

– leasing – distributed events

• RMI/Serialization • Jini infrastructure • Jini services – lookup service – discovery & join protocols – programming example – more details

– transactions – JavaSpaces

• Summary

Jini: Talk Outline

• Jini, what’s that? • Jini programming model – motivation

Leases

– resource usage is restricted to a certain time frame – interaction is modeled by repeatedly expressing interest in some resource: • I’m still interested in X – renew lease periodically – lease renewal can be denied

• I don’t need X anymore – cancel lease or let it expire – lease grantor can use X for something else

Jini: Programming Model

• Lease is contract between two parties • Leases introduce notion of time

Leases • Lease is a contract between two parties • Lease grantor is willing to let lease taker (client) access a certain resource for a certain amount of time • Lease can be extended (renewed) if resource access is still desired – extension can be denied by grantor

• Resource is released upon lease expiration or cancellation (by client)

What To Use Leases For?

– no administration necessary (for removal of stale resource reservations) – e.g. persistent storage, ...

• Distributed “garbage collection” – lease expired → “garbage”

• Inside Jini – registrations with lookup services – resources: transactions, event registrations

Jini: Programming Model

• For allocating hardware and software resources intelligently

Distributed Events

– network failure – crossing of event notifications – late and lost messages

• “publisher/subscriber” model • Architecture: 1. Registration

Subscriber 3. Send notification

Event source

2. Event occurs

Jini: Programming Model

• Objects in a JVM can register interest in certain events of another object in a different (remote) JVM

Distributed Events Jini: Programming Model

• Delivery separated from event semantics • Different delivery behaviors desired by applications, e.g. guaranteed, in-order,… • Interfaces do not reflect particular delivery behavior • Event mechanism can be extended to accommodate different application semantics

Distributed Events (Example)

Lookup Service Proxy, attributes

Management application

Proxy, attributes Proxy, attributes

Registration Events

Jini: Programming Model

• Management application wants to know about printers running out of paper • Gets printer’s proxy object from lookup service and registers for notifications

Distributed Events (Example) Type of event to be notified about (e.g. out of paper).

“handback” is returned to the notified object in every notification. Used to attach arbitrary information to events.

public interface PrinterEvents extends Remote { public EventRegistration register( long eventID, MarshalledObject handback, RemoteEventListener toInform, long leaseLength) throws RemoteException; } Registrations Reference to the are leased.

object to be notified.

Jini: Programming Model

• Printer could implement the interface:

Distributed Events (Example)

public interface RemoteEventListener extends Remote, java.util.EventListener { void notify(RemoteEvent theEvent) throws UnknownEventException, RemoteException; }

• Method notify() will be called for every event

Jini: Programming Model

• Management application (or dedicated listener object) implements interface RemoteEventListener

Distributed Events (Example)

toInform.notify(new RemoteEvent( this, eventID, seqNum, handback)); Recipient

Event source

Event type

Sequence number

Handback

• Event is unambiguously identified by tuple • Notification is synchronous – allows event source to know that event was delivered

Jini: Programming Model

• Printer informs clients about events by sending RemoteEvents

Overview

– overview

– leasing – distributed events

• RMI/Serialization • Jini infrastructure • Jini services – lookup service – discovery & join protocols – programming example – more details

– transactions – JavaSpaces

• Summary

Jini: Talk Outline

• Jini, what’s that? • Jini programming model – motivation

Transactions

– “all or nothing” semantics – operations appear to happen simultaneously (from outside transaction) – method to ensure consistency

• Two-phase commit protocol – method to perform transactions – Two phases: • vote on transaction validity • commit/abort operations

Jini: Transactions

• Transactions encapsulate a number of operations

Transactions – ensures consistency: each transaction participant will ultimately “commit” or “abort” – performs 2PC protocol

• Example: transfer money from one bank account to another

Jini: Transactions

• Central: a manager

Transactions: Properties

– 2PC performed by manager – semantics implemented by participants

Jini: Transactions

• Design goal: maximum flexibility, minimum number of interfaces • Objects must implement certain interface to participate in transactions • Traditionally transaction manager enforces certain semantics (ACID properties) • Jini separates protocol from semantics:

Distributed Transactions in Jini…

– atomicity / consistency / isolation / durability – each participant implements these properties as he sees fit • e.g.: transient objects do not need persistency

– main property is atomicity, other properties are “sometimes” optional

• Transactions are leased from manager

Jini: Transactions

• …are no transactions in a traditional (database) sense • “Lightweight” transaction • ACID properties

Transactions: Participants – coordinates transaction – Jini service – implements interface TransactionManager

• Clients – initiate transactions

• Transaction participants – objects that perform transactional operations – implement interface TransactionParticipant – participation is initiated by join operation

Jini: Transactions

• Transaction manager

Transactions: Semantic Objects

– Java type defines the kind of transaction – class Transaction tells objects to use their standard transaction semantics

• Participants accept only certain transaction types • e.g. DBTransaction – requires database semantics – transient objects not allowed (durability)

Jini: Transactions

• Transactions have no fixed semantics • Participants need to know the type of a transaction Î “semantic objects”

2PC Protocol: Details – get transaction manager from lookup service (lookup TransactionManager) – call to create() starts transaction • usually indirectly via semantic object factory

• Participation in a transaction – participants find out about transaction upon function invocation • receive Transaction object • call transaction manager’s join() method

– implement TransactionParticipant

Jini: Transactions

• Client starts a transaction

2PC Protocol: Details { create(...); –TransactionManager.Created get transaction manager from lookup void commit(...) service (lookup TransactionManager) void abort(...) join(...) –void call to create() starts transaction int getState(...) • usually indirectly via semantic object factory }

• Participation in a transaction

Jini: Transactions

• public Clientinterface starts a TransactionManager transaction

public interface find TransactionParticipant { – participants out about transaction upon void commit(TransactionManager mgr, long id) function invocation void abort(TransactionManager mgr, long id) int •prepare(TransactionManager receive Transaction objectmgr, long id) int prepareAndCommit(TransactionManager mgr, long id) • call transaction manager’s join() method }

– implement TransactionParticipant

JavaSpaces

– implemented completely in Java (and RMI) – interaction with service via local proxy

Jini: JavaSpaces

• Tool for developing distributed applications • Platform for exchanging objects between distributed applications (“shared blackboard”) • “Bag full of objects” • Realizes distributed persistency • Jini service

What To Use JavaSpaces For? – e.g. producer / consumer applications – load-balancing

• Job-oriented view – jobs / events are put into the space and picked up “eventually”, e.g. workflow

• Build-in “good” properties – concurrent access possible – write / read are atomic operations – access within transaction possible

Jini: JavaSpaces

• Models “object flow”

JavaSpaces: Objects

– net.jini.core.entry.Entry – known as Entry interface in Jini – strongly typed by Java type system – two entries of different classes are not equal, even if they encapsulate the same data types • Entry A {Integer, Char} ≠ Entry B {Integer, Char}

• Classes: include data/state and methods Æ behavior

Jini: JavaSpaces

• JavaSpace = “a bag full of objects” • Entries in a JavaSpace service:

Basic Operations: Write • Uses copy of the object, never the object itself • write returns a lease – entry in a JavaSpace has a limited duration – “garbage collection” in a JavaSpace service write(Entry)

Producer

Lease

Java Space

Jini: JavaSpaces

• write puts an entry into a JavaSpace

Basic Operations: Read – exact value match – matches subclasses as well – null matches everything – if more than one match, select and return one entry at random read(Entry)

Producer Renew lease Lease

Java Space

Consumer

Jini: JavaSpaces

• uses template (Entry)

Basic Operations: Read

– read waits until matching entry was found

• take/takeIfExists = read + removal of entry take(Entry)

Producer Renew lease Lease

Java Space

Consumer

Jini: JavaSpaces

• readIfExists returns null if no match found

Basic Operations: Notify

– registration requires a “matching template” – clients implement RemoteEventListener – registration is leased

• Order of notification unspecified – Note: “first come, first serve” for registered listeners on take

Jini: JavaSpaces

• Notify listeners at arrival of certain entries • Uses Jini distributed events • Clients can register with a JavaSpace

Peculiarities

– write/take may cause a RemoteException – meaning: “may or may not have been successful” • write: often unproblematic (may be repeated) • take: entries may be lost • transactions necessary

– example: moving entries between JavaSpaces (e.g. for load balancing) • transactions required

Jini: JavaSpaces

• Operations can be part of a transaction • Entries can be “lost”:

JavaSpaces and Linda – David Gelernter (Yale University)

• Differences: – strong type checking and objects (methods/behavior) • matching on tuple structure, not just data • templates match subclasses as well • all (serializable) data types can be used as data

– multiple spaces possible – leasing – no “eval” – a JavaSpace is just a repository

Jini: JavaSpaces

• Design based on Linda tuple spaces

Overview

– overview

– leasing – distributed events

• RMI/Serialization • Jini infrastructure • Jini services – lookup service – discovery & join protocols – programming example – more details

– transactions – JavaSpaces

• Summary

Jini: Talk Outline

• Jini, what’s that? • Jini programming model – motivation

Summary – everything will be networked – everything will (be able to) communicate – ubiquitous network access – mobility/spontaneity as important paradigms

• Problems: – getting to know the network neighborhood – infrastructure should adapt to devices, not the other way round – distribution: communication, partial failure,...

• Possible solution: Jini

Jini: Summary

• Vision:

Conclusion – simplicity,“less is more” Æ flexibility – discovery, join, lookup – extension of name services by attributes – leases, events, transactions Æ recurring design patterns

• Right direction – ubiquitous networks – mobility, spontaneity

• Individual concepts are not new, but together they offer new possibilities

Jini: Summary

• A number of good ideas

But... – each service usually requires a JVM

• Small devices – JVM and RMI required on device – adaptation to resource-restricted environment necessary (how?) – proxy objects are moved to client (memory)

• Standardized (base) interfaces • What about the competitors (SLP, UPnP, e-speak, ...)?

Jini: Summary

• Resource usage

Problem Areas – important in dynamic environments – user requires • confidentiality: encrypted communication • trust: authentication

– services might use other services on behalf of the user – what about charging for services? – Java RMI security extension does not seem to be the solution

• Scalability – does Jini scale to a global level?

Jini: Summary

• Security

Suggested Reading

• Jini Community: http://www.jini.org • W. Keith Edwards: Core Jini, Prentice Hall, 1999 – good motivation, very detailed – don’t be frightened by more than 700 pages (everything is said at least twice...)

Jini: Summary

• Jini Homepage: http://www.sun.com/jini

Contact Information

Email: [email protected] WWW: http://www.ito.tu-darmstadt.de Slides: http://www.ito.tu-darmstadt.de/ publs/presentations/asama00.pdf

Jini: Summary

Peer Hasselmeyer IT Transfer Office (ITO) Darmstadt University of Technology