ISSUE 41: Conflicting domain-level <wire> deployments - Proposed Resolution.

[Mike Edwards <mike_edwards@uk.ibm.com>]

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:  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