Embed Size (px)
DESCRIPTION
ing aeronautica
Citation preview
1
DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE
RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE
APLICACIONES EMPRESARIALES
VICTOR DANNEY GARCIA PLAZA
MARIA TERESA LOPEZ DUEÑAS
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍAS
MAESTRÍA EN INGENIERÍA DE SOFTWARE
SANTIAGO DE CALI ENERO DE 2012
2
DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE
RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE
APLICACIONES EMPRESARIALES
MARIA TERESA LOPEZ DUEÑAS
VICTOR DANNEY GARCIA PLAZA
DIEGO ARMANDO GOMEZ MOSQUERA
Director de trabajo de grado
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍAS
MAESTRÍA EN INGENIERÍA DE SOFTWARE
SANTIAGO DE CALI ENERO DE 2012
3
Nota de aceptación
________________________
________________________
________________________
________________________
Presidente del Jurado
________________________
Jurado
________________________
Jurado
Santiago de Cali, enero de 2012
4
DEDICATORIA
A Dios sobre todas las cosas, a mi familia por ser el motor que me impulsa a
crecer cada día y a mis amigos quienes con su apoyo y consejos me ayudan a
mantener firmes mis objetivos.
MARIA TERESA LÓPEZ DUEÑAS
A Dios, a mi pequeño Juan Pablo, a mi esposa Angélica, y a mis padres, por su
gran amor y apoyo en cada una de las etapas de mi vida.
VICTOR D. GARCIA PLAZA
5
AGRADECIMIENTOS
A Dios a quien confío mis retos, a mi familia y amigos quienes con su cariño y
respaldo me acompañaron en este proceso y a mi director de tesis y colegas
quienes nos respaldaron, con sus valiosos conocimientos y aportes, para el logro
de este objetivo.
MARIA TERESA LÓPEZ DUEÑAS
A Dios por darme la oportunidad de aprender, a mi familia por su enorme apoyo y
a Diego A. Gómez, por su tiempo, dedicación e ideas que contribuyeron
satisfactoriamente a la culminación de este trabajo de grado.
VICTOR D. GARCIA PLAZA
6
TABLA DE CONTENIDO
1. PLANTEAMIENTO DEL PROBLEMA ....................................................... 15
2. MARCO TEORICO ................................................................................... 17
3. METODOLOGÍA ....................................................................................... 21
3.1 Fase I, denominada Recopilación ...................................................... 21
3.1.1 Etapa I ......................................................................................... 22
3.1.2 Etapa II ........................................................................................ 22
3.1.3 Etapa III ....................................................................................... 22
3.2 Fase II, denominada Diseño .............................................................. 22
3.2.1 Etapa I ......................................................................................... 23
3.2.2 Etapa II ........................................................................................ 23
3.2.3 Etapa III ....................................................................................... 23
3.2.4 Etapa IV ....................................................................................... 23
3.2.5 Etapa V ........................................................................................ 23
3.3 Fase III, denominada Aplicación ........................................................ 23
3.3.1 Etapa I ......................................................................................... 24
3.3.2 Etapa II ........................................................................................ 24
4. RESULTADOS ......................................................................................... 25
4.1 Fase I Recopilación de información ................................................... 25
4.1.1 Etapa I Determinar conjunto de variables .................................... 25
4.1.2 Etapa II Determinar conjunto de soluciones conocidas ............... 32
4.1.3 Etapa III Determinar el conjunto de buenas prácticas ................. 49
4.2 Fase II Diseño del método ................................................................. 58
4.2.1 Etapa I: Definición de categorías ................................................. 58
4.2.2 Etapa II: Soluciones conocidas aplicables por categoría ............. 59
4.2.3 Etapa III: Buenas prácticas aplicables por categoría ................... 59
4.2.4 Etapa IV: Definición de filtros ....................................................... 59
4.2.5 Etapa V: El método diseñado ...................................................... 66
4.3 Fase III Prueba del diseño del método ............................................... 67
7
4.3.1 Etapa I: Refinamiento del método ................................................ 67
4.3.2 Etapa II: Aplicación del método diseñado .................................... 71
5. CONCLUSIONES ..................................................................................... 78
6. RECOMENDACIONES Y TRABAJOS FUTUROS ................................... 80
8
LISTA DE TABLAS
Tabla 1 Ventajas y desventajas de los estilos de integración
Tabla 2 Estilos de integración y los Frameworks que los implementan.
Tabla 3 Buenas prácticas agrupadas por cada solución conocida.
Tabla 4 Comparativo entre solución real y soluciones recomendadas.
9
LISTA DE FIGURAS
Figura 1. Esquema de la metodología desarrollada.
Figura 2. Transferencia de archivos.
Figura 3. Bases de datos compartidas.
Figura 4. Invocación a procedimientos remotos.
Figura 5. Mensajería.
Figura 6. Aplicaciones comunicadas usando mensajería.
Figura 7. Comunicación basada en mensajería a través de un MOM.
Figura 8. Transmisión de mensajes paso a paso.
Figura 9. Categorización de Patrones de integración empresarial.
Figura 10. Esquema del método diseñado.
10
LISTA DE ANEXOS
Anexo 1: Resultados de la encuesta:
Anexo 1.1 Encuesta.
Anexo1.2 Necesidades de integración.
Anexo 1.3 Criterios y restricciones para la integración.
Anexo 1.4 Tipos de aplicaciones a integrar.
Anexo 1.5 Características de calidad de la solución de integración.
Anexo 1.6 Cuadro de tecnologías
Anexo1.7 Caracterización de las empresas de los profesionales objeto de la
encuesta
Anexo 2: Combinación de variables:
Anexo 2.1 Tipos de aplicaciones
Anexo 2.2 Criterios y restricciones
Anexo 2.3 Características de calidad
Anexo 2.4 Criterios y restricciones tipo de aplicación origen
Anexo 2.5 Criterios y restricciones tipo de aplicación destino
Anexo 3: Aplicación del método diseñado
Anexo 3.1: Soluciones conocidas criterios y restricciones
Anexo 3.2: Criterios y restricciones refinado
Anexo 3.3: Soluciones conocidas tipo de aplicación origen
Anexo 3.4: Soluciones conocidas tipo de aplicación destino
Anexo 3.5: Caracterización de los casos de negocio y soluciones
11
RESUMEN
Cuando un constructor de aplicaciones empresariales se enfrenta a la integración
de dos aplicaciones para un caso específico de negocio, se encuentra con un
conjunto bastante amplio de estrategias, métodos y arquitecturas que pueden ser
utilizados. Sin embargo, cuando debe elegir una opción de entre el conjunto de
posibilidades, surgen las restricciones que están dadas por las características de
las aplicaciones de su negocio y los requerimientos no funcionales del caso
específico objeto de la integración; por lo que seleccionar la opción más adecuada
resulta ser un problema no trivial de resolver.
En este proyecto de investigación se diseñó un método que al ser usado por un
constructor de aplicaciones empresariales, que se enfrenta a un caso de
integración, le entrega una recomendación sobre las posibles opciones a usar;
considerando las características de las aplicaciones a integrar y las restricciones
presentes en su caso específico de negocio.
Para diseñar este método se inició con la recolección y definición de las
características de las aplicaciones y restricciones comunes presentes en las
empresas de Santiago de Cali; así como el conjunto de métodos, estrategias,
buenas prácticas, soluciones conocidas y otras reglas usadas para la integración
de aplicaciones empresariales. Posteriormente se realizó el diseño del método a
través de la identificación y definición de las categorías en las que se clasifican los
casos de negocio y la identificación y definición del conjunto de buenas prácticas
y soluciones conocidas aplicables a cada categoría. Con lo anterior se definió una
serie de filtros que permitieron garantizar la correcta caracterización y
categorización de los casos de negocio dados y por consiguiente cuales son las
buenas prácticas y soluciones conocidas que le son aplicables. Finalmente se
12
probó el diseño del método a diez (10) casos de negocio reales y al mismo tiempo
se hizo el refinamiento a través de la definición y validación de criterios que
permitieron determinar la pertinencia del conjunto de recomendaciones entregado
por el método diseñado, frente a la caracterización del caso de negocio.
13
INTRODUCCIÓN
Cuando se piensa en una empresa, esta se ve como un sistema complejo que
tiene un propósito u objetivo específico. Las aplicaciones empresariales intentan
apoyar a la empresa en la consecución de estos objetivos [1]. Debido a esto, los
constructores de aplicaciones empresariales se enfrentan al reto de implementar
soluciones especializadas que deben procesar tareas específicas, enfocadas a un
conjunto determinado de procesos y diseñadas a la medida de las necesidades
del negocio; que a su vez deben integrarse con otras aplicaciones de negocio y/o
sistemas legados que desempeñan otras tareas específicas.
En la búsqueda de mecanismos u opciones para realizar la integración de
aplicaciones, un constructor de aplicaciones empresariales, que se enfrenta a un
caso de negocio, encuentra un amplio conjunto de soluciones que pueden ser en
alguna medida aplicables al caso de integración. Seleccionar la mejor opción es
una habilidad que resulta de la experiencia, pues en la actualidad no se cuenta
con un método conocido que permita llegar a una mejor opción. En el presente
proyecto de investigación se diseñó un método que al ser usado por un
constructor de aplicaciones empresariales, que se enfrenta a un caso de negocio
en el que deba realizar integración de aplicaciones, este le entregara una
recomendación sobre las posibles opciones a usar; considerando las
características propias de las aplicaciones y restricciones con las que trabaja. Para
lo anterior se identificó un conjunto de características y restricciones que al ser
agrupadas, permitieron definir las categorías en las que se pueden clasificar los
casos de negocio; complementando lo anterior se definió cuáles son las buenas
prácticas y soluciones conocidas que se pueden aplicar a cada categoría. De
manera que una vez clasificado un caso de negocio en una categoría, se
relacionan las buenas prácticas y soluciones conocidas que son aplicables.
14
En los capítulos siguientes se presentan el planteamiento del problema para el
cual el método fue diseñado; el marco teórico en el que se ambientan, a través de
los diferentes enfoques y autores, el problema y las aproximaciones que se le han
dado a la integración de aplicaciones empresariales; Además se presenta,
también, cada una de las fases y etapas de la metodología definida; los resultados
hallados en cada fase de la metodología desarrollada; las conclusiones
encontradas durante la realización del proyecto, las recomendaciones y trabajos
futuros derivados de este proyecto.
15
1. PLANTEAMIENTO DEL PROBLEMA
La integración de aplicaciones empresariales, por sus siglas en ingles EAI [16]
(Enterprise Application Integration) es un término utilizado comercialmente para
denominar los planes, métodos y herramientas utilizados para integrar y coordinar
las aplicaciones en una empresa [1]. El constructor de aplicaciones empresariales
en el proceso de análisis y diseño de integración de aplicaciones [3] para un caso
específico de negocio, además de encontrarse con un conjunto genérico de
posibles estrategias [16], arquitecturas y métodos de integración [4]; se encuentra
también con un número importante de características propias de las aplicaciones
de su negocio tales como: plataformas, lenguajes de programación, protocolos,
motores de bases de datos, sistemas operativos y arquitecturas de aplicación [4]
que le agregan complejidad a la elección de una opción de integración de
aplicaciones.
Ahora, si se piensa en que esa integración debe responder eficiente y
efectivamente a las necesidades de los procesos de negocio, dadas en términos
de los requerimientos no funcionales asociados a tiempos de respuesta e
integridad de los datos, y que está condicionada por la tecnología, nivel de
madurez y cultura propios del negocio; nos enfrentamos a un problema que no es
trivial de resolver.
El presente proyecto tiene como objetivo principal diseñar un método que entregue
un conjunto de recomendaciones para realizar la integración de aplicaciones
empresariales aplicables a un caso de negocio dado. Los objetivos específicos de
este proyecto son: recopilar las diferentes estrategias, métodos y estilos de
integración existentes para realizar la integración de aplicaciones empresariales;
identificar las características más comunes a las aplicaciones presentes en las
empresas; identificar los posibles valores que pueden tomar cada una de estas
características; identificar las restricciones comunes presentes en las empresas;
16
identificar los posibles valores que pueden tomar cada una de estas restricciones;
definir una taxonomía con la que se puedan clasificar, categorizar y/o tipificar los
casos de negocio de aplicaciones empresariales; recopilar y seleccionar un
conjunto de buenas prácticas de integración de aplicaciones, que apliquen a cada
categoría; recopilar y seleccionar un conjunto de soluciones conocidas de
integración de aplicaciones, que puedan aplicar a cada categoría; definir un
conjunto de filtros, aplicables a la integración de aplicaciones, que permitan
realizar la correcta caracterización de cada caso de negocio; probar y refinar el
diseño del método aplicándolo a un conjunto de casos de negocio reales.
17
2. MARCO TEORICO
En la actualidad es cada vez más común que las organizaciones usen paquetes
de software para sus procesos de negocio principales, tales como Enterprise
Resource Planning (ERP), Supply Chain Management (SCM), Customer
Relationship Management (CRM) y Electronic Commerce (EC). Estos les permiten
a las empresas enfocarse en los sistemas de información (IS) que soportan su
operación y metas financieras [12]. Sin embargo debido a la especialización de
cada uno de estos paquetes de software, existen diferentes proveedores líderes
que brindan soluciones específicas para cada una de estas necesidades; por lo
tanto es muy común ver empresas que tienen al menos dos o más proveedores
que satisfagan sus necesidades específicas en cada uno de sus procesos de
negocio.
Como resultado de la adquisición de estas herramientas o paquetes de software
por parte de las empresas, y debido a los constantes cambios en los
requerimientos del negocio para atender al mercado en el tiempo esperado, los
cortos ciclos de vida de los productos y el aumento en la interdependencia con los
socios de negocio [15], se hace entonces necesario que los procesos de negocio
de las empresas deban amoldarse a dichos cambios para poder cubrir las
necesidades de sus clientes, lo que implica que los sistemas que soportan estos
procesos de negocio y sus interdependencias deban estar también cambiando.
Por esto, es necesaria la interoperabilidad entre los distintos paquetes de software
o aplicaciones de una empresa y además el intercambio de información con sus
socios de negocio. Por lo tanto la integración de las aplicaciones y los procesos de
negocio son una prioridad para las empresas en la actualidad [16]. No cabe duda
que la integración entre aplicaciones sea una constante en el día a día de las
grandes empresas, a tal punto que se encuentra involucrada incluso en los
18
paradigmas computacionales más actuales, como es el caso de la
interoperabilidad de aplicaciones en la nube [14]. Esto evidencia que los procesos
de integración seguirán siendo vigentes en el futuro de las empresas, por esta
razón cada vez más las compañías buscan maneras para mejorar sus procesos
de integración. Un ejemplo claro de esto se puede observar en la actualidad
cuando se intentan mitigar los problemas de interoperabilidad entre los paquetes
de software de una compañía, que como se ha hecho referencia en este mismo
documento son normalmente heterogéneos, a través de la adquisición de software
que provenga de un mismo proveedor, sin embargo, los resultados no han
cumplido las expectativas y debido a eso muchas organizaciones están
cambiando su estrategia a una que permita un rápido ensamble y desensamble de
los procesos de negocio y de los correspondientes componentes de software [12].
Otra forma de resolver los problemas de integración, se da con la aparición de
modelos de integración tal como el Modelo de Integración Empresarial (EMI) [15],
que permite a través de un enfoque de meta-modelo orientado a objetos, la
construcción de un lenguaje que describe un cierto dominio [15]. Además dicho
modelo permite la reutilización de experiencias a través de la propuesta de
patrones para el meta-modelo de integración [15].
Otra solución es el uso de un conjunto de patrones de integración empresariales,
que son el resultado de años de trabajo por parte de expertos en la materia, con
diferentes organizaciones en procesos de integración de aplicaciones
empresariales [16, 20, 22]. Estos patrones brindan solución a un conjunto amplio
de problemas de integración entre aplicaciones empresariales. Se debe tener en
cuenta que las soluciones de integración son una tarea compleja, pues existe más
de una solución posible, sin embargo saber si la solución definida es una buena
opción, no se conocerá sino hasta muchos meses o aun años más tarde, cuando
inevitablemente los cambios y la dinámica del negocio pongan a prueba la
solución original [16].
19
En la actualidad, la computación orientada a servicios aparece como un nuevo
paradigma computacional fundamentado en buena parte en el paradigma
orientado a objetos [6] y en la programación orientada a aspectos [7]. Se basa
fundamentalmente en el concepto de servicio definido como un contenedor de
capacidades que se compone de: un cuerpo de lógica que le permite llevar a cabo
esas capacidades y un contrato que expresa cuales de estas capacidades están
disponibles para ser usadas [21]. Uno de los elementos fundamentales en la
computación orientada a servicios es la arquitectura orientada a servicios,
SOA[21] por sus siglas en inglés, y dentro de SOA la integración tiene un lugar
relevante, y es resaltada por Thomas Earl, como una parte importante, de alto
perfil de la industria de las tecnologías de información [21]. Esto se debe a que
prácticamente los servicios se construyen con la capacidad intrínseca de
interactuar con múltiples consumidores y que prácticamente ninguno de ellos es
conocido en el momento de su creación [21]. Con este concepto, SOA podría ser
entonces la solución a los problemas de integración; sin embargo, esto es algo
que solo se puede presentar cuando un porcentaje importante de los servicios de
una organización está representado en un inventario de servicios de calidad [21].
Implementar SOA requiere tanto habilidades técnicas como habilidades
organizacionales, lo que quiere decir que la implementación de SOA pasa las
fronteras de lo técnico y comienza a ser un asunto organizacional [23]. Es por ello
que el mismo Thomas Earl indica que mientras se trabaja hacia el logro de un
inventario de servicios de calidad, es probable que existan muchos requisitos para
la integración tradicional entre los sistemas heredados existentes, y también entre
los sistemas heredados y sus servicios [21]. Los métodos desarrollados por los
diferentes investigadores se enfocan como propuestas metodológicas que
permiten evaluar la pertinencia o riesgos sobre las decisiones tomadas en el
diseño de arquitecturas de aplicaciones. Ejemplo de ello es ATAM (Architecture
Tradeoff Analysis Method), cuyo propósito es analizar un diseño de arquitectura y
determinar si este diseño satisface los objetivos de calidad para los cuales fue
20
construido, determinando las posibles consecuencias o riesgos de esta decisión
en función de los atributos de calidad definidos por los requisitos del sistema [8].
Otro ejemplo de un método para realizar el análisis de arquitecturas de software
es SAAM (Software Architecture Analysis Method), evalúa las arquitecturas de
software basándose en la adopción de escenarios como los medios mas
descriptivos para especificar y evaluar los atributos de calidad, de esta manera
SAAM plantea que los escenarios deben reflejar los tributos de calidad de interés y
también mostrar la interacción entre las diferentes personas que utilizaran el
sistema: usuarios finales, administrador, desarrolladores, etc. Cabe anotar que en
este método, los escenarios son analizados desde tres perspectivas
fundamentales: la perspectiva funcional, la perspectiva de estructura y la
perspectiva de distribución o asignación [9]. Otros métodos de análisis de
arquitecturas se enfocan en criterios específicos a evaluar, como la reutilización, o
en la comparación de arquitecturas desarrolladas bajo diferentes paradigmas [10].
Sin embargo no se ha identificado métodos específicos que determinen un
conjunto de pasos para encontrar posibles soluciones a un caso de integración de
aplicaciones empresariales. Es aquí donde se fundamenta el objetivo del presente
trabajo de investigación aplicada.
21
3. METODOLOGÍA
La metodología definida para el desarrollo del proyecto se muestra en la Figura 1,
se divide en tres (3) fases principales, a continuación se detalla las etapas y
actividades de cada una de estas fases:
Figura 1. Esquema de la metodología desarrollada.
3.1 Fase I, denominada Recopilación
La fase de recopilación, como su nombre lo indica, esta fase se centra en la
recopilación de información. Se divide en tres etapas, las actividades a realizar en
cada etapa se detallan a continuación:
22
3.1.1 Etapa I
Determinar el conjunto de variables con las que se puede caracterizar un caso de
integración de aplicaciones Empresariales: En la cual el trabajo se orientará a la
construcción de los siguientes entregables:
Conjunto de estrategias, métodos y arquitecturas existentes para realizar la
integración inter-aplicación de aplicaciones empresariales.
Conjunto de las características más comunes a las aplicaciones presentes
en las empresas con sus respectivos valores.
Conjunto de las restricciones comunes presentes en las empresas con sus
respectivos valores.
En esta etapa se realizará la identificación de estos elementos en la literatura
existente y se realiza la validación del uso de los mismos en el contexto de
Santiago de Cali, a través de la elaboración de una encuesta.
3.1.2 Etapa II
Determinar el conjunto de soluciones conocidas aplicables a un caso de
integración de aplicaciones empresariales: el cual se realizará con la revisión de la
literatura existente.
3.1.3 Etapa III
Determinar el conjunto de buenas prácticas aplicables a un caso de integración de
aplicaciones empresariales: para esta recopilación se hace uso de entrevistas con
expertos y revisión de la literatura existente.
3.2 Fase II, denominada Diseño
En esta fase el trabajo se centrará en el diseño del método, teniendo como
insumos los entregables de la fase de Recopilación, Fase I; los entregables de
esta fase son descritos en las siguientes etapas:
23
3.2.1 Etapa I
Definición de categorías: Para esta actividad el entregable será la taxonomía en la
que se puedan clasificar, categorizar o tipificar los casos de negocio de integración
de aplicaciones empresariales.
3.2.2 Etapa II
Definición de soluciones conocidas aplicables por categoría: Para esta actividad el
entregable será el conjunto de soluciones conocidas aplicables a cada categoría
definida en la Etapa I.
3.2.3 Etapa III
Definición de buenas prácticas aplicables por categoría: Para esta actividad el
entregable será el conjunto de buenas prácticas o reglas aplicables a cada
categoría definida en la Etapa I.
3.2.4 Etapa IV
Definición de Filtros: Para esta actividad el entregable será el conjunto de filtros y
el orden en el que se deben aplicar en el proceso de caracterización, estos filtros
se construyen para garantizar la coherencia de los valores de las variables con las
que se caracteriza el caso de negocio, compatibilidad y complemento de las
mismas, y con ello garantizar que la categoría en la que se clasificará el caso de
negocio, objeto de la aplicación del método diseñado, sea correcta.
3.2.5 Etapa V
Con la recopilación de las etapas anteriores se realizará la definición de los pasos
del método. En esta fase las definiciones se realizarán teniendo como insumo
principal la recopilación de la literatura y entrevistas con expertos realizada en la
Fase I.
3.3 Fase III, denominada Aplicación
En esta fase se pondrá a prueba el diseño del método definido en la fase de
Diseño (Fase II). Y comprende las siguientes actividades:
24
3.3.1 Etapa I
Definición de criterios para determinar la pertinencia de la(s) recomendación(es)
entregada(s) por el método frente a la caracterización del caso de negocio.
3.3.2 Etapa II
Aplicación y refinamiento del método diseñado. En esta fase se trabajará
aplicando el método diseñado en la Fase II (Fase de diseño), a casos de
integración de aplicaciones empresariales, que se han presentado en los
proyectos de construcción de aplicaciones realizados en los dos últimos años en el
Grupo Empresarial Coomeva. La pertinencia de las recomendaciones entregadas
por el diseño del método será determinada por los criterios definidos en la Etapa I
de esta fase.
25
4. RESULTADOS
Conforme a lo establecido en la metodología definida para el desarrollo del
proyecto, se llevaron a cabo las actividades de las tres (3) fases, los resultados de
estas actividades se mostraran a continuación:
4.1 Fase I Recopilación de información
La fase de recopilación de información consistió, como su nombre lo indica, en un
proceso de recolección de información sobre la integración de aplicaciones
empresariales, el cual se orientó en la elaboración de seis (6) conjuntos; cuatro (4)
de los cuales representan el dominio de las entradas al método que se va a
diseñar que corresponden a los conjuntos de variables con las cuales se puede
caracterizar un caso de negocio. Y dos (2) más que son el engranaje fundamental
del método y que corresponden al conjunto de soluciones conocidas y el conjunto
de buenas prácticas respectivamente.
4.1.1 Etapa I Determinar conjunto de variables
El propósito de esta etapa es determinar el conjunto de variables con las que se
puede caracterizar un caso de integración de aplicaciones Empresariales:
Estos elementos tienen la característica principal de influenciar la integración de
aplicaciones empresariales y ser decisivos al momento de analizar un caso de
integración de aplicaciones empresariales. Para la elaboración de estos cuatro (4)
conjuntos fue necesario la ejecución de dos (2) actividades: La revisión de la
literatura existente y la realización y análisis de resultados de la encuesta.
4.1.1.1 Revisión de la literatura existente
Como se mencionó anteriormente, el propósito de esta revisión se orientó en la
elaboración de cuatro (4) conjuntos que fueron identificados durante la revisión de
la literatura, durante la cual se reconocieron dos textos principales [16, 18] y un
26
grupo de artículos [4, 5, 11, 12, 13, 14]; a partir de los cuales se logró establecer
una serie de elementos que se agruparon como se muestra a continuación:
4.1.1.1.1 Necesidades de integración
La principal característica de este primer grupo es que reúne los elementos que
motivan la integración de aplicaciones empresariales. En otras palabras, es el
porqué y el para qué se integran las aplicaciones empresariales. Los elementos de
este grupo se describen a continuación:
Transferencia de archivos: El sistema necesitará producir archivos para
compartir datos o necesitará consumir archivos que otros producen.
Bases de datos compartidas: El sistema necesitará almacenar o extraer
datos de una base de datos externa al sistema, que ha sido compartida a
través de mecanismos propios del motor de base de datos.
Invocación remota de procedimientos: El sistema necesitará exponer
algunos de sus procedimientos para que sean invocados remotamente o
deberá invocar procedimientos para dar inicio a un proceso e intercambiar
datos.
Mensajería: El sistema necesitará usar un Middleware de mensajería para
el intercambio de datos o para inducir eventos en otros sistemas o
subsistemas.
4.1.1.1.2 Criterios de Integración
Este segundo grupo contiene los elementos que marcan los criterios a tener en
cuenta en el momento en que son tomadas las decisiones de integración y las
restricciones que se pueden presentar durante esta toma de decisiones:
Intrusión: Cuando el enfoque por el menor impacto, es decir reducir al
mínimo los cambios o la cantidad de código de integración no pueden
proporcionar la mejor solución de integración en la empresa.
27
Selección de la tecnología: Cuando se requiere del uso de software y
hardware especializado para llevar a cabo la solución de integración, pues
el hecho de construir la solución desde cero, puede resultar en un mayor
esfuerzo de lo previsto inicialmente y puede significar volver a hacer parcial
o totalmente algo que ya existe, es decir “reinventar la rueda”.
Formato de los datos: Se presenta cuando aparece alguno de estas
situaciones:
Utilizar un formato de datos común para la integración de las
aplicaciones.
Modificar la aplicación para usar un formato de datos común.
Utilizar un traductor o mediador que homologue los formatos de los
datos.
Usar un formato de datos extensible en el tiempo.
Latencia en el intercambio de datos: Se presenta cuando se requiere que:
La información compartida entre aplicaciones debe estar disponible
para el receptor tan pronto el emisor la haya generado totalmente, es
decir que el receptor nunca recibirá parcialmente la información.
La información compartida entre aplicaciones estará disponible
desde el momento en que el emisor la esté generando, es decir el
receptor podrá recibir la información a medida que esta se vaya
generando por el emisor, esto implica el envió de información
fragmentada y se hace compleja su sincronización.
Datos o Funcionalidad: Se presenta cuando:
La integración permitirá a las aplicaciones compartir solo datos.
28
La integración permitirá compartir funcionalidades en vez de
simplemente datos.
Comunicación Remota: Se presenta cuando se desea establecer
comunicación con aplicaciones que no se encuentran en la misma instancia
de sistema operativo de la aplicación que tiene la intención del llamado. En
este caso la comunicación con las aplicaciones puede ser simplemente
síncrona o asíncrona. Esta última implica mayor complejidad en el diseño,
desarrollo y depuración.
Confiabilidad: Se presenta cuando por ejemplo una solución de integración
permitirá la comunicación asíncrona entre dos o mas aplicaciones,
garantizando que en el momento que el emisor solicite una funcionalidad,
esta se realizara cuando el receptor esté disponible.
4.1.1.1.3 Tipos de aplicaciones.
El tercer grupo describe los tipos de aplicaciones empresariales, enfocándose en
el manejo de los eventos y los tipos de datos que procesan. La clasificación
adoptada para este grupo está definida en [31] y se seleccionó para el desarrollo
de este trabajo de grado debido a que es la que más se aproxima al contexto
empresarial en el que se va a trabajar el proyecto, tanto para la aplicación de la
encuesta como para la caracterización y análisis de los casos de negocio además
se ajusta a los tipos de escenarios cubiertos por los Frameworks de integración
más comunes del mercado [30,31,33].
Batch:
No procesan eventos.
Transaccionales 1:
Procesan eventos en la medida que ocurren.
29
Procesan eventos de los usuarios que se conectan vía interfaz de
usuario.
Deben estar disponibles.
No manejan tipos de datos complejos.
Transaccionales 2:
Procesan eventos en la medida que ocurren.
Procesan eventos de los usuarios que se conectan vía interfaz de
usuario.
Deben estar disponibles.
Cliente servidor:
Procesan eventos en la medida que ocurren.
Procesan eventos de los usuarios que se conectan vía interfaz de
usuario.
Deben estar disponibles.
Manejan tipos de datos complejos.
Procesamiento importante en el cliente.
Web:
Manejan tipos de datos complejos.
Procesamiento importante en el cliente.
Procesan eventos en la medida que ocurren.
Procesan eventos de los usuarios que se conectan vía interfaz de
usuario.
Deben estar disponibles.
Manejan tipos de datos complejos.
Sin procesamiento en el cliente.
Tiempo Real: Procesan eventos en el instante que ocurren
Paquetes de Software: Adquiridos y/o fabricados por terceros y proveen
mecanismos de integración predefinidos desde el fabricante.
30
4.1.1.1.4 Características de calidad:
En este cuarto grupo se consideraron las características de calidad, no para las
aplicaciones a integrar; sino de la solución de integración. Para el desarrollo de
este proyecto se seleccionó el marco de trabajo de las características de calidad
de acuerdo con la norma ISO/EIC 25010 [2,19]. Esta selección se realizó teniendo
en cuenta que es el marco con el que los investigadores han venido trabajando
durante el proceso de formación profesional y es el marco con el que está más
familiarizado el contexto empresarial en el que se va a aplicar la encuesta. Las
características de calidad conforme al marco seleccionado se definen como sigue:
Funcionalidad: Grado al cual un producto software provee las funciones que
satisfacen las necesidades explícitas e implícitas cuando el software se utiliza
bajo condiciones específicas
Seguridad: La protección del sistema de accesos maliciosos o accidentales,
uso, modificación, destrucción o divulgación.
Capacidad de transferencia: Grado en el cual un producto software puede ser
transferido de un ambiente a otro.
Fiabilidad: Grado de un producto de software para mantener un nivel específico
de funcionamiento cuando se está utilizando bajo condiciones especificadas.
Capacidad de operación: Grado al cual un producto software puede ser
entendido, aprendido, usado y atractivo al usuario, cuando es utilizado bajo las
condiciones especificadas.
Eficiencia de rendimiento: Grado al cual un producto software provee un
rendimiento adecuado, de acuerdo con la cantidad de recursos utilizados y
bajo las condiciones planteadas
Compatibilidad: La capacidad de dos o más componentes software para el
intercambio de información y/o para cumplir con sus funciones, Compartiendo
el mismo hardware o el entorno de software.
31
Capacidad de mantenimiento: Grado en el cual un producto software puede ser
modificado. Las modificaciones pueden incluir correcciones, mejoras o
adaptación del software a cambios en el entorno, y especificaciones de
requisitos y funcionalidades.
4.1.1.2 Encuesta
Una vez revisada la literatura existente y luego de recopilar y agrupar los
diferentes elementos ahí presentados; se procedió a trabajar con la segunda
herramienta, que consistió en la elaboración y análisis de resultados de una
encuesta realizada a veintiuno (21) voluntarios que trabajan o han trabajado en
proyectos de integración de aplicaciones empresariales. Los objetivos de esta
encuesta fueron:
Someter a calificación (entre 1 y 5) cada uno de los elementos recopilados, en
la revisión de la literatura, de acuerdo al nivel influencia de estos elementos en
la integración de aplicaciones empresariales.
Recolectar información sobre los métodos que se emplean actualmente.
Identificar las tecnologías en las que están construidas las aplicaciones
empresariales con las que se trabajan en proyectos de integración en las
empresas de Santiago de Cali.
Los resultados obtenidos para cada uno de los objetivos de la encuesta se
muestran a continuación:
Todos los elementos recopilados en la literatura, fueron calificados con algún
grado de influencia y todos se usan con mayor a menor frecuencia dentro de
los proyectos que han realizado los encuestados. Por lo tanto todos los
elementos recopilados en la literatura van a ser utilizados como entradas al
método para realizar la caracterización de los casos de negocio. No
aparecieron nuevos elementos, necesidades, criterios, restricciones,
características de calidad y de las aplicaciones, a incluir en el conjunto de
elementos ya recopilados.
32
Solo uno de los encuestados respondió afirmativamente a la pregunta de si
conocía un método que le permitiera identificar la mejor opción de integración
dentro de un grupo de casos de integración de aplicaciones empresariales. Sin
embargo el método descrito por el encuestado es más una descripción de un
conjunto de actividades en orden lógico usado a nivel personal para resolver
casos de integración; que un método formalmente descrito y referenciado.
Se logró identificar las tecnologías en las que están construidas las
aplicaciones empresariales (bases de datos, lenguajes de programación y
sistemas operativos) en las que han trabajado los encuestados y se identificó
que corresponde a un conjunto amplio de distintas tecnologías y fabricantes;
incluso dentro de una misma empresa.
Estos resultados se presentan de manera gráfica y detallada en el Anexo 1
Resultados de la encuesta.
4.1.2 Etapa II Determinar conjunto de soluciones conocidas
El resultado del trabajo realizado en esta etapa de la metodología, básicamente se
resume en el uso de los estilos de integración definidos en [16] como soluciones
conocidas, dado que en la actualidad son las más utilizadas dentro de la
bibliografía sobre la que se basa este documento. A continuación se profundiza
sobre cada uno de estos estilos:
4.1.2.1 Transferencia de archivos
Figura 2. Transferencia de archivos [16].
33
Esta solución se basa en el estilo de integración que lleva su mismo nombre (File
Transfer) [16]. Cuando se usa la transferencia de archivos como solución a un
problema de integración, una aplicación simplemente escribe los datos que desea
compartir con otras aplicaciones dentro de un archivo, en un sistema de archivos,
desde donde otras aplicaciones puedan leerlo y procesarlo. En este punto los
encargados de los proceso de integración tienen la responsabilidad de transformar
los archivos en diferentes formatos en caso que las aplicaciones destino así lo
requieran. Como también de identificar los intervalos de producción de dichos
archivos de acuerdo a la naturaleza del negocio.
Recomendación:
En caso que sea necesario tener la información con una periodicidad mayor a la
que la aplicación productora puede generar, o en el caso que sea necesario
realizar más transformaciones para realizar la integración con nuevos sistemas, se
recomienda usar una solución con estilo de bases de datos compartidas. O en el
caso que los periodos de frecuencia hayan disminuido y esto redunde en
intercambios de información muy pequeños comparados con los identificados en
el diseño de la solución original, se recomienda el uso del estilo de mensajería.
4.1.2.2 Bases de datos compartidas
Figura 3. Bases de datos compartidas [16].
34
Las bases de datos compartidas, al igual que la solución de transferencia de
archivos, se basa en un estilo de integración, en este caso se basa en el estilo de
integración de base de datos compartida (Shared Database) [16]. Cuando se
utiliza este estilo como solución a un problema de integración, se usa una base de
datos la cual es compartida por todas las aplicaciones que participaran en la
solución, de esta manera todas las aplicaciones que comparten su información
tienen la posibilidad de ver la información más actualizada y sin inconsistencias, a
diferencia de la solución de trasferencia de archivos.
Sin embargo para lograr esto, se requiere de un trabajo extenso, por parte de los
integradores, los responsables de las aplicaciones y el administrador de la base de
datos, pues deberá diseñarse el esquema de base de datos que satisfaga las
necesidades de cada una de las aplicaciones involucradas y lo mantenga
consistente, además de las políticas que limitaran el rango de acción y visibilidad a
cada aplicación, a solo lo necesario, de tal manera que se disminuya el riesgo de
deadlocks y por ende cuellos de botella que generen problemas de acceso o hasta
la falta de disponibilidad del servicio.
Recomendación:
En caso que sea necesario integrar la funcionalidad y ya no los datos, se sugiere
el uso del estilo de integración de procedimientos almacenados, o en caso que las
aplicaciones deseen intercambiar información en pequeñas cantidades de datos,
entre ellas y ya no a través de un esquema universal, se sugiere el uso del estilo
de integración de mensajería.
35
4.1.2.3 Invocación remota de procedimientos
Figura 4. Invocación remota de procedimientos [16].
En esta solución, al contrario del estilo de integración de bases de datos
compartidas, no son los datos, si no la funcionalidad la que se comparte con las
demás aplicaciones. Esto se logra a través del llamado de los métodos de las
aplicaciones remotas, los cuales previamente han sido publicados por la
aplicación remota y son accesibles por las aplicaciones cliente.
Este tipo de soluciones, lucen muy agradables para los desarrolladores, debido a
que esta permite llamar los métodos de aplicaciones externas, de la misma
manera como se hace con los métodos locales. Sin embargo esto puede generar
inconvenientes, pues al invocar un método remoto, este no se comporta de la
misma manera que uno local y por esta razón pueden generarse errores
inesperados. Estos pueden deberse a fallas en la red, lo cual evita que el método
pueda ser invocado, o que la aplicación propietaria del método remoto no se
encuentra disponible en este momento. Finalmente otro aspecto a tener en cuenta
en esta solución es la modificación de dichos métodos, pues mientras no se
alteren las firmas de dichos métodos no habrán problemas, pero en caso de
necesitarlo, es necesario informar a los administradores de las aplicaciones
clientes, quienes deben hacer los cambios necesarios para que las invocaciones
36
tengan en cuenta dichas modificaciones, pues de lo contrario se producirá un error
al intentar llamar el método con los parámetros equivocados.
Recomendación:
En caso que se necesitara hacer llamados asíncronos a las aplicaciones, y/o de
buscar un menor acoplamiento entre las aplicaciones a integrar, se sugiere el uso
de mensajería como solución a estos nuevos requerimientos de integración.
4.1.2.4 Mensajería
Figura 5. Mensajería [16].
La mensajería es una tecnología que permite a dos aplicaciones su comunicación
de manera confiable, asíncrona y con alto rendimiento. Al utilizar esta tecnóloga
las aplicaciones se comunican a través de canales enviándose paquetes de datos
denominados mensajes, como se muestra en la Figura 5. Un canal funciona como
una colección de mensajes que puede ser compartido por múltiples aplicaciones y
utilizado concurrentemente. Las aplicaciones actúan con roles bien definidos en la
comunicación: productor y consumidor. Un productor (o emisor) es una aplicación
que envía mensajes escribiéndolos en un canal, mientras que un consumidor (o
receptor) es una aplicación que recibe los mensajes leyéndolos del canal. En un
esquema de este tipo tanto productor como consumidor no tienen que estar
necesariamente disponibles al mismo tiempo para poder comunicarse. Esto se
debe a que la comunicación en sí misma es llevada a cabo a través de los
37
denominados sistemas de mensajería.
Figura 6. Aplicaciones comunicadas usando mensajería.
Sistemas de mensajería
Las capacidades de mensajería son típicamente provistas por sistemas de
software denominados sistema de mensajería o Message Oriented Middleware
(MOM). Los MOMs son componentes especializados en el manejo de mensajes.
Su fin principal es participar como intermediario entre la comunicación de
aplicaciones, logrando desacoplarlas. Las aplicaciones se comunican con los
sistemas de mensajería a través de clientes provistos por los proveedores de
MOMs. Estos brindan interfaces mediante las cuales las aplicaciones pueden
enviar y recibir mensajes como se ilustra en la Figura 7.
Figura 7. Comunicación basada en mensajería a través de un MOM.
38
Debido a que tanto los equipos como las redes que los conectan no son cien por
ciento seguros y confiables, hace relevante la existencia de los MOMs. Por
ejemplo, puede que no siempre que se envíe un mensaje el destinatario esté
activo y disponible, o en caso de que lo esté, podría ser que la red de
comunicación presente no disponibilidad. Previo a la aparición de los MOMs, para
atacar este tipo de problemática se implementaba manualmente la retransmisión
de mensajes hasta asegurarse que el receptor los había procesado. Esto hacía
que cada vez que se deseaba usar mensajería se debieran afrontar una y otra vez
los mismos problemas. Como respuesta a esto, surgen los sistemas de
mensajería, que permiten a quien envía un mensaje olvidarse del mismo luego del
envío, delegando al sistema de mensajería la responsabilidad de asegurar la
entrega del mensaje a su destinatario. A continuación se enumeran los
componentes de un sistema de mensajería así como su responsabilidad según
[16]:
Canales: Son direcciones lógicas en el sistema de mensajería a las cuales
las aplicaciones hacen referencia, y es donde colocan los mensajes para
ser entregados.
Mensajes: Son las entidades que transporta el sistema de mensajería.
Puntos de acceso (endpoints): Es el punto de entrada al sistema de
mensajería. Para poder acceder a un canal, las aplicaciones tienen que
conectarse al sistema de mensajería, y dicha conexión se da a través de un
endpoint.
Tubos y filtros (pipes and filters): Son los componentes encargados de
procesar mensajes complejos en varios pasos de forma flexible.
Enrutador de mensajes (message router): Cuando un mensaje debe ser
procesado pasando por varios destinos, o tiene que seguir cierta ruta
óptima, los enrutadores de mensajes se encargan de tal problemática
independizando a las aplicaciones de este manejo.
39
Componentes de transformación de mensajes: Estos componentes son
filtros particulares que se encargan de realizar transformaciones para poder
comunicar aplicaciones que utilizan formatos de mensaje diferentes.
Proceso de transmisión: El proceso de transmisión de los
mensajes es el proceso más relevante para un sistema de
mensajería y este se descompone en cinco pasos:
Crear: El emisor crea un mensaje y coloca en el los datos que
desea transmitir.
Enviar: El emisor coloca el mensaje en un canal.
Entregar: El sistema de mensajería transporta el mensaje
logrando que este esté disponible para el receptor.
Recibir: El receptor lee el mensaje desde el canal.
Procesar: El receptor extrae los datos del mensaje.
Figura 8. Transmisión de mensajes paso a paso [16].
En la Figura 8, se muestran los pasos descritos anteriormente, además se puede
apreciar la aplicación de los conceptos: Send and Forget y Store and Forward.
Estos se dan en los pasos 2 y 3 respectivamente. Observando el paso 2, se puede
ver que una vez que la aplicación entrega el mensaje en el canal, puede seguir
40
ejecutando dado que esta delegó la entrega del mensaje al sistema de
mensajería. La aplicación confiará en que el receptor recibirá el mensaje, y no
esperará hasta que esto ocurra.
En el paso 2, en el momento que la aplicación entrega el mensaje en el canal, el
sistema de mensajería lo almacena. Luego en el paso 3, el sistema de mensajería
entrega el mensaje redirigiéndolo a la computadora destinataria en la que es
nuevamente almacenado. Este proceso puede ser repetido varias veces hasta que
el mensaje se persista en la máquina destino.
Modelos de comunicación: generalmente los sistemas de mensajería
soportan alguno de estos modelos de comunicación:
Point-to-Point: Este modelo es basado en canales punto a punto.
Cuando una aplicación produce un mensaje, lo coloca en un canal de
este tipo y un receptor recibirá el mensaje. A este tipo de canales se
pueden suscribir varios interesados en recibir mensajes, pero sólo uno
obtendrá cada mensaje. El sistema de mensajería se encargara de
determinar cuál de los destinatarios subscritos obtendrá el mensaje.
Publish-Subscribe: Este modelo permite que una aplicación varios
destinatarios simultáneamente. Para esto, las aplicaciones colocan los
mensajes en un canal que corresponde a cierto tópico definido, el cual
tiene el siguiente comportamiento: los interesados en recibir mensajes
del tópico se suscriben al mismo, el emisor coloca el mensaje en el
canal, y una copia del mismo será entregada a cada uno de los
subscritos al mismo.
Características y servicios de un MOM: en general, los MOMs brindan
varias de las características y servicios que se describen a continuación:
Garantía de Entrega de mensajes: dos aplicaciones que se están
comunicando mediante un MOM no necesitan estar conectadas
41
simultáneamente para que el envío de los mensajes sea exitoso. El
MOM asegura que los mensajes enviados a un destinatario que no esté
conectado, serán entregados al mismo cuando este vuelva a estarlo.
Comunicación Asíncrona: luego que una aplicación envía un mensaje a
otra, el MOM permite que la aplicación cliente siga trabajando sin tener
que esperar que el mensaje sea procesado por el destinatario del
mismo.
Soporte transaccional: el uso de transacciones es soportado, y además
en general se proveen mecanismos de integración con otros recursos,
de forma que las transacciones contra el MOM se puedan incorporar a
transacciones globales.
Entrega en orden, y una sola vez: un MOM garantiza que los mensajes
serán entregados una sola vez, y que además los mismos serán
entregados respetando el orden en que fueron enviados.
Servicios de ruteo de mensajes: permiten definir reglas de ruteo a nivel
de configuración mediante las cuales al enviar un mensaje a un
determinado canal, los mismos son enrutados según las configuraciones
indicadas.
Servicios de notificación: en algunos casos las aplicaciones que envían
los mensajes necesitan tener una forma de saber si el mensaje enviado
ya fue procesado por el consumidor u obtener el resultado generado en
este. Para esto, los MOM’s proveen mecanismos de notificación, de
forma que al ser procesado el mensaje por su receptor se pueda
entregar el resultado de este procesamiento al productor del mismo.
Después de conocer los conceptos básicos y los elementos que componen un
sistema de mensajería, se procederá a la explicación de los patrones de
integración empresarial y su categorización.
42
Los patrones de integración empresarial fueron descritos por primera vez en la
conferencia de Patrones de Lenguaje de Programación [27], en el año 2002 por
Gregor Hohpe [26]. Dichos patrones, son una evolución de los patrones de diseño
de software tradicionales, a un contexto especifico, como lo es la integración de
aplicaciones empresariales. Estos patrones representan las decisiones que
deberán tomarse al momento de integrar dos o más aplicaciones en un contexto
empresarial y las consideraciones que implica tomar esas decisiones.
En la actualidad, se consideran 65 patrones de integración empresarial [16], cuyo
planteamiento se basa en la mensajería asíncrona como piedra angular para la
integración. A continuación se describen las categorías que componen estos
patrones y que parte del problema de comunicación dentro de la mensajería
solucionan.
4.1.2.4.1 Categorización de Patrones de Integración Empresarial
Los patrones de integración empresarial han sido agrupados en seis (6) categorías
[16], como se muestra en la Figura 9, las cuales reflejan el alcance (scope) y la
abstracción de los patrones. Resolviendo de esta manera una situación específica
dentro del proceso de integración.
43
Figura 9. Categorización de Patrones de integración empresarial [16].
Patrones de canal del mensaje
Estos patrones describen los aspectos que deben ser tenidos en cuenta a la hora
de escoger el canal de comunicación entre las aplicaciones, cuando se desea
integrar dos o más sistemas de software. Por lo tanto estos patrones resuelven
distintos problemas de transporte de los mensajes entre aplicaciones. Por ejemplo,
las aplicaciones que envían información por un canal no tienen por qué conocer
cuál es el receptor final de los datos que produce, sin embargo seleccionando un
canal en particular el productor puede asegurarse que quien reciba la información
es quien la esperaba. Apuntan a especificar características de los canales de
comunicación a utilizar, como por ejemplo: si el mensaje es enviado a uno o a
muchos receptores, garantía de entrega de los mensajes que se transportan por el
canal, expiración de los mensajes enviados al canal, entre otros. Los patrones que
integran la categoría son:
44
Point-to-Point Channel.
Publish-Subscribe Channel.
Datatype Channel.
Invalid Message Channel.
Dead Letter Channel.
Guaranteed Delivery.
Channel Adapter.
Messaging Bridge.
Message Bus.
Patrones de construcción del mensaje
Estos patrones, contemplan los aspectos que se encargan de envolver los datos
de interés en un mensaje, para que pueda ser transmitido a través de los canales,
que llevaran la información hacia los interesados en el mensaje. De esta manera
abordan el diseño de los mensajes que envían los diferentes participantes de una
comunicación. Por ejemplo, en el intercambio que se realiza entre dos
aplicaciones, la información se envía insertándola en un mensaje. Apuntan a
especificar la información que contienen los mensajes, su semántica, información
adicional para permitir su procesamiento adecuado, entre otros. Los patrones que
integran esta categoría son:
Command Message.
Document Message.
Event Message.
Request-Reply.
Return Address.
Correlation Identifier.
Message Sequence.
45
Message Expiration.
Format Indicator.
Patrones de enrutamiento del mensaje
Estos patrones, describen las distintas soluciones para proveer enrutamiento e
intermediación para una solución de integración. Dichos patrones están
relacionados con el ruteo de los mensajes desde una aplicación a otra. Por
ejemplo, permiten desacoplar los componentes que realizan en conjunto el
procesamiento en etapas de determinada información, logrando que la secuencia
de pasos a realizar dependa de un conjunto de condiciones. Apuntan a la
configuración de rutas por las que deben pasar los mensajes para su
procesamiento, independizando a quien envía o recibe los mensajes de esta
lógica. Cabe anotar que muchos de los patrones agrupados en esta categoría son
refinamientos o combinaciones del patrón Message Router [16]. Los patrones que
componen esta categoría son:
Content-Based Router.
Message Filter.
Dynamic Router.
Recipient List.
Splitter.
Aggregator.
Resequencer.
Composed Message Processor.
Scatter-Gather.
Routing Slip.
Process Manager.
Message Broker.
46
Patrones de transformación del mensaje
Estos patrones, identifican y dan solución a las diferentes situaciones que
generalmente se presentan cuando se tiene la necesidad de operar entre sistemas
que usan diferentes formatos, por lo tanto estos patrones permiten definir el
manejo de transformaciones que pueden realizarse sobre los mensajes que se
intercambian, en lo que refiere a los diferentes formatos requeridos por cada
aplicación. Así como también modificaciones automáticas que se realizan sobre
los mensajes. Los patrones que integran esta categoría son:
Message Translator.
Envelope Wrapper.
Content Enricher.
Content Filter.
Claim Check.
Normalizer.
Canonical Data Model.
Patrones de puntos de acceso (EndPoint)
Estos patrones, describen cómo las aplicaciones involucradas en la integración,
pueden conectarse al sistema de mensajería, para que puedan enviar y recibir
mensajes. Es decir estos patrones entregan pautas relacionadas a la generación y
el consumo de mensajes, especificando por ejemplo como un productor puede
interactuar con el canal para producir un mensaje o como un receptor puede
comportarse ante la ocurrencia de un nuevo mensaje. Los patrones que integran
la categoría son:
Message Endpoint.
Messaging Gateway.
Messaging Mapper.
Transactional Client.
47
Polling Consumer.
Event-Driven Consumer.
Competing Consumers.
Message Dispatcher.
Selective Consumer.
Durable Subscriber.
Idempotent Receiver.
Service Activator.
Patrones de gestión del sistema
Indican cómo atacar las necesidades de administración, monitoreo y testeo de los
componentes del sistema y de los canales de comunicación. Un claro ejemplo de
esto es la necesidad de extraer información sobre los datos que circulan por los
canales, con el fin de monitorear cual es la capacidad de procesamiento del
sistema en general y poder así detectar caídas en el rendimiento. Los patrones
que integran la categoría son:
Control Bus.
Detour.
Wire Tap.
Message History.
Message Store.
Smart Proxy.
Test Message.
Channel Purger.
La solución de mensajería, está asociada al estilo de integración empresarial de
mensajería (Messaging) [16]. Cuando este estilo es usado como solución a un
problema de integración, es necesario una infraestructura de mensajería, que
48
además de proveer el canal de comunicación entre la aplicación emisor y destino
involucradas en la integración, provea los mecanismos de reintentos necesarios
para que los mensajes enviados entre las aplicaciones, sean entregados y no se
pierdan, además en caso que la aplicación receptor no se encuentre disponible, la
infraestructura deberá estar en la capacidad de almacenar los mensajes enviados
en un datastore, y entregarlos a su receptor cuando este se encuentre de nuevo
disponible.
Claramente se observa que este tipo de soluciones, están soportadas por
infraestructuras que promueven la fiabilidad de la comunicación, además de un
esquema de comunicación asíncrona entre las aplicaciones involucradas en el
proceso de integración, lo que a su vez permite que las soluciones de integración
puedan cada vez mas tener un comportamiento más parecido a la naturaleza de
los negocios, pues es posible modelar los eventos de negocio necesarios para la
ejecución de los procesos internos y la de aquellos que requieran de la
comunicación de otras aplicaciones con las que se desea integrar.
Recomendación:
Después de tomar la decisión que la solución escogida será el estilo de
integración de mensajería, se sugiere tener en cuenta, estas mínimas
consideraciones:
Debe definirse un canal o Message Channel, el cual se utilizara como
medio de comunicación del mensaje.
A donde deben ser enviados los mensajes.
Qué tipo de formato utilizar para el mensaje.
Implementar un traductor para desacoplar las aplicaciones a integrar.
Conectar las aplicaciones a la infraestructura de mensajería por medio de
un Message Endpoint.
49
La búsqueda de las soluciones conocidas permitió refinar las variables de entrada
al método definidas en el grupo de necesidades encontrando que mas que
necesidades estos cuatro (4) estilos de integración son soluciones y básicamente
las necesidades se pueden clasificar como: compartir datos y compartir
funcionalidad.
4.1.3 Etapa III Determinar el conjunto de buenas prácticas
El objetivo de la etapa es determinar el conjunto de buenas prácticas aplicables a
la integración de aplicaciones empresariales, basado en la recopilación a través de
la consulta directa a un grupo de expertos y recopilación de información en la
literatura existente. El resultado del trabajo realizado se detalla a continuación.
4.1.3.1 Consulta a expertos
La selección de los miembros de este grupo se realizó fundamentalmente porque
son personas con una trayectoria que supera los 5 años en la construcción de
importantes proyectos de integración de aplicaciones empresariales, definición de
estándares y mecanismos de integración de las aplicaciones del core de los
negocios para las empresas en que ellos trabajan.
Al consultar las buenas prácticas, que estos expertos aplican en su trabajo diario,
se observó que las respuestas se enfocaban a cada una de las necesidades de
integración que se identificaron en la caracterización de los casos de negocio. En
la mayoría de los casos los expertos resaltaron los pros y los contras de la buena
práctica. Por lo anterior la descripción de estas buenas prácticas, se hace
agrupada por cada una de las necesidades de integración y se identifican las
ventajas y desventajas de utilizarla:
50
4.1.3.1.1 Datos
Para la necesidad de integración compartir datos, las buenas prácticas,
entregadas por el grupo de expertos, se resume a continuación:
Uso de formato: por estándar, a nivel mundial el formato de los archivos
para hacer integración debe ser XML. Las ventajas están en la facilidad
para realizar las validaciones de los datos a través del uso de XSD o DTD,
en la facilidad que tienen para ser leídas por parte de los humanos y
rapidez con la que son validados por las maquinas. La desventaja está en
el tamaño de los archivos, los archivos en formato XML siempre son de
mayor tamaño que los archivos de otros formatos; esto se debe a que la
meta-data está inmersa en los archivos.
Generación de archivos: la recomendación entregada en este sentido es
que los archivos deben ser generados por los sistemas dueños de los
datos, en lugar que la aplicación destino o una tercera aplicación, genere el
archivo ingresando a los datos de la aplicación origen.
Transporte: para este propósito existen en el mercado herramientas que
utilizan como medio de transporte protocolos especializados como son:
FTP, SFTP o SCP. El uso de buses de servicios no se recomienda para
realizar el transporte de archivos.
Bases de datos: Como buenas prácticas en el caso cuando existe la misma
entidad de base de datos en ambos sistema se recomienda:
Realizar sincronización con replicación.
Definir las políticas de sincronización como por ejemplo la periodicidad.
Utilizar en lo posible los tipos de datos nativos del motor de base de
datos.
51
Definir un buen gobierno de datos. Quien es el dueño de los datos.
Si están en la misma instancia se debe usar sincronización en línea ya
que no es necesario hacer uso de la red de datos. La práctica más
usada y recomendada por los expertos es utilizar gatillos, también
conocidos por la palabra en inglés trigers, siempre y cuando se tengan
bien establecidos los accesos y permisos sobre las tablas.
Si están diferente instancias se recomienda crear una tabla temporal de
trabajo, para posteriormente, a través de un proceso asíncrono, realizar
la integración.
4.1.3.1.2 Funcionalidades
Para la necesidad de integración compartir funcionalidad, las buenas prácticas,
entregadas por el grupo de expertos, se resume a continuación:
Mecanismo de exposición: para realizar la exposición de funcionalidades el
estándar adoptado por la industria son los servicios web usando SOAP o
Restful.
Consulta de información: Los servicios web son muy útiles para consumir
lógica de negocio de otras aplicaciones, sin embargo si los servicios
retornan bloques de datos mayores de 5MB, los servicios web no son
recomendados. Para retornar bloques de resultados de más de 5MB es
mejor usar protocolos binarios tales como RMI-IIOP, DCOM o RPC.
Llamado a procedimientos: es el mecanismo recomendado para realizar la
invocación de funcionalidades de forma síncrona.
52
4.1.3.1.3 Datos y funcionalidades
El grupo de expertos entregó un conjunto de buenas prácticas aplicables a las
necesidades compartir datos y compartir funcionalidad, las cuales se describen a
continuación:
Los sistemas de mensajería entre aplicaciones Message Oriented
Middleware son el mejor mecanismo asíncrono de integración en las
aplicaciones empresariales. El principal problema de este mecanismo es
que los protocolos no son abiertos y cada proveedor tiene su mecanismo
propietario de integración.
Formato de los mensajes: Si la integración es entre sistemas que tienen el
soporte nativo para el MOM lo mejor es usar mensajes binarios y no
mensajes en modo texto. Si la integración es entre sistemas que no tiene
soporte nativo para MOM, se deben usar mensajes de texto en formato
XML o JSON.
Mecanismo de entrega de los mensajes: para entrega del mismo mensaje
desde una aplicación hacia diferentes aplicaciones se debe usar Publish
and Subscribe. Para la entrega de mensajes solo entre dos aplicaciones, no
se conoce en el mediano plazo la inclusión de otras aplicaciones
interesadas en consumir este mensaje, se debe usar Point to Point.
4.1.3.2 Buenas prácticas extraídas de la literatura
En la revisión de la literatura se encontraron las siguientes buenas prácticas o
recomendaciones para cada una de los estilos de integración:
4.1.3.2.1 Buenas prácticas para la transferencia de archivos
La transferencia de archivos, ha sido una de las tecnologías comúnmente más
utilizadas en el mundo, por las empresas de TI para intercambiar información [29],
53
Sin embargo la complejidad de los negocios y la necesidad continua de tener
respuestas con tiempos cada vez más ajustados a las necesidades reales, han
desplazado a los antiguos procesos en batch, que comúnmente se ejecutan fuera
de línea y normalmente son concebidos para procesar grandes volúmenes de
información [30], debido a su naturaleza desatendida. Todo lo anterior unido a la
aparición de las herramientas de EAI [16], como respuesta a las necesidades cada
vez mas crecientes de integrar las aplicaciones de una o múltiples negocios,
generaron el surgimiento de tecnologías tales como la mensajería, que permitió
una comunicación con solicitudes y operaciones más granulares que las que se
alcanzaban con los procedimientos anteriores [29].
Sin embargo, la existencia de sistemas legados de misión crítica, en las empresas
actuales, renovaron el enfoque de la transferencia de archivos, y le ha permitido
mantenerse como un elemento fundamental dentro de las herramientas de EAI
[29], debido a que su uso puede ser estratégico para:
Reducir los riesgos del negocio.
Entregar un nivel de retorno (RoI) atractivo.
Mayor velocidad de entrega para nuevas implementaciones y/o servicios.
Permitir rápidamente la intercomunicación con los sistemas de otras
empresas (B2B).
A continuación se describen cinco (5) buenas prácticas para la implementación de
este estilo de integración:
Confirmar la transmisión de los archivos: todos aquellos que están
involucrados en la transferencia de uno o varios archivos generalmente
desean saber si estos han arribado satisfactoriamente a su destino final, por
esta razón una confirmación explicita es bastante útil para saber si el o los
54
archivos han sido recibidos correctamente [32]. Para esto se puede generar
un mensaje de retroalimentación al cliente a través de:
Colocando un archivo con la información de confirmación en un FTP
del emisor.
Enviando un correo electrónico.
Haciendo una invocación a un servicio web, informando la
confirmación.
Colocando un mensaje en una cola.
Almacenando el registro en una tabla de base de datos.
Fallas en la transmisión y avisos: cuando la transferencia de un archivo
falla, puede deberse a causas muy comunes como son [32]:
Problemas de red.
El servidor con el que se tiene la conexión no se encuentra
disponible.
No es posible autenticarse al servidor.
La ruta del archivo, no se encuentra disponible.
No hay permisos suficientes para acceder al archivo.
Una buena práctica en este caso es la de las “soft fail” [32], que consisten
en el reintento de la operación sin intervención humana, en un período de
una hora, sin embargo después de cinco (5) “soft fail” seguidas, deberá
generarse una “hard fail” que de inmediato generara una notificación al
personal encargado de los servidores de archivos, tanto los de recepción
como los de emisión de los archivos.
Verificación de falla de archivos: aún después de transferir el archivo
satisfactoriamente, es posible que dicho archivo no tenga el formato
esperado, o que el archivo esté corrupto. En este escenario las “soft fail” y
55
las “hard fail” no son útiles, y por ende se sugiere seguir las siguientes
buenas prácticas:
Verificar los archivos después de recibidos, por parte del receptor.
Verificar los archivos de gran tamaño, antes de transmitirlos, por
parte del emisor.
Enviar notificación a los encargados de recibir el archivo y al receptor
en caso que la verificación falle en cualquiera de los casos
anteriormente descritos.
Mejor protocolo: a menudo se presentan ciertas restricciones sobre los
protocolos que podrán ser usado para la transferencia de los archivos, sin
embargo cuando dicha restricción no exista y se pueda escoger SFTP (SSH
File Protocol) [32], se recomienda este protocolo debido a que es
ampliamente usado, soportado y bien conocido por un gran número de
comunidades en Internet, además de su seguridad.
Usar fechas, horas y minutos en la convención de nombramiento de
archivos: generalmente nuevos archivos son generados diariamente y en
algunos casos son generados son generados cada hora, en este caso para
evitar confusión y para prevenir que los viejos archivos sean sobre escritos
con los últimos datos, por esta razón el uso de fechas, hora y minutos en
los nombres de los archivos permiten alcanzar esta meta [32].
Finalmente siguiendo estas buenas prácticas, pueden ser construidos ambientes
robustos para la transferiría de archivos dentro de una organización o entre sus
proveedores o clientes (B2B).
56
4.1.3.2.2 Buenas prácticas para bases de datos compartidas
Cuando se requiere que varias aplicaciones, almacenen los datos que quieren
compartir en una base de datos en común, es necesario dar acceso a la base de
datos a cada una de las aplicaciones involucradas, sin embargo esto no es un
enfoque favorable, debido a que expone los datos a diferentes clientes, quienes
pueden no respetar las restricciones que se han establecido, pero no codificado
[33]. Por esta razón un par de buenas prácticas para evitar esta situación son:
Limitar el acceso de los clientes, solo a los objetos de interés para el.
Utilizar vistas o snapshots, para la extracción de la información, esto
previene que los clientes observen las estructuras de las entidades y la
información que no es de su interés [33].
Permitir la manipulación de los datos a través del uso de procedimientos
almacenados, que permitan un manejo transparente de las transacciones y
brinden encapsulamiento de las operaciones y entidades que se ven
afectadas [33].
El uso de estas prácticas para compartir bases de datos, no son por si solas la
mejor solución, pues deben estar acompañadas por una correcta verificación del
administrador de la base de datos, quien definirá con ayuda de lo descrito por el
cliente, la información que este realmente necesita y la definición de posibles
casos que llevarían a abortar la transacción al momento de modificar los datos,
además de identificar los posibles escenarios, que podrían generar inconsistencias
y como evitarlas pues no se debe olvidar que la información puede estar siendo
manipulada por varias aplicaciones al tiempo.
4.1.3.2.3 Buenas prácticas para invocación remota de procedimientos
En la revisión de la literatura realizada no se encontraron buenas prácticas para
este estilo de integración. Por lo tanto en lo que sigue del desarrollo del método
trabajaremos con las buenas prácticas para invocación remota de procedimientos
identificadas en la consulta directa a expertos.
57
4.1.3.2.4 Buenas prácticas para mensajería
En la actualidad, los sistemas de mensajería, se muestran como los medio de
comunicación más adecuados para la intercomunicación de aplicaciones
empresariales [16], por esta razón y después de su uso intensivo por parte de
millones de desarrolladores, se encuentra en la literatura [16] las buenas prácticas
en un grupo de patrones que se han denominado patrones de integración
empresarial, como se expuso en la etapa II de esta fase, y que se basan en el uso
del estilo de integración de mensajería como pilar principal para la integración.
Como se mostró en esta etapa, existen buenas prácticas conocidas para cada
estilo de integración, por lo tanto no existe un estilo mejor que otro, sino que cada
situación indica qué estilo debe ser usado, o en algunos casos, cuáles estilos
deben ser combinados [31]. A continuación se presentan en la Tabla 1, algunos
pros y contras de cada uno de los estilos.
Estilo de integración Ventajas Desventajas
Transferencia de archivos
Simple,
Interoperable.
No es transaccional, ni para
necesidades en tiempo real.
Bases de datos
compartidas
Simple,
transaccional.
Puede ser lento y difícil de
evolucionar.
Invocación remota de
procedimientos
Simple, puede ser
rápido.
No es interoperable, síncrono y
altamente acoplado.
Mensajería
Asíncrono,
escalable. Complejo.
Tabla 1 Ventajas y desventajas de los estilos de integración [31].
58
Para finalizar esta sección de buenas prácticas, se presenta a continuación un
cuadro que ofrece una primera alternativa hacia el uso de Frameworks, en caso de
requerir alguno de estos estilos.
Estilo de integración Framework
Transferencia de archivos Spring resource abstraction, Spring Batch,
GoAnyWhere, Kettle
Bases de datos
compartidas
Spring data access (JDBC, Object-Relational
Mapping, transaction)
Invocación remota de
procedimientos
Spring Remoting (Remote Method Invocation,
HttpInvoker, Hessian, Burlap), EJB Session
Stateless
Mensajería
Spring JmsTemplate, Spring message container
listeners, Spring Integration, Message Driver Bean,
EJB
Tabla 2 Estilos de integración y los Frameworks que los implementan.
4.2 Fase II Diseño del método
Conforme a la metodología establecida, se desarrolló la fase II del proyecto. El
resultado de las actividades realizadas se detalla a continuación:
4.2.1 Etapa I: Definición de categorías
Para la definición de las categorías en las que se pueden clasificar los casos de
negocio que son objeto del método diseñado, se tomó la decisión de
categorizarlos de acuerdo a la necesidad de integración que se busca resolver. La
decisión se tomó en un inicio teniendo en cuenta que la necesidad de integración
es la que prácticamente define el caso de negocio y que las otras características
son complementos que permiten particularizar aspectos del mismo. Durante la
etapa de definición de filtros se validó completamente la decisión aquí tomada;
pues en esta etapa se pudo evidenciar que la necesidad de integración es una
59
sola para cada caso de negocio y que las otras variables se pueden presentar
simultáneamente en la caracterización de este; siendo la necesidad de
integración la que determina la combinación que se puede presentar entre demás
variables. Por lo anterior en esta etapa se definieron:
Categoría 1: casos de negocio para compartir datos.
Categoría 2: casos de negocio para compartir funcionalidad.
4.2.2 Etapa II: Soluciones conocidas aplicables por categoría
Para la Categoría 1, casos de negocio regidos por datos, las soluciones conocidas
aplicables son [16]:
Transferencia de Archivos
Bases de datos compartidas
Mensajería
Para la Categoría 2, casos de negocio regidos por funcionalidad, las soluciones
conocidas aplicables son [16]:
Invocación Remota de procedimientos
Mensajería
4.2.3 Etapa III: Buenas prácticas aplicables por categoría
Esta etapa de la metodología, básicamente se resolvió en la Etapa III de la Fase I
en la que las buenas prácticas quedaron clasificadas de acuerdo a las
necesidades de integración y en la Etapa I de la Fase II en la que las necesidades
de integración se definieron como las categorías del método.
4.2.4 Etapa IV: Definición de filtros
Como se definió, en la Etapa I de la Fase I, determinar el conjunto de variables
con las que se puede caracterizar un caso de integración de aplicaciones
empresariales se identificaron cuatro (4) grupos de variables. El objetivo de esta
etapa de la metodología fue identificar cuáles variables son excluyentes y cuáles
son complementarias; identificación que corresponde al insumo necesario y
60
suficiente para la creación de los filtros que conducirán a la correcta la
caracterización del caso de negocio.
4.2.4.1 Combinación de variables
La identificación de estas exclusiones o complementos se realizó en dos niveles:
En las variables pertenecientes al mismo grupo y entre las variables que
pertenecen a grupos distintos. A continuación se muestra el proceso realizado y el
resultado de esta identificación, para lo cual es importante resaltar que los casos
en que las variables se subdividen en varias sub-variables, el análisis se realizó a
nivel de sub-variables.
4.2.4.1.1 Entre el mismo grupo
El propósito de esta actividad fue evaluar la compatibilidad entre las variables de
un mismo grupo. El resultado de este trabajo se muestra a continuación:
Grupo I: Tipos de Aplicaciones
Para realizar esta actividad se parte de dos premisas fundamentales: Una
aplicación solo puede tener un único tipo y se excluyen las aplicaciones tipo
Tiempo Real que al ser evaluadas por la encuesta no obtuvieron una calificación
promedio relevante para este estudio; Como se trabaja con un aplicación origen y
una aplicación destino el análisis se centró en identificar las posibles
combinaciones de tipos de aplicaciones entre ellas. Para ello se elaboró una
matriz en la que las filas corresponden a los tipos de aplicación origen y las
columnas a los tipos de aplicación destino; así, la casilla de intersección entre fila
y columna marcada con un uno (1) indica que la combinación es posible en caso
contrario se marca con un (0), ver Anexo 2.1 Tipos de aplicaciones. Después de
realizar el análisis de cada una de las combinaciones se encuentra que no hay
limitantes en cuanto al tipo de la aplicación origen y destino, por lo cual el
resultado de esta actividad arroja una matriz con todas las posiciones con valor
61
uno (1) lo que define que todas las combinaciones son posibles y que en esta
actividad no se identificaron filtros.
Grupo II: Necesidades
Como se ha expuesto en el planteamiento del problema, cada necesidad de
integración puede tener una o varias soluciones conocidas; por lo cual el alcance
del diseño del método se restringe al manejo de una única necesidad de
integración por cada caso de negocio; en la ocasión en que el mismo caso de
negocio contemple diferentes necesidades de integración, el caso de negocio
debe ser caracterizado tantas veces como necesidades de integración contemple.
Por lo anterior en esta actividad no se identificaron filtros.
Grupo III: Criterios y Restricciones
Se elaboró una matriz en la que las que tanto las filas como las columnas
corresponden a cada uno de los criterios y restricciones; la casilla de intersección
entre fila y columna marcada con un uno (1) indica que la combinación es posible
en caso contrario se marca con un (0), ver Anexo 2.2 Criterios y restricciones. En
el análisis realizado se encontraron criterios y restricciones que son mutuamente
excluyentes, a continuación se detallan las exclusiones resultantes:
Cada variable consigo misma: Debido a que la herramienta utilizada para el
análisis es una matriz en la intersección de filas y columnas surgió esta
relación. Sin embargo en el diseño del método esta relación no existe así
que la diagonal de la matriz se marcó con valor cero (0). En este análisis
no hubo identificación de filtros.
Sub-variables asociadas a la misma variable: Por la definición de cada sub-
variable, en el análisis se encontró que las sub-variables son mutuamente
excluyentes entre sí cuando están asociadas a la misma variable. Por lo
anterior las casillas de intersección entre sub-variables asociadas a la
misma variable se marcaron con cero (0). En este análisis se identificó el
62
Filtro 1. Es importante resaltar que esta exclusión tiene contenida la
exclusión del numeral anterior.
Intrusión no permitida: Por definición de la sub-variable Intrusión no
permitida y de la sub-variable Modificar la aplicación para usar un formato
de datos común, se encuentra la mutua exclusión. Es este análisis se
identificó el Filtro 2.
Formato de los datos: Por definición de la variable Formato de los datos y
de la sub-variable Funcionalidad se encuentra la mutua exclusión. Es este
análisis se identificó el Filtro 3.
Latencia en el intercambio de datos: Por definición de la variable Latencia
en el intercambio de datos y de la sub-variable Funcionalidad se encuentra
la mutua exclusión. Es este análisis se identificó el Filtro 4.
Destino NO siempre disponible y síncrona: Por definición de la sub-variable
Síncrona y de la sub-variable Destino NO siempre disponible se encuentra
la mutua exclusión. Es este análisis se identificó el Filtro 5.
Destino NO siempre disponible y Funcionalidad: Por definición de la sub-
variable Funcionalidad y de la sub-variable Destino NO siempre disponible
se encuentra la mutua exclusión. En este análisis se identificó el Filtro 6.
Además en el análisis también se identificó que la aplicación que provee la
funcionalidad siempre es la aplicación destino lo cual llevó a identificar el
Filtro 6 Funcionalidad y destino.
Como resultado de este análisis se obtuvo una matriz simétrica debido a que las
exclusiones encontradas entre las sub-variables son mutuas.
Grupo IV: Características de calidad
En este grupo el análisis se orientó con la revisión de la literatura [25], en la que se
encuentra ampliamente documentada la exclusión entre las características de
calidad. Se identificaron cuatro (4) filtros como resultado de esta revisión:
63
Filtro 7: Características de calidad que se ven afectados negativamente al
definir funcionalidad como requerimiento
Filtro 8: Características de calidad que se ven afectados negativamente al
definir eficiencia de rendimiento como requerimiento
Filtro 9: Características de calidad que se ven afectados negativamente al
definir Capacidad de operación como requerimiento
Filtro 10: Características de calidad que se ven afectados negativamente al
definir seguridad o compatibilidad o capacidad de transferencia como
requerimiento
Se elaboró una matriz en la que las que tanto las filas como las columnas
corresponden a cada uno de las características de calidad; la casilla de
intersección entre fila y columna marcada con un uno (1) indica que la
combinación es posible en caso contrario se marca con un (0), ver Anexo 2.3
Características de calidad.
4.2.4.1.2 Entre los diferentes grupos
Como parte del análisis se definió la siguiente premisa fundamental: Las variables
del grupo características de calidad no son excluyentes con las variables de
ningún otro grupo, porque las características de calidad pueden ser requeridos
independientemente de la necesidad de integración, los tipos de aplicaciones y los
criterios y restricciones. Por lo anterior solo se evaluaron las exclusiones entre los
siguientes grupos:
Criterios y Restricciones Vs. Tipo de Aplicación Origen
Se elaboró una matriz en la que las que las filas corresponden a los criterios y
restricciones y las columnas corresponden a los tipos de aplicaciones origen; la
casilla de intersección entre fila y columna marcada con un uno (1) indica que la
combinación es posible en caso contrario se marca con un (0), para este análisis
se separaron los tipos de aplicaciones transaccionales 1 y 2 que se habían venido
64
manejando, en los anteriores análisis como uno solo; lo anterior debido a que la
diferencia entre estos dos tipos de aplicaciones es el tipo de estructuras de datos
que manejan y que para este análisis es requerido revisar por separado, ver
Anexo 2.4 Criterios y restricciones tipo de aplicación origen. En el análisis
realizado se encontró que en por la definición de aplicación tipo batch, es
excluyente con las sub-variables: funcionalidad y aplicación destino no siempre
disponible en este segundo caso solo se puede resolver cuando hay tecnología
disponible que lo permita. En este análisis se identificaron los filtros 11A y 11B. Y
el filtro 12 que corresponde al tipo de aplicaciones transaccionales 1 que no
procesan datos complejos, por tanto buscar un formato de datos extensible en el
tiempo se considera excluyente.
Criterios y Restricciones Vs Tipo de Aplicación Destino
Se elaboró una matriz en la que las que las filas corresponden a los criterios y
restricciones y las columnas corresponden a los tipos de aplicaciones destino; la
casilla de intersección entre fila y columna marcada con un uno (1) indica que la
combinación es posible en caso contrario se marca con un (0), para este análisis
se separaron los tipos de aplicaciones transaccionales 1 y 2 que se habían venido
manejando, en los anteriores análisis como uno solo; lo anterior debido a que la
diferencia entre estos dos tipos de aplicaciones es el tipo de estructuras de datos
que manejan y que para este análisis es requerido revisar por separado, ver
Anexo 2.5 Criterios y restricciones tipo de aplicación destino. En el análisis
realizado se encontró el Filtro 13. En el cual se define:
Filtro 13A: Batch y criterios y restricciones necesarias: si se define que el
tipo de aplicación origen es batch, se encontró que las siguientes sub-
variables del grupo criterios y restricciones deben estar presentes: intrusión
permitida, compartir datos, comunicación síncrona y destino siempre
disponible.
65
Filtro 13B: Batch y criterios y restricciones excluyentes: el resultado del
numeral anterior implica que las sub-variables: intrusión no permitida,
compartir funcionalidad, comunicación asíncrona y destino No siempre
disponible; son excluyentes con la variable bases de datos compartidas.
Filtro 13C Batch criterios y restricciones que no aplican: las variables
formato de los datos, latencia en el intercambio de datos y selección de la
tecnología no son requeridas ni excluyentes con la necesidad bases de
datos compartidas; pues no es relevante que estén presentes o ausentes
al analizar este tipo de aplicación.
El filtro 14 que corresponde al tipo de aplicaciones transaccionales 1 que no
procesan datos complejos, por tanto buscar un formato de datos extensible en el
tiempo se considera excluyente.
4.2.4.2 Utilización de Filtros:
En esta actividad se muestran los filtros identificados en la actividad anterior de
manera consolidada. Se parte como premisa que la necesidad de integración es la
que determina la caracterización del caso de negocio y por ende es la que define
los valores que pueden tomar las demás variables y sub-variables. A continuación
se muestran los filtros y el orden en que se aplicarán
Identificar necesidad de integración: Como se había expuesto
anteriormente, se parte de la premisa que la necesidad de integración es
una sola para el caso de negocio.
Una vez identificada la necesidad de integración, datos o funcionalidad, la
siguiente variable a identificar es el tipo de aplicación origen; se establece
que una aplicación origen solo puede tener un único tipo.
Una vez identificada la necesidad de integración y el tipo de aplicación
origen, la siguiente variable a identificar es el tipo de aplicación destino; al
igual que en el punto anterior la aplicación destino solo puede tener un
único tipo, en caso que se requiera integrar una aplicación origen con varias
66
destino cada integración se considera un caso de negocio distinto y debe
evaluarse por separado en el método. No hay exclusiones a evaluar entre
los tipos de aplicaciones origen y destino;
Con la necesidad de integración y los tipos de aplicaciones origen y destino
identificadas, se pasa a identificar los criterios y restricciones de
integración. En este punto se pueden identificar varios criterios y
restricciones para un caso de negocio. Las exclusiones que se deben
evaluar son:
Necesidad de integración identificada vs. Criterios y restricciones.
Tipo de aplicación origen identificada vs. Criterios y restricciones.
Tipo de aplicación destino identificada vs. Criterios y restricciones.
Criterios y restricciones vs. Criterios y restricciones.
Características de calidad vs. Características de calidad.
4.2.5 Etapa V: El método diseñado
Como resultado de esta fase de la metodología, se resume en los siguientes pasos:
Paso1: Documentar el caso de negocio determinando los valores para cada
una de las variables de caracterización definidas. Con ello se definen las
variables de entrada al método.
Paso2: Aplicar los filtros, en el orden descrito en la última etapa de esta
fase, para con ello encontrar la correcta caracterización del caso de negocio
y por consiguiente asociarlo a una de las siguientes categorías:
Categoría 1: casos de negocio regidos datos.
Categoría 2: casos de negocio regidos por funcionalidad.
Paso3: Buscar las soluciones conocidas aplicables a la categoría
encontrada.
Paso4: Buscar las buenas prácticas aplicables a la categoría encontrada.
Paso5: Entregar la soluciones conocidas en el orden de aplicabilidad.
67
4.3 Fase III Prueba del diseño del método
Conforme a la metodología establecida se desarrollo la tercera y última fase del
proyecto. Los resultados se muestran a continuación:
4.3.1 Etapa I: Refinamiento del método
El objetivo de esta etapa es encontrar una serie de criterios que permitan validar el
conjunto de recomendaciones que el método entrega. Para ello se trabajó en
elaborar un conjunto de filtros adicionales que trabajan sobre las soluciones
conocidas y las demás variables de caracterización. Estos filtros adicionales se
describen a continuación.
4.3.1.1 Soluciones conocidas Vs. Criterios y Restricciones
Se elaboró una matriz en la que las que las filas corresponden a las necesidades
de integración y las columnas corresponden a cada uno de los criterios y
restricciones; la casilla de intersección entre fila y columna marcada con un uno
(1) indica que la combinación es posible en caso contrario se marca con un (0),
ver Anexo 3.1 Soluciones conocidas criterios y restricciones. En el análisis
realizado se encontraron necesidades de integración con criterios y restricciones
que son mutuamente excluyentes, a continuación se detallan las exclusiones
resultantes:
4.3.1.1.1 Transferencia de Archivos y Funcionalidad:
Por definición de la sub-variable Funcionalidad y de la variable Transferencia de
Archivos se encuentra la mutua exclusión. En este análisis se identificó el Filtro 15.
4.3.1.1.2 Bases de Datos Compartidas
Por definición de la variable Bases de datos compartidas se encuentra la exclusión
con la todas las variables del grupo criterios y restricciones. En este análisis se
identificó el Filtro 16. En el cual se define:
68
4.3.1.1.3 Filtro 16A
Requisitos de criterios y restricciones necesarios para la solución bases de datos
compartidas: si se define que la solución es compartir bases de datos, se encontró
que las siguientes sub-variables del grupo criterios y restricciones deben estar
presentes: intrusión permitida, compartir datos, comunicación síncrona y destino
siempre disponible.
4.3.1.1.4 Filtro 16B
Criterios y restricciones excluyentes para la solución bases de datos compartidas:
el resultado del numeral anterior implica que las sub-variables: intrusión no
permitida, compartir funcionalidad, comunicación asíncrona y destino, no siempre
disponible; son excluyentes con la variable bases de datos compartidas.
4.3.1.1.5 Filtro 16C
Criterios y restricciones para las que no aplica la solución bases de datos
compartidas: las variables formato de los datos, latencia en el intercambio de
datos y selección de la tecnología no son requeridas ni excluyentes con la solución
bases de datos compartidas; pues no es relevante que estén presentes o
ausentes al analizar la solución bases de datos compartidas.
4.3.1.1.6 Invocación Remota de Procedimientos
Por definición de la solución Invocación Remota de Procedimientos se encuentra
la exclusión con todas las variables y sub-variables del grupo criterios y
restricciones asociadas al intercambio de datos: formato de los datos, latencia en
el intercambio de datos y datos. En este análisis se identificó el Filtro 17.
4.3.1.1.7 Mensajería
Por definición de la solución Mensajería se encuentra la exclusión la sub-variable
del grupo criterios y restricciones selección de la tecnología no disponible. En este
análisis se identificó el Filtro 18.
69
4.3.1.2 Soluciones Conocidas Vs. Tipo de Aplicación Origen
Se elaboró una matriz en la que las que las filas corresponden a las soluciones
conocidas de integración y las columnas corresponden a los tipos de aplicaciones
origen; la casilla de intersección entre fila y columna marcada con un uno (1)
indica que la combinación es posible en caso contrario se marca con un (0), ver
Anexo 3.3 Soluciones conocidas tipo de aplicación origen. En el análisis realizado
se encontró que la solución conocida de integración invocación remota de
procedimientos es excluyente con el tipo de aplicación origen batch. En este
análisis se identificó el filtro 19.
4.3.1.3 Soluciones Conocidas Vs. Tipo de Aplicación Destino
Se elaboró una matriz en la que las que las filas corresponden a las soluciones
conocidas de integración y las columnas corresponden a los tipos de aplicaciones
destino; la casilla de intersección entre fila y columna marcada con un uno (1)
indica que la combinación es posible en caso contrario se marca con un (0), ver
Anexo 3.4 Soluciones conocidas tipo de aplicación destino. En el análisis realizado
se encontró que en por la definición de aplicación tipo batch, la única solución
conocida de integración que puede tener como aplicación destino tipo batch es la
de bases de datos compartidas. En este análisis se identificó el filtro 20.
En este punto se define incluir un nuevo paso para realizar la aplicación de los
filtros encontrados en esta etapa. El método refinado se define en los siguientes
pasos:
Paso1: Documentar el caso de negocio determinando los valores para cada
una de las variables de caracterización definidas. Con ello se definen las
variables de entrada al método.
Paso2: Aplicar los filtros para con ello encontrar la correcta caracterización
del caso de negocio y por consiguiente asociarlo a una de las siguientes
categorías. La aplicación de los filtros debe realizarse en el siguiente orden:
70
Identificar necesidad de integración: La necesidad de integración es
una sola para el caso de negocio
Con la necesidad de integración definir la categoría del caso de
negocio
Una vez identificada la necesidad de integración, la siguiente
variable a identificar es el tipo de aplicación origen
Una vez identificada la necesidad de integración y el tipo de
aplicación origen, la siguiente variable a identificar es el tipo de
aplicación destino
Con la necesidad de integración y los tipos de aplicaciones origen y
destino identificadas, se pasa a identificar los criterios y restricciones
de integración. En este punto se pueden identificar varios criterios y
restricciones para un caso de negocio. Las exclusiones que se
deben evaluar son:
o Tipo de aplicación origen identificada vs. Criterios y restricciones
o Tipo de aplicación destino identificada vs. Criterios y
restricciones
o Criterios y restricciones vs. Criterios y restricciones
o Características de calidad vs. Características de Calidad
Paso3: Buscar las soluciones conocidas aplicables a la categoría
encontrada
Paso4: Aplicar los filtros:
Soluciones conocidas vs. criterios y restricciones
Soluciones conocidas vs. tipo de aplicación origen
Soluciones conocidas vs. tipo de aplicación destino
Paso5: Buscar las buenas prácticas aplicables a la categoría encontrada.
Paso6: Entregar la soluciones conocidas y buenas prácticas aplicables a la
categoría
71
4.3.2 Etapa II: Aplicación del método diseñado
Para la prueba del método se recolectaron diez (10) casos reales de integración
de aplicaciones presentados en los dos últimos años en los proyectos de
integración de aplicaciones del grupo empresarial Coomeva.
Cada uno de los casos de negocio se sometió a los seis (6) pasos del método
diseñado. La documentación de la aplicación del método para los diez (10) casos
de negocio probados se encuentra detallada en el Anexo3.5 Caracterización de
los casos de negocio y soluciones
Paso1: Durante la ejecución del Paso1 se observó que las variables
identificadas y los valores definidos para ellas, fueron las necesarias y
resultaron suficientes para la caracterización de los casos de negocio.
Paso2: Durante la ejecución del Paso2 se encontró que en la definición de
los filtros faltó la evaluación de la existencia de una posible exclusión entre
los criterios Formato de datos y Selección de la tecnología, en cuanto a que
en algunos casos puede ser requerido utilizar un mediador que homologue
los datos lo que implica que deba existir tecnología para realizarlo. En este
análisis y por tratarse de solo algunos casos se agregó a la matriz de
combinación de variables de criterios y restricciones la Evaluación 1. La
matriz actualizada se muestra en el Anexo 3.2 Criterios y restricciones
refinado. Adicional a lo anterior, durante la aplicación de filtros, se encontró
que es necesario caracterizar el caso de negocio con una característica de
calidad principal que determinará la inclusión o exclusión de las restantes
características en la caracterización del caso de negocio.
Paso3: Durante la ejecución se observó que realizar el Paso3 se obtiene
como consecuencia inmediata una vez se ha realizado el paso2 de manera
adecuada.
72
Paso4: Durante la ejecución del paso4 se observó que los filtros
identificados, fueron los adecuados para refinar la caracterización de los
casos de negocio.
Paso5: Durante la ejecución se observó que realizar el paso5 se obtiene
como consecuencia inmediata una vez se han realizado el Paso2 y el
Paso4 de manera adecuada. Sin embargo, se evidenció una relación
directa de buenas prácticas con soluciones conocidas. Por lo anterior el
método se refinó para agrupar las buenas prácticas a cada una de las
soluciones conocidas. El Paso 5 quedó entonces definido así: buscar las
buenas prácticas asociadas a cada solución conocida aplicable a la
categoría encontrada como se muestra en la Tabla 3.
Paso6: Durante la ejecución se observó que realizar el Paso6 se obtiene
como consecuencia inmediata una vez se han realizado el Paso2, el Paso4
y el Paso5 de manera adecuada.
Solución Conocida Buenas prácticas
Transferencia de archivos
• Uso de Formato • Generación de Archivos • Transporte
Bases de datos compartidas • Sincronización y políticas • Tipos de datos nativos • Gobierno de datos
Invocación remota de procedimientos
• Mecanismo de Exposición • Consulta de información • Llamado a procedimientos
Mensajería • Formato de los mensajes • Mecanismos de entrega de los mensajes
Tabla 3 Buenas prácticas agrupadas por cada solución conocida.
73
El método final refinado y aplicado quedó definido como lo muestra la Figura 10.
Los pasos se describen a continuación:
Paso1: Documentar el caso de negocio determinando los valores para cada
una de las variables de caracterización definidas. Con ello se definen las
variables de entrada al método.
Paso2: Aplicar los filtros para con ello encontrar la correcta caracterización
del caso de negocio y por consiguiente asociarlo a una de las siguientes
categorías. La aplicación de los filtros debe realizarse en el siguiente orden:
Identificar necesidad de integración: La necesidad de integración es una
sola para el caso de negocio
Con la necesidad de integración definir la categoría del caso de negocio
Una vez identificada la necesidad de integración, la siguiente variable a
identificar es el tipo de aplicación origen
Una vez identificada la necesidad de integración y el tipo de aplicación
origen, la siguiente variable a identificar es el tipo de aplicación destino
Con la necesidad de integración y los tipos de aplicaciones origen y
destino identificadas, se pasa a identificar los criterios y restricciones de
integración. En este punto se pueden identificar varios criterios y
restricciones para un caso de negocio. Las exclusiones que se deben
evaluar son:
o Tipo de aplicación origen identificada vs. Criterios y restricciones
o Tipo de aplicación destino identificada vs. Criterios y restricciones
o Criterios y restricciones vs. criterios y restricciones
o Características de calidad vs. características de Calidad
Paso3: Buscar las soluciones conocidas aplicables a la categoría
encontrada
Paso4: Aplicar los filtros:
Soluciones conocidas vs. criterios y restricciones
74
Soluciones conocidas vs. tipo de aplicación origen
Soluciones conocidas vs. tipo de aplicación destino
Paso5: Buscar las buenas prácticas asociadas a cada solución conocida
aplicable a la categoría.
Paso6: Entregar la soluciones conocidas y buenas prácticas aplicables a la
categoría encontrada.
Figura 10. Esquema del método diseñado
Al realizar el análisis cualitativo de las soluciones entregadas por el método para
los diez (10) casos de negocio caracterizados se encontró que:
75
En todos los casos la solución real implementada coincide con una de las
soluciones recomendadas por el método.
En todos los casos la solución real implementada se encuentra entre las
dos soluciones más recomendadas por el método.
En el cuarenta por ciento de los casos la solución real implementada es la
solución más recomendada por el método.
En el sesenta por ciento de los casos la solución más recomendada por el
método fue la mensajería, la cual no coincidió con la solución real
implementada. Esto se debe a que en el Grupo Empresarial Coomeva, la
mensajería no había sido evaluada como una solución viable para los
problemas de integración.
La Tabla 4 muestra de manera general lo anteriormente descrito:
Tabla 4 Comparativo entre solución real y soluciones recomendadas.
Al realizar el análisis cualitativo para los casos en los que la solución más
recomendada entregada por el método no coincide con la solución real
implementada, se encontró en todos los casos la posibilidad de mejorar la
implementación real así:
En los Caso1 y Caso8, donde la solución real implementada es
Transferencia de Archivos y la solución más recomendada por el método
76
es la Mensajería, se encontró que el explotar las ventajas de la
comunicación asíncrona mejoraría los tiempos de respuesta de la
aplicación origen ya que es posible continuar el proceso sin tener una
respuesta de la aplicación destino. En estos casos solo es necesario
garantizar que el mensaje se entregue; al implementar la solución más
recomendada por el método, se liberaría a la aplicación origen de la
responsabilidad de la entrega de los mensajes. Para el Caso1, el tamaño
de la información del archivo serializado en promedio es de 3KB, lo cual
está conforme a la buena práctica recomendada, en la Fase I Etapa III,
para el tamaño de los mensajes. Para el Caso8, el tamaño del archivo, sin
serializarlo, excede el tamaño recomendado del mensaje en la buena
práctica. Sin embargo en este caso teniendo en cuenta que la aplicación
destino puede recibir parcialmente la información, se sugiere que la
implementación se realice fraccionando el archivo en unidades más
pequeñas que además de las mejoras ya mencionadas, incorpore las
ventajas del procesamiento distribuido.
En los Caso3 y Caso5, donde la solución real implementada es
Invocación Remota de Procedimientos, se encontró que implementar la
Mensajería, que es la solución más recomendada por el método, le
permitiría a la aplicación origen continuar con el proceso mientras se
procesan los mensajes en la aplicación destino; mejorando los tiempos de
respuesta de la aplicación origen. Lo anterior también mejora la fiabilidad
de la integración pues aunque las aplicaciones destino tienen como oferta
de servicio una disponibilidad de 7x24, se ha presentado inestabilidad en
los últimos 4 meses. La solución real implementada no consideró que el
destino pudiese estar no disponible, lo que ha hecho necesario que se
implemente un monitoreo manual de los procesos.
77
En los Caso4 y Caso6, donde la solución real implementada es
Bases de datos compartidas y la solución más recomendada por el
método es la mensajería, se encontró una oportunidad de mejora asociada
a la eficiencia de rendimiento. Las aplicaciones origen son aplicaciones de
misión crítica porque soportan los procesos de atención al cliente. Estas
aplicaciones se ven afectadas en los tiempos de respuesta, normalmente
durante los primeros días del mes, porque en esos días las aplicaciones
destino, que son aplicaciones que soportan los procesos administrativos,
ejecutan procesos de cierre de mes que generan una alta demanda de
transacciones de lectura y escritura en las bases de datos.
78
5. CONCLUSIONES
Todos los elementos recopilados en la literatura en el desarrollo de la fase I
de la metodología son los necesarios y suficientes para realizar la
categorización de los casos de negocio.
Los casos de negocio de integración de aplicaciones tienen dos
necesidades básicas: compartir datos y compartir funcionalidad.
Las soluciones conocidas para la necesidad compartir funcionalidad son:
mensajería e invocación remota de procedimientos.
Las soluciones conocidas para la necesidad compartir datos son:
mensajería bases de datos compartidas y transferencia de archivos.
La solución conocida mensajería es la más recomendable y aplicable a
cualquier necesidad, la única restricción que tiene es que se tenga
disponible la selección de la tecnología.
La solución conocida bases de datos compartidas es aplicable a la
necesidad compartir datos, sin embargo tiene varias restricciones entre las
cuales se pueden resaltar: comunicación síncrona y destino siempre
disponible.
La solución conocida invocación remota de procedimientos es aplicable a la
necesidad compartir funcionalidad y no tiene restricciones. Lo que quiere
decir que se puede aplicar en cualquier caso de negocio que tenga esta
necesidad. Sin embargo cuando se cuenta con la disponibilidad de la
selección de la tecnología, se recomienda utilizar mensajería.
La solución conocida transferencia de archivos es aplicable a la necesidad
compartir datos y no tiene restricciones. Lo que quiere decir que se puede
aplicar en cualquier caso de negocio que tenga esta necesidad. Sin
79
embargo cuando se cuenta con la disponibilidad de la selección de la
tecnología, se recomienda utilizar mensajería.
Las buenas prácticas asociadas a las soluciones conocidas permiten refinar
la solución entregada por el método, porque proporcionan las pautas
necesarias de lo que se debe tener en cuenta para realizar la
implementación.
El método diseñado se define en seis pasos. Sin embargo la
caracterización del caso de negocio (paso1) y la aplicación de los filtros
(paso2 y paso4) conforman los pasos fundamentales y decisivos en la
aplicación del método. Los demás pasos se obtiene como consecuencia
inmediata de la correcta aplicación de estos tres (3) pasos.
En el análisis cualitativo de las soluciones entregadas por el método se
encontró que: en todos los casos la solución real implementada coincide
con una de las soluciones recomendadas por el método, en todos los casos
la solución real implementada se encuentra entre las dos soluciones más
recomendadas por el método, en el cuarenta por ciento de los casos la
solución real implementada es la solución más recomendada por el método
y en el sesenta por ciento de los casos restantes, no se implementó la
solución más recomendada , la mensajería, como solución real debido a
que en el Grupo Empresarial Coomeva, contexto en el que se desarrolló
este trabajo, la mensajería no había sido evaluada como una solución
viable para los problemas de integración.
Al realizar el análisis cualitativo detallado para los casos de negocio en los
que la solución más recomendada entregada por el método no coincide con
la solución real implementada, se encontró en todos los casos la posibilidad
de mejorar la implementación real, con la solución recomendada por el
método.
80
6. RECOMENDACIONES Y TRABAJOS FUTUROS
En el alcance del proyecto y de la metodología desarrollada en este trabajo, se
definió la evaluación de la solución entregada por el método como un paso del
método, paso 4, que se enfoca en la aplicación de tres filtros que permiten
realizar un análisis cualitativo de la pertinencia de dicha solución. Sin embargo y
teniendo en cuenta que cualquier propuesta que involucre la toma de decisiones
sobre el diseño de arquitectura y en este caso particular, sobre la integración de
aplicaciones, debe realizarse con un análisis detallado y formal para minimizar
riegos en las etapas posteriores del proceso de construcción de software; se
propone como trabajo futuro el desarrollo de una propuesta metodológica que
permita realizar el análisis y evaluación detallada de las soluciones propuestas
entregadas por el método y determinar si la solución entregada es apropiada y
conforme a la caracterización del caso de negocio.
Como se ha mostrado en el desarrollo de este proyecto, el objetivo general es el
diseño de un método que permita entregar un conjunto de recomendaciones para
la integración de aplicaciones empresariales para un caso de negocio dado. Por lo
anterior, como trabajo futuro se presenta la implementación del método para que
sea publicado en internet, de manera que pueda ser usado ampliamente por los
constructores de integraciones de aplicaciones. Para ello se requiere realizar la
implementación de un cuestionario y de los filtros asociados a las preguntas, que
permitan realizar la correcta caracterización de los casos del caso de negocio
objeto del cuestionario. La implementación de las búsquedas a las bases de datos
de los conjuntos de características, buenas prácticas y soluciones conocidas es
también requerida.
81
Otro trabajo futuro que se presenta es el enriquecimiento de los conjuntos de
variables para realizar la caracterización de los casos de negocio, los conjuntos de
buenas prácticas y los conjuntos de soluciones conocidas; con lo que se lograría
mantener actualizado el método y por ende que permanezca vigente en el tiempo.
Adicional al anterior, se presenta un trabajo futuro que consiste en la exploración
de otros métodos derivados para otro tipo de aplicaciones, como las aplicaciones
en tiempo real; lo cual puede derivar en la prueba del método en otros contextos
diferentes al empresarial y la búsqueda de nuevos conjuntos para realizar la
caracterización de los casos, nuevos conjuntos de buenas prácticas y nuevos
conjuntos de soluciones conocidas aplicables al contexto de las aplicaciones en
estudio.
Finalmente se presenta la posibilidad de evaluar las soluciones entregadas por el
método, frente a variables no técnicas tales como tiempo, costo y esfuerzo.
82
BIBLIOGRAFIA
[1] VAN GILS, BAS, Application of Semantic Matching in Enterprise Application Integration, Tilburg University, 2002. 81 p.
[2] ISO/EIC. International standard ISO/EIC FDIS 25010.2010. Disponible en
http://pef.czu.cz/~papik/doc/MHJS/pdf/ISOIEC_FDIS25010_%28E%29.pdf [3] WOOLLEY, R. Enterprise Application Integration (EAI). Office of the
Governor State of Utah, 1999 [4] FENNER, J. Enterprise Application Integration Techniques, 1999. Disponible
en http://www.cs.ucl.ac.uk/staff/ucacwxe/lectures/3C05-02-03/aswe21-essay.pdf
[5] WANGLES, B y PAHEERATHAN S.J. Horizontal and vertical integration of organizational IT systems. En Information systems engineering: state of the art and research themes. Springer, p. 79-90, 2000
[6] DEITEL, Paul y DEITEL Harvey. Como programar en Java. 5 ed., Prentice
Hall. 2004. 1268 p. [7] REINA, A. Visión general de la programación orientada a aspectos.
Universidad de Sevilla, Facultad de informática y estadística, 2000. Disponible en www.lsi.us.es/docs/informes/aopv3.pdf
[8] KAZMAN R, KLEIN M y CLEMENTS P. ATAM: Method for architecture evaluation. Universidad de Carnigie Mellon, Software Engineering Institute, 2000.
[9] KAZMAN R, BASS L, ABOWD G y WEBB M. SAAM: A method for analyzing the properties of software architectures, Universidad de Carnigie Mellon, Software Engineering Institute, 2007.
[10] CHUNG-HORNG L, BOT S, KALAICHELVAN K y KAZMAN R. An
approach to software architecture analysis for evolution and reusability, CASCON '97,IBM Press, 1997.
[11] BIGGS, M. Enterprise application integration offers great benefits after careful desderation. En Infoworld. Enero, 2000. Vol 22, no. 3, p. 70.
83
[12] PUSCHMANN T y ALT R. Enterprise Application Integration - The Case of the Robert Bosch Group. Emerald Group Publishing Limited, En conferencia internacional sobre las ciencia de los sistemas. 2001. Hawaii: IEEE Computer Society. vol. 9
[13] GORTON, I y LIU A. Architectures and Technologies for Enterprise
Application Integration, En Conferencia Internacional sobre Ingenieria de software. (26: 23-28, mayo, 2004: Scotland, United Kingdom). 2004. Scotland: icse. p. 726-727
[14] MOUL, B. Taking Enterprise Application Integration into the Cloud. Dell,
2010. Disponible en http://www.boomi.com [15] HARALD, K, BAYER, F, JUNGINGER, S y KARAGIANNIS D. Enterprise
Model integration, 2003, Disponible en http://citeseerx.ist.psu.edu/viewdoc/similar?doi=10.1.1.196.1809&type=cc
[16] HOHPE, Gregor y WOOLF Bobby. Enterprise Integration Patterns, 14 ed.,
Massachussetts: Addison Wesley, 2004. 683 p. [ ] MA OU E , ernard y M A , Laurent. Application ntegration
EAI, B2B, BPM and SOA. 1 ed. Wiley, 2007. 256 p. [19] KAN, Stephen. Metrics and Models in Software Quality Engineering. , 1
ed., Addison Wesley Professional, 1994. 344 p. [20] ERL, Thomas. Introducing SOA Desing Patterns, En SOA World
Magazine, Junio, 2008. vol. 8, pp. 2–7 [21] SOA Principles. Disponible en http://www.soaprinciples.com [22] ERL, Thomas. SOA Desing Patterns, 1 ed. Prentice Hall: Boston, 2009.
800 p. [23] ORACLE. Enterprise architecture. SOA anti-patterns How Not to do service
oriented Architecture, 2010. Disponible en www.oracle.com/technetwork/es/topics/soa/articles/index.html
[25] EGYED, A y GRÜNBACHER P. Identifying requirements conflicts and cooperation: How quality attributes and automated traced can help, En IEEE Software, Noviembre, 2004. vol. 21, no. 6, p. 50-58
84
[26] HOHPE, G, Enterprise Integration patterns, En conferencia de patrones de lenguajes de programación (PloP). (9: 8-12, Septiembre, 2002: Illinois - usa). 2002.
[27] Conferencia sobre patrones de lenguajes de programación, Disponible en
http://www.hillside.net/plop/2011
[29] CRAGGS, S. File transfer for the future, EAI Industry Consortium, 2003. Disponible en http://hosteddocs.ittoolbox.com/Craggs010504.pdf
[30] LUI , Mark, GRAY, Mario, CHAN, Andy y LONG, Josh. Pro Spring
Integration, 1 ed, Apress, 2011. 664 p. [31] COGOLUEGNES, Arnaud, TEMPLIER, Thierry , GREGORY, Gary y
BAZOUD, Olivier. Spring batch in action. 1 ed. Manning, 2011. 504 p. [32] FLUX. Best practices in Managed File Transfer, Disponible en
http://fluxcorp.com/resources/5-best-practices-in-managed-file-transfer [33] MAK, Gary y LONG Josh. Spring Enterprise Recipes: A Problem-Solution
Approach. 1 ed, Apress, 2009. 496 p.
