terminology.xml - activemq-web - Git at Google

 <div class="wiki-content maincontent"><p>Questions on Message Orientated Middleware and ActiveMQ terminology</p>

 <structured-macro ac:macro-id="fab5b887-ca1f-4717-8fbc-963ce57c14f9" ac:name="children" ac:schema-version="1"><parameter ac:name="all">true</parameter></structured-macro>

 <h3>Store and Forward</h3>

 <p>brokers receive messages, store them locally and forwards the message to a recipient (in this case another broker) when it is able to do so. The message is only deleted once its been sucessfully delivered.</p>

 <h3>Reliable messaging</h3>

 <p>Best efforts are made to deliver a message whilst the system (broker/cluster/network) is running.</p>

 <h3>Guaranteed</h3>

 <p>No matter what happens to the physical network connections or the destination service the message will be delivered to the receiptant - provided there is no catastraphic loss to the persistent data store of a broker along the message(s) route. This means a message could be lost if there was a catastrophic failure to a broker's activemq data disk.</p>

 <h3>Fault Tolerance</h3>

 <p>Unexpected failures never lead to lost or corrupted data - for a messaging system - there are additional caveats for corrupted data - message ordering and once and only once message delivery.</p>

 <h3>Network Orphan</h3>

 <p>A broker can become isolated from other brokers in the cluster due to an network outage. The broker and it's connected clients may not be able to detect if the loss of other brokers in the cluster is due to the broker(or their machines) or simply a router/cable problem. This is a big issue for clustering, as it has the potential to create corrupted data exchanges when the network is re-established.</p>

 <h3>Clustering</h3>

 <p>multiple brokers are used to provide a single logical service. <br clear="none">
 There are three reasons for using clustering:</p>

 <h5>Increased capacity</h5>
 <p>This is load balancing - this is currently achived by networking brokers together - this won't change in ActiveMQ 4.0 (see below).</p>

 <h5>Geographical Distribution</h5>

 <p>Again this is achived in ActiveMQ by broker networks.</p>

 <h5>High Availability</h5>

 <p>The guarenteed maximum amount of downtime that will not be exceeded:</p>

 <table><tbody><tr><th colspan="1" rowspan="1"><p>Uptime</p></th><td colspan="1" rowspan="1"><p> Average Down time </p></td><td colspan="1" rowspan="1"><p> implications </p></td></tr><tr><td colspan="1" rowspan="1"><p>95% </p></td><td colspan="1" rowspan="1"><p> 8 hours a week </p></td><td colspan="1" rowspan="1"><p> System will be offline for nightly backups a broker loss could result in loss of all messages since last back-up</p></td></tr><tr><td colspan="1" rowspan="1"><p>99%</p></td><td colspan="1" rowspan="1"><p> 1.5 hours a week</p></td><td colspan="1" rowspan="1"><p> system maybe offline for backup or maintenance</p></td></tr><tr><td colspan="1" rowspan="1"><p>99.9%</p></td><td colspan="1" rowspan="1"><p> 40 mins/month</p></td><td colspan="1" rowspan="1"><p> all back-ups done online</p></td></tr><tr><td colspan="1" rowspan="1"><p>99.999% </p></td><td colspan="1" rowspan="1"><p> 5 mins/year</p></td><td colspan="1" rowspan="1"><p> full redundancy</p></td></tr></tbody></table>


 <h5>Architecture basics</h5>

 <p>Clusters can be either based around shared storage (shared database or disk) or shared nothing (every broker has their own private storage). There is also two basic mechanisms used for message integrity for failure scenarios:</p>

 <h6>Master/Slave</h6>

 <p>A broker has a standby replacement - another broker that is kept in step by the cluster that will take over in the event of a broker failure.</p>

 <h6>Synchronous</h6>

 <p>Every broker is kept exactly in-step with message exchanges across the entire cluster. This is the most secure for failure scenrios, but suffers from performance problems because it the responsibility of the cluster to ensure that messages are fully replicated across every node. This results in higher latency and increased traffic. In practice, it is unsual to have more than 2 brokers in such a cluster, because the performance degradation is directly related to the number of brokers in the cluster.</p>

 <h6>Hybrid</h6>

 <p>A fully synchronous cluster, but it is the responsibility of the client (not the brokers) to ensure every broker is kept up to date. This has advantages for performance, but is complicated by the additional exchange between client and broker(s) to ensure that only one broker does the message dispatching for a client.</p>

 </div>
	<div class="wiki-content maincontent"><p>Questions on Message Orientated Middleware and ActiveMQ terminology</p>

	<structured-macro ac:macro-id="fab5b887-ca1f-4717-8fbc-963ce57c14f9" ac:name="children" ac:schema-version="1"><parameter ac:name="all">true</parameter></structured-macro>

	<h3>Store and Forward</h3>

	<p>brokers receive messages, store them locally and forwards the message to a recipient (in this case another broker) when it is able to do so. The message is only deleted once its been sucessfully delivered.</p>

	<h3>Reliable messaging</h3>

	<p>Best efforts are made to deliver a message whilst the system (broker/cluster/network) is running.</p>

	<h3>Guaranteed</h3>

	<p>No matter what happens to the physical network connections or the destination service the message will be delivered to the receiptant - provided there is no catastraphic loss to the persistent data store of a broker along the message(s) route. This means a message could be lost if there was a catastrophic failure to a broker's activemq data disk.</p>

	<h3>Fault Tolerance</h3>

	<p>Unexpected failures never lead to lost or corrupted data - for a messaging system - there are additional caveats for corrupted data - message ordering and once and only once message delivery.</p>

	<h3>Network Orphan</h3>

	<p>A broker can become isolated from other brokers in the cluster due to an network outage. The broker and it's connected clients may not be able to detect if the loss of other brokers in the cluster is due to the broker(or their machines) or simply a router/cable problem. This is a big issue for clustering, as it has the potential to create corrupted data exchanges when the network is re-established.</p>

	<h3>Clustering</h3>

	<p>multiple brokers are used to provide a single logical service. <br clear="none">
	There are three reasons for using clustering:</p>

	<h5>Increased capacity</h5>
	<p>This is load balancing - this is currently achived by networking brokers together - this won't change in ActiveMQ 4.0 (see below).</p>

	<h5>Geographical Distribution</h5>

	<p>Again this is achived in ActiveMQ by broker networks.</p>

	<h5>High Availability</h5>

	<p>The guarenteed maximum amount of downtime that will not be exceeded:</p>

	<table><tbody><tr><th colspan="1" rowspan="1"><p>Uptime</p></th><td colspan="1" rowspan="1"><p> Average Down time </p></td><td colspan="1" rowspan="1"><p> implications </p></td></tr><tr><td colspan="1" rowspan="1"><p>95% </p></td><td colspan="1" rowspan="1"><p> 8 hours a week </p></td><td colspan="1" rowspan="1"><p> System will be offline for nightly backups a broker loss could result in loss of all messages since last back-up</p></td></tr><tr><td colspan="1" rowspan="1"><p>99%</p></td><td colspan="1" rowspan="1"><p> 1.5 hours a week</p></td><td colspan="1" rowspan="1"><p> system maybe offline for backup or maintenance</p></td></tr><tr><td colspan="1" rowspan="1"><p>99.9%</p></td><td colspan="1" rowspan="1"><p> 40 mins/month</p></td><td colspan="1" rowspan="1"><p> all back-ups done online</p></td></tr><tr><td colspan="1" rowspan="1"><p>99.999% </p></td><td colspan="1" rowspan="1"><p> 5 mins/year</p></td><td colspan="1" rowspan="1"><p> full redundancy</p></td></tr></tbody></table>


	<h5>Architecture basics</h5>

	<p>Clusters can be either based around shared storage (shared database or disk) or shared nothing (every broker has their own private storage). There is also two basic mechanisms used for message integrity for failure scenarios:</p>

	<h6>Master/Slave</h6>

	<p>A broker has a standby replacement - another broker that is kept in step by the cluster that will take over in the event of a broker failure.</p>

	<h6>Synchronous</h6>

	<p>Every broker is kept exactly in-step with message exchanges across the entire cluster. This is the most secure for failure scenrios, but suffers from performance problems because it the responsibility of the cluster to ensure that messages are fully replicated across every node. This results in higher latency and increased traffic. In practice, it is unsual to have more than 2 brokers in such a cluster, because the performance degradation is directly related to the number of brokers in the cluster.</p>

	<h6>Hybrid</h6>

	<p>A fully synchronous cluster, but it is the responsibility of the client (not the brokers) to ensure every broker is kept up to date. This has advantages for performance, but is complicated by the additional exchange between client and broker(s) to ensure that only one broker does the message dispatching for a client.</p>

	</div>