JINI: Evaluating the Technology & Impact on Present & Future Army Systems

1. JINI: Evaluating the Technology & Impacton Present & Future Army Systems 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. What is a Distributed Application? • Distributed Computing/Applications are … • Systems of Systems • Interoperation of New & Existing Applications • Legacy, Databases, COTS, New Clients, etc. • Network Centric Environment • Distributed Computing Applications must … • Manage, Control, Access, and Modify Data • Allow Humans to Interact with Data • Provide High-Availability and Performance • Evolvable Over Time • Present & Future Army Systems Exhibit All of These Characteristics and More!

3. Why is Distributed Computing Needed? • Today’s Environments Contain Applications … • Created with Multiple Prog. Languages • Executing on Heterogeneous Platforms • Locally and Geographically Distributed • Distributed Computing Applications Must … • Allow Seamless and Transparent Interoperation • Provide Tools for Engineers and Users • Result: Inter-Operating Environment • Utilize Information in New/Innovative Ways • Leveraged to Increase Productivity • Support Diverse User Activities • Dynamically Respond to Changes

4. Who are the Players in Distributed Computing? • Stakeholders • Software Architects (Requirements) • System Designers (Solutions) • Application Builders (Implementation) • Stakeholders Striving to Provide … • System Interaction and Information Exchange • Utilization of Existing Applications in New and Innovative Ways • End-Users at Various Skill Levels and with Specific and Limited Access Requirements • Novice vs. Adept vs. Expert • Division vs. Brigade vs. Battalion • Who Uses What When and for How Long?

5. Why Must We Strive for New Techniques and Technologies? • We Must Diverge from Business as Usual • C Programming with RPC • Customized Development without Reuse • Solutions that Aren’t Extensible and Evolvable • 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!

6. What are Emerging Technologies for Distributed Computing? • Distributed Object Computing (DOC) • DCE, CORBA, DCOM/OLE • Middleware for Heterogeneous Hardware and Software Environments • Java Technologies • Platform Independent Language/Environment • Enterprise Java Beans, Java IDL, JDBC • Wrappers, Middleware, File Services to Bring Together “System of Systems” • Software Agent Models and Technologies • A Mobile Agent is Application Capable of Migrating Across Network with Code and Data to Accomplish Required Tasks

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

8. 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???

9. Overview of Presentation • Brief Review: Background Material on JAVA • What is Java? • Object Serialization • Remote Method Invocation • Sun’s JINI Technology • 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

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

11. Background Material on JAVA Object Serialization • Object Serialization is a Bi-directional Process of • Writing an Object (Save in Serialized form) • Reading an Object (Reconstruct Serialized) • Used in: • Remote Method Invocation (RMI) • Exchange of Information Across Network • // Serialize • Person p = new Person ("Steve", "CS&E UConn"); • FileOutputStream f = new FileOutputStream("tmp"); • ObjectOutputStream s = new ObjectOutputStream(f); • s.writeObject(i); • // Deserialize • FileInputStream in = new FileInputStream("tmp"); • ObjectInputStream s = new ObjectInputStream(in); • Person p = (Person)s.readObject();

12. Background Material on JAVABlock Diagram for RMI Client Server Hello HelloImpl HelloApplet rmic HelloImpl.java 3 5 1 2 Stub Stub Skel Skel Unmarshall Marshall Unmarshall Marshall RMI Layer NDR NDR NDR NDR Transport Transport Transport Transport 4 • Java Objects in JVMs (on Different Computers) Transparently Invoke Each Other's Methods • RMI Enables Distributed Object Computing Start rmiregistery

13. Sun’s JINI Technology • JINI is a Sophisticated Java API • Construct Distributed Applications Using JINI by • Federating Groups of Users (Army Personnel) • Resources Provide Services (Weather Data, Map Overlays, Logistics Data)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

14. Sun’s JINI TechnologyKey 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, Comm. Channel • Software Filter, Real-Time Data Source • Sensor or Probe, Hardware (Printer, Display, etc.) • Logistics Data, Weather Data, Map Overlays • Services Register with Lookup Service • Clearinghouse for Resources to Register Services and Clients to Locate Services

15. Sun’s JINI TechnologyResources & Services Register Services PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob Class and Methods Define Services to be Registered Printer Resource Service Object Service Attributes • Sun’s Initial Perspective • JINI for Hardware • Printers, Digital Cameras, etc. • Plug-and-Play on Network • Our Intent • Evaluate Effectiveness for Software JINI Lookup Service

16. Sun’s JINI TechnologyKey JINI Concepts and Terms • Registrationof Services via Leasing Mechanism • Resource Leases Services to Lookup Service • Leases are Forever or with Expirations • Resources Renew Services Prior to Expiration • If not, Services Become Unavailable • Lookup Service Maintains Registry • Logistics Data Only Available at Start of Battle & During Specific, Preset Time-slices • Leasing Supports High-Availability • Registration and Renewal Process • Upon Failure, Services Removed from Registry • Clients, Resources, Lookup Can Occupy Same or Different Computing Nodes

17. Sun’s JINI TechnologyRegistration & Leasing Printer Resource PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob Class and Methods Define Services to be Registered Service Object Service Attributes • FOREVER or EXPIRATION DATE (millisecs) • Renewal Must Occur Prior to Expiration • JINI Provides Lease Renewal Manager to Allow Resource to Delegate Renewal Responsibility JINI Lookup Service Leasing/Lease Renewal 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!

18. Sun’s JINI TechnologySupport for Distributed Computing Redundant Lookups Clients Using Services JINI Lookup Service Java Client Resources Provide Services Database Legacy Legacy COTS Java Client Legacy Client Network COTS Database Client Legacy Database COTS Client JINI Lookup Service COTS

19. 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 • Both Critical for “Moving” Personnel • For Stakeholders, JINI Provides • Infrastructure for Federating Services in Distributed Setting • Programming Model to Register & Discover Services • Availabilityof Services Throughout Distributed Setting Leading to Ease in Constructing, Maintaining, and Evolving Network Centric Applications

20. Sun’s JINI TechnologyWhat 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 Present/Future Army Systems • Goals of JINI • Plug-and-Play of Clients and Services • Erasing Hardware/Software Distinction: Everything is a Service • Enable Spontaneous Network Applications • Architecture where Services Define Function • Strive for Easy to Use/Understand Technology

21. Sun’s JINI Technology Overall Computing Architecture and JINI.

22. Sun’s JINI Technology Components and Dependencies Leasing Transaction Manager Discovery/Join Transactions JavaSpaces Distributed Security Lookup Events Lookup service Programming Model Services Infrastructure Base Java Java VM Java APIs JNDI RMI JavaBeans Enterprise Beans Java Security JTS JMS Java + JINI

23. Sun’s JINI TechnologyHow Does JINI Work? • Distributed Application Constructed Using One or More Lookup Services • Lookup Service Support Interactions by • Resources: “Advertise” ServicesDiscover, Register Services, Renew Lease • Client: “Locate/Utilize” ServicesDiscover, Search for Services, Invocation • Multiple Lookup Services • Resources Responsible for Registering All • Clients Interact with Multiple Lookups • Stakeholders Must Write “Apropos” Code • Discovery Initiates Process for Client or Resource

24. Sun’s JINI TechnologyDiscovery by Resource & Client Resource Service Object Service Attributes JINI Lookup Service JINI Lookup Service Discovery to Register Services Discovery to Locate Services Client

25. Sun’s JINI TechnologyHow 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

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

27. 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 • Present/Future Army Systems • Movement of Clients/Reconfigure Networks • Need for Data Availability on Demand • Receive “Current” Data if Client/Resource Plugs Back In

28. 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 Army Domain • Client Java GUI for University ApplicationCorrespond to New Java GUI for Army Appl. • Resource Java Application for Database ResourceLegacy Relational Database in Army Appl. • Prototyping Environment: 3 NT 400 Mz. PCs • JINI 1.0 and JDK/JRE 2 v1.2.2 • Visual Café 3.0 and Microsoft Access

29. Experimental PrototypesRapid, 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

30. 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

31. 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)

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

33. Services Console

34. Services GUI

35. User Login Screen

36. Add Course

37. Confirmation

38. Course Information

39. 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

40. 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

41. 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

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

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

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

45. 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

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

47. 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

48. 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

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

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