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