URI Scheme for JMS Test Comments

URI Scheme for JMS Test Comments

The "Abstract" talks about general applicability of JMS URI for locating
a  destination, i.e. that SOAP/JMS is not the only use.

So, we could have a separate test suite -  in addition to those for the
SOAP/JMS use case -  that test the ability of an implementation to
interpret, send and receive against a list of test URIs.

Testable Assertions
    
Section 3 Syntax of a jms URI is a definitive ABNF definition.

Section 3.1 URI scheme semantics has the following assertions

"JMS URI schemes are used to locate JMS Destination resources"
	
"The required particles in the JMS URI are the scheme name ("jms"),  the
variant identifier, and the "jms-dest" portions.   The two recognized
variants (jms-variant above) are "jndi", and "context".
    
There are "may" and "should" statement for which perhaps we have
non-mandatory tests:

"Each variant may have query parameters specific to that variation."

"All such parameters that cannot be shared across schemes should use the
name  of the variant as the prefix to the parameters."

"Parameters that apply across multiple variants, perhaps because they
are  generally applicable, such as JMS settings, should not have any
particular  prefix, and should not begin with any known prefix."
    
Section 4.1 "Shared Parameters" has definitive statements on the
following  parameters, how they map to JMS, how they default

deliveryMode
timeToLive
priority
replyToName

Section 4.2.1 JNDI Parameters has clear statements on what the JNDI
parameters are with reference the JNDI spec and on how destinations are
derived.:
		
jndiConnectionFactoryName
jndiInitialContextFactory
jndiURL

"To perform a look-up based on a JNDI variant URI an application must
create a  JNDI InitialContext object.  The InitialContext object can
then be used to look  up the JMS ConnectionFactory object (using the
"jndiConnectionFactoryName" URI  parameter); the target JMS Destination
object (using the "jms-dest" portion of  the JMS URI); and the
"replyToName" JMS Destination object (if the  "replyToName" parameter is
specified on the  URI)." etc etc


Section 4.3 Context Variant

"The "context" variant intends that the jms-dest is purely a logical
name, ...  How this binding is done is outside the scope of this
specification."

"Note that all of the shared parameters defined above may be used with
this variant"

"The lookup mechanism for the context variant must result in etc"

"The set of parameters is extensible.  "

 

"Encoding considerations"

Escaping rules for "?", "&"  and (optionally ":") within jms-dest should
be tested. 

Should sentences

"Message senders are strongly urged to remove from the URI extra
parameters  like the above in environments where the data will be
redundant with information specified elsewhere in the JMS message. "

"If a recipient is aware of the jms URI scheme, and it receives a
message  containing a JMS URI, it MUST ignore or discard parameters that
it does not  recognize."