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.

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.

Servicios Web en Java

Esta es una de las definiciones que se pueden encontrar sobre un servicio web:

"Un servicio web (en inglés, web service) es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares."

Al estar basado en la interoperabilidad el desarrollo de Servicios Web puede realizarse en diferentes entornos de desarrollo como Java o .NET.

Si nos centramos en el mundo Java, para el desarrollo de un servicio web se pueden emplear diferentes frameworks, por ejemplo, Apache Axis, Apache Axis2, Apache CFX o GlassFish Metro. Estas implementaciones están basadas en alguna de las versiones del modelo de programación estandarizado dentro de la Comunidad Java.

Es interesante conocer la evolución de la especificación del modelo de programación de servicios web en Java, pues puede permitir identificar las características y compatibilidad, dentro de un mismo desarrollo, en el caso de utilizar diferentes frameworks.