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: 

Mike Edwards <>

08/15/2008 08:49 AM

To

"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