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.
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.
Para obtener más información consulte la guía de la herramienta Creación de un modelo de servicio en RSA.
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.Nombre | Tecnología | Entradas | Salidas | Comentarios |
---|---|---|---|---|
sp_get_custlist_by_phone | Procedimiento almacenado del servidor SQL | phonenum (char 10) | Lista de:
custid (id) |
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 |
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.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.
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.
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.