Folks,
Replies inline as <mje>...</mje>
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:
"Michael Rowley"
<>
20/11/2007 21:03
To
Mike Edwards/UK/IBM@IBMGB, "OASIS
Assembly" <>
cc
Subject
RE: [sca-assembly] ISSUE 6 - alternate
proposal - Version 2 updated
I like this. I’ve include
just a couple comments inline.
Michael
From: Mike Edwards [mailto:]
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.
<mje> I don't follow
this comment - I think that the previous paragraph outlaws the mixing of
@target
and binding/@uri for all
cases (at least, that is what I intended and it is how I read the paragraph).
Why do we need to re-state
the same thing for 0..n references?
</mje>
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.
<mje>Agreed</mje>
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.
<mje>Interesting point. Depends on your runtime model. If
reference proxies don't change,
then it may be valid to
test before invocation. If reference proxies do change ("smart
proxy"
concept) then it ain't
so clear - especially for composite scoped components. Think carefully
about how a BPEL process
would be handled in this respect. Deployment acts can occur
while such components are
"running". "Before the reference is invoked"
was a deliberate
attempt on my part to address
this dynamic situation. When the reference is invoked you
should definitely know....
PS this calls more than
ever for a runtime spec
</mje>
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?
<mje>Excellent question.
I don't have a clear answer. One place might be some monitoring
entity - but this then
begs the question of a management model for the SCA runtime.
(Another todo, in my opinion)
Reporting the error to
the component might be another possibility, but what the component
would do about it is not
clear to me.
In any case, I dont want
to try to answer this question in THIS proposal - I feel a new issue
being born....
</mje>
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
<mje>I don't agree
with you here. componentName/serviceName is always a fine description
for some service within the SCA Domain, even if
some binding like binding.ws
is being used. I don't see why @target has to be used, particularly
if in x..n multiplicity cases, different targets
REQUIRE different bindings.
Users are always free to give a URI which is binding specific, but
why force them to do that when not necessary?
</mje>
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:
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
