Hola a todos, pensaba hacer una reseña al uso sobre el SpringIO 2011 Madrid, pero las distintas sesiones a las que asistí me han dejado una idea bastante persistente en la cabeza: VMWare se está posicionando como clara competencia de Oracle en el mundo de las aplicaciones empresariales JAVA (plataforma JVM mejor dicho). Como la mayoría de vosotros sabeis VMWare compró SpringSource, así que ahora todas las decisiones estratégicas sobre el desarrollo de Spring se toman con la participación y el consentimiento de VMWare. Pensar otra cosa sería pecar de excesiva inocencia.
En la conferencia me percaté de que varios temas se repetían una y otra vez en las distintas charlas: Grails, Cloud Computing, noSQL y “Portable Service Abstractions”. Comentaré primero lo que se habló sobre cada uno de estos temas y después explicaré porqué todos ellos me hacen pensar que VMWare se postula como seria competencia de Oracle.
Sin saber mucho de Grails, me da la impresión que es un framework “orientado a la base de datos”. En los ejemplos que he visto siempre se habla del MVC, pero todos los modelos Grails que he visto no son más que JavaBeans (a.k.a. registros COBOL recauchutados), eso sí, codificados en Groovy, que es mas “cool”. Después tienes las vistas, que no son más que JSPs (perdonad, GSPs) y un controlador escrito en Groovy que en realidad es un controlador de Spring MVC (que es casi igual a un backing bean de JSF). Vamos, más modelo anémico. Ciertamente es mucho mejor que un modelo anémico que podamos hacer en JAVA, y sí, no hay que picar apenas código (se agradece), con lo cual considero a Grails la plataforma perfecta para este tipo de aplicaciones. Si estoy metiendo la pata perdonadme, pero ya sabéis que me hierve la sangre con este tema ¡ Si alguien sabe como hacer buena OO con Grails que me lo diga !
Dejando de lado esta diatriba, la charla a la que asistí de Grails fue muy interesante. Peter Ledbrook explicó de forma bastante clara como integrar Grails con el resto de la empresa. ¿Qué hacemos si queremos hacer un build con ANT? ¿Y con MAVEN? ¿Y si ya existe un modelo hecho con JPA? ¿Y si resulta que el administrador de base de datos nos obliga a una determinada nomenclatura? La verdad es que resolvió bastante bien todos estos escenarios, aunque la parte de integración con MAVEN me dio la impresión de estar un pelín verde. Quizás el mayor problema es cuando ya existe un esquema de base de datos que tenemos que respetar. Aquí es donde la solución que dio no me terminó de parecer clara, y me pareció que proponía que se hiciera un modelo JPA y se integrara éste modelo con Grails. Está claro que en SpringSource se han dado cuenta de que uno de los obstáculos principales para que Grails triunfe es poder integrarse con los elementos más usuales en un sistema empresarial.
Otro punto que se habló de Grails fue integrar GORM (motor de mapeo Objeto/Relacional de Grails) con bases de datos noSQL. Se mencionó este tema en la segunda key note e @ialcazar me comentó un poco sobre una sesión que se dio a este respecto. No termino de ver como se puede integrar un motor de mapeo objeto/relacional con una base de datos no relacional ¡ Precisamente una de las ventajas de una base de datos noSQL es que no necesitamos un mapeo Objeto/Relacional ! No termino de verle el sentido técnico, pero sí el de marketing. En cualquier caso creo que es una iniciativa muy interesante de la comunidad de Grails, esperemos que lo consigan sin cargarse la escalabilidad que nos da un noSQL. También noté preocupación por el rendimiento de Grails, y se ve que están trabajando muy duro para mejorarlo.
Otro tema que estuvo bastante presente fue el Cloud Computing. Durante la primera key note y alguna que otra charla se habló de que el objetivo a medio plazo es preparar a Spring para permitir desarrollar aplicaciones en la nube. Realmente no termino de ver que problema hay con las APIs actuales de Spring y la nube, así que todo esto me suena a simple marketing. En este sentido me hubiera gustado que hablaran de tecnologías como vFabric o GemFire, pero claro, aunque son parte de VMWare, técnicamente no forman parte de Spring, con lo que hubiera estado fuera de lugar nombrarlas. Tal vez cuando se hablaba de adaptar Spring a la nube se refirieran a conseguir mayor rendimiento, y sobre todo escalabilidad y elasticidad, cosa fundamental en este tipo de entornos.
Quizás en este sentido se entienda el esfuerzo por integrarse con sistemas de persistencia noSQL, que proporcionan mayor escalabilidad a las aplicaciones. Una de las charlas más interesantes fue la de Spring Data de Costin Landau. Realmente me gustó la propuesta de Spring de montar un API “estándar” para noSQL, sobre todo teniendo en cuenta que JEE no proporciona nada comparable. En concreto las APIs de bajo nivel y el concepto de “repositorio” me resultó interesante. También la idea de dar cobertura a bases de datos documentales y orientadas a grafos me resultó bastante atractiva. Sin embargo a otras propuestas, como incorporar un sistema de persistencia mixto que mantuviera parte del modelo en BBDD relacional y parte en noSQL no acabo de verles el sentido. Tal vez sea un compromiso de “marketing” para que a la gente no le de miedo adoptar noSQL, ya que seguirían teniendo el respaldo de bases de datos tradicionales. A mi simplemente me parece una postura originada por el miedo de la gente a noSQL. Ya sabéis que pienso que si el sistema tiene las consultas bien definidas, el enfoque noSQL es totalmente superior al tradicional, y que sólo usaría un sistema SQL si realmente el conjunto de consultas las va a decidir el usuario en runtime, como son el caso de bussiness inteligence y data mining por ejemplo.
En la línea de noSQL la charla sobre Redis de Alberto Gimeno fue curiosa. Personalmente pienso que Redis está un poco verde todavía, aunque a alguno le puede interesar el concepto de clave/valor avanzado. Al contrario que un clave/valor simple, el valor almacenado puede ser no sólo un array de bytes, sino estructuras de datos como contadores, listas, mapas o sets. Para cada tipo de datos REDIS proporciona un conjunto de operaciones específicas, que se pueden ejecutar de forma atómica, y extienden el paradigma clásico del clave/valor. No termino de ver por qué esta complejidad extra es necesaria, pero sí que es verdad que facilita a un recién llegado al noSQL la transición desde el mundo de las BBDD relacionales. En todo caso me alegró ver que la gente empieza a usar sistemas noSQL, ya sabéis de que pié cojeo.
Otro tema que fue hilo conductor de esta conferencia fue el concepto de “Portable Service Abstraction”. Este nombre es una forma “cool” de decir que si desarrollamos contra interfaces “estándar”, nuestro código será portable a otros entornos. Es una idea muy vieja, y es lo que intentó JEE. Como ejemplos de estas “Portable Service Abstraction” podemos tener Spring Data, Spring REST, Spring AMQP, Spring Social, Spring Mobile y Spring Android. En general me gusta el enfoque de Spring de hacer APIs sencillas, y de reaccionar de forma rápida y ágil a las necesidades de los desarrolladores. Sin embargo no es oro todo lo que reluce. No entiendo la necesidad de Spring REST, desde mi punto de vista JAX-RS era un estándar más que suficiente. De hecho ambos estándares son tan similares, que es difícil distinguir dos aplicaciones hechas sobre cada una de ellas. Por otro lado Spring Mobile y Spring Android me decepcionaron, ya que apenan aportan valor. El primero básicamente sólo te detecta el tipo de dispositivo móvil y te redirige a una página de presentación u otra en función de éste. Vamos, nada que no exista ya en las múltiples arquitecturas multicanal “clásicas”. Spring Android es sólo un cliente para hacer llamadas al servidor. Los que sí me gustaron bastante fueron Spring Social, Spring Data y Spring AMQP. En concreto este último, ya que me pareció que el RabbitMQ era genial.
Toda esta información que recibí en la SpringIO me hizo ver que VMWare está intentando atacar a Oracle por varios frentes:
- Spring como substituto de JEE. Aunque Spring es compatible con JEE, en el fondo lo que pretende es que programemos contra sus APIs en vez de las de JEE, aduciendo motivos de portabilidad. Esto es gracioso, ya que JEE nos propone exactamente lo mismo: una aplicación programada contra JEE es portable al ser éste el estándar de iure para el desarrollo de aplicaciones empresariales. Así que, ¿cuál API es más estándar, JEE o Spring? Esta claro que Spring ha sabido evolucionar sus APIs de forma más ágil y práctica que JEE, con todos sus comités. Todo esto es una amenaza clara contra Oracle, que es la actual “dueña” de JEE.
- Tomcat y Spring tc Server como substitutos de WebLogic (y de paso de WebSphere). Si vamos a programar contra Spring en vez de contra JEE no tiene sentido comprar un servidor JEE completo como WebLogic o WebSphere, nos basta un contenedor de Servlets como Tomcat. Para los que no lo sepáis WebLogic es de Oracle.
- AMQP y RabbitMQ contra JMS. Aunque RabbitMQ se integra con JMS, en realidad es una alternativa viable a JMS, y a cosas como MQSeries.
- Grails como substituto de JSF. Como ya sabréis el modelo de programación web JEE es JSF. De hecho Oracle ha invertido en su implementación de JSF, llamada Oracle ADF, y en un IDE especial para ADF basado en Eclipse. Oracle ADF y su IDE nos permite hacer aplicaciones orientadas a base de datos muy rápidamente (o eso me han contado). Está claro que SpringToolSuite junto con Grails es competencia directa de esta tecnología.
- noSQL contra las bases de datos relacionales. Como sabéis Oracle es dueña no sólo de la base de datos relacional más famosa del mundo, sino que con la compra de Sun, puede hacerse con el control de MySQL. Obviamente apostar por noSQL es un golpe directo a la linea de flotación de Oracle. Curiosamente el único sistema noSQL del que se habló con detalle en la conferencia fue de REDIS, que está “esponsorizado” por VMWare.
- Cloud Computing contra hosting tradicional. El Cloud Computing es un escenario que creo beneficia más a VMWare que a Oracle. El primero, ha hecho una apuesta fuerte en este sentido con vFabric y vmForce. Si tienes una instalación propia, puede venir un comercial de Oracle a venderte WebLogic y la base de datos de turno. En un cloud no. Si convences a una empresa para irse al cloud, es más que probable que sus bases de datos Oracle queden en desuso.
En definitiva, Spring pretende suplantar a JEE como plataforma estandarizada para el desarrollo de aplicaciones empresariales con JAVA. Bueno, tal vez yo sea un poco suspicaz, pero esto es lo que realmente leo entre lineas de la conferencia SpringIO. Por cierto fue un éxito de público, y en general el nivel de las sesiones y talleres fue bastante alto. Enhorabuena a la organización, ya que no creo que con 20 euros se pudiera haber hecho mejor. ¿A alguien le pareció caro? A mi no.
Buen post Enrique.
Es cierto que cada vez se hace más patente la intención de Spring de sustituir el uso del estandar JEE por sus APIs. De hecho, creo que uno de los mejores “inventos” que introdujo Spring fue el IOC, que ha facilitado y mejorado la productividad en el desarrollo de aplicaciones java.
Desde mi punto de vista, creo que JEE tiene una dura competencia, aunque tiene un nicho de mercado bastante concreto, principalmente potenciado por empresas como IBM que necesitan vender sus plataformas.
“un sistema de persistencia mixto que mantuviera parte del modelo en BBDD relacional y parte en noSQL no acabo de verles el sentido…
”
pues segun me enteré yo de esta “fiesta” se me vino a la cabeza un gestor de contenidos, con las relaciones entre contenidos modeladas en NOSQL para permitir busquedas avanzadas y los datos pesados en RDBs….
no?
Mmm, quizás me haya explicado mal en ese párrafo. Lo que realmente quiero decir es: ¿para qué quieres este sistema mixto? ¿Por qué no usas sólo un sistema noSQL? ¿Qué valor te aporta la BBDD relacional? Por supuesto es una buena idea como solución “diplomática” el poder decir: “hey, voy a usar esto del noSQL pero que nadie se alarme, los datos también estarán en BBDD de toda la vida” o algo como “tranquilos, los datos importantes van a ir en la BBDD relacional como dios manda, en noSQL sólo meteré información sin importancia, cosillas de la web
”
Si la BBDD relacional te está entorpeciendo… ¡quitala!
Ya sabes que sólo le veo sentido en algunos escenarios concretos, e incluso en estos escenarios un sistemas de persistencia orientado a grafos puede ser más útil y sencillo de manejar.
La fuerza de una graphdb reside en sus busquedas, mas que en el volumen ni peso de los contenidos que maneja… por eso mi enfoque aqui es, pon en la graph-db la informacion relevante para las relaciones y los campos mas comunes siempre que pesen poco… los campos pesados (los que guardarias en un CLOB) sacalos a RDB o ficheros o donde sea, manteniendo una referencia claro…
En ese escenario la BBDD no me molesta demasiado si es eficiente al tratar con el contenido que le asigno… Eso si, tiene las pegas de mantener varias fuentes de datos y sincronizarlas…
Por cierto, has visto spring-data-commons… Arriba el DDD!!!
Y has visto spring-data-jpa? El API magica de persistencia, todo semantico, solo picas interfaces…. mola pero da un poco de miedito…
Sí, justo una de las sesiones repasó el Spring Data ¡ Muy interesante !
La verdad es que comparto esa sensación que te produjo el Spring IO. Sin duda la idea de Oracle es tener un stack de productos web basados en Oracle ADF. Como IDE un potente JDeveloper con integración con todos sus productos y un flamante Weblogic con servidor de aplicaciones.
Desde mi punto de vista la ventaja de Oracle ADF es la gran integración y uso sencillo que tienen en todas sus plataformas. En JDeveloper es muy potente y se hace realmente sencillo trabajar con él. Da igual si vas a hacer Portales o Procesos de negocio, JDeveloper es tu IDE.
En contraposición el STS de Spring se va posicionando poco a poco como alternativa al tradicional Eclipse. Incluso me sorpredión grátamente Spring Integration, la solución SOA de Spring que permite modelar procesos de negocio.
Quién se llevará el gato al agua?. Creo que Oracle se equivoca si busca enemigos en IBM o Google, su principal competidor es VMWare y todo su Stack tecnológico.
Por otro lado, eché en falta que se hablara un poco mas de OSGI…donde está todo esto? La gente habla de Cloud y noSQL pero nada de OSGI.
Gran post Enrique, se hace hasta corto incluso
Me queda la duda de cual es más productivo haciendo aplicaciones orientadas a base de datos: ¿Grails+STS u Oracle ADF+JDeveloper? Realmente no conozco ninguna de las dos plataformas a fondo y no se juzgar.
Buen post, en esto de las tecnologias es casi imprescindible una buena dosis de espiritu critico para separar el marketing del analisis tecnico y contextualizar este ultimo en el competitivo mundo del j2ee. Sobre todo si acudes a un evento organizado por aquellos que te venden las tecnologias de las que se hablan.
En él desde hace tiempo triunfa el conservadurismo y es normal que una empresa que quiere ganar mercado en el enterprise ofrezca soluciones conservadoras y progresivas, aunque no te cuenten en los actos que organizan ellos mismos el coste de ese conservadurismo y solo te vendan que asi tienes “lo mejor de ambos”.
En el otro lado (el de sun/oracle) se estan haciendo tb avances en parte recogiendo las caracteristicas que han hecho popular a Spring y seria injusto no tenen en cuenta esos avances.
Sin embargo no veo porque grails obligue mas que el j2ee tradicional a implementar modelos anemicos, mas bien diria que aunque te permite y hasta facilita hacerlos tambien lo contrario. Si te cuadra poner a regimen tus entidades de negocio y “decorarlas” segun el contexto que las uses pues las conviertes en sacos de propiedades, si quieres darles mas responsabilidades de forma “estatica” en el codigo pues les das. En todo caso las validaciones de las entidades de negocio viven en ellas y al menos para mi que peleo con el j2ee de hace 10 años me parece un avance. El ecosistema de plugins es bastante dinamico (doble filo de nuevo) y seguro que que tienes unos cuantos para hacer bdd usando librerias java grooverizadas (70% de los plugins son eso)
No quise decir que Grails fomentara más que JEE el modelo anémico. En mi opinión ambos lo fomentan por igual. Pero leyendo bien lo que escribí sí que se entiende por ese sentido.
Tienes toda la razón con lo de la venta usando un enfoque conservador y “lo mejor de ambos”. Al fin y al cabo hay que recuperar la inversión de lo que ya se tiene, y eso de tirarlo y empezar de cero puede ser admitir que se invirtió dinero en algo que no sirve o no ha sido rentable.
La verdad es que a mi lo de los plugins de Grails es lo que más me pica la curiosidad. ¿Hay mucha diversidad? ¿Hasta que punto se puede extender Grails con un plugin? Un día tengo que pararme a mirarlos con tranquilidad ¡ Lo mismo me animo a escribir uno !
[...] aplicaciones sin el web.xml. Esto está creando una competencia directa entre Spring y Java EE (VMWare vs Oracle), aunque también pueden utilizarse [...]