MobileAgents.Imported @ jos.sf.net

Distributed or Mobile agents have a lot in common with the goals of the NetworkOfWorkstations and the DistributionProposal. The following relates to both, separating the DistributionProposal into process related stuff and agents stuff. In terms of the DP, the domain is a local subgroup of agents and implemented as a feature of the agent namespace, and potentially implemented over process or thread group protections, eg, sandboxes.

The following complements developments like Java Spaces and Java Beans in distributing or communicating agent parametric information.

An agents framework is most efficient when object code is communicated in archive and agents are produced and reproduced by parametric data. Some mobile agents communicate in serialized objects & RMI, which precludes features valuable to agents.

Parametric agents allow scripting or at least editing of agent initialization info.

Parametric agents allow message based intra and interagent communication based on the same or similar interfaces.

Parametric agents avoid serialization overhead and multiple serialized transactions' overhead.

The parametrically distributed agent differs from the mobile agent in design and implementation but not in basic properties. The parametric agent reproduces via parameter data and the mobile agent is typically serialized into the pipe.

The parameterized agent principally communicates in String messages containing agent or component specific parameter information. Parametric messages are asynchronous, not neccessarily acknowledged, atomic transactions that are suitable for a range of applications.

Message based components become agents when they are addressable in a global namespace. Asynchronous messaging provides a simple, efficient route to transactions with high level semantics. These transactions tend to either renovate the state of a component or append additional information to a list or queue of usable data due to the mutual independence of completely asynchronous agents. This interface- abstraction fits Java well.

Message acknowledgement is available by choice for guaranteed transactions.

Asynchronous messaging is a distributed event model not unlike an AWT ActionEvent. In a round trip, request- reply message the class is designed to make the request and continue as required, receiving the reply at a completely undetermined point in the future. The class is written to make requests and receive replies in disjoint processes, implying a higher level of abstraction for the messaging interface than user input or other simple mechanisms (as may occur in RMI usage). A message event occurs subsequent to some involved (client or distributed) processing for low runtime "event" frequency, and works well over udp.

A parametric agent implements an interface providing

initialization

update (accepts runtime parametric messages)

parent or creator reference

persistence in, eg, toString() state parameterization

reference to agent context

local and universal agent identity, eg, by host!classname!alias or host!domain!classname!alias

The agent context or environment interface provides

agent loader and initializer (includes network query relating classname to its archive)

agent reference by name for existing agents (may partition access by domain or thread group)

agent persistent storage

agent (update) message delivery.

I have written a tentative implementation of message based components for applets and servlets including AWT lightweight components' animation. -- JohnPritchard

Something more esoteric but very fascinating, are motivated agents, see an interesting paper at http://home.t-online.de/home/alfschurm/agent.htm

Content of these pages are owned and copyrighted by the poster.
Hosted by: