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:

Through the value of its @target
attribute

Through one or more separate
<wire/> elements

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:

Through a value declared in
the configuration of the component property

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:

Wire elements may be added,
removed or replaced by deployment actions

Components may be updated by
deployment actions (ie this may change the component reference configuration)

Components that are the targets
of reference wires may be updated or removed

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