About the gnu.cajo.utils.extra package

The extra package is a collection of potentially standard 'thought-starters,' with regard to advanced posibilities offered through the cajo project. They were left out of the core, so as to minimise the learning curve for new developers.

• AsyncMethod: This class is used to asynchronously invoke methods on objects. Each time the invoke method is called, it spawns a one-use thread, to perform the method invocation. From the perspective of the caller, the method returns immediately. When the invocation is completed, it will callback the provided listening object; invoking a method of the identical name as the one invoked on the called object; passing a single object argument, which is either the resulting data of the invocation, if any, or the exception resulting from the invocation. It is intended for method invocations which require a significant amount of time to complete. It can also be remoted, and even be passed between virtual machines, which would enable some very interesting possibilities.

• AuditorItem: This class allows one object to audit the operation of another. The auditing object will be notified when a method on the audited object is being invoked. The auditing object then has the opportunity to examine the argument objects, and even to modify them, before allowing the audited item to execute. It even has the option to throw an exception back at the caller, rejecting the entire invocation from taking place. The auditor object will again be notified, when the invocation on the audited item is complete. The auditor object then has the option to inspect, and even modify the result object (or exception) from the invocation, or even to throw an exception of its own. The audited object, and the calling object, are completely unaware of the auditing object. Neither need modify their code in any way to work in the audited environment. The auditing relationship can be established statically at compiletime, or dynamically at runtime. It is a simple cajo-focused implementation of the long-established Go4 decorator design pattern; which is currently being over-hyped, under the rather dubious title Aspect Oriented Programming.

• ClientProxy: This class is used by one VM, to asynchronously callback another VM, behind a firewall that blocks inbound socket connections. This is one of the most common problems with RMI deployment over the internet, and ClientProxy, in conjunction with ItemProxy, to be described next, solve it elegantly and effectively. The ClientProxy utilizes a symmetrically synchronized method invocation handler, to make its reference appear to the calling item as though it were not behind a firewall at all. This prevents having to develop two communication mechanisms, one for blocked objects, and one for unblocked. The object calling a method on this proxy is suspended, while at the same time a blocked thread on the client is woken. The client thread immediately processes this invocation, and returns the result. No wasteful polling mechanism is used.

• DynamicObject: This class wraps any server object, yet it allows the server to change its implementation dynamically, at runtime; while all of its client references remain completely unchanged. This creates extraordinary opportunities; for dynamic server object customisation, enhancement, and refinement, in a surprisingly simple and intuitive manner.

• HashedProxy: This class demonstrates how to encrypt serialized objects transparently before sending on the network, and transparently decrypt them on arrival. Rather than incur the overhead of encrypting the entire stream between remote VMs, just the sensitive objects can be encrypted. While the example does not employ strong cryptography, if strong crypto were used, the result would be even tighter security, as each object could use its own separate cypher and key. An excellent example of this type of approach can be found here.

• Implements: This class takes any service object, and allows its methods to be tested for existence, without invoking them. A service object would canonically provide a public getImplements() method, which would return a remote reference to the service object, wrapped by an Implements instance. Then clients can invoke the set of methods they think the object implements. Class objects can be used to represent the arguments by type, or the actual argument instances can be used. Instead of the normal method return; it will return a boolean: true indicates that the service object supports the method, false otherwise.

• ItemProxy: This class is the cooperating other half to the ClientProxy. It is used by a firewalled client, to receive asynchronous callbacks over its outgoing thread. The client links a remote reference to a ClientProxy with the local object, using this object, and the callbacks are handled transparently. It creates a thread, and calls the remote ClientProxy. This causes it to block until the remote object has a callback to make. The remote invocation wakes this thread, and it immediately invokes the corresponding method on its local object, returning the result. It then is automatically blocked, until another callback is needed.

• Queue: This class is used to support a message-based communication paradigm. A Queue object wraps any object, and queues its method invocations. The queue is threadsafe, and ensures that only one invocation thread will be executing within the object at a time. All invocations on a Queue object return immediately to the client, without a return argument. By virtue of completing without an exception, the client is assured the invocation is successfully entered into the queue. Clearly, objects intending to be wrapped by a Queue should not return values, as the Queue will simply discard them. If completion notification, or return results are required, the queued object should take a client callback reference, as one of its method arguments.

• Registry: This class is an extremely handy registry for collecting remote object references. The best part is that the more instances that are running, the greater the interconnectivity. It has a static main method, which makes a multicast announcement of its startup, to link with other registries. Remote objects can register with it statically, and can also request a list of its registered objects, which also contain references to remote registries. Duplicate and dead references are automatically purged, to provide maximum utility. Remote objects are even free to register dynamically as well, using the Multicast class.

• Scheduler: This class is the exciting foundation for the development of network distributed operating systems! It coordinates remote procedure calls between Virtual Machines cooperatively, with various levels of priority, and asynchronous triggering. Multiple schedulers can be run for concurrent scheduling. The architecture is elegant and simple, yet extremely powerful. Most exciting of all, a scheduler can be sent between virtual machines, cloning it, even while it is running! The implications of this are truly mind-bending.

• Timer: This class uses a Scheduler object to execute remote procedure calls at timed intervals, for a specific number of times, or indefinitely. Any loaded task can also be cancelled, asynchronously. Just as with the scheduler, the timed tasks are executed cooperatively, to eliminate concurrency issues. Again multiple schedulers and timers can be used whenever concurrency is needed. It is very simple to understand, and to use. Timed tasks can also be transparently cloned, by sending them to another Virtual Machine. It's some very interesting stuff to think about.

• TransparentItemProxy: This class wraps any server object, and dynamically creates a local object instance. This object instance will literally implement a collection of interfaces, provided by the client, at runtime. This allows the remote object to be used via standard Java syntax; more importantly, it also allows clients to categorise item references in terms of the collection of interfaces they support.

• Wrapper: This class is a standard generic base for wrapping objects. It can be used for remote references, proxies, and even local objects. In its base form its constructor takes a String URL, which it uses to load the object, only if invoked. It is intended for creating lots of customised wrappers, with compiletime typesafe application specific method signatures.

• Xfile: This class is used to transfer files between Java Virtual Machines. It can selectively enable itself for remote invocation, this would allow a remote JVM to be directed to read a file from yet another remote JVM, and save it into itself, or relay it to yet another JVM.

• Zedmobject: This class wraps any serialisable object, and allows it to be passed back and forth between remote virtual machines in an optimised compressed format. The compression and decompression are done automatically, and transparently, during serialisation and deserialisation. It also places the object graph into a MarshalledObject, to further ensure its transport integrity. It is highly recommended for any large objects. It can also be used for purely data objects. It requires no modification to the object being wrapped, nor to the remote code using the object.