Do You Want 1000 Entities Cooperating? OK with me!

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
Current issues #1: Configuration Files and Processing; reported the importance of configuration files and the need to handle them more "generically" than in the prototype. One particular problem stemmed from the fact that using multiple distributed copies of HLL was a sudden flash insight during prototyping.

Building the prototype with a robotics example application close at hand, I originally thought any user interface would communicate with the robot's HLL directly. That would be the same as communicating with the robot. Then it occurred to me that the Command Center (user interface) needs its own separate intelligence to do the things it needs to do intelligently, so it should have its own personal copy of HLL. Then WOW! - Once that's working, you can get as many "entities" (robots, complex specialized experts, - or any distributed entities for any type of application(s)) as needed to do anything. (And with special regard for robotics, it would simplify an effort to get robots to cooperate.)

OK (yes, I'm being verbose - selling HLL) back to the prototype. Before I thought of that, I set up the system to read a simple XML file that gave the host and port of the HLL system, supporting loose coupling. Then I added the browser-based GUI, which also needed to be loosely coupled, so I created another XML file and explicitly handled its reading in the code. Then I decided the Command Center should have its own copy of HLL and explicitly added again. I handled later configurations better, but, so far as the communication information was concerned, it was clear it had to change.

I reprogrammed the handling of the comm configuration file, so that it reads and stores a list of comm entries of arbitrary length. In order to add information for a new connection, the application programmer needs only extend the XML file.

<?xml version="1.0" encoding="ISO-8859-1"?>
<commconfig>
 <config>
  <name>server</name>
  <type>hll</type>
  <host>anyreachablehost.com</host>
  <port>4049</port>
 </config>
 ... continue ad infinitum
</commconfig>

To send a message to any entity in the list, a method called sendCommand() in HLL's HLLCommUtils class is used.

response = hllCommUtils.sendCommand(commandMessage, "server", true);

sends a message to the "server" at the host and port specified in the XML above, and receives a response. The sendCommand() method is used whether the message is being passed internally ("server" is in fact currently the reserve word for some of HLL's basic internal communication) or to another HLL installation 1000 miles away, using whatever naming convention is chosen for identifying HLL installations. It's only required that the names are unique.

Both "commandMessage" and "response" are complex objects, allowing complex messages to be passed back and forth easily. A variety of message formats are in fact supported; i.e. SOAP, java objects, strings ... The commandMessage can contain information on the recipient of the message that goes beyond host and port. Issue #2 is about making these messages FIPA compliant.