Hi Simon,
Insofar as any of what you wrote up makes you wish you could get
changes in the JMS URI spec, please don't hesitate send an email to the
authors. Either that, or you can send an email to the
uri-review@ietf.org mailing list.
At the moment, I'm waiting on Oracle's sign-off on a change in the
legalese that the IETF introduced this year (hint to Anish & Ashok,
please remind Jeff Mischinsky on this point). Once that's in place, I
intend to do one last update to the draft, one final round of review at
uri-review@ietf.org, then request publication as an RFC. So if there
are useful changes you (or anyone else on the TC, for that matter) see
that should be made to the URI scheme, now's the time to bring those
issues up.
-Eric.
Simon Holdsworth wrote:
OF971637E1.3CBB0826-ON80257665.004F54C4-80257665.0057E8B9@uk.ibm.com"
type="cite">
These three issues relate to the
normative
statements regarding priorities between different places for specifying
the same information in the JMS binding.
I've taken another look at the
current
JMS URI spec (http://www.ietf.org/id/draft-merrick-jms-uri-06.txt)
and the text in the JMS binding, as well as the current set of three
issues,
to figure out the best way to resolve these consistently.
One point to mention here is that
the
JMS URI spec allows custom properties in the URI, but it does not state
any relationship between those custom properties and user properties in
a JMS message. The JMS spec currently is written to allow this
relationship;
it is also written to allow the message selector to be present in the
URI,
although the JMS URI spec does not define a standard means for this to
be done, so we need to consider whether we allow these cases or remove
them.
Another point is that JMS user
properties
have a number of different types, which can be specified in the JMS
binding,
but there's no text that describes that at all.
----------------------------------------
Overall, the following rules apply
(note
these are not stated in this form anywhere in the binding specification:
A) JMS headers (type, delivery mode,
time to live, priority)
For each JMS header, the value set
in
a message sent by the JMS binding is taken from the binding definition
in the following priority order:
A1) the value for the header
specified
in the @uri attribute;
A2) the value for the header
specified
in the operationProperties/headers element matching the operation being
invoked;
A3) the value for the header
specified
in the headers element.
B) User properties
For each JMS user property, the name
and value set in a message sent by the JMS binding is taken from the
binding
definition in the following priority order:
B1) the name and value for the user
property specified in the @uri attribute, assuming String type (not
standardised
by the JMS URI spec)
B2) the name, type and value for the
user property specified in an operationProperties/headers/property
element
matching the operation being invoked;
B3) the name, type and value for the
user property specified in a headers/property element.
C) Message selector
For the message selector, the value
used for a JMS binding is taken from the binding definition in the
following
priority order:
C1) the value for the message
selector
specified in the @uri attribute (not standardised by the JMS URI spec)
C2) the value for the message
selector
specified in the messageSelection/@selector attribute.
----------------------------------------
Normative statements:
Currently to enforce this priority
order,
we have the following normative statements:
[A1 and B1 and C1] An SCA runtime
MUST
use the values specified in the @uri attribute in preference to
corresponding
attributes and elements in the binding [BJM30035].
[A3 but not A1] The SCA runtime MUST
set JMS headers in messages that it creates to the values specified by
the headers element unless overridden for the operation being invoked.
[BJM30024].
[A1 again] If the @uri attribute
includes
values for the type, delivery mode, time to live or priority properties
then the @uri values are used and the headers and
operationProperties/headers
@type, @deliveryMode, @timeToLive or @priority attributes are ignored
[BJM30025].
[B3 but not B1] For each
header/properties
element the SCA runtime MUST set the named JMS user property to the
given
value in messages it creates unless overridden for the operation being
invoked [BJM30026].
[A2 but not A1] The SCA runtime MUST
set JMS headers in messages it creates when the operation identified by
the operationProperties/@name attribute is invoked to the values
specified
by the corresponding operationProperties/headers element [BJM30032].
[B2 but not B1] For each
operationProperties/headers/property
element the SCA runtime MUST set the named JMS user property to the
given value in messages it creates when the operation identified by the
operationProperties/@name attribute is invoked [BJM30033].
[C1 again] If the @uri attribute
includes
a value for the message selector then the @uri value is used and the
messageSelection/@selector
attribute is ignored [BJM30027].
[C2] No normative statement
Issue 95 covers the fact that
BJM30032
[A2 but not A1] and BJM30035 [A1] conflict.
Issue 105 covers the fact that
BJM30025
[A1 again] has no normative keywords, although all it is doing is
repeating
BJM30035 [A1 and B1 and C1] so the proposal there is to remove the
normative
keywords from BJM30025.
Issue 106 is around BJM30027 [C1
again]
having no normative keyword. I'd propose that we resolve 106 by
ensuring
we have normative statements that cover C1 and C2.
We don't have issues for the fact
that
BJM30033 [B2 but not B1] and BJM30035 [A1 and B1] conflict, or that
BJM30024
and BJM30026 conflict with BJM30035.
----------------------------------------
Resolution via modifying existing
statements:
In terms of resolving these issues,
one approach would be:
Issue 95: Modify normative
statements
for headers and user properties as follows:
Leave: [A1 and B1 and C1] An SCA
runtime
MUST use the values specified in the @uri attribute in preference to
corresponding
attributes and elements in the binding [BJM30035].
Change: [A2] The SCA runtime MUST
set
JMS headers in messages it creates when the operation identified by the
operationProperties/@name attribute is invoked to the values specified
by the corresponding operationProperties/headers element unless those
values
are specified in the @uri attribute [BJM30032].
Change: [A3] The SCA runtime MUST
set
JMS headers in messages that it creates to the values specified by the
headers element unless overridden for the operation being invoked or
specified
in the @uri attribute [BJM30024].
Change: [B2] For each
operationProperties/headers/property
element the SCA runtime MUST set the named JMS user property to the
given value with the given type in messages it creates when the
operation
identified by the operationProperties/@name attribute is invoked,
unless
the named user property is specified in the @uri attribute. [BJM30033].
Change: [B3] For each
headers/property
element the SCA runtime MUST set the named JMS user property to the
given
value with the given type in messages it creates unless the named user
property is specified for the operation being invoked or in the @uri
attribute
[BJM30026].
Issue 105:
Change to non-normative: [A1 again]
If the @uri attribute includes values for the type, delivery mode, time
to live or priority properties then the @uri values are used and the
headers
and operationProperties/headers @type, @deliveryMode, @timeToLive or
@priority
attributes are ignored.
Issue 106:
Change: [C1] If the @uri attribute
includes
a value for the message selector then the SCA runtime MUST receive
messages
using that message selector [BJM30027]
Add: [C2] If the
messageSelection/@selector
attribute is specified and no message selector is specified via the
@uri
attribute then the SCA runtime MUST receive messages using the message
selector identified by the messageSelection/@selector attribute
[BJM300XX]
----------------------------------------
Alternative resolution using
explicit
priority rules.
The alternative would be to remove
all
these normative statements and replace them with three following
statements:
Issue 95/105:
3.2 JMS headers and User Properties
(new section)
The JMS binding allows you to
specify
that JMS headers are set to specific values in messages sent by the SCA
runtime. The binding provides several places where JMS message
headers
and user properties may be specified at different levels of granularity.
When sending messages for a JMS
binding,
the SCA runtime MUST set each of the type, delivery mode, time to live
and priority JMS headers to values specified in the binding definition
in the following priority order:
1) the value for the header
specified
in the @uri attribute;
2) the value for the header
specified
in the operationProperties/headers element matching the operation being
invoked;
3) the value for the header
specified
in the headers element;
4) the default value for the header
[BJM300XX]
When sending messages for a JMS
binding,
the SCA runtime MUST set each named user property with type and value
specified
in the binding definition in the following priority order:
1) the value for the named user
property
specified in the @uri attribute, assuming a string type;
2) the type and value for the named
user property specified in an operationProperties/headers/property
element
matching the operation being invoked;
3) the type and value for the named
user property specified in a headers/property element [BJM300XX]
Issue 106:
3.3 JMS Message Selection
(new section)
Message selectors allow the JMS
binding
to receive a specific subset of messages from a given destination, such
that only messages that match the selector are delivered to a given JMS
binding. This allows more than one JMS binding to share a destination.
When receiving messages for a JMS
binding,
the SCA runtime MUST use a message selector if specified in the binding
definition in the following priority order:
1) the value for the message
selector
specified in the @uri attribute;
2) the value for the message
selector
specified in the messageSelection/@selector attribute;
3) otherwise no message selector is
used [BJM300XX].
----------------------------------------
Comments?
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC
Chair
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
|