Goals

Magnet Framework

• Magnet has two main functions:
  1. as the messaging system adapter for any agent or application/service end point and
  2. as the agent management system and agent plug-in framework. Agents in this case are just a special class of messaging end points that represent resources and control their life cycle. (See resource agent, managed resource)
• Magnet is realized in Python, based on Twisted and txAMQP. It can interface with applications in any programming language; typically they include some kind of Magnet adapter
• Any messaging client (whether agent or application client) is at its core represented by a state-machine via the Magnet role concept. This state-machine realizes the binding between events (messages) and actions (execution of code). The binding is descriptively located within the state-machine configuration: states and transitions. Roles can be chained and thus can be the FSMs (realizing nested FSMs)

Architecture

Layers

The following diagram shows the layers of concern covered by the Magnet framework and its interfaces. Exemplar classes are shown within the layers and interfaces between layers. Interfaces between layers realize the DIF (Distributed IPC facility) according to Day's network patterns book.

Layers are defined as:

• Transport Layer: The AMQP Broker (and later the OOI Messaging Service)
• Transport Adapter Layer: Specific protocol adapter clients, such as txAMQP based on the Twisted framework
• Transport Abstraction Layer: Hides specifics of the transport protocol (AMQP) from higher layers.
• Distributed Role Layer: Reactive behavior of any messaging end point. Makes use of FSMs to bind events to actions
• Conversation Layer:  Connects roles to conversations (interaction type specifications with conversations as instances), and performs interaction based governance and policy enforcement
• Application Adapter Layer: Additional boilerplate code provided by Magnet to make the development of agents and service clients easier
• Application Layer: Specific agents and services

Magnet/Resource/Agent Interactions

The following diagram shows how the individual pieces around Magnet interact:

The following interactions and dependencies exist:

• Message Broker to Magnet Pole: A pole represents an entity in the network
• Magnet Role: Encapsulates one FSM and represents a slice of the behavior of a client (end point) in the distributed message-based system network.
• Managed Resource Agent: An agent that controls a resource. A resource can be physical (node, process, etc) or a service (function block). The agent monitors the resources state and represents it as a state machine (FSM). It controls the resource state. The agent interacts with the resource via resource specific control protocols. Makes use of Magnet roles to communicate via the messaging system
• Proxy Resource Agent: An agent that represents a resource (or multiple resources) at a higher level in the system. It proxies the managed resource agent and interacts with it instead of directly accessing the resource. This chained pattern can repeat multiple times.

Detailed specifications

• See here for state-machine client design
• See here for the resource agent framework design
• See here for the abstract managed resource model
• See here for a specification of the Messaging service and the client interface
• See here for more detail on Magnet framework (partly outdated)