You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by cm...@apache.org on 2010/01/12 05:23:34 UTC
svn commit: r898181 [1/5] - in
/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator: ./
specification/ specification/1.0-PR2/ src/ src/main/ src/main/java/
src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/activemq/ src/m...
Author: cmacnaug
Date: Tue Jan 12 04:23:30 2010
New Revision: 898181
URL: http://svn.apache.org/viewvc?rev=898181&view=rev
Log:
Start of AMQP 1.0 protocol generator.
Added:
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/ (with props)
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/security.xml
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/transport.xml
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/types.xml
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpChoice.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpClass.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpDescriptor.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpDoc.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpEncoding.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpException.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpField.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Generator.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/JAXBGen.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Main.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Marshalable.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/TypeRegistry.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/UnknownTypeException.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Utils.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Amqp.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/B.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Choice.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Dd.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Definition.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Descriptor.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Dl.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Doc.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Dt.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Encoding.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Exception.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Field.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/I.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Li.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/ObjectFactory.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Ol.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/P.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Picture.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Section.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Sub.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Sup.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Type.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Ul.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Xref.java
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/activemq/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/activemq/amqp/
activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/activemq/amqp/generator/
Propchange: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/
------------------------------------------------------------------------------
--- svn:ignore (added)
+++ svn:ignore Tue Jan 12 04:23:30 2010
@@ -0,0 +1,4 @@
+.classpath
+.project
+.settings
+target
Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml Tue Jan 12 04:23:30 2010
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?><project>
+ <parent>
+ <artifactId>activemq-parent</artifactId>
+ <groupId>org.apache.activemq</groupId>
+ <version>6.0-SNAPSHOT</version>
+ </parent>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>org.apache.activemq</groupId>
+ <artifactId>activemq-amqp-generator</artifactId>
+ <name>activemq-amqp-generator</name>
+ <version>6.0-SNAPSHOT</version>
+ <url>http://maven.apache.org</url>
+ <repositories>
+ <repository>
+ <id>repo1.maven.org</id>
+ <name>Maven central</name>
+ <url>http://repo1.maven.org/maven2</url>
+ </repository>
+ </repositories>
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>3.8.1</version>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.velocity</groupId>
+ <artifactId>velocity</artifactId>
+ <version>1.6</version>
+ </dependency>
+ <dependency>
+ <groupId>javax.xml</groupId>
+ <artifactId>jaxb-api</artifactId>
+ <version>2.1</version>
+ </dependency>
+ <dependency>
+ <groupId>commons-logging</groupId>
+ <artifactId>commons-logging-api</artifactId>
+ <version>1.1</version>
+ </dependency>
+ <dependency>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ <version>1.2.15</version>
+ <scope>runtime</scope>
+ </dependency>
+ </dependencies>
+</project>
\ No newline at end of file
Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd Tue Jan 12 04:23:30 2010
@@ -0,0 +1,212 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!--
+ Copyright Notice
+ ================
+ (c) Copyright Cisco Systems, Credit Suisse, Deutsche Börse Systems, Envoy Technologies, Inc.,
+ Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A,
+ Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc
+ 2006, 2007. All rights reserved.
+
+ License
+ =======
+ JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix Corporation, IONA
+ Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc. (collectively, the
+ "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable,
+ nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue
+ Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for
+ the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and
+ any rights under this Agreement will terminate immediately without notice from any Author if you
+ bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol
+ Specification against any Author. Upon termination, you shall destroy all copies of the Advanced
+ Messaging Queue Protocol Specification in your possession or control.
+
+ As used hereunder, "Licensed Claims" means those claims of a patent or patent application,
+ throughout the world, excluding design patents and design registrations, owned or controlled, or
+ that can be sublicensed without fee and in compliance with the requirements of this Agreement, by
+ an Author or its affiliates now or at any future time and which would necessarily be infringed by
+ implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily
+ infringed hereunder only when it is not possible to avoid infringing it because there is no
+ plausible non-infringing alternative for implementing the required portions of the Advanced
+ Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not
+ include any claims other than as set forth above even if contained in the same patent as Licensed
+ Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue
+ Protocol Specification that are not required by the Advanced Messaging Queue Protocol
+ Specification, or that, if licensed, would require a payment of royalties by the licensor to
+ unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling
+ technologies that may be necessary to make or use any Licensed Product but are not themselves
+ expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
+ manufacturing technology, compiler technology, object oriented technology, networking technology,
+ operating system technology, and the like); or (ii) the implementation of other published
+ standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue
+ Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or
+ function of which is not required for compliance with the Advanced Messaging Queue Protocol
+ Specification. For purposes of this definition, the Advanced Messaging Queue Protocol
+ Specification shall be deemed to include both architectural and interconnection requirements
+ essential for interoperability and may also include supporting source code artifacts where such
+ architectural, interconnection requirements and source code artifacts are expressly identified as
+ being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol
+ Specification.
+
+ As used hereunder, "Licensed Products" means only those specific portions of products (hardware,
+ software or combinations thereof) that implement and are compliant with all relevant portions of
+ the Advanced Messaging Queue Protocol Specification.
+
+ The following disclaimers, which you hereby also acknowledge as to any use you may make of the
+ Advanced Messaging Queue Protocol Specification:
+
+ THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO
+ REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
+ OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
+ IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD
+ PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+ THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
+ DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR OF THE ADVANCED
+ MESSAGING QUEUE PROTOCOL SPECIFICATION.
+
+ The name and trademarks of the Authors may NOT be used in any manner, including advertising or
+ publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents
+ without specific, written prior permission. Title to copyright in the Advanced Messaging Queue
+ Protocol Specification will at all times remain with the Authors.
+
+ No other rights are granted by implication, estoppel or otherwise.
+
+ Upon termination of your license or rights under this Agreement, you shall destroy all copies of
+ the Advanced Messaging Queue Protocol Specification in your possession or control.
+
+ Trademarks
+ ==========
+ "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are
+ trademarks of JPMorgan Chase & Co.
+
+ IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
+
+ IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its
+ subsidiaries.
+
+ LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat,
+ Inc. in the US and other countries.
+
+ Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the
+ United States, other countries, or both.
+
+ Other company, product, or service names may be trademarks or service marks of others.
+
+ Links to full AMQP specification:
+ =================================
+ http://www.envoytech.org/spec/amq/
+ http://www.iona.com/opensource/amqp/
+ http://www.redhat.com/solutions/specifications/amqp/
+ http://www.twiststandards.org/tiki-index.php?page=AMQ
+ http://www.imatix.com/amqp
+-->
+
+<!ELEMENT amqp (doc|section)*>
+<!ATTLIST amqp
+ xmlns CDATA #IMPLIED
+ name CDATA #REQUIRED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT section (doc|definition|type)*>
+<!ATTLIST section
+ name CDATA #REQUIRED
+ title CDATA #IMPLIED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT definition (doc)*>
+<!ATTLIST definition
+ name CDATA #REQUIRED
+ value CDATA #REQUIRED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT type (encoding|descriptor|field|choice|exception|doc)*>
+<!ATTLIST type
+ name CDATA #REQUIRED
+ class (primitive|compound|restricted|union) #REQUIRED
+ source CDATA #IMPLIED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT encoding (doc)*>
+<!ATTLIST encoding
+ name CDATA #IMPLIED
+ label CDATA #IMPLIED
+ code CDATA #REQUIRED
+ category (fixed|variable|compound|array) #REQUIRED
+ width CDATA #IMPLIED
+>
+
+
+<!ELEMENT descriptor (doc)*>
+<!ATTLIST descriptor
+ name CDATA #IMPLIED
+ code CDATA #IMPLIED
+>
+
+<!ELEMENT field (doc|exception)*>
+<!ATTLIST field
+ name CDATA #REQUIRED
+ type CDATA #IMPLIED
+ default CDATA #IMPLIED
+ label CDATA #IMPLIED
+ required CDATA #IMPLIED
+ multiple CDATA #IMPLIED
+>
+
+<!ELEMENT choice (doc)*>
+<!ATTLIST choice
+ name CDATA #REQUIRED
+ value CDATA #REQUIRED
+>
+
+<!ELEMENT exception (doc)*>
+<!ATTLIST exception
+ name CDATA #REQUIRED
+ error-code CDATA #IMPLIED
+>
+
+<!ELEMENT doc (p|ul|ol|dl|picture)*>
+<!ATTLIST doc
+ title CDATA #IMPLIED
+>
+
+<!ELEMENT p (#PCDATA|xref|b|i|sup|sub)*>
+
+<!ELEMENT xref (#PCDATA)>
+<!ATTLIST xref
+ type CDATA #IMPLIED
+ name CDATA #REQUIRED
+>
+
+<!ELEMENT b (#PCDATA)>
+<!ELEMENT i (#PCDATA)>
+<!ELEMENT sup (#PCDATA|sup|sub|b|i)*>
+<!ELEMENT sub (#PCDATA|sup|sub|b|i)*>
+
+<!ELEMENT ul (li)*>
+<!ATTLIST ul
+ title CDATA #IMPLIED
+>
+<!ELEMENT ol (li)*>
+<!ATTLIST ol
+ title CDATA #IMPLIED
+>
+
+<!ELEMENT li (p|ul)*>
+
+<!ELEMENT dl (dt, dd)*>
+<!ATTLIST dl
+ title CDATA #IMPLIED
+>
+<!ELEMENT dt (#PCDATA)>
+<!ELEMENT dd (p)*>
+
+<!ELEMENT picture (#PCDATA)>
+<!ATTLIST picture
+ title CDATA #IMPLIED
+>
Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml Tue Jan 12 04:23:30 2010
@@ -0,0 +1,122 @@
+<?xml version="1.0"?>
+
+<!--
+ Copyright Notice
+ ================
+ (c) Copyright Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,
+ Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A,
+ Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc.
+ 2006, 2007. All rights reserved.
+
+ License
+ =======
+
+ Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,Goldman Sachs,
+ IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A, Novell, Rabbit
+ Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc. (collectively,
+ the "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable,
+ nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue
+ Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for
+ the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and
+ any rights under this Agreement will terminate immediately without notice from any Author if you
+ bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol
+ Specification against any Author. Upon termination, you shall destroy all copies of the Advanced
+ Messaging Queue Protocol Specification in your possession or control.
+
+ As used hereunder, "Licensed Claims" means those claims of a patent or patent application,
+ throughout the world, excluding design patents and design registrations, owned or controlled, or
+ that can be sublicensed without fee and in compliance with the requirements of this Agreement, by
+ an Author or its affiliates now or at any future time and which would necessarily be infringed by
+ implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily
+ infringed hereunder only when it is not possible to avoid infringing it because there is no
+ plausible non-infringing alternative for implementing the required portions of the Advanced
+ Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not
+ include any claims other than as set forth above even if contained in the same patent as Licensed
+ Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue
+ Protocol Specification that are not required by the Advanced Messaging Queue Protocol
+ Specification, or that, if licensed, would require a payment of royalties by the licensor to
+ unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling
+ technologies that may be necessary to make or use any Licensed Product but are not themselves
+ expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
+ manufacturing technology, compiler technology, object oriented technology, networking technology,
+ operating system technology, and the like); or (ii) the implementation of other published
+ standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue
+ Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or
+ function of which is not required for compliance with the Advanced Messaging Queue Protocol
+ Specification. For purposes of this definition, the Advanced Messaging Queue Protocol
+ Specification shall be deemed to include both architectural and interconnection requirements
+ essential for interoperability and may also include supporting source code artifacts where such
+ architectural, interconnection requirements and source code artifacts are expressly identified as
+ being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol
+ Specification.
+
+ As used hereunder, "Licensed Products" means only those specific portions of products (hardware,
+ software or combinations thereof) that implement and are compliant with all relevant portions of
+ the Advanced Messaging Queue Protocol Specification.
+
+ The following disclaimers, which you hereby also acknowledge as to any use you may make of the
+ Advanced Messaging Queue Protocol Specification:
+
+ THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO
+ REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
+ OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
+ IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD
+ PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+ THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
+ DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED
+ MESSAGING QUEUE PROTOCOL SPECIFICATION.
+
+ The name and trademarks of the Authors may NOT be used in any manner, including advertising or
+ publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents
+ without specific, written prior permission. Title to copyright in the Advanced Messaging Queue
+ Protocol Specification will at all times remain with the Authors.
+
+ No other rights are granted by implication, estoppel or otherwise.
+
+ Upon termination of your license or rights under this Agreement, you shall destroy all copies of
+ the Advanced Messaging Queue Protocol Specification in your possession or control.
+
+ Trademarks
+ ==========
+ "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are
+ trademarks of JPMorgan Chase & Co.
+
+ IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
+
+ IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its
+ subsidiaries.
+
+ LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat,
+ Inc. in the US and other countries.
+
+ Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the
+ United States, other countries, or both.
+
+ Other company, product, or service names may be trademarks or service marks of others.
+
+ Links to full AMQP specification:
+ =================================
+ http://www.envoytech.org/spec/amq/
+ http://www.iona.com/opensource/amqp/
+ http://www.redhat.com/solutions/specifications/amqp/
+ http://www.twiststandards.org/tiki-index.php?page=AMQ
+ http://www.imatix.com/amqp
+-->
+
+<!DOCTYPE amqp SYSTEM "amqp.dtd">
+
+<amqp xmlns="http://www.amqp.org/schema/amqp.xsd"
+ name="index" label="working version">
+
+ <doc>
+ <ul>
+ <li><p><xref type="amqp" name="types"/></p></li>
+ <li><p><xref type="amqp" name="transport"/></p></li>
+ <li><p><xref type="amqp" name="messaging"/></p></li>
+ <li><p><xref type="amqp" name="security"/></p></li>
+ </ul>
+ </doc>
+
+</amqp>
Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml Tue Jan 12 04:23:30 2010
@@ -0,0 +1,1139 @@
+<?xml version="1.0"?>
+
+<!--
+ Copyright Notice
+ ================
+ (c) Copyright Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,
+ Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A,
+ Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc.
+ 2006, 2007. All rights reserved.
+
+ License
+ =======
+
+ Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,Goldman Sachs,
+ IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A, Novell, Rabbit
+ Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc. (collectively,
+ the "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable,
+ nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue
+ Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for
+ the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and
+ any rights under this Agreement will terminate immediately without notice from any Author if you
+ bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol
+ Specification against any Author. Upon termination, you shall destroy all copies of the Advanced
+ Messaging Queue Protocol Specification in your possession or control.
+
+ As used hereunder, "Licensed Claims" means those claims of a patent or patent application,
+ throughout the world, excluding design patents and design registrations, owned or controlled, or
+ that can be sublicensed without fee and in compliance with the requirements of this Agreement, by
+ an Author or its affiliates now or at any future time and which would necessarily be infringed by
+ implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily
+ infringed hereunder only when it is not possible to avoid infringing it because there is no
+ plausible non-infringing alternative for implementing the required portions of the Advanced
+ Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not
+ include any claims other than as set forth above even if contained in the same patent as Licensed
+ Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue
+ Protocol Specification that are not required by the Advanced Messaging Queue Protocol
+ Specification, or that, if licensed, would require a payment of royalties by the licensor to
+ unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling
+ technologies that may be necessary to make or use any Licensed Product but are not themselves
+ expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
+ manufacturing technology, compiler technology, object oriented technology, networking technology,
+ operating system technology, and the like); or (ii) the implementation of other published
+ standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue
+ Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or
+ function of which is not required for compliance with the Advanced Messaging Queue Protocol
+ Specification. For purposes of this definition, the Advanced Messaging Queue Protocol
+ Specification shall be deemed to include both architectural and interconnection requirements
+ essential for interoperability and may also include supporting source code artifacts where such
+ architectural, interconnection requirements and source code artifacts are expressly identified as
+ being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol
+ Specification.
+
+ As used hereunder, "Licensed Products" means only those specific portions of products (hardware,
+ software or combinations thereof) that implement and are compliant with all relevant portions of
+ the Advanced Messaging Queue Protocol Specification.
+
+ The following disclaimers, which you hereby also acknowledge as to any use you may make of the
+ Advanced Messaging Queue Protocol Specification:
+
+ THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO
+ REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
+ OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
+ IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD
+ PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+ THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
+ DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED
+ MESSAGING QUEUE PROTOCOL SPECIFICATION.
+
+ The name and trademarks of the Authors may NOT be used in any manner, including advertising or
+ publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents
+ without specific, written prior permission. Title to copyright in the Advanced Messaging Queue
+ Protocol Specification will at all times remain with the Authors.
+
+ No other rights are granted by implication, estoppel or otherwise.
+
+ Upon termination of your license or rights under this Agreement, you shall destroy all copies of
+ the Advanced Messaging Queue Protocol Specification in your possession or control.
+
+ Trademarks
+ ==========
+ "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are
+ trademarks of JPMorgan Chase & Co.
+
+ IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
+
+ IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its
+ subsidiaries.
+
+ LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat,
+ Inc. in the US and other countries.
+
+ Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the
+ United States, other countries, or both.
+
+ Other company, product, or service names may be trademarks or service marks of others.
+
+ Links to full AMQP specification:
+ =================================
+ http://www.envoytech.org/spec/amq/
+ http://www.iona.com/opensource/amqp/
+ http://www.redhat.com/solutions/specifications/amqp/
+ http://www.twiststandards.org/tiki-index.php?page=AMQ
+ http://www.imatix.com/amqp
+-->
+
+<!DOCTYPE amqp SYSTEM "amqp.dtd">
+
+<amqp xmlns="http://www.amqp.org/schema/amqp.xsd"
+ name="messaging" label="working version">
+
+ <section name="introduction" label="introduction to the Messaging layer">
+ <doc>
+ <p>
+ The messaging layer builds on top of the concepts described in books II and III. The
+ <xref name="transport"/> layer defines a number of extension points suitable for use in a
+ variety of different messaging applications. The messaging layer specifies a standardized
+ use of these to provide interoperable messaging capabilities. This standard covers:
+ </p>
+
+ <ul>
+ <li>
+ <p>properties for the bare message</p>
+ </li>
+
+ <li>
+ <p>formats for structured and unstructured sections in the bare message</p>
+ </li>
+
+ <li>
+ <p>headers and footers for the annotated message</p>
+ </li>
+
+ <li>
+ <p>formats for sources and targets</p>
+
+ <ul>
+ <li>
+ <p>destructive and non-destructive access to messages from a node</p>
+ </li>
+
+ <li>
+ <p>filtering of messages from a node</p>
+ </li>
+
+ <li>
+ <p>default disposition of transfers</p>
+ </li>
+
+ <li>
+ <p>disposition of orphaned transfers</p>
+ </li>
+
+ <li>
+ <p>on-demand node creation</p>
+ </li>
+ </ul>
+ </li>
+
+ <li>
+ <p>states for messages held in a node</p>
+ </li>
+
+ <li>
+ <p>dispositions for messages transferred to/from a node</p>
+ </li>
+
+ <li>
+ <p>a transactional model for modifying the state of messages held in a node</p>
+ </li>
+ </ul>
+ </doc>
+ </section>
+
+ <section name="message-format" title="Message Format" label="Message format definitions">
+
+ <doc>
+ <p>
+ The term message is used with various connotations in the messaging world. The sender may
+ like to think of the message as an immutable payload handed off to the messaging
+ infrastructure for delivery. The receiver often thinks of the message as not only that
+ immutable payload from the sender, but also various annotations supplied by the messaging
+ infrastructure along the way. To avoid confusion we formally define the term <i>bare
+ message</i> to mean the message as supplied by the sender and the term <i>annotated
+ message</i> to mean the message as seen at the receiver.
+ </p>
+
+ <p>
+ An annotated message consists of the bare message plus areas for annotation at the head and
+ foot of the bare message. There are two classes of annotations: annotations that travel with
+ the message indefinitely, and annotations that are consumed by the next node.
+ </p>
+
+ <p>
+ The bare message is divided between standard properties and application data. The standard
+ properties have a defined format and semantics and are visible to the messaging
+ infrastructure. Application data may be AMQP formatted, opaque binary, or a combination of
+ both. AMQP formatted application data is visible to the messaging infrastructure for
+ additional services such as querying by filters.
+ </p>
+
+ <p>
+ Altogether the message consists of the following sections:
+ </p>
+
+ <ol>
+ <li>
+ <p>
+ Exactly one <xref name="header"/> section for annotations at the head of the message.
+ </p>
+ </li>
+ <li>
+ <p>
+ Exactly one <xref name="properties"/> section for standard properties in the bare
+ message.
+ </p>
+ </li>
+ <li>
+ <p>Zero or more application data sections.</p>
+ </li>
+ <li>
+ <p>
+ Exactly one <xref name="footer"/> section for annotations at the tail of the message.
+ </p>
+ </li>
+ </ol>
+
+ <picture><![CDATA[
+ Section 0 Section 1 Section 2 Section n-2 Section n-1
++-----------+------------+-----------+-----+-------------+-------------+
+| header | properties | app-data | ... | app-data | footer |
++-----------+------------+-----------+-----+-------------+-------------+
+]]>
+ </picture>
+
+ <p>
+ Each message section MUST be distinguished and identified with a format-code as per the
+ Message Fragmentation definition in the <xref name="links"/> section of Book III. The format
+ codes are assigned according to <xref name="section-codes"/>.
+ </p>
+ </doc>
+
+ <type class="restricted" name="section-codes" source="uint">
+ <choice name="header" value="0">
+ <doc>
+ <p>
+ Section-code indicating a header section (one of which MUST form the first section of a
+ Message). Sections of this type MUST be of zero length or consist of a single encoded
+ instance of the <xref name="header"/> type.
+ </p>
+ </doc>
+ </choice>
+ <choice name="properties" value="1">
+ <doc>
+ <p>
+ Section-code indicating a properties section (one of which MUST form the second section
+ of a Message). Sections of this type MUST be of zero length or consist of a single
+ encoded instance of the <xref name="properties"/> type.
+ </p>
+ </doc>
+ </choice>
+ <choice name="footer" value="2">
+ <doc>
+ <p>
+ Section-code indicating a footer section (one of which MUST form the last section of a
+ Message). Sections of this type MUST be of zero length or consist of a single encoded
+ instance of the <xref name="footer"/> type.
+ </p>
+ </doc>
+ </choice>
+ <choice name="map-data" value="3">
+ <doc>
+ <p>
+ Section-code indicating a application data section. Sections of this type MUST be of
+ zero length or consist of a single encoded instance of an AMQP the
+ <xref type="type" name="map"/>.
+ </p>
+ </doc>
+ </choice>
+ <choice name="list-data" value="4">
+ <doc>
+ <p>
+ Section-code indicating a application data section. Sections of this type MUST be of
+ zero length or consist of a single encoded instance of an AMQP the
+ <xref type="type" name="list"/>.
+ </p>
+ </doc>
+ </choice>
+ <choice name="data" value="5">
+ <doc>
+ <p>
+ Section-code indicating a application data section. Sections of this type consist of
+ opaque binary data (note, in particular, that the section is <b>not</b> an instance of
+ the AMQP <xref type="type" name="binary"/> type).
+ </p>
+ </doc>
+ </choice>
+ </type>
+
+ <type class="compound" name="header" label="transport headers for a Message">
+ <doc>
+ <p>
+ The header struct carries information about the transfer of a Message over a specific
+ Link.
+ </p>
+ </doc>
+
+ <descriptor name="amqp:header:list" code="0x00000001:0x0009801"/>
+
+ <field name="durable" type="boolean" label="specify durability requirements">
+ <doc>
+ <p>
+ Durable Messages MUST NOT be lost even if an intermediary is unexpectedly terminated and
+ restarted.
+ </p>
+ </doc>
+ </field>
+
+ <field name="priority" type="ubyte" label="relative Message priority">
+ <doc>
+ <p>
+ This field contains the relative Message priority. Higher numbers indicate higher
+ priority Messages. Messages with higher priorities MAY be delivered before those with
+ lower priorities.
+ </p>
+
+ <p>
+ An AMQP intermediary implementing distinct priority levels MUST do so in the following
+ manner:
+ </p>
+
+ <ul>
+ <li>
+ <p>
+ If n distinct priorities are implemented and n is less than 10 -- priorities 0 to
+ (5 - ceiling(n/2)) MUST be treated equivalently and MUST be the lowest effective
+ priority. The priorities (4 + floor(n/2)) and above MUST be treated equivalently
+ and MUST be the highest effective priority. The priorities (5 - ceiling(n/2)) to (4
+ + floor(n/2)) inclusive MUST be treated as distinct priorities.
+ </p>
+ </li>
+
+ <li>
+ <p>
+ If n distinct priorities are implemented and n is 10 or greater -- priorities 0 to
+ (n - 1) MUST be distinct, and priorities n and above MUST be equivalent to priority
+ (n - 1).
+ </p>
+ </li>
+ </ul>
+
+ <p>
+ Thus, for example, if 2 distinct priorities are implemented, then levels 0 to 4 are
+ equivalent, and levels 5 to 9 are equivalent and levels 4 and 5 are distinct. If 3
+ distinct priorities are implements the 0 to 3 are equivalent, 5 to 9 are equivalent and
+ 3, 4 and 5 are distinct.
+ </p>
+
+ <p>
+ This scheme ensures that if two priorities are distinct for a server which implements m
+ separate priority levels they are also distinct for a server which implements n
+ different priority levels where n > m.
+ </p>
+ </doc>
+ </field>
+
+ <field name="transmit-time" type="timestamp" label="the time of Message transmit">
+ <doc>
+ <p>
+ The point in time at which the sender considers the Message to be transmitted. The ttl
+ field, if set by the sender, is relative to this point in time.
+ </p>
+ </doc>
+ </field>
+
+ <field name="ttl" type="ulong" label="time to live in ms">
+ <doc>
+ <p>
+ Duration in milliseconds for which the Message should be considered "live". If this is
+ set then a Message expiration time will be computed based on the transmit-time plus this
+ value. Messages that live longer than their expiration time will be discarded (or dead
+ lettered). If the transmit-time is not set, then the expiration is computed relative to
+ the Message arrival time.
+ </p>
+ </doc>
+ </field>
+
+ <field name="former-acquirers" type="uint" label="">
+ <doc>
+ <p>
+ The number of other DESTRUCTIVE Links to which delivery of this Message was previously
+ attempted unsuccessfully. This does not include the current Link even if delivery to the
+ current Link has been previously attempted.
+ </p>
+ </doc>
+ </field>
+
+ <field name="delivery-failures" type="uint"
+ label="the number of prior unsuccessful delivery attempts">
+ <doc>
+ <p>
+ The number of unsuccessful previous attempts to deliver this message. If this value is
+ non-zero it may be taken as an indication that the Message may be a duplicate. The
+ delivery-failures value is initially set to the same value as the Message has when it
+ arrived at the source. It is incremented When:
+ </p>
+
+ <ol>
+ <li>
+ <p>
+ the Message has previously been sent from this Node using a Source with a
+ distribution-mode of DESTRUCTIVE which closed without the Message being acknowledged
+ </p>
+ </li>
+
+ <li>
+ <p>
+ the Message has previously been sent from this Node using a Source with a
+ distribution-mode of DESTRUCTIVE and was subsequently finalized with a disposition
+ of <xref name="released"/> and the delivery-failed field set to true.
+ </p>
+ </li>
+ </ol>
+ </doc>
+ </field>
+
+ <field name="format-code" type="uint" label="indicates the format of the Message"/>
+
+ <field name="message-attrs" type="message-attributes" label="message attributes">
+ <doc>
+ <p>
+ The message-attrs map provides an extension point where domain or vendor specific
+ end-to-end attributes can be added to the Message header. As the Message (and therefore
+ the header) passes through a node, the values in the message-attrs map MUST be retained,
+ unless augmented or updated at the node. Further the message-attrs value can be
+ augmented or updated at each node either through node configuration, or through
+ explicit updates using the <xref type="type" name="disposition"/> command and
+ dispositions which allow for updates to the message-attrs.
+ </p>
+ </doc>
+ </field>
+
+ <field name="delivery-attrs" type="message-attributes" label="delivery attributes">
+ <doc>
+ <p>
+ The delivery-attrs map provides an extension point where domain or vendor specific
+ attributes related only to the current state of the Message at the source, or relating
+ to the current transfer to the target can be added to the Message header. The
+ delivery-attrs value can be augmented or updated at the node either through node
+ configuration, or through explicit updates using the
+ <xref type="type" name="disposition"/> command
+ and dispositions which allow for updates to the delivery-attrs.
+ </p>
+ </doc>
+ </field>
+
+ </type>
+
+ <type class="compound" name="properties" label="immutable properties of the Message">
+ <doc>
+ <p>Message properties carry information about the Message.</p>
+ </doc>
+
+ <descriptor name="amqp:properties:list" code="0x00000001:0x00009802"/>
+
+ <field name="message-id" type="binary" label="application Message identifier">
+ <doc>
+ <p>
+ Message-id is an optional property which uniquely identifies a Message within the
+ Message system. The Message producer is usually responsible for setting the message-id
+ in such a way that it is assured to be globally unique. The server MAY discard a Message
+ as a duplicate if the value of the message-id matches that of a previously received
+ Message sent to the same Node.
+ </p>
+ </doc>
+ </field>
+
+ <field name="user-id" type="binary" label="creating user id">
+ <doc>
+ <p>
+ The identity of the user responsible for producing the Message. The client sets this
+ value, and it MAY be authenticated by intermediaries.
+ </p>
+ </doc>
+ </field>
+
+ <!-- XXX: discuss type and fix docs if it really is a string -->
+ <field name="to" type="string" label="the name of the Node the Message is destined for">
+ <doc>
+ <p>
+ The to field identifies the Node that is the intended destination of the Message. On any
+ given transfer this may not be the Node at the receiving end of the Link.
+ </p>
+ </doc>
+ </field>
+
+ <!-- XXX: discuss type and fix docs if it really is a string -->
+ <field name="reply-to" type="string" label="the Node to send replies to">
+ <doc>
+ <p>The name of the Node to send replies to.</p>
+ </doc>
+ </field>
+
+ <field name="correlation-id" type="binary" label="application correlation identifier">
+ <doc>
+ <p>
+ This is a client-specific id that may be used to mark or identify Messages between
+ clients. The server ignores this field.
+ </p>
+ </doc>
+ </field>
+
+ <field name="content-length" type="ulong" label="length of the combined payload in bytes">
+ <doc>
+ <p>
+ The total size in octets of the combined payload of all transfer commands that together
+ make the Message.
+ </p>
+ </doc>
+ </field>
+
+ <field name="content-type" type="symbol" label="MIME content type">
+ <doc>
+ <p>
+ The RFC-2046 MIME type for the Message content (such as "text/plain"). This is set by
+ the originating client. As per RFC-2046 this may contain a charset parameter defining
+ the character encoding used: e.g. 'text/plain; charset="utf-8"'.
+ </p>
+ </doc>
+ </field>
+
+ </type>
+
+ <type class="compound" name="footer" label="transport footers for a Message">
+
+ <descriptor name="amqp:footer:list" code="0x00000001:0x00009803"/>
+
+ <field name="message-attrs" type="message-attributes" label="message attributes">
+ <doc>
+ <p>
+ The message-attrs map provides an extension point where domain or vendor specific
+ end-to-end attributes can be added to the Message footer. As the Message (and therefore
+ the header) passes through a node, the values in the message-attrs map MUST be retained,
+ unless augmented or updated at the node. Further the message-attrs value can be
+ augmented or updated at each node either through node configuration, or through
+ explicit updates using the <xref type="type" name="disposition"/> command and
+ dispositions which allow for updates to the message-attrs.
+ </p>
+ </doc>
+ </field>
+
+ <field name="delivery-attrs" type="message-attributes" label="delivery attributes">
+ <doc>
+ <p>
+ The delivery-attrs map provides an extension point where domain or vendor specific
+ attributes related only to the current state of the Message at the source, or relating
+ to the current transfer to the target can be added to the Message footer. The
+ delivery-attrs value can be augmented or updated at the node either through node
+ configuration, or through explicit updates using the
+ <xref type="type" name="disposition"/> command and dispositions which allow for updates
+ to the delivery-attrs.
+ </p>
+ </doc>
+ </field>
+ </type>
+
+ <type class="restricted" name="message-attributes" source="map">
+ <doc>
+ <p>
+ A map providing an extension point by which annotations on message deliveries. All values
+ used as keys in the map MUST be of type symbol. Further if a key begins with the string
+ "x-req-" then the target MUST reject the message unless it understands how to process the
+ supplied key/value.
+ </p>
+ </doc>
+ </type>
+
+ </section>
+
+ <section name="transfer-dispositions" title="Transfer Dispositions"
+ label="definitions for transfer dispositions">
+
+ <doc title="Message State on a Node">
+ <p>
+ The Messaging layer defines a precise set of states for Messages on a Node. The transitions
+ between these states are controlled by the transfer of Messages from a Node and the
+ disposition communicated back. Note that the state of a Message on one Node does not affect
+ the state of the same Message at a separate Node.
+ </p>
+ <p>
+ By default a Message will begin in the AVAILABLE state. If the Message begins transferring
+ over a <i>destructive</i> Link, the Message will transition to the ACQUIRED state - thus
+ becoming ineligible for transfer to other Links with a default configuration.
+ </p>
+ <p>
+ A Message will remain ACQUIRED at the sending node until the disposition is <i>settled</i>,
+ or until the transfer is aborted. A transfer aborted due to the destruction of the
+ underlying Link will cause the Message to transition according to the disposition configured
+ as the <i>orphan-disposition</i> on the source.
+ </p>
+ <p>
+ If the transfer occurs on a Session configured in a transaction mode (i.e. with a
+ <i>txn-mode</i> of <i>local</i>, <i>distributed</i> or <i>promotable</i>) then the
+ disposition is not settled until the transaction has been committed. If a transaction fails
+ to commit (either through an explicit failure or rollback, or through the destruction of the
+ Session without a commit having occurred) then all unsettled transfers are irreversibly
+ assigned the released disposition.
+ </p>
+ <picture title="Message State Transitions"><![CDATA[
+ +------------+
+ +->| AVAILABLE |
+ | +------------+
+ | |
+DISPOSITION | | S:TRANSFER
+(RELEASED) | |
+ | |
+ | |
+ | |
+ | \|/
+ | +------------+
+ +--| ACQUIRED |
+ +------------+
+ |
+ |
+ |
+ | DISPOSITION(COMPLETE)
+ |
+ |
+ \|/
+ +------------+
+ | ARCHIVED |
+ +------------+
+]]>
+ </picture>
+ <p>
+ State transitions may also occur spontaneously at the Node. For example if a Message with
+ ttl set may expire, and the effect of expiry may be (depending on Node configuration) to
+ move spontaneously from the AVAILABLE state into the ARCHIVED state.
+ </p>
+ </doc>
+
+
+ <type class="restricted" name="message-state" source="ubyte">
+ <doc>
+ <p>
+ An enumeration of the defined states of a Message on a Node.
+ </p>
+ </doc>
+
+ <choice name="available" value="0">
+ <doc>
+ <p>
+ The AVAILABLE state.
+ </p>
+ </doc>
+ </choice>
+ <choice name="acquired" value="1">
+ <doc>
+ <p>
+ The ACQUIRED state.
+ </p>
+ </doc>
+ </choice>
+ <choice name="archived" value="2">
+ <doc>
+ <p>
+ The ARCHIVED state.
+ </p>
+ </doc>
+ </choice>
+ </type>
+
+ <doc title="Dispositions">
+ <p>
+ The Messaging layer defines a concrete set of dispositions which can be used in the
+ <xref type="type" name="disposition"/> command:
+ </p>
+ <ul>
+ <li>
+ <p><b>released</b></p>
+ </li>
+ <li>
+ <p><b>rejected</b></p>
+ </li>
+ <li>
+ <p><b>completed</b></p>
+ </li>
+
+ </ul>
+ </doc>
+
+ <type class="compound" name="released" label="the released disposition">
+ <doc>
+ <p>
+ The released disposition is used to indicate that a given transfer was not and will not be
+ acted upon. The Messages carried by released transfers transition to the available state.
+ Messages that have been released MAY subsequently be delivered out of order.
+ Implementations SHOULD ensure that released Messages keep their position with respect to
+ undelivered Messages of the same priority.
+ </p>
+ </doc>
+
+ <descriptor name="amqp:released:map" code="0x00000001:0x00009804"/>
+
+ <field name="truncate" type="boolean" label="permit truncation of the remaining transfer">
+ <doc>
+ <p>
+ The truncate flag, if true, indicates that the receiver is not interested in the rest of
+ the Message content, and the sender is free to omit it.
+ </p>
+ </doc>
+ </field>
+
+ <field name="delivery-failed" type="boolean"
+ label="count the transfer as an unsuccessful delivery attempt">
+ <doc>
+ <p>
+ If the delivery-failed flag is set, any Messages released MUST have their
+ delivery-failures count incremented.
+ </p>
+ </doc>
+ </field>
+
+ <field name="deliver-elsewhere" type="boolean" label="prevent redelivery">
+ <doc>
+ <p>
+ If the deliver-elsewhere is set, then any Messages released MUST NOT be redelivered to
+ the releasing Link Endpoint.
+ </p>
+ </doc>
+ </field>
+
+ <field name="message-attrs" type="message-attributes" label="message attributes">
+ <doc>
+ <p>
+ Map containing attributes to combine with the existing <i>message-attrs</i> held in the
+ Message's header section. Where the existing message-attrs of the Message contain an
+ entry with the same key as an entry in this field, the value in this field associated
+ with that key replaces the one in the existing headers; where the existing message-attrs
+ has no such value, the value in this map is added.
+ </p>
+ </doc>
+ </field>
+
+ <field name="delivery-attrs" type="message-attributes" label="delivery attributes">
+ <doc>
+ <p>
+ Map containing attributes to combine with the existing <i>delivery-attrs</i> held in the
+ Message's header section. Where the existing delivery-attrs of the Message contain an
+ entry with the same key as an entry in this field, the value in this field associated
+ with that key replaces the one in the existing headers; where the existing
+ delivery-attrs has no such value, the value in this map is added.
+ </p>
+ </doc>
+ </field>
+
+ </type>
+
+ <type class="compound" name="rejected" label="the rejected disposition">
+ <doc>
+ <p>
+ The rejected disposition is used to indicate that an incoming Message is invalid and
+ therefore unprocessable. If an attempt to transfer a Message results in a reject from the
+ recipient, the sender MUST add the supplied reject-properties to the Message header
+ message-attrs. A rejected Message may be held at the node, forwarded to a different node
+ (for instance a dead letter queue) or discarded depending on configuration at the node.
+ </p>
+ </doc>
+
+ <descriptor name="amqp:rejected:map" code="0x00000001:0x00009805"/>
+
+ <field name="truncate" type="boolean" label="permit truncation of the remaining transfer">
+ <doc>
+ <p>
+ The truncate flag, if true, indicates that the receiver is not interested in the rest of
+ the Message content, and the sender is free to omit it.
+ </p>
+ </doc>
+ </field>
+
+ <field name="reject-properties" type="map">
+ <doc>
+ <p>
+ The map supplied in this field will be placed in any rejected Message headers in the
+ message-attrs map under the key "reject-properties".
+ </p>
+ </doc>
+ </field>
+ </type>
+
+ <type class="compound" name="completed" label="the completed disposition">
+ <doc>
+ <p>
+ The completed disposition is used to indicate that the Message has been processed at this
+ time, and can be moved to the ARCHIVED state. For a destructive link this is the default
+ presumptive disposition.
+ </p>
+ </doc>
+
+ <descriptor name="amqp:completed:map" code="0x00000001:0x00009806"/>
+
+ <field name="truncate" type="boolean" label="permit truncation of the remaining transfer">
+ <doc>
+ <p>
+ The truncate flag, if true, indicates that the receiver is not interested in the rest of
+ the Message content, and the sender is free to omit it.
+ </p>
+ </doc>
+ </field>
+
+ </type>
+
+ </section>
+
+
+ <section name="addressing" title="Sources and Targets">
+
+ <doc>
+ <p>
+ Concrete types <xref type="type" name="source"/> and <xref type="type" name="target"/> are
+ defined to be used in the <i>source</i> and <i>target</i> fields of the
+ <xref type="type" name="link"/> command respectively. The <xref type="type" name="source"/>
+ is comprised of an address (which the container of the outgoing Link Endpoint will resolve
+ to a Node within that container) coupled with properties which determine:
+ </p>
+ <ul>
+ <li>
+ <p>
+ which messages from the sending Node will be sent on the Link,
+ </p>
+ </li>
+ <li>
+ <p>
+ how sending the message affects the state of that message at the sending Node,
+ </p>
+ </li>
+ <li>
+ <p>
+ the length of time that the source will retain state following the destruction of the
+ Link with which it was last associated, and
+ </p>
+ </li>
+ <li>
+ <p>
+ the behaviour of Messages which have been transferred on the Link, but whose fate has
+ not yet been settled, when the source is destroyed.
+ </p>
+ </li>
+ </ul>
+
+ </doc>
+ <doc title="Distribution Modes">
+ <p>
+ The Source defines a distribution-mode. There are two defined distribution-modes:
+ <i>destructive</i> and <i>non-destructive</i>. The distribution-mode has two related effects
+ on the behaviour of the source.
+ </p>
+ <ol>
+ <li>
+ <p>
+ The <i>destructive</i> distribution-mode causes messages transferred from the node to
+ transition to the ACQUIRED state as they enter the source. The <i>non-destructive</i>
+ distribution-mode leaves the state of the Message unchanged on the Node.
+ </p>
+ </li>
+ <li>
+ <p>
+ The <i>destructive</i> distribution-mode allows messages transferred from the node to
+ have their further state transitions affected by the presumptive disposition which may
+ be altered using the <xref type="type" name="disposition"/> command. The
+ <xref type="type" name="disposition"/> command has no effect on Messages transferred
+ from a Source with a <i>non-destructive</i> distribution-mode.
+ </p>
+ </li>
+ </ol>
+ <p>
+ The distribution-mode of a Source determines how Messages from a Node are distributed among
+ its associated Sources. Messages from a Node MAY be distributed to all associated Sources
+ with a NON-DESTRUCTIVE distribution-mode, but to at most one associated Link with a
+ DESTRUCTIVE distribution mode.
+ </p>
+ </doc>
+ <doc title="Filtering Messages">
+ <p>
+ The Source has properties which control which messages from the Node enter the Link
+ associated with the Source. Firstly the source controls the set of potentially transferrable
+ Messages by restricting entry to the link based on the state of the Message at the source
+ node. By default, only Messages in the AVAILABLE state at the node are eligible for
+ transfer.
+ </p>
+ <p>
+ Secondly the source may be further restricted by the addition of a <i>filter</i>. Filters
+ can be thought of as functions which take the message as input and return a boolean value:
+ true if the message will be accepted by the source, false otherwise. A <i>filter</i>
+ MUST NOT change its return value for a Message unless the state or annotations on the
+ Message at the Node change (e.g. through an updated disposition).
+ </p>
+ <p>
+ Finally the Source MUST NOT resend a Message which has previously been successfully
+ transferred from the Source, and been settled to a COMPLETED disposition. For a
+ <i>destructive</i> source with a default configuration this is trivially achieved as such an
+ end result will lead to the Message in the ARCHIVED state on the Node, and thus anyway
+ ineligible for transfer. For a <i>non-destructive</i> state must be retained at the source
+ to ensure compliance. In practice, for nodes which maintain a strict order on Messages at
+ the node, the state may simply be a record of the most recent Message transferred.
+ </p>
+
+ </doc>
+ <!-- XXX: update this stuff-->
+ <!-- TODO
+ <doc>
+
+
+ <p>
+ If the name refers to an existing Link within the defined scope (either container or
+ Session), and the source and target are either not present or match the source and target of
+ the existing Link, then the Link end is updated to match the desired state specified in the
+ <xref name="link"/> command. If the source and target do <b>not</b> match the source and
+ target of the existing Link, then the old Link end is destroyed and a new Link end is
+ created in accordance with the <xref name="link"/> command.
+ </p>
+ </doc>
+ -->
+
+ <type class="compound" name="source">
+ <descriptor name="amqp:source:map" code="0x00000001:0x00009701"/>
+
+ <field name="address" type="address" label="the address of the source">
+ <exception name="address-not-found" error-code="not-found"/>
+ <doc>
+ <p>
+ The address is resolved to a Node in the Container of the sending Link Endpoint.
+ </p>
+ <p>
+ The address of the source MUST be set when sent on a <xref type="type" name="link"/>
+ command sent by the sending Link Endpoint. When sent by the receiving Link Endpoint the
+ address MUST be set unless the create flag is set, in which case the address MUST NOT be
+ set.
+ </p>
+ </doc>
+ </field>
+
+ <!-- XXX: this should be shared with target somehow -->
+ <field name="create" type="boolean" label="request creation of a remote Node">
+ <doc>
+ <p>
+ The create flag, if set, indicates that the local peer would like the remote peer to
+ generate a unique address. The remote peer will supply the generated address in source
+ field of the corresponding <xref type="type" name="link"/> command. If the create flag
+ is set, the source address MUST be null. The generated Node will exist until the Source
+ is destroyed. The create flag MUST NOT be set on the source carried by the
+ <xref type="type" name="link"/> sent by the outgoing Link Endpoint.
+ <!-- FIXME : lifetime of created Source -->
+ </p>
+
+ <p>
+ The algorithm used to produce the address from the Link name, must produce repeatable
+ results. If the Link is durable, generating an address from a given Link name within a
+ given client-id MUST always produce the same result. If the Link is not durable,
+ generating an address from a given Link name within a given Session MUST always produce
+ the same result. The generated address SHOULD include the Link name and Session-name or
+ client-id in some recognizable form for ease of traceability.
+ </p>
+ </doc>
+ </field>
+
+ <!-- XXX: this should be shared with target somehow -->
+ <field name="timeout" type="uint" label="the source timeout">
+ <doc>
+ <p>
+ The minimum length of time (in milliseconds) after the Session has been destroyed before
+ the source is destroyed. The value set by the receiving Link endpoint is indicative of
+ the timeout it desires, the value set by the sending Link endpoint defines the timeout
+ which will be used.
+ </p>
+ </doc>
+ </field>
+
+ <field name="distribution-mode" type="distribution-mode"
+ label="the distribution mode of the Link">
+ <doc>
+ <p>
+ This field MUST be set by the sending end of the Link. This field MAY be set by the
+ receiving end of the Link to indicate a preference when a Node supports multiple
+ distribution modes. The <xref type="type" name="disposition"/> command has no effect on
+ messages sent over a <i>non-destructive</i> Link.
+ </p>
+ </doc>
+ </field>
+
+ <field name="filter" type="filter-set"
+ label="a set of predicate to filter the Messages admitted onto the Link" />
+
+ <field name="message-states" type="message-state" multiple="true"
+ label="states of messages to be considered for sending from the source">
+ <doc>
+ <p>
+ Indicates the Message states that may be transferred over this Link. If no values are
+ set by the receiver, the sender MUST set this to <i>available</i>; otherwise the
+ sender MUST send only messages in states that are in both the sender's and receiver's
+ <i>message-states</i> values. Sources with distribution-mode of <i>destructive</i>
+ may only send messages in the <i>available</i> state.
+ </p>
+ </doc>
+ </field>
+
+ <field name="orphan-disposition" type="map" label="disposition for unacked Messages">
+ <doc>
+ <p>
+ Indicates the disposition to be used for Messages that are acquired but not acknowledged
+ when the Link is destroyed and it is no longer possible to acknowledge any of the
+ outstanding Messages, e.g. the Session is also destroyed. The value must be a valid
+ disposition (e.g. a <xref name="released"/>, or <xref name="rejected"/> value).
+ </p>
+ </doc>
+ </field>
+
+ </type>
+
+ <type class="compound" name="target">
+
+ <descriptor name="amqp:target:map" code="0x00000001:0x00009702"/>
+
+ <field name="address" type="address" label="The address of the target.">
+ <exception name="address-not-found" error-code="not-found"/>
+ <doc>
+ <p>
+ The address is resolved to a Node by the Container of the receiving Link Endpoint.
+ </p>
+ <p>
+ The address of the target MUST be set when sent on a <xref type="type" name="link"/>
+ command sent by the receiving Link Endpoint. When sent by the sending Link Endpoint the
+ address MUST be set unless the create flag is set, in which case the address MUST NOT be
+ set.
+ </p>
+ </doc>
+ </field>
+
+ <field name="create" type="boolean" label="request creation of a remote Node">
+ <doc>
+ <p>
+ The create flag, if set, indicates that the local peer would like the remote peer to
+ generate a unique address. The remote peer will supply the generated address in target
+ field of the corresponding <xref type="type" name="link"/> command. If the create flag
+ is set, the target address MUST be null. The generated Node will exist until the Link is
+ destroyed. The create flag MUST NOT be set on the target carried by the
+ <xref type="type" name="link"/> sent by the incoming Link Endpoint.
+ <!-- FIXME : lifetime of created Target -->
+ </p>
+
+ <p>
+ The algorithm used to produce the address from the Link name, must produce repeatable
+ results. If the Link is durable, generating an address from a given Link name within a
+ given client-id MUST always produce the same result. If the Link is not durable,
+ generating an address from a given Link name within a given Session MUST always produce
+ the same result. The generated address SHOULD include the Link name and Session-name or
+ client-id in some recognizable form for ease of traceability.
+ </p>
+ </doc>
+ </field>
+
+ <!-- XXX: this should be shared with source somehow -->
+ <field name="timeout" type="uint" label="the target timeout">
+ <doc>
+ <p>
+ The minimum length of time (in milliseconds) after the Link has been destroyed before
+ the target is destroyed. The value set by the sending Link endpoint is indicative of
+ the timeout it desires, the value set by the receiving Link endpoint defines the timeout
+ which will be used.
+ </p>
+ </doc>
+ </field>
+
+ </type>
+
+ <type class="restricted" name="address" source="binary"
+ label="name of the source or target for a Message">
+ <doc>
+ <p>
+ Specifies the name for a source or target to which Messages are to be transferred to or
+ from. Addresses are expected to be human readable, but are intentionally considered
+ opaque. The format of an address is not defined by this specification.
+ </p>
+ </doc>
+ </type>
+
+ <type class="restricted" name="distribution-mode" source="uint"
+ label="Link distribution policy">
+ <doc>
+ <p>
+ Policies for distributing Messages when multiple Links are connected to the same Node.
+ </p>
+ </doc>
+
+ <choice name="destructive" value="1">
+ <doc>
+ <p>
+ once successfully transferred over the Link, the Message will no longer be available to
+ other Links from the same Node
+ </p>
+ </doc>
+ </choice>
+
+ <choice name="non-destructive" value="2">
+ <doc>
+ <p>
+ once successfully transferred over the Link, the Message is still available for other
+ Links from the same Node
+ </p>
+ </doc>
+ </choice>
+ </type>
+
+ <type class="compound" name="filter"
+ label="the predicate to filter the Messages admitted onto the Link">
+
+ <descriptor name="amqp:filter:list" code="0x00000001:0x00009703"/>
+
+ <field name="filter-type" type="symbol" required="true" label="the type of the filter" />
+ <field name="filter" type="*" required="true"
+ label="the filter predicate" />
+
+ </type>
+
+ <type class="restricted" name="filter-set" source="map">
+ <doc>
+ <p>
+ A set of named filters. Every key in the map must be of type
+ <xref type="type" name="symbol"/>, every value must be of type
+ <xref type="type" name="filter"/>. A message will pass through a filter-set if and only
+ if it passes through each of the named filters
+ </p>
+ </doc>
+ </type>
+
+ </section>
+
+</amqp>