Download PPT 97 - University of Connecticut

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
JINI-1
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!
JINI-2
What is a Distributed Application?
System of Systems
Heterogeneity
Hardware
OS, PLs
Network Centric Environment
DB Client
Legacy
Client
Legacy
Database
COTS
Dynamic
Environment
High-Availability
Performance
Java
Client
Server
Server
Legacy
Java
Client
Database
COTS
COTS
Client
Increase Productivity
New/Innovative
Transparent Interoperation
Information Use
JINI-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
JINI-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
 Who Uses What When and for How Long?
JINI-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!
JINI-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
JINI-7
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
JINI-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???
JINI-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: Component-Based Development
Experimental Prototyping Effort
 Assumptions and Scenarios
 Prototypes: Approach and Results
 Future Work
Conclusions and Recommendations
JINI-10
Background Material on JAVA
Java Visualization
Java is a Third Generation, General Purpose, Platform
Independent, Concurrent, Class-Based, Object-Oriented
Language and Environment
JINI-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();
JINI-12
Background Material on JAVA
Block Diagram for RMI


Java Objects in JVMs (on Different Computers)
Transparently Invoke Each Other's Methods
RMI Enables Distributed Object Computing
Client
Server
HelloImpl
HelloApplet
5
1
2
Stub
Stub
Skel
Unmarshall
Marshall
NDR
Transport
Hello
NDR
rmic HelloImpl.java
3
Skel
Unmarshall Marshall
RMI Layer
NDR
Start rmiregistery
Transport
Transport
NDR
Transport
4
JINI-13
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
JINI-14
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


JINI-15
Sun’s JINI Technology
Resources & Services
JINI
Lookup
Service


Register
Services
Printer Resource
Service Object
Service Attributes
Sun’s Initial Perspective
 JINI for Hardware
Class and
Methods
 Printers, Digital
Define
Cameras, etc.
Services
 Plug-and-Play on
to be
Network
PrinterActions Class Defines Registered
the “Component” that is
Registered with JINI
PrinterActions Class
enqueuePrintJob
dequeuePrintJob
getPrinterStatus
getPrinterType
installPrinter
removePrinter
startJob
cancelJob
JINI-16
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
JINI-17
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
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!
Printer Resource
Service Object
Service Attributes
Class and
Methods
Define
Services
to be
Registered
PrinterActions Class
enqueuePrintJob
dequeuePrintJob
getPrinterStatus
getPrinterType
installPrinter
removePrinter
startJob
cancelJob
JINI-18
Sun’s JINI Technology
Support for Distributed Computing
Clients
Using
Services
JINI Lookup
Service
Redundant
Lookups
Java
Client
Database
Legacy
Resources
Provide
Services
COTS
Java
Client
Legacy
Legacy
Client
COTS
Database
Client
COTS
Client
Database
JINI Lookup
Service
Legacy
COTS
JINI-19
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
Java
Client
Constructed via Services of
Legacy, COTS, Database, etc.
Lookup Registered Services
Functionality via Service Reuse
Services as Component APIs
Legacy
COTS
JINI
Lookup
Service
Database
Legacy
COTS
JINI-20
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)
JINI-21
What Does an Actual System Look Like?
Java
GUI
UDB Client
UDBServer Service
GetClasses();
PreReqCourse();
GetVacantClasses();
EnrollCourse();
AddCourse();
RemoveCourse();
Java
GUI
MDB Client
JINI
Lookup
Service
MDBServer
GetParts
GetRequisition
GetReqParts
WriteParts
WriteRequisition
DeletePart
DeleteRequisition
AddParts
RemovePart
AddRequisition
University DB
Resource (UDB)
Military
Requisition
DB
Resource
JINI-22
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
JINI-23
Execution Process of Client using JINI
1 Register_Client(Harris,Security Off., Military)
Military
Client
4 Return Result,Create_Token(Security Off., Token)
2 Verify_UR(Harris, Security Off.)
5. Discover/Lookup(MilitaryDb,Modification,
CreateRequisition) Returns Proxy to Military Client
6 CreateRequisition(Token, Tank Details, Harris)
11 Return Result,CreateRequisition(…)
Lookup
Service
Security
Registration
Services
3 Client OK?
USR
Security
Authorization
Services
7 IsClient_Registered(Token)
9 Check_Privileges(Token, MilitaryDb, Modification,
CreateRequisition, [Tank Details, Harris])
MilitaryDB
Resource
8 Return Result of IsClient_Registered(…)
Security
Policy
Services
10 Return Result of Check_Privileges(…)
JINI-24
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
 Availability of Services Throughout Distributed
Setting
Leading to Ease in Constructing, Maintaining, and
Evolving Network Centric Applications
JINI-25
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 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
JINI-26
Sun’s JINI Technology
Overall Computing Architecture and JINI.
JINI-27
Sun’s JINI Technology
Components and Dependencies
Base
Java
Infrastructure
Programming
Model
Services
Java VM
Java APIs
JNDI
RMI
JavaBeans
Enterprise Beans
Java Security
JTS
JMS
Java +
JINI
Discovery/Join
Leasing
Distributed
Security
Lookup
Transactions
Transaction
Manager
JavaSpaces
Events
Lookup service
JINI-28
Sun’s JINI Technology
How Does JINI Work?




Distributed Application Constructed Using One or
More Lookup Services
Lookup Service Support Interactions by
 Resources: “Advertise” Services
Discover, Register Services, Renew Lease
 Client: “Locate/Utilize” Services
Discover, 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
JINI-29
Sun’s JINI Technology
Discovery by Resource & Client
JINI
Lookup
Service
Discovery to
Locate Services
JINI
Lookup
Service
Discovery to
Register Services
Resource
Client
Service Object
Service Attributes
JINI-30
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
JINI-31
Sun’s JINI Technology
Join, Lookup, and Service Invocation
Request
Service
AddCourse(CSE900)
Lookup Service
Registry of Entries
Return
Service
Proxy to
AddCourse( )
Client
Service Object
Service Attributes
J Register & Lease Services
CourseDB Class
o
i Contains Method
AddCourse ( )
n
Service Invocation via Proxy
by Transparent RMI Call
Resource
Service Object
Service Attributes
1. Client Invokes AddCourse(CSE900) on Resource
2. Resource Returns Status of Invocation
JINI-32
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
JINI-33
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
JINI-34
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 PreLookup Services for Locking During Updates
JINI-35
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
JINI-36
Services Console
JINI-37
Services GUI
JINI-38
Executing the Database Resource
The DBServer Console
JINI-39
GUIClient Console
JINI-40
User Login Screen
JINI-41
Invalid Login
JINI-42
Select Semester
JINI-43
List of Courses
JINI-44
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 JINI’s 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
JINI-45
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)
JINI-46
Another NT
Block Diagram for Prototype Three
Client1
1. Get services from
Course DB
2. Service
List Proxies
3. Invoke
addCourse(CSE900)
Client2
Client3
JINI
Lookup
Service
Discover, Join,
Reg. Services
Database
Resource
PersonDB Class
verifyUser
CourseDB Class
getClasses
getClassDescription
preReqCourse
getVacantClasses
addCourse
removeCourse
updateCourse
One NT
JINI-47
Add Course
JINI-48
Confirmation
JINI-49
Course Information
JINI-50
Delete Course
JINI-51
Update Course
JINI-52
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
JINI-53
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
JINI-54
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
JINI-55
Services in Prototype Four
Services
to Update
Replicas
addCourse2
removeCourse2
updateCourse2
Database
(copy 1)
Another NT
Database
(copy 2)
Discover,
Join,
Register
Services
for Client
PersonDB Class
verifyUser
CourseDB Class
getClasses
getClassDescription
preReqCourse
getVacantClasses
addCourse
removeCourse
updateCourse
Database
(copy 3)
Another NT
Client
JINI
Lookup
Service
One NT
JINI-56
Execution in Prototype Four
1. Get Services
for CourseDB
Client
2. Service List
Proxies
3. Invoke
addCourse(CSE900)
JINI
Lookup
Service
4. Get Services
for CourseDB
5. Service
List Proxies
7. Notify Completion of Service Invocation
6a. Invoke
addCourse2(CSE900)
Database
(copy 1)
Database
(copy 3)
6b. Invoke
addCourse2(CSE900)
Database
(copy 2)
JINI-57
Add Course
GUI ACTION CAUSES addCourse(CSE900)
TO BE EXECUTED ON ONE PRIMARY DATABASE
RESOUCE AND MIGRATED FROM
THERE TO THE OTHER TWO REPLICAS
JINI-58
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
JINI-59
Execution in Prototype Five
Client1
1. Get Services for CourseDB
2. Service List
Proxies
3. Invoke
4. Invoke
addCourse(CSE900) addCourse(CSE900)
Database
(copy 1)
Database
(copy 2)
JINI
Lookup
Service
5. Invoke
addCourse(CSE900)
Database
(copy 3)
JINI-60
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
JINI-61
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
JINI-62
Services in Prototype Six
Pre-Lookup
Service
Client1
Discover, Join,
Reg. Services
for Client
Client2
Lock
UnLock
getClientID
addService
rmvService
JINI
Lookup
Service
Client3
Database
(copy 1)
Database
(copy 2)
Database
(copy 3)
JINI-63
Order to Start Application
Start
6th, 7th, 8th
Register/Ask permission
Clients
Pre-Lookup Start
2nd
Service
Back to JINI
Register
JINI
Start
1st Lookup
Register
Service
Register
Database Start
Replicas 3rd, 4th, 5th
JINI-64
Execution Process in Prototype Six
1. Request
Update Lock
Client1
8. Release
Lock
2. Granted or Wait
Pre-Lookup
Service
3. Get Services for CourseDB
4. Service List
Proxies
5. Invoke
6. Invoke
addCourse(CSE900) addCourse(CSE900)
Database
(copy 1)
Database
(copy 2)
JINI
Lookup
Service
7. Invoke
addCourse(CSE900)
Database
(copy 3)
JINI-65
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
JINI-66
Pre-Lookup when Client Invokes
“addCourse” Service
CLIENT BEING GRANTED ACCESS TO addCourse
SERVICE ON DALMATION & SHEPARD
JINI-67
Client Passed Through Pre-Lookup
CLIENT INTERACTING WITH PRE-LOOKUP
ANNOUNCING PRESENCE: User found
ESTABLISHING IDENTIFIER
READ REQUEST: NO LOCK NECESSARY
JINI-68
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
JINI-69
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 PreLookup 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
JINI-70
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 JINI’s Readiness for Army Systems!
JINI-71
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
JINI-72
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?
JINI-73
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!
JINI-74
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
JINI-75
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


JINI-76
Conclusions and Recommendations
Is JINI Ready for Prime Time???



Track Record of Java and Sun
 Java’s Increasing Dominance in Agents, ECommerce, 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!
JINI-77
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!
JINI-78