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: Re: [sca-assembly] ISSUE 41: Conflicting domain-level <wire> 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: aupperle@us.ibm.com

Mike Edwards <mike_edwards@uk.ibm.com>

08/15/2008 08:49 AM

"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
[sca-assembly] 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]