_Remarks to the DistributionProposal _
_1.2 Goals _
A wider concept would be to distribute processes over a network of workstations in order to utilize different services. Processing capacity would then be a service like any computational or networking services offered at a given location.
_1.3 Assumptions _
Assuming an application where a notebook user connects to a network to start a job that is then distributed across the network, one cannot be sure of a well connected network. There should be the possibility for a node to signal that it is pluggable and then to be unplugged from the network. If it is attached again, all processes on that node may return to their homes or resume travelling on the network. Also a process inserted into the network from the pluggable workstation(notebook) may then return to it's initial starting point.
_1.4 Process aka Agent _
A process that can halt it's execution, travel across a network and resume it's execution at a different location may well be called a MobileAgent.
Assuming that the goal is to utilize different services in a network, and that a task can then be divided into subtasks, an Agent has to have a certain knowledge about it's task. The Agent can then be called an IntelligentAgent as well.
_2.1 Domains _
In accordance to the concept of services explained at 1.2 a Domain should have a mechanism for registering services offered at that domain. To be consistant within the AgentParadigma a service should be an Agent with the restriction, that it is stationary and bound to that domain (this is for having a certain amount of reliability on which a Mobile Agent can build it's plan on).
_2.2 Inter-Domain Communication _
For a more intelligent communication of tasks and plans I would suggest a message mechanism like Kqml (see KqmlNotes) that relies on the speechact theory and offers the communication of knowledge (see KifNotes) and actions contrary to mere data.
Kqml is also a means by which different Agents can communicate among each other inside a given Domain and across Domain borders.
_2.3 Process Distribution _
The architecture should be scalable as to provide different levels of Process distribution. To achieve the goal of sharing processing capacity there should be a low level distribution that works just like what is proposed in the DistributionProposal. But for sharing higherlevel services the architecture should provide a mechanism for each Domain to advertise it's higher services to other domains. E.g: At a workstation A there's a registered Service that provides fast graphics calculations. An Agent at workstation B finds out that he is not capable of making these calculations alone (or not as fast) and finds out about this Service at A. It then travels to A, registers with the calculation service and returns home when the calculation is done.
Such an architecture would make it possible for software to be installed at specialized workstations, where it can be executed most efficiently. (Think about a ray tracing renderer running on a 386 compared to having this program reside on a fast SGI machine and a 386 user just sends an Agent to the SGI to make the computing).
_2.4 Domain Managers _
To have a single Domain Manager at each Domain is a good concept. It can serve as a centralized information and registration point for all Agents executing on that Domain. I agree on the concepts for Domain Managers with the DistributionProposal.
Remarks
CarstenEckelmann, 30-MAY-98
_1.4 Process aka Agent _
Your comments imply that the process is aware that is is running in a distributed environment. That's good but I'd also like to see the architecture work with existing applications without recompilation. That's why I chose to say process rather than agent. I see it that dumb processes can be distributed automatically to provide load balancing but intelligent agents can turn it around and actively seek alternative Domains. The architecture should provide for both scenarios.
I'd like to be able to kick off processes from my PDA that immediately migrate to my desktop and beyond and return when complete to present the results to me.
_2.2 Inter-Domain Communication _
KQML is a good choice even if it is still a bit obscure. I'd like to see a way of communicating and defining ontologies with XML which should be more than capable of the job.
Remarks
One thing I'd like to add to your list of considerations is (please excuse what I'm about to say on a Free Software site;) Pricing. Domains should be able to set prices for their services, allowing agents to shop around to find the best price. It's a good way of achieving load balancing and should create a market for processing power. I'm not talking dollars or pounds here but micro units of currency. i.e. I'll let your process run 1 million bytecodes for 0.0002c. It can work both ways too. Imagine a search engine paying visiting agents for quality links pre categorised. Barter - that's what I'd like to see evolve.
IanDavis, 7 Jun 1998