[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] NEW ISSUE: multiplicity is too complex
On Aug 20, 2009, at 12:46 AM, Patil, Sanjay wrote: 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]