I like this. I’ve include just
a couple comments inline.
Michael
From: Mike
Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Monday, November 19, 2007
11:49 AM
To: OASIS Assembly
Subject: Re: [sca-assembly] ISSUE
6 - alternate proposal - Version 2 updated
I've updated the proposal to put in more text dealing
with the error cases for multiplicity in
section
3.0.1.1, to answer points raised in the discussion on the list.
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.
We
should explicitly note that for 0..n references, it is not legal to mix targets
specified using @Target and binding/@uri.
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.
The
assembler or the deployer of the
composite, since the reference could be resolved by acts of the deployer.
For
the error cases identified above, an error MUST be generated by the SCA
runtime before the reference is invoked by the
component implementation.
I would
prefer that this error occur before the component that contains the reference
is invoked.
Some
errors can be detected at deployment time. For example, where a
composite is
used as a component implementation, wires and target services
cannot be
added to the composite after deployment. As a result, for
components
which are part of the composite, both missing
wires and
wires with a non-existent target can be detected at deployment
time through
a scan of the contents of the composite. In these cases, an
error SHOULD
be generated by the SCA runtime at deployment time.
Other errors
can only be checked at runtime. Examples include cases of
components
deployed to the SCA Domain. At the Domain level, the target of
a wire, or
even the wire itself, may form part of a separate deployed
contribution
and as a result these may be deployed after the original
component is
deployed. In these cases, the SCA runtime MUST generate an
error before
the reference is invoked by the component implementation.
Who
would the error be reported to? What would happen to the component that
is currently running?
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).
I’m
not sure about specifying “componentName/serviceName” as a valid
target for bindings. I believe it would be better for these URI to be
absolute, rather than relative, since if they were relative, it means that the
target must be in SCA, in which case the @target attribute should have been
used.
Michael
Rowley
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