Portabilidad: Siguiendo la especificación

En Coding the Architecture abrieron un debate muy interesante hace unos días. Es ese tipo de debate en el que miras hacia atrás y ves inevitablemente como tu opinión ha ido cambiado con el tiempo, ya se hacia un lado o hacia el otro. Y es que al final, cada uno contará la historia como le haya ido en la feria.

Hace ocho años, era todo acerca de la portabilidad. Acerca de la especificación. La portabilidad era la gran baza de JEE, y cualquiera que se mantuviese dentro de los límites de la especificación estaba a salvo. ¡Qué gran consuelo cuando tecnologías como EJB 1.1 te garantizaban un camino amargo y tortuoso! Con el tiempo, el debate sobre portabilidad se ha aligerado mucho, y el no seguir la especificación es como el hombre del saco, que te asusta las primeras veces pero que cuando ves que funciona y no pasa nada, pues pierde toda su importancia.

En mi caso, como el de Simon Brown, mi opinión también ha ido cambiando con el tiempo. Pero un poco al contrario. Hace años yo era partidario de no seguir la especificación si llegabas a un punto en el que te estaba restringiendo demasiado. Todavía recuerdo discusiones airadas sobre este tema con amigos y compañeros de trabajo que opinaban justamente lo contrario. El tiempo me ha enseñado que no hay una verdad única respecto a este tema, y que como casi todo, realmente dependerá en el problema que tengas que solucionar, pero que si realmente decides apartarte de la especificación, este debe ser un factor como otro cualquiera que deberás balancear y sobre el que deberás ponderar riesgos y ventajas.

Por ejemplo, hace tiempo, trabajando en un proyecto me encontré con varias partes de una gran aplicación que utilizaban threads directamente para realizar ciertas operaciones. Estas operaciones incluían escrituras en base de datos o envio de mensajes entre otras cosas. ¡Herejía! ¡Uso de threads en managed-systems! El desarrollo había continuado adelante porque era rápido y porque nunca había pasado nada. Sin embargo, a medida que la carga del sistema aumentaba, se pudo observar que se empezaban a perder mensajes, que había transacciones que no se completaban o se hacía rollback de repente, y otro número de efectos insospechados.

El problema era que se habían apartado demasiado de la especificación, y los efectos eran inesperados. Es así de fácil. No estás en la especificación, no tienes garantía de nada. ¡Si es que a veces no la tienes ni cuando sigues la especificación! La solución en este caso fue aprovechar que el servidor implementaba la specificación commonj y devolver esos Threads al contexto que le pertenecían, el contenedor. Eso solucionó todos los problemas.

Ser consciente de que te pueden pasar estas cosas es algo importante a la hora de hacer la decisión de restringirte o no a la especificación. Otro factor muy importante que he podido ver con el tiempo es el negocio al que se dedique la compañía, y como se va a vender la aplicación que se está creando. Muchas compañías que facturan productos ofrecen soluciones basadas en plataformas comunes como Oracle, WebSphere, WebLogic, a la vez que ofrecen otras soluciones de bajo coste basadas en MySQL, PostgreSQL o JBoss. En este caso, es importante mantenerse lo más cerca posible de la especificación, ya que cualquier opción especial que utilizemos la tendremos que reimplementar tanto para la plataforma premium como para la Open Source.

Otro caso con el que me encontrado es con productos que están bajo un servidor de aplicaciones en contreto y necesitan ser migradas a otro para entrar en determinado sector. Un ejemplo típico sería el entrar en la banca donde en algunos sitios te exigirán IBM WebSphere como plataforma de despliegue.

En fin, que al final, como mencionan en los comentarios, es un balance entre los planes de futuro que haya en la aplicación en cuanto a portabilidad y los problemas que nos encontremos al desarrollar. Si existe la posibilidad de despligue en múltiples plataformas, entonces es mejor ir con cuidado; en caso contrario, siempre se puede quebrantar un poco más las normas, pero siempre siendo conscientes de las posibles consecuencias en cuanto a efectos inesperados.

¿Es Spring el nuevo Java EE?

Me ha parecido interesante el artículo de Salil Deshpande, ex CEO of The Middleware Company, publicado en su ex-portal TheServerSide.

Sobre todo porque es un poco un recordatorio de lo que ha pasado en los últimos tres años. Y además tiene toda la razón. ¡Es que parece que fue ayer! El artículo va muy en la línea de este post de hoy mismo de Ignacio Coloma. Hay que reconocer que Spring se ha impuesto al yugo de toda especificación posible, y además con el mérito de haber hecho de AOP una cosa habitual, hasta el punto de que probablemente nadie utilizará AOP si no existiese Spring. Probablemente algo parecido pasará con OSGi que parece ser la nueva baza de los chicos de Interface21.

Pero volviendo al artículo original, personalmente, yo ya sabéis que soy gallego, y en fin, que ni lo uno ni lo otro, que hay sitio para todos. Nosotros utilizamos Spring, pero también tenemos nuestro servidor de aplicaciones que nos ayuda en muchas cosas que de otro modo nos complicarían muchísimo la vida el hacerlas nosotros a mano (léase mensajería ... bueno, ejem, ... ayuda mmmm ... , clustering y failover, integración con third parties, bla bla bla).

De cualqueir modo, el mérito de Spring es impresionante. Sobrevivir manteniéndose al márgen de los estándares y convertirse en estándar de facto tiene realmente muchísimo mérito.