Ok - here's my first draft of the scope for the JMS Component... all comments / questions / disagreements welcome :-)
-- Rob ---- The goal of the JMS client is to implement the JMS 2.0 api as a pure Java library using the Proton-J engine. The JMS client will implement fully the AMQP-JMS mapping as defined within the OASIS AMQP Bindings and Mappings technical committee. The JMS client will aim to interoperate with any AMQP Broker or service that similarly implements AMQP 1.0 and the JMS Mapping specification. For Brokers/Services which implement AMQP 1.0 but not the JMS Mapping specification the client should interoperate to the greatest degree possible. Non-standardised AMQP functionality will only be supported in so much as it is registered within the AMQP capabilities registries. The JMS client will support both unencrypted and encrypted (TLS) connections over TCP and should aim to support connections over other transports (SCTP, WebSockets) as these bindings emerge as standards. Authentication using SASL mechanisms ANONYMOUS, PLAIN, and CRAM-MD5 will be supported, as well as using SSL client certificates with SASL EXTERNAL. Other SASL mechanisms MAY be supported. It is not anticipated that the emerging AMQP standards around Claims based security will immediately require any special support, but this standard along with standards around Management will be reviewed to see if special support is necessary. Support for distributed transactions will be added as a standard for these over AMQP 1.0 evolves. The JMS client will aim to minimize dependencies. Logic to handle failover from one server/broker to another is currently out of scope. Use of transport protocols other than AMQP 1.0 and its successors is also out of scope (in particular the client will not support AMQP 0-8,0-9,0-9-1 or 0-10). This client will obsolete the existing qpid-amqp-1.0-client-jms component.
