Folks,
Comments 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:
From:
David Booz <>
To:
Date:
18/08/2008 13:29
Subject:
Re: [sca-assembly] ISSUE 41: Conflicting
domain-level <wire> deployments - Proposed Resolution.
Mike,
Two questions.
i) What is the identity of a wire element so that the runtime knows whether
or not you're replacing it?
<mje>We discussed
this at the F2F and we decided that anything deployed into the
domain has to have its
"origins" remembered so that it can be later undeployed.
So "replacement"
= deployment where the same deployment composite name is
used as a previous deployment.</mje>
ii) Suppose there is a component A in the domain with reference A.R (0..n),
configured with @target="B". I'm not sure it matters, but
suppose this
component came from composite X.
Further suppose there is a deployment of composite Z which contains <wire/>
elements connecting A.R to "C" and "D".
Finally, suppose Z is redeployed containing only one wire element (with
replace=true), connecting A.R to "E". What happens to the
wires connecting
A.R to "C" and "D"?
<mje>The wires linking
A.R to C and D are logically undeployed and replaced by the
wire to E. The timing
of the update to the component A is discussed in the section
on dynamic behaviour in
my proposal.</mje>
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:
Mike Edwards
<mike_edwards@uk.
ibm.com>
To
"OASIS
Assembly"
08/15/2008 10:57
<>
AM
cc
Subject
Re: [sca-assembly]
ISSUE 41:
Conflicting
domain-level <wire>
deployments
- Proposed Resolution.
Brian,
The scenario you give would cause an error.
@replace=true does NOT replace any existing <wire/> elements using
a given
component reference as a source.
If adding the new wire then violates the multiplicity of the component
reference, it's an error.
If you want to replace an existing <wire/>, go redeploy the <wire/>.
(ie
remove the old one and replace it with the new one)
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:
From: Bryan Aupperle <>
To: "OASIS Assembly" <>
Date: 15/08/2008 15:12
Subjec Re: [sca-assembly] ISSUE 41: Conflicting domain-level <wire>
t: deployments - Proposed Resolution.
Does adding a <wire/> element with @replace="true" and
a source component
reference with multiplicity 0..1 or 1..1 that is already wired via an
existing <wire/> element result in an error or does the new wire
replace
the existing wire?
Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Research Triangle Park, NC
+1 919-254-7508 (T/L 444-7508)
Internet Address:
Mike Edwards
<>
To
08/15/2008 08:49 AM
"OASIS Assembly"
<>
cc
Subject
[sca-assembly]
ISSUE 41: Conflicting
domain-level <wire>
deployments -
Proposed Resolution.
Folks,
Where angels fear to tread...
http://www.osoa.org/jira/browse/ASSEMBLY-41
Note, that as agreed on the Assembly TC call of 5th August, the scope of
this issue is extended to encompass the updating
of Domain-level property values (where those values are being used to set
property values belonging to Domain-level
components)
Recap:
A ComponentReference can be wired in one of 3 ways:
1. Through the value of its @target attribute
2. Through one or more separate <wire/>
elements
3. Through the autowire mechanism if @autowire=true
is specified
Rule 1: The use of the autowire mechanism is mutually exclusive with the
use of the @target attribute and the presence of one or
more <wire/> elements for the same reference. In other words,
where
@autowire=true is declared for a reference and there are
one or more wires specified by means of the @target attribute or by means
of <wire/> elements, then the autowire mechanism
is not used and the specified wires apply.
References have a multiplicity, which is one of 0..1, 1..1, 0..n, 1..n
The concerns of this issue are mainly to do with the maximum number of
wires allowed for a reference and so the principal
distinction is between the (0..1 and 1..1) cases and the (0..n and 1..n)
cases,
There are 3 deployment operations to consider that affect Domain level
references and their wires:
1) Replacement of an existing entity with a new version
2) Addition of a new entity
3) Removal of an existing entity
The proposal here is going to specify a set of static rules relating to
the
wiring of references that apply to the configuration of
the Domain - "static" in that the rules apply whatever the deployment
history of the domain - in other words, examine the current
configuration of the domain and apply the rules is all that is necessary.
The proposal is then also going to address the dynamic aspect of the domain
configuration and describe what the SCA runtime
MAY do when the configuration changes in specific ways. (Note the
MAY -
the behaviour will be optional...)
A ComponentProperty value is set in one of 2 ways:
1. Through a value declared in the configuration
of the component
property
2. From the value of Property element in the
enclosing composite,
using the @source attribute
These mechanisms are exclusive - they cannot be used together.
For a component at the Domain level, the property value can be obtained
from a Domain-level property contributed by a
different contribution, using the @source attribute. In this case,
it is
possible for the domain-level property to be changed
through deployment actions. In this case, the property value for
the
component also changes.
Proposal:
<in what follows, it is assumed that all wires are valid in the sense
that
the source and target match in the required fashion - if
they do not match then an error must be raised>
a) Where a component reference has @autowire=true applied to it (as defined
in the autowire section of the specification), the
autowire mechanism MUST NOT be used where that same reference has one or
more static wires configured, either using the
@target attribute or using <wire/> elements.
b) <wire/> elements are extended to include a new attribute @replace,
which
has the values "false" and "true", with a default value
of "false". When a wire element with @replace=false specifies
a particular
component reference as a source, the wire is added to
the set of wires which apply to that reference. When a wire element
with
@replace=true specifies a particular component.
reference as a source, the wire is added to the set of wires which apply
to
that reference but any wires for that reference specified
by means of a @target attribute on the reference are removed from the set
of wires.
In other words if any wire element is used for a particular component
reference which has @replace=true specified, then the
value of any @target attribute for that reference is ignored. This
permits
the existing wires specified on the reference to be overridden
by separate configuration, if required.
c) The multiplicity of a reference MUST be honoured. For a reference
with
0..1 or 1..1 multiplicity, 2 or more wires MUST NOT be
configured for that reference and the SCA runtime must raise an error if
such a configuration is detected. For a reference with 1..1 or
1..n multiplicity, 1 or more wires MUST be configured and the SCA runtime
must not start a component and must raise a warning if
such a configuration is detected.
d) Dynamic behaviour of the SCA runtime when the wires for a component
reference change (this can only apply to component
references as the Domain level):
The configuration of the wires for a component reference can change by
means of deployment actions:
1. Wire elements may be added, removed or replaced
by deployment
actions
2. Components may be updated by deployment actions
(ie this may
change the component reference configuration)
3. Components that are the targets of reference
wires may be updated
or removed
4. Components may be added that are potential
targets for references
which are marked with @autowire=true
1. Where wire elements are added, removed or replaced by deployment
actions, the components whose references are
affected by those deployment actions MAY have their references updated
by
the SCA runtime dynamically without the
need to stop and start those components.
2. Where components are updated by deployment actions (their configuration
is changed in some way, which may include
changing the wires of component references), the new configuration MUST
apply to all new instances of those components
once the update is complete. An SCA runtime MAY choose to maintain
existing instances of those components with the
old configuration, but an SCA runtime MAY choose to stop and discard
existing instances of those components.
3. Where a component that is the target of a wire is removed, without the
wire being changed, then future invocations of the
reference that use that wire SHOULD fail with a ServiceUnavailable fault.
If the wire is the result of the autowire process, the SCA runtime MUST:.
- either cause future invocation of the target component's services to
fail
with a ServiceUnavailable fault
- or alternatively, if an alternative target component is available that
satisfies the autowire process, update the references
of source component
4. Where a component that is the target of a wire is updated, future
invocations of that reference SHOULD use the updated
component. An SCA runtime MAY maintain a copy of a component offering
a
conversational service until all existing
conversations complete - alternatively all existing conversations may be
terminated.
5. Where a component is added to the domain that is a potential target
for
a domain level component reference where that
reference is marked as @autowire=true, the SCA runtime MUST:
- either update the references for the source component once the new
component is running.
- or alternatively, defer the updating of the references of the source
component until the source component is stopped and restarted.
e) For a domain level component with a Property whose value is obtained
from a Domain-level Property through the use of
the @source attribute, if the domain level property is updated by means
of
deployment actions, the SCA runtime MUST
- either update the property value of the domain level component. once
the
update of the domain property is complete
- or alternative defer the updating of the component property value until
the compoennt is stopped and restarted
I'll build an updated Assembly spec if we're agreed on the details here...
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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
