Draft proposed resolution to BINDINGS-102, needs input

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

Draft proposal for resolution to BINDINGS-102
"Need to specify all valid enumerations for @create attribute and
others" 

This issue is against the JCA binding,
however there are similar changes that could be made for the JMS binding
spec, which I've described after the JCA changes.  The WS binding
does not define any enumerations.

Note in both cases all suggested changes
are editorial for clarification and do not change any behaviour or normative
statements - so I the TC is happy with the JMS binding text updates I believe
we could handle that update as an editorial action - alternatively we need
a JMS variant of issue 102 to be opened.

JCA binding:

These are the enumerations defined by
binding.jca:

<outboundConnection managed="xs:boolean">
 

This is fully defined in lines 129-135,
although it doesn't explicitly say that it takes one of the values {"true",
"false", "1", "0"} but that should be implicit
from xs:boolean.  Suggestion here is no change required.

<connection jndiName=”xs:anyURI”
type="NMTOKEN” create=”always or never or ifNotExist”?>  
<activationSpec jndiName=”xs:anyURI”
type="NMTOKEN” create=”always or never or ifNotExist”?>  

As per resolutions to issues 88 and
89, so now we have the values in the pseudo schema, but don't describe
each value in the @create attribute description.

Suggestion is to add the following to
the description of the @create enumeration values for the connection and
activationSpec elements, between the existing text that lists the values,
and the sentence that states the default:

[ Valid values are ....  ] "always"
indicates that new resources are created for use by this binding; "never"
indicates that existing resources are used and none created; "ifNotExist"
indicates that if the resources already exist those are used, otherwise
new ones are created. Refer to the binding.jca/outboundConnection/connection/@jndiName
attribute for a detailed definition of each case. [The default value is...
]

<resAuth>container|application</resAuth>


Currently no mention of the values in
the element description.

Suggestion is to add the following to
the description of the resAuth element:

Valid values are "container"
and "application".  "container" indicates that
the runtime container takes the responsibility of configuring and managing
the EIS sign-on; "application" indicates that the component includes
logic that performs the sign-on process to the EIS. If this element is
omitted then no authentication is required by this binding definition.

This is the bit that I need some help
on.  I'm not sure how with the JCA binding we would expect an SCA
component to "perform the sign-on process".  It may be that
the expectation is that it is the binding.jca implementation that is the
"application" in this case (performing the sign-on process based
on the binding.jca subelements?), but I'm not sure.

Also note that this is the only enumeration
we have that is defined as an element rather than an attribute.  I'm
not clear on why this is necessary.

-----------------------------------------

JMS binding:

These are the enumerations defined by
the JMS binding spec:

<destination type="queue or
topic">

Current text is:   the type of
the request destination. Valid values are “queue” and “topic”.  The
default value is “queue”   I feel that that is sufficient.

<destination create=”always or never
or ifNotExist”>
<connectionFactory create=”always
or never or ifNotExist”>
<activationSpec create=”always or
never or ifNotExist”>

Same comment applies as for JCA binding,
suggestion would be to add the following to the description of the create
attribute of these elements, between the existing text that lists the values,
and the sentence that states the default:

[ Valid values are ....  ]  "always"
indicates that new resources are created for use by this binding; "never"
indicates that existing resources are used and none created; "ifNotExist"
indicates that if the resources already exist those are used, otherwise
new ones are created. Refer to the binding.jms/destination/@jndiName attribute
for a detailed definition of each case.  [The default value is...
]

<binding.jms><headers deliveryMode="persistent
or nonpersistent" priority="0 .. 9">

Current text is (after applying BINDINGS-90):
Valid values for @deliveryMode are "persistent" and "nonpersistent"
with "persistent" being the default; valid values for @priority
are "0" to "9", with "4" being the default;
valid values for @timeToLive are positive integers, with 0 indicating unlimited
time and being the default value. 

Suggestion is to change this text to:

Valid values for @deliveryMode are "persistent"
and "nonpersistent", corresponding to the values defined for
the JMSDeliveryMode message header, with "persistent" being the
default; valid values for @priority are integers in the range "0"
to "9", where "0" indicates lowest priority and "9"
highest priority, with "4" being the default; valid values for
@timeToLive are positive integers, with 0 indicating unlimited time and
being the default value. 

<binding.jms><operationProperties><headers
deliveryMode="persistent or nonpersistent" priority="0 ..
9">

Current text does not describe the possible
values.  Suggestion is to add:

Refer to the description of the <headers>
child of <binding.jms> for the valid values for these attributes.

-----------------------------------------

Regards, Simon

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
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