[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Re: [ASSEMBLY-88] Proposal discussion
At the risk of rehashing the same discussions from OSOA, allow me to disagree. The reason I opened this issue was because I noticed that <component> is not required to have an implementation element. I.e., it can be implementation independent. The whole reason for creating constrainingType was because componentType (unfortunately choice of name) is specific to an implementation and *cannot* be shared across implementations. This lead to creation of three elements: component, constrainingType and componentType, that look very very similar syntactically, but serve very different purposes. I'm looking to see if we can simplify this *without* removing the functionality that is currently provided. Sharing is critical here. It is the usual type-instance difference. You want the constrainingType (or something similar) to be created once and used by multiple implementations. If you cared about the shape and not about a specific implementation technology then this allows you to choose implementations based on the shape and have the SCA runtime validate/enforce the shape for you. BTW, one thing missing in your proposal is the ability to specific the constrainingType on a componentType side file (and by extension in an annotation), which is currently allowed (although the constrainingType section does not specify this). The solution that I had in mind was to make sca:component a GED and allow that to be reused as a constraining type when it does not contain the <implementation> element. This would not remove the constrainingType attribute, but allow us to remove the constrainingType GED. Comments? -Anish -- Mike Edwards wrote: > > Folks, > > I was somewhat surprised by some of the reaction to the proposal made > below to resolve issue 88 in the TC call yesterday. > > I take the view that the proposal gives the functionality required by a > designer at minimal cost and > is in fact considerably simpler than the current design involving a > separate data structure in a separate file. > > My view is that the functionality that is required here is that the > assembler - the creator of composites in a top-down scenario - > can restrict what a developer ("implementation creator") is able to do, > so that a particular composition "does what it says on > the tin" - and no more. > > It seems to me that the simple marking I propose does exactly this - and > with minimal effort. > > A point was made that by having a separate file contain the data > structure used for constraining, that this could be reused, seems > far from the reality of the development experience for the assembler and > is not a feature that is likely to get much use. Frankly, > it is much easier to copy the configuration of a component from one > place to another, if that is required, than it is to point each > component to a shared file. And I note that in the case where a shared > file is used, it is STILL necessary to lay out the contents > of the component structure in order to perform the actual configuration > of that component - so there is still real duplication that > just gets in the way of the assembler. > > So I argue that a separate "constrainingType" file is actually an > unnecessary overhead of little benefit. The proposal below > gives the assembler all the real control that is necessary - and at > minimum cost. > > > If true sharing IS required, then it is more obvious to use the > <include/> capability and reuse the complete definition of a > component which is structured for reuse (eg - all services declared, > references declared but left unwired). This is more > meaningful than sharing some constrainingType file. > > > 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: Mike Edwards/UK/IBM@IBMGB > To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org> > Date: 18/11/2008 15:10 > Subject: [sca-assembly] [ASSEMBLY-88] Possible duplicate functionality > offered by constrainingType and component - proposed resolution > > > ------------------------------------------------------------------------ > > > > > This is a proposal to resolve Issue 88. > > Summary: > - remove constrainingType from the specification > - add an attribute to <component/> called @constrained which is a > boolean value with a default of "false" > > - a <component/> with constrained=false is just like a component today - > no changes > - a <component/> with constrained=true requires its implementation to > follow rules similar to those for > constrainingType - namely: > > "When the component using an implementation has @constrained=true the > implementation's component type > MUST contain all the services, references and properties explicitly > declared by the component. The component’s > references and services can have interfaces specified and can have > intents specified - the implementation's > service interfaces must be the same or a superset and its reference > interfaces must the the same or a subset, while > any intents present in the componentType must match those declared by > the component.. An implementation MAY > contain additional services, additional optional references > (multiplicity 0..1 or 0..n) and additional optional properties > beyond those declared by the component, but MUST NOT contain additional > non-optional references > (multiplicity 1..1 or 1..n) or additional non-optional properties (a > property with mustSupply=true). (and any such references > will not be wired and any such properties will not be configured by the > component). Any services in the componentType > which are not also declared by the component cannot be wired or promoted" > > I believe that this allows a component to control what its > implementations MUST look like, which is the idea behind > constrainingType. > > Detailed changes: > > > > 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]