QMFv2 Project Page
Introduction
This developer page shall be used to collect architecture, design, and project information for the development of the Qpid Management Framework. It will become the basis for a distilled, user-oriented set of documentation.
Changes from Version 1
- Broker participation in QMF is no longer mandatory. In QMFv1, the broker provides two essential services for QMF: Agent registration and Schema caching. In QMFv2, the need for agent registration has been removed. Schema caching remains a valuable optimization but is not required in QMFv2.
- Message body formats are based on AMQP maps. In QMFv1, message bodies were formatted as packed binary data (using the AMQP type encodings). In QMFv2, message bodies are AMQP maps and are therefore easily extended without causing backward compatibility problems. Another benefit of the map-message format is that all messages can be fully parsed when received without the need for external schema data. In QMFv1, messages cannot be decoded unless the schema for the data is already known.
- Federation is supported. In QMFv1, messages cannot be transferred over federation links between brokers. Each broker represents its own isolated QMF domain. In QMFv2, agents and consoles can connect to any broker in a federated network and interact with other agents and consoles anywhere in the network.
- Agent and Object identification is more flexible. Agent and object identification in QMFv1 uses fixed-length binary data fields. In QMFv2, variable-length strings are used. QMFv2 agents choose their own globally unique identifiers (either through configuration or by embedding a UUID into the ID). Managed objects are identified by the ID of the owning agent plus a unique (to the agent) string identifying the object.
- Agents no longer publish data globally. Global publishing of data by agents causes security and scaling issues. In QMFv2, the global publish is replaced by subscription queries where a console establishes a subscription and receives periodic updates about changes to data in its field of interest. The benefits are that the query can be authorized based on an authenticated user-id and that data is not generated if there are not consoles interested in receiving that data.
- QMF uses native AMQP Types The base types in QMFv2 are the same as those supported by AMQP. There is no additional type-id space as there is in QMFv1.
Backward/Forward Compatibility with QMFv1
The following compatibility matrix shows all combinations of V1 and V2 components (console, agent, and broker). Those intersections marked "OK" are supported without the need for compatibility-oriented development.
V1 Console V2 Console
+--------------------+--------------------+
| | |
| OK | note 3 | V1 Broker
| | |
V1 Agent | -----------------+ -----------------+
| | |
| note 1 | note 2 | V2 Broker
| | |
+--------------------+--------------------+
| | |
| note 3 | OK | V1 Broker
| | |
V2 Agent | -----------------+ -----------------+
| | |
| note 4 | OK | V2 Broker
| | |
+--------------------+--------------------+
The following notes address how intersections in the matrix might be supported.
Note 1: V2 broker retains V1 capability
Note 2: V2 broker proxies V1 agents (including the embedded one) to V2 protocol
Note 3: V2 clients speak both protocols, choosing which to use by the version of the connected broker
Note 4: V2 broker proxies V2 agents to V1 protocol
Planning:
- The features in notes 1 and 2 must be implemented. It is important that users not be required to upgrade all components of their deployments at the same time.
- The feature in note 3 may be implemented. This is considered lower priority.
- The feature in note 4 shall not be implemented. Because QMF V2 is intended to scale to larger networks than are currently possible with V1, and this feature would limit the scalability of QMF V2, this is considered non-desirable.