Jini Overview and Specification

1. Jini Overview and Specification Presented by Jas, Alvin & Chris CSE 291-B May 29, 2003

2. Jini - Introduction • Jini technology allows devices to dynamically establish communication to share and exchange services across a network. • Provides simple mechanisms which enable devices to plug together to form an impromptu community (federation) • Lesson in Political Science: In a federation, most power lies in local authorities. Federal authorities ensure that local authorities work together. • Each device provides services that other devices in the community may use. • These devices provide their own interfaces which ensure reliability & compatibility.

3. Jini - Introduction • Jini is an extension of Java • Java consists of one virtual machine • Jini is a kind of virtual network • Jini Devices must have processing power or memory. • Otherwise controlled by another device. • Relies on existence of a network of “reasonable” speed connecting these devices.

4. Key Concepts • Services • An Entity used by person, program, or another service. May be a computation, storage, a communication channel, etc. You know…a service! • Jini system consists of services that can be collected to perform a particular task. • Services can be dynamically added or withdrawn from the system as needed. • Services Communicate using a service protocol which is a set of interfaces written in Java.

5. Key Concepts • Lookup Service • Major point of contact between users of the system and the system. • Finds and adds services to the Jini Federation • Maps functionality to a set of objects in Jini that actually implement the service • Can include other lookup services (hierarchy) • Can for bridges to other lookup services. • Services added using two protocols • Discovery – locates appropriate lookup service • Join – join lookup service.

6. Key Concepts • Java RMI • Provides communication between services • Extension to normal remote procedure call. • Passes not only data, but entire objects and code. • Provides Simplicity • Code can be encapsulated in an object and can be passed from service to service.

7. Key Concepts • Leasing • Access to many services are lease based. • Guarantees access to a service for a negotiated period of time. • Services can be exclusive or non-exclusive. • Transactions • A series of operations to be performed. • Within a single service or spanning multiple services.

8. Key Concepts • Security • Built on the twin notions of a principal and an access control list. • Jini services are accessed on behalf of some entity (principal) which traces back to a user of the system. • Check object’s access control list to determine permissions to use a particular service.

9. Key Concepts • Events • Ability to notify objects when a particular event occurs. • Could trigger new task/transaction

10. Components • Three main components • Infrastructure • Programming Model • Services • Tend to get blurred, but just an extension of the virtual machine concept.

11. Components • Infrastructure • Discovery & Join Protocol • Define way services become part of Jini System • Java RMI • Base language with which services communicate • Security Model • Define how entities are identified and how they get rights to perform actions. • Lookup Service • Marketplace for finding and offering services. • Entries in Lookup Service are objects written in Java. Objects can be downloaded and act as local proxies.

12. Components • Programming Model • Sets of interfaces designed to extend the usual single virtual machine model. • Leasing Interfaces • Adds time-based interface to resources. • Event and Notification Interfaces • Enable event-based communication between services

13. Components • Programming Model (Cont) • Transaction Interfaces • Coordinates the actions of a group of distributed objects in a two phase system • Voting Phase • An object votes on whether it has completed it portion of a task and is ready to commit. • Commit Phase • Coordinator issues a commit request to each object.

14. Components • Services • Consist of objects coded in Java • Can be made up of other objects • Has an interface that defines what a service is capable of doing

15. A Closer Look at JINI • Similar Technologies • Limitations of JINI • Case Studies • Current Status

16. Similar Technologies • UPnP, Salutation, NINJA • Common Object Request Broker Architecture • CORBA is a specification for a Distributed Object System • RMI vs CORBA • performance and portability tradeoffs • Distributed Objects vs Distributed Services • Can be used in complementary fashion?

17. Using CORBA with JINI

18. Limitations: Service Lookups • Lookup Servers vs Name Servers • Query by service or name • Exact Matching • ServiceTemplate / ServiceRegistrar provide limited expressiveness (i.e. for range queries) • Fault-tolerance • No defined policies for system recovery

19. Limitations: Low-Resource Hosts • Servers: Sun’s reference implementation of Lookup Service consumes 3 MB storage • Clients: Limitedness of lookup interface can require a lot of unnecessary overhead • Is this really a problem (given the success stories)?

20. Case Studies: Who uses it? • Quantum • Seagate • 3COM • Cisco • Xerox • Novell • Nokia • Philips • Sony • Motorola • Kodak • Sharp • Canon • Siemens • Toshiba • Samsung • Kinko’s • Hewlett Packard • AOL • Adaptive Networks • Ericsson

21. Case Studies: Success Stories • 4D Networks: Application Services for the Web Built on Jini Network Technology. • Appropria: Jini Technology Brings Mission-critical Information Out of the Silo. • Entegrity Solutions: Major Online E-commerce and Enterprise Solutions Company Rely on Jini Network Technology for Secure E-Commerce. • Eko: Jini Technology connects medical data and equipment dynamically and reliably. • FETISH Federation: Jini Network Technology Links Online Travel Services. • Lightflow: Jini Network Technology Adds "High Touch" to Online Shopping. • Maui High Performance Computing Center: Sun Architects Jini Network Technology Infrastructure for Military Simulations. • Procoma: An Innovative Solution for Commerzbank AG with Jini Technology. • Raytheon: Open, Adaptive, Self-Healing Architecture for DD21. • U.S. Army: Reliable Battlefield Communication Using Jini Connection Technology.

22. Case Studies: Success Stories (cont.) • “We believe that the Jini and Java technologies will dramatically change the way DD 21 and future Navy systems are developed. The spontaneous community capabilities of Jini will lead to much more reliable, capable and maintainable systems. The development and integration cycle will be reduced significantly, and the use of commercial components will finally be cost-effective.”-- Lead Systems Engineer for DD21, Raytheon • "The cost of manually implementing what Jini network technology is providing us would have been prohibitive both from an actual cost perspective (person-hours to build) and time perspective (time to market)," said Horvath. "Jini technology's increasingly mature and well-documented capabilities would be very difficult to reproduce. The use of Jini technology allows our team to stay focused on the problem space of AssureDelivery, and not on implementation details of the underlying distributed service." -- Director of Product Development, Entegrity Corp.

23. Current Status • Increased Deployment: “Jini Technology Licensees, Including Heartlab Inc, Templar Corp, Valaran Corp, FETISH Federation, and Cysive Inc., Turn to Jini Technology to Address Dynamic Networking Challenges” (May 7, 2003) • Standardization:“Jini Community Approves the ServiceUI API”(May 7, 2003)

24. Current Status (cont.) • Open Issues: • Network Scalability: In theory, a JINI systerm can scale if it uses a hierarchy of lookup servers (like DNS), but no actual ‘wide area’ JINI network has been deployed. But is this even relevant? • Generality: Can well-defined interfaces be established for all types of services besides simple examples like printers and cameras?

25. Jini & SensorNets Can they benefit from each other?

26. Benefits of Jini on SensorNets • Sensor networks could benefit from having a virtual machine on each platform so that not every platform required special code • Allows for single deployments with multiple sensing applications • Dynamic addition/removal of services • As platforms with newer sensors come onboard, the network would automatically adapt to support them

27. Divergences • Jini seems to imply high connectivity and high bandwidth • Code is dynamically downloaded to the node • Currently, this is too much to expect from nodes • Jini makes no attempt to address power consumption issues • Asynchronous communication implies the radio be on most of the time • Automatic discovery and handshaking looks costly • Perhaps this is why Jini hasn’t taken off—most embedded devices are on a power conscious diet

28. Future Work • Since they expect Jini to take off for embedded devices which have significant power constraints, Jini should be made aware of these constraints • Should prioritize the needs in sensor networks and eliminate “marketing” features found in Jini

29. Discussion Questions • Should sensornets adapt and conform to Jini-like standards or should sensornets use a simplified version of Jini? • How much overhead is acceptable for sensor networks in terms of communication and computation? • Can virtual machines be made to have virtually no overhead and still be powerful?