sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Draft proposed resolution to BINDINGS-102, needs input
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 14 Jan 2010 15:55:11 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]