Thursday, August 11, 2011

RFC-6167 notes

This post outline some key points of the RFC-6167. This specification defines a new URI scheme for JMS objects ( such as ConnectionFactories, Queues and Topics). Following are some of the key points.

1. The name of the URI Scheme is "jms".

2. Syntax of a JMS URI looks like below.
jms-uri = "jms:" jms-variant ":" jms-dest

[ "?" param *( "&" param ) ]
jms-variant = segment-nz-nc
jms-dest = segment-nz ; specific meaning per variant
param = param-name "=" param-value
param-name = 1*(unreserved / pct-encoded)
param-value = *(unreserved / pct-encoded)
segment-nz-nc = <as defined in RFC 3986>
path-rootless = <as defined in RFC 3986>
unreserved = <as defined in RFC 3986>
pct-encoded = <as defined in RFC 3986>


3. RFC-6168 only defines how to address JMS resources and DO NOT specify actions to be taken on those resources. Those operations are normally defined by the JMS API.

4. <jms-variant> can be either jndi, queue, topic or a vendor specific type(example : vnd.example.ex).

5. All the terminals that result from <jms-variant> and <jms-dest> are case sensitive.

6. Parameter can appear in any order and name of a parameter SHOULD NOT appear more than once. If same parameter appear more than once only the last parameter value should be considered.

7. Each variant can have query parameters specific to that variation. All such variant-specific parameters SHOULD use the name of the variant as the prefix to the parameter.
Example: Vendor specific jms-variant - vnd.example.ex and for a parameter called Parameter, it should name as vnd.example.exParameter.

8. Parameters that apply across multiple variants MUST NOT have a name that starts with the name of any known variants.

9. Examples URI.
jms:jndi:REQ_QUEUE?jndiURL=file:/C:/JMSAdmin

&jndiInitialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory
&jndiConnectionFactoryName=CONNFACT
&replyToName=RESP_QUEUE

jms:jndi:REQ_QUEUE?jndiURL=file:/C:/JMSAdmin

&jndiInitialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory
&jndiConnectionFactoryName=CONNFACT
&jndi-com.example.jndi.someParameter=someValue

jms:topic:REQ_QUEUE?timeToLive=1000

&priority=2


10. Shared parameters. Parameters which are available for all jms-variant are called shared parameters. These parameters are corresponds to various JMS headers that comes in the JMS message.
  • deliveryMode(JMSDeliveryMode header) - PERSISTENT | NON_PERSISTENT
  • timeToLive - lifetime in milliseconds
  • priority(JMSPriority) - a value between 0 and 9(inclusive)
  • replyToName(JMSReplyTo)/topicRelyToName - the queue name of the reply message and if using a topic variant should use topicReplyToName
11. The JNDI-specific parameters SHOULD only be processed when the URI variant is "jndi".
  • jndiInitialContextFactory - Fully qualified Java class name of the "InitialContextFactory" implementation class to use.
  • jndiURL - Specify the JNDI provider URL.
12. Additional JNDI parameters should be prefix with jndi-.
Ex: If the JNDI provider needs a parameter called com.example.jndi.someParameter and it should be provided in the URI as:
jndi-com.example.jndi.someParameter=someValue

13. A JMS URI MUST NOT specify both replyToName and topicReplyToName.

14. Characters "?" and "&" MUST BE encoded when they appear within section or in a query parameters.


15. The character ":" SHOULD BE escaped when appearing in the <jms-dest> portion of the syntax.


2 comments:

  1. Thanks for the notes on RFC 6167. Do you know if there are any existing Java classes that can be passed a JMS URI and will connect to the requested destinations?

    ReplyDelete
  2. Not any library that I am aware of. But it should be fairly straight forward to implement IMO.

    Rajika

    ReplyDelete