See Goals

Core Use Cases

Data Exchange

• owner of a dataset registers it with the system
• retrieve/get a dataset (get all data)
• query the dataset (get the metadata)
• subscribe to dataset updates
• load/cache a dataset
• generate catalog
• transform/subset dataset

Messaging Service

• create an Exchange Space within the system
• create an Exchange Point in an Exchange Space (implies creating a representation of the Exchange Point in each Message Broker)
• use an Exchange Point (use = put something in the queue or reading )
• find out local Broker
• add a Message Broker to the message broker federation

Cloud Provisioning Environment

• provision cloud node (i.e., bring up and contextualize)
• schedule processes & nodes (depending on policy, existing resources are scheduled or new resources need to be provisioned)
• control/supervise resources (system, node, process, etc)
• resource agent monitors the resource internally
• resource agent controls the resource internally

Agent Contract Network

• negotiate resource contract
• resource agent monitors a resource (aggregates monitoring input from the instrumentation)
• resource agent executes control on a resource (lifecycle commands)
• resource agent gateways to resource capabilities
• monitor interactions to check compliance with the contracts (part of the resource agent, or global monitoring?)
• store interaction patterns
• manage contract lifecycle

Architecture

The figure below shows an exemplar representative scenario of an Amazon EC2 cloud node that hosts processes that provide application services. All resources are represented and controlled by agents. All entities communicate through the messaging system. Magnet realized the agent management system as well as the messaging adapter. Multiple such nodes realize a system deployment, in this case the Data Exchange.

The following picture shows a rough separation of responsibility for the core implementation artifacts within the projects:

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
• 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
• A typical messaging client (whether agent or application client) is typically at its core represented by a state-machine implementation. 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
• Detailed specifications and summary pages:
  • 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)