Issue 157: alternate proposal

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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
--