La modernidad en el desarrollo software

El jueves pasado pude asistir al evento Oracle Enterprise Java Developer Day. En general fue bastante interesante, sobre todo las exposiciones que se realizaron en la primera parte, luego las prácticas se hicieron un poco aburridas, quizás influyó que las herramientas presentadas me eran familiares.

Lo que más llamó mi atención fue el comentario de Alfredo Casado (javaHispano), en su exposición sobre "Desarrollo Moderno y Ligero con Java EE 6", sobre el significado de la modernidad en el desarrollo de software: no es sólo utilizar las últimas tecnologías, es hacerlo aprendiendo de los errores del pasado.

Me identifico bastante con esta definición de modernidad y creo que es una buena reflexión. Realizar desarrollos modernos no es sólo utilizar tecnologías vanguardistas, es mucho más, es usarlas con criterio para hacer el proceso mas sencillo, productivo y de calidad, con el objetivo de poder construir aplicaciones más robustas, mantenibles, eficientes e innovadoras.

Control de errores, ¿reinventando la rueda?

Cuando se define la interfaz de un servicio no suele haber demasiada confusión en qué incluir en el mensaje de entrada, parece claro que debe ser la información necesaria para poder realizar la operación, ni más ni menos. En cambio, en el mensaje de salida, se tiende a incluir en algunas ocasiones, además de la propia información de respuesta, estructuras de control de excepciones, con las siguientes consecuencias:

1. La definición del mensaje de respuesta tiene que incluir una estructura de datos adicional para cuando se producen excepciones.
2. Si se usa una estructura genérica para el control de errores, dificulta poder especificar información diferente para cada excepción. Esto no suele tener importancia si lo que se busca es que el sistema cliente se limite a registrar el problema, pero es fundamental si se devuelve información, que aun no siendo habitual, es parte del funcionamiento del servicio.
3. Obliga a documentar el mecanismo de control de excepciones del servicio para que los sistemas cliente lo puedan interpretar.
4. El sistema cliente para usar el servicio tiene que incluir en su código un procesado específico de la estructura de control de excepciones definida.

¿No estamos en estos casos reinventado la rueda? ¿No está definido en la especificación de servicios como realizar el control de excepciones?

Versionado de servicios

En una arquitectura SOA los servicios van evolucionando con el tiempo, lo que afecta a la definición de sus interfaces. Por eso, es de gran utilidad disponer de un procedimiento que permita minimizar el impacto de los cambios en los sistemas que usan los servicios. De esta forma, conseguiremos reducir las situaciones en las que es preciso regenerar los clientes de acceso, facilitando las tareas de mantenimiento y la adopción de los servicios.

Lo primero es comprender bien como se usa un servicio y que implicaciones tiene, porque, a veces, por la el propio lenguaje, se tiende a confundir o no diferenciar entre el propio servicio y las operaciones que lo componen. Es importante tener claro que un sistema sólo consume realmente un servicio si usa al menos una de las operaciones.

En adelante se asumen las siguientes condicionantes para encontrar el procedimiento de versionado más adecuado:

1. Los servicios pueden ser consumidos por sistemas de diversa índole: diferentes equipos de soporte, diferentes calendarios de subidas a producción, diferentes tiempos de desarrollo, diferentes prioridades, etc., lo que dificulta coordinar los cambios en los servicios.
2. Se busca minimizar el número de servicios publicados, de forma que se pueda reducir la complejidad de uso, las tareas de mantenimiento y los recursos de infraestructura.

Duendecillos verdes y el Dr. House

De vez en cuando se encuentra algún problema o error que a primera vista no tiene mucho sentido, es más, parece que no hay una explicación razonable de lo que está pasando. Es como si hubiera un duendecillo verde en algún lado que está haciendo de las suyas.

En este tipo de problemas, a priori, no parece imperar lógica alguna y muchas veces se tiene la tentación de dejarlo de lado, de hacer como si no existiera, pues no resulta fácil dar con su origen para poder solucionarlo. Pero, son muchas las ocasiones en las que el impacto es importante y hay que hacer todo lo posible por entender el problema y resolverlo.

Código fuente en el blog: SyntaxHighlighter

Tarde o temprano tendrá que llegar la necesidad de incluir algún extracto de código en una entrada del blog y, en vista de que blogger no incluye esta funcionalidad, he realizado una búsqueda rápida para ver alguna alternativa. El que más me gusta por el momento es SyntaxHighlighter, un cliente JavaScript open source interesante, vistoso y al mismo tiempo sencillo de utilizar.

Una de las ventajas de usar este cliente JavaScript es que el autor ha subido a un servidor de Amazon S3 los recursos que utiliza (librerías y hojas de estilos) por lo que no necesitamos de un almacenamiento externo para poder utilizarlo.

Definir bien un servicio: esquemas XML

En el diseño de la interfaz de un servicio es conveniente definir en detalle los mensajes de entrada, de salida y de los posibles fallos que se pueden intercambiar.

Para la descripción de estos mensajes, aunque hay otras alternativas, es habitual emplear el lenguaje Schema XML que permite establecer en detalle las estructuras de campos, tipos de datos, restricciones en los valores (patrones, listas...), obligatoriedades, estructuras alternativas, etc.