Re: [sca-bindings] Comments on issues BINDINGS-95, 105 and 106 - priorityrules for headers etc.

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Eric,

I've been thinking about this some more.
 While it makes sense for a particular client to set JMS user properties
a particular way for all operations, or for a specific operation, it doesn't
really make sense for a JMS application to require that all clients set
a user property to a specific fixed value - that's what the URI function
I said was missing would produce; the same is true I think for the message
selector - it doesn't make sense for the JMS application to mandate a specific
value for all clients to use via the URI. So I don't think the JMS URI
spec is inadequate in this respect.

That being said, when you configure
a JMS binding on a reference in particular, the URI value is copied into
the binding configuration, which means at that point there's no reason
why you couldn't modify the URI to contain client-specific values, rather
than setting them on elements/attributes within the binding itself.  For
that reason I'd prefer to say that values in the URI take precedence, even
if the JMS URI standard does not define how you would specify the message
selector or user properties.  

So the two alternative proposals in
my email still stand.  I'm hoping we can get these issues resolved
over the next week or two so that we can get to CD03-rev1 of the specs
and a corresponding CD candidate for the TA documents.

Any comments on the style of 1 normative
statement per option vs. 1 normative statement for the entire prioritised
list?  Assembly has one example of the latter - [ASM12023]

Regards, Simon

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

From:	Eric Johnson <eric@tibco.com>
To:	Simon Holdsworth/UK/IBM@IBMGB
Cc:	sca-bindings@lists.oasis-open.org
Date:	05/11/2009 23:07
Subject:	Re: [sca-bindings] Comments on issues BINDINGS-95, 105 and 106 - priority rules for headers etc.

---

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: 

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

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

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