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