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 @@ -6. Receiving Messages from Multiple Sources +2.6. Receiver Capacity (Prefetch)

2.6. Receiver Capacity (Prefetch)

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 prefetch 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.

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 @@ -7. Request / Response

7. Request / Response

Request / Response applications use the reply-to property, - described in Table 2.8, “Mapping to AMQP 0-10 Message Properties”, 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. -

Example 2.13. Request / Response Applications in C++

This example shows the C++ code for a client and server - that use the request / response pattern.

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.

Receiver receiver = session.createReceiver("service_queue; {create: always}");
+2.7. Acknowledging Received Messages

2.7. Acknowledging Received Messages

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& 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(); -} -

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 - #, it is given a unique name.

-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 << request.getContent() << " -> " << response.getContent() << std::endl;
-	  

The client sends the string ping to - the server. The server sends the response - pong back to the same client, using the - replyTo property.


+ Some cases may not require this however and the reliability can be + controlled through a link property in the address options (see + Table 2.3, “Link Properties”).

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).

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.

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 @@ -8. Maps in Message Content

8. Maps in Message Content

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 MapMessage - interface, which allows sets of named type/value pairs, but does - not provide a set of portable datatypes.

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 - MapMessage interface; in Python, we - support dict and - list in message content; in C++, we - provide the Variant::Map and - Variant::List classes to represent maps - and lists. In all languages, messages are encoded using AMQP's - portable datatypes. -

Tip

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.

8.1. Qpid Maps in Python

In Python, Qpid supports the dict and list types directly in message content. The following code shows how to send these structures in a message:

Example 2.14. Sending Qpid Maps in Python

-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)
-       

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++.

Table 2.4. Python Datatypes in Maps

Python Datatype→ C++→ Java
boolboolboolean
intint64long
longint64long
floatdoubledouble
unicodestringjava.lang.String
uuidqpid::types::Uuidjava.util.UUID
dictVariant::Mapjava.util.Map
listVariant::Listjava.util.List

8.2. Qpid Maps in C++

In C++, Qpid defines the the - Variant::Map and - Variant::List types, which can be - encoded into message content. The following code shows how to - send these structures in a message:

Example 2.15. Sending Qpid Maps in C++

-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);
-     

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.

Table 2.5. C++ Datatypes in Maps

C++ Datatype→ Python→ Java
boolboolboolean
uint16int | longshort
uint32int | longint
uint64int | longlong
int16int | longshort
int32int | longint
int64int | longlong
floatfloatfloat
doublefloatdouble
stringunicodejava.lang.String
qpid::types::Uuiduuidjava.util.UUID
Variant::Mapdictjava.util.Map
Variant::Listlistjava.util.List

+2.8. Receiving Messages from Multiple Sources

2.8. Receiving Messages from Multiple Sources

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 next receiver; 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#. +

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 + Section 2.6, “Receiver Capacity (Prefetch)” for more on this.

Example 2.12. Receiving Messages from Multiple Sources

C++:

+Receiver receiver1 = session.createReceiver(address1);
+receiver1.setCapacity(10);
+Receiver receiver2 = session.createReceiver(address2);
+receiver2.setCapacity(10);
+
+Message message =  session.nextReceiver().fetch();
+std::cout << message.getContent() << std::endl;
+session.acknowledge(); // acknowledge message receipt
+	  

Python:

+receiver1 = session.receiver(address1)
+receiver1.capacity = 10
+receiver2 = session.receiver(address)
+receiver2.capacity = 10
+message = session.next_receiver().fetch()
+print message.content
+session.acknowledge()
+	  

.NET C#:

+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();
+	  

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 @@ -9. Performance

9. Performance

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

9.1. Batching Acknowledgements

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.

9.2. Prefetch

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.

Example 2.16. Prefetch

C++

-Receiver receiver = session.createReceiver(address);
-receiver.setCapacity(100);
-Message message = receiver.fetch();
-	  

9.3. Sizing the Replay Buffer

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.

Example 2.17. Sizing the Replay Buffer

C++

-Sender sender = session.createSender(address);
-sender.setCapacity(100);
-	  

+2.9. Transactions

2.9. Transactions

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 + + [7] + + .

Example 2.13. Transactions

C++:

+Connection connection(broker);
+Session session =  connection.createTransactionalSession();
+...
+if (smellsOk())
+   session.commit();
+else 
+   session.rollback();
+   



[7] 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.

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 @@ -10. Reliability

10. Reliability

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.

10.1. Reconnect

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.

Example 2.18. Specifying Connection Options in C++ and Python

In C++, these options are set using Connection::setOption():

-Connection connection(broker);
+2.10. Connection Options

2.10. Connection Options

+ 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. +

Example 2.14. Specifying Connection Options in C++ and Python

In C++, these options can be set using Connection::setOption() or by passing in a set of options to the constructor. The options can be passed in as a map or in string form:

+Connection connection("localhost:5672", "{reconnect: true}");
+try {
+    connection.open();
+    !!! SNIP !!!
+    

or

+Connection connection("localhost:5672");
 connection.setOption("reconnect", true);
 try {
     connection.open();
     !!! SNIP !!!
-    

In Python, these options are set using named arguments in +

In Python, these options can be set as attributes of the connection or using named arguments in the Connection constructor:

 connection = Connection("localhost:5672", reconnect=True)
 try:
   connection.open()
   !!! SNIP !!!
-  

See the reference documentation for details on how to set - these on connections for each language.


The following table lists the connection options that can - be used.

Table 2.6. Connection Options

optionvaluesemantics
+ + +or + +
+connection = Connection("localhost:5672")
+connection.reconnect = True
+try:
+  connection.open()
+  !!! SNIP !!!
+  

See the reference documentation for details in each language.


The following table lists the supported connection options.

Table 2.4. Connection Options

option namevalue typesemantics
+ username + + string + + The username to use when authenticating to the broker. +
+ password + + string + + The password to use when authenticating to the broker. +
+ sasl-mechanism + + string + + 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. +
reconnect - True, False + boolean Transparently reconnect if the connection is lost.
reconnect_timeout - N + integer Total number of seconds to continue reconnection attempts before giving up and raising an exception.
reconnect_limit - N + integer Maximum number of reconnection attempts before giving up and raising an exception.
reconnect_interval_min - N + integer representing time in seconds 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 reconnect_interval_min; if that attempt fails, the reconnect interval increases exponentially until a reconnection attempt succeeds or reconnect_interval_max is reached.
reconnect_interval_max - N + integer representing time in seconds Maximum reconnect interval.
reconnect_interval - N + integer representing time in seconds Sets both reconnection_interval_min and reconnection_interval_max to the same value. -

10.2. Guaranteed Delivery

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 QpidComponents.org.

Example 2.19. Guaranteed Delivery

C++:

-Sender sender = session.createSender("durable-queue");
-
-Message message("Hello world!");
-message.setDurable(1);
-
-sender.send(Message("Hello world!"));
-

10.3. Reliability Options in Senders and Receivers

When creating a sender or a receiver, you can specify a reliability option in the address string. For instance, the following specifies at-least-once as the reliability mode for a sender:

-Sender = session.createSender("topic;{create:always,link:{reliability:at-least-once}}");
-	

The modes unreliable, at-most-once, at-least-once, and exactly-once are supported. These modes govern the reliability of the connection between the client and the messaging broker.

The modes unreliable and at-most-once 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.

The mode at-most-once 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 exactly-once is similar to at-most-once, but eliminates duplicate messages.

10.4. Cluster Failover

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.

In C++, the FailoverUpdates class keeps track of the brokers in a cluster, so a reconnect can select another broker in the cluster to connect to:

Example 2.20. Cluster Failover in C++

-#include <qpid/messaging/FailoverUpdates.h>
-...
-Connection connection(broker);
-connection.setOption("reconnect", true);
-try {
-    connection.open();
-    std::auto_ptr<FailoverUpdates> updates(new FailoverUpdates(connection));
-	

+

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 @@ -11. Security

11. Security

Qpid provides authentication, rule-based authorization, encryption, and digital signing.

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.

To enable Kerberos in a client, set the sals-mechanism connection option to GSSAPI:

-Connection connection(broker);
-connection.setOption("sasl-mechanism", "GSSAPI");
-try {
-    connection.open();
-    ...
-      

For Kerberos authentication, if the user running the - program is already authenticated, e.g. using - kinit, 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:

-connection.setOption("username", "mick");
-connection.setOption("password", "pa$$word");
-      

Encryption and signing are done using SSL (they can also be done using SASL, but SSL provides stronger encryption). To enable SSL, set the protocol connection option to ssl:

-connection.setOption("protocol", "ssl");
-      

Use the following environment variables to configure the SSL client:

Table 2.7. SSL Client Environment Variables for C++ clients

- SSL Client Options for C++ clients -
- SSL_USE_EXPORT_POLICY - - Use NSS export policy -
- SSL_CERT_PASSWORD_FILE PATH - - File containing password to use for accessing certificate database -
- SSL_CERT_DB PATH - - Path to directory containing certificate database -
- SSL_CERT_NAME NAME - - Name of the certificate to use. When SSL client authentication is enabled, a certificate name should normally be provided. -

+2.11. Maps in Message Content

2.11.2. Qpid Maps in C++

In C++, Qpid defines the the + Variant::Map and + Variant::List types, which can be + encoded into message content. The following code shows how to + send these structures in a message:

Example 2.16. Sending Qpid Maps in C++

+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);
+     

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.

Table 2.6. C++ Datatypes in Maps

C++ Datatype→ Python→ Java
boolboolboolean
uint16int | longshort
uint32int | longint
uint64int | longlong
int16int | longshort
int32int | longint
int64int | longlong
floatfloatfloat
doublefloatdouble
stringunicodejava.lang.String
qpid::types::Uuiduuidjava.util.UUID
Variant::Mapdictjava.util.Map
Variant::Listlistjava.util.List

2.11.3. Qpid Maps in .NET

+ The .NET binding for the Qpid Messaging API binds .NET managed data types + to C++ Variant data types. The following code shows how to + send Map and List structures in a message: +

Example 2.17. Sending Qpid Maps in .NET C#

+using System;
+using Org.Apache.Qpid.Messaging;
+
+// !!! SNIP !!!
+
+Dictionary<string, object> content = new Dictionary<string, object>();
+Dictionary<string, object> subMap = new Dictionary<string, object>();
+Collection<object> colors = new Collection<object>();
+
+// 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);
+     

+ The following table shows the mapping between datatypes in .NET and C++. +

Table 2.7. Datatype Mapping between C++ and .NET binding

C++ Datatype→ .NET binding
boolbool
uint8byte
uint16UInt16
uint32UInt32
uint64UInt64
uint8char
int16Int16
int32Int32
int64Int64
floatSingle
doubleDouble
stringstring (1)
qpid::types::UuidGuid
Variant::MapDictionary& lt;string, object> (2)
Variant::ListCollection<object> (3)

(1)

Strings are currently interpreted only with UTF-8 encoding.



[8] Unlike JMS, there is not a specific message type for + map messages.

[9] Note that the Qpid JMS client supports + MapMessages whose values can be nested maps or lists. This is + not standard JMS behaviour.

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 @@ -12. Transactions

12. Transactions

In AMQP, transactions cover the semantics of enqueues and - dequeues.

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.

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.

Example 2.21. Transactions

C++:

-Connection connection(broker);
-Session session =  connection.createTransactionalSession();
-...
-if (smellsOk())
-   session.commit();
-else 
-   session.rollback();
-   

+2.12. The Request / Response Pattern

2.12. The Request / Response Pattern

Request / Response applications use the reply-to property, + described in Table 2.8, “Mapping to AMQP 0-10 Message Properties”, 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. +

Example 2.18. Request / Response Applications in C++

This example shows the C++ code for a client and server + that use the request / response pattern.

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.

Receiver receiver = session.createReceiver("service_queue; {create: always}");
+
+Message request = receiver.fetch();
+const Address&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();
+}
+     

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 + #, it is given a unique name.

+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 << request.getContent() << " -> " << response.getContent() << std::endl;
+	  

The client sends the string ping to + the server. The server sends the response + pong back to the same client, using the + replyTo property.


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