[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid attributefor a Composite Reference
Mike Edwards wrote: > > Folks, > > I think the argument between multiplicity="0..0" and wiredByImpl="true" > is one that we can > debate. I don't think it is the most important part of the problem. > > The real debate this has stirred up is what it means to promote a > wiredByImpl reference: > a) if it's allowed, what does it mean? > b) if it's not allowed, then the spec needs to say so > > Let's assume that it is allowed. So I can validly promote a component > reference which is > marked as "wiredByImpl". > > One thing I note is that "wiredByImpl" is like an intent. It cannot be > removed no matter how > many times I promote the reference, (Perhaps it should be modelled as > an intent???) > > OK, so the promoting composite reference MUST also be "wiredByImpl". (We > will definitely > need to add this restriction into the spec). > > Now, if the component reference has some configuration (policies, I > think it is limited to > policies - I can't specify a binding since a reference binding MUST > contain an endpoint > definition - and by definition you can't specify an endpoint target for > a wiredByImpl > reference), what happens?? > > I assume that the composite reference may add intents - and so may the > configuration of > that composite reference by the component at the next higher level. The > added intents > must not be mutually exclusive with intents on the component reference. > As for PolicySets > I assume that any policy sets expressed on the composite reference (or > expressed in a > higher level component configuring that reference) replace those on the > promoted > component reference. Ah, except that I can't define the Binding that > the reference is going > to use. And since PolicySets imply a Binding (usually) then I think we > may be limited to > intents.... > Not sure I follow. I agree that one can't specify bindings for wiredByImpl. But, if I want to ensure that a particular binding feature is used for such a reference, I'll include an appropriate intent. If I would like to add a binding feature but want to allow overrides I can include an interaction policy. I may also have implementation policies that have nothing to do with bindings. Perhaps I have missed something in the spec that disallows policy sets on references that do not contain a binding. -Anish -- > So this then is the meaning of promoting a wiredByImpl reference - you > get the chance to > spell out the policies you want to apply to the reference. > > > Let me make a parting shot. One final possibility is that promotion of > wiredByImpl component > references is disallowed. In that case, I get to set policies via the > external attachment mechanism. > So I can achieve the same result in a different way. > > I'm OK with either solution - I'm interested to hear everyone's opinions. > > > 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 > > > From: Anish Karmarkar <Anish.Karmarkar@oracle.com> > To: OASIS Assembly <sca-assembly@lists.oasis-open.org> > Date: 25/11/2008 23:12 > Subject: Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid > attribute for a Composite Reference > > > ------------------------------------------------------------------------ > > > > Mike, > > Apologies for misunderstanding your proposal on the call today. > Unfortunately, line numbers on a 2007 .doc file don't mean a whole lot > to me. > > IIUIC, what you are proposing is to get rid of the attribute wiredByImpl > on a composite reference, while retaining the ability to promote a > component reference that has wiredByImpl='true'. > > If this is correct, I think this is problematic. Without the > wiredByImpl='true', the componentType associated with the composite will > not contain information about the fact that the reference cannot be > wired. Higher-level composites won't know the cardinality associated > with the reference (which is 0..0) and therefore will be free to wire > it. Unless, the spec says that wiredByImpl='true' automatically becomes > part of the CT associated with the composite by the virtue of the fact > that the underlying component reference has wiredByImpl='true'. We allow > narrowing of constraints when promoting. A 0..0 cannot be narrowed any > further, so wireByImpl='true' is indeed ripe for defaulting in such cases. > > But as it stands I don't think there is any inconsistency in the spec > (other than the fact that it does not say that you cannot change the > value of wiredByImpl when promoting). > > Currently, wiredByImpl says: > "wiredByImpl : boolean (0..1) - a boolean value, "false" by default, > which indicates that the implementation wires this reference > dynamically. If set to "true" it indicates that the target of the > reference is set at runtime by the implementation code (eg by the code > obtaining an endpoint reference by some means and setting this as the > target of the reference through the use of programming interfaces > defined by the relevant Client and Implementation specification). If > "true" is set, then the reference should not be wired statically within > a composite, but left unwired." > > Which seems right to me. There is implementation code associated with a > composite reference: it is the code associated with the corresponding > promoted component reference (however levels deep). > > OTOH, the existence of wiredByImpl when we already have the multiplicity > attribute (on both component reference as well as composite reference) > always seemed a little strange to me. wiredByImpl is really saying > multiplicity of 0..0, why not then just say exactly that. I know this > was discussed during the OSOA days, but I don't recall why addition of a > new attribute was chosen over 0..0. > > I'll be bold and make a proposal to remove wiredByImpl altogether and > use 0..0 on the multiplicity attribute instead (with the usual narrowing > rules for promotion). > > I'm hoping that, if there was a good argument for choosing wiredByImpl > over 0..0 in OSOA, someone will bring it up here. > > Comments? > > -Anish > -- > > Mike Edwards wrote: > > > > Raiser: Mike Edwards > > > > Target: Assembly spec: sca-assembly-1.1-spec-cd01-rev3.doc > > > > Description: > > > > The current spec has the attribute @wiredByImpl as an attribute of a > > Composite reference element. > > This cannot be valid, since there @wiredByImpl=true implies that the > > composite itself will act to wire > > the reference at runtime. However, this can never happen since there is > > no active code in the > > composite which could do this. > > > > It is valid for a reference on a component within the composite to have > > @wiredByImpl on one of its > > references, but this applies to wiring of the component reference - and > > NOT to wiring of any > > promotion of that reference. > > > > Proposal: > > > > Remove @wiredByImpl from <reference/> within a <composite/>. > > > > Specifically: > > > > Line 1337 - remove wiredByImpl="xs:boolean"? > > > > Lines 1399 - 1405 - remove > > > > Lines 3825 - 3826 - remove > > > > Lines 3971 - 4006 - replace with: > > > > <complexType name="ComponentReference"> > > > > <complexContent> > > > > <sequence> > > > > <element ref="sca:interface" > > minOccurs="0" maxOccurs="1" /> > > > > <element name="operation" > > type="sca:Operation" minOccurs="0" > > > > maxOccurs="unbounded" /> > > > > <element ref="sca:binding" /> > > > > <element ref="sca:callback" > > minOccurs="0" maxOccurs="1" /> > > > > <any namespace="##other" > > processContents="lax" minOccurs="0" > > > > maxOccurs="unbounded" /> > > > > </sequence> > > > > <attribute name="name" type="NCName" > > use="required" /> > > > > <attribute name="autowire" type="boolean" > > use="optional" /> > > > > <attribute name="wiredByImpl" type="boolean" > > use="optional" > > > > default="false"/> > > > > <attribute name="target" > > type="sca:listOfAnyURIs" use="optional"/> > > > > <attribute name="multiplicity" > > type="sca:Multiplicity" > > > > use="optional" default="1..1" /> > > > > <attribute name="requires" > > type="sca:listOfQNames" use="optional"/> > > > > <attribute name="policySets" > > type="sca:listOfQNames" > > > > use="optional"/> > > > > <anyAttribute namespace="##other" > > processContents="lax" /> > > > > </complexContent> > > > > </complexType> > > > > > > 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/ > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > ------------------------------------------------------------------------ > > / > / > > /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]