Overview of Jini CS Fall 2000 Jason I. Hong

Motivation Coordination framework –Simple, seamless, and scalable interoperability –Network "plug and play" with minimum admin –Networked software and hardware provide services –Any device can find and use existing services Example scenarios –"Find all nearby color duplex printers" –"Start brewing coffee five minutes before my alarm clock goes off" –"Let my cell phone use the car speakers"

Networ k One Way Scenarios Might Be Done Today Networ k Alarm Clock Service Coffee Maker Desktop PC Cell Phone Stereo Speaker Service Printer Service Networ k

What Jini Proposes Lookup service Coffee Maker Desktop PC Alarm Clock Service Stereo Speaker Service Printer Service Network Cell Phone

What Jini Provides Middleware interfaces + implementations Programming model for distributed services Federating and using services Core to Jini is lookup service –Service for registering, finding, and leasing other services –Uses a well-known multicast address

Service Registration Lookup service Network Alarm Clock Service 1. Find Lookup Service 2. Return stub to lookup 3. Return stub to service

Service Leasing Lookup service Network Alarm Clock Service 1. Find Lookup Service Coffee Maker 2. Return stub to lookup 3. Query for service 4. Service returned Find interface Printer (duplex=yes, color=yes)

Using Services Lookup service Network Alarm Clock Service Coffee Maker Can use any protocol to communicate to service (or stub can contain service itself!)

Some Cool Things with Jini Can form ensembles of lookup services –Pass requests up hierarchy (like DNS) Leasing model handles service failures Flexible search on properties Distributed transactions (two-phase) Distributed events

Some Problems with Jini Requires a priori knowledge of service interface –Everyone must agree on same service interface –Ex. "Printer" and "Speakers" interface Currently requires Java VMs everywhere –Needs lots of memory and processor power Complexity of code

Some More Problems with Jini No good way to attach user interfaces Lack of security mechanisms Single point of failure for service lookup

Competing Technologies Universal Plug and Play (UPnP) –Aim is to be independent of OS, language, and physical medium –UPnP relies on well-defined XML data formats and HTTP-based protocols –Jini relies on well-defined Java interfaces –UPnP philosophy: different APIs for each platform (no code download, higher startup, more reliable?) –Jini philosophy: "Write Once Run Anywhere" (code download, low startup, but less reliable?)

Competing Technologies Salutation –Aim is to be independent of vendors and network architectures (ex. Java, UDP, TCP/IP, HTTP) –Aim for platform, OS, and network independence –All service functions mediated by Salutation Manager –Completely open and nonproprietary architecture –Small footprint –Point-to-point service discovery (but can also do directory-based too)

Further Reading Jini Specification Jini Developers Universal Plug and Play Salutation