Stigmergy as an organizational principle of a service infrastructure?
Stigmergy is a mechanism of indirect coordination, through the environment, between agents or actions. The principle is that the trace left in the environment by an individual action stimulates the performance of a succeeding action (possibly by the same agent, but in many scenarios by a different agent).
"Stimulation of workers by the performance they have achieved." (https://en.wikipedia.org/wiki/Stigmergy)
A task (ergon) is disassembled by a program into a set of small, limited subtasks with associated information about what kind of work has to be done (stigma). It is put into a context, in which fitting executors can detect it and deal with it, leaving the results and the stigma “done”. An assembling program in the end puts the pieces together.
Complete tasks, which can be completed in subtasks (down to modules that can no longer be meaningfully divided further), can be processed by relatively simple "finishers" and "assemblers". The task division and the information for merging the results (with all necessary plausibility checks) must be determined once in advance for suitable task types, then a scalable process is possible.
Environments in which subtasks can be processed safely, quickly and certified, may be called "anthill". There may be specialized anthills. The disassembled modules of a task can be brought to several anthills for parallel completion if reasonable.
This requires a dispatcher who receives the entire task, disassembles it and distributes its modules to suitable anthills. To do this, he uses a dynamic database giving the operational readiness, current workload, specialization, rating and costs of the anthills.
The dispatcher who takes on a task makes his claim on it transparent so that others do not also access it. The claim has a limited duration until completion. If this is not adhered to, all dispatchers - except the last one - go back to action. There may be reasons for the dispatcher to postpone the end of the runtime. The cases and the postponement must be defined in advance.
The dispatcher's platform should be organized as a cooperative of the platforms of the anthills, the anthills as cooperatives of the "ants", i.e. the providers of certified code for modules. An ant can have its code work in several anthills after approval. An anthill can be listed with several dispatchers.
Dispatchers have a set of task templates in which they specialize.
Publicly tested, certified templates are integrated by vendors in their online stores. When a customer has decided on a good/service, the seller loads the corresponding parameters into the template. The customer then can define the offered choice of parameters and enter his personal data. After a cryptographic signature, the task is transferred to a pool that is accessed by the dispatchers.
One of them takes up the task, making it taboo for others until it is possibly put down again unfinished. The resignation can be forced if a defined time is exceeded or not extended.
After completion, the dispatcher pays out the involved anthills, keeping his set share. The dispatcher will lay down the result as specified and notify the client.
The concept stands and falls with the question whether it is possible, analogous to a problem-oriented programming language, but in reverse mode, to identify such modules from which overall tasks can be composed.
In a programming language, the hardware is known, which is programmed with the machine language in the sequence of binary states. The assembler is already a summary for recurring operations. The assembler code is brought into memory and started by a loader and libraries.
Problem-oriented programming languages have compilers, which generate assembler code from their instructions, which in turn is started by loaders and libraries.
In a stigmergic system, an assembler of a virtual, non-binary machine is wanted, which is supposed to process contracts without manual intervention. If it is possible to identify the assembler instructions (what the ants do), the compiler can be designed.
Possible Stigmata
- Check cryptographic integrity
- Check the identity of the contracting parties
- Make a report to the tax office on duty
- Make a money transfer when the delivery bill is received.
- Wait a time X until a delivery bill is received.
- Remind the money receipt
- Save the completed contract in Merkle trees of the contracting parties
- Get a competence to access the tree of a contract partner
- Delete yourself after a time Y
- Extend Y, for certain events.
