[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Updated proposed resolution to BINDINGS-102
Seems reasonable 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: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |02/11/2010 07:06 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[sca-bindings] 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]