[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 157: alternate proposal
After the discussion last week on issue 157 and the proposal to make it optional, Dave, Ashok and I had a call about issue 157. Few of my thoughts on the issue and an alternate proposal: 1) The proposal to make it optional dilutes the utility of constraining type. Especially, if runtimes that don't support it are allowed to silently ignore it. 2) There are two aspects of constraining type: a) A constraining type can be specified on a component type (either in a component type side file or on the composite, which results in the constraining type being part of the introspected component type of the composite. b) A constraining type can be specified on the component. This ensures that at runtime/deployment an appropriate type check is made. As MikeE pointed out, (b) can be achieved by using recursive composition. This would be similar to how BPEL C&I got rid of component type side files, since recursive composition does the same job. (a) above allows one to look for components (implementation.composite or components that belong to some specific technology) with a particular shape and provides some typing support in the system. While I think such a typing support does have a useful purpose, this is more of a design time issue then a runtime issue. If we were to remove constraining type from the spec, it will reduce complexity of the spec, can still be introduced in a subsequent version of the spec (perhaps with more experience on the design-time aspects of SCA), and would allow a runtime to introduce such a feature through proprietary design time/tool extension as a value-add. So I'll propose that instead of making it optional, we remove the concept all together. This would require that we remove the appropriate section and all mention of it in various sections through out the assembly spec (and other specs) as well as the pseudo-schema and schema (in appendix and in the stand-alone schema). Note that this would be a non-backward compatible/breaking change. I see this as a better way to resolve issue 157 than making it optional. Comments? -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]