Re: [sca-assembly] NEW ISSUE: multiplicity is too complex

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

David Booz wrote:
> TARGET: SCA Assembly spec CD03 rev2 [1]
> 
> DESCRIPTION:
> The concept of reference multiplicity is too complex. It's hard to 
> measure complexity as the degree of complexity is often directly 
> proportional to the level of past experience, which is going to be 
> different fro each person. In my experience, it is useful to measure 
> complexity by counting the number of concepts that must be mastered 
> inorder to to understand the thing or concept being studied. 

I would add that consistency and providing the element of least surprise 
does reduce confusion, which in turn contributes to complexity (wrt 
understanding of the concepts by the developer/assembler/deployer).

> Therefore, 
> the fewer concepts we have, the easier this will be to understand, and 
> therefore the more useful it will be for developers and assemblers.
> 
> The concepts that need to be understood in the space of multiplicity 
> are: reference, reference targets, multiplicity itself, promotion, 
> componentType, wiredByImpl, autoWire, bindings, binding URI targets, 
> wire targets, wire deployment (i.e. @replace on <wire/>). Did I miss any?
> 

Yes, nonOverridable.

> The following is the state of the current assembly spec (with the 
> resolution of ASSEMBLY-136):
> 
> 1) Composite references MUST specify @multiplicity, there is no default. 
> This is a consummability concern.
> 2) The @nonOverrideable attribute has the worst name of all time. This 
> is a consummability concern.

Bryan had a suggestion regd this (promoteAddsTargets, I think).
Another suggestion would be to just remove the 'non' from the name and 
flip the default value to 'true'.

> 3) wiredByImpl is effectively multiplicity 0..0, but it has a different 
> name and is therefore a different concept. Why?

I remember that there was a discussion regarding this and that there was 
a particular reason for picking a different attribute, but I cannot 
remember what it was.
Interestingly, not making it 0..0 adds to complexity for more than one 
reason:
1) 2 attributes that essentially address the same concept (multiplicity).
2) when references are promoted, wiredByImpl gets set depending on 
whether there is a component target and multiplicty is 0..1 or 1..1 and 
nonOverridable='true'. So there are complex interactions between these 
attributes.

> 4) It's possible to configure a reference with multiplicity 1..1 and yet 
> not specify any targets, but requires the reference to be promoted. So 
> the '1..' part of 1..1 doesn't mean 1, it means sometimes 1. Unless 
> you're using autowire in which case 1 does mean 1 again.

autowire is a syntactic convenience for a composite that is not 
deployable and scary at the deployable composite level. I won't be too 
sad to see it gone.

> 5) In the context of multiplicity, there are three ways to specify 
> reference targets (a) component/reference/@target, (b) 
> composite/reference/@target and (c) binding/@uri. Three ways is always 
> more complicated than one way.

There is one more: bindings can have binding specific way. Eg: EPR, WSDL 
port/service.

> 6) multiplicity itself is composed of two concepts; the minimum and 
> maximum number of reference targets that can be specified.
> 7) With @autowire, a 0..1 reference might get a target from autowire 
> processing or from the component above in promotion.

Won't that depend on nonOverridable?

> 8) ...others should feel free to append their favorite contradiction 
> here as well and we can collect them into this issue.
> 

Not a contradiction, but I think we have provided too many switches for 
fine tuning here.
We have references that are optional, required or not-allowed 
(wiredByImpl). Then we have references that are arrays or not.
Why not just stop there? The complexity is introduced by additional 
features that we have introduced:
1) Ability to promote and allow some targets to be specified at a 
lower-level other at a higher-level. Why not just require the assembler 
to make up their mind? Either you wire it or promote it but not both.
2) Default targets are nice, but not at the cost of complexity (this 
would also get rid of nonOverrideable)
3) autowire is just syntactic sugar, just specify the targets you want.
4) Convert wiredByImpl to 0..0

If we remove these capabilities the spec gets simplified quite a bit and 
a lot of complex rules just go away.

Having said that, I do realize that features that I think add complexity 
and can be removed, are important features to others and worth the 
complexity. Oh, the world of design by committee!

> I am as aware as anyone of how we got here and have been part of 
> creating this mess along with the rest of you (you know who you are). 
> Now's the time to clean this up.
> 

+1

> PROPOSAL:
> None at this time.
> 
> 
> [1] 
> http://www.oasis-open.org/committees/download.php/33563/sca-assembly-1.1-spec-cd03-Rev2.pdf
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
>