[Sigia-l] notes on multi-agent system configuration architecture

[Elim Qiu]

I'm working on an online community info system and the following is part of
my architecting notes.

The dynamic nature of information system requires the system behaviors be
altered by a network of participants (users or other systems), in various
aspects, scopes and levels. Among all the runtime inputs, those affect the
system's behavior at rule/logic level constitute the dynamic part of system
configuration.

Aspects of Multi-Agent System Configuration

  * DataType  An OOP type is a result of the classification of objects in a
system by behavior and data structure. In general OOP, the static
correspondence between type and Class implementation will become optional:
types need to be modified at runtime. This is achieved by dynamic typing at
object model level (DTM): where a type is an object of a special class which
holds the runtime manageable data that regulate the objects of the type. DTM
makes Type Data Management the most important part of Configuration

  * Privileger  Some privileged objects (type, owner etc) may have various
levels of configuration controls over an object. Such controls form a
directional graph indicating the configuration complexity.

  * Instance configuration  An object might have its own additional behavior
settings beside those from its type.

  * Meta Configuration  Both type and instance configuration need to follow
some rules which conform system's ultimate purpose. Such rules plus a set of
fixed logics form the Meta configuration.

  * System Configuration    There are no needs to discuss system
configuration separately if system itself is typed.

  * The Configuration Issuers  The capability of providing the right tools
and right scope of data access per system access is called the service
localization with respect to participation (SLP). SLP is itself the result
of configuration. Handling multiple configuration (possibly concurrent)
updates from agents (issuers) is interesting and challenging; more
importantly, it's demanded by every real operational situation.

  * The Runtime Configuration   This is the runtime merging result of
(possibly partial) configurations by various issuers.

  *The Transition of Configuration  Certain configuration transition
policies are needed just as the real operational world.

Multi-Agent System Configuration architecture

  *Configuration Data Structure    Property list is proposed to be the data
structure of configuration. Its formal recursion capability is used to
present the hierarchical nature of configuration data.

  *The Uniqueness of Configuration KeyPath.   Meta configuration shall
determine the keyPath of a set of configuration data per theme. Any objects
hold configuration data of a theme shall find the data by the keyPath
uniquely determined by theme and reference data type. Any configuration is a
data subtree of the configuration tree defined in the Meta configuration
tree structure wise; and the merging logic is readily found in the Meta
configuration by the uniqueness of the keyPath.

  *The Merging Algorithm   There is a default merging order which can be
overridden by Mata configuration and the real merge procedure is recursive
until the leaf merge (data item merge).

  *The Transition of Configuration  An analysis of dynamic configuration
performance and the justification of the rationality of the configuration
caching will be provided.