Creating a branch for experimenting with some ideas for JMS client.rajith_jms_client

git-svn-id: https://svn.apache.org/repos/asf/qpid/branches/rajith_jms_client@1128369 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 53 insertions, 0 deletions

diff --git a/qpid/cpp/examples/old_api/xml-exchange/README.txt b/qpid/cpp/examples/old_api/xml-exchange/README.txt
new file mode 100644
index 0000000000..85caebe352
--- /dev/null
+++ b/qpid/cpp/examples/old_api/xml-exchange/README.txt
@@ -0,0 +1,53 @@
+This example shows how to program a simple application
+using the XML Exchange. 
+
+[Note: The XML Exchange is not a standard AMQP exchange type. To run
+this example you need to have a broker that has support for the xml
+exchange. If you are compiling the broker from source please refer to
+the INSTALL notes from qpid.]
+
+To run the example, execute the programs in the
+following order:
+
+1 ./declare_queues
+2 ./listener
+3 ./message_producer (in a separate window)
+
+The XML Exchange must be explicitly declared. Bindings
+are established using queries in XQuery. These queries
+can reference message content, message application 
+properties (which are declared as external variables
+in the XQuery), or both. 
+
+Once this is done, message producers publish to the
+exchange using the exchange name and a routing key,
+just as for other exchange types. Message consumers
+read from the queues to which messages are routed.
+If a message does not have XML content, or is
+missing message application properties needed by
+the query, the query is not routed.
+
+Queries can use message application headers to
+provide functionality similar to JMS selectors.
+If a query does not use the content of a message,
+the message content is not parsed, and need not
+be XML.
+
+The XQuery processor, XQilla,  does path-based 
+document projection, so once the portion of
+a document needed to evaluate a query has
+been read, it stops parsing the document.
+Suppose a long document has a header section.
+You can indicate in the query that only
+one header section needs to be queried,
+and there is no need to parse the entire
+document to see if there are further header
+sections, using a path like this:
+
+./message/header[1]/date
+
+If you used a path like this, all children
+of the message element would be read to
+see if there are further headers:
+
+./message/header/date