Cómo reconocer la verdadera cara de la arquitectura orientada a servicios SOA

En la teoría clásica de la ingeniería de software, ya sea el método en cascada o el método prototipo, todos parten del análisis de la demanda y construyen varios sistemas de software paso a paso. Sin embargo, los cambios en la demanda son como una sombra persistente que siempre acompaña al sistema. Todo desarrollador de sistemas de aplicaciones prácticas ha experimentado el dolor extremo de encontrar cambios abrumadores en la demanda cuando el sistema ingresa a la etapa de desarrollo, prueba o incluso a la etapa en línea. Que los clientes traten los requisitos modificados como errores (errores) es el principal problema en la fase de prueba y lanzamiento. ¿Cómo resolver este problema? ¿Puede haber una revolución en el desarrollo y la arquitectura de software? La propuesta de la arquitectura SOA se considera una revolución. La esencia es separar el modelo del sistema de la implementación del sistema. 1. Definición SOA no es un concepto nuevo. Algunas personas consideran que los modelos de componentes como CORBA y DCOM son los predecesores de la arquitectura SOA. Ya en 1996, Gartner Group ya había presentado la predicción de SOA, pero en ese momento era sólo una "profecía". El nivel de desarrollo de software e informatización en ese momento no era suficiente para respaldar dicho concepto en una aplicación sustantiva. escenario. En los últimos dos años, los métodos de implementación técnica de SOA han madurado gradualmente. Con la fuerte promoción de gigantes del software como BEA e IBM, poco a poco se ha vuelto popular. La visión objetivo descrita por Gartner para SOA es lograr una empresa en tiempo real (Real-Time Enterprise). En cuanto a SOA, actualmente no existe una definición unificada y aceptada en toda la industria. En general, se cree que: SOA, la arquitectura orientada a servicios es un modelo de componentes que conecta diferentes unidades funcionales de una aplicación: servicios (servicios) a través de interfaces bien definidas y contratos entre servicios. La interfaz se define de forma neutral, independiente de la plataforma de hardware, el sistema operativo y el lenguaje de programación que implementa específicamente el servicio, de modo que los servicios integrados en dicho sistema puedan comunicarse de forma unificada y estándar. Esta característica de tener definiciones de interfaz neutrales (sin vinculación forzada a una implementación específica) se denomina acoplamiento flexible entre servicios. De esta definición, vemos los siguientes dos puntos: ·Arquitectura de sistema de software: SOA no es un lenguaje, ni una tecnología específica, ni un producto, sino una arquitectura de sistema de software, que intenta proporcionar una arquitectura recomendada en un entorno específico. Desde esta perspectiva, en realidad se parece más a un patrón arquitectónico (Pattern), una arquitectura conceptual y un marco de solución para los servicios de aplicaciones de las personas. ·El servicio es el núcleo de toda la implementación SOA. El elemento básico de la arquitectura SOA es el servicio. SOA especifica un conjunto de entidades (proveedor de servicios, consumidor de servicios, registro de servicios, términos de servicio, agente de servicios y contrato de servicios) que especifican cómo proporcionar y consumir servicios. Un sistema que sigue la perspectiva SOA debe tener servicios que sean interoperables, independientes, modulares, bien ubicados, débilmente acoplados y cuya dirección se pueda encontrar a través de la red. 2. La relación entre las tres funciones de SOA. Un servicio es una entidad autónoma y sin estado que puede estar compuesta por varios componentes. Responde a las solicitudes de servicio a través de una interfaz predefinida. También puede realizar tareas discretas como editar y procesar transacciones. El servicio en sí no depende del estado de otras funciones y procedimientos. La tecnología utilizada para implementar el servicio no está limitada en su definición. Los proveedores de servicios brindan servicios que se ajustan al contrato y los publican a los corredores de servicios. El consumidor de servicios (consumidor de servicios), también llamado usuario de servicios, descubre y llama a otros servicios de software para brindar soluciones comerciales. Conceptualmente, SOA esencialmente deja los detalles de las redes, los protocolos de transporte y la seguridad a la implementación específica. Un solicitante de servicios suele denominarse cliente, pero también puede ser una aplicación de usuario final u otro servicio.

Un corredor de servicios actúa como repositorio, páginas amarillas o cámara de compensación para generar interfaces de software publicadas por los proveedores de servicios. Estos tres tipos de participantes SOA: proveedores de servicios, intermediarios de servicios y solicitantes de servicios interactúan a través de tres operaciones básicas: publicar, buscar y vincular. Los proveedores de servicios publican servicios para corredores de servicios. Los solicitantes de servicios encuentran los servicios requeridos a través de intermediarios de servicios y se vinculan a estos servicios. Es posible la interacción entre proveedores de servicios y solicitantes de servicios. El llamado servicio sin estado significa que el servicio no depende de condiciones preestablecidas y no tiene estado. En la arquitectura SOA, un servicio no depende del estado de otros servicios. Aceptan solicitudes de servicio de los clientes. Debido a que los servicios no tienen estado, se pueden orquestar y secuenciar en múltiples secuencias (a veces utilizando un mecanismo de canalización) para ejecutar la lógica empresarial. La orquestación se refiere a serializar servicios y proporcionar lógica de procesamiento de datos. Pero no incluye la función de visualización de datos. 3.Características de SOA Con base en la discusión anterior, damos las siguientes características de SOA: · Encapsulación de servicios (encapsulation). Funciones de aplicación que encapsulan servicios en componentes reutilizables para procesos de negocio. Proporciona información o simplifica la transición de datos comerciales de un estado válido y consistente a otro. La encapsulación oculta la complejidad. La API del servicio permanece sin cambios, aislando a los usuarios de cambios en la implementación. ·Reutilización de servicios. El diseño reutilizable de los servicios reduce significativamente los costes. Para lograr la reutilización, los servicios solo funcionan en el contexto de un proceso específico, independientemente de los cambios en la implementación subyacente y los requisitos del cliente. ·Interoperabilidad de servicios. La interoperabilidad no es un concepto nuevo. La tecnología de interoperabilidad ya se ha utilizado en CORBA, DCOM y servicios web. En SOA, los servicios interoperan a través de protocolos de comunicación establecidos. Hay dos mecanismos de comunicación principales: sincrónicos y asincrónicos. Las características de interoperabilidad de los servicios proporcionados por SOA facilitan su reutilización en múltiples ocasiones. ·Los servicios son entidades funcionales autónomas (Autónomas). Los servicios están compuestos por módulos de componentes autónomos y modulares. SOA pone gran énfasis en la total independencia de las entidades funcionales que brindan servicios en la arquitectura. Tecnologías de componentes tradicionales como. NET Remoting, EJB, COM o CORBA requieren un host (Host o Servidor) para almacenar y administrar estas entidades funcionales cuando el host finaliza, la vida útil de estos componentes también finaliza; De esta manera, cuando hay un problema con el propio host u otras partes funcionales, otros servicios de aplicaciones que se ejecutan en el host se verán afectados. La arquitectura SOA pone gran énfasis en las capacidades de recuperación y autogestión de las entidades. Las tecnologías comunes utilizadas para la autorrecuperación, como el procesamiento de transacciones (Transaction), la cola de mensajes (Message Queue), la implementación redundante (Redundant Deployment) y el sistema de clúster (Cluster), desempeñan un papel vital en SOA. ·Acoplamiento flexible entre servicios. La vinculación entre el solicitante del servicio y el proveedor del servicio debe estar ligeramente acoplada al servicio. Esto significa que el solicitante del servicio no conoce los detalles técnicos de la implementación del proveedor, como el lenguaje de programación, la plataforma de implementación, etc. Los solicitantes de servicios tienden a invocar operaciones a través de mensajes, solicitando mensajes y respuestas, en lugar de utilizar API y formatos de archivo. Este acoplamiento flexible permite que el software en un extremo de una conversación cambie sin afectar al otro extremo, siempre que el patrón de mensajería siga siendo el mismo. En un caso extremo, el proveedor de servicios puede reemplazar completamente la implementación anterior basada en código heredado (por ejemplo, COBOL) con código nuevo basado en el lenguaje Java sin ningún impacto en el solicitante del servicio.

Esto es cierto siempre que el nuevo código admita el mismo protocolo de comunicación. ·El servicio es transparente en cuanto a ubicación. Los servicios están diseñados para las necesidades empresariales. Necesita responder a los cambios en los requisitos, lo que constituye el llamado diseño ágil. Para realizar verdaderamente la separación de negocios y servicios. Es necesario hacer que el diseño y despliegue de los servicios sea completamente transparente para los usuarios. En otras palabras, los usuarios no necesitan saber la ubicación del servicio que responde a sus necesidades, ni siquiera qué servicio participa en la respuesta. 4. Tres niveles de abstracción Conceptualmente, existen tres niveles principales de abstracción en SOA: · Operación: representa una transacción de una única unidad lógica de trabajo (LUW). La realización de operaciones normalmente da como resultado la lectura, escritura o modificación de uno o más datos persistentes. Las operaciones SOA se pueden comparar directamente con los enfoques orientados a objetos (OO). Todos tienen interfaces estructuradas específicas y devuelven respuestas estructuradas. Al igual que los métodos, la ejecución de una operación específica puede implicar la llamada de operaciones adicionales. ·Servicio: Representa una agrupación lógica de operaciones. Los servicios se pueden estratificar para reducir el acoplamiento y la complejidad. El tamaño de granularidad de un servicio también está estrechamente relacionado con el rendimiento del sistema. Si la granularidad es demasiado pequeña, aumentará la sobrecarga de la comunicación interoperable entre servicios; si la granularidad es demasiado grande, afectará la agilidad del servicio para enfrentar los cambios en la demanda. ·Proceso de negocio: Conjunto de acciones o actividades de larga duración realizadas para lograr un objetivo de negocio específico. Los procesos comerciales suelen incluir múltiples llamadas comerciales. En SOA, un proceso de negocio consta de una serie de operaciones realizadas en una secuencia ordenada basada en un conjunto de reglas de negocio. La secuenciación, selección y ejecución de operaciones se denomina orquestación de servicios u procesos. Normalmente, los servicios orquestados se llaman en respuesta a eventos comerciales. Desde el punto de vista del modelado, el desafío resultante es cómo caracterizar abstracciones operativas, de servicios y de procesos bien diseñadas y cómo construirlas sistemáticamente. Estas cuestiones relacionadas con el modelado de servicios y la extracción de características se han convertido en el centro de atención en esta etapa.