This is far too big of a topic to cover in a blog post...
You use frameworks to provide the 'boilerplate' or repetitive operations you normally would have to do by hand. Some examples of those tasks:
- handling web traffic to your java objects
- rendering pages of output as HTML - what format do you convey them in, etc - JSF and
JSP are two approaches, but also velocity templates and way back when even XML/XSLT have been used, so don't re-invent the wheel...
- handling security
- handling transactions (rolling back with failures)
- logging (log4j is a very popular logging API / framework)
- configuring applications
etc...
So there are application development platform frameworks (Grails, Rails), application infrastructure services (Spring, Seam, Guice) that provide component wiring and easy
testing, security frameworks (Spring Security, Java EE security), even transaction management frameworks (JTA comes to mind).
Some advocates of languages such as Scala feel that frameworks are a bad thing and that
you should write that as code. I'm not convinced myself.
As for Spring...
There are plenty of presentations on why to use Spring - actually Rod Johnson lays it out nicely in his original book on Pro Java EE (forgive me, I don't remember the full title).
The quick answer is that Spring is forward-looking, always trying to find the most elegant and productive way of doing things. Java EE 6 owes a lot to Spring and also to Ruby on Rails, and other frameworks. In some ways, Java EE 6 needs less configuration than Spring does for the base case of providing web apps with services and repositories, but that is the basic use case. Spring is so much more than just a basic web application or service application container. There are tons of useful APIs, and you get very productive very quickly once you learn how to work with dependency injection and with the Spring component APIs and factories.
Hibernate is becoming yet another JPA container too, so you can put it behind a JPA 2 API and use it as your Java EE persistence layer. Spring lives in that world, so you can use hibernate behind JPA (or even naked, with the Session API) with Spring. But you're not limited to that. You can use Spring Data to connect to a number of NoSQL databases. You can use Spring with MyBatis if you like SQL Mapping rather than ORM. Heck, you can do some
JDBC code very efficiently with the JdbcTemplate API. Spring does not lock you in to anything, but opens the possibility to efficiently write software against a wide range of other APIs simply.
Spring is also container neutral. It will run in a simple
servlet engine all the way up to WebSphere and WebLogic and
JBoss and doesn't make any choices for you. It will use JDBC connection pools or app server JNDI data sources for database connectivity. The security, transaction management and monitoring via JMX are all platform agnostic. They don't care what you run on, but will integrate with much of it if needed.
Hopefully that gives you wide enough of a swath of information to start with.
I would read up on Spring itself - go to springsource.org/documentation and download/read the Spring Framework documentation for 3.0.x - if you're already a Java developer, it will be an easy (and illuminating) read. Sure, some of this seems like work compared to setting up the most recent Java EE 6 platforms, but it isn't really that bad and gives you so many options on how to write your applications that you don't feel limited by Spring, rather supported by it.
Best,
Ken
PS - I've worked on a lot of other software that isn't Spring in my past, in my recent past have been a huge fan of Grails, and currently our company web site is Rails 3.1, so I have some comparative background - I have no complaint with any of these things, but if I'm in an enterprise the gotos would be Spring and/or Grails and/or Roo for first choices - it's all Spring and compatible with Java. It's all horses for courses, it's what makes the best sense for your organization.