THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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 the Original (QMFv1)
Architecture
Protocol
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.