Behavior Server
The server provides an environment for uploading and storing java classes,
creating instances from these classes and running these instances at the
server. The server implements 'online authoring' this means a client can
upload an other (newer) version of a class. In this case the instances
of the replaced class (and the instances of the subclasses) will by restarted
automatically.
The server is fully multithreaded each connection to a client is handled
by a separate thread. A 'Listener' thread accepts requests of clients for
setting up a connection and creates a 'Connection' thread for each request.
A separate 'Runner' thread goes periodically through the instances of the
uploaded classes. It calls the 'run' method of each instance whose status
is RUNNING.
The server provides the following functionality
Functionality for uploading, updating and deleting java classes
The classes must be derived from a special class called Behavior. The
behavior classes can use system classes (these are classes which are available
locally at the server e.g. the java standard API classes) and assistant
classes. Assistant classes are classes which are not derived from Behavior
and are used to assist the behavior class. E.g. a Coord class for storing
a 3D vector is a typical assistant class. Assistant classes will be requested
by the behavior server on demand.
Each behavior class can be updated simply by uploading the new version
of the class. In this case the server updates the class and its subclasses
and restarts the instances of all updated classes.
Functionality for creating and deleting instances of uploaded behavior
classes.
A client can cause the server to create instances of uploaded classes
simply by sending a command and parameters of the constructor. The server
sends back an unique identifier of the new instance.
Functionality for starting and stopping instances
A client can send commands for starting and stopping instances of behavior
classes at the server. A separate server thread called 'Runner' goes periodically
through the instances of the uploaded classes. It calls the 'run' method
of each instance whose status is RUNNING. If the time needed for a complete
round is less than a specified time slice, the 'Runner' threads blocks
until time slice is reached. The time slice can be adjusted any time using
the options dialog of the server.
Functionality for setting and querying static class parameters
A client can send a command to the server for setting specific static
parameters of a class. The server uses the java reflection API to find
out if the specified class has a method public static void setClassParam
with one string parameter. If the server has found such a method it will
be called with the parameter sent in the command. The method setClassParam
can be used to initialize static variables. The effect of the method depends
entirely on the implementation in a class.
Querying specific class parameters works analog. The server uses the
java reflection API to find out if the specified class has a method public
static String getClassParam with no parameters. If the server has
found such a method it will be called and the result will be sent back
to the client. The effect of the method getClassParam depends entirely
on the implementation in a class.
Functionality for querying information about the uploaded classes and instances
A client can query:
-
a list of all uploaded behavior classes
-
the identifiers of the instances of a class (with or without subclasses)
-
information about a specific instance this includes the status, the parameters
and the restart flag
Functionality for communication between instances of uploaded behavior
classes
Instances from uploaded behavior classes can get references to other
uploaded behavior classes via a class called 'Shared'. The Behavior class
has a static field 'shared'. The Behavior Server initializes this field
with a reference to a global instance of the 'Shared' class.
Behavior Server Information Window
This window views information about the state of the server. It contains
the following six lists:
-
Classes:
This list shows all uploaded classes.
-
Instances of Class:
This list shows the identifiers of all instances of the class which
is selected in the 'Classes' list.
-
Information:
This list shows information about an instance which is selected in
the 'Instances of Class' list.
-
Assistant Classes:
This list shows the assistant classes of the class which is selected
in the 'Classes' list. If the selected class has a getClassParam method
then the list shows also the result of a call to this method.
-
Instances:
This list shows the identifiers of all instances of all uploaded classes.
-
Connections:
This list shows all active connections to clients.
Behavior Server Option Window
This window is used to change options of the server. This includes:
-
Timeslice
The server periodically goes through the instances of the uploaded
classes and calls the 'run' method of each instance whose status is RUNNING.
If the time needed for a complete round is less than timeslice, the server
blocks the 'Runner' thread until timeslice is reached.
-
Verbose Classes
If this checkbox is checked the server writes debug information about
uploading, constructing, defining, ... classes to stdout.
-
Verbose Loader
If this checkbox is checked the server writes debug information about
the operations of the ClassLoader to stdout.
-
Verbose Packets
If this checkbox is checked the server writes debug information about
the packets received or sent by the server to stdout.
-
Verbose Timeslice
If this checkbox is checked the server writes the timeslice and the
remaining unused time of the timeslice to stdout.
Behavior Server Error Log Window
This window is used to display error messages. It shows mainly messages
about errors respectively exceptions encountered while running an instance
of an uploaded class. It doesn't show errors which occur through incorrect
client commands (e.g. trying to delete a nonexistent class).
Behavior Server Limitations
-
A client can explicitly upload only classes derived from the 'Behavior'
-
A behavior class can use 'assistant classes'. These classes couldn't be
derived from 'Behavior'. The assistant classes will be requested by the
server on demand. But because a server cannot make requests by itself these
requests must be done within a transaction. So assistant classes can only
be requested within a 'class upload' or a 'new instance' transaction. This
means the programmer of a behavior class must ensure that the needed assistant
classes will be used in the class constructor at the latest.
-
Each behavior class has its own private assistant classes. If two behavior
classes are using the same assistant class the assistant class will be
uploaded and stored twice.
-
The only way to update the assistant classes of a specific uploaded behavior
class is to delete the behavior class and uploading it again.
-
An instance x of an uploaded behavior class can get a reference r to another
instance y via the 'Shared' object. In java it's not possible to explicitly
delete objects. So the instance x should check whether the reference r
is up to date via r.isDeleted() and refresh the reference if needed.
-
As mentioned above an instance x of an uploaded behavior class can get
a reference r to another instance y via the 'Shared' object. If the underlying
class cy of y has been updated by a client and the instance x has refreshed
its reference r to y a 'ClassCastException' can occur. This happens because
when x gets a reference to y the java virtual machine stores a reference
to the class cy of y in the class cx of x. So if x refreshes the reference
r to y then r points to an instance of the new version of cy. But cx has
a reference to the old version of cy! The only way to refresh the reference
in cx to cy is to redefine the class cx. The behavior server and client
are providing a command for doing this.
Related Topics