[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 6 - alternate proposal - Version 2 !
It looks good to me. As far as I can tell, it has the same technical
points that I wanted to cover, with the additional dimension of autowire
included. I think that's good. Your proposal is more verbose, but
sometimes that can be beneficial.
I spotted one typo in the following; delete one of "created" or "implied".
I prefer created.
Where the reference has a value specified in its @target attribute, all the
binding types identified by the child binding elements
are available for use on each wire created implied by the @target
attribute.
Final comment in passing. We need to take a look at the Wires section (6.4
currently) and align it with this new text also. But that's going to be
alot more work that might be better done under a seperate issue. This one
is starting to get large and we aren't really changing anything, just
clarifying.
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
Mike Edwards
<mike_edwards@uk.
ibm.com> To
"OASIS Assembly"
11/13/2007 09:27 <sca-assembly@lists.oasis-open.org>
AM cc
Subject
Re: [sca-assembly] ISSUE 6 -
alternate proposal - Version 2 !
Dave,
I've been pondering this some more and I think there is a need to go
further than your proposal text.
The main issue here is to define what it means for a reference to have one
or more target services configured, either through wiring or through
promotion:
a) Wiring through promotion by a composite reference element
b) Wiring through the use of value of @target on the enclosing reference
element
c) Identification of a target service through the @uri attribute on the
binding element
d) Identification of a target service through binding-specific attributes
and child elements, as defined in
the specification for the specific binding
e) autowire
....and that is the order of precedence....
In order to deal with all this, I think that we must introduce a new
subsection into the specification, to follow line 330:
3.0.1 Specifying the Target Service(s) for a Reference
A reference may define one or more target services which satisfy the
reference. The target service(s) may be
defined in the following ways:
1) Through a value specified in the @target attribute of the reference
element.
2) Through a target URI specified in the @uri attribute of a binding
element which is a child of the reference element
3) Through the setting of one or more values for binding-specific
attributes and/or child elements of a binding element
which is a child of the reference element
4) Through the specification of @autowire="true" for the reference (or
through inheritance of that value from the component or composite
containing the reference)
5) Through the promotion of a component reference by a composite reference
of the composite containing the component (the target service is then
identified by the configuration of the composite reference).
Some combinations of these different methods are not allowed:
If @autowire="true" applies to the reference, the autowire procedure is
only used to find a target service if no target is identified by any of the
other ways listed above. It is not an error if autowire="true" applies to
a reference and a target is also defined through some other means.
If a reference has a value specified for one or more target services in its
@target attribute, the child binding elements,
of that reference MUST NOT identify target services using the @uri
attribute or using binding specific attributes or elements.
If a binding element has a value specified for a target service using its
@uri attribute, the binding element MUST NOT identify
target services using binding specific attributes or elements.
It is possible that a particular binding type MAY require that the address
of a target service uses more than a simple URI. In such
cases, the @uri attribute MUST NOT be used to identify the target service -
instead, binding specific attributes and/or child
elements must be used.
Where the reference has a value specified in its @target attribute, all the
binding types identified by the child binding elements
are available for use on each wire created implied by the @target
attribute.
3.0.1.1 Multiplicity and the Valid Number of Target Services for a
Reference
For references with multiplicity 0..1 or 0..n, it is valid for the
reference to have no target service defined.
For references with multiplicity 0..1 or 1..1, it is an error for the
reference to have more than 1 target service defined.
For references with multiplicity 1..1 or 1..n, it is an error for the
reference to have no target service defined.
For references with multiplicity 0..n or 1..n, it is valid for the
reference to have 1 or more target services defined.
The assembler of a composite MUST ensure that references are properly
configured according to these rules.
For the error cases identified above, an error MUST be generated by the SCA
runtime before the reference is invoked
by the component implementation.
For the cases where it is valid for the reference to have no target service
specified, the component implementation language
specification defines the programming model for interacting with an
untargetted reference.
Where a component reference is promoted by a composite reference, the
promotion is treated from a multiplicity perspective
as providing 0 or more target services for the component reference,
depending upon the further configuration of the composite
reference. These target services are in addition to any target services
identified on the component reference itself, subject to
the rules relating to multiplicity described in this section
----------------------------------------------------------------------
Replace lines 274 - 280 with the following:
"A reference may identify one or more target services which satisfy the
reference. This can be done in a
number of ways, which are fully described in section "3.0.1 Specifying the
Target Service(s) for a Reference".
Replace lines 1424 - 1430 with the following:
"A reference may identify one or more target services which satisfy the
reference. This can be done in a
number of ways, which are fully described in section "3.0.1 Specifying the
Target Service(s) for a Reference".
Replace lines 2372 - 2383 with the following:
uri - has the following semantic
The uri attribute can be omitted.
For the binding of a reference, the uri attribute defines the
target URI of the reference. This can be either the
componentName/serviceName for a wire to an endpoint within the SCA
domain, or the accessible address of some service
endpoint either inside or outside the SCA domain (where the
addressing scheme is defined by the type of the binding).
The circumstances under which the uri attribute can be used are
defined in section 3.0.1 Specifying the Target Service(s) for a
Reference
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
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]