Ejemplo: Ejemplo de modelo de SOA

 Descripción del problema

 Ámbito del proyecto y objetivos
 Identificación de servicios
 Diseño de servicios
 Realización de servicios

Descripción del problema 

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 

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.

 Búsqueda de clientes: Se trata de un proceso en dos pasos desde el terminal en el

sentido de que hay una base de datos local en el almacén de clientes que ya ha
adquirido artículos del almacén o que ha dado servicio a los artículos en el almacén. Si
el cliente no se encuentra en la base de datos del almacén (se realiza una conexión
directa a la base de datos y se ejecuta una consulta SQL) entonces, la aplicación
empresarial consulta una base de datos de clientes central utilizando un enfoque de
cola de mensajes mediante un servidor de colas en el ISS. El nuevo servicio debe estar
situado en el ISS y actuar de punto único de comunicación desde la aplicación
empresarial; la aplicación establecerá comunicación con el ISS que a su vez consultará
la base de datos local antes de enviar la solicitud a otro servicio (implementando la
misma especificación de servicio) en el servidor central que consultará su base de
datos local.
 Planificación de servicio: En este caso un cliente desea planificar un servicio sobre
un elemento que ha adquirido; en la actualidad la aplicación empresarial tiene que
consultar la base de datos del cliente (véase más arriba), consultar la base de datos de
garantía central para ver si el elemento está en garantía y actualizar la planificación de
servicio con la fecha/hora en la que el cliente está pensando en recoger el elemento.
Parece que hay una forma mejor de resolver el problema y el nuevo servicio de
planificación funcionará de la manera siguiente. Dado que un elemento tiene un
 número de serie, la base de de datos de garantía puede consultarse; esta base de
datos ya contiene el ID de cliente de forma que los datos del cliente pueden extraerse
en cualquier momento. Si el cliente sólo dispone del ID de tipo de elemento, debemos
consultar el cliente y el elemento tal como hemos indicado anteriormente. Esto lo
realizará totalmente el servicio, eliminando la lógica de la aplicación empresarial.
 Comprobación de inventario: En este caso, existe un problema similar; el servicio
consulta primero en la base de datos de tiempo real el inventario y si se no se
encuentra un elemento, consulta la base de datos de la empresa que contiene menos
información sobre los productos pero contiene el inventario de todos los almacenes
(excepto que sólo se actualiza por lotes durante la noche y, por consiguiente, no está
garantizado. El nuevo servicio ISS agregará las consultas tal como se ha indicado
anteriormente, pero también proporcionará actualizaciones en tiempo real al servidor
central para pasar los sucesos de cambio de inventario al centro y permitir que las
consultas en otros almacenes sean más exactas. Esto implica que el servicio de
inventario en el centro tiene la posibilidad de recibir estos sucesos de cambio de
inventario y el servicio local no.

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

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.

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.

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 phonenum Lista de: Este procedimiento
almacenado (char 10) custid (id) almacenado devuelve
del servidor custname una lista de detalles del
SQL (char 40) 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 custid (id) Registro del Se devuelven los
almacenado cliente detalles de un cliente,
del servidor su nombre, dirección,
SQL información de
contacto, etc.
CUST_QUERY IBM MQSeries phonenum N/D En esta cola la
(char 10) aplicación coloca los
return-queue- detalles de los clientes
name (char que hay que consultar,
120) el mensaje se entrega
correlation-id en el centro donde el
(char 120) servidor publica el
mensaje de respuesta
a la cola de retorno
identificada.
<nombre-cola-retorno> IBM MQSeries N/D correlation-id Al devolver los
(char 120) registros del cliente el
Lista de mensaje de retorno
registro del también contiene el
cliente 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 sku (char 13) Registro del
almacenado inventario
del servidor
 SQL
INVENTORY_QUERY IBM MQSeries sku (char 13) N/D
return-queue-
name (char
120)
correlation-id
(char 120)
<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.

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

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

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.
Para obtener más información, consulte el concepto Diseño de mensajes.

Realización de servicios 
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.

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.
Para obtener más información, consulte la directriz Cómo pasar de servicios a componentes
de servicios.