IMPORTANCIA DE SOA - DESCRIPCION Y EJEMPLO DE 5 PRINCIPIOS SOA

IMPORTANCIA DE SOA

DESCRIPCION Y EJEMPLO DE 5 PRINCIPIOS SOA

1.            SERVICIOS DE BAJO ACOPLAMIENTO:

Hace referencia al nivel de dependencia entre servicios, entre el proveedor y el consumidor. Cuanto menos acoplamiento se logra una mayor independencia para el diseño del servicio y su posterior evolución

Considero que este es el que más se aplica a mi organización y a la forma en que trabajo, esto debido a que independiza a cada Servicio y da libertad para la implementación de cada uno o nuevos servicios.

Ejemplo de su uso:

Una Empresa administra la carga a exportar o importar de nuestros clientes. Al ser estos procesos distintos y con requerimientos independientes por parte de Aduanas, considero necesario contar con dicha independencia. Por ejemplo, las transmisiones de las Importaciones tienen un límite de tiempo, 430 horas, al arribo de la nave y en Exportaciones el tiempo es mayor y varia del destino. Así mismo, un Consignatario en exportaciones no es de gran importancia para Aduanas, sin embargo, en la importación es el principal a manifestar.

2.            REUSABILIDAD DE LOS SERVICIOS

Cada servicio debe ser pensado de modo que se pueda explotar al máximo su uso, es decir, que sea de algún modo genérico con el fin de que pueda ser usado en diferentes contextos y satisfacer distintos objetivos, este es el caso de los procesos de negocio donde cada uno de estos puede tener un propósito totalmente distinto del otro y aun así estar usando un mismo servicio.

Uno de los beneficios más evidentes de la orientación a servicios es este. La reusabilidad forma parte de la historia del desarrollo del software desde sus inicios, aunque a distintas escalas.

Este principio indica tres matices importantes:

1.       La lógica a incluir en este servicio debe ser la inherente a dicha entidad, despojada de ninguna lógica heredada de ningún sistema de información; si la hubiera podemos decir que estaríamos contaminando el servicio, e introduciendo un cierto grado de acoplamiento.

2.       Los servicios incluyen lógica explícita. Es importante que la lógica sea explícitamente inherente a la entidad protagonista del servicio, sin ambigüedades.

3.       Los servicios deben poder ofrecerse como recursos empresariales reutilizables. Se trata de incorporar al proceso de concepción, diseño, construcción y pruebas de piezas de software los mismos principios que rigen el proceso de concepción, diseño, fabricación y pruebas de piezas de cualquier sector industrial.

Ejemplo de Uso

Un Servicio de consulta de datos de un estudiante, podría estar implementado por un componente Java. Estos datos deben estar ubicados en algún sistema y será accedido a través del conector apropiado.  Los EJB (Enterprise Java Beans) exponen su funcionalidad a través de métodos java invocables remotamente desde distintos servidores de la red a través del protocolo estándar RMI (Remote Method Invocation).  Eventualmente otras aplicaciones como matrícula o pagos podrán hacer uso de esta interface, invocando a las funciones de esta componente a través de RMI y sabiendo que el servicio cumplirá para cada uno de ellos con un “Contrato” específico.

3.            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.

Ejemplo de Uso

Una aplicación donde se registre la asistencia diaria la cual mediante un web service se actualice en el sistema de planilla, usando algunas funcionalidades para otros servicios que involucren al personal.

4.            Autonomía

Este principio hace referencia al concepto de servicios débilmente acoplado que puede diseñarse y ser desplegados independientemente del resto de servicios, pero que a su vez sean capaces de comunicarse con otros a través de contratos y políticas.

Ejemplo de Uso

Lograr tener un conjunto de servicios estándar, orientados por eventos de negocio, orquestados por las reglas de negocio, y que puedan ser autónomos y al mismo tiempo componer entre sí servicios de mayor orden, nos proporciona una tremenda potencia y flexibilidad a la hora de maximizar el impacto y el beneficio de toda la estrategia SOA. Es como tener una caja de piezas de lego de distintas formas y colores. Es mucho mejor que tener piezas grandes, ensambladas de forma específica para alguna necesidad concreta. Reduciría nuestra capacidad de reutilizar esa pieza, para empezar

5.            Abstracción de Servicios

Este principio llamado ABSTRACCION está muy relacionado 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.

Los 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. En otras palabras, ocultar lo que hace el sistema. No hace notar la lógica interna algo así como una CAJA NEGRA. 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.

Ejemplo de Uso

En una fábrica de pinturas textiles para estampado, para crear tintes se necesita de toda una "formula" que es "secreta para la organización", pero necesita para fabricarse toda una lógica de negocios(considerando almacén, demanda, calidad de agua, cliente) y logística que genera gastos que deben ser manejados por algunas personas. Basado en el principio de abstracción que 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. Es decir que solo se invoque el servicio que llamaremos "Obtener_Costos_Insumos_fabricacion_Service" y solo le diremos cuanto producto necesitamos. El servicio por si solo nos devolverá la lista y precios de esta (sin que el cliente se entere de todos los "trabajos" que hizo este determinado servicio para dar sus resultados)