Agent Device assembly and analogue to a neuron.

Since I now have established a relatively stable implementation of the core data model, I have been adapting the Agent Device to it. This has actually gone through smoother than I imagined.

The core Element declarations were no big problem to implement in the Agent Device, and since the identifiers and their factory and quanta are generically closed in the core data model (inside the common Clique Space project - shared between Agent Device and administrator client), the Agent Device readily accepted the changes.

[Edit 19 March 2013: Much of the time,] I love this Clique Space (TM) adventure. I find that the architecture talks to me at least as much as I direct its form. As I walk through this journey, the concept reminds me of how similar its function is to that of a neuron.

For instance, I had to ponder a bit today about how external devices interface with a serving Agent Device. Now, a cluster of one or more Agent Devices form an Agent Collaboration. This Agent Collaboration constructs a Clique which is modelling a collaboration going on in another cluster of one or more external devices. Each external device is represented by one or more Participants in the Clique which represents this external device collaboration in one or more Clique Spaces; the Clique spans Clique Spaces when it contains Participants (a Clique must contain a minimum of two Participants) from two or more Clique Spaces.

Now, each Participant has at least one Connection which represents precisely one channel of communication between precisely one external device and precisely one Agent Device. The Agent Device from whence the Connection serving the external device originates could be of the same Agent Device as the one from whence the Participant originates; but then it may not be, and this fact might promise some rather interesting phenomena to do with the makeup of individual Participants. However, this aside, the dilema I had today was based around the question of knowing which Agent Device served which external device through which Connection.

This question is resolved nicely around the notions of generic closure of the Elements. This "generic closure" notion is one I've come to like as I have developed my idea in Java. Like the identifiers and their factories and quanta, the Elements come in a bottom and a top half. The bottom half of these structures create a "generically open" mechanism where classes and interfaces are parameterised in such a way that allows strong and circular type conveyance between almost all methods - certainly all methods that convey one Element out of another.

When implementing the top half of these open structures, one "generically closes" the bottom half with the desired implementation that the particular device requires. Neither the implemented identifiers, factory or quanta, nor the Elements require further parameterisation; hence the term. However - and this is very convenient indeed because it promises to overcome the dilemma I had pondered today - these generically closed implementations are regular Java classes, and hence can still be extended.

Now, considering the requirement that a single Agent Device must be responsible for serving a single external device, this extensibility can be applied to any given Connection as this given Connection is created on the Agent Device maintaining this service channel. This Agent Device can then transmit this Connection to other Agent Devices as necessary, and when the receiving Agent Devices reconstruct the transmitted Connection , they need only create the conventional underived version of the Connection.

This is especially good since the derived type of Connection object does not need to be conveyed in the connection identifier's quantum; this quantum is the first thing that is transmitted to an Agent Device (the receiver). This quantum lets the receiver know of the existence of a Connection Element identified by the identifier's value contained in the quantum object. As the receiver isn't the server for the Connection, it needn't create the extended Connection class. So, the receiver needn't even know of what the extended class the transmitter (or rather - because the receiver can be a link in a chain of transmissions and retransmissions - the originator) is extended as. Hence, any Agent Device can receive any type of connection object even if a given Agent Device does not have the extended version of the Connection class loaded in its JVM.

Quaint and rather good, that one. Still, a Connection, like any other Element, can contain any number and type of components it likes. One will probably have a need to deal with dynamic class loading and RMI code-base servers in time... a frustrating situation which will probably see me looking for a good library that will allow one Agent Device to load classes from another, or perhaps, to put one of these together myself.

Returning directly to the analogue with the neuron, this knowledge of the Connection type only by the Element's originator serves, I imagine, a very similar purpose to an organism which has only a subset of its interconnected neurons sending an receiving signals directly from cells of other organs. Most neurons merely relay signals from one neuron to the next, and hence, neither have, nor need, knowledge themselves of how those neurons connected to a cell of another organ actually serve these communication channels. The relay neurons, however, can, because they must, still convey information about these other cells.

Hence, the concept of a specialised Connection type appears to fit the purpose for those neurons (Agent Devices) which interface channels with cells of another organ (external Devices), while the general Connection type is what is constructed on the relay neurons.