JMS Component Scope [1st Draft]

[Rob Godfrey <ro...@gmail.com>]

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.