I was tracking some comments, and recently noticed a thread of discussion (in English) on a python mailing list. This is a follow-up to someone else posting about his discovery of Spring Python through the news announcement from SpringSource. (I appreciated that the person also caught on to my article defending the usage of AOP in python.)
They concluded their response by indicating:
Aunque para convencerme de usarlo todavía le falta compararse con otros frameworks de python.
(Run this through Google Translate if you need to.) Apparently, this person, while slightly impressed that I wasn’t coding in horrible java paradigms, didn’t see enough to use this instead of other python frameworks. I knew that he was comparing it to other python web frameworks.
I started thinking about the basis of all this, and realized a little bit of a history lesson is in order. Anybody who has ever heard of Spring, knows it by its full name, The Spring Framework. This should help illuminate why Spring is referred to as a framework, and why Spring Python is often thought of as a framework itself.
Starting around 1999, the first EJB spec came out. This was the technology everyone in the java industry started using, and people were throwing together any and all java web apps using EJBs. It caused a resurgance in the value of java, and arguably catapulted java into the enterprise space. EJBs promised much. The application servers that would run your EJB-based app had many features, like transactions, security, failover, messaging, and web services to name a few. All you had to do was extend a few interfaces, write a few configuration files, and do a little configuration to the app server.
Well, that was how it was supposed to be, right? The truth was, EJB apps required lots of XML file configuration. Each container had deviations, so your app tended to be container-specific. People usually had too many services turned on, and unit testing was next to impossible. You couldn’t test your app outside the container, so turn around time to see your changes was a nightmare. That is what generated the flurry of frameworks, like Struts, to help make EJB app development simpler. By extending these framework’s classes, you had a little bit less to extend, less to write, and less to configure. But you still had to do it anyway. And that turn around time to test your app? No better. And you had to make your WHOLE app do this. There was no such thing as, “Part of my app is using Struts, another part is using Wicket.”
Then in 2002, Rod Johnson, a java software consultant, wrote a book Expert One-on-One J2EE Development without EJB. When Rod’s book hit the shelves, the message he was sending was completely unorthodox. He showed tactics of code development that quickly made these container-based services obsolete. You didn’t have to extend anyone’s classes. And…you didn’t have to adopt any framework lock-stock-and-barrel. Instead, your app could be 99% based on POJOs. The code he was writing for examples in the book was very pragmatic, and was just like the other frameworks, only it was a framework based on POJOs. Another consultant approached Rod about releasing that software as an open source project, and thus was born The Spring Framework.
This code, while acting similar in output as other frameworks, had a peculiar difference: it did not require actually extending anybody’s classes. In fact, you could write your code 99% framework-free, and Rod & Co. encouraged this.
“So…is Spring a framework or a library?”
I argue: both!
Considering that a library is a set of functions and classes you download and install in your software development toolbox, Spring fits this perfectly. It was inspired by the need to overcome the lethargic development process of the EJB spec. Not only did they improve over EJB’s way of doing things, they also enhanced JDBC, JDNI, JMX, and other things.
- Ben Alex decided to develop a Security library based on the pragmatic concepts behind Spring, which has since become the most widely adopted security solution for java.
- Mark Pollack was also watching Spring cut through the java industry and coded a similar solution for C#/.NET and called it Spring .NET.
- …and the list goes on of other widely adopted libraries/tools developed for the java industry based on Spring’s approach to solving problems
So, yes, Spring is a library. But it is ALSO a framework, in that its original intention was to faciliate building enterprise-grade web applications inside EJB containers. They simply showed that the servlet container was enough. In fact, many shops started fresh adopted the concept of using Apache Tomcat or Jetty as the servlet container, which has been challening the commerical app server market. Combined with the fact that your app could run inside and outside an EJB container, and also be easily JUnit-tested without the slow make-deploy cycle made it a hit.
And…its NOT a framework!
“But, you just SAID Spring is a framework!”
Yeah, I know I did, but many people interpret framework as code meant to be extended. Spring doesn’t require this. It may accomplish the same end result as these other EJB frameworks, but through simpler means. I know this first hand, because I have developed thick Java client apps using Swing. No EJB container to be found! And yet, I have found Spring provided much leverage and functionality. I didn’t have to extend anything. Okay…I had a unique situation involving security where I needed to extend a Spring Security interface, but 99% of my code doesn’t do that. And that’s the point.
“Enough Java already! I thought this was a Python blog!”
Okay, if you’re still reading, it means you are really a cross technology buff. Or maybe you just read blogs instead of sword fighting while waiting while waiting for your code to compile. Otherwise, you freaked that I spent so much time talking about Java, XML, EJBS, and fled the scene. Well, I’m a polyglot programmer. I use all kinds of stuff: C/C++, Java, Python, Tcl/Tk/Expect, PERL, bash/csh, jython, scala, groovy, clojure, anything! Actually, I had never heard the term until I saw Russ’s Skills Matter presentation where he presented himself as an “self professed, unapologetic, polyglot programmer”. But I immediately connected with it.
Anyway, the point I’m trying to make is that the concepts Rod presented are of incredible value. Its not the fact that he was working in Java, but instead the idea that pragmatism is valuable. Instead of always resting comfortably against specs, we need to always be on the lookout for places and paradigms where we are wasting countless cycles in coding and re-coding the same thing. I contend that repetition is one of the top ranking source of bugs, if not the highest.
I believe Spring Python is a library
My first entry into the world of Spring was through their fabulous JdbcTemplate. Writing SQL queries without leaking cursors and connections was of high important to me. When I decided to code a carputer application, I picked Python because reading Dive Into Python had sold me on the beauty of it. However, I quickly realized I was missing my lean-and-mean JdbcTemplate. I started coding a DatabaseTemplate to help me, and realized I was starting to do something just like Rod. Well, I decided then and there to share my library with anyone who was interested. Hope it helps you like it has helped me.
I think, and it’s not a mockery, that the Java world is rather a framework type of environment which leads usually to have as many frameworks as you have developers for the very reason I described above. Python has also its share of frameworks but the language is flexible enough to encourage libraries. I *strongly* believe that Python Spring[sic] has both functionalities that could be attractive to many developers while having the chance of doing so as a library rather than a framework. –Sylvain while commenting about Spring Python w/CherryPy 3
And that’s why I call it Spring Python. It takes the cool concepts of Spring, and write them in a slick-and-quick, pythonic library. And yes, it is a library.