Ejemplo: Ejemplo de modelo de SOA

Descripción del problema Ir a la parte superior de la página

En este ejemplo contemplamos los problemas de un minorista que ha elegido reimplementar determinadas funciones utilizadas por las aplicaciones en sus terminales de punto de venta (PoS) como servicios. En la actualidad la aplicación empresarial se desarrolla como aplicación monolítica con componentes estrechamente acoplados pero con algunos componentes residiendo en los servidores en el almacén (ISS) y algunas solicitudes incluso se envían mediante el ISS a servidores situados de forma centralizada en la empresa. La cuestión es que la infraestructura del almacén en general y la aplicación empresarial en particular pueden ser difíciles de mantener debido al estrecho acoplamiento de los componentes y al uso de protocolos propietarios y de la tecnología en el desarrollo de los componentes y la conexión entre ellos.

En generaciones anteriores de sistemas de almacenamiento se utilizaban máquinas propietarias y de baja capacidad para los terminales PoS y había restricciones sobre el ancho de banda en el almacén así como fuera del almacén; ahora estas restricciones ya no existen. Teniendo esto en cuenta y la tendencia actual a la arquitectura orientada a los servicios dentro de los sistemas de fondo de la empresa, se ha decidido que algunas de las funciones suministradas por los ISS y los servidores centrales deben exponerse a la aplicación empresarial como servicios.

Ámbito del proyecto y objetivos Ir a la parte superior de la página

Inicialmente las funciones que hay que contemplar se han elegido porque comparten un patrón común en el sentido de que requieren actualmente lógica en las aplicaciones empresariales para consultar información en más de un almacén de datos. Por ello, los servicios propuestos no sólo proporcionan una interfaz común sino que también dividen la aplicación empresarial del conocimiento explícito de la ubicación de los datos y de tener que tratar con múltiples protocolos. Estos servicios se accederán a través de RMI desde la aplicación empresarial al servicio ISS y utilizando SOAP a través de JMS desde el ISS al servicio central.

Identificación de servicios Ir a la parte superior de la página

A continuación se resaltan los pasos seguidos por el equipo de arquitectos que consta de miembros de la propia organización de TI de los minoristas y de consultores externos que están en calidad de expertos en el desarrollo de soluciones orientadas a servicios. Observe que los pasos siguientes no pretenden representar una serie de actividades de RUP recomendadas, simplemente catalogan las actividades de un proyecto real.

Es importante destacar que este proyecto es para mejorar la implementación técnica de las funciones actualmente existentes y, por lo tanto, no incluye todo el tiempo invertido en el modelado o análisis empresarial, dado que podemos reutilizar los modelos creados para la aplicación empresarial original. El conjunto actual de modelos (a la izquierda del diagrama que se muestra a continuación) sigue la estructura que se indica debajo, que muestra un modelo de casos de uso de RUP, un modelo de análisis para los componentes comunes de la aplicación empresarial, seguido del modelo de diseño detallado y finalmente un conjunto de modelos de implementación para los equipos de desarrollo de Java.

El diagrama se describe en el contenido textual.

Se ha introducido el modelo de servicio (a la derecha del diagrama inferior) como un perfeccionamiento del modelo de análisis en un conjunto de servicios con sus propios modelos de implementación. El diseño de la aplicación empresarial puede ahora modificarse para mostrar el uso de estos servicios comunes y también aparece la relación entre la aplicación empresarial y los modelos Java de servicio.

Creación del modelo de servicio

El modelo de servicio de soporte de almacén se creó según el perfil de UML para servicios de software y un modelo de plantilla (incluido en Rational Software Architect), tal como se ha descrito en el diagrama siguiente. El modelo se ha identificado como un perfeccionamiento del modelo de análisis, tal como se ha mostrado anteriormente. Tal como se puede ver, la estructura se presenta en un diagrama de visión general que muestra las dependencias entre las vistas recomendadas por la plantilla.

El diagrama se describe en el contexto textual.

Los enlaces del diagrama junto a los paquetes de vista permiten una rápida navegación del modelo y se completarán en los apartados siguientes.

Para obtener más información consulte la guía de la herramienta Creación de un modelo de servicio en RSA.

Identificar particiones del servicio (localidad)

Se desprende claramente de la descripción del problema anterior que existe una serie de formas para poder examinar el particionamiento del sistema, por ejemplo podemos introducir particiones que representan la gestión de inventarios, la gestión del servicio/garantía, operaciones de punto de venta (búsqueda de precios, clientes, etc.) No obstante, hay preocupaciones básicas para el arquitecto y, por consiguiente, las particiones añadidas al modelo representan localidades lógicas para los servicios suministrados en el almacén o en el ámbito empresarial.

El diagrama se describe en el contenido contextual.

Cuando indicamos que se trata de particiones lógicas, estamos identificando que la partición Servicios de almacén contiene un conjunto de servicios de los que se crean instancias en el nivel de almacén y no decimos nada sobre el despliegue físico de estos servicios (servidor único, clúster, etc.). Estas particiones lógicas se proporcionan para que el arquitecto represente los aspectos significativos de la solución.

También cabe destacar que en la imagen superior el arquitecto ha introducido un elemento adicional, la propia aplicación empresarial, para permitir descripciones de comunicación entre la aplicación y los servicios. La aplicación empresarial es un componente de UML 2.0 con el estereotipo Consumidor de servicio.

Para obtener más información, consulte el concepto Particionamiento de soluciones.

Analizar funciones existentes

El paso siguiente es analizar la implementación actual de la aplicación empresarial, para examinar los detalles del acceso a la base de datos identificado en la sentencia del problema superior. A continuación, se ha desarrollado la tabla siguiente (observe que sólo contiene detalles para las búsquedas de clientes y de inventario).
 
Nombre Tecnología Entradas Salidas Comentarios
sp_get_custlist_by_phone Procedimiento almacenado del servidor SQL phonenum (char 10) Lista de:
custid (id)
custname (char 40)
Este procedimiento almacenado devuelve una lista de detalles del cliente por número de teléfono; la lista puede presentarse al cliente para su selección. La llamada sp_get_cust_details se utiliza para devolver un registro único del cliente.
sp_get_cust_details Procedimiento almacenado del servidor SQL custid (id) Registro del cliente Se devuelven los detalles de un cliente, su nombre, dirección, información de contacto, etc.
CUST_QUERY IBM MQSeries phonenum (char 10)
return-queue-name (char 120)
correlation-id (char 120)
N/D En esta cola la aplicación coloca los detalles de los clientes que hay que consultar, el mensaje se entrega en el centro donde el servidor publica el mensaje de respuesta a la cola de retorno identificada.
<nombre-cola-retorno> IBM MQSeries N/D correlation-id (char 120)
Lista de registro del cliente
Al devolver los registros del cliente el mensaje de retorno también contiene el correlation-id para garantizar que la respuesta se puede asociar con una solicitud determinada. Esto permite que el servidor en el almacén tenga una sola cola de retorno para todos los terminales, el terminal consulta en la cola un mensaje de respuesta con su ID de correlación.
sp_get_invstate_for_sku Procedimiento almacenado del servidor SQL sku (char 13) Registro del inventario
INVENTORY_QUERY IBM MQSeries sku (char 13)
return-queue-name (char 120)
correlation-id (char 120)
N/D
<nombre-cola-retorno> IBM MQSeries N/D Registro del inventario

Como se puede ver, estas entradas representan la implementación existente, que se sustituirá por una nueva implementación, pero se mantendrán el propósito y la función.

Desarrollo de la especificación de servicio inicial

La actividad Identificación de servicios introduce una serie de técnicas para identificar los servicios y las operaciones sobre los servicios, solicitadas para dar soporte a una solución. En el caso de este ejemplo, estamos observando una forma de renovación heredada, la formación de la funcionalidad existente en un modelo de servicios y específicamente la tecnología de implementación de servicios. Al hacerlo, el primer aspecto es desarrollar el conjunto de Especificaciones de servicios que proporcionarán los contratos para los servicios que implementan las funciones descritas anteriormente. El diagrama siguiente muestra las tres, actualmente vacías, especificaciones de servicios creadas en esta fase, una para cada uno de los servicios que se han tratado en la introducción.

El diagrama se describe en el contenido textual.

A continuación, analizaremos los posibles patrones de uso para los servicios; por ejemplo podríamos en realidad tener dos servicios, uno en el almacén y uno en la empresa, donde la lógica para el acceso a la base de datos y el acceso a la empresa estén ambos encapsulados en el servicio en el almacén. O bien, se puede elegir tener un servicio de fachada en el almacén que encapsule la lógica y llame a dos servicios idénticos, uno que encapsule el acceso a la base de datos local y el segundo en el nivel de la empresa. La segunda opción añade flexibilidad en el cambio de la lógica para acceder a los dos almacenes, pero añade costes de sobrecarga y de comunicación para una función relativamente simple. De este modo, para la búsqueda de clientes y la búsqueda de inventario, se ha elegido la primera opción. Como todavía no se han decidido los detalles de la distribución de servicios y los proveedores de servicios, la identificación de servicio es mucho más eficaz si se centra solamente en especificaciones de servicios.

Para identificar los roles y responsabilidades de estos servicios, utilizamos una Colaboración de servicio y en particular un diagrama de estructura compuesta de UML 2.0 que representa la configuración de los servicios para la búsqueda de clientes. El diagrama de estructura se muestra a continuación y podemos ver partes de UML 2.0 que representan cada elemento en la colaboración. Observe que los conectores entre la aplicación empresarial y el servicio en el almacén y entre los servicios en el almacén y en la empresa están estereotipados como Canal de servicio y destacan los enlaces que hay que utilizar (RMI o JMS tal como se ha identificado anteriormente). El enlace para el conector entre el servicio en el almacén y el componente de la base de datos local (más adelante) no está definido.

El diagrama se describe en el contenido textual.

Un elemento clave que hay que resaltar es que el LocalCustomerLookupProvider es un servicio generado, es un servicio de derivador fino en torno a una consulta de base de datos, hay una sola operación que representa una selección SQL. Este enfoque se ha elegido a través del acceso directo a la base de datos mediante el servicio de búsqueda de clientes en el almacén para permitir que el servicio local incluya reglas empresariales adicionales o incluso se convierta en un servicio más completo en una fecha posterior.

No obstante, este diagrama sólo muestra la estructura de la colaboración, el siguiente diagrama de interacción (Diagrama de secuencia de UML 2.0) representa las comunicaciones reales entre los servicios. Observe que hemos añadido la operación getCustomerByPhone a la especificación de servicio. También observe que UML 2.0 permite la especificación de un "fragmento" opcional de un diagrama de secuencia, en este caso para indicar que sólo establecemos comunicación con el servicio empresarial si la búsqueda local no se realiza correctamente.

El diagrama se describe en el contexto textual.

La combinación de diagramas de estructura estática y de comunicación nos permite documentar la composición de servicios y la colaboración y tener en este caso sólo identificada la necesidad de una sola operación en la especificación de servicio.

Para obtener más información, consulte la actividad Identificación de servicios.

Diseño de servicios Ir a la parte superior de la página

Tomando el modelo de la actividad Identificación de servicios, pasamos la identificación de un conjunto de servicios candidatos al diseño detallado de los servicios que pretendemos crear. El primer paso consiste en correlacionar las especificaciones de servicios que realizan las especificaciones anteriores; como se puede imaginar, hay que adoptar decisiones sobre cómo los servicios llevan a cabo las especificaciones de servicios del modelo anterior. En este ejemplo, tenemos una estructura relativamente simple, pero que probablemente será común a muchos proyectos. En este caso, tenemos un único Proveedor de servicios que presenta un único servicio que es la realización de una única especificación. Es ciertamente posible tener más de un servicio por proveedor. También observamos ciertas relaciones de uso entre los servicios en este modelo; estas dependencias son importantes para comprender cómo pueden evolucionar los servicios con el tiempo.

El diagrama se describe en el contenido textual.

Esta estructura nos permite ahora movernos más en el espacio de distribución, mientras el modelo sigue siendo una vista lógica de los servicios, ya que los proveedores de servicios representan las unidades de despliegue para el modelo de servicio. Los proveedores de servicios también son necesarios para la definición de servicios compuestos dado que un servicio propio (un puerto de UML 2.0) no puede tener la estructura necesaria para describir la composición.

Diseño de mensajes

No hemos señalado nada anteriormente, en la actividad de identificación del servicio, sobre los mensajes reales intercambiados entre las operaciones descritas sobre las especificaciones de servicios. Este enfoque puede ser bastante común para capturar las responsabilidades de los servicios en cuanto a operaciones que retrasan el diseño detallado de los mensajes para más adelante; en algunos casos este enfoque es el inverso, las estructuras de mensajes se conocen con antelación y a continuación se agregan a un conjunto de operaciones.

En este caso, podemos aprovechar un modelo de dominio desarrollado como parte del modelo de análisis de componentes (activo desarrollado anteriormente) y, de esta forma, nuestro modelo de mensaje no se crea a partir de nada sino que identifica un subconjunto del modelo de dominio que se va a reutilizar. El ejemplo siguiente muestra esta relación, las clases de dominios ignoran por completo la tecnología y la plataforma; por otra parte, se supone que nuestros mensajes son objetos de transferencia de datos, estructuras transferidas entre servicios. Por consiguiente, en lugar de cambiar el modelo de dominio, creamos los mensajes "fuera" de la estructura de clase, compuesta de elementos en el interior.

El diagrama se describe en el contenido textual.

Para obtener más información, consulte el concepto Diseño de mensajes.

Realización de servicios Ir a la parte superior de la página

En este caso, nos centraremos en la realización del servicio de búsqueda de clientes en el almacén; este servicio es habitual en la transformación del modelo de servicio al modelo de diseño. La propia transformación está documentada en una directriz y el resultado es la estructura de modelo siguiente.

El diagrama está descrito en el contenido textual.

Mientras esto sigue siendo un modelo de diseño podemos, mediante herramientas, transformar este modelo todavía más en la implementación EJB que se indica a continuación. Básicamente, esta implementación se transforma de la clase CustomerByPhone anterior y los mensajes que detallan el cliente se transforman en el bean de entidades que se utiliza para consultar la base de datos.

El diagrama se describe en el contenido textual.

Para obtener más información, consulte la directriz Cómo pasar de servicios a componentes de servicios.