El próximo Jueves 2 de junio, tendrá lugar la primera reunión del grupo de Java de Madrid (JUG). Espero poder asistir a este primer evento de este grupo recién creado y que sea un foro donde se pueda aprender y discutir sobre la plataforma (realmente es más que un lenguaje) en la que se ha convertido Java.

A lo largo de estos años he pasado por Caja Madrid, Banco Urquijo, BBVA, Bankinter, Linea Directa, Mutua Madrileña y MAPFRE. Creo que es una buena representación del sector de Banca Seguros de España, y en todas ellas se usa la plataforma Java para construir sus aplicaciones (y cada vez más). Por supuesto, son muchas sus virtudes pero por desgracia también son varios sus defectos. Y precisamente, pensando en el evento de Madrid JUG me he parado un poco a reflexinar cuales son aquellos aspectos que tiene que mejorar:

Baja productividad

Si cogemos lo que podríamos llamar el estándar de Java (plataforma JEE) como podría ser por ejemplo el API de Servlets y de JSP, y nos ponemos a implementar una aplicación, está claro que sufriremos bastante. El API es de demasiado bajo nivel y para hacer una aplicación sencilla con un par de páginas que muestran información guardada en base de datos, podemos tardar mucho, mucho tiempo. Además, nos veríamos obligados a hacer tareas repetitivas y de bajo nivel, por ejemplo con el API de acceso de base de datos tendríamos que asegurarnos de que se cierren bien las conexiones, tratamiento de errores, etc. etc.
En esta situación, es prácticamente imprescindible usar un framework de desarrollo, precisamente para evitarnos las tareas de bajo nivel que no nos aportan nada y que nos permitan centrarnos en implementar la lógica de negocio no en los aspectos técnicos.
Además con el uso de un framework, lograremos que nuestro código esté estructurado, separado por capas (interacción con el usuario, control, negocio, acceso a datos, etc.) y será más fácil su mantenimiento y se facilita la transferencia del conocimiento de la aplicación a otra persona o a otro equipo de desarrollo.
Sin embargo, no llega a ser suficiente. La productividad obtenida con los frameworks estándar sigue siendo bastante pobre. 

Excesiva complejidad

Otro de los males que aquejan gravemente a las aplicaciones Java, y en general a las aplicaciones de sistemas abiertos es su excesiva complejidad.
Una aplicación sencilla ya es es dificil de gestionar y mantener pero la complejidad de los desarrollos no hace mas que crecer y crecer.
Con la orientación a servicios y procesos, la complejidad crece de forma exponencial. Así, en una aplicación de este tipo tendremos:

  • Una aplicación para el frontal (servidor de aplicaciones + servidor web)
  • Uno o varios servicios publicados en el ESB donde de está la lógica de integración
  • Un registro de servicios (UDDI)
  • Uno o varios backends con la lógica de negocio
  • Base de datos
  • Repositorio de usuario para autenticación y autorización tipo LDAP
  • Repositorio documental
  • Un sistema de archivos tipo NAS
  • Si usamos monitorizacion en el proceso (BAM) un dashboard

Simple, lo que se dice simple, no es.

Excesiva fragilidad

Derivado de su gran complejidad encontramos una tremenda fragilidad. Me refiero con esto por ejemplo, que un error en un fichero propiedades puede tener como resultado que una aplicación tan compleja deje de funcionar.
Esta es una cosa que a las personas que vienen del mundo de los mainframes no se acaban de creer. Ellos están acostumbrados a que las cosas funcionen y a que no se caen. Los de “sistemas abiertos”, no diría que estamos acostumbrados a que las aplicaciones se caigan, digamos que no “nos coge por sorpresa”

Conclusión:

¿que podemos hacer para paliar estos tres males? Buena pregunta para un grupo como el Madrid JUG ¿no?

Comparte esta entrada:
Share