Location-independent distributed object references via UUID proxy
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional remote procedure call systems fail to locate remote objects that have been moved, as they tightly couple object identity with location, making it impossible for client programs to find the object if it changes machines or becomes disconnected from the network.
Innovation Solution
Location-independent references are created using a proxy object with a universally unique identifier (UUID) that allows clients to obtain a new reference to the remote object by accessing identifier directories, which map UUIDs to updated locations, enabling method calls even after object movement.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional remote procedure call systems use location-dependent references, then the reference structure is simple and direct, but the system cannot locate remote objects that have been moved to different machines
Solution Approach 1:
The reference is segmented into two distinct parts: a location-independent UUID that identifies the remote object globally, and a location-dependent live reference that points to the current machine and port. This segmentation allows the system to separate object identity from object location, enabling the reference to remain valid even when the object moves to a different machine.
Solution Approach 2:
The UUID acts as an intermediary between the client and the remote object's current location. Instead of directly embedding the machine and port numbers in the reference, the system uses the UUID to look up the current location through the proxy object and identifier directory, allowing the reference to remain location-independent while still enabling object location.
2Adaptability or versatility
If the reference contains machine and port number information, then method calls can be made directly, but the reference becomes invalid when the object moves location
Solution Approach 1:
The reference structure is made dynamic through the proxy object, which automatically updates the live reference component based on the remote object's current location. When the remote object moves to a different machine, the proxy object detects this change and retrieves the new location information from the identifier directory, updating the reference without requiring client intervention.
Solution Approach 2:
The system implements feedback through the proxy object, which continuously monitors the remote object's location status. When the remote object moves or becomes unavailable, the proxy object receives feedback about this change and automatically refreshes the live reference by querying the identifier directory with the UUID, ensuring the reference remains current and functional.
3Reliability
If the system uses secondary active references for object activation, then object mobility is partially supported, but the system fails when the original machine no longer exists on the network
Solution Approach 1:
The UUID serves as a universal, location-independent identifier that works across all machines and network configurations. Unlike conventional systems that rely on machine-specific references or tombstone mechanisms, the UUID provides a single, consistent identifier that remains valid regardless of which machine hosts the remote object, enabling truly universal object mobility across the entire network.
Data Source
AI summary
Location-independent references include a live reference containing a location of a remote object and a universally unique identifier (UUID) which provides a unique global reference to that remote object. If a method call to the remote object using the live reference fails, the UUID is used to obtain a new reference to the remote object and the new reference is then used to make another method call. A new reference can be obtained from an identifier directory that contains a mapping between UUIDs and location-independent references. When a remote object is first created, or when a remote object is moved from one location to another, the remote object registers with any and all such directories that it can find in its environment. These registrations are leased; that is, if they are not occasionally refreshed by the remote object which registered them, they are dropped from the directory.