QMFv2 Architecture

Introduction

QMF (Qpid Management Framework) is a set of APIs, in multiple programming languages, that provide an abstraction for object-oriented and service-oriented remote management. It is layered on top of AMQP messaging and implemented using the Apache Qpid messaging APIs.

Architectural Components and Operations

There are two central components in the architecture of QMF: The Agent and the Console. An agent is a software component that is managed via QMF and a console is a component that manages agents. The distinction will become clearer as we discuss operations.

A better way to describe console and agent is to call them roles. For example, a software program may perform the role of QMF Agent, and therefore become manageable via QMF. Another program may act in the role of QMF Console and manage some number of agents. It is also possible for a software program to act in both roles simultaneously and can do so using a single connection into the AMQP messaging infrastructure.

   +-----------+    +-----------+
   |  Console  |    |  Console  |
   +-----+-----+    +-----+-----+
         |                |
         |                |
+--------+----------------+-------------------------+
|                                                   |
|             Standard AMQP Messaging               |
|                                                   |
+----------+--------------+--------------+----------+
           |              |              |
           |              |              |
      +----+----+    +----+----+    +----+----+
      |  Agent  |    |  Agent  |    |  Agent  |
      +---------+    +---------+    +---------+

In QMF, there may be any number of agents and any number of consoles. Of course, if there are no agents, it won't be a very interesting network. Agents and consoles may appear and disappear dynamically.

Addressing and Scoping

QMF, being distributed in nature, needs a way to address the various entities that it represents. Further, the addressing of entities within QMF is organized in a scope hierarchy as follows:

+--------------------------------------------------------------------+
| Domain                                                             |
|                                                                    |
|  +-------------------------------+    +-------------------+        |
|  | Agent                         |    | Console           |        |
|  |                               |    |                   |        |
|  |  +--------------------+       |    +-------------------+        |
|  |  | Object             |       |                                 |
|  |  |                    |       |    +-------------------+        |
|  |  |                    |       |    | Topic Addresses   |-+      |
|  |  +--------------------+       |    |                   | |-+    |
|  |                               |    +-------------------+ | |    |
|  +-------------------------------+      +-------------------+ |    |
|                                           +-------------------+    |
|                                                                    |
+--------------------------------------------------------------------+

QMF Domain

Note that this is a new concept being introduced in QMFv2. It refers to a top-level scope for the addressing of all QMF entities. Multiple domains may be established so that independent, disjoint QMF deployments can share the same AMQP messaging network.

Console Address

When a console joins the network (i.e. an application that acts in the role of "Qmf Console"), it uses a unique and temporary identifier for addressing. This address is most likely different for each execution of the application. It is used only for reply messages sent directly to the console from an agent in the network.

Agent Address

The agent address, like the console address, must be unique within the domain. Unlike the console address, the agent address should be persistent, remaining the same even after the agent application is shut down and restarted.

Object Address

Topic Addresses

Operations

QMF operations are defined in terms of the console and agent roles. This section will introduce the operations at a fairly high level. For full details on how the operations operate, refer to the API specification for the programming language you are interested in.

Agent Locate

After a console first connects itself to an AMQP messaging broker, the first thing it must do is identify one or more agents with which to interact. This is done in one of two ways, depending on the purpose of the console application.

The console may attempt to locate a single specific agent by name (i.e. The HP printer on the second floor). In this case, the console communicates directly with the agent to see if it is present in the network (using a direct exchange and the agent's unique name).

Alternatively, the console may wish to interact with a set of agents, possibly all of them. In this case, the console establishes a set of criteria in the form of a query (i.e. "all printers where vendor == 'HP'") and builds a list of available agents. In this case, the console sends a multicast query (using a topic exchange) and collects responses from matching agents. Furthermore, if a new agent comes on line that meets the criteria, the console will learn about the new agent.

Query

A query is initiated by a console and answered by one or more agents. A query requests data from an agent and supplies selection criteria for the data. Once each agent sends the requested data to the console, the query operation is complete.

Subscription Query

A subscription query is similar to a normal query except that after the requested data is sent by an agent, the query remains open and subsequent changes to the requested data are sent to the address supplied by the console.

A subscription query is kept open by the agent and is closed in one of two situations. Either the console explicitly closes the subscription query or it times out after a time interval. The console may periodically refresh an exiting subscription query to keep it from timing out. This allows for subscription queries to be cleaned up in case the requesting console goes away without shutting down the subscription.

Schema Query

Method Invocation

Event Distribution

The QMF Data Model

+---- QmfData
       |
       +---- QmfDescribed
       |      |
       |      +---- QmfManaged
       |      |
       |      +---- QmfEvent
       |
       +---- QmfClassManaged
       |
       +---- QmfClassEvent

Other names that have been assigned to these concepts: