DISEO DE UN MTODO PARA DETERMINAR UN CONJUNTO DE

RECOMENDACIONES PARA REALIZAR LA INTEGRACIN DE

APLICACIONES EMPRESARIALES

VICTOR DANNEY GARCIA PLAZA

MARIA TERESA LOPEZ DUEAS

UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERAS
MAESTRA EN INGENIERA DE SOFTWARE
SANTIAGO DE CALI ENERO DE 2012
1

DISEO DE UN MTODO PARA DETERMINAR UN CONJUNTO DE

RECOMENDACIONES PARA REALIZAR LA INTEGRACIN DE
APLICACIONES EMPRESARIALES

MARIA TERESA LOPEZ DUEAS

VICTOR DANNEY GARCIA PLAZA

DIEGO ARMANDO GOMEZ MOSQUERA

Director de trabajo de grado

UNIVERSIDAD DE SAN BUENAVENTURA

FACULTAD DE INGENIERAS
MAESTRA EN INGENIERA DE SOFTWARE
SANTIAGO DE CALI ENERO DE 2012
2

Nota de aceptacin
________________________
________________________
________________________

________________________
Presidente del Jurado

________________________
Jurado

________________________
Jurado

Santiago de Cali, enero de 2012

DEDICATORIA

A Dios sobre todas las cosas, a mi familia por ser el motor que me impulsa a
crecer cada da y a mis amigos quienes con su apoyo y consejos me ayudan a
mantener firmes mis objetivos.

MARIA TERESA LPEZ DUEAS

A Dios, a mi pequeo Juan Pablo, a mi esposa Anglica, y a mis padres, por su

gran amor y apoyo en cada una de las etapas de mi vida.

VICTOR D. GARCIA PLAZA

AGRADECIMIENTOS

A Dios a quien confo mis retos, a mi familia y amigos quienes con su cario y
respaldo me acompaaron 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 LPEZ DUEAS

A Dios por darme la oportunidad de aprender, a mi familia por su enorme apoyo y

a Diego A. Gmez, por su tiempo, dedicacin e ideas que contribuyeron
satisfactoriamente a la culminacin de este trabajo de grado.

VICTOR D. GARCIA PLAZA

TABLA DE CONTENIDO

1.

PLANTEAMIENTO DEL PROBLEMA ....................................................... 15

2.

MARCO TEORICO ................................................................................... 17

3.

METODOLOGA ....................................................................................... 21
3.1

3.1.1

Etapa I ......................................................................................... 22

3.1.2

Etapa II ........................................................................................ 22

3.1.3

Etapa III ....................................................................................... 22

3.2

Fase II, denominada Diseo .............................................................. 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

4.

Fase I, denominada Recopilacin ...................................................... 21

Fase III, denominada Aplicacin ........................................................ 23

3.3.1

Etapa I ......................................................................................... 24

3.3.2

Etapa II ........................................................................................ 24

RESULTADOS ......................................................................................... 25
4.1

Fase I Recopilacin de informacin ................................................... 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 prcticas ................. 49

4.2

Fase II Diseo del mtodo ................................................................. 58

4.2.1

Etapa I: Definicin de categoras ................................................. 58

4.2.2

Etapa II: Soluciones conocidas aplicables por categora ............. 59

4.2.3

Etapa III: Buenas prcticas aplicables por categora ................... 59

4.2.4

Etapa IV: Definicin de filtros ....................................................... 59

4.2.5

Etapa V: El mtodo diseado ...................................................... 66

4.3

Fase III Prueba del diseo del mtodo ............................................... 67

4.3.1

Etapa I: Refinamiento del mtodo................................................ 67

4.3.2

Etapa II: Aplicacin del mtodo diseado .................................... 71

5.

CONCLUSIONES ..................................................................................... 78

6.

RECOMENDACIONES Y TRABAJOS FUTUROS ................................... 80

LISTA DE TABLAS

Tabla 1 Ventajas y desventajas de los estilos de integracin

Tabla 2 Estilos de integracin y los Frameworks que los implementan.
Tabla 3 Buenas prcticas agrupadas por cada solucin conocida.
Tabla 4 Comparativo entre solucin real y soluciones recomendadas.

LISTA DE FIGURAS

Figura 1. Esquema de la metodologa desarrollada.

Figura 2. Transferencia de archivos.
Figura 3. Bases de datos compartidas.
Figura 4. Invocacin a procedimientos remotos.
Figura 5. Mensajera.
Figura 6. Aplicaciones comunicadas usando mensajera.
Figura 7. Comunicacin basada en mensajera a travs de un MOM.
Figura 8. Transmisin de mensajes paso a paso.
Figura 9. Categorizacin de Patrones de integracin empresarial.
Figura 10. Esquema del mtodo diseado.

LISTA DE ANEXOS

Anexo 1: Resultados de la encuesta:

Anexo 1.1 Encuesta.
Anexo1.2 Necesidades de integracin.
Anexo 1.3 Criterios y restricciones para la integracin.
Anexo 1.4 Tipos de aplicaciones a integrar.
Anexo 1.5 Caractersticas de calidad de la solucin de integracin.
Anexo 1.6 Cuadro de tecnologas
Anexo1.7 Caracterizacin de las empresas de los profesionales objeto de la
encuesta

Anexo 2: Combinacin de variables:

Anexo 2.1 Tipos de aplicaciones
Anexo 2.2 Criterios y restricciones
Anexo 2.3 Caractersticas de calidad
Anexo 2.4 Criterios y restricciones tipo de aplicacin origen
Anexo 2.5 Criterios y restricciones tipo de aplicacin destino

Anexo 3: Aplicacin del mtodo diseado

Anexo 3.1: Soluciones conocidas criterios y restricciones
Anexo 3.2: Criterios y restricciones refinado
Anexo 3.3: Soluciones conocidas tipo de aplicacin origen
Anexo 3.4: Soluciones conocidas tipo de aplicacin destino
Anexo 3.5: Caracterizacin de los casos de negocio y soluciones

10

RESUMEN

Cuando un constructor de aplicaciones empresariales se enfrenta a la integracin

de dos aplicaciones para un caso especfico de negocio, se encuentra con un
conjunto bastante amplio de estrategias, mtodos y arquitecturas que pueden ser
utilizados. Sin embargo, cuando debe elegir una opcin de entre el conjunto de
posibilidades, surgen las restricciones que estn dadas por las caractersticas de
las aplicaciones de su negocio y los

requerimientos no funcionales del caso

especfico objeto de la integracin; por lo que seleccionar la opcin ms adecuada

resulta ser un problema no trivial de resolver.

En este proyecto de investigacin se dise un mtodo que al ser usado por un

constructor de aplicaciones empresariales, que se enfrenta a un caso de
integracin, le entrega una recomendacin sobre las posibles opciones a usar;
considerando las caractersticas de las aplicaciones a integrar y las restricciones
presentes en su caso especfico de negocio.

Para disear este mtodo se inici con la recoleccin y definicin de las

caractersticas de las aplicaciones y restricciones comunes presentes en las
empresas de Santiago de Cali; as como el conjunto de mtodos, estrategias,
buenas prcticas, soluciones conocidas y otras reglas usadas para la integracin
de aplicaciones empresariales. Posteriormente se realiz el diseo del mtodo a
travs de la identificacin y definicin de las categoras en las que se clasifican los
casos de negocio y la identificacin y definicin del conjunto de buenas prcticas
y soluciones conocidas aplicables a cada categora. Con lo anterior se defini una
serie de filtros que permitieron garantizar la correcta caracterizacin y
categorizacin de los casos de negocio dados y por consiguiente cuales son las
buenas prcticas y soluciones conocidas que le son aplicables. Finalmente se
11

prob el diseo del mtodo a diez (10) casos de negocio reales y al mismo tiempo
se hizo el refinamiento a travs de la definicin y validacin de criterios que
permitieron determinar la pertinencia del conjunto de recomendaciones entregado
por el mtodo diseado, frente a la caracterizacin del caso de negocio.

12

INTRODUCCIN

Cuando se piensa en una empresa, esta se ve como un sistema complejo que

tiene un propsito u objetivo especfico. Las aplicaciones empresariales intentan
apoyar a la empresa en la consecucin de estos objetivos [1]. Debido a esto, los
constructores de aplicaciones empresariales se enfrentan al reto de implementar
soluciones especializadas que deben procesar tareas especficas, enfocadas a un
conjunto determinado de procesos y diseadas a la medida de las necesidades
del negocio; que a su vez deben integrarse con otras aplicaciones de negocio y/o
sistemas legados que desempean otras tareas especficas.
En la bsqueda de mecanismos u opciones para realizar la integracin 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 integracin. Seleccionar la mejor opcin es
una habilidad que resulta de la experiencia, pues en la actualidad no se cuenta
con un mtodo conocido que permita llegar a una mejor opcin. En el presente
proyecto de investigacin se dise un mtodo que al ser usado por un
constructor de aplicaciones empresariales, que se enfrenta a un caso de negocio
en el que deba realizar integracin de aplicaciones, este le entregara una
recomendacin

sobre

las

posibles

opciones

usar;

considerando

las

caractersticas propias de las aplicaciones y restricciones con las que trabaja. Para
lo anterior se identific un conjunto de caractersticas y restricciones que al ser
agrupadas, permitieron definir las categoras en las que se pueden clasificar los
casos de negocio; complementando lo anterior se defini cules son las buenas
prcticas y soluciones conocidas que se pueden aplicar a cada categora. De
manera que una vez clasificado un caso de negocio en una categora, se
relacionan las buenas prcticas y soluciones conocidas que son aplicables.

13

En los captulos siguientes se presentan el planteamiento del problema para el

cual el mtodo fue diseado; el marco terico en el que se ambientan, a travs de
los diferentes enfoques y autores, el problema y las aproximaciones que se le han
dado a la integracin de aplicaciones empresariales; Adems se presenta,
tambin, cada una de las fases y etapas de la metodologa definida; los resultados
hallados en cada fase de la metodologa desarrollada; las conclusiones
encontradas durante la realizacin del proyecto, las recomendaciones y trabajos
futuros derivados de este proyecto.

14

1. PLANTEAMIENTO DEL PROBLEMA

La integracin de aplicaciones empresariales, por sus siglas en ingles EAI [16]

(Enterprise Application Integration) es un trmino utilizado comercialmente para
denominar los planes, mtodos y herramientas utilizados para integrar y coordinar
las aplicaciones en una empresa [1]. El constructor de aplicaciones empresariales
en el proceso de anlisis y diseo de integracin de aplicaciones [3] para un caso
especfico de negocio, adems de encontrarse con un conjunto genrico de
posibles estrategias [16], arquitecturas y mtodos de integracin [4]; se encuentra
tambin con un nmero importante de caractersticas propias de las aplicaciones
de su negocio tales como: plataformas, lenguajes de programacin, protocolos,
motores de bases de datos, sistemas operativos y arquitecturas de aplicacin [4]
que le agregan complejidad a la eleccin de una opcin de integracin de
aplicaciones.
Ahora, si se piensa en que esa integracin debe responder eficiente y
efectivamente a las necesidades de los procesos de negocio, dadas en trminos
de los requerimientos no funcionales asociados a tiempos de respuesta e
integridad de los datos, y que est

condicionada por la tecnologa, 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 disear un mtodo que entregue
un conjunto de recomendaciones para realizar la integracin de aplicaciones
empresariales aplicables a un caso de negocio dado. Los objetivos especficos de
este proyecto son: recopilar las diferentes estrategias, mtodos y estilos de
integracin existentes para realizar la integracin de aplicaciones empresariales;
identificar las caractersticas ms comunes a las aplicaciones presentes en las
empresas; identificar los posibles valores que pueden tomar cada una de estas
caractersticas; identificar las restricciones comunes presentes en las empresas;

15

identificar los posibles valores que pueden tomar cada una de estas restricciones;
definir una taxonoma con la que se puedan clasificar, categorizar y/o tipificar los
casos de negocio de aplicaciones empresariales; recopilar y seleccionar un
conjunto de buenas prcticas de integracin de aplicaciones, que apliquen a cada
categora; recopilar y seleccionar un conjunto de soluciones conocidas de
integracin de aplicaciones, que puedan aplicar a cada categora; definir un
conjunto de filtros, aplicables a la integracin de aplicaciones, que permitan
realizar la correcta caracterizacin de cada caso de negocio; probar y refinar el
diseo del mtodo aplicndolo a un conjunto de casos de negocio reales.

16

2. MARCO TEORICO

En la actualidad es cada vez ms comn 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 informacin (IS) que soportan su
operacin y metas financieras [12]. Sin embargo debido a la especializacin de
cada uno de estos paquetes de software, existen diferentes proveedores lderes
que brindan soluciones especficas para cada una de estas necesidades; por lo
tanto es muy comn ver empresas que tienen al menos dos o ms proveedores
que satisfagan sus necesidades especficas en cada uno de sus procesos de
negocio.

Como resultado de la adquisicin 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 tambin cambiando.
Por esto, es necesaria la interoperabilidad entre los distintos paquetes de software
o aplicaciones de una empresa y adems el intercambio de informacin con sus
socios de negocio. Por lo tanto la integracin de las aplicaciones y los procesos de
negocio son una prioridad para las empresas en la actualidad [16]. No cabe duda
que la integracin entre aplicaciones sea una constante en el da a da de las
grandes empresas, a tal punto que se encuentra involucrada incluso en los
17

paradigmas

computacionales

ms

actuales,

como

es

el

caso

de

la

interoperabilidad de aplicaciones en la nube [14]. Esto evidencia que los procesos

de integracin seguirn siendo vigentes en el futuro de las empresas, por esta
razn cada vez ms las compaas buscan maneras para mejorar sus procesos
de integracin. 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 compaa, que como se ha hecho referencia en este mismo
documento son normalmente heterogneos, a travs de la adquisicin de software
que provenga de un mismo proveedor, sin embargo, los resultados no han
cumplido las expectativas y debido a eso muchas organizaciones estn
cambiando su estrategia a una que permita un rpido ensamble y desensamble de
los procesos de negocio y de los correspondientes componentes de software [12].
Otra forma de resolver los problemas de integracin, se da con la aparicin de
modelos de integracin tal como el Modelo de Integracin Empresarial (EMI) [15],
que permite a travs de un enfoque de meta-modelo orientado a objetos, la
construccin de un lenguaje que describe un cierto dominio [15]. Adems dicho
modelo permite la reutilizacin de experiencias a travs de la propuesta de
patrones para el meta-modelo de integracin [15].

Otra solucin es el uso de un conjunto de patrones de integracin empresariales,

que son el resultado de aos de trabajo por parte de expertos en la materia, con
diferentes

organizaciones

en

procesos

de

integracin

de

aplicaciones

empresariales [16, 20, 22]. Estos patrones brindan solucin a un conjunto amplio
de problemas de integracin entre aplicaciones empresariales. Se debe tener en
cuenta que las soluciones de integracin son una tarea compleja, pues existe ms
de una solucin posible, sin embargo saber si la solucin definida es una buena
opcin, no se conocer sino hasta muchos meses o aun aos ms tarde, cuando
inevitablemente los cambios y la dinmica del negocio pongan a prueba la
solucin original [16].
18

En la actualidad, la computacin orientada a servicios aparece como un nuevo

paradigma computacional fundamentado en buena parte en el paradigma
orientado a objetos [6] y en la programacin 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 lgica que le permite llevar a cabo
esas capacidades y un contrato que expresa cuales de estas capacidades estn
disponibles para ser usadas [21]. Uno de los elementos fundamentales en la
computacin orientada a servicios es la arquitectura orientada a servicios,
SOA[21] por sus siglas en ingls, y dentro de SOA la integracin tiene un lugar
relevante, y es resaltada por Thomas Earl, como una parte importante, de alto
perfil de la industria de las tecnologas de informacin [21]. Esto se debe a que
prcticamente los servicios se construyen con la capacidad intrnseca de
interactuar con mltiples consumidores y que prcticamente ninguno de ellos es
conocido en el momento de su creacin [21]. Con este concepto, SOA podra ser
entonces la solucin a los problemas de integracin; sin embargo, esto es algo
que solo se puede presentar cuando un porcentaje importante de los servicios de
una organizacin est representado en un inventario de servicios de calidad [21].
Implementar SOA

requiere

tanto

habilidades

tcnicas

como

habilidades

organizacionales, lo que quiere decir que la implementacin de SOA pasa las

fronteras de lo tcnico 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 integracin tradicional entre los sistemas heredados existentes, y tambin entre
los sistemas heredados y sus servicios [21]. Los mtodos desarrollados por los
diferentes investigadores se enfocan como propuestas metodolgicas que
permiten evaluar la pertinencia o riesgos sobre las decisiones tomadas en el
diseo de arquitecturas de aplicaciones. Ejemplo de ello es ATAM (Architecture
Tradeoff Analysis Method), cuyo propsito es analizar un diseo de arquitectura y
determinar si este diseo satisface los objetivos de calidad para los cuales fue
19

construido, determinando las posibles consecuencias o riesgos de esta decisin

en funcin de los atributos de calidad definidos por los requisitos del sistema [8].
Otro ejemplo de un mtodo para realizar el anlisis de arquitecturas de software
es SAAM (Software Architecture Analysis Method), evala las arquitecturas de
software basndose en la adopcin 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 inters y
tambin mostrar la interaccin entre las diferentes personas que utilizaran el
sistema: usuarios finales, administrador, desarrolladores, etc. Cabe anotar que en
este

mtodo,

los

escenarios

son

analizados

desde

tres

perspectivas

fundamentales: la perspectiva funcional, la perspectiva de estructura y la

perspectiva de distribucin o asignacin [9]. Otros mtodos de anlisis de
arquitecturas se enfocan en criterios especficos a evaluar, como la reutilizacin, o
en la comparacin de arquitecturas desarrolladas bajo diferentes paradigmas [10].
Sin embargo no se ha identificado mtodos especficos que determinen un
conjunto de pasos para encontrar posibles soluciones a un caso de integracin de
aplicaciones empresariales. Es aqu donde se fundamenta el objetivo del presente
trabajo de investigacin aplicada.

20

3. METODOLOGA

La metodologa definida para el desarrollo del proyecto se muestra en la Figura 1,

se divide en tres (3) fases principales, a continuacin se detalla las etapas y
actividades de cada una de estas fases:

Figura 1. Esquema de la metodologa desarrollada.

3.1 Fase I, denominada Recopilacin

La fase de recopilacin, como su nombre lo indica, esta fase se centra en la
recopilacin de informacin. Se divide en tres etapas, las actividades a realizar en
cada etapa se detallan a continuacin:

21

3.1.1 Etapa I
Determinar el conjunto de variables con las que se puede caracterizar un caso de
integracin de aplicaciones Empresariales: En la cual el trabajo se orientar a la
construccin de los siguientes entregables:

Conjunto de estrategias, mtodos y arquitecturas existentes para realizar la

integracin inter-aplicacin de aplicaciones empresariales.

Conjunto de las caractersticas ms 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 identificacin de estos elementos en la literatura

existente y se realiza la validacin del uso de los mismos en el contexto de
Santiago de Cali, a travs de la elaboracin de una encuesta.
3.1.2 Etapa II
Determinar el conjunto de soluciones conocidas aplicables a un caso de
integracin de aplicaciones empresariales: el cual se realizar con la revisin de la
literatura existente.
3.1.3 Etapa III
Determinar el conjunto de buenas prcticas aplicables a un caso de integracin de
aplicaciones empresariales: para esta recopilacin se hace uso de entrevistas con
expertos y revisin de la literatura existente.
3.2 Fase II, denominada Diseo
En esta fase el trabajo se centrar en el diseo del mtodo, teniendo como
insumos los entregables de la fase de Recopilacin, Fase I; los entregables de
esta fase son descritos en las siguientes etapas:

22

3.2.1 Etapa I
Definicin de categoras: Para esta actividad el entregable ser la taxonoma en la
que se puedan clasificar, categorizar o tipificar los casos de negocio de integracin
de aplicaciones empresariales.
3.2.2 Etapa II
Definicin de soluciones conocidas aplicables por categora: Para esta actividad el
entregable ser el conjunto de soluciones conocidas aplicables a cada categora
definida en la Etapa I.
3.2.3 Etapa III
Definicin de buenas prcticas aplicables por categora: Para esta actividad el
entregable ser el conjunto de buenas prcticas o reglas aplicables a cada
categora definida en la Etapa I.
3.2.4 Etapa IV
Definicin 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 caracterizacin, 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 categora en la que se clasificar el caso de
negocio, objeto de la aplicacin del mtodo diseado, sea correcta.
3.2.5 Etapa V
Con la recopilacin de las etapas anteriores se realizar la definicin de los pasos
del mtodo. En esta fase las definiciones se realizarn teniendo como insumo
principal la recopilacin de la literatura y entrevistas con expertos realizada en la
Fase I.
3.3 Fase III, denominada Aplicacin
En esta fase se pondr a prueba el diseo del mtodo definido en la fase de
Diseo (Fase II). Y comprende las siguientes actividades:

23

3.3.1 Etapa I
Definicin de criterios para determinar la pertinencia de la(s) recomendacin(es)
entregada(s) por el mtodo frente a la caracterizacin del caso de negocio.
3.3.2 Etapa II
Aplicacin y refinamiento del mtodo diseado.

En esta fase se trabajar

aplicando el mtodo diseado en la Fase II (Fase de diseo), a

casos de

integracin de aplicaciones empresariales, que se han presentado en los

proyectos de construccin de aplicaciones realizados en los dos ltimos aos en el
Grupo Empresarial Coomeva. La pertinencia de las recomendaciones entregadas
por el diseo del mtodo ser determinada por los criterios definidos en la Etapa I
de esta fase.

24

4. RESULTADOS

Conforme a lo establecido en la metodologa 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 continuacin:

4.1 Fase I Recopilacin de informacin

La fase de recopilacin de informacin consisti, como su nombre lo indica, en un
proceso de recoleccin de informacin sobre la integracin de aplicaciones
empresariales, el cual se orient en la elaboracin de seis (6) conjuntos; cuatro (4)
de los cuales representan el dominio de las entradas al mtodo que se va a
disear que corresponden a los conjuntos de variables con las cuales se puede
caracterizar un caso de negocio. Y dos (2) ms que son el engranaje fundamental
del mtodo y que corresponden al conjunto de soluciones conocidas y el conjunto
de buenas prcticas respectivamente.
4.1.1 Etapa I Determinar conjunto de variables
El propsito de esta etapa es determinar el conjunto de variables con las que se
puede caracterizar un caso de integracin de aplicaciones Empresariales:
Estos elementos tienen la caracterstica principal de influenciar la integracin de
aplicaciones empresariales y ser decisivos al momento de analizar un caso de
integracin de aplicaciones empresariales. Para la elaboracin de estos cuatro (4)
conjuntos fue necesario la ejecucin de dos (2) actividades: La revisin de la
literatura existente y la realizacin y anlisis de resultados de la encuesta.
4.1.1.1 Revisin de la literatura existente
Como se mencion anteriormente, el propsito de esta revisin se orient en la
elaboracin de cuatro (4) conjuntos que fueron identificados durante la revisin de
la literatura, durante la cual se reconocieron dos textos principales [16, 18] y un

25

grupo de artculos [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 continuacin:
4.1.1.1.1 Necesidades de integracin
La principal caracterstica de este primer grupo es que rene los elementos que
motivan la integracin 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 continuacin:

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
travs de mecanismos propios del motor de base de datos.

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

Mensajera: El sistema necesitar usar un Middleware de mensajera para

el

intercambio de datos o para inducir

eventos en otros sistemas o

subsistemas.
4.1.1.1.2 Criterios de Integracin
Este segundo grupo contiene los elementos que marcan los criterios a tener en
cuenta en el momento en que son tomadas las decisiones de integracin y las
restricciones que se pueden presentar durante esta toma de decisiones:

Intrusin: Cuando el enfoque por el menor impacto, es decir reducir al

mnimo los cambios o la cantidad de cdigo de integracin no pueden
proporcionar la mejor solucin de integracin en la empresa.

26

Seleccin de la tecnologa: Cuando se requiere del uso de software y

hardware especializado para llevar a cabo la solucin de integracin, pues
el hecho de construir la solucin 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 comn para la integracin de las

aplicaciones.

Modificar la aplicacin para usar un formato de datos comn.

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

La informacin compartida entre aplicaciones estar disponible

desde el momento en que el emisor la est generando, es decir el
receptor podr recibir la informacin a medida que esta se vaya
generando por el emisor, esto implica el envi de informacin
fragmentada y se hace compleja su sincronizacin.

Datos o Funcionalidad: Se presenta cuando:

La integracin permitir a las aplicaciones compartir solo datos.

27

La integracin permitir compartir funcionalidades en vez de

simplemente datos.

Comunicacin Remota: Se presenta cuando se desea establecer

comunicacin con aplicaciones que no se encuentran en la misma instancia
de sistema operativo de la aplicacin que tiene la intencin del llamado. En
este caso la comunicacin con las aplicaciones puede ser simplemente
sncrona o asncrona. Esta ltima implica mayor complejidad en el diseo,
desarrollo y depuracin.

Confiabilidad: Se presenta cuando por ejemplo una solucin de integracin

permitir la comunicacin asncrona 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, enfocndose en
el manejo de los eventos y los tipos de datos que procesan. La clasificacin
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 ms se aproxima al contexto
empresarial en el que se va a trabajar el proyecto, tanto para la aplicacin de la
encuesta como para la caracterizacin y anlisis de los casos de negocio adems
se ajusta a los tipos de escenarios cubiertos por los Frameworks de integracin
ms comunes del mercado [30,31,33].
Batch:

No procesan eventos.

Transaccionales 1:

Procesan eventos en la medida que ocurren.

28

Procesan eventos de los usuarios que se conectan va 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 va interfaz de

usuario.

Deben estar disponibles.

Cliente servidor:

Procesan eventos en la medida que ocurren.

Procesan eventos de los usuarios que se conectan va 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 va 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 integracin predefinidos desde el fabricante.

29

4.1.1.1.4 Caractersticas de calidad:

En este cuarto grupo se consideraron las caractersticas de calidad, no para las
aplicaciones a integrar; sino de la solucin de integracin. Para el desarrollo de
este proyecto se seleccion el marco de trabajo de las caractersticas de calidad
de acuerdo con la norma ISO/EIC 25010 [2,19]. Esta seleccin se realiz teniendo
en cuenta que es el marco con el que los investigadores han venido trabajando
durante el proceso de formacin profesional y es el marco con el que est ms
familiarizado el contexto empresarial en el que se va a aplicar la encuesta. Las
caractersticas de calidad conforme al marco seleccionado se definen como sigue:

Funcionalidad: Grado al cual un producto software provee las funciones que

satisfacen las necesidades explcitas e implcitas cuando el software se utiliza
bajo condiciones especficas

Seguridad: La proteccin del sistema de accesos maliciosos o accidentales,

uso, modificacin, destruccin o divulgacin.

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 especfico

de funcionamiento cuando se est utilizando bajo condiciones especificadas.

Capacidad de operacin: 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 ms componentes software para el

intercambio de informacin y/o para cumplir con sus funciones, Compartiendo
el mismo hardware o el entorno de software.

30

Capacidad de mantenimiento: Grado en el cual un producto software puede ser

modificado. Las modificaciones pueden incluir correcciones, mejoras o
adaptacin 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 elaboracin y anlisis de resultados de una
encuesta realizada a veintiuno (21) voluntarios que trabajan o han trabajado en
proyectos de integracin de aplicaciones empresariales. Los objetivos de esta
encuesta fueron:

Someter a calificacin (entre 1 y 5) cada uno de los elementos recopilados, en

la revisin de la literatura, de acuerdo al nivel influencia de estos elementos en
la integracin de aplicaciones empresariales.

Recolectar informacin sobre los mtodos que se emplean actualmente.

Identificar las tecnologas en las que estn construidas las aplicaciones

empresariales con las que se trabajan en proyectos de integracin en las
empresas de Santiago de Cali.

Los resultados obtenidos para cada uno de los objetivos de la encuesta se

muestran a continuacin:

Todos los elementos recopilados en la literatura, fueron calificados con algn

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
mtodo para realizar la caracterizacin de los casos de negocio. No
aparecieron

nuevos

elementos,

necesidades,

criterios,

restricciones,

caractersticas de calidad y de las aplicaciones, a incluir en el conjunto de

elementos ya recopilados.

31

Solo uno de los encuestados respondi afirmativamente a la pregunta de si

conoca un mtodo que le permitiera identificar la mejor opcin de integracin
dentro de un grupo de casos de integracin de aplicaciones empresariales. Sin
embargo el mtodo descrito por el encuestado es ms una descripcin de un
conjunto de actividades en orden lgico usado a nivel personal para resolver
casos de integracin; que un mtodo formalmente descrito y referenciado.

Se logr identificar las tecnologas en las que estn construidas las

aplicaciones empresariales (bases de datos, lenguajes de programacin y
sistemas operativos) en las que han trabajado los encuestados y se identific
que corresponde a un conjunto amplio de distintas tecnologas y fabricantes;
incluso dentro de una misma empresa.

Estos resultados se presentan de manera grfica 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 metodologa, bsicamente se
resume en el uso de los estilos de integracin definidos en [16] como soluciones
conocidas, dado que en la actualidad son las ms utilizadas dentro de la
bibliografa sobre la que se basa este documento. A continuacin se profundiza
sobre cada uno de estos estilos:
4.1.2.1 Transferencia de archivos

Figura 2. Transferencia de archivos [16].

32

Esta solucin se basa en el estilo de integracin que lleva su mismo nombre (File
Transfer) [16]. Cuando se usa la transferencia de archivos como solucin a un
problema de integracin, una aplicacin 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 integracin tienen la responsabilidad de transformar
los archivos en diferentes formatos en caso que las aplicaciones destino as lo
requieran. Como tambin de identificar los intervalos de produccin de dichos
archivos de acuerdo a la naturaleza del negocio.

Recomendacin:
En caso que sea necesario tener la informacin con una periodicidad mayor a la
que la aplicacin productora puede generar, o en el caso que sea necesario
realizar ms transformaciones para realizar la integracin con nuevos sistemas, se
recomienda usar una solucin con estilo de bases de datos compartidas. O en el
caso que los periodos de frecuencia hayan disminuido y esto redunde en
intercambios de informacin muy pequeos comparados con los identificados en
el diseo de la solucin original, se recomienda el uso del estilo de mensajera.
4.1.2.2 Bases de datos compartidas

Figura 3. Bases de datos compartidas [16].

33

Las bases de datos compartidas, al igual que la solucin de transferencia de

archivos, se basa en un estilo de integracin, en este caso se basa en el estilo de
integracin de base de datos compartida (Shared Database) [16]. Cuando se
utiliza este estilo como solucin a un problema de integracin, se usa una base de
datos la cual es compartida por todas las aplicaciones que participaran en la
solucin, de esta manera todas las aplicaciones que comparten su informacin
tienen la posibilidad de ver la informacin ms actualizada y sin inconsistencias, a
diferencia de la solucin 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 disearse el esquema de base de datos que satisfaga las
necesidades de cada una de las aplicaciones involucradas y lo mantenga
consistente, adems de las polticas que limitaran el rango de accin y visibilidad a
cada aplicacin, 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.

Recomendacin:
En caso que sea necesario integrar la funcionalidad y ya no los datos, se sugiere
el uso del estilo de integracin de procedimientos almacenados, o en caso que las
aplicaciones deseen intercambiar informacin en pequeas cantidades de datos,
entre ellas y ya no a travs de un esquema universal, se sugiere el uso del estilo
de integracin de mensajera.

34

4.1.2.3 Invocacin remota de procedimientos

Figura 4. Invocacin remota de procedimientos [16].

En esta solucin, al contrario del estilo de integracin de bases de datos

compartidas, no son los datos, si no la funcionalidad la que se comparte con las
dems aplicaciones. Esto se logra a travs del llamado de los mtodos de las
aplicaciones remotas, los cuales previamente han sido publicados

por la

aplicacin 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 mtodos de aplicaciones externas, de la misma
manera como se hace con los mtodos locales. Sin embargo esto puede generar
inconvenientes, pues al invocar un mtodo remoto, este no se comporta de la
misma manera que uno local y por esta razn pueden generarse errores
inesperados. Estos pueden deberse a fallas en la red, lo cual evita que el mtodo
pueda ser invocado, o que la aplicacin propietaria del mtodo remoto no se
encuentra disponible en este momento. Finalmente otro aspecto a tener en cuenta
en esta solucin es la modificacin de dichos mtodos, pues mientras no se
alteren las firmas de dichos mtodos no habrn 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

35

tengan en cuenta dichas modificaciones, pues de lo contrario se producir un error

al intentar llamar el mtodo con los parmetros equivocados.

Recomendacin:
En caso que se necesitara hacer llamados asncronos a las aplicaciones, y/o de
buscar un menor acoplamiento entre las aplicaciones a integrar, se sugiere el uso
de mensajera como solucin a estos nuevos requerimientos de integracin.
4.1.2.4 Mensajera

Figura 5. Mensajera [16].

La mensajera es una tecnologa que permite a dos aplicaciones su comunicacin

de manera confiable, asncrona y con alto rendimiento. Al utilizar esta tecnloga
las aplicaciones se comunican a travs de canales envindose paquetes de datos
denominados mensajes, como se muestra en la Figura 5. Un canal funciona como
una coleccin de mensajes que puede ser compartido por mltiples aplicaciones y
utilizado concurrentemente. Las aplicaciones actan con roles bien definidos en la
comunicacin: productor y consumidor. Un productor (o emisor) es una aplicacin
que enva mensajes escribindolos en un canal, mientras que un consumidor (o
receptor) es una aplicacin que recibe los mensajes leyndolos 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 comunicacin en s misma es llevada a cabo a travs de los
36

denominados sistemas de mensajera.

Figura 6. Aplicaciones comunicadas usando mensajera.

Sistemas de mensajera

Las capacidades de mensajera son tpicamente provistas por sistemas de

software denominados sistema de mensajera o Message Oriented Middleware
(MOM). Los MOMs son componentes especializados en el manejo de mensajes.
Su fin principal es participar como intermediario entre la comunicacin de
aplicaciones, logrando desacoplarlas. Las aplicaciones se comunican con los
sistemas de mensajera a travs 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. Comunicacin basada en mensajera a travs de un MOM.

37

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 enve un mensaje el destinatario est
activo y disponible, o en caso de que lo est, podra ser que la red de
comunicacin presente no disponibilidad. Previo a la aparicin de los MOMs, para
atacar este tipo de problemtica se implementaba manualmente la retransmisin
de mensajes hasta asegurarse que el receptor los haba procesado. Esto haca
que cada vez que se deseaba usar mensajera se debieran afrontar una y otra vez
los mismos problemas. Como respuesta a esto, surgen los sistemas de
mensajera, que permiten a quien enva un mensaje olvidarse del mismo luego del
envo, delegando al sistema de mensajera la responsabilidad de asegurar la
entrega del mensaje a su destinatario. A continuacin se enumeran los
componentes de un sistema de mensajera as como su responsabilidad segn
[16]:

Canales: Son direcciones lgicas en el sistema de mensajera 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 mensajera.

Puntos de acceso (endpoints): Es el punto de entrada al sistema de

mensajera. Para poder acceder a un canal, las aplicaciones tienen que
conectarse al sistema de mensajera, y dicha conexin se da a travs 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 problemtica
independizando a las aplicaciones de este manejo.

38

Componentes de transformacin 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 transmisin: El proceso de transmisin de los

mensajes es el proceso ms relevante para un sistema de
mensajera 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 mensajera 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. Transmisin de mensajes paso a paso [16].

En la Figura 8, se muestran los pasos descritos anteriormente, adems se puede

apreciar la aplicacin 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 aplicacin entrega el mensaje en el canal, puede seguir

39

ejecutando dado que esta deleg la entrega del mensaje al sistema de

mensajera. La aplicacin confiar en que el receptor recibir el mensaje, y no
esperar hasta que esto ocurra.

En el paso 2, en el momento que la aplicacin entrega el mensaje en el canal, el

sistema de mensajera lo almacena. Luego en el paso 3, el sistema de mensajera
entrega el mensaje redirigindolo 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 mquina destino.

Modelos de comunicacin: generalmente los sistemas de mensajera

soportan alguno de estos modelos de comunicacin:

Point-to-Point: Este modelo es basado en canales punto a punto.

Cuando una aplicacin 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 slo uno
obtendr cada mensaje. El sistema de mensajera se encargara de
determinar cul de los destinatarios subscritos obtendr el mensaje.

Publish-Subscribe: Este modelo permite que una aplicacin varios

destinatarios simultneamente. Para esto, las aplicaciones colocan los
mensajes en un canal que corresponde a cierto tpico definido, el cual
tiene el siguiente comportamiento: los interesados en recibir mensajes
del tpico 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.

Caractersticas y servicios de un MOM: en general, los MOMs brindan

varias de las caractersticas y servicios que se describen a continuacin:

Garanta de Entrega de mensajes: dos aplicaciones que se estn

comunicando mediante un MOM no necesitan estar conectadas

40

simultneamente para que el envo de los mensajes sea exitoso. El

MOM asegura que los mensajes enviados a un destinatario que no est
conectado, sern entregados al mismo cuando este vuelva a estarlo.

Comunicacin Asncrona: luego que una aplicacin enva un mensaje a

otra, el MOM permite que la aplicacin 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 adems

en general se proveen mecanismos de integracin 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
sern entregados una sola vez, y que adems los mismos sern
entregados respetando el orden en que fueron enviados.

Servicios de ruteo de mensajes: permiten definir reglas de ruteo a nivel

de configuracin mediante las cuales al enviar un mensaje a un
determinado canal, los mismos son enrutados segn las configuraciones
indicadas.

Servicios de notificacin: en algunos casos las aplicaciones que envan

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 MOMs proveen mecanismos de notificacin, de
forma que al ser procesado el mensaje por su receptor se pueda
entregar el resultado de este procesamiento al productor del mismo.

Despus de conocer los conceptos bsicos y los elementos que componen un

sistema de mensajera, se proceder a la explicacin de los patrones de
integracin empresarial y su categorizacin.

41

Los patrones de integracin empresarial fueron descritos por primera vez en la

conferencia de Patrones de Lenguaje de Programacin [27], en el ao 2002 por
Gregor Hohpe [26]. Dichos patrones, son una evolucin de los patrones de diseo
de software tradicionales, a un contexto especifico, como lo es la integracin de
aplicaciones empresariales. Estos patrones representan las decisiones que
debern tomarse al momento de integrar dos o ms aplicaciones en un contexto
empresarial y las consideraciones que implica tomar esas decisiones.

En la actualidad, se consideran 65 patrones de integracin empresarial [16], cuyo

planteamiento se basa en la mensajera asncrona como piedra angular para la
integracin. A continuacin se describen las categoras que componen estos
patrones y que parte del problema de comunicacin dentro de la mensajera
solucionan.
4.1.2.4.1 Categorizacin de Patrones de Integracin Empresarial
Los patrones de integracin empresarial han sido agrupados en seis (6) categoras
[16], como se muestra en la Figura 9, las cuales reflejan el alcance (scope) y la
abstraccin de los patrones. Resolviendo de esta manera una situacin especfica
dentro del proceso de integracin.

42

Figura 9. Categorizacin de Patrones de integracin 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 comunicacin entre las aplicaciones, cuando se desea
integrar dos o ms sistemas de software. Por lo tanto estos patrones resuelven
distintos problemas de transporte de los mensajes entre aplicaciones. Por ejemplo,
las aplicaciones que envan informacin por un canal no tienen por qu conocer
cul es el receptor final de los datos que produce, sin embargo seleccionando un
canal en particular el productor puede asegurarse que quien reciba la informacin
es quien la esperaba. Apuntan a especificar caractersticas de los canales de
comunicacin a utilizar, como por ejemplo: si el mensaje es enviado a uno o a
muchos receptores, garanta de entrega de los mensajes que se transportan por el
canal, expiracin de los mensajes enviados al canal, entre otros. Los patrones que
integran la categora son:

43

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 construccin del mensaje

Estos patrones, contemplan los aspectos que se encargan de envolver los datos
de inters en un mensaje, para que pueda ser transmitido a travs de los canales,
que llevaran la informacin hacia los interesados en el mensaje. De esta manera
abordan el diseo de los mensajes que envan los diferentes participantes de una
comunicacin. Por ejemplo, en el intercambio que se realiza entre dos
aplicaciones, la informacin se enva insertndola en un mensaje. Apuntan a
especificar la informacin que contienen los mensajes, su semntica, informacin
adicional para permitir su procesamiento adecuado, entre otros. Los patrones que
integran esta categora son:

Command Message.

Document Message.

Event Message.

Request-Reply.

Return Address.

Correlation Identifier.

Message Sequence.

44

Message Expiration.

Format Indicator.

Patrones de enrutamiento del mensaje

Estos patrones, describen las distintas soluciones para proveer enrutamiento e

intermediacin

para una solucin de integracin. Dichos patrones estn

relacionados con el ruteo de los mensajes desde una aplicacin a otra. Por
ejemplo, permiten desacoplar los componentes que realizan en conjunto el
procesamiento en etapas de determinada informacin, logrando que la secuencia
de pasos a realizar dependa de un conjunto de condiciones. Apuntan a la
configuracin de rutas por las que deben pasar los mensajes para su
procesamiento, independizando a quien enva o recibe los mensajes de esta
lgica. Cabe anotar que muchos de los patrones agrupados en esta categora son
refinamientos o combinaciones del patrn Message Router [16]. Los patrones que
componen esta categora son:

Content-Based Router.

Message Filter.

Dynamic Router.

Recipient List.

Splitter.

Aggregator.

Resequencer.

Composed Message Processor.

Scatter-Gather.

Routing Slip.

Process Manager.

Message Broker.

45

Patrones de transformacin del mensaje

Estos patrones, identifican y dan solucin 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
aplicacin. As como tambin modificaciones automticas que se realizan sobre
los mensajes. Los patrones que integran esta categora son:

Message Translator.

Envelope Wrapper.

Content Enricher.

Content Filter.

Claim Check.

Normalizer.

Canonical Data Model.

Patrones de puntos de acceso (EndPoint)

Estos patrones, describen cmo las aplicaciones involucradas en la integracin,

pueden conectarse al sistema de mensajera, para que puedan enviar y recibir
mensajes. Es decir estos patrones entregan pautas relacionadas a la generacin 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 categora son:

Message Endpoint.

Messaging Gateway.

Messaging Mapper.

Transactional Client.

46

Polling Consumer.

Event-Driven Consumer.

Competing Consumers.

Message Dispatcher.

Selective Consumer.

Durable Subscriber.

Idempotent Receiver.

Service Activator.

Patrones de gestin del sistema

Indican cmo atacar las necesidades de administracin, monitoreo y testeo de los

componentes del sistema y de los canales de comunicacin. Un claro ejemplo de
esto es la necesidad de extraer informacin 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 cadas en el rendimiento. Los patrones
que integran la categora son:

Control Bus.

Detour.

Wire Tap.

Message History.

Message Store.

Smart Proxy.

Test Message.

Channel Purger.

La solucin de mensajera, est asociada al estilo de integracin empresarial de

mensajera (Messaging) [16]. Cuando este estilo es usado como solucin a un
problema de integracin, es necesario una infraestructura de mensajera, que

47

adems de proveer el canal de comunicacin entre la aplicacin emisor y destino

involucradas en la integracin, provea los mecanismos de reintentos necesarios
para que los mensajes enviados entre las aplicaciones, sean entregados y no se
pierdan, adems en caso que la aplicacin 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, estn soportadas por

infraestructuras que promueven la fiabilidad de la comunicacin, adems de un
esquema de comunicacin asncrona entre las aplicaciones involucradas en el
proceso de integracin, lo que a su vez permite que las soluciones de integracin
puedan cada vez mas tener un comportamiento ms parecido a la naturaleza de
los negocios, pues es posible modelar los eventos de negocio necesarios para la
ejecucin de los procesos internos y la de aquellos que requieran de la
comunicacin de otras aplicaciones con las que se desea integrar.
Recomendacin:
Despus de tomar la decisin que la solucin escogida ser el estilo de
integracin de mensajera, se sugiere tener en cuenta, estas mnimas
consideraciones:

Debe definirse un canal o Message Channel, el cual se utilizara como

medio de comunicacin 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 mensajera por medio de

un Message Endpoint.

48

La bsqueda de las soluciones conocidas permiti refinar las variables de entrada

al mtodo definidas en el grupo de necesidades encontrando que mas que
necesidades estos cuatro (4) estilos de integracin son soluciones y bsicamente
las necesidades se pueden clasificar como: compartir datos y compartir
funcionalidad.
4.1.3 Etapa III Determinar el conjunto de buenas prcticas
El objetivo de la etapa es determinar el conjunto de buenas prcticas aplicables a
la integracin de aplicaciones empresariales, basado en la recopilacin a travs de
la consulta directa a un grupo de expertos y recopilacin de informacin en la
literatura existente. El resultado del trabajo realizado se detalla a continuacin.
4.1.3.1 Consulta a expertos
La seleccin de los miembros de este grupo se realiz fundamentalmente porque
son personas con una trayectoria que supera los 5 aos en la construccin de
importantes proyectos de integracin de aplicaciones empresariales, definicin de
estndares y mecanismos de integracin de las aplicaciones del

core de los

negocios para las empresas en que ellos trabajan.

Al consultar las buenas prcticas, que estos expertos aplican en su trabajo diario,
se observ que las respuestas se enfocaban a cada una de las necesidades de
integracin que se identificaron en la caracterizacin de los casos de negocio. En
la mayora de los casos los expertos resaltaron los pros y los contras de la buena
prctica. Por lo anterior la descripcin de estas buenas prcticas, se hace
agrupada por cada una de las necesidades de integracin y se identifican las
ventajas y desventajas de utilizarla:

49

4.1.3.1.1 Datos
Para la necesidad de integracin compartir datos, las buenas prcticas,
entregadas por el grupo de expertos, se resume a continuacin:

Uso de formato: por estndar, a nivel mundial el formato de los archivos

para hacer integracin debe ser XML. Las ventajas estn en la facilidad
para realizar las validaciones de los datos a travs del uso de XSD o DTD,
en la facilidad

que tienen para ser ledas por parte de los humanos y

rapidez con la que son validados por las maquinas. La desventaja est en
el tamao de los archivos, los archivos en formato XML siempre son de
mayor tamao que los archivos de otros formatos; esto se debe a que la
meta-data est inmersa en los archivos.

Generacin de archivos: la recomendacin entregada en este sentido es

que los archivos deben ser generados por los sistemas dueos de los
datos, en lugar que la aplicacin destino o una tercera aplicacin, genere el
archivo ingresando a los datos de la aplicacin origen.

Transporte: para este propsito 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 prcticas en el caso cuando existe la misma

entidad de base de datos en ambos sistema se recomienda:

Realizar sincronizacin con replicacin.

Definir las polticas de sincronizacin como por ejemplo la periodicidad.

Utilizar en lo posible los tipos de datos nativos del motor de base de

datos.

50

Definir un buen gobierno de datos. Quien es el dueo de los datos.

Si estn en la misma instancia se debe usar sincronizacin en lnea ya

que no es necesario hacer uso de la red de datos. La prctica ms
usada y recomendada por los expertos es utilizar gatillos, tambin
conocidos por la palabra en ingls trigers, siempre y cuando se tengan
bien establecidos los accesos y permisos sobre las tablas.

Si estn diferente instancias se recomienda crear una tabla temporal de

trabajo, para posteriormente, a travs de un proceso asncrono, realizar
la integracin.

4.1.3.1.2 Funcionalidades
Para la necesidad de integracin compartir funcionalidad, las buenas prcticas,
entregadas por el grupo de expertos, se resume a continuacin:

Mecanismo de exposicin: para realizar la exposicin de funcionalidades el

estndar adoptado por la industria son los servicios web usando SOAP o
Restful.

Consulta de informacin: Los servicios web son muy tiles para consumir
lgica 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 ms de 5MB es
mejor usar protocolos binarios tales como RMI-IIOP, DCOM o RPC.

Llamado a procedimientos: es el mecanismo recomendado para realizar la

invocacin de funcionalidades de forma sncrona.

51

4.1.3.1.3 Datos y funcionalidades

El grupo de expertos entreg un conjunto de buenas prcticas aplicables a las
necesidades compartir datos y compartir funcionalidad, las cuales se describen a
continuacin:

Los sistemas de mensajera entre aplicaciones Message Oriented

Middleware

son el mejor mecanismo asncrono de integracin 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 integracin.

Formato de los mensajes: Si la integracin 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 integracin 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 aplicacin 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 inclusin de otras aplicaciones
interesadas en consumir este mensaje, se debe usar Point to Point.

4.1.3.2 Buenas prcticas extradas de la literatura

En la revisin de la literatura se encontraron las siguientes buenas prcticas o
recomendaciones para cada una de los estilos de integracin:
4.1.3.2.1 Buenas prcticas para la transferencia de archivos
La transferencia de archivos, ha sido una de las tecnologas comnmente ms
utilizadas en el mundo, por las empresas de TI para intercambiar informacin [29],

52

Sin embargo la complejidad de los negocios y la necesidad continua de tener

respuestas con tiempos cada vez ms ajustados a las necesidades reales, han
desplazado a los antiguos procesos en batch, que comnmente se ejecutan fuera
de lnea y normalmente son concebidos para procesar grandes volmenes de
informacin [30], debido a su naturaleza desatendida. Todo lo anterior unido a la
aparicin de las herramientas de EAI [16], como respuesta a las necesidades cada
vez mas crecientes de integrar las aplicaciones de una o mltiples negocios,
generaron el surgimiento de tecnologas tales como la mensajera, que permiti
una comunicacin con solicitudes y operaciones ms granulares que las que se
alcanzaban con los procedimientos anteriores [29].

Sin embargo, la existencia de sistemas legados de misin crtica, 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 estratgico para:

Reducir los riesgos del negocio.

Entregar un nivel de retorno (RoI) atractivo.

Mayor velocidad de entrega para nuevas implementaciones y/o servicios.

Permitir rpidamente la intercomunicacin con los sistemas de otras

empresas (B2B).

A continuacin se describen cinco (5) buenas prcticas para la implementacin de

este estilo de integracin:

Confirmar la transmisin de los archivos: todos aquellos que estn

involucrados en la transferencia de uno o varios archivos generalmente
desean saber si estos han arribado satisfactoriamente a su destino final, por
esta razn una confirmacin explicita es bastante til para saber si el o los

53

archivos han sido recibidos correctamente [32]. Para esto se puede generar
un mensaje de retroalimentacin al cliente a travs de:

Colocando un archivo con la informacin de confirmacin en un FTP

del emisor.

Enviando un correo electrnico.

Haciendo una invocacin a un servicio web, informando la

confirmacin.

Colocando un mensaje en una cola.

Almacenando el registro en una tabla de base de datos.

Fallas en la transmisin 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 conexin 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 prctica en este caso es la de las soft fail [32], que consisten
en el reintento de la operacin sin intervencin humana, en un perodo de
una hora, sin embargo despus de cinco (5) soft fail seguidas, deber
generarse una hard fail que de inmediato generara una notificacin al
personal encargado de los servidores de archivos, tanto los de recepcin
como los de emisin de los archivos.

Verificacin de falla de archivos: an despus 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

54

las hard fail no son tiles, y por ende se sugiere seguir las siguientes
buenas prcticas:

Verificar los archivos despus de recibidos, por parte del receptor.

Verificar los archivos de gran tamao, antes de transmitirlos, por

parte del emisor.

Enviar notificacin a los encargados de recibir el archivo y al receptor

en caso que la verificacin falle en cualquiera de los casos
anteriormente descritos.

Mejor protocolo: a menudo se presentan ciertas restricciones sobre los

protocolos que podrn ser usado para la transferencia de los archivos, sin
embargo cuando dicha restriccin 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 nmero de
comunidades en Internet, adems de su seguridad.

Usar fechas, horas y minutos en la convencin 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 confusin y para prevenir que los viejos archivos sean sobre escritos
con los ltimos datos, por esta razn el uso de fechas, hora y minutos en
los nombres de los archivos permiten alcanzar esta meta [32].

Finalmente siguiendo estas buenas prcticas, pueden ser construidos ambientes

robustos para la transferira de archivos dentro de una organizacin o entre sus
proveedores o clientes (B2B).

55

4.1.3.2.2 Buenas prcticas para bases de datos compartidas

Cuando se requiere que varias aplicaciones, almacenen los datos que quieren
compartir en una base de datos en comn, 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 razn un par de buenas prcticas para evitar esta situacin son:

Limitar el acceso de los clientes, solo a los objetos de inters para el.

Utilizar vistas o snapshots, para la extraccin de la informacin, esto

previene que los clientes observen las estructuras de las entidades y la
informacin que no es de su inters [33].

Permitir la manipulacin de los datos a travs 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 prcticas para compartir bases de datos, no son por si solas la
mejor solucin, pues deben estar acompaadas por una correcta verificacin del
administrador de la base de datos, quien definir con ayuda de lo descrito por el
cliente, la informacin que este realmente necesita y la definicin de posibles
casos que llevaran a abortar la transaccin al momento de modificar los datos,
adems de identificar los posibles escenarios, que podran generar inconsistencias
y como evitarlas pues no se debe olvidar que la informacin puede estar siendo
manipulada por varias aplicaciones al tiempo.

4.1.3.2.3 Buenas prcticas para invocacin remota de procedimientos

En la revisin de la literatura realizada no se encontraron buenas prcticas para
este estilo de integracin. Por lo tanto en lo que sigue del desarrollo del mtodo
trabajaremos con las buenas prcticas para invocacin remota de procedimientos
identificadas en la consulta directa a expertos.
56

4.1.3.2.4 Buenas prcticas para mensajera

En la actualidad, los sistemas de mensajera, se muestran como los medio de
comunicacin ms adecuados para la intercomunicacin de aplicaciones
empresariales [16], por esta razn y despus de su uso intensivo por parte de
millones de desarrolladores, se encuentra en la literatura [16] las buenas prcticas
en un grupo de patrones que se han denominado patrones de integracin
empresarial, como se expuso en la etapa II de esta fase, y que se basan en el uso
del estilo de integracin de mensajera como pilar principal para la integracin.

Como se mostr en esta etapa, existen buenas prcticas conocidas para cada
estilo de integracin, por lo tanto no existe un estilo mejor que otro, sino que cada
situacin indica qu estilo debe ser usado, o en algunos casos, cules estilos
deben ser combinados [31]. A continuacin se presentan en la Tabla 1, algunos
pros y contras de cada uno de los estilos.

Estilo de integracin

Ventajas
Simple,

Desventajas
No es transaccional, ni para

Transferencia de archivos Interoperable.

necesidades en tiempo real.

Bases de datos

Simple,

Puede ser lento y difcil de

compartidas

transaccional.

evolucionar.

Invocacin remota de

Simple, puede ser No es interoperable, sncrono y

procedimientos

rpido.

altamente acoplado.

Asncrono,
Mensajera

escalable.

Complejo.

Tabla 1 Ventajas y desventajas de los estilos de integracin [31].

57

Para finalizar esta seccin de buenas prcticas, se presenta a continuacin un

cuadro que ofrece una primera alternativa hacia el uso de Frameworks, en caso de
requerir alguno de estos estilos.

Estilo de integracin
Transferencia de archivos
Bases de datos
compartidas
Invocacin remota de
procedimientos

Framework
Spring resource abstraction, Spring Batch,
GoAnyWhere, Kettle
Spring data access (JDBC, Object-Relational
Mapping, transaction)
Spring Remoting (Remote Method Invocation,
HttpInvoker, Hessian, Burlap), EJB Session
Stateless
Spring JmsTemplate, Spring message container

Mensajera

listeners, Spring Integration, Message Driver Bean,

EJB

Tabla 2 Estilos de integracin y los Frameworks que los implementan.

4.2 Fase II Diseo del mtodo
Conforme a la metodologa establecida, se desarroll la fase II del proyecto. El
resultado de las actividades realizadas se detalla a continuacin:
4.2.1 Etapa I: Definicin de categoras
Para la definicin de las categoras en las que se pueden clasificar los casos de
negocio que son objeto del mtodo diseado, se tom la decisin de
categorizarlos de acuerdo a la necesidad de integracin que se busca resolver. La
decisin se tom en un inicio teniendo en cuenta que la necesidad de integracin
es la que prcticamente define el caso de negocio y que las otras caractersticas
son complementos que permiten particularizar aspectos del mismo. Durante la
etapa de definicin de filtros se valid completamente la decisin aqu tomada;
pues en esta etapa se pudo evidenciar que la necesidad de integracin es una
58

sola para cada caso de negocio y que las otras variables se pueden presentar
simultneamente en la caracterizacin de este; siendo la necesidad de
integracin la que determina la combinacin que se puede presentar entre dems
variables. Por lo anterior en esta etapa se definieron:

Categora 1: casos de negocio para compartir datos.

Categora 2: casos de negocio para compartir funcionalidad.

4.2.2 Etapa II: Soluciones conocidas aplicables por categora

Para la Categora 1, casos de negocio regidos por datos, las soluciones conocidas
aplicables son [16]:

Transferencia de Archivos

Bases de datos compartidas

Mensajera

Para la Categora 2, casos de negocio regidos por funcionalidad, las soluciones

conocidas aplicables son [16]:

Invocacin Remota de procedimientos

Mensajera

4.2.3 Etapa III: Buenas prcticas aplicables por categora

Esta etapa de la metodologa, bsicamente se resolvi en la Etapa III de la Fase I
en la que las buenas prcticas quedaron clasificadas de acuerdo a las
necesidades de integracin y en la Etapa I de la Fase II en la que las necesidades
de integracin se definieron como las categoras del mtodo.
4.2.4 Etapa IV: Definicin 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 integracin de aplicaciones
empresariales se identificaron cuatro (4) grupos de variables. El objetivo de esta
etapa de la metodologa fue identificar cules variables son excluyentes y cules
son complementarias; identificacin que corresponde al insumo necesario y

59

suficiente para la creacin de los filtros que conducirn a la correcta la

caracterizacin del caso de negocio.

4.2.4.1 Combinacin de variables

La identificacin 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 continuacin se muestra el proceso realizado y el
resultado de esta identificacin, para lo cual es importante resaltar que los casos
en que las variables se subdividen en varias sub-variables, el anlisis se realiz a
nivel de sub-variables.
4.2.4.1.1 Entre el mismo grupo
El propsito de esta actividad fue evaluar la compatibilidad entre las variables de
un mismo grupo. El resultado de este trabajo se muestra a continuacin:

Grupo I: Tipos de Aplicaciones

Para realizar esta actividad se parte de dos premisas fundamentales: Una

aplicacin solo puede tener un nico tipo y se excluyen las aplicaciones tipo
Tiempo Real que al ser evaluadas por la encuesta no obtuvieron una calificacin
promedio relevante para este estudio; Como se trabaja con un aplicacin origen y
una aplicacin destino el anlisis 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 aplicacin origen y las
columnas a los tipos de aplicacin destino; as, la casilla de interseccin entre fila
y columna marcada con un uno (1) indica que la combinacin es posible en caso
contrario se marca con un (0), ver Anexo 2.1 Tipos de aplicaciones. Despus de
realizar el anlisis de cada una de las combinaciones se encuentra que no hay
limitantes en cuanto al tipo de la aplicacin origen y destino, por lo cual el
resultado de esta actividad arroja una matriz con todas las posiciones con valor

60

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

integracin puede tener una o varias soluciones conocidas; por lo cual el alcance
del diseo del mtodo se restringe al manejo de una nica necesidad de
integracin por cada caso de negocio; en la ocasin en que el mismo caso de
negocio contemple diferentes necesidades de integracin, el caso de negocio
debe ser caracterizado tantas veces como necesidades de integracin 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 interseccin

entre fila y columna marcada con un uno (1) indica que la combinacin es posible
en caso contrario se marca con un (0), ver Anexo 2.2 Criterios y restricciones. En
el anlisis realizado se encontraron criterios y restricciones que son mutuamente
excluyentes, a continuacin se detallan las exclusiones resultantes:

Cada variable consigo misma: Debido a que la herramienta utilizada para el

anlisis es una matriz en la interseccin de filas y columnas surgi esta
relacin. Sin embargo en el diseo del mtodo esta relacin no existe as
que la diagonal de la matriz se marc con valor cero (0). En este anlisis
no hubo identificacin de filtros.

Sub-variables asociadas a la misma variable: Por la definicin de cada subvariable, en el anlisis se encontr que las sub-variables son mutuamente
excluyentes entre s cuando estn asociadas a la misma variable. Por lo
anterior las casillas de interseccin entre sub-variables asociadas a la
misma variable se marcaron con cero (0). En este anlisis se identific el
61

Filtro 1. Es importante resaltar que esta exclusin tiene contenida la

exclusin del numeral anterior.

Intrusin no permitida: Por definicin de la sub-variable Intrusin no

permitida y de la sub-variable Modificar la aplicacin para usar un formato
de datos comn,

se encuentra la mutua exclusin. Es este anlisis se

identific el Filtro 2.

Formato de los datos: Por definicin de la variable Formato de los datos y

de la sub-variable Funcionalidad se encuentra la mutua exclusin. Es este
anlisis se identific el Filtro 3.

Latencia en el intercambio de datos: Por definicin de la variable Latencia

en el intercambio de datos y de la sub-variable Funcionalidad se encuentra
la mutua exclusin. Es este anlisis se identific el Filtro 4.

Destino NO siempre disponible y sncrona: Por definicin de la sub-variable

Sncrona y de la sub-variable Destino NO siempre disponible se encuentra
la mutua exclusin. Es este anlisis se identific el Filtro 5.

Destino NO siempre disponible y Funcionalidad: Por definicin de la subvariable Funcionalidad y de la sub-variable Destino NO siempre disponible
se encuentra la mutua exclusin. En este anlisis se identific el Filtro 6.
Adems en el anlisis tambin se identific que la aplicacin que provee la
funcionalidad siempre es la aplicacin destino lo cual llev a identificar el
Filtro 6 Funcionalidad y destino.

Como resultado de este anlisis se obtuvo una matriz simtrica debido a que las
exclusiones encontradas entre las sub-variables son mutuas.

Grupo IV: Caractersticas de calidad

En este grupo el anlisis se orient con la revisin de la literatura [25], en la que se

encuentra ampliamente documentada la exclusin entre las caractersticas de
calidad. Se identificaron cuatro (4) filtros como resultado de esta revisin:

62

Filtro 7: Caractersticas de calidad que se ven afectados negativamente al

definir funcionalidad como requerimiento

Filtro 8: Caractersticas de calidad que se ven afectados negativamente al

definir eficiencia de rendimiento como requerimiento

Filtro 9: Caractersticas de calidad que se ven afectados negativamente al

definir Capacidad de operacin como requerimiento

Filtro 10: Caractersticas 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 caractersticas de calidad; la casilla de

interseccin entre fila y columna marcada con un uno (1) indica que la
combinacin es posible en caso contrario se marca con un (0), ver Anexo 2.3
Caractersticas de calidad.
4.2.4.1.2 Entre los diferentes grupos
Como parte del anlisis se defini la siguiente premisa fundamental: Las variables
del grupo caractersticas de calidad no son excluyentes con las variables de
ningn otro grupo, porque las caractersticas de calidad pueden ser requeridos
independientemente de la necesidad de integracin, 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 Aplicacin 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 interseccin entre fila y columna marcada con un uno (1) indica que la
combinacin es posible en caso contrario se marca con un (0), para este anlisis
se separaron los tipos de aplicaciones transaccionales 1 y 2 que se haban venido

63

manejando, en los anteriores anlisis 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 anlisis es requerido revisar por separado, ver
Anexo 2.4 Criterios y restricciones tipo de aplicacin origen. En el anlisis
realizado se encontr que en por la definicin de aplicacin tipo batch, es
excluyente con las sub-variables: funcionalidad y aplicacin destino no siempre
disponible en este segundo caso solo se puede resolver cuando hay tecnologa
disponible que lo permita. En este anlisis 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 Aplicacin 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 interseccin entre fila y columna marcada con un uno (1) indica que la
combinacin es posible en caso contrario se marca con un (0), para este anlisis
se separaron los tipos de aplicaciones transaccionales 1 y 2 que se haban venido
manejando, en los anteriores anlisis 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 anlisis es requerido revisar por separado, ver
Anexo 2.5 Criterios y restricciones tipo de aplicacin destino. En el anlisis
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 aplicacin origen es batch, se encontr que las siguientes subvariables del grupo criterios y restricciones deben estar presentes: intrusin
permitida, compartir datos, comunicacin sncrona y destino siempre
disponible.

64

Filtro 13B: Batch y criterios y restricciones excluyentes: el resultado del

numeral anterior implica que las sub-variables: intrusin no permitida,
compartir funcionalidad, comunicacin asncrona 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 seleccin de la
tecnologa no son requeridas ni excluyentes con la necesidad bases de
datos compartidas; pues no es relevante que estn presentes o ausentes
al analizar este tipo de aplicacin.

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 Utilizacin 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 integracin es la
que determina la caracterizacin del caso de negocio y por ende es la que define
los valores que pueden tomar las dems variables y sub-variables. A continuacin
se muestran los filtros y el orden en que se aplicarn

Identificar

necesidad

de

integracin:

Como

se

haba

expuesto

anteriormente, se parte de la premisa que la necesidad de integracin es

una sola para el caso de negocio.

Una vez identificada la necesidad de integracin, datos o funcionalidad, la

siguiente variable a identificar es el tipo de aplicacin origen; se establece
que una aplicacin origen solo puede tener un nico tipo.

Una vez identificada la necesidad de integracin y el tipo de aplicacin

origen, la siguiente variable a identificar es el tipo de aplicacin destino; al
igual que en el punto anterior la aplicacin destino solo puede tener un
nico tipo, en caso que se requiera integrar una aplicacin origen con varias

65

destino cada integracin se considera un caso de negocio distinto y debe

evaluarse por separado en el mtodo. No hay exclusiones a evaluar entre
los tipos de aplicaciones origen y destino;

Con la necesidad de integracin y los tipos de aplicaciones origen y destino

identificadas, se pasa a identificar los criterios y restricciones de
integracin. En este punto se pueden identificar varios criterios y
restricciones para un caso de negocio. Las exclusiones que se deben
evaluar son:

Necesidad de integracin identificada vs. Criterios y restricciones.

Tipo de aplicacin origen identificada vs. Criterios y restricciones.

Tipo de aplicacin destino identificada vs. Criterios y restricciones.

Criterios y restricciones vs. Criterios y restricciones.

Caractersticas de calidad vs. Caractersticas de calidad.

4.2.5 Etapa V: El mtodo diseado

Como resultado de esta fase de la metodologa, se resume en los siguientes
pasos:
Paso1: Documentar el caso de negocio determinando los valores para cada
una de las variables de caracterizacin definidas. Con ello se definen las
variables de entrada al mtodo.

Paso2: Aplicar los filtros, en el orden descrito en la ltima etapa de esta

fase, para con ello encontrar la correcta caracterizacin del caso de negocio
y por consiguiente asociarlo a una de las siguientes categoras:

Categora 1: casos de negocio regidos datos.

Categora 2: casos de negocio regidos por funcionalidad.

Paso3: Buscar las soluciones conocidas aplicables a la categora

encontrada.

Paso4: Buscar las buenas prcticas aplicables a la categora encontrada.

Paso5: Entregar la soluciones conocidas en el orden de aplicabilidad.

66

4.3 Fase III Prueba del diseo del mtodo

Conforme a la metodologa establecida se desarrollo la tercera y ltima fase del
proyecto. Los resultados se muestran a continuacin:
4.3.1 Etapa I: Refinamiento del mtodo
El objetivo de esta etapa es encontrar una serie de criterios que permitan validar el
conjunto de recomendaciones que el mtodo entrega. Para ello se trabaj en
elaborar un conjunto de filtros adicionales que trabajan sobre las soluciones
conocidas y las dems variables de caracterizacin. Estos filtros adicionales se
describen a continuacin.
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 integracin y las columnas corresponden a cada uno de los criterios y
restricciones; la casilla de interseccin entre fila y columna marcada con un uno
(1) indica que la combinacin es posible en caso contrario se marca con un (0),
ver Anexo 3.1 Soluciones conocidas criterios y restricciones. En el anlisis
realizado se encontraron necesidades de integracin con criterios y restricciones
que son mutuamente excluyentes, a continuacin se detallan las exclusiones
resultantes:
4.3.1.1.1 Transferencia de Archivos y Funcionalidad:
Por definicin de la sub-variable Funcionalidad y de la variable Transferencia de
Archivos se encuentra la mutua exclusin. En este anlisis se identific el Filtro 15.
4.3.1.1.2 Bases de Datos Compartidas
Por definicin de la variable Bases de datos compartidas se encuentra la exclusin
con la todas las variables del grupo criterios y restricciones. En este anlisis se
identific el Filtro 16. En el cual se define:

67

4.3.1.1.3 Filtro 16A

Requisitos de criterios y restricciones necesarios para la solucin bases de datos
compartidas: si se define que la solucin es compartir bases de datos, se encontr
que las siguientes sub-variables del grupo criterios y restricciones deben estar
presentes: intrusin permitida, compartir datos, comunicacin sncrona y destino
siempre disponible.
4.3.1.1.4 Filtro 16B
Criterios y restricciones excluyentes para la solucin bases de datos compartidas:
el resultado del numeral anterior implica que las sub-variables: intrusin no
permitida, compartir funcionalidad, comunicacin asncrona 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 solucin bases de datos
compartidas: las variables formato de los datos, latencia en el intercambio de
datos y seleccin de la tecnologa no son requeridas ni excluyentes con la solucin
bases de datos compartidas; pues no es relevante

que estn presentes o

ausentes al analizar la solucin bases de datos compartidas.

4.3.1.1.6 Invocacin Remota de Procedimientos
Por definicin de la solucin Invocacin Remota de Procedimientos se encuentra
la exclusin 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 anlisis se identific el Filtro 17.

4.3.1.1.7 Mensajera
Por definicin de la solucin Mensajera se encuentra la exclusin la sub-variable
del grupo criterios y restricciones seleccin de la tecnologa no disponible. En este
anlisis se identific el Filtro 18.

68

4.3.1.2 Soluciones Conocidas Vs. Tipo de Aplicacin Origen

Se elabor una matriz en la que las que las filas corresponden a las soluciones
conocidas de integracin y las columnas corresponden a los tipos de aplicaciones
origen; la casilla de interseccin entre fila y columna marcada con un uno (1)
indica que la combinacin es posible en caso contrario se marca con un (0), ver
Anexo 3.3 Soluciones conocidas tipo de aplicacin origen. En el anlisis realizado
se encontr que la solucin conocida de integracin invocacin remota de
procedimientos es excluyente con el tipo de aplicacin origen batch. En este
anlisis se identific el filtro 19.
4.3.1.3 Soluciones Conocidas Vs. Tipo de Aplicacin Destino
Se elabor una matriz en la que las que las filas corresponden a las soluciones
conocidas de integracin y las columnas corresponden a los tipos de aplicaciones
destino; la casilla de interseccin entre fila y columna marcada con un uno (1)
indica que la combinacin es posible en caso contrario se marca con un (0), ver
Anexo 3.4 Soluciones conocidas tipo de aplicacin destino. En el anlisis realizado
se encontr que en por la definicin de aplicacin tipo batch, la nica solucin
conocida de integracin que puede tener como aplicacin destino tipo batch es la
de bases de datos compartidas. En este anlisis se identific el filtro 20.
En este punto se define incluir un nuevo paso para realizar la aplicacin de los
filtros encontrados en esta etapa. El mtodo refinado se define en los siguientes
pasos:

Paso1: Documentar el caso de negocio determinando los valores para cada

una de las variables de caracterizacin definidas. Con ello se definen las
variables de entrada al mtodo.

Paso2: Aplicar los filtros para con ello encontrar la correcta caracterizacin
del caso de negocio y por consiguiente asociarlo a una de las siguientes
categoras. La aplicacin de los filtros debe realizarse en el siguiente orden:

69

Identificar necesidad de integracin: La necesidad de integracin es

una sola para el caso de negocio

Con la necesidad de integracin definir la categora del caso de

negocio

Una vez identificada la necesidad de integracin, la siguiente

variable a identificar es el tipo de aplicacin origen

Una vez identificada la necesidad de integracin y el tipo de

aplicacin origen, la siguiente variable a identificar es el tipo de
aplicacin destino

Con la necesidad de integracin y los tipos de aplicaciones origen y

destino identificadas, se pasa a identificar los criterios y restricciones
de integracin. 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 aplicacin origen identificada vs. Criterios y restricciones
o Tipo

de

aplicacin

destino

identificada

vs.

Criterios

restricciones
o Criterios y restricciones vs. Criterios y restricciones
o Caractersticas de calidad vs. Caractersticas de Calidad

Paso3: Buscar las soluciones conocidas aplicables a la categora

encontrada

Paso4: Aplicar los filtros:

Soluciones conocidas vs. criterios y restricciones

Soluciones conocidas vs. tipo de aplicacin origen

Soluciones conocidas vs. tipo de aplicacin destino

Paso5: Buscar las buenas prcticas aplicables a la categora encontrada.

Paso6: Entregar la soluciones conocidas y buenas prcticas aplicables a la

categora

70

4.3.2 Etapa II: Aplicacin del mtodo diseado

Para la prueba del mtodo se recolectaron diez (10) casos reales de integracin
de aplicaciones presentados en los dos ltimos aos en los proyectos de
integracin de aplicaciones del grupo empresarial Coomeva.
Cada uno de los casos de negocio se someti a los seis (6) pasos del mtodo
diseado. La documentacin de la aplicacin del mtodo para los diez (10) casos
de negocio probados se encuentra detallada en el Anexo3.5 Caracterizacin de
los casos de negocio y soluciones

Paso1: Durante la ejecucin del Paso1 se observ que las variables

identificadas y los valores definidos para ellas, fueron las necesarias y
resultaron suficientes para la caracterizacin de los casos de negocio.

Paso2: Durante la ejecucin del Paso2 se encontr que en la definicin de

los filtros falt la evaluacin de la existencia de una posible exclusin entre
los criterios Formato de datos y Seleccin de la tecnologa, en cuanto a que
en algunos casos puede ser requerido utilizar un mediador que homologue
los datos lo que implica que deba existir tecnologa para realizarlo. En este
anlisis

y por tratarse de solo algunos casos se agreg a la matriz de

combinacin de variables de criterios y restricciones la Evaluacin 1. La

matriz actualizada se muestra en el Anexo 3.2 Criterios y restricciones
refinado. Adicional a lo anterior, durante la aplicacin de filtros, se encontr
que es necesario caracterizar el caso de negocio con una caracterstica de
calidad principal que determinar la inclusin o exclusin de las restantes
caractersticas en la caracterizacin del caso de negocio.

Paso3: Durante la ejecucin se observ que realizar el Paso3 se obtiene

como consecuencia inmediata una vez se ha realizado el paso2 de manera
adecuada.

71

Paso4: Durante la ejecucin del paso4 se observ que los filtros

identificados, fueron los adecuados para refinar la caracterizacin de los
casos de negocio.

Paso5: Durante la ejecucin 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 relacin
directa de buenas prcticas con soluciones conocidas. Por lo anterior el
mtodo se refin para agrupar las buenas prcticas a cada una de las
soluciones conocidas. El Paso 5 qued entonces definido as: buscar las
buenas

prcticas asociadas a cada solucin conocida aplicable a la

categora encontrada como se muestra en la Tabla 3.

Paso6: Durante la ejecucin 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.

Solucin Conocida
Transferencia de archivos

Buenas prcticas
Uso de Formato
Generacin de Archivos
Transporte

Sincronizacin y polticas
Tipos de datos nativos
Gobierno de datos
Mecanismo de Exposicin
Invocacin remota de procedimientos Consulta de informacin
Llamado a procedimientos
Bases de datos compartidas

Mensajera

Formato de los mensajes

Mecanismos de entrega de los mensajes

Tabla 3 Buenas prcticas agrupadas por cada solucin conocida.

72

El mtodo final refinado y aplicado qued definido como lo muestra la Figura 10.
Los pasos se describen a continuacin:

Paso1: Documentar el caso de negocio determinando los valores para cada

una de las variables de caracterizacin definidas. Con ello se definen las
variables de entrada al mtodo.

Paso2: Aplicar los filtros para con ello encontrar la correcta caracterizacin
del caso de negocio y por consiguiente asociarlo a una de las siguientes
categoras. La aplicacin de los filtros debe realizarse en el siguiente orden:

Identificar necesidad de integracin: La necesidad de integracin es una

sola para el caso de negocio

Con la necesidad de integracin definir la categora del caso de negocio

Una vez identificada la necesidad de integracin, la siguiente variable a

identificar es el tipo de aplicacin origen

Una vez identificada la necesidad de integracin y el tipo de aplicacin

origen, la siguiente variable a identificar es el tipo de aplicacin destino

Con la necesidad de integracin y los tipos de aplicaciones origen y

destino identificadas, se pasa a identificar los criterios y restricciones de
integracin. En este punto se pueden identificar varios criterios y
restricciones para un caso de negocio. Las exclusiones que se deben
evaluar son:

Tipo de aplicacin origen identificada vs. Criterios y restricciones

Tipo de aplicacin destino identificada vs. Criterios y restricciones

Criterios y restricciones vs. criterios y restricciones

Caractersticas de calidad vs. caractersticas de Calidad

Paso3: Buscar las soluciones conocidas aplicables a la categora

encontrada

Paso4: Aplicar los filtros:

Soluciones conocidas vs. criterios y restricciones

73

Soluciones conocidas vs. tipo de aplicacin origen

Soluciones conocidas vs. tipo de aplicacin destino

Paso5: Buscar las buenas prcticas asociadas a cada solucin conocida

aplicable a la categora.

Paso6: Entregar la soluciones conocidas y buenas prcticas aplicables a la

categora encontrada.

Figura 10. Esquema del mtodo diseado

Al realizar el anlisis cualitativo de las soluciones entregadas por el mtodo para

los diez (10) casos de negocio caracterizados se encontr que:

74

En todos los casos la solucin real implementada coincide con una de las
soluciones recomendadas por el mtodo.

En todos los casos la solucin real implementada se encuentra entre las

dos soluciones ms recomendadas por el mtodo.

En el cuarenta por ciento de los casos la solucin real implementada es la

solucin ms recomendada por el mtodo.

En el sesenta por ciento de los casos la solucin ms recomendada por el

mtodo fue la mensajera, la cual no coincidi con la solucin real
implementada. Esto se debe a que en el Grupo Empresarial Coomeva, la
mensajera no haba sido evaluada como una solucin viable para los
problemas de integracin.

La Tabla 4 muestra de manera general lo anteriormente descrito:

Tabla 4 Comparativo entre solucin real y soluciones recomendadas.

Al realizar el anlisis cualitativo para los casos en los que la solucin ms

recomendada entregada por el mtodo no coincide con la solucin real
implementada, se encontr en todos los casos la posibilidad de mejorar la
implementacin real as:

En los Caso1 y Caso8, donde la solucin real implementada es

Transferencia de Archivos y la solucin ms recomendada por el mtodo

75

es la Mensajera, se encontr que el explotar las ventajas de la

comunicacin asncrona mejorara los tiempos de respuesta de la
aplicacin origen ya que es posible continuar el proceso sin tener una
respuesta de la aplicacin destino. En estos casos solo

es necesario

garantizar que el mensaje se entregue; al implementar la solucin ms

recomendada por el mtodo, se liberara a la aplicacin origen de la
responsabilidad de la entrega de los mensajes. Para el Caso1, el tamao
de la informacin del archivo serializado en promedio es de 3KB, lo cual
est conforme a la buena prctica recomendada, en la Fase I Etapa III,
para el tamao de los mensajes. Para el Caso8, el tamao del archivo, sin
serializarlo, excede el tamao recomendado del mensaje en la buena
prctica. Sin embargo en este caso teniendo en cuenta que la aplicacin
destino puede recibir parcialmente la informacin, se sugiere que la
implementacin se realice fraccionando el archivo en unidades ms
pequeas que adems de las mejoras ya mencionadas, incorpore las
ventajas del procesamiento distribuido.

En los Caso3 y Caso5, donde la solucin real implementada es

Invocacin Remota de Procedimientos, se encontr que implementar la

Mensajera, que es la solucin ms recomendada por el mtodo, le
permitira a la aplicacin origen continuar con el proceso mientras se
procesan los mensajes en la aplicacin destino; mejorando los tiempos de
respuesta de la aplicacin origen. Lo anterior tambin mejora la fiabilidad
de la integracin pues aunque las aplicaciones destino tienen como oferta
de servicio una disponibilidad de 7x24, se ha presentado inestabilidad en
los ltimos 4 meses. La solucin 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.

76

En los Caso4 y Caso6, donde la solucin real implementada es

Bases de datos compartidas y la solucin ms recomendada por el

mtodo es la mensajera, se encontr una oportunidad de mejora asociada
a la eficiencia de rendimiento. Las aplicaciones origen son aplicaciones de
misin crtica porque soportan los procesos de atencin al cliente. Estas
aplicaciones se ven afectadas en los tiempos de respuesta, normalmente
durante los primeros das del mes, porque en esos das 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.

77

5. CONCLUSIONES

Todos los elementos recopilados en la literatura en el desarrollo de la fase I

de la metodologa son los necesarios y suficientes para realizar la
categorizacin de los casos de negocio.

Los casos de negocio de integracin de aplicaciones tienen dos

necesidades bsicas: compartir datos y compartir funcionalidad.

Las soluciones conocidas para la necesidad compartir funcionalidad son:

mensajera e invocacin remota de procedimientos.

Las soluciones conocidas para la necesidad compartir datos son:

mensajera bases de datos compartidas y transferencia de archivos.

La solucin conocida mensajera es la ms recomendable y aplicable a

cualquier necesidad, la nica restriccin que tiene es que se tenga
disponible la seleccin de la tecnologa.

La solucin conocida bases de datos compartidas es aplicable a la

necesidad compartir datos, sin embargo tiene varias restricciones entre las
cuales se pueden resaltar: comunicacin sncrona y destino siempre
disponible.

La solucin conocida invocacin 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
seleccin de la tecnologa, se recomienda utilizar mensajera.

La solucin 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

78

embargo cuando se cuenta con la disponibilidad de la seleccin de la

tecnologa, se recomienda utilizar mensajera.

Las buenas prcticas asociadas a las soluciones conocidas permiten refinar

la solucin entregada por el mtodo, porque proporcionan las pautas
necesarias de lo que se debe tener en cuenta para realizar la
implementacin.

El mtodo diseado se define en seis pasos. Sin embargo la

caracterizacin del caso de negocio (paso1) y la aplicacin de los filtros
(paso2 y paso4) conforman los pasos fundamentales y decisivos en la
aplicacin del mtodo. Los dems pasos se obtiene como consecuencia
inmediata de la correcta aplicacin de estos tres (3) pasos.

En el anlisis cualitativo de las soluciones entregadas por el mtodo se

encontr que: en todos los casos la solucin real implementada coincide
con una de las soluciones recomendadas por el mtodo, en todos los casos
la solucin real implementada se encuentra entre las dos soluciones ms
recomendadas por el mtodo, en el cuarenta por ciento de los casos la
solucin real implementada es la solucin ms recomendada por el mtodo
y en el sesenta por ciento de los casos restantes, no se implement la
solucin ms recomendada , la mensajera, como solucin real debido a
que en el Grupo Empresarial Coomeva, contexto en el que se desarroll
este trabajo, la mensajera no haba sido evaluada como una solucin
viable para los problemas de integracin.

Al realizar el anlisis cualitativo detallado para los casos de negocio en los

que la solucin ms recomendada entregada por el mtodo no coincide con
la solucin real implementada, se encontr en todos los casos la posibilidad
de mejorar la implementacin real, con la solucin recomendada por el
mtodo.

79

6. RECOMENDACIONES Y TRABAJOS FUTUROS

En el alcance del proyecto y de la metodologa desarrollada en este trabajo, se

defini la evaluacin de la solucin entregada por el mtodo como un paso del
mtodo, paso 4,

que se enfoca en la aplicacin de tres filtros que permiten

realizar un anlisis cualitativo de la pertinencia de dicha solucin. Sin embargo y

teniendo en cuenta que cualquier propuesta que involucre la toma de decisiones
sobre el diseo de arquitectura y en este caso particular, sobre la integracin de
aplicaciones, debe realizarse con un anlisis detallado y formal para minimizar
riegos en las etapas posteriores del proceso de construccin de software; se
propone como trabajo futuro el desarrollo de una propuesta metodolgica que
permita realizar el anlisis y evaluacin detallada de las soluciones propuestas
entregadas por el mtodo y determinar si la solucin entregada es apropiada y
conforme a la caracterizacin del caso de negocio.

Como se ha mostrado en el desarrollo de este proyecto, el objetivo general es el

diseo de un mtodo que permita entregar un conjunto de recomendaciones para
la integracin de aplicaciones empresariales para un caso de negocio dado. Por lo
anterior, como trabajo futuro se presenta la implementacin del mtodo 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
implementacin de un cuestionario y de los filtros asociados a las preguntas, que
permitan realizar la correcta caracterizacin de los casos del caso de negocio
objeto del cuestionario. La implementacin de las bsquedas a las bases de datos
de los conjuntos de caractersticas, buenas prcticas y soluciones conocidas es
tambin requerida.

80

Otro trabajo futuro que se presenta es el enriquecimiento de los conjuntos de

variables para realizar la caracterizacin de los casos de negocio, los conjuntos de
buenas prcticas y los conjuntos de soluciones conocidas; con lo que se lograra
mantener actualizado el mtodo y por ende que permanezca vigente en el tiempo.
Adicional al anterior, se presenta un trabajo futuro que consiste en la exploracin
de otros mtodos derivados para otro tipo de aplicaciones, como las aplicaciones
en tiempo real; lo cual puede derivar en la prueba del mtodo en otros contextos
diferentes al empresarial y la bsqueda de nuevos conjuntos para realizar la
caracterizacin de los casos, nuevos conjuntos de buenas prcticas 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

mtodo, frente a variables no tcnicas tales como tiempo, costo y esfuerzo.

81

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. Visin general de la programacin orientada a aspectos.
Universidad de Sevilla, Facultad de informtica y estadstica, 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.

82

[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. 27
[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 GRNBACHER 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

83

[26] HOHPE, G, Enterprise Integration patterns, En conferencia de patrones de

lenguajes de programacin (PloP). (9: 8-12, Septiembre, 2002: Illinois usa). 2002.
[27] Conferencia sobre patrones de lenguajes de programacin, 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.

84