OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Updated proposed resolution to BINDINGS-102



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]