La Abstracción en los Servicios

por

 

Principio SOA 3 – Los Contratos de Servicios solo contienen informacion esencial y la informacion sobre los servicios se limita a lo que se publica en los Contratos de Servicios

 

La abstracción tenía que estar en los principios SOA. Si has leído mis anteriores entradas en este blog, habrás visto como este concepto aparece a menudo cuando tratamos la orientación a servicios. De hecho le dedicamos esta entrada expresamente.

 

Abstracción.

Efectivamente este tercer principio SOA se centra en la abstracción. Tal como se indica en el texto que acompaña ese principio, la abstracción está muy relacionada con el nivel de acoplamiento y con la granularidad de los servicios. Y por lo tanto incide también en el índice de reutilización (del que hablaremos en otro principio SOA muy pronto).

 

Si os fijáis estos primeros principios SOA están muy relacionados entre sí. El uso de estándares (primer principio SOA) permite definir interfaces uniformes que esconden la lógica del servicio respecto del entorno que le rodea (sistemas proveedores y consumidores). Esto permite encapsular el servicio y reducir el acoplamiento (segundo principio SOA). Y con un servicio encapsulado, estándar y desacoplado, el nivel de abstracción define el alcance del servicio en su ámbito de negocio, y su índice de reutilización.

 

La abstracción es una característica profundamente presente en la historia del software. Las tecnologías de la información, los lenguajes de programación, los API, las técnicas de diseño, distintos diagramas UML, etc, etc, etc, aplican continuamente sucesivas capas de abstracción para, por un lado, alejarnos de la tecnología, y por otro lado, para acercarnos al mundo real que pretendemos captar y modelar. El propio modelo OSI que tanta importancia tuvo en su momento era un ejercicio de abstracción.

 

Los distintos paradigmas de desarrollo de software han supuesto pasos significativos en los niveles de abstracción que aplicamos al diseñar sistemas de información.

 

La programación estructurada promovió no solo el orden en el código fuente sino la reutilización interna de trozos de código especializados (los procedimientos, las funciones), para lo cual era necesario abstraer su función para hacerlo útil en distintos momentos de la ejecución del programa.

 

La Orientación a Objetos supuso un salto cualitativo enorme al consagrar la abstracción como una característica imprescindible para el diseño de los diagramas de clases, y para el diseño de las propias clases. Dejaba atrás el ámbito local de un programa y nos situaba en un plano más alto, común a distintas aplicaciones, que podían usar las mismas clases para resolver requisitos similares.

 

Ahora la Orientación a Servicios va un paso más allá y deja atrás el ámbito de los sistemas de información, para situarnos al nivel de la implementación de los estándares al nivel del negocio. En este nivel de abstracción es donde nos movemos al identificar, definir y diseñar los servicios de negocio. La tecnología y los mismos sistemas de información que usarán estos servicios quedan más abajo, y dejan de tener importancia para diseñar los servicios de negocio.

 

Este nivel de abstracción permite centrarnos exclusivamente en la especificación del servicio, sin incluir información tecnológica ni de ninguna otra naturaleza, más allá de la propia especificación estándar del servicio desde el punto de vista del negocio al que sirve, que queda recogida en su contrato.

Y esto es, justamente, lo que viene a indicar el enunciado de este principio.

 

Te puede interesar

0 comentarios

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