BT

Dependency Injection: New Ground or Solid Footing?

by Michael Bushe on Jan 31, 2008 |
Spring and other dependency injection frameworks have really paid off for many developers in terms of reducing coupling, improving unit testing, and cleaning architectures.  As architects, it is helpful to understand the history of a technology in order to properly understand the situations where it is best applied, its limitations, and its future direction.  For example, knowing that EJBs came out of the CORBA world and that SOA is an evolution on Message-Oriented Middleware (MOM) systems helps architects understand the place of these technologies in the software world.  For many, however, DI seems to come out of nowhere.  

Andrew McVeigh has written a detailed history of dependency injection, summarized here.   McVeigh is an academic that is working on  architecture description languages (ADLs) as part of his  Ph.D.  He has also worked with Rod Johnson on a commercial product.  

While DI may not have directly sprung from ADL efforts, McVeigh says that ADLs and DI are similar methods to solve a common problem.  This is similiar to convergent evolution, whereby, for example, birds and bats have separately evolved similar structures, wings, that are well-suited to an important behavior, flying.  

McVeigh writes:
To academics familiar with the research behind software components over the last twenty years, it is clear that DI is very closely related to a well-established area of software research known as architecture description languages (ADLs).  The job of an ADL is to assemble or wire components together via configuration....In fact, the Spring bean configuration language is (technically speaking) a non-hierarchical ADL with implicit connectors.  
McVeigh provides this definition of a software component:
A component is a unit of software that can be instantiated, and is insulated from its environment by explicitly indicating which services (via interfaces) are provided and required.
McVeigh compares software components with electronic components since both should be "interchangeable, tangible units which are clear about which services they provide and which services they require."  As you wire up your receiver, speakers, DVD, and your new 96"  HDTV, the  shape of the input and output connectors explicitly inform you which services each component requires and provides, respectively.  

A Java or .Net class is not a component per se.  A class can describe what it provides by means of its interfaces, but it does not declare exactly what it depends on to run.  It is true that method types declare what a specific method requires, but nothing declares what is required by the class as a whole.   Spring and other DI containers fill this gap by allowing class annotations or external configuration files to explicitly declare what a class requires.  Configuration together with a Java class creates a software component that almost meets McVeigh's definition. Spring Bean's fall just short of McVeigh's definition of a component because for Spring the connectors are implicit - you can only set the bean property and Spring simply calls the setter.  

A major feature of ADL's is the fact that the connectors are explicit.  It's not just loose wire, but a cable with an HDMI connector on the end.  The explicit nature of the connectors provide ADLs with interesting architecutal features, including improved testability and improved architecural tooling.  In certain ADL's the connectors can be more functional.  They can act like components in their own right, by performing extra functions like filtering or error handling.

Another major differentiator between ADLs and current DI technology is the notion of a Composite Component.  Once you've wired all your electronics together, you have a Home Entertainment System.  Yet, it isn't like Frosty the Snowman.  There is no additional entity that magically appears once everything is put together just so.  Your Home Entertainment System is nothing but the components and the wires that connect them.  

Using McVeigh's ADL language called Backbone, you can create a new Composite Component by wiring up existing components.  You can't perform this trick with Spring today since every Spring bean must be associated with a class.  Despite it's power, Backbase is much easier to read than Spring XML configurations.

McVeigh narrates and interesting history of ADL.  The first ADL was Conic, written in Pascal and used in distributed computing in the 1980s.  Another ADL, Darwin, influenced COM.  The UML specification contains an ADL that was influenced by Rational Realtime and the ROOM methodology.  

Some of the future directions of dependency injection that McVeigh details include:
  • The ability to swap out components at runtime.
  • Evolving systems over time by capturing the change sets in ADL.
  • Fractal-like composition - being able to drill into a layered system and see composite components at every level.
  • GUIs - a natural fit for composite development
  • Architectural design and analysis tools.
Finally, McVeigh laments the disconnect between academic and industry in software development.  Academics aren't interested in the industry's trodden ground and academic work is inaccessible to industry, and may be considered not worthy of production.  Yet it's apparent both could gain by a closer relationship.

McVeighs shows us that not only is Dependency Injection here to stay, but it has a long history and an interesting future.
*Note: editted Feb 1st in response to reader comments

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

good summary by andrew mcveigh

It was a surprise to see my article quoted. I think you've done a really good summary, very accurate. Very nice pickup on convergent evolution, i hadn't thought of that before.

Just a few minor points. My component language is Backbone, rather than Backbase. Also, the UML was influenced by ROOM and Rational Realtime rather than the other way around.

In this first article, I wasn't able to describe the key Backbone features, as I felt I needed to cover the similarities between ADLs and DI. I'll write up Backbone per se in the second article. The key point of Backbone is that it allows wiring changes for component reuse. Explicit connectors are a bit of a must for this type of facility.

Rod (Johnson) also pointed out that the new namespace features in Spring2.5 should allow me to build the composite features directly into Spring. I plan to try this out, as it sounds quite interesting.

Cheers (and thanks),
Andrew McVeigh


Cheers,
Andrew McVeigh

Re: good summary by Jep Castelein

I guess there was some confusion with Backbase, The Ajax Company. It seems that all words starting with 'back' are prone to typos :-)

Over the years we've been confused with:

-'backspace'

-'backpack', the ajax-based project manager

-'jackbase', combination of Jackbe and Backbase

And more...

Jep



Re: good summary by Michael Bushe

Whoops! Yes, I do a lot of work with RIAs so I mentally slipped in Backbase for Backbone. My apologies.

I look forward to your future articles. Backbone is such a nice little language, I would like to see it integrate directly with Spring as an alternative to XML. Is this the type of integration you are planning?

Michael

Re: good summary by andrew mcveigh

Whoops! Yes, I do a lot of work with RIAs so I mentally slipped in Backbase for Backbone. My apologies.


No worries! Backbone isn't a great name at any rate. Since the language is so close in syntax to Darwin, the neat-o name for it would be Huxley (Darwin's bulldog) which is also the name of building of the comp sci department of Imperial... I just can't be bothered to change it ;-)

Following up on your notion of convergent evolution -- when I designed Backbone, I had never seen Darwin. Bizarrely, the syntax turned out to be very, very similar and many of the concepts are identical even though Darwin is perhaps 8 years older. The same needs lead to similar solutions, I guess. In retrospect I probably took my terminology from UML which was influenced by the ADLs.


I look forward to your future articles. Backbone is such a nice little language, I would like to see it integrate directly with Spring as an alternative to XML. Is this the type of integration you are planning?


I wasn't planning this (although it's an interesting idea and closely linked to the discussion on XML versus language grammars). Backbone is more of a proof of concept (and interestingly the runtime for my case modelling tool). I think that writing Backbone/Spring at the level of text isn't great -- I see the text form as an means to an end. What i meant is that i would use the Spring namespace features to add simple connectors to spring. I may also add a simple form of composites. I will be doing this as part of a case study for inclusion into my phd.

Instead of using text to create these types of configurations, I use a UML2 case tool I have spent the last 3 years on. It can model these architectures in a very pleasant and intuitive way. It's called jUMbLe and all the pictures in my article are from it. It has sophisticated features for the rewiring and checking abilities I allude to in my article, which allow reuse and evolution of a component system to be modelled (the core of my phd). The plan is to generate Spring output (as well as other ADLs) from the models (hence the need to add extra expressiveness to the Spring config). At the moment, I just generate Backbone which is not as "production capable" as Spring (also less feature rich in many other areas -- e.g. no aspects).

Interestingly, my phd started with the idea of using Backbone as the plugin architecture for my case tool. My goal (soon to be reached) is that jUMbLe is able to manipulate its own component architecture! The aim is to form a very extensible componentised case tool... The working title for my thesis is "An Architectural Approach for Extensible Applications" or something like that ;-)

Here's a picture of a dummy architecture i'm modeling as an example: www.doc.ic.ac.uk/~amcveigh/images/stereo-evolut...
This shows the evolution of a "Stereo" component -- I have replaced a component instance with the "EnhancedMixer" component instance. This is one type of rewiring where i have disconnected the old mixer and wired in a new one as a delta change.

Another feature worth quickly mentioning is that this example shows type inferencing on the ports of Stereo. The interface types have been inferred from the internal connections of the component.

Cheers,
Andrew

Article Fixed by Michael Bushe

The article has been updated to correct the project name to Backbase.

I look forward to seeing your project develop, it looks like a great tool, and especially cool if it can output Spring config.

Michael

Re: good summary by andrew mcveigh

the uni machine hosting the screenshot has died. here's an alternative link: www.hopstepjump.com/stereo-evolution.png

Cheers,
Andrew

Last point worth re-reading... by Jim Leonardo

"Finally, McVeigh laments the disconnect between academic and industry in software development."

Wow... I suspect McVeigh's got an industry background? true? One of the biggest problems I see in academic literature is the fact that all too much of it is utterly incomprehensible to someone who doesn't live in set notation (whereas most real world programming languages are described with something such as Backus Naur Form instead of often cryptic set notations). As a result, too much of the academic literature is nigh-unto useless to someone on the engineering/architecture side of things. This isn't universal, but its common enough that I wonder how much duplicate effort goes on, or worse, how many bright ideas get buried in phd-jargon and never used.

Re: Last point worth re-reading... by andrew mcveigh

"Finally, McVeigh laments the disconnect between academic and industry in software development."

Wow... I suspect McVeigh's got an industry background? true?


Yes, I've spent the last 18 yrs working on commercial s/w systems, although i also spent time as a speech researcher in my misspent youth (he laments on the day before his 40th birthday ;-)


One of the biggest problems I see in academic literature is the fact that all too much of it is utterly incomprehensible to someone who doesn't live in set notation (whereas most real world programming languages are described with something such as Backus Naur Form instead of often cryptic set notations). As a result, too much of the academic literature is nigh-unto useless to someone on the engineering/architecture side of things. This isn't universal, but its common enough that I wonder how much duplicate effort goes on, or worse, how many bright ideas get buried in phd-jargon and never used.


True about many of the computer science formalisms, although I think there has to be give and take on both sides which happens (albeit slowly). E.g. BNF (and lots of parsing theory) is based on Chomsky grammars, a good example of how something that is once considered to be of mainly academic interest has now been accepted as a standard s/w engineering technique.

My belief is that both academia and industry need to find a healthy middle ground. Too often getting a paper published in an academic journal is about putting sophisticated spin on fairly simple ideas so that it will get published (the reviewers are often incredibly mean). Academia needs to strive for simplicity of explanation. On the other side, too often industry accepts substandard s/w simply because the market doesn't expect better either ignoring of dismissing academic results that could be applied. It's really not good enough.

At the core of s/w engineering research is completely mind-blowing stuff, which unfortunately needs to be understood to be applied: things like turing machines and complexity modeling, the pi calculus (for mobile systems), CSP for modeling concurrency and checking for deadlock etc, model checking (got 2007's turing award) for checking systems. i think (hope) that as this type of stuff becomes more accepted by s/w engineers, they will eventually be as commonplace as BNF is now.

I remain optimistic: things like automata behind regular expressions are considered old hat now, but they are also the basis of much of the theory of computer science. I sincerely hope that in time, developers will be to computing as surgeons are to medicine -- i.e. the theory and practice meet up in the same group of people.

Cheers,
Andrew
p.s. I agree with you about much of the academic papers on computer languages, though. I really struggle with these. I think they tend to be a bit ridiculous...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT