Los principios de diseño SOA

Como primer  post, en este proceso de inmersión dentro del mundo de los sistemas distribuidos, considerando que es importante que conozcamos la Arquitectura Orientada a Servicios (SOA) la cual define y sirve como base para la creación y utilizaciónd e servicios para dar soporte a los requisitos del Negocio. Asimismo, nos permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios, lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

Dentro de esta arquitectura se pueden mencionar un conjunto de  8 principios los cuales pasamos a detallar a continuación:

1.- Contrato de Servicios Estandarizados

Cuando un servicio se implementa como un servicio web, se debe adherir (proporcionar) un contrato de comunicaciones explícitamente declarado y definido colectivamente por uno o más descriptores del servicio, en el cual debe figurar especificaciones como:

• Nombre del Servicio.
• Forma de accesos.
• Funcionalidades que ofrece.
• Descripción de los datos de entrada de cada funcionalidad que ofrece.
• Descripción de los datos de salida de cada funcionalidad que ofrece.

De este modo, todo consumidor de los servicios accederá mediante el contrato, logrando la independencia entre el consumidor y la implementación del propio servicio. Con esto se evita el manejo incorrecto de los datos, se evita trabajo innecesario en la invocación entre estos servicios y también se pone de manifiesto que la existencia de un modelo de datos a nivel de servicio es una de las primeras necesidades que se debe tener en cuenta.

Service Contract

2.- Bajo Acoplamiento:

Este principio hace referencia a que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.

Service Loose Coupling

3.- Abstracción:

El principio de abstracción permite encapsular el servicio y reducir el acoplamiento. El servicio debe ser una caja negra, únicamente definido por su contrato, que a su vez es el mínimo acoplamiento posible con el consumidor del mismo.

El uso de estándares permite definir interfaces uniformes que esconden la lógica del servicio respecto del entorno que le rodea (sistemas proveedores y consumidores)

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.

Service Abstraction

4.- Reusabilidad:

La reutilización es el principal principio de la arquitectura SOA, cada servicio debe ser analizado, diseñado y construido de manera que su uso pueda serexplotado al máximo, es decir, cada servicio debe ser de algún modo genéricocon el fin de que pueda usarse en diferentes contextos y satisfacer distintosobjetivos. De esta manera, los servicios podrán ser reusables dentro de lamisma aplicación, dentro del dominio de aplicaciones de la empresa o inclusodentro del dominio público para su uso masivo.

Por otro lado, estos servicios reutilizables deben estar diseñados de maneratal que su solución lógica sea independiente de cualquier proceso de negocio otecnología en particular.

Con este principio se busca reducir las posibilidades de duplicación de lógica.Si un servicio que ya existe en un contexto funcional se ajusta a la nuevalógica reutilizable, en lugar de crear un nuevo servicio, dicha lógica debeformar parte del servicio existente.

Service Reusability

5.- Autonomía:

Este principio nos dice que todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.

Service Autonomy

6.- No estado:

Un servicio no debe guardar ningún tipo de información. El tratamiento de una gran información de estado afectaría gravemente a la escalabilidad del servicio, poniendo en riesgo su disponibilidad. Idealmente, todos los datos que necesita el servicio para trabajar deben provenir directamente de los parámetros de entrada.

Service Statelessness

7.- Descubrimiento:

Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.

Service Discoverability

8.- Composición:

Este principio nos dice que todo servicio debe estar construido de tal manera que pueda ser utilizado para construir servicios genéricos de mayor complejidad, el cual estará compuesto de servicios de menor nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).

El concepto de desarrollo de software a partir de componentes existentes independientemente fomenta el concepto de composición. Por ello el concepto de composición es heredado por la orientación a servicios, por lo que un proceso de negocio está automatizado mediante la combinación de múltiples servicios. Sin embargo, dentro de la orientación a servicios es mayor el enfoque en la creación de servicios que se pueden componer y recomponer dentro de múltiples soluciones para proporcionar la agilidad prometida por la SOA. Como resultado de este énfasis, algunas pautas son requeridas para el desarrollo de servicios que pueden ser efectivamente agregados en varias soluciones.

Service Composability

Estos son en resumen los principios del diseño SOA. A partir del próximo post empezaremos a armar una solución en .NET (C#) esperando aplicar todos los conceptos hasta aquí mencionados.

Conclusión

No es preciso definir cuál es la mejor opción para orquestar arquitecturas SOA. En ese proceso intervienen muchos factores como requerimientos funcionales y no funcionales, presupuesto, experiencia de desarrollo, etc. Lo importante es saber identificar cuando usar cual y como usarlos para poder crear una arquitectura escalable, de alta disponibilidad y que conserve siempre la estructura SOA. Ello garantizará el éxito de una integración empresarial.

Referencias:

http://www.soapatterns.org/patterns_principles.php

http://arquitecturaorientadaaservicios.blogspot.com/2006/06/principios-de-la-orientacin-servicios.html

http://info-soa.blogspot.com/2010/09/principios-de-una-arquitectura.html

http://www.ibm.com/developerworks/library/ws-soaintro.html

http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s