Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
The Rich Engineering Heritage Behind Dependency Injection
URL: The Rich Engineering Heritage Behind Dependency Injection
At 9:47 AM on Dec 28, 2007, Matthew Schmidt wrote:
Fresh Jobs for Developers Post a job opportunity
Read the full article.
9 replies so far (
Post your own)
Re: The Rich Engineering Heritage Behind Dependency Injection
Nice article. I'm not sure if you have come across them, but there have been a number of early programming models that use DI extensively. ATG's Dynamo application server had Nucleus which did DI using properties files circa 1997 (back before XML was prevalent in the Java community). I think some of the CORBA POM can even be interpreted as an early form of DI.I liked your discussion of composition and view that as a key next step in software systems design. It would be interesting to see what you think of Service Component Architecture (SCA, www.osoa.org), particularly the Assembly specification which is based on a composition model. I've been fairly heavily involved in those as well as an open source implementation, Fabric3 (http://fabric3.codehaus.org/).
Re: The Rich Engineering Heritage Behind Dependency Injection
Thanks for the comments. Sorry for the late-ish reply -- i've had all manner of relatives visiting over the Christmas period!> Nice article. I'm not sure if you have come across
> them, but there have been a number of early
> programming models that use DI extensively. ATG's
> Dynamo application server had Nucleus which did DI
> using properties files circa 1997 (back before XML
> was prevalent in the Java community).
I've not used Dynamo, but I've heard of it. What's the component model like in it? Does it feature composites? I'm interested to know also if they do anything dynamic with it. i.e. reloading the components at runtime.
> I think some of
> the CORBA POM can even be interpreted as an early
> form of DI.
I'm not familiar with this. Do you have a link I could look at? I used to do a lot of CORBA -- is it related to the POA, or POS specs? CCM?
> I liked your discussion of composition and view that
> as a key next step in software systems design. It
I feel the same way about composition -- it's a much more powerful and predictable way to assemble applications. My phd work started with composites, but as I designed I realised they cause abstractions to be deeply buried. e.g. I'd want to reuse a complex composite, but I wanted to change a child component very deep down in the nesting for the new situation. My current phd work is allowing this type of reuse.
Some info on this work is at http://www.cs.ucf.edu/~leavens/SAVCBS/2006/papers/McVeigh-Kramer-Magee.pdf and http://wwwhomes.doc.ic.ac.uk/~amcveigh/papers/savcbs-2007/SAVCBS-2007.pdf
> would be interesting to see what you think of Service
> Component Architecture (SCA, www.osoa.org),
> particularly the Assembly specification which is
> based on a composition model. I've been fairly
> heavily involved in those as well as an open source
> implementation, Fabric3
> (http://fabric3.codehaus.org/).
thanks for the link. i've had a quick look, i'll look at it in depth early in the new year.
a couple of things jumped out at me from the SCA assembly model page: http://www.osoa.org/display/Main/The+Assembly+Model
1. you have full composites with wires and delegates (promoted wires). very nice!
Can you have complex wires? i.e. wires that loop back onto the same "port" etc?
2. the promotion of properties onto the composite level
I came to the same conclusion in my component model: that composite parents must be able to map their state onto the state of the children. It's a very powerful way of selectively exposing and grouping the state of the children without breaking encapsulation. I call this property aliasing.
3. the children seem to be component types rather than component instances
i.e. one of the children is ComponentA. Can you have more than one instance of ComponentA in CompositeA? Is this even needed in your model?
Do the components represent arbitrary service points in the SOA, or is this actually also a packaging and deployment model dealing with concrete components? Can it wire up the internals of an application (i.e. inside 1 VM) as well as handling distributed components?
Cheers (and happy new year!)
Andrew
Re: The Rich Engineering Heritage Behind Dependency Injection
> 3. the children seem to be component types rather> than component instances
I've read parts of the SCA assembly spec (http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications).
I see now that the children are component instances with names and optional multiplicities.
Cheers,
Andrew
Re: The Rich Engineering Heritage Behind Dependency Injection
"It's kind of a shame" that articles resulting from publicly funded research are not publicly available. The last time that I had free access to most academic publications was on university.Re: The Rich Engineering Heritage Behind Dependency Injection
Out of curiosity, have you ever looked at how electronic hardware is designed and specified? Or at how simulators (of analogue, digital, RF, general systems) require the system-under-test to be specified?The similarities are pretty much self-evident, even if some of the implementation techniques are different. But I'd be interested in a discussion of non-obvious differences, particularly around aspects that can/cannot be expressed.
Re: The Rich Engineering Heritage Behind Dependency Injection
yes, it's a bit of a scandal. i guess the research might be theoretically "available" to engineers, but the actual publications/papers describing the research are copyright controlled by the publishers.Andrew
Re: The Rich Engineering Heritage Behind Dependency Injection
> Out of curiosity, have you ever looked at how> electronic hardware is designed and specified? Or at
> how simulators (of analogue, digital, RF, general
> systems) require the system-under-test to be
> specified?
i did electronic engineering for my undergraduate degree so I have some exposure to both analog and digital techniques. however, it was a while ago and i've not revisited the area.
from memory the digital specs were in terms of signals and timings. the catalogs looked very much like a shopping guide for components. i can't remember much about analog techniques.
do you have any good pointers / links to share?
> The similarities are pretty much self-evident, even
> if some of the implementation techniques are
> different. But I'd be interested in a discussion of
> non-obvious differences, particularly around aspects
> that can/cannot be expressed.
i guess much of the s/w component literature aims to make s/w components behave a bit like ICs. Certainly this was Brad Cox's (inventor of Objective-C) take on it with his s/w IC metaphor. Most of the graphical languages for s/w components even look a bit like ICs.
i guess from a practical view, s/w components can be composed much more easily than ICs. Certainly in my electronics work, i plugged together ICs into a board, but the resulting physical structure was much bigger than the individual parts. As a non-physical domain, s/w components don't have this limitation, so composition can be done much more conveniently.
On the verification/testing/compliance side, i use sequence diagrams (with operators for loops, a la UML2) which I then translate into a process algebra (i.e. a variant of CSP) -- this is called this the component protocol. When a group of components are wired together, the set of protocols are "composed" which results in a simplified, single protocol for the network. This "hides" any internal connections which are not externally exposed on the composite's boundary.
If it sounds complicated, it's just my poor explanation. Essentially it all boils down to a way to form a protocol from a composite by composing together all of the protocols of the objects making up that composite.
The benefit is that concurrency properties can be checked (liveness, safety) and that any protocol violations are reported. I guess in this sense it was very similar to the way I checked my digital circuits using a simulator. I don't have access to my undergraduate work at the moment -- i think i used some sort of simulation language (maybe VHDL). Very similar approach, as you noted.
My current work is oriented towards being able to arbitrarily change components to get greater reuse. testing is a fairly interesting problem in this area.
Cheers,
Andrew
Re: The Rich Engineering Heritage Behind Dependency Injection
Ah hum.I decided to dive into spring and bought a book to understand the notion of IOC and dependancy injection.
I appreciate your high level description against ADL etc, being an ACMESTUDIO buff and also dabbling with TOPCASED and AADL.
But I am amused at a historical relic people seem to miss.
Borland Delphi and Borland JBuilder are component based application development tools that use IOC and DI at their heart and ... *cough* they have fallen off the map.
I still think Delphi and JBuilder are brilliant tools though I haven't fired either up for some time.
So, I am interest in peoples notions of software development history. Of note:
Smalltalk was panned because it was byte code interpreted and that was bad but Java compiles down to bytecode which is good.
No one unit tested before JUnit, except smalltalk coders who invented SUnit which JUnit is a shameless copy.
Functional languages are interesting academic things that would never catch on in real applications but if you wrap it up in xml tags and call it XSLT go for it.
So now IOC and DI are in vogue again, does that mean I can dust off my old borland Delphi discs?
When is someone going to develop a graphical component designer/assembler rival the delphi/jbuilder environment.
I do now remorse throwing away a book on component design and construction (in delphi but with principles general enough for any environment): now that IOC is fashionable again.
I smirk also where we are told that parallel computing is the next best thing after taking my occam coding cap off and moving away from realtime acoustic processing systems.
Everything old is new again. If only IOC and DI was in vogue when Delphi came out. If only people could make up their minds.
Re: The Rich Engineering Heritage Behind Dependency Injection
Who meet somewhere the development of applications for robots on java?hgh injection