1. Bond-Jini Interoperability
Mathew Lowery
This project will allow for limited communication between the Bond and Jini distributed object systems.

2. Goals Bond Jini Framework for distributed agents Jini lookup service
Ability to move around
Ability to save execution state
Jini
Jini lookup service
Ability to form federations dynamically
Bond has slightly different goals than Jini in that it was built to support a specific type of object called an agent. Agents are intelligent objects.
Bond gives agents the ability to move from JVM to JVM.
Bond also allows for execution state of an agent to be saved and restarted at a later time.
At the heart of Jini is the lookup service. It allows client objects to find objects that offer services.
At runtime, objects form virtual networks or federations in which a complex task can be carried out.

3. Implementations Bond Jini Message passing (asynchronous)
Lookup based on aliases
Jini
Method invocation (synchronous)
Lookup based on type
The implementation of the two distributed object systems are very different.
Bond
Message passing – allows objects to communicate through space and time
Lookup – Bond has a “directory” which maps bondID to an alias
Jini – Jini builds on top of Java RMI; all the distributed functionality lies in RMI; Jini just adds the dynamic lookup
Method invocation – method callers block until results are returned
Lookup – Jini’s lookup service maps RMI stubs to types (Java interfaces)

4. Bond-Jini Communication
Bond-Jini communication using Bond protocols (bondObject)
Bond-Jini communication using Jini protocols (UnicastRemoteObject)
We can divide communication between the systems into two categories. Protocols are the ones that provide the distributed functionality.
Bond protocols – In this case, both objects are bondObjects. The base bondObject provides the communication functionality.
Jini protocols – In this case, both objects are UnicastRemoteObjects.

5. Bond server in Jini network
Bond object
Jini client object
Jini lookup service
register
method calls
Jini server object
lookup
Stub of Jini server object
Since both networks require the objects involved to subclass base classes, an object that works in both networks is not easily created.
Instead, an existing object from one network will need to be augmented to work in the other network.
Shown in this slide is a Bond object which has a Jini object that registers its services in a Jini lookup service. Next a client object gets a stub to the registered object. Then the server object passes along method calls to the Bond object. In this way the Bond object behaves synchronously when offering or consuming services on a Jini network.
method calls

6. Jini server in Bond network
KQML messages
Bond client object
Bond object
Bond object
Jini stub
find
addAlias
Bond directory
Not shown is the Jini lookup service where the Bond object got the Jini stub object.
Here a Bond object queries a lookup service for a stub. Next that Bond object registers in the Bond directory. It is now available to handle client requests. A Bond client queries the directory. It then sends KQML messages to the Bond object. That bond object is responsible for translating that message into an RMI call.
We could have easily just bypassed the Bond wrapper but then every object that needs the Jini services would need Jini lookup code.
Also, this setup allows a Jini service to behave asynchronously without knowing it.
method calls
Stub of Jini server object
Jini server object
method calls