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
- jndiInitialContextFactory - Fully qualified Java class name of the "InitialContextFactory" implementation class to use.
- jndiURL - Specify the JNDI provider URL.
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
15. The character ":" SHOULD BE escaped when appearing in the <jms-dest> portion of the syntax.
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?
ReplyDeleteNot any library that I am aware of. But it should be fairly straight forward to implement IMO.
ReplyDeleteRajika