Distributed Systems with JINI

1. Distributed Systems with JINI Lincoln Carlton 4/23/01 Parallel and Distributed Systems

2. What is JINI? • No one really know what JINI really stands for. (Anyone know what JAVA stands for?) • JINI is a distributed system based on groups of “Federated” users and resources required by those users. • Overall goal is to provide a flexible, easily administered tool on which resources can found and shared. JINI extends the JAVA environment from a single Virtual Machine to a network of VM’s, with both code and data moving between machines. • Built in security of JAVA platform to allow code to be built on one machine, executed in another • Strong typing to the class level • Allows services to Discover, Join, Detach dynamically from a JINI system.

3. Why JINI? • Today’s N-tier network systems (like DCOM, CORBA or RMI) require that components • know about each other while they are being built • Be evolved lock-step, because interface changes require global synchronization • Require fairly tight administration Seven Fallacies of Networking • The network is reliable • Latency is zero • Bandwidth is secure • Network is secure • Topology doesn’t change • There is one administrator • Transport cost is zero

4. Why JINI? • Move from a N-tier system to a P2P system. • The scale of interactions between peers increases if everyone can communicate with everyone else • The rate of exchange increases • Napster scenario, no one-entity can control the exchange of services JINI absolves some of the networking fallacies • Deals with the unreliability of the network (#1) • Keep up with changing Topology(#5) • Allow multiple administrators…or none!! (#6) • Evolve Components • Take failure seriously and recover from it (Self Healing Networks)

5. A JINI system is composed of... • A set of components that providing an infrastructure for federating services in a distributed system • A programming model that encourages production of reliable distributed services • Services that can be federated to offer functionality to other members of the federation The Overall Goal • Enable users to share services and resources over a network • Provide users easy access to resources over a network while allowing the user to change network locations • Simplify the task of building, maintaining and altering a network of devices, software and users.

6. Key Concepts • Services • Any entity that can be used by a program, user or another service. Examples include printing a document or translating a document from one word-processor format to another. • Lookup Service • Services are found using a lookup. Employs a hierarchical mechanism to allow services to contain lookup services. • RMI • An RPC mechanism that pioneered the ability to move JAVA object from one VM to another. Used by JINI to find and communicate with objects. • Security • Two ideas dominate JINI security: • a principal: Usually a user of the system who is authenticated • an access control list: lists principals or groups of principals allow to access an object

7. Key Concepts • Leasing • All service access in JINI is based on a lease. The access is granted for a timed-interval. Leases can be exclusive or non-exclusive • Transactions • Actions in any number of services may be collected into a single transaction. Two-phase commit ensure that all service action are committed or rolled-back together. • Events • Distributed events allow asynchronous notification between objects with reliability, scalability and interval guarantees.

8. Component Overview • Infrastructure • What is provided by the JINI system to make it work? • Programming Model • What interfaces must be created to integrate with the JINI system? • Services • Combining Infrastructure and Programming Model, create a service for federating device.

9. Infrastructure • Three components compose the base of the JINI system: • Distributed Security enforcing the Principal and ACL security devices across the network • Discovery/Join protocol to allow service to discover, join and advertise their functionality. • Lookup Service service as a repository of services

10. Programming Model • A service must implement base JINI interfaces to integrate with the JINI system: • Leasing interface – ensure accurate set of services are listed • Event and notification interfaces – JavaBeans based notification models • Transaction interfaces – “Voting” phase, commit request • In addition, the service must implement desired functionality (i.e. the Printing service)

11. Services • The JINI infrastructure, defined by the JINI specification, provides the means of sharing code and data between VMs. • The implementation of the Leasing, Event and Transaction interfaces allows service integration in the federation. A Service provides the value-add in the system. For example a printing service, light-switch service, PDA synchronizing service. So how does it all fit together?

12. Service Architecture • Three protocols • Discovery happens when a service is looking for a lookup service to register with. • Join happens when a lookup service is found and a service is added to the federation. • Lookup happens when a client or user needs to locate and invoke a service..

13. Discovery Lookup Service Client Service Service Object Service Attributes

14. Join Lookup Service Service Object Service Attributes Client Service Service Object Service Attributes

15. Lookup Lookup Service Service Object Service Attributes Client Service Service Object Service Attributes

16. Lookup Lookup Service Service Attributes Client Service Service Object Service Object Service Attributes

17. Service Invocation Lookup Service Service Attributes Client Service Service Object Service Object Service Attributes

18. Example Registering and Using a Printer Service

19. Code Examples

20. More Information • Core JINI by Keith Edwards • Various Whitepapers at http://java.sun.com • Questions