About Us Products Articles News Contact Support

Programming Distributed Systems with YAMI4

4.2 Agents

The agent encapsulates system resources (network connections, threads, etc.) that are needed for communication.

The name ``agent'' is used to reflect the terminology used in previous versions of the project. Another popular term for the entity that manages communication is a broker (the name mostly associated with ORB, from Object Request Broker), but it is useful to distinguish these terms in the context of previous chapter, where ``broker'' clearly referred to external central service that was used to relay messages between other remote participants - in contrast, ``agent'' is meant to be a local manager object that handles everything that is related to communication with other programs.

In many programs - in particular in all YAMI4 examples - the agent is created in a single instance and is kept alive for the lifetime of the program. In fact, server-like programs that are reactive in nature will have most or even all of their activity driven by the agent, which will orchestrate the work in response to the arriving messages. This is a very clean approach from the design perspective, but certainly not the only one possible with YAMI4.

Agent is a relatively cheap object that can be created in many instances if that makes sense in a give project - such an approach can be useful when different parts of the same program take part in remote communication for completely different purposes. It is also possible to create agents for a short period of time that corresponds to a single communication scenario.

The agent object provides services for both sending and receiving messages, which means that in a client-server system there will be at least one agent on both client and server side.

A single agent manages the following internal entities:

• Zero or more listeners that are connection targets for other (possibly remote) agents. The listeners are physically listening sockets that can accept incoming connections and in special cases there might be none of them, which might make sense for purely client-side agents.
• Zero or more active connections to other agents.
• One outgoing message queue for each connection, where the outgoing messages or replies to incoming messages are posted for transmission. The fact that outgoing message queues are separate for each physical connection allows the agent to optimally use the available network bandwidth - that is, slow connections have no impact on the message throughput on other connections.
• One incoming message collector for each connection, where the data arriving from other agents is assembled into complete incoming messages or message replies. The message collectors are necessary for those protocols that can potentially reorder message frames at the transport level - the collector makes sure that messages are reconstructed properly before they are passed for further processing.
• One incoming message queue where the incoming messages are stored until they are dispatched.
• Zero or more object callbacks where the incoming messages are dispatched. The object callbacks are in fact entry points into user-provided implementations of message handlers, which in the object-oriented approach might be treated as physical implementations of methods that are exposed to remote callers.
• Zero or more dispatcher threads that consume incoming messages from the incoming message queue and handle them in calls to relevant object callbacks.
• A single I/O worker thread that processes all I/O events in the background.

Each of these internal entities is described in detail in the following chapters.

A single agent is always associated with at least one background thread (at least the I/O worker thread). All threads managed by the agent are stopped when the agent itself is finalized in Ada, destroyed in C++ or when its close() operation is called in Java or .NET.

Distinct agents do not share any state with the exception of global system space for network port numbers.

Agents can be safely used from multiple threads.