OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


Where angels fear to tread...


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


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.


<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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]