cis1530ap04 arquitectura para observatorio nacional...
TRANSCRIPT
Memoria de Trabajo de Grado – Aplicación práctica.
Página 1
CIS1530AP04
Arquitectura para Observatorio Nacional de Oferta y disponibilidad de productos farmacéuticos.
Software Architecture Document - SAD.
Renzo David Rojas Silva.
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS BOGOTÁ, D.C.
2015
Memoria de Trabajo de Grado – Aplicación práctica.
Página 2
Contenido 1. Introducción. .......................................................................................................... 3
2. Definir entradas. .................................................................................................... 4
3. Creación de vistas. ................................................................................................. 6
3.2.1 Componentes específicos para el Observatorio. ................................... 16
4. Vista de Datos. .................................................................................................... 28
5. Verificación de la Arquitectura. .......................................................................... 29
6. Bibliografía. ........................................................................................................ 29
Memoria de Trabajo de Grado – Aplicación práctica.
Página 3
1. Introducción.
El siguiente documento tiene como fin crear la arquitectura del Observatorio que soporte los
requerimientos funcionas y no funcionales detectados en los documentos “Memoria-Renzo” y
“EspecificacionReq”.
Para el diseño de la arquitectura y procesos que soportan los requerimientos funcionales y no
funcionales detectados en la etapa de análisis, se procedió con lo planteado por Bass [1], usando
una metodología de Diseño Dirigido por Atributos (Attribute-Driven Design):
Para el levantamiento de información que permitió la obtención de lo expuesto en este
documento se procedió a tomar como base la metodología propuesta por Loucopoulos [1],
quien plantea un proceso expuesto en la siguiente figura:
Ilustración 1 Proceso diseño de arquitectura, Bass [1].
El anterior diagrama muestra el conjunto de actividades planteada por Bass [1] realizadas para
el diseño de la arquitectura del Observatorio. El proceso fue iterativo y se repitió siempre que
se detectó un sub componente del sistema general.
Definir entradas
•Especificación casos de uso
•Escenarios Requerimientos no funcionales.
•Requerimientos Arquitecturalmente Significantes.
Descomponer
•Del sistema general descomponer en sub sistemas.
Refinar
•Asociar sub sistemas con funcionalidades.
•Refinar funcionalidades y escenarios si es necesario.
Creación de vistas.
•Lógica.
•De componentes.
•De despliegue.
Verificación
•Evaluación de la arquitectura propuesta.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 4
El siguiente documento presenta los resultados obtenidos para el proceso de creación de la
arquitectura para el Observatorio.
2. Definir entradas.
Como se muestra en la ilustración 1, el primer paso para la creación de la arquitectura fue la
elección de entradas que permitieran el diseño de la misma.
Para este paso ya se cuenta con un una especificación de casos de uso encontrada en el
documento “EspecificacionReq”, junto con el planteamiento y descripción de los atributos de
calidad y escenarios para estos.
Posteriormente se escogieron los requerimientos arquitecturalmente significativos teniendo
en cuenta lo siguiente:
Complejidad de desarrollo: se calculó teniendo en cuenta el número de pasos
necesarios para ejecutar el caso de uso que se encuentra descrito en el flujo dentro de
la especificación del SRS. Se tomó como base el caso de uso más extenso (13 pasos
dentro del flujo) y a partir de este se definió la siguiente clasificación:
o COMPLEJIDAD ALTA: [9-13] pasos dentro del flujo.
o COMPLEJIDAD MEDIA: [5-8] pasos dentro del flujo.
o COMPLEJIDAD BAJA: [0-4] pasos dentro del flujo.
Numero de dependencias: se calculó teniendo en cuenta el número de dependencias
que tiene un caso de uso con otros. Se hizo en base a la descripción de casos de uso del
SRS, que permitió obtener el caso de uso con mayor número de dependencias ( 5
dependencias ) y a partir de este se definió la siguiente clasificación:
o COMPLEJIDAD ALTA: [4-5] dependencias.
o COMPLEJIDAD MEDIA: [1-3] dependencias.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 5
o COMPLEJIDAD BAJA: 0 dependencias.
Componentes involucrados: se calculó teniendo en cuenta cuantos componentes
distintos están involucrados en el flujo dentro de la especificación del caso de uso. Se
tomó como base el caso de uso que más componentes tenía involucrados (5 llamados)
y a partir de este se definió la siguiente clasificación:
o COMPLEJIDAD ALTA: [4-5] pasos dentro del flujo.
o COMPLEJIDAD MEDIA: [2-3] pasos dentro del flujo.
o COMPLEJIDAD BAJA: 1 paso dentro del flujo.
Teniendo en cuenta la clasificación anterior se tomaron los siguientes casos de uso
arquitecturalmente significativos:
CÓDIGO CU NOMBRE COMPLEJIDAD NÚMERO DE
DEPENDENCIAS
COMPONENTES
INVOLUCRADOS
CU001 Buscar
medicamento por
nombre comercial.
ALTA ALTA ALTA
CU003 Buscar
medicamento en
droguerías.
ALTA BAJA ALTA
CU011 Apartar
medicamento.
MEDIA MEDIA MEDIA
CU002 Buscar droguerías
cercanas.
MEDIA BAJA BAJA
CU004 Generar
recomendación
por genérico.
MEDIA MEDIA BAJA
CU005 Comparar
producto
comercial con
genérico.
BAJA MEDIA MEDIA
CU008 Generar
indicadores de
negocio.
ALTA ALTA BAJA
Tabla 1 CU Arquitecturalmente significativos.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 6
Para los requerimientos no funcionales se tomó como entrada los escenarios descritos dentro
del documento “EspecificacionReq” que sirvieron como guía para la verificación de la
arquitectura planteada.
Con lo anterior realizado ya se cuenta con una entrada para el proceso de realización de la
arquitectura.
3. Creación de vistas.
En esta etapa se procedió a la creación de la vista lógica, de componentes y de despliegue de
la arquitectura. A continuación se expone lo logrado en cada una.
3.1. Vista Lógica.
Para lograr una profundización y entender el impacto de los casos de uso
Arquitecturalmente Significativos dentro de la arquitectura, se procedió a la
elaboración de un diagrama Entity Boundary Controller (EBC) tomando como entrada
los casos de uso Arquitecturalmente Significativos. A continuación se presenta el
diagrama obtenido:
Memoria de Trabajo de Grado – Aplicación práctica.
Página 7
Ilustración 2 Diagrama EBC.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 8
El diagrama anterior permitió identificar varios componentes lógicos del observatorio
importantes para el desarrollo de la arquitectura. Posteriormente cada uno de estos
elementos lógicos fue relacionado con un componente donde fue desplegado.
Las necesidades de interconexión entre distintos sistemas heterogéneos, la necesaria
orquestación de estos para brindar servicios de valor a los consumidores finales junto
con los componentes detectados en el anterior diagrama EBC dieron a resaltar la
necesidad de implementar una arquitectura BPM/SOA apoyada en un ESB.
3.2. Vista de componentes.
Para lograr una descomposición del sistema que ayudara a satisfacer los requerimientos
detectados anteriormente y que permitiera la organización de los componentes lógicos
detectados en el diagrama EBC, se tomaron como base lineamientos para la creación
de arquitecturas BPM/SOA de referencias como IBM [2], Oracle [3], MuleSoft [4] y
The OpenGroup [5].
Como primer paso fue necesaria la identificación y selección de las capas necesarias
para la construcción y organización de la arquitectura del Observatorio. A continuación
se presentan la organización de las capas escogidas.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 9
Ilustración 3Capas Lógicas.
La imagen anterior ilustra las capas sobre las cuales se construyó la arquitectura del
Observatorio. A continuación se explica la función de cada una:
Memoria de Trabajo de Grado – Aplicación práctica.
Página 10
Capa Sistemas Externos: hace referencia a aquellos servicios y sistemas que se
encuentran fuera de los límites del Observatorio. Esta capa representa principalmente
los sistemas de las droguerías (repositorios de datos) y otros sistemas externos de
terceros que ofrezcan servicios utilitarios. De igual forma acá también es incorporada
la base de datos propia del Observatorio para permitir un desacople.
Capa ESB: su principal función está en integrar los diferentes repositorios de datos al
Observatorio. Conecta las droguerías existentes en la capa de Sistemas Externos
mediante Servicios de Negocio, así como otros servicios externos utilitarios al
Observatorio. De igual forma une, transforma y enruta a las droguerías bajo Proxys
que ofrecen servicios utilitarios a la capa superior SOA. Finalmente los servicios
expuestos a los consumidores finales, creados dentro del observatorio son expuestos
bajo el bus, para poder lograr cualidades de escalabilidad bajo este componente.
Capa SOA: acá se encuentra toda la estructuración de los servicios ofrecidos y
consumidos por el Observatorio. Cada uno de los servicios expuestos o consumidos
por esta capa se encuentran clasificados de la siguiente manera [6]:
o Servicios utilitarios: son expuestos por la Capa ESB mediante proxys y son
consumidos por la capa SOA para ser usados por otros servicios. Hacen
referencia a los servicios más pequeños y ofrecen operaciones específicas y
que carecen de valor para los consumidores.
o Servicios de Negocio: son servicios de nivel medio. Hacen uso de los
servicios utilitarios combinando varios de estos para crear nuevos servicios de
valor. Son estrictamente de corta duración (no existen actividades de
intervención humana). Son creados mediante BPM consumiendo los servicios
utilitarios y son expuestos nuevamente en la capa SOA como nuevos
servicios.
o Servicios de Proceso: son los servicios de más alto nivel que representan un
valor para los consumidores de la capa superior. Hacen uso de los servicios
de Negocio. Son creados mediante BPM y son expuestos nuevamente en la
capa SOA para ser usados por la capa de consumidores. Pueden ser de corta
o larga duración.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 11
Ilustración 4 Tipos de servicios
Capa BPM: como se mencionaba anteriormente, esta se encarga de la orquestación de
servicios utilitarios y servicios de negocio para crear servicios de proceso. Se encarga
de la creación, modelado y coordinación de los servicios; igualmente acá se produce
la generación de indicadores sobre los procesos. De acuerdo a los procesos expuestos
en la etapa de análisis, se detectaron tres escenarios importantes donde participa la capa
BPM:
o BPM como consumidor: mediante el modelado de procesos, BPM puede
consumir servicios expuestos por las capas SOA, la capa ESB y orquestarlos.
Ilustración 5 BPM como consumidor
El siguiente diagrama de flujo expone, mediante el Caso de Uso
CU002_Buscar droguerías cercanas, el escenario descrito al realizar el llamado
al servicio Utilitario getAllDrugstores expuesto por el ESB.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 12
Ilustración 6 BPM como consumidor, secuencia.
El diagrama anterior muestra una parte del proceso Buscar droguerías cercanas
donde se expone el escenario de BPM como consumidor. Acá el proceso hace
un llamado a la actividad getAllDrugstores que está implementada como un
servicio. La actividad busca en el catálogo de servicios SOA el servicio que la
implementa y llama al servicio en la capa ESB. Este a su vez llama al Servicio
de Negocio relacionado que realiza la consulta SQL sobre la base de datos del
observatorio. Cuando la respuesta vuelve hasta el proxy, este la transforma al
formato solicitado y la retorna a la actividad que lo llamó.
o BPM como proveedor síncrono: los procesos creados con la capa BPM
pueden ser encapsulados y expuestos como servicios en la capa SOA para ser
consumidos por otros procesos o consumidores finales. Así, los servicios de
Negocio y de Proceso son procesos BPM expuestos como servicios en SOA.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 13
Ilustración 7 BPM como Proveedor.
El siguiente diagrama de flujo expone mediante el Caso de Uso
CU001_Buscar medicamento por nombre comercial, el escenario descrito
anteriormente.
Ilustración 4 BPM como proveedor, secuencia.
Este escenario comienza con interacción del usuario quien solicita el método
findMedicine dentro del consumidor móvil. Este método en el cliente llama un
servicio expuesto a los consumidores mediante el ESB quien llama a un
Memoria de Trabajo de Grado – Aplicación práctica.
Página 14
servicio de la capa SOA que se encuentra implementado mediante un proceso
BPM que es invocado. De igual forma este proceso BPM llama a otras
actividades que llaman a otros servicios para realizar el proceso. Cuando el
mensaje llega al componente SOA FindNearestDrugstores se inicia el
escenario descrito en BPM como consumidor.
o BPM como proveedor asíncrono: algunos procesos de negocio, por su
naturaleza pueden ser de larga duración debido a la intervención de otros
usuarios para completarlos. Lo anterior ocasiona que los procesos BPM de
larga duración tengan que ser expuestos como servicios asíncronos para no
dejar a los consumidores finales que los invocan en espera sin poder realizar
nada más. El Caso de Uso U011_Apartar medicamento presenta estas
condiciones en el siguiente diagrama:
Ilustración 5 BPM como proveedor asíncrono.
En el diagrama anterior se muestra la petición de apartado de un medicamento
desde la aplicación móvil consumidor. Debido a que este servicio necesita de
la aprobación de la droguería, cuando el consumidor invoca al servicio, este
Memoria de Trabajo de Grado – Aplicación práctica.
Página 15
responde automáticamente con un código único del apartado solicitado para
no dejar a la aplicación cliente esperando por respuesta. Cuando se realiza la
solicitud, el proceso del CU011 crea un proceso asíncrono encargado de poner
la solicitud en la consola web del droguista y que queda esperando a que este
conteste. Para consultar el estado de la solicitud, es necesario otro proceso que
dado el código del apartado retorne el estado de este.
Ilustración 6 Proceso Obtener Status Apartado.
Capa de Consumidores: son consumidores finales que hacen uso de una interfaz de
usuario. Es la última capa de la arquitectura y consume los servicios de Proceso
expuestos en la capa de SOA haciendo uso del ESB como intermediario.
Las capas anteriores necesarias para la construcción de la arquitectura se relacionaron a nivel
lógico con el diagrama EBC creado. La Ilustración 7 ilustra la relación creada.
Una vez hecha la relación lógica entre capas y EBC para la realización de la arquitectura
BPM/SOA/ESB del Observatorio, se llevó a cabo la incorporación de componentes específicos
dentro de cada una que permitieron el desarrollo del sistema.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 16
3.1.1 Componentes específicos para el Observatorio.
Bus de Servicios Empresarial – ESB: componente principal de la Capa ESB. Este es
el componente que se encarga de la abstracción de la homogeneidad existente entre
los diferentes esquemas de datos de las diferentes droguerías y exponer las interfaces
de acceso a estas de manera uniforme. Por otro lado se encarga de exponer los servicios
que los consumidores externos usan, es decir, es el punto de entrada a la lógica
desarrollada. De igual forma se conecta con servicios de terceros utilitarios para
exponerlos a la capa SOA. Para lograrlo se vale de componentes Proxy y Servicios de
Negocio:
o Servicios de Negocio: componente interno del ESB que se encarga de
consumir directamente las bases de datos externas mediante un conector
específico o mediante un servicio web expuesto externamente sobre estas:
Consumidor mediante conector: En este caso es necesario que la
base de datos de la droguería soporte el estándar JDBC. Será otorgado
un usuario para conectarse directamente desde el Observatorio a la BD
creando el conector dentro del Bus de Servicio Empresarial.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 17
Ilustración 7 Diagrama EBC con capas lógicas.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 18
Consumidor mediante servicio web externo: La droguería tendrá que
ofrecer la dirección de un servicio web mediante el cual se puedan llevar a
cabo las consultas necesarias dentro del Observatorio. No existirá adaptador
interno y el Servicio de Negocio se comunicará con el Servicio Web dado.
De igual forma, el Servicio de Negocio se puede comunicar con servicios externos,
distintos a los droguistas, que son expuestos como servicios utilitarios.
o Proxy: componente interno del ESB que se encarga de consumir los Servicios de
Negocio. Dentro de este componente se realiza la lógica de enrutamiento, cambio de
protocolos, cambio de esquemas de distintos mensajes y se ofrecen bajo una sola
interfaz uniforme como servicios utilitarios.
Dentro del observatorio se encuentran los siguientes servicios utilitarios:
Nombre Descripción
getAllDrugstores Obtiene la información de todas las droguerías del observatorio.
distanceCalculator Obtiene la distancia entre dos puntos (latitud, longitud) en kilómetros.
medicinesSearch Obtiene la información de un medicamento basado en su nombre desde las droguerías.
getGenerics Obtiene una lista de medicamentos genéricos desde la base de datos del observatorio
basado en un componente activo.
getGenericId Obtiene el Id del componente activo de un medicamento desde la base de datos del
observatorio.
getOwnerSession Retorna el estado de la sesión actual del droguista dentro de la aplicación web.
ReserveMedicine Envía a la aplicación cliente web del droguista la solicitud de apartado de un medicamento.
getManufacturers Retorna los laboratorios Genéricos que producen medicamentos con el componente activo
dado.
insertMedicine Inserta un nuevo medicamento dentro del registro histórico de búsquedas del observatorio.
insertSeparateRegistry Inserta una nueva solicitud de apartado de medicamento con su estado dentro del
Observatorio.
selectDrugstoreOwner Retorna la información de la persona asociada como dueña de una droguería.
selectSeparateRegistry Retorna una solicitud de apartado existente dentro del observatorio.
updateOwnerSession Actualiza la sesión actual de un droguista dentro de la aplicación web.
updateSeparateRegistry Actualiza un registro de apartado dentro del Observatorio.
getConsumerSession Obtiene la sesión actual del consumidor.
updateConsumerSession Actualiza la sesión actual del consumidor.
Tabla 2 Servicios utilitarios. A continuación se muestra el resumen del componente ESB con sus partes relacionadas:
Memoria de Trabajo de Grado – Aplicación práctica.
Página 19
Ilustración 8 Componente ESB
En la parte más baja del diagrama vemos dos componentes de bases de datos que representan
las dos formas de conectar un sistema al Observatorio. La base de datos X se incorpora
mediante un conector que la expone como servicio. La base de datos N se conecta mediante
web service expuesto de forma externa, por lo cual el conector no es necesario pero si la
incorporación de un wsdl que describa el servicio. La base de datos al extremo derecho del
diagrama es la propia del Observatorio, la cual es incorporada con conector. De igual forma
el servicio externo más a la izquierda necesita de su wsdl para ser consumido por el Servicio
de Negocio. Arriba de los servicios de negocio se encuentran los Proxy que se encargan de
las tareas necesarias de transformación, enrutamiento y enriquecimiento de mensajes. Cada
proxy expone una interfaz uniforme independiente de los Servicios de negocios con los que
se comunica como Servicio Utilitario a la capa SOA. Por cada servicio utilitario del
Observatorio es necesaria la creación de un Proxy.
Servidor SOA: encargado de la Capa SOA, consume administra y expone servicios de los
tres tipos ya mencionados: Utilitarios, de Negocio y de Proceso. Cuenta con un Catálogo de
Servicios interno donde se registran servicios externos (utilitarios, proxys del ESB) e internos
Memoria de Trabajo de Grado – Aplicación práctica.
Página 20
(creados con BPM) para ser re utilizados o expuestos a los consumidores. Cuenta con un
motor de procesos para el despliegue de servicios. De igual forma cuenta con un servidor
de presentación que se conecta al Motor de servicios para poder llevar una administración en
tiempo real de los servicios desplegados por medio de un navegador de internet. A
continuación se muestra el componentes:
Ilustración 9 Servidor SOA
Dentro de la capa SOA, en sí, sólo se encuentran desplegados servicios de proceso y servicios
de negocio. Para el caso del Observatorio se cuentan con los siguientes servicios de Proceso
y de Negocio:
SERVICIOS DE NEGOCIO SERVICIOS DE PROCESO
FindNearestDrugstores Dados una latitud, longitud y radio,
retorna las droguerías que se
encuentran dentro del perímetro.
FindMedicine Proceso para encontrar un
medicamento comercial en las
droguerías cercanas al usuario.
FindMedicineInDrugstores Dado un nombre comercial de
medicamento y una lista de droguerías,
retorna todos los medicamentos dentro
SeparateMedicineSyn Proceso para apartar un medicamento
dentro de una droguería. Devuelve el
codigo único asociado a la solicitud.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 21
de las droguerías que tenga el nombre
dado.
GetSeparateStatus Dado el código único de una solicitud
de apartado de medicamento retorna el
estado actual de esta.
RecomendGeneric Proceso para pedir al Observatorio la
recomendación de un medicamento
genérico basado en uno comercial.
DrugstoreLogin Permite al droguista autenticarse
dentro del sistema Web.
ObtainMedicineInfo Proceso para obtener toda la
información disponible de un
medicamento.
DrugstoreLogOut Permite al droguista cerrar sesión
dentro del sistema Web.
ObtainDrugstoreInfo Proceso para obtener toda la
información disponible de una
droguería.
CompareCommercialGeneric Proceso para pedir al Observatorio la
realización de una comparación entre
medicamento comercial y sus
genéricos.
ConsumerLogin Permite al consumidor autenticarse
dentro del sistema móvil.
ConsumerLogOut Permite al consumidor cerrar sesión
dentro del sistema móvil.
SeparateMedicineAsy Proceso de larga duración, asíncrono
que envía la petición de apartado a una
droguería y espera a que esta conteste.
Tabla 3 Servicios de negocio y de proceso.
Componentes BPM: En primer lugar se encuentra un Motor BPM encargado de desplegar
y poner en funcionamiento un proceso BPM definido por el usuario. Está compuesto de los
siguientes componentes:
o Modelador de Procesos: mediante herramientas visuales permite el modelado de
procesos nuevos. Por otro lado el modelador se conecta con el Catálogo de Servicios
del servidor SOA para permitir el consumo de servicios ya existentes dentro del
proceso que se está creando.
o Motor BPM: componente donde se ejecuta el proceso de negocio una vez
desplegado. Cuando el proceso es expuesto como servicio en el motor SOA, este
último hace referencia a la instancia del proceso que se está ejecutando dentro del
motor BPM cuando es llamado.
o Servidor de Administración (BAM): permite ver el rendimiento en tiempo real de
los procesos que se encuentran desplegados así como todo su análisis y creación de
informes de análisis a partir de indicadores de negocio.
A continuación se muestra el componente.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 22
Ilustración 10 Componente BPM.
Componentes Consumidores: El Observatorio cuenta con un cliente Web para los
droguistas y un cliente Móvil para los consumidores. Para el cliente Web se cuenta con un
servidor de presentación que por un lado se conecta con los servicios disponibles en la Capa
SOA y además ofrece las pantallas para que los droguistas puedan conectarse al sistema y
recibir notificaciones de apartados. A continuación se exponen los componentes
consumidores:
Memoria de Trabajo de Grado – Aplicación práctica.
Página 23
Ilustración 11 Consumidores.
En la siguiente página se presentan todos los componentes y su comunicación dentro de un solo
diagrama bajo la Ilustración 12 Componentes Observatorio.
Ya con los componentes detectados se procedió a relacionar estos con el diagrama EBC realizado
anteriormente. La relación detectada se expone en la Ilustración 13 EBC Componentes.
El proceso realizado anteriormente permitió la identificación de componentes necesarios dentro del
Observatorio y la relación de estos con las funcionalidades lógicas del sistema. Posteriormente se
realizó el diagrama de despliegue que expone como se ubicaron los componentes antes detectados.
1. Vista de Despliegue.
Para realizar el despliegue de todos los componentes del Observatorio, se procedió a investigar las
diferentes formas topológicas en que se pude configurar un Bus de servicios empresarial y en base a
la opción seleccionada ubicar los demás componentes.
Así se escogió una topología Hub and Spoke [7]que permite una instalación sencilla del bus, donde
existe un gran solo componente que se comunica de forma central con todos los servicios que se
exponen en este para lograr el enrutamiento de mensajes. De igual forma permite disponibilidad al
distribuir la instalación del mismo ESB en dos o más servidores. Permite una administración sencilla
y fácil debuggeo.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 24
Ilustración 12 Componentes Observatorio.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 25
Ilustración 13 EBC Componentes.
Con base en lo anterior, los componentes del observatorio se desplegaron como se muestra en la
Ilustración 14 Diagrama de Despliegue.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 26
A continuación se describen los nodos detectados dentro del diagrama de despliegue expuesto en la
Ilustración 14 Diagrama de Despliegue:
Nodo Servidor ESB: Donde es desplegado el ESB junto con los proxy y servicios de negocio
definidos dentro de él. Posee lógica para enrutar, transformar, y validar los mensajes entrantes
y salientes
Nodo Servidor SOA: Acá son desplegados los servicios de esta capa (servicios de proceso
y de negocio). Adicionalmente contiene todos los componentes que permiten el manejo,
control y monitoreo de los servicios desplegados dentro del motor de procesos.
Nodo Servidor BPM: Acá son desplegados los procesos pertenecientes a esta capa. Se
encuentra el motor de proceso, el modelador de procesos, el servidor de administración y la
base de datos del servidor de administración donde se guarda la definición de los KPI junto
con las medidas tomadas de estos en los procesos ejecutados.
Nodos Droguerías: Es el componente externo, el cual es conectado al Observatorio por
solicitud de un droguista. Representa la conexión entre la base de datos de la droguería con
el Observatorio. Sobre este componente se realizan consultas, de forma orquestada para dar
respuesta a las solicitudes de los consumidores.
Nodo Base de datos Observatorio: Componente del Observatorio donde este va guardando
los datos correspondientes a los droguistas inscritos junto con los medicamentos que se han
buscado. De igual forma acá se van almacenando los datos correspondientes a los indicadores
de negocio.
o Estrategia de inserción de datos:
Debido a que la principal fuente de datos son las droguerías, la base de datos del
Observatorio se encuentra vacía al principio. Para solucionar esto, la base de datos
será cargada con dos reportes de precios, descripción de medicamentos y laboratorios
obtenidos del INVIMA y del OBSERVAMED, ambas instituciones públicas en
Colombia. De igual forma, la base de datos se ira llenando a medida que se realizan
consultas desde el cliente móvil.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 27
Ilustración 14 Diagrama de Despliegue.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 28
Nodos Cliente Web: Es el cliente por el cuál accede el droguista para consultar indicadores
de interés y de igual forma para pedir en primer lugar la inscripción al observatorio de una
droguería.
Nodos Cliente Móvil: Es el cliente por el cual accede el consumidor al Observatorio. Acá se
exponen los servicios que están disponibles para él.
Nodo Servicio Externo: Representa la forma de conexión de los servicios externos de
terceros que consuma el observatorio y que no se encuentran dentro de su dominio. Un
ejemplo de este servicio es aquel que calcula la distancia entre dos puntos en un mapa.
4. Vista de Datos.
A continuación se muestra la vista de datos relacionada al esquema existente en la base de datos del
Observatorio.
Ilustración 15 Vista de datos.
Memoria de Trabajo de Grado – Aplicación práctica.
Página 29
5. Verificación de la Arquitectura.
Este proceso se separó del documento SAD y se puede encontrar en documento “Evaluación de la
Arquitectura”.
6. Bibliografía.
[1] Bass, L. Clements, P. Kazman, R. (2003) Software Architecture in Practice (2nd Edition)
Addison-Wesley Professional.
[2] “Design an SOA solution using a reference architecture” (2014) [en línea], disponible en:
http://www.ibm.com/developerworks/library/ar-archtemp/, recuperado: Octubre de 2015.
[3] “Oracle Reference Architecture” (2010) [en línea], disponible en:
http://www.oracle.com/technetwork/topics/entarch/oracle-ra-soa-foundation-r3-1-176715.pdf,
recuperado: Octubre de 2015.
[4] “Services in SOA” [en línea], disponible en: https://www.mulesoft.com/resources/esb/services-
in-soa recuperado: Octubre de 2015.
[5] “SOA Reference Architecture Technical Standard” (2013) [en línea], disponible en:
https://www.opengroup.org/soa/source-book/soa_refarch/layers.htm#figure4, recuperado: Octubre
de 2015.
[6] Dikmans, L. “SOA made simple” (2011) [en línea], disponible en:
http://www.oracle.com/technetwork/articles/soa/soa-made-simple-chap-4-1918442.pdf, recuperado:
Octubre de 2015.
[7] Rotem, A. SOA Patterns (2012), Manning.