Subject: Re: [sca-assembly] ISSUE 41: Conflicting domain-level <wire> deployments -Proposed Resolution.
Mike, Two questions. i) What is the identity of a wire element so that the runtime knows whether or not you're replacing it? ii) Suppose there is a component A in the domain with reference A.R (0..n), configured with @target="B". I'm not sure it matters, but suppose this component came from composite X. Further suppose there is a deployment of composite Z which contains <wire/> elements connecting A.R to "C" and "D". Finally, suppose Z is redeployed containing only one wire element (with replace=true), connecting A.R to "E". What happens to the wires connecting A.R to "C" and "D"? Dave Booz STSM, BPM and SCA Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:email@example.com Mike Edwards <mike_edwards@uk. ibm.com> To "OASIS Assembly" 08/15/2008 10:57 <firstname.lastname@example.org> AM cc Subject Re: [sca-assembly] ISSUE 41: Conflicting domain-level <wire> deployments - Proposed Resolution. Brian, The scenario you give would cause an error. @replace=true does NOT replace any existing <wire/> elements using a given component reference as a source. If adding the new wire then violates the multiplicity of the component reference, it's an error. If you want to replace an existing <wire/>, go redeploy the <wire/>. (ie remove the old one and replace it with the new one) 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: email@example.com From: Bryan Aupperle <firstname.lastname@example.org> To: "OASIS Assembly" <email@example.com> Date: 15/08/2008 15:12 Subjec Re: [sca-assembly] ISSUE 41: Conflicting domain-level <wire> t: 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: firstname.lastname@example.org Mike Edwards <email@example.com> To 08/15/2008 08:49 AM "OASIS Assembly" <firstname.lastname@example.org> 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: email@example.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 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