Bond objects

The Bond environment uses a special type of objects, the Bond object, which extends the basic java.lang.Object with some very important functionality. The enhancement added to it will serve the needs for every bond object.
We will take a look at a very small bondObject, and try all the features it has.:

//---------cut here ----------------//

import bond.core.*;
import bond.core.util.*;

public class myStarter extends bondExecutable{

        public myStarter(){
                dir.addAlias("Starter",this);
                System.out.println("myStarter:myStarter():\n"+toString());
        }

        public String toString(){
                 String myself="Info about bondObject:";
                myself+="\nbondID \t"+bondID;
                return myself;
        }

        public static void main(String argv[]){
                bondConfiguration.initSysProperties();
                dir= new bondDirectory();
                loader = new bondLoader();
                com = new bondCommunicator();
                conf = new bondConfiguration();
                new myStarter();
        }
} //end of class

// ---------- end cut here -----------//

• bondID
  This is the only mean to identify all the existing objects. Why do we need another means to identify the objects (other that its reference that we get when the object is created) ? Remember bond is a distributed system in which objects (local and remote) want to be able to interact. Since the reference returned by the java makes sence only within the local virtual machine, there is a need to be able to identify objects at remote sites (or at the same site , but running a different JVM - java virtual machine).
  For this purspose, each object has associated an identifying java.langString :
  bondID="bond"+bondIPaddress+commEnginePort+localMilisecondsSinceStartOfResident+
  Here is a bond ID captured while passinh through the net (it can also just prinded out, as in the exaple above):
  bondID_985369946696_13 TODO - change that
  Related to this field, we the bondObject implements the methods getName() and setName().
• com
  Each bond object has a reference to the communicator object, that will facilitate its communication with other bond objects. The communicator object is unique within a resident. It essential to the architecture of the Bond systems, because every object will use it to send and receive messages. For that bondCommunicator implements the say(bondMessage,bondObject) method. This is essential for receiveing messages from other objects, and usually sends the messages to be interpreted by probes that know how to speak a certain subprotocol(we'll cover these soon). The default subprotocol understood by all objects is PropertyAccess, and if this one does not understand the message sent will reply with sorry.
  If one wants to implement its own message handling system, it should overwrite this say(bondMessage,bondObject) method. The ideea from this is that objects will have a means to decode and interpret messages according to different protocols, or failing to do that will notify the sender with a sorry message. We'll present the communicator soon, in more detail.
• conf
  The configuration component.of the bond object. It specifies properties of all the objects created at a specific resident (site). To change the configuration properties, you'll have to edit $BONDHOME/bon/core/properties file (also see below)
• dir
  The directory is an object that keeps track of the objects created locally (and possibly migrated to some other resident). Similarly to the bondConfiguration and to bondCommunicator (covered so far) it is unique at each resident, and is made up of a hashtable where we put (register) all the objects from this resident (except messages) .
  It also has a messaging thread for TODO
  Some of the methods defined on the directory permit registering, deregistering objects, accesing objects by their aliases (objects can be registered in the aliases -alternative- directory using an alias, besides their actual name). The other methods defined on the directory are used to find objects (either registered locally or using the local directory's knowledge about some other directory - at other resident), that together with thelocal directory make up a distributed directory for the Bond system. The communication betweebn directories is implemented by the means of the say(bondMessage, bondObject) method that handles only the TODO ask: find: message.
• bondFileLogger
  It is a thread-derived object that supports appending a string to a log file.
• bondListener
  This is essentially a vector in which we store bond objects that are interested in the change of some property of this object. When a property of this object changes, the notifyListener(property,value) will call the propertyChanged(property) on all the registered objects that waited a change of this property, and these will do whatever they implemented in propertyChanged method. The bondListener field of the object is strongly related to the next field, values
• values
  As we said above, the bondObject can have a set of properties added on the fly. These properties are objects, and are identified by a string name. All the properties that we decide to add to some bond object will be stored in the values hastable. We will be able easily to use the fields and methods of this "component objects". As we have seen above, we can find even more uses of these added components, by registering with each of them a set of listeners, that will be notified when the status of the property changes.
  Related to this, the bondObject implements the methods get(), getProperties(), set(), take().
• loader
  Will instantiate bondObjects by name. This component is unique at the resident level, and it enables the loading of classes, having specified their name and the search paths. The advantage is an increased flexibility in the code, enabling us to load and run objects from classes specified from sources external to the compiled code (like user input). An example of how the Bond environment uses this is the way probes work
• userver
  The microserver concept is related to the ability to remotely access a certain resource (object) unaware of this fact. The microserver simply enables this remote access by "exporting" the resource capabilities through a common use protocol (ex. HTTP) enabling thus interoperability between systems using a common communication layer (ex. HTTP) as well as advanced features like object browsing and transparent object control.
  The main ideea is to make this in a as transparent as possible way (the resource is not aware of this, it simply sees the messages/calls it receives as local calls). In this respect, the microserver can be regarded as a protocol translator from an external (HTTP) to an internall (java virtual machine call) protocol.
  

TODO: REVIEW !!!!
• initialization of the bond environment: initbond(). It is the one that creates everything needed for the creatin of a resident (all the static filelds):
  1. bondConfiguration.initSysProperties() this method will load the configuration options of the Bond environment specified in the configuration file: $BONDHOME/bond/properties
  2. loader = new bondLoader() initializes the component that will perform dynamic loading of the classes. For a description, see above.
  3. dir = new bondDirectory() This will set up the local directory and will provide means to register the newly created objects. The constructor of the bondObject will attempt to do exactly that. So if instead adding initbond() to our example we'll add only the creation of the directory we'll have a unique ID for our object.
     We can observe that this time our application exits, (it does not initialize the rest of the components of the Bond resident)
  4. com = new bondCommunicator() So far we have initialized only the identifiers. This communicator component will provide us with the ability to send messages between objects. For a more extended presentation, follown the link above.
  5. conf = new bondConfiguration();
  6. filelogger = new bondFileLogger ("Log"+System.currentTimeMillis(), System.getProperty("bond.filelogger"))This is the logging service of bond. Its capabilities are described in detail (follow the link) bondMessage.initMessage()

  If you try to compile and run the myStarter application at the top og the page (and also here), you will notice that the bondObject needs all those supporting components in order to be fully functional. If you comment out one of the initialization steps, the application will loose the ability to fully integrate in the bond environment . This is a low-level initialization of the bondObject,which we will later replace with initbond(). The output of the application will just print the bondID value: bondID_986424220538_6, and the program idles (providing the functionality of a resident). This is because it started a complete bond environment (called resident), the communication component of this one will start listening on a port for messages, and thus our small application will not sop by itself If you want (and mots of the time you will) to take advantage of most of the bond facilities, be sure to call initbond() right at the beginning of your code.

• the communication between objects: ask(), on_reply(), say(), sayTo(). We will cover these more extensively shortly, when we will describe in more detail the commuication component of bond.
• semantic understanding of different subprotocols: genericSPH(),sphPropertyAccess(). genericSPH will try to invoke the correct subprotocol handler for which the message was intended. Calling genericSPH function in the say function of a higher object dispatches the message directly to the related subprotocol handler without the need to pass through all the link of say() functions.
  sphPropertyAccess is the default subprotocol implemented for all the bond objects and it handles four messages, grouped into two (semantically related) classes, according to the performative of the message:
  • bondKQML.PF_ASK_ONE:
    • message with content get, that will want to read a property of the object
    • message with content set, that will want to set a property of the object
  • bondKQML.PF_TELL:
    • message with content realize, used to send an object TODO.. MORE on this
    • message with content ok, for confirmation purposes.
  Note that the subprotocol handlers of the subprotocol XXX must have the format void sphXXX(bondMessage m, bondObject sender);

From the description above, we can deduce the following characteristics of the bond object:

• extensibility - by means of the dynamic properties (see the values field)
• asynchronous communication using ask ???
• synchronous communication
• abilty to speak and learn different protocols by means of probes and protocol handlers.