ISSUE 178: multiplicity is too complex

[Scott Vorthmann <scottv@tibco.com>]

logged as:

http://www.osoa.org/jira/browse/ASSEMBLY-178


On Aug 26, 2009, at 3:58 PM, Jim Marino wrote:

> Hi Sanjay,
>
> More comments inline...
>
> Jim
>
> On Aug 20, 2009, at 6:45 PM, Patil, Sanjay wrote:
>
>> Jim,
>>
>> I also had a feeling that you would respond to my nudge :-)
>>
>> Perhaps our views of the utility of the autowire feature (and  
>> perhaps even of SCA) are quite different. I think of SCA primarily  
>> as a technology for composing solutions from coarse grained  
>> components (built on heterogeneous platforms like Java EE, BPEL,  
>> etc, in most cases). In this scenario (which is more geared towards  
>> integration), wiring is a critical aspect of the design and any  
>> errors in wiring will lead to disastrous results. This is not to  
>> say that errors in wiring would be tolerated in any other cases but  
>> the point is - in the use cases I am envisioning the risk of  
>> erroneous wiring that is accompanied with the convenience of  
>> autowiring is very high and it would be quite acceptable and even  
>> natural to do the wiring by hand. Even if autowiring is used, there  
>> will be a need to recheck the correctness of all the wires which  
>> defeats the purpose of autowiring to certain degree, IMHO. I do not  
>> think that the syntactic shortcut and the saving of some keystrokes  
>> in the SCDL is that big a deal.
>>
>
> I suspect we do have different views on the utility of SCA, which  
> may just indicate that it can serve a variety of interests. I also  
> view SCA as an "integration technology" in that it promotes software  
> reuse and distributed systems. I think where we are different is  
> that I believe SCA is more effective and simple when it is used as a  
> programming model rather than as another abstraction on an existing  
> technology such as EJB (or Spring).
>
> I'm a little surprised by your dislike of autowire given that SCA is  
> full of other similar features. For example, intents and binding.sca  
> require the runtime to make very similar choices about the wiring of  
> an application. In of those cases, the physical manifestation of a  
> wire is not configured by the developer and/or assembler. Instead,  
> the runtime derives a physical wire by running a set of algorithms.  
> Similar to autowire, if a runtime matches an incorrect policy or  
> remote transport technology, it can have serious consequences for an  
> application.
>
>>
>
> In terms of your specific comments on wiring, I think it is a  
> critical aspect of all applications, not just some. I've been  
> involved in a number of fairly complex applications built using SCA  
> (some in financial services) and have never had an issue with  
> autowire. In fact, we have built the entire Fabric3 runtime  
> consisting of more than a thousand SCA services using autowire and  
> have never encountered an erroneous wire that was the result of  
> autowire. I suspect Fabric3's wiring requirements are much more  
> complex than those of a typical application (it relies on advanced  
> features such as reinjection to effect bootstrap, etc.).
>
> Also, I'm not sure how autowire requires someone to perform more  
> checks than explicit name-based wiring. In either case, an  
> application should have integration tests which will implicitly  
> validate wiring when they are run regardless of how the wires were  
> established. If an application has good test coverage, there should  
> be no need to manually "check" the wires. This is the same thing  
> that would need to be done to verify policy and binding.sca.
>
> What autowire does do is save a tremendous amount of time when it  
> comes to refactoring. This is more than just reducing typing. For  
> example, when developing Fabric3, we typically go through a series  
> of refactors where services are moved between composites and/or  
> renamed. Using autowire saves on having to manually adjust wires.  
> I'm sure someone will come up with a tool that does this  
> automatically for explicit wires, but having this capability "built- 
> in" is nice for people that prefer limited development tooling  
> environments.
>
>> Granted that autowire may be a common concept in the world of DI  
>> and I must confess that I haven't kept myself abreast of all the  
>> developments there, however I still think that the application of  
>> SCA is at a relatively higher level than the common DI frameworks.  
>> If for some reason SCA must support an autowire like feature in  
>> some C&I specs, then I think we should define and scope the  
>> autowire feature to the specific C&I specs and not elevate it at  
>> the assembly level.
>>
>
> In all of the SCA projects I have worked on and presentations I have  
> made, a common theme that has emerged is people think SCA is  
> powerful because it provides assembly of coarse-grained and fine- 
> grained services. That translates into simpler applications because  
> developers only need to learn one assembly technology and  
> configuration is consistent across the entire application. Sure,  
> there is integration of legacy systems built using technologies such  
> as EJB, but even in those scenarios, it is easier to build the  
> service integration layer using a combination of coarse- and fine- 
> grained artifacts.
>
> Basically, I think the distinction between coarse- and fine-grained  
> assembly is artificial. There is a difference between creating  
> coarse- and fine-grained services, but it is better to have one  
> common way of configuring them. While this results in simpler  
> applications today, I believe it is going to become imperative in  
> the future. For example, virtualization and cloud technologies will  
> require metadata to provision applications. Assembly (SCDL and  
> policies) provides a lot of what is required. Having multiple ways  
> of performing wiring and specifying assembly at different levels in  
> an application will only complicate this effort.
>
>> I think I understand you usage of the autowire feature for  
>> subscription-style services but I am not sure if autowire is a good  
>> long-term solution for this scenario. Perhaps you should bring up  
>> your use case for discussion under the Eventing related issue  
>> (which is deferred to post 1.1 release of SCA specs, BTW)
>>
>
> I'm glad to see eventing was delayed until post-1.1. I looked at it  
> for my use case but I don't think it fits as the use-case requires  
> dispatching to a typed service to perform an action. My  
> understanding of eventing is that it is a much more loosely coupled  
> paradigm that does not involve the notion of an invocation.
>
>> -- Sanjay
>>
>> From: Jim Marino [mailto:jim.marino@gmail.com]
>> Sent: Thursday, Aug 20, 2009 6:27 AM
>> To: Patil, Sanjay
>> Cc: David Booz; sca-assembly@lists.oasis-open.org
>> Subject: Re: [sca-assembly] NEW ISSUE: multiplicity is too complex
>>
>>
>> On Aug 20, 2009, at 12:46 AM, Patil, Sanjay wrote:
>>
>>>
>>> +1
>>>
>>> A good deal of complexity seems to have slowly crept into the  
>>> spec. Perhaps time to prune a few features that are rarely used  
>>> but still show up all over the place (autowire anybody?).
>>> -- Sanjay
>>>
>> Sanjay,
>>
>> We have been over this one several times and had a feeling you  
>> would bring this up. Can you explain how autowire is complex?
>>
>> Two items that lead to complexity are a behavior developers don't  
>> expect or excessive configuration. I would like to point out that  
>> every modern Java dependency injection framework I am aware of  
>> supports autowire. Some - such as Guice and PicoContainer - are  
>> based on it. Others that support autowire include:
>>
>> - EJB 3
>> - Web Beans
>> - Spring
>>
>> Based on this, I think it is fair to say autowire is fairly well- 
>> established in the developer lexicon and therefore doesn't  
>> contribute to increased complexity based on it being an additional  
>> concept people must master.
>>
>> On the contrary, autowire actually reduces complexity as it  
>> eliminates the need to write reams of configuration. In fact, many  
>> people are now switching over to using annotation-based autowire in  
>> Spring applications. For example, this was just posted on the  
>> ServerSide yesterday: http://www.theserverside.com/news/thread.tss?thread_id=56989#319078 
>> . On this note, I would argue SCA's concept of autowire is even  
>> simpler than Springs, since it does not require a specialized  
>> annotation.
>>
>> Autowire has proven to be a huge time-saver and essential  
>> capability on the SCA projects I have been involved with. It's a  
>> time-saver because we don't need to manually code target URIs and  
>> because it is easier to refactor. If we change a component name,  
>> wiring does not break. It's also an essential feature because we  
>> are using it for subscription-style services. This use case comes  
>> up very often in service-based systems. One approach is to use a  
>> "white-board" pattern similar to OSGi. Instead, we use autowire  
>> with a registry that dispatches to multiple services:
>>
>>
>> registry ---------- 0..n --------> service
>>
>> In SCA we model this as a multiplicity autowire. Services are added  
>> to the registry which contains a collection-based reference. As  
>> autowire is enabled, the services do not need to have knowledge of  
>> the registry. In addition, autowire provides dynamic capabilities.  
>> Since our runtime supports reinjection, when a new service comes  
>> online, it reinjects the multiplicity reference, thereby updating  
>> the registry.
>>
>> If autowire were removed, it would require us to provide additional  
>> wire elements. When the number of services increases, this gets  
>> cumbersome and error-prone. Moreover, if there are several  
>> registries involved, it adds to the complexity.
>>
>> Autowire is a feature people commonly use. If we were to remove it,  
>> I'm afraid we would be going in the opposite direction of most DI  
>> frameworks which rely heavily on it for simplicity.
>>
>> Jim
>>
>>
>>
>>> From: David Booz [mailto:booz@us.ibm.com]
>>> Sent: Tuesday, Aug 18, 2009 12:19 PM
>>> To: sca-assembly@lists.oasis-open.org
>>> Subject: [sca-assembly] NEW ISSUE: multiplicity is too complex
>>>
>>> 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. 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?
>>>
>>> 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.
>>> 3) wiredByImpl is effectively multiplicity 0..0, but it has a  
>>> different name and is therefore a different concept. Why?
>>> 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.
>>> 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.
>>> 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.
>>> 8) ...others should feel free to append their favorite  
>>> contradiction here as well and we can collect them into this issue.
>>>
>>> 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.
>>>
>>> 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
>>>
>>
>