qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Qpid > QMFv2 Project Page
Date Mon, 07 Dec 2009 22:41:00 GMT
<html>
<head>
    <base href="http://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/1519/1/1/_/styles/combined.css?spaceKey=qpid&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background-color: white" bgcolor="white">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
     <h2><a href="http://cwiki.apache.org/confluence/display/qpid/QMFv2+Project+Page">QMFv2
Project Page</a></h2>
     <h4>Page <b>edited</b> by             <a href="http://cwiki.apache.org/confluence/display/~tross">Ted
Ross</a>
    </h4>
     
          <br/>
     <div class="notificationGreySide">
         <h1><a name="QMFv2ProjectPage-QMFv2ProjectPage"></a>QMFv2 Project
Page</h1>
<h2><a name="QMFv2ProjectPage-Introduction"></a>Introduction</h2>

<p>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.</p>

<ul>
	<li><a href="/confluence/display/qpid/QMFv2+Architecture" title="QMFv2 Architecture">Architecture</a></li>
	<li><a href="/confluence/display/qpid/QMF+Map+Message+Protocol" title="QMF Map Message
Protocol">Protocol</a></li>
	<li><a href="/confluence/pages/createpage.action?spaceKey=qpid&amp;title=QMFv2+Design&amp;linkCreation=true&amp;fromPageId=5965402"
class="createlink">Design</a></li>
	<li><a href="/confluence/display/qpid/QMFv2+APIs" title="QMFv2 APIs">APIs</a></li>
</ul>


<h2><a name="QMFv2ProjectPage-ChangesfromVersion1"></a>Changes from Version
1</h2>

<ul>
	<li><b>Broker participation in QMF is no longer mandatory.</b>  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.</li>
</ul>


<ul>
	<li><b>Message body formats are based on AMQP maps.</b>  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.</li>
</ul>


<ul>
	<li><b>Federation is supported.</b> 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.</li>
</ul>


<ul>
	<li><b>Agent and Object identification is more flexible.</b>  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.</li>
</ul>


<ul>
	<li><b>Agents no longer publish data globally.</b>  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.</li>
</ul>


<ul>
	<li><b>QMF uses native AMQP Types</b>  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.</li>
</ul>


<h2><a name="QMFv2ProjectPage-Backward%2FForwardCompatibilitywithQMFv1"></a>Backward/Forward
Compatibility with QMFv1</h2>

<p>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.</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>                 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
           |                    |                    |
           +--------------------+--------------------+
</pre>
</div></div>

<p>The following notes address how intersections in the matrix might be supported.</p>

<p>Note 1: V2 broker retains V1 capability<br/>
Note 2: V2 broker proxies V1 agents (including the embedded one) to V2 protocol<br/>
Note 3: V2 clients speak both protocols, choosing which to use by the version of the connected
broker<br/>
Note 4: V2 broker proxies V2 agents to V1 protocol</p>

<p>Planning:</p>
<ul>
	<li>The features in notes 1 and 2 <b>must</b> be implemented.  It is important
that users not be required to upgrade all components of their deployments at the same time.</li>
	<li>The feature in note 3 <b>may</b> be implemented.  This is considered
lower priority.</li>
	<li>The feature in note 4 <b>shall not</b> 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.</li>
</ul>


<h2><a name="QMFv2ProjectPage-DevelopmentRoadmap"></a>Development Roadmap</h2>
     </div>
     <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="http://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
       </div>

       <a href="http://cwiki.apache.org/confluence/display/qpid/QMFv2+Project+Page">View
Online</a>
       |
       <a href="http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=5965402&revisedVersion=8&originalVersion=7">View
Change</a>
              |
       <a href="http://cwiki.apache.org/confluence/display/qpid/QMFv2+Project+Page?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:commits-subscribe@qpid.apache.org


Mime
View raw message