I am often asked (i.e. once every other year) by my coworkers, “What is Spring”? I usually launch into a long-winded diatribe of what it is followed by how it’s used and what it allows you to do. Most people get it, but I have decided it’s time to solidify that base definition of Spring so that it can be taken, alone, as a concise yet accurate definition of Spring. The people who ask me this are often bright Java guys, just unaware of the base concepts of Spring, IOC etc… so the definition can’t contain any of those buzzwords typically associated with Spring (kind of like explaining what “the” means without using the word “the”). My first attempt looked something like this:
Spring is a framework for transparently forming relationships between objects.
Ok, that statement is accurate but hardly embodies the full power of the framework. The word “transparent” is key and should be kept. We should also convey it’s lightweight nature and maybe the fact that it allows for the interception of it’s wired components using aspects? (but let’s not use the word “aspect”):
Spring is a lightweight framework that allows for the transparent management, wiring and interception of application components.
Ok, that’s a pretty tight definition of the base Spring functionality. Remember, I’m not trying to tell somebody everything Spring can do in one sentence, I’m just trying to convey the major functionality and potential of the framework. I’d like to add something in there about Spring’s ability to both replace or work with J2EE technology as Spring’s documentation goes to great length to stress both:
Spring is a lightweight framework, working in concert with or replacing J2EE, that allows for the transparent management, wiring and interception of application components.
But it also works in concert with many other standard Java frameworks and specs such as Hibernate, JDBC etc…, not just “J2EE”:
Spring is a lightweight framework that allows for the complete abstraction and encapsulation of implementation-specific technologies, like EJB, JDBC, Hibernate and others, by providing the ability to transparently manage, wire and intercept application components.
I feel like that’s a pretty good stab at it. My only fear is that I’m so engrossed in the making of the definition that it makes perfect sense to me while making absolutely no sense to any other reasonable person. That’s where you come in.. thoughts?
Onething friends keep ask me “Why Spring is lightweight container vis a vis other containers say weblogic?” So, I would like to add to list of above definitions. Traditional J2EE containers must provide Servlet Container, EJB Container, JMS container, JTA, etc by spec to qualify JEE container. So when you run a traditional app server, its heavy weight with redundat containers running. Say if you just want a servlet container, appserver still load other containers. You may choose not to use them, but they still are loaded and thats why its called heavyweight container. On other hand, Spring just provides Templates or similiar wrapped objects for all these services and its up to you to choose which of these services you actually want. One more reason its called lieghtweight container is when you have to unit test your components, you dont need any real service provider. Say if u want to JMS part of your application architecure, you can use mock JMSTemplate objects (connection, queue, reader and writer) and test them in isolation, without a JMS provider. Where as if you are writing an application in any other container, you can’t unit test without the actual container running. So, even though your application needs all services(web, messaging, transactions, ..etc) in production environment, you dont need any of them to run your tests. I’m no Guru on Spring, you are free to correct me if my comments doesn’t make sense. Thanks