qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonat...@apache.org
Subject svn commit: r967163 [2/4] - in /qpid/site/docs/books/0.7/Programming-In-Apache-Qpid: html/ pdf/
Date Fri, 23 Jul 2010 16:48:12 GMT
Modified: qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s06.html
URL: http://svn.apache.org/viewvc/qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s06.html?rev=967163&r1=967162&r2=967163&view=diff
==============================================================================
--- qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s06.html (original)
+++ qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s06.html Fri Jul 23 16:48:11 2010
@@ -1,27 +1,9 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>6. Receiving Messages from Multiple Sources</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s05.html" title="5. Logging"><link rel="next" href="ch02s07.html" title="7. Request / Response"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">6. Receiving Messages from Multiple Sources</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s05.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s07.html">Next</a></td></tr></tabl
 e><hr></div><div class="section" title="6. Receiving Messages from Multiple Sources"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2743998"></a>6. Receiving Messages from Multiple Sources</h2></div></div></div><p>A receiver can only read from one source, but many
-      programs need to be able to read messages from many sources,
-      preserving the original sequence of the messages. In the Qpid
-      Messaging API, a program can ask a session for the <span class="quote">&#8220;<span class="quote">next
-      receiver</span>&#8221;</span>; that is, the receiver that is responsible for
-      the next available message. The following example shows how this
-      is done in C++, Python, and .NET C#.</p><div class="example"><a name="id2744018"></a><p class="title"><b>Example 2.12. Receiving Messages from Multiple Sources</b></p><div class="example-contents"><p>C++:</p><pre class="programlisting">
-Receiver receiver1 = session.createReceiver(address1);
-Receiver receiver2 = session.createReceiver(address2);
-
-Message message =  session.nextReceiver().fetch();
-session.acknowledge(); // acknowledge message receipt
-std::cout &lt;&lt; message.getContent() &lt;&lt; std::endl;
-	  </pre><p>Python:</p><pre class="programlisting">
-receiver1 = session.receiver(address1)
-receiver2 = session.receiver(address)
-message = session.next_receiver().fetch()
-print message.content
-	  </pre><p>.NET C#:</p><pre class="programlisting">
-Receiver receiver1 = session.CreateReceiver(address1);
-Receiver receiver2 = session.CreateReceiver(address2);
-
-Message message = new Message();
-message =  session.NextReceiver().Fetch();
-session.Acknowledge();
-Console.WriteLine("{0}", message.GetContent());
-	  </pre></div></div><br class="example-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s07.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5. Logging </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 7. Request / Response</td></tr></table></div></body></html>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>2.6. Receiver Capacity (Prefetch)</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s05.html" title="2.5. Sender Capacity and Replay"><link rel="next" href="ch02s07.html" title="2.7. Acknowledging Received Messages"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">2.6. Receiver Capacity (Prefetch)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s05.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s07.html">Next</a>
 </td></tr></table><hr></div><div class="section" title="2.6. Receiver Capacity (Prefetch)"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="prefetch"></a>2.6. Receiver Capacity (Prefetch)</h2></div></div></div><p>By default, a receiver requests the next message from the
+    server in response to each fetch call, resulting in messages being
+    sent to the receiver one at a time. As in the case of sending, it
+    is often desirable to avoid this roundtrip for each message. This
+    can be achieved by allowing the receiver
+    to <em class="firstterm">prefetch</em> messages in anticipation of
+    fetch calls being made. The receiver needs to be able to store
+    these prefetched messages, the number it can hold is controlled by
+    the receivers capacity.</p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s07.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.5. Sender Capacity and Replay </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2.7. Acknowledging Received Messages</td></tr></table></div></body></html>

Modified: qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s07.html
URL: http://svn.apache.org/viewvc/qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s07.html?rev=967163&r1=967162&r2=967163&view=diff
==============================================================================
--- qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s07.html (original)
+++ qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s07.html Fri Jul 23 16:48:11 2010
@@ -1,42 +1,21 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>7. Request / Response</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s06.html" title="6. Receiving Messages from Multiple Sources"><link rel="next" href="ch02s08.html" title="8. Maps in Message Content"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">7. Request / Response</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s06.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s08.html">Next</a></td></tr></table><hr>
 </div><div class="section" title="7. Request / Response"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2744067"></a>7. Request / Response</h2></div></div></div><p>Request / Response applications use the reply-to property,
-      described in <a class="xref" href="ch02s13.html#table-amqp0-10-message-properties" title="Table 2.8. Mapping to AMQP 0-10 Message Properties">Table 2.8, &#8220;Mapping to AMQP 0-10 Message Properties&#8221;</a>, to allow a server
-      to respond to the client that sent a message. A server sets up a
-      service queue, with a name known to clients. A client creates a
-      private queue for the server's response, creates a message for a
-      request, sets the request's reply-to property to the address of
-      the client's response queue, and sends the request to the
-      service queue. The server sends the response to the address
-      specified in the request's reply-to property.
-      </p><div class="example"><a name="id2744102"></a><p class="title"><b>Example 2.13. Request / Response Applications in C++</b></p><div class="example-contents"><p>This example shows the C++ code for a client and server
-	that use the request / response pattern.</p><p>The server creates a service queue and waits for a
-	message to arrive. If it receives a message, it sends a
-	message back to the sender.</p><pre class="programlisting">Receiver receiver = session.createReceiver("service_queue; {create: always}");
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>2.7. Acknowledging Received Messages</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s06.html" title="2.6. Receiver Capacity (Prefetch)"><link rel="next" href="ch02s08.html" title="2.8. Receiving Messages from Multiple Sources"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">2.7. Acknowledging Received Messages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s06.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s
 08.html">Next</a></td></tr></table><hr></div><div class="section" title="2.7. Acknowledging Received Messages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="acknowledgements"></a>2.7. Acknowledging Received Messages</h2></div></div></div><p>Applications that receive messages should acknowledge their
+    receipt by calling the session's acknowledge method. As in the
+    case of sending messages, acknowledged transfer of messages to
+    receivers provides at-least-once reliability, which means that the
+    loss of the connection or a client crash does not result in lost
+    messages; durable messages are not lost even if the broker is
+    restarted.
 
-Message request = receiver.fetch();
-const Address&amp;amp; address = request.getReplyTo(); // Get "reply-to" from request ...
-if (address) {
-  Sender sender = session.createSender(address); // ... send response to "reply-to"
-  Message response("pong!");
-  sender.send(response);
-  session.acknowledge();
-}
-     </pre><p>The client creates a sender for the service queue, and
-	also creates a response queue that is deleted when the
-	client closes the receiver for the response queue. In the C++
-	client, if the address starts with the character
-	<code class="literal">#</code>, it is given a unique name.</p><pre class="programlisting">
-Sender sender = session.createSender("service_queue");
-
-Address responseQueue("#response-queue; {create:always, delete:always}");
-Receiver receiver = session.createReceiver(responseQueue);
-
-Message request;
-request.setReplyTo(responseQueue);
-request.setContent("ping");
-sender.send(request);
-Message response = receiver.fetch();
-std::cout &lt;&lt; request.getContent() &lt;&lt; " -&gt; " &lt;&lt; response.getContent() &lt;&lt; std::endl;
-	  </pre><p>The client sends the string <code class="literal">ping</code> to
-	the server. The server sends the response
-	<code class="literal">pong</code> back to the same client, using the
-	<code class="varname">replyTo</code> property.</p></div></div><br class="example-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s06.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s08.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">6. Receiving Messages from Multiple Sources </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 8. Maps in Message Content</td></tr></table></div></body></html>
+    Some cases may not require this however and the reliability can be
+    controlled through a link property in the address options (see
+    <a class="xref" href="ch02s04.html#table-link-properties" title="Table 2.3. Link Properties">Table 2.3, &#8220;Link Properties&#8221;</a>).</p><p>The acknowledge call acknowledges all messages received on
+    the session (i.e. all message that have been returned from a fetch
+    call on a receiver created on that session).</p><p>The acknowledge call also support an optional parameter
+    controlling whether the call is synchronous or not. A synchronous
+    acknowledge will block until the server has confirmed that it has
+    received the acknowledgement. In the asynchronous case, when the
+    call returns there is not yet any guarantee that the server has
+    received and processed the acknowledgement. The session may be
+    queried for the number of unsettled acknowledgements; when that
+    count is zero all acknowledgements made for received messages have
+    been successful.</p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s06.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s08.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.6. Receiver Capacity (Prefetch) </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2.8. Receiving Messages from Multiple Sources</td></tr></table></div></body></html>

Modified: qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s08.html
URL: http://svn.apache.org/viewvc/qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s08.html?rev=967163&r1=967162&r2=967163&view=diff
==============================================================================
--- qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s08.html (original)
+++ qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s08.html Fri Jul 23 16:48:11 2010
@@ -1,87 +1,37 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>8. Maps in Message Content</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s07.html" title="7. Request / Response"><link rel="next" href="ch02s09.html" title="9. Performance"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">8. Maps in Message Content</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s07.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s09.html">Next</a></td></tr></table><hr></div><div class="sectio
 n" title="8. Maps in Message Content"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section-Maps"></a>8. Maps in Message Content</h2></div></div></div><p>Many messaging applications need to exchange data across
-      languages and platforms, using the native datatypes of each
-      programming language. AMQP provides a set of portable datatypes,
-      but does not directly support a set of named type/value
-      pairs. Java JMS provides the <code class="classname">MapMessage</code>
-      interface, which allows sets of named type/value pairs, but does
-      not provide a set of portable datatypes.</p><p>The Qpid Messaging API supports maps in message
-      content. Unlike JMS, any message can contain maps. These maps
-      are supported in each language using the conventions of the
-      language. In Java, we implement the
-      <code class="classname">MapMessage</code> interface; in Python, we
-      support <code class="classname">dict</code> and
-      <code class="classname">list</code> in message content; in C++, we
-      provide the <code class="classname">Variant::Map</code> and
-      <code class="classname">Variant::List</code> classes to represent maps
-      and lists. In all languages, messages are encoded using AMQP's
-      portable datatypes.
-      </p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Because of the differences in type systems among
-      languages, the simplest way to provide portable messages is to
-      rely on maps, lists, strings, 64 bit signed integers, and
-      doubles for messages that need to be exchanged across languages
-      and platforms.</p></div><div class="section" title="8.1. Qpid Maps in Python"><div class="titlepage"><div><div><h3 class="title"><a name="section-Python-Maps"></a>8.1. Qpid Maps in Python</h3></div></div></div><p>In Python, Qpid supports the <code class="classname">dict</code> and <code class="classname">list</code> types directly in message content. The following code shows how to send these structures in a message:</p><div class="example"><a name="id2744275"></a><p class="title"><b>Example 2.14. Sending Qpid Maps in Python</b></p><div class="example-contents"><pre class="programlisting">
-from qpid.messaging import *
-# !!! SNIP !!!
-
-content = {'Id' : 987654321, 'name' : 'Widget', 'percent' : 0.99}
-content['colours'] = ['red', 'green', 'white']
-content['dimensions'] = {'length' : 10.2, 'width' : 5.1,'depth' : 2.0};
-content['parts'] = [ [1,2,5], [8,2,5] ]
-content['specs'] = {'colors' : content['colours'], 
-                    'dimensions' : content['dimensions'], 
-                    'parts' : content['parts'] }
-message = Message(content=content)
-sender.send(message)
-       </pre></div></div><br class="example-break"><p>The following table shows the datatypes that can be sent in a Python map message,
- and the corresponding datatypes that will be received by clients in Java or C++.</p><div class="table"><a name="table-Python-Maps"></a><p class="title"><b>Table 2.4. Python Datatypes in Maps</b></p><div class="table-contents"><table summary="Python Datatypes in Maps" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Python Datatype</th><th>&#8594; C++</th><th>&#8594; Java</th></tr></thead><tbody><tr><td>bool</td><td>bool</td><td>boolean</td></tr><tr><td>int</td><td>int64</td><td>long</td></tr><tr><td>long</td><td>int64</td><td>long</td></tr><tr><td>float</td><td>double</td><td>double</td></tr><tr><td>unicode</td><td>string</td><td>java.lang.String</td></tr><tr><td>uuid</td><td>qpid::types::Uuid</td><td>java.util.UUID</td></tr><tr><td>dict</td><td>Variant::Map</td><td>java.util.Map</td></tr><tr><td>list</td><td>Variant::List</td><td>java.util.List</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="8.2. Qpid Maps in C
 ++"><div class="titlepage"><div><div><h3 class="title"><a name="section-cpp-Maps"></a>8.2. Qpid Maps in C++</h3></div></div></div><p>In C++, Qpid defines the the
-	<code class="classname">Variant::Map</code> and
-	<code class="classname">Variant::List</code> types, which can be
-	encoded into message content. The following code shows how to
-	send these structures in a message:</p><div class="example"><a name="id2744416"></a><p class="title"><b>Example 2.15. Sending Qpid Maps in C++</b></p><div class="example-contents"><pre class="programlisting">
-using namespace qpid::types;
-
-// !!! SNIP !!!
-
-Message message;
-Variant::Map content;
-content["id"] = 987654321;
-content["name"] = "Widget";
-content["percent"] = 0.99;
-Variant::List colours;
-colours.push_back(Variant("red"));
-colours.push_back(Variant("green"));
-colours.push_back(Variant("white"));
-content["colours"] = colours;
-
-Variant::Map dimensions;
-dimensions["length"] = 10.2;
-dimensions["width"] = 5.1;
-dimensions["depth"] = 2.0;
-content["dimensions"]= dimensions; 
-
-Variant::List part1;
-part1.push_back(Variant(1));
-part1.push_back(Variant(2));
-part1.push_back(Variant(5));
- 
-Variant::List part2;
-part2.push_back(Variant(8));
-part2.push_back(Variant(2));
-part2.push_back(Variant(5));
- 
-Variant::List parts;
-parts.push_back(part1);
-parts.push_back(part2);
-content["parts"]= parts; 
-
-Variant::Map specs;
-specs["colours"] = colours; 
-specs["dimensions"] = dimensions; 
-specs["parts"] = parts; 
-content["specs"] = specs;
-
-encode(content, message);
-sender.send(message, true);
-     </pre></div></div><br class="example-break"><p>The following table shows the datatypes that can be sent
-	in a C++ map message, and the corresponding datatypes that
-	will be received by clients in Java and Python.</p><div class="table"><a name="table-cpp-Maps"></a><p class="title"><b>Table 2.5. C++ Datatypes in Maps</b></p><div class="table-contents"><table summary="C++ Datatypes in Maps" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>C++ Datatype</th><th>&#8594; Python</th><th>&#8594; Java</th></tr></thead><tbody><tr><td>bool</td><td>bool</td><td>boolean</td></tr><tr><td>uint16</td><td>int | long</td><td>short</td></tr><tr><td>uint32</td><td>int | long</td><td>int</td></tr><tr><td>uint64</td><td>int | long</td><td>long</td></tr><tr><td>int16</td><td>int | long</td><td>short</td></tr><tr><td>int32</td><td>int | long</td><td>int</td></tr><tr><td>int64</td><td>int | long</td><td>long</td></tr><tr><td>float</td><td>float</td><td>float</td></tr><tr><td>double</td><td>float</td><td>double</td></tr><tr><td>string</td><td>unicode</td><td>java.lang.String</td></tr><tr><td>qpid::types::Uuid</td><td>uuid</td><td>java.util.UUID</t
 d></tr><tr><td>Variant::Map</td><td>dict</td><td>java.util.Map</td></tr><tr><td>Variant::List</td><td>list</td><td>java.util.List</td></tr></tbody></table></div></div><br class="table-break"></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s07.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s09.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">7. Request / Response </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 9. Performance</td></tr></table></div></body></html>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>2.8. Receiving Messages from Multiple Sources</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s07.html" title="2.7. Acknowledging Received Messages"><link rel="next" href="ch02s09.html" title="2.9. Transactions"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">2.8. Receiving Messages from Multiple Sources</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s07.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s09.html
 ">Next</a></td></tr></table><hr></div><div class="section" title="2.8. Receiving Messages from Multiple Sources"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2543744"></a>2.8. Receiving Messages from Multiple Sources</h2></div></div></div><p>A receiver can only read from one source, but many
+      programs need to be able to read messages from many sources. In
+      the Qpid Messaging API, a program can ask a session for
+      the <span class="quote">&#8220;<span class="quote">next receiver</span>&#8221;</span>; that is, the receiver that is
+      responsible for the next available message. The following
+      example shows how this is done in C++, Python, and .NET C#.
+      </p><p>Note that to use this pattern you must enable prefetching
+      for each receiver of interest so that the broker will send
+      messages before a fetch call is made. See
+      <a class="xref" href="ch02s06.html" title="2.6. Receiver Capacity (Prefetch)">Section 2.6, &#8220;Receiver Capacity (Prefetch)&#8221;</a> for more on this.</p><div class="example"><a name="id2543776"></a><p class="title"><b>Example 2.12. Receiving Messages from Multiple Sources</b></p><div class="example-contents"><p>C++:</p><pre class="programlisting">
+Receiver receiver1 = session.createReceiver(address1);
+receiver1.setCapacity(10);
+Receiver receiver2 = session.createReceiver(address2);
+receiver2.setCapacity(10);
+
+Message message =  session.nextReceiver().fetch();
+std::cout &lt;&lt; message.getContent() &lt;&lt; std::endl;
+session.acknowledge(); // acknowledge message receipt
+	  </pre><p>Python:</p><pre class="programlisting">
+receiver1 = session.receiver(address1)
+receiver1.capacity = 10
+receiver2 = session.receiver(address)
+receiver2.capacity = 10
+message = session.next_receiver().fetch()
+print message.content
+session.acknowledge()
+	  </pre><p>.NET C#:</p><pre class="programlisting">
+Receiver receiver1 = session.CreateReceiver(address1);
+receiver1.SetCapacity(10);
+Receiver receiver2 = session.CreateReceiver(address2);
+receiver2.SetCapacity(10);
+
+Message message = new Message();
+message =  session.NextReceiver().Fetch();
+Console.WriteLine("{0}", message.GetContent());
+session.Acknowledge();
+	  </pre></div></div><br class="example-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s07.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s09.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.7. Acknowledging Received Messages </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2.9. Transactions</td></tr></table></div></body></html>

Modified: qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s09.html
URL: http://svn.apache.org/viewvc/qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s09.html?rev=967163&r1=967162&r2=967163&view=diff
==============================================================================
--- qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s09.html (original)
+++ qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s09.html Fri Jul 23 16:48:11 2010
@@ -1,18 +1,23 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>9. Performance</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s08.html" title="8. Maps in Message Content"><link rel="next" href="ch02s10.html" title="10. Reliability"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">9. Performance</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s08.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s10.html">Next</a></td></tr></table><hr></div><div class="section" title="9. Perf
 ormance"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2727808"></a>9. Performance</h2></div></div></div><p>
-         Clients can often be made significantly faster by batching acknowledgements and setting the capacity of receivers to allow prefetch. The size of a sender's replay buffer can also affect performance.
-      </p><div class="section" title="9.1. Batching Acknowledgements"><div class="titlepage"><div><div><h3 class="title"><a name="id2727820"></a>9.1. Batching Acknowledgements</h3></div></div></div><p>Many of the simple examples we have shown retrieve a message and immediately acknowledge it. Because each acknowledgement results in network traffic, you can dramatically increase performance by acknowledging messages in batches. For instance, an application can read a number of related messages, then acknowledge the entire batch, or an application can acknowledge after a certain number of messages have been received or a certain time period has elapsed. Messages are not removed from the broker until they are acknowledged, so guaranteed delivery is still available when batching acknowledgements.</p></div><div class="section" title="9.2. Prefetch"><div class="titlepage"><div><div><h3 class="title"><a name="id2727840"></a>9.2. Prefetch</h3></div></div></div><p>By default, a r
 eceiver retrieves the next message from the server, one message at a time, which provides intuitive results when writing and debugging programs, but does not provide optimum performance. To create an input buffer, set the capacity of the receiver to the size of the desired input buffer; for many applications, a capacity of 100 performs well. </p><div class="example"><a name="id2787506"></a><p class="title"><b>Example 2.16. Prefetch</b></p><div class="example-contents"><p>C++</p><pre class="programlisting">
-Receiver receiver = session.createReceiver(address);
-receiver.setCapacity(100);
-Message message = receiver.fetch();
-	  </pre></div></div><br class="example-break"></div><div class="section" title="9.3. Sizing the Replay Buffer"><div class="titlepage"><div><div><h3 class="title"><a name="id2787527"></a>9.3. Sizing the Replay Buffer</h3></div></div></div><p>In order to guarantee delivery, a sender automatically
-	keeps messages in a replay buffer until the messaging broker
-	acknowledges that they have been received. The replay buffer
-	is held in memory, and is never paged to disk. For most
-	applications, the default size of the replay buffer works
-	well. A large replay buffer requires more memory, a small
-	buffer can slow down the client because it can not send new
-	messages if the replay buffer is full, and must wait for
-	existing sends to be acknowledged.</p><div class="example"><a name="id2787544"></a><p class="title"><b>Example 2.17. Sizing the Replay Buffer</b></p><div class="example-contents"><p>C++</p><pre class="programlisting">
-Sender sender = session.createSender(address);
-sender.setCapacity(100);
-	  </pre></div></div><br class="example-break"></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s08.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s10.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">8. Maps in Message Content </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 10. Reliability</td></tr></table></div></body></html>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>2.9. Transactions</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s08.html" title="2.8. Receiving Messages from Multiple Sources"><link rel="next" href="ch02s10.html" title="2.10. Connection Options"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">2.9. Transactions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s08.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s10.html">Next</a></td></tr></table><hr></div><d
 iv class="section" title="2.9. Transactions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2543829"></a>2.9. Transactions</h2></div></div></div><p>Sometimes it is useful to be able to group messages
+      transfers - sent and/or received - on a session into atomic
+      grouping. This can be done be creating the session as
+      transactional. On a transactional session sent messages only
+      become available at the target address on commit. Likewise any
+      received and acknowledged messages are only discarded at their
+      source on commit
+
+      <sup>[<a name="id2544129" href="#ftn.id2544129" class="footnote">7</a>]</sup>
+
+      .</p><div class="example"><a name="id2544139"></a><p class="title"><b>Example 2.13. Transactions</b></p><div class="example-contents"><p>C++:</p><pre class="programlisting">
+Connection connection(broker);
+Session session =  connection.createTransactionalSession();
+...
+if (smellsOk())
+   session.commit();
+else 
+   session.rollback();
+   </pre></div></div><br class="example-break"><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id2544129" href="#id2544129" class="para">7</a>] </sup>Note that this currently is only true for
+      messages received using a reliable mode
+      e.g. at-least-once. Messages sent by a broker to a receiver in
+      unreliable receiver will be discarded immediately regardless of
+      transctionality.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s08.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s10.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.8. Receiving Messages from Multiple Sources </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2.10. Connection Options</td></tr></table></div></body></html>

Modified: qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s10.html
URL: http://svn.apache.org/viewvc/qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s10.html?rev=967163&r1=967162&r2=967163&view=diff
==============================================================================
--- qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s10.html (original)
+++ qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s10.html Fri Jul 23 16:48:11 2010
@@ -1,76 +1,91 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>10. Reliability</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s09.html" title="9. Performance"><link rel="next" href="ch02s11.html" title="11. Security"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">10. Reliability</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s09.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s11.html">Next</a></td></tr></table><hr></div><div class="section" title="10. Reliability"><di
 v class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2787563"></a>10. Reliability</h2></div></div></div><p>The Qpid Messaging API supports automatic reconnect, guaranteed delivery via persistent messages, reliability options in senders and receivers, and cluster failover. This section shows how programs can take advantage of these features.</p><div class="section" title="10.1. Reconnect"><div class="titlepage"><div><div><h3 class="title"><a name="id2787575"></a>10.1. Reconnect</h3></div></div></div><p>Connections in the Qpid Messaging API support automatic
-	reconnect if a connection is lost. This is done using connection
-	options. The following example shows how to use connection options in C++ and Python.</p><div class="example"><a name="id2787587"></a><p class="title"><b>Example 2.18. Specifying Connection Options in C++ and Python</b></p><div class="example-contents"><p>In C++, these options are set using <code class="function">Connection::setOption()</code>:</p><pre class="programlisting">
-Connection connection(broker);
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>2.10. Connection Options</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s09.html" title="2.9. Transactions"><link rel="next" href="ch02s11.html" title="2.11. Maps in Message Content"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">2.10. Connection Options</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s09.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s11.html">Next</a></td></tr></table><hr></div><div class=
 "section" title="2.10. Connection Options"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="connection-options"></a>2.10. Connection Options</h2></div></div></div><p>
+        Aspects of the connections behaviour can be controlled through
+        specifying connection options. For example, connections can be
+        configured to automatically reconnect if the connection to a
+        broker is lost.
+      </p><div class="example"><a name="id2544178"></a><p class="title"><b>Example 2.14. Specifying Connection Options in C++ and Python</b></p><div class="example-contents"><p>In C++, these options can be set using <code class="function">Connection::setOption()</code> or by passing in a set of options to the constructor. The options can be passed in as a map or in string form:</p><pre class="programlisting">
+Connection connection("localhost:5672", "{reconnect: true}");
+try {
+    connection.open();
+    !!! SNIP !!!
+    </pre><p>or</p><pre class="programlisting">
+Connection connection("localhost:5672");
 connection.setOption("reconnect", true);
 try {
     connection.open();
     !!! SNIP !!!
-    </pre><p>In Python, these options are set using named arguments in
+    </pre><p>In Python, these options can be set as attributes of the connection or using named arguments in
 	  the <code class="function">Connection</code> constructor:</p><pre class="programlisting">
 connection = Connection("localhost:5672", reconnect=True)
 try:
   connection.open()
   !!! SNIP !!!
-  </pre><p>See the reference documentation for details on how to set
-	  these on connections for each language.</p></div></div><br class="example-break"><p>The following table lists the connection options that can
-	be used.</p><div class="table"><a name="id2787637"></a><p class="title"><b>Table 2.6. Connection Options</b></p><div class="table-contents"><table summary="Connection Options" width="100%" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>option</th><th>value</th><th>semantics</th></tr></thead><tbody><tr><td>
+  </pre>
+
+or 
+
+	  <pre class="programlisting">
+connection = Connection("localhost:5672")
+connection.reconnect = True
+try:
+  connection.open()
+  !!! SNIP !!!
+  </pre><p>See the reference documentation for details in each language.</p></div></div><br class="example-break"><p>The following table lists the supported connection options.</p><div class="table"><a name="id2544252"></a><p class="title"><b>Table 2.4. Connection Options</b></p><div class="table-contents"><table summary="Connection Options" width="100%" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>option name</th><th>value type</th><th>semantics</th></tr></thead><tbody><tr><td>
+		  username
+		</td><td>
+		  string
+		</td><td>
+		  The username to use when authenticating to the broker.
+		</td></tr><tr><td>
+		  password
+		</td><td>
+		  string
+		</td><td>
+		  The password to use when authenticating to the broker.
+		</td></tr><tr><td>
+		  sasl-mechanism
+		</td><td>
+		  string
+		</td><td>
+		  The specific SASL mechanism to use when
+		  authenticating to the broker. In c++ only a single
+		  value can be specified at present. In python the
+		  value can be a space separated list in order of
+		  preference.
+		</td></tr><tr><td>
 		  reconnect
 		</td><td>
-		  True, False
+		  boolean
 		</td><td>
 		  Transparently reconnect if the connection is lost.
 		</td></tr><tr><td>
 		  reconnect_timeout
 		</td><td>
-		  N
+		  integer
 		</td><td>
 		  Total number of seconds to continue reconnection attempts before giving up and raising an exception.
 		</td></tr><tr><td>
 		  reconnect_limit
 		</td><td>
-		  N
+		  integer
 		</td><td>
 		  Maximum number of reconnection attempts before giving up and raising an exception.
 		</td></tr><tr><td>
 		  reconnect_interval_min
 		</td><td>
-		  N
+		  integer representing time in seconds
 		</td><td>
 		  Minimum number of seconds between reconnection attempts. The first reconnection attempt is made immediately; if that fails, the first reconnection delay is set to the value of <code class="literal">reconnect_interval_min</code>; if that attempt fails, the reconnect interval increases exponentially until a reconnection attempt succeeds or <code class="literal">reconnect_interval_max</code> is reached.
 		</td></tr><tr><td>
 		  reconnect_interval_max
 		</td><td>
-		  N
+		  integer representing time in seconds
 		</td><td>
 		  Maximum reconnect interval.
 		</td></tr><tr><td>
 		  reconnect_interval
 		</td><td>
-		  N
+		  integer representing time in seconds
 		</td><td>
 		  Sets both <code class="literal">reconnection_interval_min</code> and <code class="literal">reconnection_interval_max</code> to the same value.
-		</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="10.2. Guaranteed Delivery"><div class="titlepage"><div><div><h3 class="title"><a name="id2787798"></a>10.2. Guaranteed Delivery</h3></div></div></div><p>If a queue is durable, the queue survives a messaging
-	broker crash, as well as any durable messages that have been
-	placed on the queue. These messages will be delivered when the
-	messaging broker is restarted. Delivery is guaranteed if and
-	only if both the message and the queue are durable. Guaranteed
-	delivery requires a persistence module, such as the one
-	available from <a class="ulink" href="http://QpidComponents.org" target="_top">QpidComponents.org</a>.</p><div class="example"><a name="id2787818"></a><p class="title"><b>Example 2.19. Guaranteed Delivery</b></p><div class="example-contents"><p>C++:</p><pre class="programlisting">
-Sender sender = session.createSender("durable-queue");
-
-Message message("Hello world!");
-message.setDurable(1);
-
-sender.send(Message("Hello world!"));
-</pre></div></div><br class="example-break"></div><div class="section" title="10.3. Reliability Options in Senders and Receivers"><div class="titlepage"><div><div><h3 class="title"><a name="id2787839"></a>10.3. Reliability Options in Senders and Receivers</h3></div></div></div><p>When creating a sender or a receiver, you can specify a reliability option in the address string. For instance, the following specifies <code class="literal">at-least-once</code> as the reliability mode for a sender:</p><pre class="programlisting">
-Sender = session.createSender("topic;{create:always,link:{reliability:at-least-once}}");
-	</pre><p>The modes <code class="literal">unreliable</code>, <code class="literal">at-most-once</code>, <code class="literal">at-least-once</code>, and <code class="literal">exactly-once</code> are supported. These modes govern the reliability of the connection between the client and the messaging broker.</p><p>The modes <code class="literal">unreliable</code> and <code class="literal">at-most-once</code> are currently synonyms. In a receiver, this mode means that messages received on an auto-delete subscription queue may be lost in the event of a broker failure. In a sender, this mode means that the sender can consider a message sent as soon as it is written to the wire, and need not wait for broker acknowledgement before considering the message sent.</p><p>The mode <code class="literal">at-most-once</code> ensures that messages are not lost, but duplicates of a message may occur. In a receiver, this mode ensures that messages are not lost in event of a broker failure. In a
  sender, this means that messages are kept in a replay buffer after they have been sent, and removed from this buffer only after the broker acknowledges receipt; if a broker failure occurs, messages in the replay buffer are resent upon reconnection. The mode <code class="literal">exactly-once</code> is similar to <code class="literal">at-most-once</code>, but eliminates duplicate messages.</p></div><div class="section" title="10.4. Cluster Failover"><div class="titlepage"><div><div><h3 class="title"><a name="id2787939"></a>10.4. Cluster Failover</h3></div></div></div><p>The messaging broker can be run in clustering mode, which provides high reliability at-least-once messaging. If one broker in a cluster fails, clients can choose another broker in the cluster and continue their work.</p><p>In C++, the <code class="classname">FailoverUpdates</code> class keeps track of the brokers in a cluster, so a reconnect can select another broker in the cluster to connect to:</p><div cl
 ass="example"><a name="id2787960"></a><p class="title"><b>Example 2.20. Cluster Failover in C++</b></p><div class="example-contents"><pre class="programlisting">
-#include &lt;qpid/messaging/FailoverUpdates.h&gt;
-...
-Connection connection(broker);
-connection.setOption("reconnect", true);
-try {
-    connection.open();
-    std::auto_ptr&lt;FailoverUpdates&gt; updates(new FailoverUpdates(connection));
-	</pre></div></div><br class="example-break"></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s09.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s11.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">9. Performance </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 11. Security</td></tr></table></div></body></html>
+		</td></tr></tbody></table></div></div><br class="table-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s09.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s11.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.9. Transactions </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2.11. Maps in Message Content</td></tr></table></div></body></html>

Modified: qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s11.html
URL: http://svn.apache.org/viewvc/qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s11.html?rev=967163&r1=967162&r2=967163&view=diff
==============================================================================
--- qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s11.html (original)
+++ qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s11.html Fri Jul 23 16:48:11 2010
@@ -1,39 +1,164 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>11. Security</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s10.html" title="10. Reliability"><link rel="next" href="ch02s12.html" title="12. Transactions"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">11. Security</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s10.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s12.html">Next</a></td></tr></table><hr></div><div class="section" title="11. Security"><div cl
 ass="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2787972"></a>11. Security</h2></div></div></div><p>Qpid provides authentication, rule-based authorization, encryption, and digital signing.</p><p>Authentication is done using Simple Authentication and
-      Security Layer (SASL) to authenticate client connections to the
-      broker. SASL is a framework that supports a variety of
-      authentication methods. For secure applications, we suggest
-      CRAM-MD5, DIGEST-MD5, or GSSAPI (Kerberos). The ANONYMOUS method
-      is not secure. The PLAIN method is secure only when used
-      together with SSL.</p><p>To enable Kerberos in a client, set the <code class="varname">sals-mechanism</code> connection option to <code class="literal">GSSAPI</code>:</p><pre class="programlisting">
-Connection connection(broker);
-connection.setOption("sasl-mechanism", "GSSAPI");
-try {
-    connection.open();
-    ...
-      </pre><p>For Kerberos authentication, if the user running the
-      program is already authenticated, e.g. using
-      <span class="command"><strong>kinit</strong></span>, there is no need to supply a user name
-      or password. If you are using another form of authentication, or are not already authenticated with Kerberos, you can supply these as connection options:</p><pre class="programlisting">
-connection.setOption("username", "mick");
-connection.setOption("password", "pa$$word");
-      </pre><p>Encryption and signing are done using SSL (they can also be done using SASL, but SSL provides stronger encryption). To enable SSL, set the <code class="varname">protocol</code> connection option to <code class="literal">ssl</code>:</p><pre class="programlisting">
-connection.setOption("protocol", "ssl");
-      </pre><p>Use the following environment variables to configure the SSL client:</p><div class="table"><a name="id2788074"></a><p class="title"><b>Table 2.7. SSL Client Environment Variables for C++ clients</b></p><div class="table-contents"><table summary="SSL Client Environment Variables for C++ clients" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th colspan="2" align="center">
-		SSL Client Options for C++ clients
-	      </th></tr></thead><tbody><tr><td align="left">
-		<span class="command"><strong>SSL_USE_EXPORT_POLICY</strong></span>
-	      </td><td align="left">
-		Use NSS export policy
-	      </td></tr><tr><td align="left">
-		<span class="command"><strong>SSL_CERT_PASSWORD_FILE <em class="replaceable"><code>PATH</code></em></strong></span>
-	      </td><td align="left">
-		File containing password to use for accessing certificate database
-	      </td></tr><tr><td align="left">
-		<span class="command"><strong>SSL_CERT_DB <em class="replaceable"><code>PATH</code></em></strong></span>
-	      </td><td align="left">
-		Path to directory containing certificate database
-	      </td></tr><tr><td align="left">
-		<span class="command"><strong>SSL_CERT_NAME <em class="replaceable"><code>NAME</code></em></strong></span>
-	      </td><td align="left">
-		Name of the certificate to use. When SSL client authentication is enabled, a certificate name should normally be provided.
-	      </td></tr></tbody></table></div></div><br class="table-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s10.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s12.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">10. Reliability </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 12. Transactions</td></tr></table></div></body></html>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>2.11. Maps in Message Content</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s10.html" title="2.10. Connection Options"><link rel="next" href="ch02s12.html" title="2.12. The Request / Response Pattern"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">2.11. Maps in Message Content</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s10.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s12.html">Next</a></td></tr></tab
 le><hr></div><div class="section" title="2.11. Maps in Message Content"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section-Maps"></a>2.11. Maps in Message Content</h2></div></div></div><p>Many messaging applications need to exchange data across
+      languages and platforms, using the native datatypes of each
+      programming language.</p><p>The Qpid Messaging API supports maps in message
+      content. 
+
+      <sup>[<a name="id2587005" href="#ftn.id2587005" class="footnote">8</a>]</sup>
+
+      These maps are supported in each language using
+      the conventions of the language. In Java, we implement the
+      <code class="classname">MapMessage</code> interface
+  
+      <sup>[<a name="id2587016" href="#ftn.id2587016" class="footnote">9</a>]</sup>
+
+      ; in Python, we
+      support <code class="classname">dict</code> and
+      <code class="classname">list</code> in message content; in C++, we
+      provide the <code class="classname">Variant::Map</code> and
+      <code class="classname">Variant::List</code> classes to represent maps
+      and lists. In all languages, messages are encoded using AMQP's
+      portable datatypes.
+      </p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Because of the differences in type systems among
+      languages, the simplest way to provide portable messages is to
+      rely on maps, lists, strings, 64 bit signed integers, and
+      doubles for messages that need to be exchanged across languages
+      and platforms.</p></div><div class="section" title="2.11.1. Qpid Maps in Python"><div class="titlepage"><div><div><h3 class="title"><a name="section-Python-Maps"></a>2.11.1. Qpid Maps in Python</h3></div></div></div><p>In Python, Qpid supports the <code class="classname">dict</code> and <code class="classname">list</code> types directly in message content. The following code shows how to send these structures in a message:</p><div class="example"><a name="id2587071"></a><p class="title"><b>Example 2.15. Sending Qpid Maps in Python</b></p><div class="example-contents"><pre class="programlisting">
+from qpid.messaging import *
+# !!! SNIP !!!
+
+content = {'Id' : 987654321, 'name' : 'Widget', 'percent' : 0.99}
+content['colours'] = ['red', 'green', 'white']
+content['dimensions'] = {'length' : 10.2, 'width' : 5.1,'depth' : 2.0};
+content['parts'] = [ [1,2,5], [8,2,5] ]
+content['specs'] = {'colors' : content['colours'], 
+                    'dimensions' : content['dimensions'], 
+                    'parts' : content['parts'] }
+message = Message(content=content)
+sender.send(message)
+       </pre></div></div><br class="example-break"><p>The following table shows the datatypes that can be sent in a Python map message,
+ and the corresponding datatypes that will be received by clients in Java or C++.</p><div class="table"><a name="table-Python-Maps"></a><p class="title"><b>Table 2.5. Python Datatypes in Maps</b></p><div class="table-contents"><table summary="Python Datatypes in Maps" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Python Datatype</th><th>&#8594; C++</th><th>&#8594; Java</th></tr></thead><tbody><tr><td>bool</td><td>bool</td><td>boolean</td></tr><tr><td>int</td><td>int64</td><td>long</td></tr><tr><td>long</td><td>int64</td><td>long</td></tr><tr><td>float</td><td>double</td><td>double</td></tr><tr><td>unicode</td><td>string</td><td>java.lang.String</td></tr><tr><td>uuid</td><td>qpid::types::Uuid</td><td>java.util.UUID</td></tr><tr><td>dict</td><td>Variant::Map</td><td>java.util.Map</td></tr><tr><td>list</td><td>Variant::List</td><td>java.util.List</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="2.11.2. Qpid Maps i
 n C++"><div class="titlepage"><div><div><h3 class="title"><a name="section-cpp-Maps"></a>2.11.2. Qpid Maps in C++</h3></div></div></div><p>In C++, Qpid defines the the
+	<code class="classname">Variant::Map</code> and
+	<code class="classname">Variant::List</code> types, which can be
+	encoded into message content. The following code shows how to
+	send these structures in a message:</p><div class="example"><a name="id2587242"></a><p class="title"><b>Example 2.16. Sending Qpid Maps in C++</b></p><div class="example-contents"><pre class="programlisting">
+using namespace qpid::types;
+
+// !!! SNIP !!!
+
+Message message;
+Variant::Map content;
+content["id"] = 987654321;
+content["name"] = "Widget";
+content["percent"] = 0.99;
+Variant::List colours;
+colours.push_back(Variant("red"));
+colours.push_back(Variant("green"));
+colours.push_back(Variant("white"));
+content["colours"] = colours;
+
+Variant::Map dimensions;
+dimensions["length"] = 10.2;
+dimensions["width"] = 5.1;
+dimensions["depth"] = 2.0;
+content["dimensions"]= dimensions; 
+
+Variant::List part1;
+part1.push_back(Variant(1));
+part1.push_back(Variant(2));
+part1.push_back(Variant(5));
+ 
+Variant::List part2;
+part2.push_back(Variant(8));
+part2.push_back(Variant(2));
+part2.push_back(Variant(5));
+ 
+Variant::List parts;
+parts.push_back(part1);
+parts.push_back(part2);
+content["parts"]= parts; 
+
+Variant::Map specs;
+specs["colours"] = colours; 
+specs["dimensions"] = dimensions; 
+specs["parts"] = parts; 
+content["specs"] = specs;
+
+encode(content, message);
+sender.send(message, true);
+     </pre></div></div><br class="example-break"><p>The following table shows the datatypes that can be sent
+	in a C++ map message, and the corresponding datatypes that
+	will be received by clients in Java and Python.</p><div class="table"><a name="table-cpp-Maps"></a><p class="title"><b>Table 2.6. C++ Datatypes in Maps</b></p><div class="table-contents"><table summary="C++ Datatypes in Maps" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>C++ Datatype</th><th>&#8594; Python</th><th>&#8594; Java</th></tr></thead><tbody><tr><td>bool</td><td>bool</td><td>boolean</td></tr><tr><td>uint16</td><td>int | long</td><td>short</td></tr><tr><td>uint32</td><td>int | long</td><td>int</td></tr><tr><td>uint64</td><td>int | long</td><td>long</td></tr><tr><td>int16</td><td>int | long</td><td>short</td></tr><tr><td>int32</td><td>int | long</td><td>int</td></tr><tr><td>int64</td><td>int | long</td><td>long</td></tr><tr><td>float</td><td>float</td><td>float</td></tr><tr><td>double</td><td>float</td><td>double</td></tr><tr><td>string</td><td>unicode</td><td>java.lang.String</td></tr><tr><td>qpid::types::Uuid</td><td>uuid</td><td>java.util.UUID</t
 d></tr><tr><td>Variant::Map</td><td>dict</td><td>java.util.Map</td></tr><tr><td>Variant::List</td><td>list</td><td>java.util.List</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="2.11.3. Qpid Maps in .NET"><div class="titlepage"><div><div><h3 class="title"><a name="section-dotnet-Maps"></a>2.11.3. Qpid Maps in .NET</h3></div></div></div><p>
+	  The .NET binding for the Qpid Messaging API binds .NET managed data types
+	  to C++ <code class="classname">Variant</code> data types.  The following code shows how to
+	  send Map and List structures in a message:
+	</p><div class="example"><a name="id2587455"></a><p class="title"><b>Example 2.17. Sending Qpid Maps in .NET C#</b></p><div class="example-contents"><pre class="programlisting">
+using System;
+using Org.Apache.Qpid.Messaging;
+
+// !!! SNIP !!!
+
+Dictionary&lt;string, object&gt; content = new Dictionary&lt;string, object&gt;();
+Dictionary&lt;string, object&gt; subMap = new Dictionary&lt;string, object&gt;();
+Collection&lt;object&gt; colors = new Collection&lt;object&gt;();
+
+// add simple types
+content["id"] = 987654321;
+content["name"] = "Widget";
+content["percent"] = 0.99;
+
+// add nested amqp/map
+subMap["name"] = "Smith";
+subMap["number"] = 354;
+content["nestedMap"] = subMap;
+
+// add an amqp/list
+colors.Add("red");
+colors.Add("green");
+colors.Add("white");
+content["colorsList"] = colors;
+
+// add one of each supported amqp data type
+bool mybool = true;
+content["mybool"] = mybool;
+
+byte mybyte = 4;
+content["mybyte"] = mybyte;
+
+UInt16 myUInt16 = 5;
+content["myUInt16"] = myUInt16;
+
+UInt32 myUInt32 = 6;
+content["myUInt32"] = myUInt32;
+
+UInt64 myUInt64 = 7;
+content["myUInt64"] = myUInt64;
+
+char mychar = 'h';
+content["mychar"] = mychar;
+
+Int16 myInt16 = 9;
+content["myInt16"] = myInt16;
+
+Int32 myInt32 = 10;
+content["myInt32"] = myInt32;
+
+Int64 myInt64 = 11;
+content["myInt64"] = myInt64;
+
+Single mySingle = (Single)12.12;
+content["mySingle"] = mySingle;
+
+Double myDouble = 13.13;
+content["myDouble"] = myDouble;
+
+Guid myGuid = new Guid("000102030405060708090a0b0c0d0e0f");
+content["myGuid"] = myGuid;
+
+Message message = new Message(content);
+Send(message, true);
+     </pre></div></div><br class="example-break"><p>
+	  The following table shows the mapping between datatypes in .NET and C++.
+	</p><div class="table"><a name="table-dotnet-Maps"></a><p class="title"><b>Table 2.7. Datatype Mapping between C++ and .NET binding</b></p><div class="table-contents"><table summary="Datatype Mapping between C++ and .NET binding" border="1"><colgroup><col><col></colgroup><thead><tr><th>C++ Datatype</th><th>&#8594; .NET binding</th></tr></thead><tbody><tr><td>bool</td><td>bool</td></tr><tr><td>uint8</td><td>byte</td></tr><tr><td>uint16</td><td>UInt16</td></tr><tr><td>uint32</td><td>UInt32</td></tr><tr><td>uint64</td><td>UInt64</td></tr><tr><td>uint8</td><td>char</td></tr><tr><td>int16</td><td>Int16</td></tr><tr><td>int32</td><td>Int32</td></tr><tr><td>int64</td><td>Int64</td></tr><tr><td>float</td><td>Single</td></tr><tr><td>double</td><td>Double</td></tr><tr><td>string</td><td>string  <a class="co" name="mapping-dotnet-string" href="ch02s11.html#callout-dotnet-string">(1)</a></td></tr><tr><td>qpid::types::Uuid</td><td>Guid</td></tr><tr><td>Variant::Map</td><td>Dictionary&
 lt;string, object&gt;  <a class="co" name="mapping-dotnet-dict-index" href="ch02s11.html#callout-dotnet-string">(2)</a></td></tr><tr><td>Variant::List</td><td>Collection&lt;object&gt;  <a class="co" name="mapping-dotnet-list-value" href="ch02s11.html#callout-dotnet-string">(3)</a></td></tr></tbody></table></div></div><br class="table-break"><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a name="callout-dotnet-string"></a><a href="#mapping-dotnet-string">(1)</a> </p></td><td valign="top" align="left"><p>Strings are currently interpreted only with UTF-8 encoding.</p></td></tr></table></div></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id2587005" href="#id2587005" class="para">8</a>] </sup>Unlike JMS, there is not a specific message type for
+      map messages.</p></div><div class="footnote"><p><sup>[<a name="ftn.id2587016" href="#id2587016" class="para">9</a>] </sup>Note that the Qpid JMS client supports
+      MapMessages whose values can be nested maps or lists. This is
+      not standard JMS behaviour.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s10.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s12.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.10. Connection Options </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2.12. The Request / Response Pattern</td></tr></table></div></body></html>

Modified: qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s12.html
URL: http://svn.apache.org/viewvc/qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s12.html?rev=967163&r1=967162&r2=967163&view=diff
==============================================================================
--- qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s12.html (original)
+++ qpid/site/docs/books/0.7/Programming-In-Apache-Qpid/html/ch02s12.html Fri Jul 23 16:48:11 2010
@@ -1,17 +1,42 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>12. Transactions</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s11.html" title="11. Security"><link rel="next" href="ch02s13.html" title="13. The AMQP 0-10 mapping"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">12. Transactions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s11.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s13.html">Next</a></td></tr></table><hr></div><div class="section" title="12. Tra
 nsactions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2788193"></a>12. Transactions</h2></div></div></div><p>In AMQP, transactions cover the semantics of enqueues and
-      dequeues.</p><p>When sending messages, a transaction tracks enqueues
-      without actually delivering the messages, a commit places
-      messages on their queues, and a rollback discards the
-      enqueues.</p><p>When receiving messages, a transaction tracks dequeues
-      without actually removing acknowledged messages, a commit
-      removes all acknowledged messages, and a rollback discards
-      acknowledgements. A rollback does not release the message, it
-      must be explicitly released to return it to the queue.</p><div class="example"><a name="id2788218"></a><p class="title"><b>Example 2.21. Transactions</b></p><div class="example-contents"><p>C++:</p><pre class="programlisting">
-Connection connection(broker);
-Session session =  connection.createTransactionalSession();
-...
-if (smellsOk())
-   session.commit();
-else 
-   session.rollback();
-   </pre></div></div><br class="example-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s11.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s13.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">11. Security </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 13. The AMQP 0-10 mapping</td></tr></table></div></body></html>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>2.12. The Request / Response Pattern</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Programming in Apache Qpid"><link rel="up" href="ch02.html" title="Chapter 2. Using the Qpid Messaging API"><link rel="prev" href="ch02s11.html" title="2.11. Maps in Message Content"><link rel="next" href="ch02s13.html" title="2.13. Performance Tips"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">2.12. The Request / Response Pattern</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s11.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Using the Qpid Messaging API</th><td width="20%" align="right"> <a accesskey="n" href="ch02s13.html">Next</a></td></tr>
 </table><hr></div><div class="section" title="2.12. The Request / Response Pattern"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2587681"></a>2.12. The Request / Response Pattern</h2></div></div></div><p>Request / Response applications use the reply-to property,
+      described in <a class="xref" href="ch02s16.html#table-amqp0-10-message-properties" title="Table 2.8. Mapping to AMQP 0-10 Message Properties">Table 2.8, &#8220;Mapping to AMQP 0-10 Message Properties&#8221;</a>, to allow a server
+      to respond to the client that sent a message. A server sets up a
+      service queue, with a name known to clients. A client creates a
+      private queue for the server's response, creates a message for a
+      request, sets the request's reply-to property to the address of
+      the client's response queue, and sends the request to the
+      service queue. The server sends the response to the address
+      specified in the request's reply-to property.
+      </p><div class="example"><a name="id2587705"></a><p class="title"><b>Example 2.18. Request / Response Applications in C++</b></p><div class="example-contents"><p>This example shows the C++ code for a client and server
+	that use the request / response pattern.</p><p>The server creates a service queue and waits for a
+	message to arrive. If it receives a message, it sends a
+	message back to the sender.</p><pre class="programlisting">Receiver receiver = session.createReceiver("service_queue; {create: always}");
+
+Message request = receiver.fetch();
+const Address&amp;amp; address = request.getReplyTo(); // Get "reply-to" from request ...
+if (address) {
+  Sender sender = session.createSender(address); // ... send response to "reply-to"
+  Message response("pong!");
+  sender.send(response);
+  session.acknowledge();
+}
+     </pre><p>The client creates a sender for the service queue, and
+	also creates a response queue that is deleted when the
+	client closes the receiver for the response queue. In the C++
+	client, if the address starts with the character
+	<code class="literal">#</code>, it is given a unique name.</p><pre class="programlisting">
+Sender sender = session.createSender("service_queue");
+
+Address responseQueue("#response-queue; {create:always, delete:always}");
+Receiver receiver = session.createReceiver(responseQueue);
+
+Message request;
+request.setReplyTo(responseQueue);
+request.setContent("ping");
+sender.send(request);
+Message response = receiver.fetch();
+std::cout &lt;&lt; request.getContent() &lt;&lt; " -&gt; " &lt;&lt; response.getContent() &lt;&lt; std::endl;
+	  </pre><p>The client sends the string <code class="literal">ping</code> to
+	the server. The server sends the response
+	<code class="literal">pong</code> back to the same client, using the
+	<code class="varname">replyTo</code> property.</p></div></div><br class="example-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02s11.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s13.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.11. Maps in Message Content </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 2.13. Performance Tips</td></tr></table></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