JINI: A Technology for 21st Century Is It Ready for Prime Time? - PowerPoint PPT Presentation

About This Presentation
Title:

JINI: A Technology for 21st Century Is It Ready for Prime Time?

Description:

JINI-1. JINI: A Technology for 21st Century. Is It Ready for Prime Time? ... Cobbling Together Solutions w/o Method or Reason is Unacceptable and Doomed to Fail! ... – PowerPoint PPT presentation

Number of Views:130
Avg rating:3.0/5.0
Slides: 79
Provided by: stevenad
Category:

less

Transcript and Presenter's Notes

Title: JINI: A Technology for 21st Century Is It Ready for Prime Time?


1
JINI A Technology for 21st CenturyIs 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_at_engr.uconn.edu http//www.en
gr.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
What is a Distributed Application?
Network Centric Environment
System of Systems
High-Availability
Performance
Heterogeneity Hardware OS, PLs
Dynamic Environment
Increase Productivity
New/Innovative Information Use
Transparent Interoperation
4
Why is Distributed Computing Needed?
  • Todays 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

5
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
  • Who Uses What When and for How Long?

6
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 Arent Extensible and Evolvable
  • Cobbling Together Solutions w/o Method or Reason
    is Unacceptable and Doomed to Fail!
  • We Must Face Todays 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!

7
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

8
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 to Distributed OS with
    Dynamically Definable/Changeable Resources

9
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???

10
Overview of Presentation
  • Brief Review Background Material on JAVA
  • What is Java?
  • Object Serialization
  • Remote Method Invocation
  • Suns JINI Technology
  • What is JINI?
  • How Does JINI Work?
  • Comparison Component-Based Development
  • Experimental Prototyping Effort
  • Assumptions and Scenarios
  • Prototypes Approach and Results
  • Future Work
  • Conclusions and Recommendations

11
Background Material on JAVA Java Visualization
Java is a Third Generation, General Purpose,
Platform Independent, Concurrent, Class-Based,
Object-Oriented Language and Environment
12
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",
"CSE 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()
13
Background Material on JAVABlock Diagram for RMI
  • Java Objects in JVMs (on Different Computers)
    Transparently Invoke Each Other's Methods
  • RMI Enables Distributed Object Computing

Start rmiregistery
14
Suns 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
Suns 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, 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
Suns JINI TechnologyResources Services
JINI Lookup Service
  • Suns 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
Suns JINI TechnologyKey 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
Suns JINI TechnologyRegistration Leasing
  • 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!
19
Suns JINI TechnologySupport for Distributed
Computing
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

JINI Lookup Service
21
Two Example Resources
  • University Application
  • Students can Register/Drop Courses and Check the
    Schedule/Catalog
  • Faculty can Alter Course DB and Check the
    Schedule/Catalog
  • Military Application - Database of Parts
  • Ability to Requisition/Add/Delete Parts
  • Different User Authority Based on Rank
  • For Both
  • Client to JINI to Discover Services
  • Client to Resource for Method Invocation
    (Resembles RMI)

22
What Does an Actual System Look Like?
Java GUI UDB Client
Java GUI MDB Client
MDBServer GetParts GetRequisition GetReqParts Writ
eParts WriteRequisition DeletePart DeleteRequisiti
on AddParts RemovePart AddRequisition
UDBServer Service GetClasses() PreReqCourse() Ge
tVacantClasses() EnrollCourse() AddCourse() Rem
oveCourse()
JINI Lookup Service
University DB Resource (UDB)
Military Requisition DB Resource
23
Services of Military Application
  • Query Service
  • GetParts Queries DB for Parts
  • GetRequisition Queries DB for Requisition
  • GetReqParts All Requisition Details for a
    Particular Part
  • Update Service
  • WriteParts Store Part to DB
  • WriteRequisition Requisition Changes to DB
  • DeletePart Deletes Part from DB
  • DeleteRequisition Deletes Requisition from DB
  • Other Services/Methods Omitted
  • Notice These are Just Public Methods Organized
    into Logical Groupings
  • JINI Allows Searching of Groupings by Service

24
Execution Process of Client using JINI
25
Suns 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
  • Availability of Services Throughout Distributed
    Setting
  • Leading to Ease in Constructing, Maintaining,
    and Evolving Network Centric Applications

26
Suns 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

27
Suns JINI Technology Overall Computing
Architecture and JINI.
28
Suns JINI Technology Components and Dependencies
Programming Model
Services
Infrastructure
Base Java
Java VM
Java APIs
JNDI
RMI
JavaBeans
Enterprise Beans
Java Security
JTS
JMS
Java JINI
29
Suns 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

30
Suns JINI TechnologyDiscovery by Resource
Client
JINI Lookup Service
JINI Lookup Service
Discovery to Register Services
Discovery to Locate Services
Client
31
Suns 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

32
Suns JINI TechnologyJoin, Lookup, and Service
Invocation
Lookup Service
Registry of Entries
Client
1. Client Invokes AddCourse(CSE900) on
Resource 2. Resource Returns Status of Invocation
33
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

34
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 ApplicationCorresp
    ond to New Java GUI for Domain
  • Resource Java Application for Database
    ResourceLegacy 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

35
Experimental PrototypesRapid, Incremental
Design/Development
  • First Prototype Explore JINI and Develop
    Baseline University Application Single Computer
  • Second PrototypeClient 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

36
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
  • Purposes
  • Learn about Various Technologies
  • Verify Installation of Jini1.0, JDK 2 v1.2.2,
    Visual Cafe3.0
  • Retrieve Data From MS Access DB Using Java
    Program - This is the Database Resource!
  • Build a Client/Services Application

37
Services Console
38
Services GUI
39
Executing the Database ResourceThe DBServer
Console
40
GUIClient Console
41
User Login Screen
42
Invalid Login
43
Select Semester
44
List of Courses
45
Results from Prototype One
  • Achievements
  • Learned the Basic Concepts of JINI
  • Proper Installation of JDK1.2, JINI 1.0, and
    Visual Café 3.0
  • Establish Environment Variables and Setup
    Information for Visual Café and JINI
  • Use of JINIs Services GUI to Start Httpd, Rmid
    and Lookup Services
  • JDBC/ODBC to Connect to MS Access DB
  • Drawbacks
  • Application Runs on Single Workstation
  • No Usage of Proxies - Direct Database Calls from
    Client to Microsoft Access

46
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)

47
Block Diagram for Prototype Three
PersonDB Class verifyUser CourseDB Class
getClasses getClassDescription
preReqCourse getVacantClasses
addCourse removeCourse updateCourse
Discover, Join, Reg. Services
48
Add Course
49
Confirmation
50
Course Information
51
Delete Course
52
Update Course
53
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

54
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

55
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

56
Services in Prototype Four
Discover, Join, Register Services for Client
Services to Update Replicas addCourse2 removeC
ourse2 updateCourse2
57
Execution in Prototype Four
Client
JINI Lookup Service
Database (copy 3)
Database (copy 2)
Database (copy 1)
58
Add Course
GUI ACTION CAUSES addCourse(CSE900) TO BE
EXECUTED ON ONE PRIMARY DATABASE RESOUCE AND
MIGRATED FROM THERE TO THE OTHER TWO REPLICAS
59
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

60
Execution in Prototype Five
Client1
JINI Lookup Service
Database (copy 3)
Database (copy 2)
Database (copy 1)
61
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

62
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

63
Services in Prototype Six
Client1
Pre-Lookup Service
Client2
Client3
JINI Lookup Service
Database (copy 3)
Database (copy 2)
Database (copy 1)
64
Order to Start Application
65
Execution Process in Prototype Six
8. Release Lock
66
Pre-Lookup when Two Replicated Database Resources
Register
TWO DATABASE RESOURCES ARE INTERACTINGWITH THE
PRE-LOOKUP TO Register Services from
DALMATION SHEPARD getClassDescription,
preReqCourse, updateCourse, removeCourse,
addCourse, getVacantClasses, getClasses
67
Pre-Lookup when Client Invokes addCourse Service
CLIENT BEING GRANTED ACCESS TO addCourse SERVICE
ON DALMATION SHEPARD
68
Client Passed Through Pre-Lookup
CLIENT INTERACTING WITH PRE-LOOKUP ANNOUNCING
PRESENCE User found ESTABLISHING IDENTIFIER READ
REQUEST NO LOCK NECESSARY
69
Client Locked by Pre-Lookup
CLIENT INTERACTING WITH PRE-LOOKUP ANNOUNCING
PRESENCE User found ESTABLISHING
IDENTIFIER WAITING FOR AND OBTAINING LOCK ON
CSE900 Im waiting for the service Im
using the DBServer 2 DBServers are found
70
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
  • Cant 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

71
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 Army 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 JINIs
    Readiness for Army Systems!

72
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 Army Data
  • Redundant Pre-Lookup/JINI Lookup Services
  • Significantly Increases Client/Resource Code
  • Nesting and Interactions of Lookup Services
  • Extend Replication for Army Applications

73
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?

74
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!

75
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

76
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

77
Conclusions and Recommendations Is JINI Ready
for Prime Time???
  • Track Record of Java and Sun
  • Javas 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!

78
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!
Write a Comment
User Comments (0)
About PowerShow.com