1 / 46

JINI Design and Principles Ranjita Bhagwan CSE225: High-Performance Distributed Computing

JINI Design and Principles Ranjita Bhagwan CSE225: High-Performance Distributed Computing. What is Jini?. A distributed computing environment for Network Plug and Play . A system to provide services easily and transparently over the network.

roy
Download Presentation

JINI Design and Principles Ranjita Bhagwan CSE225: High-Performance Distributed Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. JINI Design and Principles Ranjita Bhagwan CSE225: High-Performance Distributed Computing

  2. What is Jini? • A distributed computing environment for Network Plug and Play. • A system to provide services easily and transparently over the network. • A system that can be “dynamic” - users and resources can come and go as they please with minimal administrative overhead.

  3. Jini’s goals • Provide shared service and resources. • Provide easy access to resources in spite of changing network location of users. • Simplifying system and network management. • Not yet a platform for a parallel programming environment – more of a “plug and play” mechanism than a metacomputing infrastructure.

  4. Jini Architecture

  5. Service Locator Service Client Jini Components • Service – an entity used by a person, program or another service. • Service Locator/Lookup Service – keeps track of services and their properties and provides the Lookup Service. • Client – uses the services.

  6. Service • An object (or set of objects) located in a server which can be used by a user, program or another service. • An application can be viewed as a collection of services – different from regular object-oriented view. • More localized notion than Globus service, which can be distributed over a number of hosts.

  7. FileClassifier SmartViewer getMIMEType() DisplayService TextDisplay display() ImageDisplay display() display() Small Example

  8. FileClassifierProxy ImageDisplayProxy TextDisplayProxy Example SmartViewer User FileClassifierService FileClassifierProxy Service ImageDisplayProxy ImageDisplayService Service TextDisplayService Service locator Service

  9. Lookup Service • Service is added to the Lookup Service by a pair of protocols • Discovery: Service locates the lookup service. • Join: Service joins the lookup service. • Server “discovers” the service locator • Unicast TCP if location of service locator is known. • Multicast UDPif location of service locator is not known. • May include other Lookup Services for hierarchical lookup. Discovery/Join & Lookup

  10. service registrar Object Serialization is used to move the service object to the Service Locator. Service Registration Service Server Service Locator service Discovery/Join & Lookup

  11. service service registrar Object Deserialization is used at the client to recreate the object. registrar Client Lookup Service Locator Client Discovery/Join & Lookup

  12. Entries and Groups • Entries: A service may specify certain properties. • For a plain text editor, entries = {(“plain/text”)} • A client may specify the properties it requires of the service. • A matching of all specified entry fields is performed with the services on the service locator. • Relational operators (>,<, etc) not supported! • Serialized entries are compared. • Groups: A service can specify which groups it belongs to. • Groups = {“CSE, UCSD”, “ECE, UCSD”) Discovery/Join & Lookup

  13. Service Proxies • Toaster, Printer, etc. cannot perform their services remotely. • So, service sends out a “proxy”. • The proxy communicates with the service. • The proxy is told its server’s location when it is created. Service Locator Client Service Service Proxy Service Service Proxy Registrar Registrar Discovery/Join & Lookup

  14. Jini Architecture

  15. Leasing: request and grant • The service requests that its copy be kept on the service locator for a given amount of time. • ANY: service locator determines lease time. • FOREVER: request for a lease that never expires. • The service locator grants the lease and specifies how long it stays valid. • Default for SUN = 5 seconds. Leasing

  16. Leasing: Expiry • “Quiet” expiration: no notification from the service locator to the service. • The service has to renew the lease before it expires. • Problem: high network latency may cause lease to expire before it is renewed. • The Lease Renewal Manager quietly renews leases at regular intervals. Leasing

  17. Jini Architecture

  18. Security • Based on JDK 1.2 security model. • Uses a text based policy file to set security policy. • If an all permissive policy is used, a malicious service, masquerading as a requested service may run on the client. Security

  19. JDK 1.2 Security • Grant permission only for certain activities, such as access to certain files for reading, writing and execution. • Grant access only to particular hosts, subdomains or domains. • Require digital signatures attached to code. Security

  20. Security problems for a client http server proxy class files service locator client service proxy instance data Security

  21. A Policy that restricts attacks Grant permissions to Application code based on the codesource. If you suspect these might be tampered with, get them signed. Security

  22. A Policy that restricts attacks Grant permission to Jini core classes based on the codesource. These may be signed if need be. Security

  23. A Policy that restricts attacks Grant permission to downloaded code only if it is signed by an authority you trust. Even then, grant only the minimum permission that is needed to perform the service’s task. Security

  24. Security challenges • security should be strong but easily managed so that the ease of use of Jini does not disappear. • In ad-hoc networks, when services may not have a fixed identity, how do you decide who is “trusted” and who is not? Security

  25. Jini Architecture

  26. Transactions • A series of operations within a single service or involving multiple services. • ACID properties • Atomicity • Consistency • Isolation • Durability • Jini uses the two-phase commit method. Transactions

  27. Two-phase commit • Mechanism • All participants in a transaction “vote” on it. • If all agree to go ahead, transaction commits. • If any of them abort during the voting stage, the transaction aborts on all participants. • Jini supplies the mechanism, but policies are left to the participants. Transactions

  28. get cost An example txnmanager accounts client service Transactions

  29. cost An example txnmanager accounts client service Transactions

  30. create An example txnmanager accounts client service Transactions

  31. An example txnmanager accounts client service txn Transactions

  32. credit An example txnmanager accounts client service txn Transactions

  33. An example txnmanager accounts client service txn credit debit Transactions

  34. join An example txnmanager accounts client service txn Transactions

  35. join An example txnmanager accounts client service txn Transactions

  36. request service An example txnmanager accounts client service txn Transactions

  37. result An example txnmanager accounts client service txn Transactions

  38. commit An example txnmanager accounts client service txn Transactions

  39. prepare An example txnmanager accounts client service txn Transactions

  40. commit An example txnmanager accounts client service txn Transactions

  41. commit An example txnmanager accounts client service txn Transactions

  42. Related Technologies • HAVi • JetSend by Hewlett-Packard • Bluetooth • Inferno by Lucent • Universal Plug and Play

  43. JINI v/s UPnP “Sun officials this morning said Universal Plug and Play is behind Jini in development terms, and criticized it for being "PC-centric" and thus tied to the Microsoft operating system. Microsoft has countered that for Jini to work, thousands of applications will have to be rewritten in Java and Jini code.”

  44. Non-technical Issues • July 1998: Jini was introduced. • “Jini products will be out by mid 1999.” • Jan 1999: Around 30 partners to the Jini technology were announced. • “Jini products will be out by late1999.” • Are they out yet?

  45. Jini Products • It is claimed that e-commerce and web-based applications are overshadowing Jini product development. • Jini product prototypes are being developed by a number of companies – HP, 3Com, Cisco, Sony, Nokia, etc.

  46. Concerns • Security!!! • Common interface development • All printers should ideally use the same interface. • Does not as yet support XML, which UPnP does(will do). • Needs JAVA VM to run on every device to avoid large delays: this means large memory requirements. • Possible solution: Dallas semiconductors’ JAVA VM on a chip. • Needs all applications to be coded in Java. • All manufacturers have to accept Java as their programming language. • Scalability issues

More Related