Contratos de Servicios Estandarizados

por

Principio SOA 1 – Todos los Contratos de Servicio del Catalogo SOA deben cumplir los mismos estandares y normas de diseño

 

Contratos de Servicios.

Lo primero que me gustaría destacar de este principio es el término Contrato.

No cometamos el error de pensar automáticamente en los WSDL de los servicios web. Esos contratos se sitúan a nivel tecnológico. El Contrato de un Servicio SOA es su documento de diseño, y recoge toda la información de negocio y funcional que delimitan su alcance y casos de uso, la estructura del mensaje que utiliza, el detalle de la información que debe viajar en cada nodo del mensaje, su diagrama de secuencia, que ilustra el patrón de comunicación típico para ese servicio (sincronía, asincronía, secuencia de eventos/mensajes, etc), los errores funcionales que pueden darse, y cuantas referencias sean necesarias a las normas de diseño establecidas por la Oficina de Gobernanza.

 

Normas de Diseño.

Lo segundo que vamos a comentar es justo esto último: las normas de diseño.

Los Contratos de Servicios no deben incluir ninguna norma de diseño. Fijaros que hemos dicho que el Contrato de Servicio debe incluir «cuantas referencias sean necesarias a las normas de diseño», pero no las normas en sí mismas.

 

Todas estas normas deben estar recogidas en un único documento aparte, que a modo de libro blanco constituye la referencia única y vinculante de uso obligatorio por todos y cada uno de los actores participantes en los proyectos de interoperabilidad. A menudo a esta normativa se la conoce como Catálogo de Normas.

 

La Oficina de Gobernanza es quien debe mantener dichas normas y quien debe velar por su cumplimiento. Pero no solo en los Contratos de Servicios, tal como indica este principio SOA, sino también debe velar por su cumplimiento por parte de los equipos responsables de los sistemas que proveen y/o consumen el servicio sujeto del Contrato. Esta es la parte más difícil.

 

Estándar.

El tercer término importante a destacar en este principio es el estándar.

Como hemos dicho en anteriores entradas en este blog, el uso de estándares garantiza la interoperabilidad y la reutilización de los servicios. Pero el uso de estándares debe ser un uso correcto, lo cual implica precisión. La ambigüedad es uno de los enemigos de la definición de Contratos de Servicios, y es un enemigo muy escurridizo.

 

Una vez dicho todo esto, lo que este principio viene a destacar es que, en un mismo Catálogo de Servicios, todos los servicios (sus Contratos de diseño) deben cumplir las mismas normas y estándares de diseño marcados desde la Oficina de Gobernanza SOA. El uso de estándares y el cumplimiento de las normas establecidas hace posible la gobernanza del Catálogo, esto es evidente. Pensad que, precisamente, la ausencia de estándares y normas comunes es una de las principales causas de las arquitecturas de espagueti que abundan en las empresas y organismos públicos, donde el control y coordinación de los mapas de sistemas de integración suponen tareas prácticamente imposibles de acometer.

 

A modo de conclusión por mi parte, este primer principio SOA apunta directamente a permitir la Gobernanza, que como hemos dicho aquí varias veces, supone el motor fundamental de la estrategia SOA.

 

¿Qué opináis vosotros?

 

Te puede interesar

2 Comentarios

  1. Rodrigo Romero

    Estimado, estoy queriendo realizar un precepto en SOA, de «contrato de servio», pero no se como hacerlo ya q no es un tema que tenga mucha informacion no hay ejemplo de Precepto., si pueden orientarme.

    Gracias

    Responder
    • Manuel Jesús Morales

      Hola Rodrigo, gracias por comentar. Para poder orientarte necesitaría alguna información más, ¿exactamente qué quieres hacer?. Puedes seguir este mismo hilo de comentarios, o si lo prefieres puedes utilizar el formulario de contacto para ampliar la información por correo. Un saludo.

      Responder

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This