He de confesar mi admiración por el creador de Spring y fundador de la empresa que lo soporta (empezó llamándose Interface21 y ahora se llama SpringSource, una divisón de VMWARE). Me refiero a Rod Johnson, autor de dos libros que fueron éxito de ventas en su momento: Expert One-on-One J2EE Design and Development (2002) y J2EE without EJB (2004).
En estos libros explicaba su visión de J2EE desde un punto de vista muy práctico y sobre todo rezumando experiencia de primera mano en el uso de los APIs y frameworks J2EE. Con una visión crítica respecto a lo que había en ese momento (en especial contra el uso de EJB que realmente no veía necesario) creó un nuevo framework que hoy conocemos como Spring.
No fue el inventor de conceptos como Inyección de Dependencia o Inversión de Control (Principio de Hollywood), pero sí fue el que los popularizó e hizo que hoy en día son patrones que nadie discute (se incluyeron por ejemplo en la especificación EJB 3.0)
En un principio Spring únicamente fue un framework al que se le fue añadiendo sucesivos módulos alrededor de su factoría de beans (contenedor ligero con inyección de dependencia), como por ejemplo:
- MVC: un framework para la creación de interfaces web siguiendo el paradigma Modelo-Vista-Controlador
- DAO: acceso a base de datos
- AOP: soporte a orientación a aspectos
- Spring Security
- Etc.
Sin embargo,en los últimos tiempos Spring es más que un framework, ha ido evolucionando hasta dar una completa oferta para todas las necesidades de construcción, despliegue y ejecución de una aplicación J2EE.
Así, divide su oferta en tres grandes pilares:
- Build: con el framework Spring, Groovy and Grails y herramientas para el desarrollo de aplicaciones
- Run: proporciona infraestructura de ejecución como tc Server (extensión de Apache Tomcat) capaz de gestionar las aplicaciones y realizar diagnósticos avanzados de su ejecución o como ERS, extensión de Apache http server como capacidades mejoradas de seguridad, escalabilidad y rendimiento
- Manage: tal vez Spring sea el framework más usado en la actualidad (se estiman más de 3 millones de desarrolladores) por lo que proporcionan el producto Hyperic HQ que monitoriza y gestiona la infraestructura con un enfoque 24/7
Entre el resto de sus productos podemos mencionar:
- Spring Batch: framework de desarrollo de aplicaciones batch en Java basada en conceptos tradicionales como Job y Step
- Spring Roo: herramienta para el desarrollo rápido de aplicaciones
- Spring OSGI: soporte a OSGI para actualizar módulos de aplicaciones en tiempo de ejecución, puede añadir, eliminar y modificar estos módulos y tener simultáneamente varias versiones en tiempo de ejecución.
En fin, soy de la opinión de que hoy en día debería ser “obligatorio” el uso de Spring Framework en las aplicaciones JEE.
15/03/2010 at 21:10
Buenas,
Estoy totalmente de acuerdo contigo, hoy en día las aplicaciones JEE sin Spring no tienen mucho sentido, es tanto lo que ofrece que es impensable hacerse toda esa cantidad de funcionalidad de forma ad hoc para una empresa y no usar Spring… Aunque conozco casos donde ha ocurrido lo contrario 🙂
Al igual que los creadores de Hibernate colaboraron con la especificación JPA, desconozco si la gente de Spring ha colaborado en alguna JSR, la verdad es que si no lo han hecho tienen mucho que aportar para la comunidad Java por lo que se debería contar con ellos.
Spring tiene mucho que ofrecer y poco le queda para convertirse en un estándar de facto.
Saludos.
PD: Visita la página de mi grupo: http://www.shalm.es
16/03/2010 at 13:50
Hace muchos años que Spring aporta un gran valor a los proyectos. Como todo hay que saber para que sirve y como utilizarlo bien y sobre todo como evitar utilizarlo mal.
Conocí Spring en el 2005 como parte de una investigación interna y comencé a trabajar con en él 2006. Hasta ese momento solo como light framework por los beneficios del IoC y así evitar el lío de las AbstractFactories. No solo la versión Java, sino la .Net también.
Hoy estoy utilizándolo en mi proyecto de final de carrera con JPA, Hibernate, Struts y todo dentro de Tomcat. Para proyectos «no enterprise» es una gran solución, ya que permite aplicar los paradigmas de una aplicación enterprise pero en la escala adecuada.
Comparto la idea de lo importante que es pensar si nuestro proyecto no puede beneficiarse de uno o varios módulos del SpringFramework. Si aplica, hay que aprovecharlo, no vale la pena reinventarse nada.
Creo que el problema de estas cosas es que hay muy pocos arquitectos para tantos proyectos que comienzan. Arquitecto es Arquitecto, no un chaval que como hay que aumentarle el sueldo le damos ese puesto.
PD: ¿Quién me explica el concepto de arquitecto Jr?
16/03/2010 at 21:24
Arquitecto Jr. es un perfil que ofrecen las empresas que buscan un programador, el cual ha inflado su CV para decir que es arquitecto…