1. JINI-1 JINI: A Technology for 21st Century Is it Ready for Prime Time? Prof. Steven A. Demurjian and Dr. Paul Barr Parag Bhogte and Haiying Ren Computer Science & Engineering Department 191 Auditorium Road, Box U-155 The University of Connecticut Storrs, Connecticut 06269-3155 {steve, parag, hyren}@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

2. JINI-2 Overview of Presentation  Component-Based Development  Distributed Development/Emerging Technologies  Sun’s JINI Technology  Background Material on JAVA  What is JINI?  How Does JINI Work?  Comparison with DOC Technologies  Experimental Prototyping Effort  Assumptions and Scenarios  Prototypes: Approach and Results  Future Work  Conclusions and Recommendations

3. JINI-3 What is CBD? CBD: Component-Based Development

4. JINI-4 Supplier /Consumer Model SUPPLY Build New Wrap Existing Buy CONSUME Assemble Applications MANAGE Publish Subscribe Catalog Browse

5. JINI-5 Components vs. Objects  Components  Business Oriented  Coarse Grained  Standards Based  Multiple Interfaces  Provide Services  Fully Encapsulated  Understood by Everyone  Objects  Technology-Oriented  Fine Grained  Language Based  Single Interface  Provide Operations  Use Inheritance  Understood by Developers

6. JINI-6 Specification Implementation Executable Interfaces Component

7. JINI-7 Components as Assets can Grow Complexity of Component

8. JINI-8 Java Client Java Client Legacy Client DB Client COTS Client What is a Distributed Application? Legacy Database Server Legacy COTS Server Database COTS Network Centric Environment High-Availability Performance Heterogeneity Hardware OS, PLs Transparent Interoperation New/Innovative Information Use Increase Productivity Dynamic Environment System of Systems

9. JINI-9 Why Must We Strive for New Techniques and Technologies?  We Must Diverge from Business as Usual  C Programming with RPC  Customized Development without Reuse  Non-Extensible and Non-Evolvable Solutions  Cobbling Together Solutions w/o Method or Reason is Unacceptable and Doomed to Fail!  We Must Face Today’s Realities  Legacy Code is Fact of Life  New Technologies Offer New Challenges  Adopt to Leverage Their Benefits  We Must Draw Careful Balance to Opt for Mature Technologies While Targeting Emerging Technologies with Potential!

10. JINI-10 What are Emerging Technologies for Distributed Computing?  Distributed Object Computing  DCE, CORBA, DCOM/OLE  Middleware for Heterogeneous Hardware and Software Environments  Java Technologies: Platform Independence  Enterprise Java Beans, Java IDL, JDBC  System of Systems via Wrappers/Middleware  Systems are “Components”!  Software Agent Models and Technologies  Mobile Agent Migrates Across Network with Code and Data to Accomplish Required Tasks  How Will Technologies (JINI, CORBA, Agents, etc.) Work Together?

11. JINI-11 What are Basic JINI Concepts?  JINI Lookup Service Maintains Registry for Available Services of Distributed Application  Resources Provide Services that Register and Join with JINI Lookup Service  Clients Discover and Utilize Services Based on Interface of Services  Ask Lookup for RegisterForCourse(CSE900)  Return Proxy for Execution of Service  Location of Service Transparent to Client  Locations of Clients, Services, Lookup Service, etc., can Change over Time  Conceptually, JINI Similar Distributed OS with Dynamically Definable/Changeable Resources

12. JINI-12 Goals of Research Effort  Can JINI Support Highly-Available Distributed Applications?  Can Replicated Database Services be Registered and Available for Use by Clients?  Can JINI Support a Network-Centric Environment with Dynamic Clients and Services?  Will Clients Continue to Operate Effectively if Replicated Databases Services Fail?  Can JINI be Utilized to Maintain “minutes-off” Data Consistency of Replicas?  Is JINI Easy to Learn and Use?  What is Maturity Level of JINI Technology?  Is JINI Ready for Prime Time???

13. JINI-13 Background Material on JAVA Java Visualization Java is a Third Generation, General Purpose, Platform Independent, Concurrent, Class-Based, Object-Oriented Language and Environment

14. JINI-14 Sun’s JINI Technology  JINI is a Sophisticated Java API  Construct Distributed Applications Using JINI by  Federating Groups of Users  Resources Provide Services (Database Access, Printing, Real-Time Sensor) for Users  JINI and Stakeholders  Core of Technologies to Architect, Design, Implement, and Test Distributed Applications  Construct Software “Resistant” to Failure  JINI and Users  High Availability Through Redundancy  Dynamic Responses to User Requests Regardless of Network & Resource Changes

15. JINI-15 Sun’s JINI Technology Key JINI Concepts and Terms  A Resource Provides a Set of Services for Use by Clients (Users) and Other Resources (Services)  A Service is Similar to a Public Method  Exportable - Analogous to API  Any Entity Utilized by Person or Program  Samples Include:  Computation, Persistent Store, Printer, Sensor  Software Filter, Real-Time Data Source  Anything that is Relevant for Your Domain!  Services: Concrete Interfaces of Components  Services Register with Lookup Service  Clearinghouse for Resources to Register Services and Clients to Locate Services

16. JINI-16 Sun’s JINI Technology Resources & Services JINI Lookup Service Printer Resource Service Object Service Attributes PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob Class and Methods Define Services to be Registered Register Services  Sun’s Initial Perspective  JINI for Hardware  Printers, Digital Cameras, etc.  Plug-and-Play on Network  PrinterActions Class Defines the “Component” that is Registered with JINI

17. JINI-17 Sun’s JINI Technology Key JINI Concepts and Terms  Registration of Services via Leasing Mechanism  Resource Leases Services to Lookup Service  Resources Renew Services Prior to Expiration  If not, Services Become Unavailable  Lookup Service Maintains Registry  Limit Availability of Services Based on Time, Workload, User Requirements, etc.  Services as Available “Components”  Leasing Supports High-Availability  Registration and Renewal Process  Upon Failure, Services Removed from Registry  Clients, Resources, Lookup Can Occupy Same or Different Computing Nodes

18. JINI-18 JINI Lookup Service Printer Resource Service Object Service Attributes Leasing/Lease Renewal PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob Class and Methods Define Services to be Registered Sun’s JINI Technology Registration & Leasing  FOREVER or EXPIRATION DATE (millisecs)  Renewal Must Occur Prior to Expiration  JINI Provides Lease Renewal Manager to Allow Resource to Delegate Renewal Responsibility Lease for 5 minutes (3000000 msec) Must Renew Before 5 Minutes Expire If Not Renewed, Lookup Removes If Failure, Lookup May Still Supply Service Until Expiration (5 mins) Client MUST be SMART!

19. JINI-19 Sun’s JINI Technology Support for Distributed Computing Legacy COTS Database Legacy COTS Database Resources Provide Services Java Client Java Client Legacy Client Database Client COTS Client Clients Using Services JINI Lookup Service JINI Lookup Service Redundant Lookups

20. JINI-20 Component Perspective and JINI  Resources as Components  Resources Provide Services  What Service Provides: Component Interface  Clients, Servers, Resources, Use Component Interface to Design/Construct Functionality Legacy COTS Legacy COTSDatabase Java Client JINI Lookup Service Constructed via Services of Legacy, COTS, Database, etc. Lookup Registered Services Functionality via Service Reuse Services as Component APIs

21. JINI-21 Sun’s JINI Technology Key JINI Concepts and Terms  For Users, JINI Offers  Sharing of Resources (Services) over Network  Location Transparency of Users and Services  Support Dynamic Behavior of Users  For Stakeholders, JINI Provides  Infrastructure for Federating Services in Distributed Setting  Programming Model to Register & Discover Services  Availability of Services Throughout Distributed Setting Leading to Ease in Constructing, Maintaining, and Evolving Network Centric Applications

22. JINI-22 Sun’s JINI Technology What is JINI?  An Infrastructure for Network Centric Applications in Spontaneous Environment  Clients Enter/Leave Network Unpredictably  Resources and Services Enter/Leave due to Failure, Redundancy, Topology Change  Both Typify Enterprise Applications  Goals of JINI  Plug-and-Play (Components) of Clients and Services  No HW/SW Distinction: Everything a Service  Enable Spontaneous Network Applications  Architecture where Services Define Function  Strive for Easy to Use/Understand Technology

23. JINI-23 Sun’s JINI Technology Overall Computing Architecture and JINI.

24. JINI-24 Sun’s JINI Technology Components and Dependencies Infrastructure Programming Model Services Base Java Java VM RMI Java Security Java APIs JavaBeans JNDI Enterprise Beans JTS JMS Java + JINI Discovery/Join Leasing Transaction Manager Distributed Security TransactionsJavaSpaces LookupEventsLookup service

25. JINI-25 Sun’s JINI Technology How Does JINI Work?  Distributed Application Constructed Using One or More Lookup Services  Lookup Service Support Interactions by “Advertise”  Resources: “Advertise” Services Discover, Register Services, Renew Lease Services as “Components” “Locate/Utilize”  Client: “Locate/Utilize” Services Discover, Search for Services, Invocation  Multiple Lookup Services  Resources Responsible for Registering All  Clients Interact with Multiple Lookups  Discovery Initiates Process for Client or Resource

26. JINI-26 Sun’s JINI Technology Discovery by Resource & Client Client JINI Lookup Service Resource Service Object Service Attributes JINI Lookup Service Discovery to Register Services Discovery to Locate Services

27. JINI-27 Sun’s JINI Technology How Does JINI Work?  Resources Discover and Join Lookup Service  When Resources Leave or Fail to Renew Leases  Lookup Service Must Adjust Registry  Time Lag Between Departure and Removal of Services from Registry  What Happens When Client Receives Service Just Prior to Failure?  Utilization of Java Exception Handling  Client Code Written to Dynamically Adapt  Resource Register  Services on Class-by-Class Basis  Service Object (Java API - Method Signatures)  Optional Descriptive Service Attributes

28. JINI-28 Sun’s JINI Technology Join, Lookup, and Service Invocation Client Resource Service Object Service Attributes Lookup Service Request Service AddCourse(CSE900) Return Service Proxy to AddCourse( ) JoinJoin Register & Lease Services CourseDB Class Contains Method AddCourse ( ) 1. Client Invokes AddCourse(CSE900) on Resource 2. Resource Returns Status of Invocation Service Invocation via Proxy by Transparent RMI Call Service Object Service Attributes Registry of Entries

29. JINI-29 Experimental Prototyping Effort Goals and Objectives  High Availability of Services and Data  Volatility of Resources, Clients, and Network  Clients Rely on Lookup Service to Locate and Execute Services Against Replicated Resources  Databases Replicated in Multiple Workstations  Redundant Services Available if Failure  “Minutes-Off” Allowed - Sync Over Time  No Lost Updates During Modification Process  Characteristics of Enterprise Applications  Movement of Clients/Reconfigure Networks  Need for Data Availability on Demand  Receive “Current” Data if Client/Resource Plugs Back In

30. JINI-30 Experimental Prototyping Effort Assumptions and Scenario  Employ University Application  Person and Course Database Repositories  Students Query Course Information  Faculty Query, Change, Create Schedule  Authentication and Authorization  Analogous to Tasks in Many Domains  Client Java GUI for University Application Correspond to New Java GUI for Domain  Resource Java Application for Database Resource Legacy Relational Database in a Domain  Prototyping Environment: 3 NT 400 Mz. PCs  JINI 1.0 and JDK/JRE 2 v1.2.2  Visual Café 3.0 and Microsoft Access

31. JINI-31 Experimental Prototypes Rapid, Incremental Design/Development  First Prototype: Explore JINI and Develop Baseline University Application: Single Computer  Second Prototype:Client and Services Spread to Two Computers: Lookup with Database Services  Third Prototype: Extend Second to Multiple Clients and Three Computers  Fourth and Fifth Prototypes  Single Client, Three Replicated Databases  Change in One Replica Propagation to Others  Testing of Replica Failures on Application  Fifth: Multiple Clients/Simultaneous Updates  Sixth Prototype: Extends Fifth Prototype with Pre- Lookup Services for Locking During Updates

32. JINI-32 Prototype One  Functionality:  One GUI Client/One Database Resource (and its Services)  Microsoft Access for PersonDB & CourseDB  Client, Services, and JINI Lookup Service All Run on the Same NT Workstation  Achievements: Learned Basic Concepts of JINI  Installed JDK1.2, JINI 1.0, &Visual Café 3.0  Establish Environment Variables and Setup Information for Visual Café and JINI  Use of JINI’s Services GUI to Start Httpd, Rmid and Lookup Services  JDBC/ODBC to Connect to MS Access DB

33. JINI-33 Prototype Two and Three  Functionality:  Distributes the Client and Database Resource (and its Services) on Multiple NT Workstations  Lookup Service Runs on the Same Workstation as Database  Fully Functional GUI Client for Course Access  Prototype Three Extends Two with Multiple Clients  Purposes:  Verify Whether the Same JINI Concepts Function Across Multiple Nodes (Two)  Insure That Multiple Clients Can Interact With the Same Lookup Service (Three)

34. JINI-34 Block Diagram for Prototype Three 1. Get services from Course DB 2. Service List Proxies 3. Invoke addCourse(CSE900) Discover, Join, Reg. Services PersonDB Class verifyUser CourseDB Class getClasses getClassDescription preReqCourse getVacantClasses addCourse removeCourse updateCourse Client1Client2 JINI Lookup Service Database Resource Client3 One NT Another NT

35. JINI-35 Services Console

36. JINI-36 Services GUI

37. JINI-37 User Login Screen

38. JINI-38 Add Course

39. JINI-39Confirmation

40. JINI-40 Course Information

41. JINI-41 Results from Prototype Two and Three  Achievements:  Upgrade to Visual Café 3.0c  Full-fledged Application with All Types of Queries (Select, Insert, Update and Delete)  Use of Broadcast Discovery to Locate the Lookup Server Running on Another Machine  Use of Proxy to Allow the Client to Connect to MS Access DB on the Server Machine  Drawbacks:  Does Not Have Replicated Database Resource  No Experimentation with Failure of Database Resource

42. JINI-42 Aside: Important Lesson Learned!  PT One Downloaded Service Code for DB Access  Transition to PT Two Invalidated Code  Downloaded Code Attempted to Access DB that was No Longer Local  Downloaded Code  Requires All Assets Local  Sophisticated Enough for Inter-Computer Access  Why is Downloading Code a Terrible Idea?  Limits Extensibility, Introduces Domain Specificity, Yields Difficult to Maintain Code  Service no Longer Abstract Conceptual Unit  If Need to Move Code - Mobile Agents  Limited Bandwidth - RMI is Preferred

43. JINI-43 Prototype Four  Functionality:  One Client, Three Replicated Database Resources, and One JINI Lookup Service  Client, Resources, Lookup on Three NTs  Purposes:  Verify that a Single Client Can Interact With One of the Replicas  Attempt Registration of Redundant Replicated Database Services for High-Availability  Demonstrate that the Changes to Replica are Forwarded to All Other Replicas  Experiment With Failure by Taking Down One and then Two Replicas

44. JINI-44 Services in Prototype Four Discover, Join, Register Services for Client Client JINI Lookup Service Database (copy 3) Database (copy 2) Database (copy 1) Services to Update Replicas addCourse2 removeCourse2 updateCourse2 One NT Another NT PersonDB Class verifyUser CourseDB Class getClasses getClassDescription preReqCourse getVacantClasses addCourse removeCourse updateCourse

45. JINI-45 Execution in Prototype Four 1. Get Services for CourseDB 2. Service List Proxies 4. Get Services for CourseDB Client JINI Lookup Service Database (copy 3) Database (copy 2) Database (copy 1) 6a. Invoke addCourse2(CSE900) 6b. Invoke addCourse2(CSE900) 7. Notify Completion of Service Invocation 3. Invoke addCourse(CSE900) 5. Service List Proxies

46. JINI-46 Add Course GUI ACTION CAUSES addCourse(CSE900) TO BE EXECUTED ON ONE PRIMARY DATABASE RESOUCE AND MIGRATED FROM THERE TO THE OTHER TWO REPLICAS

47. JINI-47 Prototype Five  Functionality:  Expand Prototype Four with Three Clients/Three Replicated DB Services  Single Lookup Service Runs on One of the NT Workstations  Client Receives Needed Services from All Resources Upon Discovery  Simultaneous Updates of All Replicas by Client  Purposes:  Eliminate Database Interactions  Attempt to Improve Database Consistency  Test Resource Availability During Failure

48. JINI-48 Execution in Prototype Five Client1 Database (copy 3) Database (copy 2) Database (copy 1) JINI Lookup Service 1. Get Services for CourseDB 2. Service List Proxies 3. Invoke addCourse(CSE900) 4. Invoke addCourse(CSE900) 5. Invoke addCourse(CSE900)

49. JINI-49 Results from Prototype Four and Five  Achievements:  Same Services Can be Registered With Lookup  Client Can Request and Utilize All Replicated Services in Registry  Client Can Function As Long As at Least One of the Replicated Database Resources is Alive  Consistency of Databases is Preserved  Prototype 4: Replica Updates other Replicas  Prototype 5: Client Updates All Replicas  Drawbacks:  Registry Currency Problem During Failure  Multiple Clients Can Modify Same Data  Lost Update Possible if Multiple Clients

50. JINI-50 Prototype Six  Functionality:  Incorporate Pre-Lookup Service that Insures Only One Client Updates Replicas  Use a Exclusive Write/Simultaneous Reads Protocol  Client Interacts with Pre-Lookup Service to “Request” Locks  Client Then Asks Lookup Service for Services  Client Receives and Updates All Replicas  Purpose:  Bootstrap: Use JINI to Solve Update Problem  Eliminate Consistency Problems Across Replicas by Locking Databases During Update

51. JINI-51 Services in Prototype Six Discover, Join, Reg. Services for Client Lock UnLock getClientID addService rmvService Client1 JINI Lookup Service Database (copy 3) Database (copy 2) Database (copy 1) Pre-Lookup Service Client2 Client3

52. JINI-52 Order to Start Application Start 6th, 7th, 8th Register/Ask permission Back to JINI Clients Start 2nd Register Pre-Lookup Service Start 1st JINI Lookup Service Start 3rd, 4th, 5th Register Database Replicas

53. JINI-53 Execution Process in Prototype Six Client1 JINI Lookup Service Database (copy 3) Database (copy 2) Database (copy 1) Pre-Lookup Service 3. Get Services for CourseDB 4. Service List Proxies 1. Request Update Lock 8. Release Lock 2. Granted or Wait 5. Invoke addCourse(CSE900) 6. Invoke addCourse(CSE900) 7. Invoke addCourse(CSE900)

54. JINI-54 Pre-Lookup when Two Replicated Database Resources Register TWO DATABASE RESOURCES ARE INTERACTING WITH THE PRE-LOOKUP TO … Register Services from DALMATION & SHEPARD: getClassDescription, preReqCourse, updateCourse, removeCourse, addCourse, getVacantClasses, getClasses

55. JINI-55 Pre-Lookup when Client Invokes “addCourse” Service CLIENT BEING GRANTED ACCESS TO addCourse SERVICE ON DALMATION & SHEPARD

56. JINI-56 Client Passed Through Pre-Lookup CLIENT INTERACTING WITH PRE-LOOKUP ANNOUNCING PRESENCE: User found ESTABLISHING IDENTIFIER READ REQUEST: NO LOCK NECESSARY

57. JINI-57 Client Locked by Pre-Lookup CLIENT INTERACTING WITH PRE-LOOKUP ANNOUNCING PRESENCE: User found ESTABLISHING IDENTIFIER WAITING FOR AND OBTAINING LOCK ON CSE900 I’m waiting for the service I’m using the DBServer … 2 DBServers are found

58. JINI-58 Results from Prototype Six  Achievements:  Any Number of Clients Can Do the Read Operation on the Database  Only One Client Can Modify a Replicated Database Resource at a Given Point of Time  Pre-Lookup Service Can be Modified to Support other Locking Protocols  Drawbacks:  Can’t Force Stakeholders to Consult Pre- Lookup Service - Rely on SW Practice  No Redundant Lookup/Pre-Lookup Services  Failure of Lookup/Pre-Lookup - Total Restart  No Logging and Recovery When Replicated Server Application Fails and is Restarted

59. JINI-59 Experimental Prototyping Effort Future Work Possibilities  Experimentation with Leasing and Failure  Failure of Database Resource with Forever Lease Required 5 mins. to Update Registry  Experiment with Lease Capabilities and Improve Client Code to Process Exceptions  Logging and Recovery After Failure  Limit Availability of Sensitive Data  Verification of Write-Once-Run Anywhere  Extend Prototype 6 to  Win95, 98, NT, and Solaris Hardware  Other Database Resources (Sybase, Oracle, …)  CRITICAL for Comprehensive Evaluation of JINI’s Readiness for 21st Century!

60. JINI-60 Experimental Prototyping Effort Future Work Possibilities  Explore Other JINI Capabilities  Group/Bind Clients to “Close” Lookup  Consistency: Transactions/Two-Phase Commit  Experiment with JINI Security Model for Granting/Denial of Services (Ongoing Project)  Response, Consistency, Authorization  Alternative Locking Protocols for Pre-Lookup  Write Excludes Reading/Granularity of Locks  Fine Tune Access to Data  Redundant Pre-Lookup/JINI Lookup Services  Significantly Increases Client/Resource Code  Nesting and Interactions of Lookup Services  Extend Replication for Applications

61. JINI-61 Experimental Prototyping Effort Future Work Possibilities  JavaSpaces: An API that Extends JINI with  Shared Persistent Object Space, Distributed Data Structures, Synchronization Techniques, Message Passing and Channels  Evaluate Yet-Another Emerging Technology  Performance Analyses for Prototyping Efforts  Unclear on Impact of UConn Local Network  Evaluate Heterogeneous Prototypes  Software Agents and JINI  Ongoing Project this Semester  Two Grad Students  Can Technologies Work Together?

62. JINI-62 Conclusions and Recommendations Revisiting Goals of Research Effort  Can JINI Support Highly-Available Distributed Applications?  Strongly Demonstrated by PTs 4, 5 and 6  Architect Highly Available Solutions via JINI  Results Basis for Further Investigation  Can Replicated Database Services be Registered and Available for Use by Clients?  PT 4 with Multiple DB Resources  PTs 5 and 5 with Multiple Clients  JINI Lookup Service Distinguishes Between “Same” Services from “Different” Resources  Clients Treat Services as Component APIs!

63. JINI-63 Conclusions and Recommendations Revisiting Goals of Research Effort  Can JINI Support a Network-Centric Environment with Dynamic Clients and Services? Will Clients Continue to Operate Effectively if Replicated Databases Services Fail?  Yes, PTs 4, 5, 6 All Support Starting and Stopping of Clients and Database Resources  JINI Needs Time to Remove “Old” Services  Upgrade Client Software Appropriately  Can JINI be Utilized to Maintain “minutes-off” Data Consistency of Replicas?  Demonstrated in Varying Degrees by PTs  PT 6 Superior Due to Pre-Lookup Service Guarantee of No Lost Updates

64. JINI-64 Conclusions and Recommendations Is JINI Ready for Prime Time???  Compatibility of JINI with Java  Homogeneity of JINI and Java Unlike ORBs and IDL which are Heterogeneous  Demonstration of  GUI Client as “New” Java Application  Microsoft Access Wrapped with JDBC/ODBC as a Legacy Database  But - Verify Across Heterogeneous HW/SW  Commitment of Sun to Java/JINI  Keynote Address by Bill Joy Touts Strong Commitment to Java and JINI  Distributed Computing with JINI is Future  But - Danger of Evolving Technologies

65. JINI-65 Conclusions and Recommendations Is JINI Ready for Prime Time???  Track Record of Java and Sun  Java’s Increasing Dominance in Agents, E- Commerce, EJB, Data Mining, etc.  But - Incompatibility of Java Releases  Understandability and Ease of Use of JINI  400 Hours Total for Obtaining Familiarity with JINI, Visual Café, JDBC/ODBC, 6 PTs, etc.  Faster Speed Up w.r.t. CORBA/ORB  High-Level Abstraction of JINI  UML Modeling for Distr./Real-Time Design  Characterize JINI Architecture/Design  Transition to Visual Café  Promote Software Engineering and Rigor!

66. JINI-66 Conclusions and Recommendations Important Caveats  Future Work Clearly Indicate that More Effort is Required to Tilt Scales Toward JINI  Work Extensive w.r.t. JINI Technologies  Potential Role of JavaSpaces  Experiences on Whole Positive  Leasing Issues Need to be Explored  Impact of Registry Currency on Clients  Continued Evolution of JINI Specification  Will JINI 1.1 be Compatible with JINI 1.0?  Java has Had Compatibility Problems in Past (Deprecated APIs)  Conclusion: JINI Great Promise as a Successful Technology in 21st Century!