sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Comments on issues BINDINGS-95, 105 and 106 - priority rules for headersetc.
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 5 Nov 2009 16:02:20 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]