sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Updated proposed resolution to BINDINGS-102
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 11 Feb 2010 12:10:39 +0000
Dave,
My updated understanding is that resAuth=application
indicates that information provided by the "application" in the
connectionSpec is used to perform authentication, rather than the runtime
using whatever security context is currently in force (i.e. the context
held by the runtime "container"). It does not mean that
the application code calls EIS-specific APIs to perform the authentication,
i.e. it does not expose any details of the use of the EIS binding to the
connected component(s). I would prefer we retain the terms that would
be familiar to JCA users. So given that the JCA binding already includes
the ability to specify connectionSpec, I think the definition of the resAuth
values could be worded as follows:
Valid values are "container"
and "application". "container" indicates that the SCA
runtime takes the responsibility for configuring and managing the EIS sign-on;
"application" indicates that the security details specified via
the outboundConnection/connectionSpec element are used instead. If this
element is omitted then no authentication is required by this binding definition.
Here's the updated proposed resolution:
-------------------------------------------------
This issue is against the JCA binding,
however there are similar changes that should be made for the JMS binding
spec, which I've described after the JCA changes as a proposed editorial
action item.
Make the following editorial changes
to the JCA binding:
For <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.
No change required.
For:
<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, we have the values in the pseudo schema, but don't describe each value
in the @create attribute description. 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...
]
For <resAuth>container|application</resAuth>
there is currently no mention of the values in the element description.
Add the following to the description of the resAuth element:
Valid values are "container"
and "application". "container" indicates that the SCA
runtime takes the responsibility for configuring and managing the EIS sign-on;
"application" indicates that the security details specified via
the outboundConnection/connectionSpec element are used instead. If this
element is omitted then no authentication is required by this binding definition.
-----------------------------------------
Create an editorial action item against
the JMS binding to make the following changes:
For <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”.
No change required.
For:
<destination create=”always or never
or ifNotExist”>
<connectionFactory create=”always
or never or ifNotExist”>
<activationSpec create=”always or
never or ifNotExist”>
The same comment applies as for JCA
binding - 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...
]
For: <binding.jms><headers
deliveryMode="persistent or nonpersistent" priority="0 ..
9"> Change the current text from:
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.
To:
Valid values for @deliveryMode are "persistent"
and "nonpersistent", corresponding to the values defined in the
JMS Specification [JMS] 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.
For: <binding.jms><operationProperties><headers
deliveryMode="persistent or nonpersistent" priority="0 ..
9"> the current text does not describe the possible values. Add:
Refer to the description of the <headers>
child of <binding.jms> for the valid values for these attributes.
-----------------------------------------
Simon Holdsworth
From:
| David Booz <booz@us.ibm.com>
|
To:
| sca-bindings@lists.oasis-open.org
|
Date:
| 14/01/2010 16:01
|
Subject:
| Re: [sca-bindings] Draft proposed resolution
to BINDINGS-102, needs input |
Yes, I agree, but the component developer wouldn't
be using JCA adapter
specific APIs to do it, they would be using JCA binding specific APIs.
In
the context of JCA, resAuth=application means JCA specific APIs. Certainly
we could redefine the meaning of "application" for our context,
but I'm not
sure that this kind of overloading is helpful.
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Mike Edwards <mike_edwards@uk.ibm.com>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|sca-bindings@lists.oasis-open.org
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|01/14/2010 10:52 AM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [sca-bindings] Draft proposed resolution to BINDINGS-102, needs
input
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Folks,
I think that the proposal is OK, but I tend to agree with Dave's
observations below, with one twist.
While we may prefer SCA component implementations not to use any APIs to
do
things like set up
authorization credentials, such APIs do exist and I suppose there is a
distiction to be made for
implementations that use such APIs, versus the "more SCA" concept
of the
component configuration
pointing at the appropriate information. So perhaps this is the real
value
of "application" ?
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From: David Booz <booz@us.ibm.com>
To: sca-bindings@lists.oasis-open.org
Date: 14/01/2010 15:15
Subject: Re: [sca-bindings] Draft proposed resolution to BINDINGS-102,
needs input
FWIW, I think you're correct that resAuth=application actually means that
the binding implementation is taking care of the sign-on process. As
such,
the value "application" is not a great choice. It's not even
clear to me
that there's value in the distinction between container and application
(i.e. binding impl) resAuth. A binding impl could be viewed as part
of a
runtime container. There's no SCA Runtime spec to clarify this sort of
distinction. Do we need resAuth=application?
That aside, it seems to follow that some binding configuration might
be
needed to make resAuth=application sign-on happen. Would a binding
provider use the extensibility mechanisms in JCAInboundConnection or
JCAOutboundConnection to do this? Or do we need to make the resAuth
element extensible in order to carry the necessary configuration. Maybe
we
should assume that the config is kept outside the binding instance in an
SCA runtime specific location, given that we're talking about sensitive
information?
As far as the rest of your proposal goes, looks good to me.
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Simon Holdsworth <simon_holdsworth@uk.ibm.com>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|sca-bindings@lists.oasis-open.org
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|01/14/2010 07:14 AM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[sca-bindings] Draft proposed resolution to BINDINGS-102, needs input
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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
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
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]