DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES

Transcripción

1 DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES VICTOR DANNEY GARCIA PLAZA MARIA TERESA LOPEZ DUEÑAS UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍAS MAESTRÍA EN INGENIERÍA DE SOFTWARE SANTIAGO DE CALI ENERO DE

2 DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES MARIA TERESA LOPEZ DUEÑAS VICTOR DANNEY GARCIA PLAZA DIEGO ARMANDO GOMEZ MOSQUERA Director de trabajo de grado UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍAS MAESTRÍA EN INGENIERÍA DE SOFTWARE SANTIAGO DE CALI ENERO DE

3 Nota de aceptación Presidente del Jurado Jurado Jurado Santiago de Cali, enero de

4 DEDICATORIA A Dios sobre todas las cosas, a mi familia por ser el motor que me impulsa a crecer cada día y a mis amigos quienes con su apoyo y consejos me ayudan a mantener firmes mis objetivos. MARIA TERESA LÓPEZ DUEÑAS A Dios, a mi pequeño Juan Pablo, a mi esposa Angélica, y a mis padres, por su gran amor y apoyo en cada una de las etapas de mi vida. VICTOR D. GARCIA PLAZA 4

5 AGRADECIMIENTOS A Dios a quien confío mis retos, a mi familia y amigos quienes con su cariño y respaldo me acompañaron en este proceso y a mi director de tesis y colegas quienes nos respaldaron, con sus valiosos conocimientos y aportes, para el logro de este objetivo. MARIA TERESA LÓPEZ DUEÑAS A Dios por darme la oportunidad de aprender, a mi familia por su enorme apoyo y a Diego A. Gómez, por su tiempo, dedicación e ideas que contribuyeron satisfactoriamente a la culminación de este trabajo de grado. VICTOR D. GARCIA PLAZA 5

6 TABLA DE CONTENIDO 1. PLANTEAMIENTO DEL PROBLEMA MARCO TEORICO METODOLOGÍA Fase I, denominada Recopilación Etapa I Etapa II Etapa III Fase II, denominada Diseño Etapa I Etapa II Etapa III Etapa IV Etapa V Fase III, denominada Aplicación Etapa I Etapa II RESULTADOS Fase I Recopilación de información Etapa I Determinar conjunto de variables Etapa II Determinar conjunto de soluciones conocidas Etapa III Determinar el conjunto de buenas prácticas Fase II Diseño del método Etapa I: Definición de categorías Etapa II: Soluciones conocidas aplicables por categoría Etapa III: Buenas prácticas aplicables por categoría Etapa IV: Definición de filtros Etapa V: El método diseñado Fase III Prueba del diseño del método

7 4.3.1 Etapa I: Refinamiento del método Etapa II: Aplicación del método diseñado CONCLUSIONES RECOMENDACIONES Y TRABAJOS FUTUROS

8 LISTA DE TABLAS Tabla 1 Ventajas y desventajas de los estilos de integración Tabla 2 Estilos de integración y los Frameworks que los implementan. Tabla 3 Buenas prácticas agrupadas por cada solución conocida. Tabla 4 Comparativo entre solución real y soluciones recomendadas. 8

9 LISTA DE FIGURAS Figura 1. Esquema de la metodología desarrollada. Figura 2. Transferencia de archivos. Figura 3. Bases de datos compartidas. Figura 4. Invocación a procedimientos remotos. Figura 5. Mensajería. Figura 6. Aplicaciones comunicadas usando mensajería. Figura 7. Comunicación basada en mensajería a través de un MOM. Figura 8. Transmisión de mensajes paso a paso. Figura 9. Categorización de Patrones de integración empresarial. Figura 10. Esquema del método diseñado. 9

10 LISTA DE ANEXOS Anexo 1: Resultados de la encuesta: Anexo 1.1 Encuesta. Anexo1.2 Necesidades de integración. Anexo 1.3 Criterios y restricciones para la integración. Anexo 1.4 Tipos de aplicaciones a integrar. Anexo 1.5 Características de calidad de la solución de integración. Anexo 1.6 Cuadro de tecnologías Anexo1.7 Caracterización de las empresas de los profesionales objeto de la encuesta Anexo 2: Combinación de variables: Anexo 2.1 Tipos de aplicaciones Anexo 2.2 Criterios y restricciones Anexo 2.3 Características de calidad Anexo 2.4 Criterios y restricciones tipo de aplicación origen Anexo 2.5 Criterios y restricciones tipo de aplicación destino Anexo 3: Aplicación del método diseñado Anexo 3.1: Soluciones conocidas criterios y restricciones Anexo 3.2: Criterios y restricciones refinado Anexo 3.3: Soluciones conocidas tipo de aplicación origen Anexo 3.4: Soluciones conocidas tipo de aplicación destino Anexo 3.5: Caracterización de los casos de negocio y soluciones 10

11 RESUMEN Cuando un constructor de aplicaciones empresariales se enfrenta a la integración de dos aplicaciones para un caso específico de negocio, se encuentra con un conjunto bastante amplio de estrategias, métodos y arquitecturas que pueden ser utilizados. Sin embargo, cuando debe elegir una opción de entre el conjunto de posibilidades, surgen las restricciones que están dadas por las características de las aplicaciones de su negocio y los requerimientos no funcionales del caso específico objeto de la integración; por lo que seleccionar la opción más adecuada resulta ser un problema no trivial de resolver. En este proyecto de investigación se diseñó un método que al ser usado por un constructor de aplicaciones empresariales, que se enfrenta a un caso de integración, le entrega una recomendación sobre las posibles opciones a usar; considerando las características de las aplicaciones a integrar y las restricciones presentes en su caso específico de negocio. Para diseñar este método se inició con la recolección y definición de las características de las aplicaciones y restricciones comunes presentes en las empresas de Santiago de Cali; así como el conjunto de métodos, estrategias, buenas prácticas, soluciones conocidas y otras reglas usadas para la integración de aplicaciones empresariales. Posteriormente se realizó el diseño del método a través de la identificación y definición de las categorías en las que se clasifican los casos de negocio y la identificación y definición del conjunto de buenas prácticas y soluciones conocidas aplicables a cada categoría. Con lo anterior se definió una serie de filtros que permitieron garantizar la correcta caracterización y categorización de los casos de negocio dados y por consiguiente cuales son las buenas prácticas y soluciones conocidas que le son aplicables. Finalmente se 11

12 probó el diseño del método a diez (10) casos de negocio reales y al mismo tiempo se hizo el refinamiento a través de la definición y validación de criterios que permitieron determinar la pertinencia del conjunto de recomendaciones entregado por el método diseñado, frente a la caracterización del caso de negocio. 12

13 INTRODUCCIÓN Cuando se piensa en una empresa, esta se ve como un sistema complejo que tiene un propósito u objetivo específico. Las aplicaciones empresariales intentan apoyar a la empresa en la consecución de estos objetivos [1]. Debido a esto, los constructores de aplicaciones empresariales se enfrentan al reto de implementar soluciones especializadas que deben procesar tareas específicas, enfocadas a un conjunto determinado de procesos y diseñadas a la medida de las necesidades del negocio; que a su vez deben integrarse con otras aplicaciones de negocio y/o sistemas legados que desempeñan otras tareas específicas. En la búsqueda de mecanismos u opciones para realizar la integración de aplicaciones, un constructor de aplicaciones empresariales, que se enfrenta a un caso de negocio, encuentra un amplio conjunto de soluciones que pueden ser en alguna medida aplicables al caso de integración. Seleccionar la mejor opción es una habilidad que resulta de la experiencia, pues en la actualidad no se cuenta con un método conocido que permita llegar a una mejor opción. En el presente proyecto de investigación se diseñó un método que al ser usado por un constructor de aplicaciones empresariales, que se enfrenta a un caso de negocio en el que deba realizar integración de aplicaciones, este le entregara una recomendación sobre las posibles opciones a usar; considerando las características propias de las aplicaciones y restricciones con las que trabaja. Para lo anterior se identificó un conjunto de características y restricciones que al ser agrupadas, permitieron definir las categorías en las que se pueden clasificar los casos de negocio; complementando lo anterior se definió cuáles son las buenas prácticas y soluciones conocidas que se pueden aplicar a cada categoría. De manera que una vez clasificado un caso de negocio en una categoría, se relacionan las buenas prácticas y soluciones conocidas que son aplicables. 13

14 En los capítulos siguientes se presentan el planteamiento del problema para el cual el método fue diseñado; el marco teórico en el que se ambientan, a través de los diferentes enfoques y autores, el problema y las aproximaciones que se le han dado a la integración de aplicaciones empresariales; Además se presenta, también, cada una de las fases y etapas de la metodología definida; los resultados hallados en cada fase de la metodología desarrollada; las conclusiones encontradas durante la realización del proyecto, las recomendaciones y trabajos futuros derivados de este proyecto. 14

15 1. PLANTEAMIENTO DEL PROBLEMA La integración de aplicaciones empresariales, por sus siglas en ingles EAI [16] (Enterprise Application Integration) es un término utilizado comercialmente para denominar los planes, métodos y herramientas utilizados para integrar y coordinar las aplicaciones en una empresa [1]. El constructor de aplicaciones empresariales en el proceso de análisis y diseño de integración de aplicaciones [3] para un caso específico de negocio, además de encontrarse con un conjunto genérico de posibles estrategias [16], arquitecturas y métodos de integración [4]; se encuentra también con un número importante de características propias de las aplicaciones de su negocio tales como: plataformas, lenguajes de programación, protocolos, motores de bases de datos, sistemas operativos y arquitecturas de aplicación [4] que le agregan complejidad a la elección de una opción de integración de aplicaciones. Ahora, si se piensa en que esa integración debe responder eficiente y efectivamente a las necesidades de los procesos de negocio, dadas en términos de los requerimientos no funcionales asociados a tiempos de respuesta e integridad de los datos, y que está condicionada por la tecnología, nivel de madurez y cultura propios del negocio; nos enfrentamos a un problema que no es trivial de resolver. El presente proyecto tiene como objetivo principal diseñar un método que entregue un conjunto de recomendaciones para realizar la integración de aplicaciones empresariales aplicables a un caso de negocio dado. Los objetivos específicos de este proyecto son: recopilar las diferentes estrategias, métodos y estilos de integración existentes para realizar la integración de aplicaciones empresariales; identificar las características más comunes a las aplicaciones presentes en las empresas; identificar los posibles valores que pueden tomar cada una de estas características; identificar las restricciones comunes presentes en las empresas; 15

16 identificar los posibles valores que pueden tomar cada una de estas restricciones; definir una taxonomía con la que se puedan clasificar, categorizar y/o tipificar los casos de negocio de aplicaciones empresariales; recopilar y seleccionar un conjunto de buenas prácticas de integración de aplicaciones, que apliquen a cada categoría; recopilar y seleccionar un conjunto de soluciones conocidas de integración de aplicaciones, que puedan aplicar a cada categoría; definir un conjunto de filtros, aplicables a la integración de aplicaciones, que permitan realizar la correcta caracterización de cada caso de negocio; probar y refinar el diseño del método aplicándolo a un conjunto de casos de negocio reales. 16

17 2. MARCO TEORICO En la actualidad es cada vez más común que las organizaciones usen paquetes de software para sus procesos de negocio principales, tales como Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Customer Relationship Management (CRM) y Electronic Commerce (EC). Estos les permiten a las empresas enfocarse en los sistemas de información (IS) que soportan su operación y metas financieras [12]. Sin embargo debido a la especialización de cada uno de estos paquetes de software, existen diferentes proveedores líderes que brindan soluciones específicas para cada una de estas necesidades; por lo tanto es muy común ver empresas que tienen al menos dos o más proveedores que satisfagan sus necesidades específicas en cada uno de sus procesos de negocio. Como resultado de la adquisición de estas herramientas o paquetes de software por parte de las empresas, y debido a los constantes cambios en los requerimientos del negocio para atender al mercado en el tiempo esperado, los cortos ciclos de vida de los productos y el aumento en la interdependencia con los socios de negocio [15], se hace entonces necesario que los procesos de negocio de las empresas deban amoldarse a dichos cambios para poder cubrir las necesidades de sus clientes, lo que implica que los sistemas que soportan estos procesos de negocio y sus interdependencias deban estar también cambiando. Por esto, es necesaria la interoperabilidad entre los distintos paquetes de software o aplicaciones de una empresa y además el intercambio de información con sus socios de negocio. Por lo tanto la integración de las aplicaciones y los procesos de negocio son una prioridad para las empresas en la actualidad [16]. No cabe duda que la integración entre aplicaciones sea una constante en el día a día de las grandes empresas, a tal punto que se encuentra involucrada incluso en los 17

18 paradigmas computacionales más actuales, como es el caso de la interoperabilidad de aplicaciones en la nube [14]. Esto evidencia que los procesos de integración seguirán siendo vigentes en el futuro de las empresas, por esta razón cada vez más las compañías buscan maneras para mejorar sus procesos de integración. Un ejemplo claro de esto se puede observar en la actualidad cuando se intentan mitigar los problemas de interoperabilidad entre los paquetes de software de una compañía, que como se ha hecho referencia en este mismo documento son normalmente heterogéneos, a través de la adquisición de software que provenga de un mismo proveedor, sin embargo, los resultados no han cumplido las expectativas y debido a eso muchas organizaciones están cambiando su estrategia a una que permita un rápido ensamble y desensamble de los procesos de negocio y de los correspondientes componentes de software [12]. Otra forma de resolver los problemas de integración, se da con la aparición de modelos de integración tal como el Modelo de Integración Empresarial (EMI) [15], que permite a través de un enfoque de meta-modelo orientado a objetos, la construcción de un lenguaje que describe un cierto dominio [15]. Además dicho modelo permite la reutilización de experiencias a través de la propuesta de patrones para el meta-modelo de integración [15]. Otra solución es el uso de un conjunto de patrones de integración empresariales, que son el resultado de años de trabajo por parte de expertos en la materia, con diferentes organizaciones en procesos de integración de aplicaciones empresariales [16, 20, 22]. Estos patrones brindan solución a un conjunto amplio de problemas de integración entre aplicaciones empresariales. Se debe tener en cuenta que las soluciones de integración son una tarea compleja, pues existe más de una solución posible, sin embargo saber si la solución definida es una buena opción, no se conocerá sino hasta muchos meses o aun años más tarde, cuando inevitablemente los cambios y la dinámica del negocio pongan a prueba la solución original [16]. 18

19 En la actualidad, la computación orientada a servicios aparece como un nuevo paradigma computacional fundamentado en buena parte en el paradigma orientado a objetos [6] y en la programación orientada a aspectos [7]. Se basa fundamentalmente en el concepto de servicio definido como un contenedor de capacidades que se compone de: un cuerpo de lógica que le permite llevar a cabo esas capacidades y un contrato que expresa cuales de estas capacidades están disponibles para ser usadas [21]. Uno de los elementos fundamentales en la computación orientada a servicios es la arquitectura orientada a servicios, SOA[21] por sus siglas en inglés, y dentro de SOA la integración tiene un lugar relevante, y es resaltada por Thomas Earl, como una parte importante, de alto perfil de la industria de las tecnologías de información [21]. Esto se debe a que prácticamente los servicios se construyen con la capacidad intrínseca de interactuar con múltiples consumidores y que prácticamente ninguno de ellos es conocido en el momento de su creación [21]. Con este concepto, SOA podría ser entonces la solución a los problemas de integración; sin embargo, esto es algo que solo se puede presentar cuando un porcentaje importante de los servicios de una organización está representado en un inventario de servicios de calidad [21]. Implementar SOA requiere tanto habilidades técnicas como habilidades organizacionales, lo que quiere decir que la implementación de SOA pasa las fronteras de lo técnico y comienza a ser un asunto organizacional [23]. Es por ello que el mismo Thomas Earl indica que mientras se trabaja hacia el logro de un inventario de servicios de calidad, es probable que existan muchos requisitos para la integración tradicional entre los sistemas heredados existentes, y también entre los sistemas heredados y sus servicios [21]. Los métodos desarrollados por los diferentes investigadores se enfocan como propuestas metodológicas que permiten evaluar la pertinencia o riesgos sobre las decisiones tomadas en el diseño de arquitecturas de aplicaciones. Ejemplo de ello es ATAM (Architecture Tradeoff Analysis Method), cuyo propósito es analizar un diseño de arquitectura y determinar si este diseño satisface los objetivos de calidad para los cuales fue 19

20 construido, determinando las posibles consecuencias o riesgos de esta decisión en función de los atributos de calidad definidos por los requisitos del sistema [8]. Otro ejemplo de un método para realizar el análisis de arquitecturas de software es SAAM (Software Architecture Analysis Method), evalúa las arquitecturas de software basándose en la adopción de escenarios como los medios mas descriptivos para especificar y evaluar los atributos de calidad, de esta manera SAAM plantea que los escenarios deben reflejar los tributos de calidad de interés y también mostrar la interacción entre las diferentes personas que utilizaran el sistema: usuarios finales, administrador, desarrolladores, etc. Cabe anotar que en este método, los escenarios son analizados desde tres perspectivas fundamentales: la perspectiva funcional, la perspectiva de estructura y la perspectiva de distribución o asignación [9]. Otros métodos de análisis de arquitecturas se enfocan en criterios específicos a evaluar, como la reutilización, o en la comparación de arquitecturas desarrolladas bajo diferentes paradigmas [10]. Sin embargo no se ha identificado métodos específicos que determinen un conjunto de pasos para encontrar posibles soluciones a un caso de integración de aplicaciones empresariales. Es aquí donde se fundamenta el objetivo del presente trabajo de investigación aplicada. 20

21 3. METODOLOGÍA La metodología definida para el desarrollo del proyecto se muestra en la Figura 1, se divide en tres (3) fases principales, a continuación se detalla las etapas y actividades de cada una de estas fases: Figura 1. Esquema de la metodología desarrollada. 3.1 Fase I, denominada Recopilación La fase de recopilación, como su nombre lo indica, esta fase se centra en la recopilación de información. Se divide en tres etapas, las actividades a realizar en cada etapa se detallan a continuación: 21

22 3.1.1 Etapa I Determinar el conjunto de variables con las que se puede caracterizar un caso de integración de aplicaciones Empresariales: En la cual el trabajo se orientará a la construcción de los siguientes entregables: Conjunto de estrategias, métodos y arquitecturas existentes para realizar la integración inter-aplicación de aplicaciones empresariales. Conjunto de las características más comunes a las aplicaciones presentes en las empresas con sus respectivos valores. Conjunto de las restricciones comunes presentes en las empresas con sus respectivos valores. En esta etapa se realizará la identificación de estos elementos en la literatura existente y se realiza la validación del uso de los mismos en el contexto de Santiago de Cali, a través de la elaboración de una encuesta Etapa II Determinar el conjunto de soluciones conocidas aplicables a un caso de integración de aplicaciones empresariales: el cual se realizará con la revisión de la literatura existente Etapa III Determinar el conjunto de buenas prácticas aplicables a un caso de integración de aplicaciones empresariales: para esta recopilación se hace uso de entrevistas con expertos y revisión de la literatura existente. 3.2 Fase II, denominada Diseño En esta fase el trabajo se centrará en el diseño del método, teniendo como insumos los entregables de la fase de Recopilación, Fase I; los entregables de esta fase son descritos en las siguientes etapas: 22

23 3.2.1 Etapa I Definición de categorías: Para esta actividad el entregable será la taxonomía en la que se puedan clasificar, categorizar o tipificar los casos de negocio de integración de aplicaciones empresariales Etapa II Definición de soluciones conocidas aplicables por categoría: Para esta actividad el entregable será el conjunto de soluciones conocidas aplicables a cada categoría definida en la Etapa I Etapa III Definición de buenas prácticas aplicables por categoría: Para esta actividad el entregable será el conjunto de buenas prácticas o reglas aplicables a cada categoría definida en la Etapa I Etapa IV Definición de Filtros: Para esta actividad el entregable será el conjunto de filtros y el orden en el que se deben aplicar en el proceso de caracterización, estos filtros se construyen para garantizar la coherencia de los valores de las variables con las que se caracteriza el caso de negocio, compatibilidad y complemento de las mismas, y con ello garantizar que la categoría en la que se clasificará el caso de negocio, objeto de la aplicación del método diseñado, sea correcta Etapa V Con la recopilación de las etapas anteriores se realizará la definición de los pasos del método. En esta fase las definiciones se realizarán teniendo como insumo principal la recopilación de la literatura y entrevistas con expertos realizada en la Fase I. 3.3 Fase III, denominada Aplicación En esta fase se pondrá a prueba el diseño del método definido en la fase de Diseño (Fase II). Y comprende las siguientes actividades: 23

24 3.3.1 Etapa I Definición de criterios para determinar la pertinencia de la(s) recomendación(es) entregada(s) por el método frente a la caracterización del caso de negocio Etapa II Aplicación y refinamiento del método diseñado. En esta fase se trabajará aplicando el método diseñado en la Fase II (Fase de diseño), a casos de integración de aplicaciones empresariales, que se han presentado en los proyectos de construcción de aplicaciones realizados en los dos últimos años en el Grupo Empresarial Coomeva. La pertinencia de las recomendaciones entregadas por el diseño del método será determinada por los criterios definidos en la Etapa I de esta fase. 24

25 4. RESULTADOS Conforme a lo establecido en la metodología definida para el desarrollo del proyecto, se llevaron a cabo las actividades de las tres (3) fases, los resultados de estas actividades se mostraran a continuación: 4.1 Fase I Recopilación de información La fase de recopilación de información consistió, como su nombre lo indica, en un proceso de recolección de información sobre la integración de aplicaciones empresariales, el cual se orientó en la elaboración de seis (6) conjuntos; cuatro (4) de los cuales representan el dominio de las entradas al método que se va a diseñar que corresponden a los conjuntos de variables con las cuales se puede caracterizar un caso de negocio. Y dos (2) más que son el engranaje fundamental del método y que corresponden al conjunto de soluciones conocidas y el conjunto de buenas prácticas respectivamente Etapa I Determinar conjunto de variables El propósito de esta etapa es determinar el conjunto de variables con las que se puede caracterizar un caso de integración de aplicaciones Empresariales: Estos elementos tienen la característica principal de influenciar la integración de aplicaciones empresariales y ser decisivos al momento de analizar un caso de integración de aplicaciones empresariales. Para la elaboración de estos cuatro (4) conjuntos fue necesario la ejecución de dos (2) actividades: La revisión de la literatura existente y la realización y análisis de resultados de la encuesta Revisión de la literatura existente Como se mencionó anteriormente, el propósito de esta revisión se orientó en la elaboración de cuatro (4) conjuntos que fueron identificados durante la revisión de la literatura, durante la cual se reconocieron dos textos principales [16, 18] y un 25

26 grupo de artículos [4, 5, 11, 12, 13, 14]; a partir de los cuales se logró establecer una serie de elementos que se agruparon como se muestra a continuación: Necesidades de integración La principal característica de este primer grupo es que reúne los elementos que motivan la integración de aplicaciones empresariales. En otras palabras, es el porqué y el para qué se integran las aplicaciones empresariales. Los elementos de este grupo se describen a continuación: Transferencia de archivos: El sistema necesitará producir archivos para compartir datos o necesitará consumir archivos que otros producen. Bases de datos compartidas: El sistema necesitará almacenar o extraer datos de una base de datos externa al sistema, que ha sido compartida a través de mecanismos propios del motor de base de datos. Invocación remota de procedimientos: El sistema necesitará exponer algunos de sus procedimientos para que sean invocados remotamente o deberá invocar procedimientos para dar inicio a un proceso e intercambiar datos. Mensajería: El sistema necesitará usar un Middleware de mensajería para el intercambio de datos o para inducir eventos en otros sistemas o subsistemas Criterios de Integración Este segundo grupo contiene los elementos que marcan los criterios a tener en cuenta en el momento en que son tomadas las decisiones de integración y las restricciones que se pueden presentar durante esta toma de decisiones: Intrusión: Cuando el enfoque por el menor impacto, es decir reducir al mínimo los cambios o la cantidad de código de integración no pueden proporcionar la mejor solución de integración en la empresa. 26

27 Selección de la tecnología: Cuando se requiere del uso de software y hardware especializado para llevar a cabo la solución de integración, pues el hecho de construir la solución desde cero, puede resultar en un mayor esfuerzo de lo previsto inicialmente y puede significar volver a hacer parcial o totalmente algo que ya existe, es decir reinventar la rueda. Formato de los datos: Se presenta cuando aparece alguno de estas situaciones: Utilizar un formato de datos común para la integración de las aplicaciones. Modificar la aplicación para usar un formato de datos común. Utilizar un traductor o mediador que homologue los formatos de los datos. Usar un formato de datos extensible en el tiempo. Latencia en el intercambio de datos: Se presenta cuando se requiere que: La información compartida entre aplicaciones debe estar disponible para el receptor tan pronto el emisor la haya generado totalmente, es decir que el receptor nunca recibirá parcialmente la información. La información compartida entre aplicaciones estará disponible desde el momento en que el emisor la esté generando, es decir el receptor podrá recibir la información a medida que esta se vaya generando por el emisor, esto implica el envió de información fragmentada y se hace compleja su sincronización. Datos o Funcionalidad: Se presenta cuando: La integración permitirá a las aplicaciones compartir solo datos. 27

28 La integración permitirá compartir funcionalidades en vez de simplemente datos. Comunicación Remota: Se presenta cuando se desea establecer comunicación con aplicaciones que no se encuentran en la misma instancia de sistema operativo de la aplicación que tiene la intención del llamado. En este caso la comunicación con las aplicaciones puede ser simplemente síncrona o asíncrona. Esta última implica mayor complejidad en el diseño, desarrollo y depuración. Confiabilidad: Se presenta cuando por ejemplo una solución de integración permitirá la comunicación asíncrona entre dos o mas aplicaciones, garantizando que en el momento que el emisor solicite una funcionalidad, esta se realizara cuando el receptor esté disponible Tipos de aplicaciones. El tercer grupo describe los tipos de aplicaciones empresariales, enfocándose en el manejo de los eventos y los tipos de datos que procesan. La clasificación adoptada para este grupo está definida en [31] y se seleccionó para el desarrollo de este trabajo de grado debido a que es la que más se aproxima al contexto empresarial en el que se va a trabajar el proyecto, tanto para la aplicación de la encuesta como para la caracterización y análisis de los casos de negocio además se ajusta a los tipos de escenarios cubiertos por los Frameworks de integración más comunes del mercado [30,31,33]. Batch: No procesan eventos. Transaccionales 1: Procesan eventos en la medida que ocurren. 28

29 Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. No manejan tipos de datos complejos. Transaccionales 2: Procesan eventos en la medida que ocurren. Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. Cliente servidor: Procesan eventos en la medida que ocurren. Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. Manejan tipos de datos complejos. Procesamiento importante en el cliente. Web: Manejan tipos de datos complejos. Procesamiento importante en el cliente. Procesan eventos en la medida que ocurren. Procesan eventos de los usuarios que se conectan vía interfaz de usuario. Deben estar disponibles. Manejan tipos de datos complejos. Sin procesamiento en el cliente. Tiempo Real: Procesan eventos en el instante que ocurren Paquetes de Software: Adquiridos y/o fabricados por terceros y proveen mecanismos de integración predefinidos desde el fabricante. 29

30 Características de calidad: En este cuarto grupo se consideraron las características de calidad, no para las aplicaciones a integrar; sino de la solución de integración. Para el desarrollo de este proyecto se seleccionó el marco de trabajo de las características de calidad de acuerdo con la norma ISO/EIC [2,19]. Esta selección se realizó teniendo en cuenta que es el marco con el que los investigadores han venido trabajando durante el proceso de formación profesional y es el marco con el que está más familiarizado el contexto empresarial en el que se va a aplicar la encuesta. Las características de calidad conforme al marco seleccionado se definen como sigue: Funcionalidad: Grado al cual un producto software provee las funciones que satisfacen las necesidades explícitas e implícitas cuando el software se utiliza bajo condiciones específicas Seguridad: La protección del sistema de accesos maliciosos o accidentales, uso, modificación, destrucción o divulgación. Capacidad de transferencia: Grado en el cual un producto software puede ser transferido de un ambiente a otro. Fiabilidad: Grado de un producto de software para mantener un nivel específico de funcionamiento cuando se está utilizando bajo condiciones especificadas. Capacidad de operación: Grado al cual un producto software puede ser entendido, aprendido, usado y atractivo al usuario, cuando es utilizado bajo las condiciones especificadas. Eficiencia de rendimiento: Grado al cual un producto software provee un rendimiento adecuado, de acuerdo con la cantidad de recursos utilizados y bajo las condiciones planteadas Compatibilidad: La capacidad de dos o más componentes software para el intercambio de información y/o para cumplir con sus funciones, Compartiendo el mismo hardware o el entorno de software. 30

31 Capacidad de mantenimiento: Grado en el cual un producto software puede ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptación del software a cambios en el entorno, y especificaciones de requisitos y funcionalidades Encuesta Una vez revisada la literatura existente y luego de recopilar y agrupar los diferentes elementos ahí presentados; se procedió a trabajar con la segunda herramienta, que consistió en la elaboración y análisis de resultados de una encuesta realizada a veintiuno (21) voluntarios que trabajan o han trabajado en proyectos de integración de aplicaciones empresariales. Los objetivos de esta encuesta fueron: Someter a calificación (entre 1 y 5) cada uno de los elementos recopilados, en la revisión de la literatura, de acuerdo al nivel influencia de estos elementos en la integración de aplicaciones empresariales. Recolectar información sobre los métodos que se emplean actualmente. Identificar las tecnologías en las que están construidas las aplicaciones empresariales con las que se trabajan en proyectos de integración en las empresas de Santiago de Cali. Los resultados obtenidos para cada uno de los objetivos de la encuesta se muestran a continuación: Todos los elementos recopilados en la literatura, fueron calificados con algún grado de influencia y todos se usan con mayor a menor frecuencia dentro de los proyectos que han realizado los encuestados. Por lo tanto todos los elementos recopilados en la literatura van a ser utilizados como entradas al método para realizar la caracterización de los casos de negocio. No aparecieron nuevos elementos, necesidades, criterios, restricciones, características de calidad y de las aplicaciones, a incluir en el conjunto de elementos ya recopilados. 31

32 Solo uno de los encuestados respondió afirmativamente a la pregunta de si conocía un método que le permitiera identificar la mejor opción de integración dentro de un grupo de casos de integración de aplicaciones empresariales. Sin embargo el método descrito por el encuestado es más una descripción de un conjunto de actividades en orden lógico usado a nivel personal para resolver casos de integración; que un método formalmente descrito y referenciado. Se logró identificar las tecnologías en las que están construidas las aplicaciones empresariales (bases de datos, lenguajes de programación y sistemas operativos) en las que han trabajado los encuestados y se identificó que corresponde a un conjunto amplio de distintas tecnologías y fabricantes; incluso dentro de una misma empresa. Estos resultados se presentan de manera gráfica y detallada en el Anexo 1 Resultados de la encuesta Etapa II Determinar conjunto de soluciones conocidas El resultado del trabajo realizado en esta etapa de la metodología, básicamente se resume en el uso de los estilos de integración definidos en [16] como soluciones conocidas, dado que en la actualidad son las más utilizadas dentro de la bibliografía sobre la que se basa este documento. A continuación se profundiza sobre cada uno de estos estilos: Transferencia de archivos Figura 2. Transferencia de archivos [16]. 32

33 Esta solución se basa en el estilo de integración que lleva su mismo nombre (File Transfer) [16]. Cuando se usa la transferencia de archivos como solución a un problema de integración, una aplicación simplemente escribe los datos que desea compartir con otras aplicaciones dentro de un archivo, en un sistema de archivos, desde donde otras aplicaciones puedan leerlo y procesarlo. En este punto los encargados de los proceso de integración tienen la responsabilidad de transformar los archivos en diferentes formatos en caso que las aplicaciones destino así lo requieran. Como también de identificar los intervalos de producción de dichos archivos de acuerdo a la naturaleza del negocio. Recomendación: En caso que sea necesario tener la información con una periodicidad mayor a la que la aplicación productora puede generar, o en el caso que sea necesario realizar más transformaciones para realizar la integración con nuevos sistemas, se recomienda usar una solución con estilo de bases de datos compartidas. O en el caso que los periodos de frecuencia hayan disminuido y esto redunde en intercambios de información muy pequeños comparados con los identificados en el diseño de la solución original, se recomienda el uso del estilo de mensajería Bases de datos compartidas Figura 3. Bases de datos compartidas [16]. 33

34 Las bases de datos compartidas, al igual que la solución de transferencia de archivos, se basa en un estilo de integración, en este caso se basa en el estilo de integración de base de datos compartida (Shared Database) [16]. Cuando se utiliza este estilo como solución a un problema de integración, se usa una base de datos la cual es compartida por todas las aplicaciones que participaran en la solución, de esta manera todas las aplicaciones que comparten su información tienen la posibilidad de ver la información más actualizada y sin inconsistencias, a diferencia de la solución de trasferencia de archivos. Sin embargo para lograr esto, se requiere de un trabajo extenso, por parte de los integradores, los responsables de las aplicaciones y el administrador de la base de datos, pues deberá diseñarse el esquema de base de datos que satisfaga las necesidades de cada una de las aplicaciones involucradas y lo mantenga consistente, además de las políticas que limitaran el rango de acción y visibilidad a cada aplicación, a solo lo necesario, de tal manera que se disminuya el riesgo de deadlocks y por ende cuellos de botella que generen problemas de acceso o hasta la falta de disponibilidad del servicio. Recomendación: En caso que sea necesario integrar la funcionalidad y ya no los datos, se sugiere el uso del estilo de integración de procedimientos almacenados, o en caso que las aplicaciones deseen intercambiar información en pequeñas cantidades de datos, entre ellas y ya no a través de un esquema universal, se sugiere el uso del estilo de integración de mensajería. 34

35 Invocación remota de procedimientos Figura 4. Invocación remota de procedimientos [16]. En esta solución, al contrario del estilo de integración de bases de datos compartidas, no son los datos, si no la funcionalidad la que se comparte con las demás aplicaciones. Esto se logra a través del llamado de los métodos de las aplicaciones remotas, los cuales previamente han sido publicados por la aplicación remota y son accesibles por las aplicaciones cliente. Este tipo de soluciones, lucen muy agradables para los desarrolladores, debido a que esta permite llamar los métodos de aplicaciones externas, de la misma manera como se hace con los métodos locales. Sin embargo esto puede generar inconvenientes, pues al invocar un método remoto, este no se comporta de la misma manera que uno local y por esta razón pueden generarse errores inesperados. Estos pueden deberse a fallas en la red, lo cual evita que el método pueda ser invocado, o que la aplicación propietaria del método remoto no se encuentra disponible en este momento. Finalmente otro aspecto a tener en cuenta en esta solución es la modificación de dichos métodos, pues mientras no se alteren las firmas de dichos métodos no habrán problemas, pero en caso de necesitarlo, es necesario informar a los administradores de las aplicaciones clientes, quienes deben hacer los cambios necesarios para que las invocaciones 35

36 tengan en cuenta dichas modificaciones, pues de lo contrario se producirá un error al intentar llamar el método con los parámetros equivocados. Recomendación: En caso que se necesitara hacer llamados asíncronos a las aplicaciones, y/o de buscar un menor acoplamiento entre las aplicaciones a integrar, se sugiere el uso de mensajería como solución a estos nuevos requerimientos de integración Mensajería Figura 5. Mensajería [16]. La mensajería es una tecnología que permite a dos aplicaciones su comunicación de manera confiable, asíncrona y con alto rendimiento. Al utilizar esta tecnóloga las aplicaciones se comunican a través de canales enviándose paquetes de datos denominados mensajes, como se muestra en la Figura 5. Un canal funciona como una colección de mensajes que puede ser compartido por múltiples aplicaciones y utilizado concurrentemente. Las aplicaciones actúan con roles bien definidos en la comunicación: productor y consumidor. Un productor (o emisor) es una aplicación que envía mensajes escribiéndolos en un canal, mientras que un consumidor (o receptor) es una aplicación que recibe los mensajes leyéndolos del canal. En un esquema de este tipo tanto productor como consumidor no tienen que estar necesariamente disponibles al mismo tiempo para poder comunicarse. Esto se debe a que la comunicación en sí misma es llevada a cabo a través de los 36

37 denominados sistemas de mensajería. Figura 6. Aplicaciones comunicadas usando mensajería. Sistemas de mensajería Las capacidades de mensajería son típicamente provistas por sistemas de software denominados sistema de mensajería o Message Oriented Middleware (MOM). Los MOMs son componentes especializados en el manejo de mensajes. Su fin principal es participar como intermediario entre la comunicación de aplicaciones, logrando desacoplarlas. Las aplicaciones se comunican con los sistemas de mensajería a través de clientes provistos por los proveedores de MOMs. Estos brindan interfaces mediante las cuales las aplicaciones pueden enviar y recibir mensajes como se ilustra en la Figura 7. Figura 7. Comunicación basada en mensajería a través de un MOM. 37

38 Debido a que tanto los equipos como las redes que los conectan no son cien por ciento seguros y confiables, hace relevante la existencia de los MOMs. Por ejemplo, puede que no siempre que se envíe un mensaje el destinatario esté activo y disponible, o en caso de que lo esté, podría ser que la red de comunicación presente no disponibilidad. Previo a la aparición de los MOMs, para atacar este tipo de problemática se implementaba manualmente la retransmisión de mensajes hasta asegurarse que el receptor los había procesado. Esto hacía que cada vez que se deseaba usar mensajería se debieran afrontar una y otra vez los mismos problemas. Como respuesta a esto, surgen los sistemas de mensajería, que permiten a quien envía un mensaje olvidarse del mismo luego del envío, delegando al sistema de mensajería la responsabilidad de asegurar la entrega del mensaje a su destinatario. A continuación se enumeran los componentes de un sistema de mensajería así como su responsabilidad según [16]: Canales: Son direcciones lógicas en el sistema de mensajería a las cuales las aplicaciones hacen referencia, y es donde colocan los mensajes para ser entregados. Mensajes: Son las entidades que transporta el sistema de mensajería. Puntos de acceso (endpoints): Es el punto de entrada al sistema de mensajería. Para poder acceder a un canal, las aplicaciones tienen que conectarse al sistema de mensajería, y dicha conexión se da a través de un endpoint. Tubos y filtros (pipes and filters): Son los componentes encargados de procesar mensajes complejos en varios pasos de forma flexible. Enrutador de mensajes (message router): Cuando un mensaje debe ser procesado pasando por varios destinos, o tiene que seguir cierta ruta óptima, los enrutadores de mensajes se encargan de tal problemática independizando a las aplicaciones de este manejo. 38

39 Componentes de transformación de mensajes: Estos componentes son filtros particulares que se encargan de realizar transformaciones para poder comunicar aplicaciones que utilizan formatos de mensaje diferentes. Proceso de transmisión: El proceso de transmisión de los mensajes es el proceso más relevante para un sistema de mensajería y este se descompone en cinco pasos: Crear: El emisor crea un mensaje y coloca en el los datos que desea transmitir. Enviar: El emisor coloca el mensaje en un canal. Entregar: El sistema de mensajería transporta el mensaje logrando que este esté disponible para el receptor. Recibir: El receptor lee el mensaje desde el canal. Procesar: El receptor extrae los datos del mensaje. Figura 8. Transmisión de mensajes paso a paso [16]. En la Figura 8, se muestran los pasos descritos anteriormente, además se puede apreciar la aplicación de los conceptos: Send and Forget y Store and Forward. Estos se dan en los pasos 2 y 3 respectivamente. Observando el paso 2, se puede ver que una vez que la aplicación entrega el mensaje en el canal, puede seguir 39

40 ejecutando dado que esta delegó la entrega del mensaje al sistema de mensajería. La aplicación confiará en que el receptor recibirá el mensaje, y no esperará hasta que esto ocurra. En el paso 2, en el momento que la aplicación entrega el mensaje en el canal, el sistema de mensajería lo almacena. Luego en el paso 3, el sistema de mensajería entrega el mensaje redirigiéndolo a la computadora destinataria en la que es nuevamente almacenado. Este proceso puede ser repetido varias veces hasta que el mensaje se persista en la máquina destino. Modelos de comunicación: generalmente los sistemas de mensajería soportan alguno de estos modelos de comunicación: Point-to-Point: Este modelo es basado en canales punto a punto. Cuando una aplicación produce un mensaje, lo coloca en un canal de este tipo y un receptor recibirá el mensaje. A este tipo de canales se pueden suscribir varios interesados en recibir mensajes, pero sólo uno obtendrá cada mensaje. El sistema de mensajería se encargara de determinar cuál de los destinatarios subscritos obtendrá el mensaje. Publish-Subscribe: Este modelo permite que una aplicación varios destinatarios simultáneamente. Para esto, las aplicaciones colocan los mensajes en un canal que corresponde a cierto tópico definido, el cual tiene el siguiente comportamiento: los interesados en recibir mensajes del tópico se suscriben al mismo, el emisor coloca el mensaje en el canal, y una copia del mismo será entregada a cada uno de los subscritos al mismo. Características y servicios de un MOM: en general, los MOMs brindan varias de las características y servicios que se describen a continuación: Garantía de Entrega de mensajes: dos aplicaciones que se están comunicando mediante un MOM no necesitan estar conectadas 40

41 simultáneamente para que el envío de los mensajes sea exitoso. El MOM asegura que los mensajes enviados a un destinatario que no esté conectado, serán entregados al mismo cuando este vuelva a estarlo. Comunicación Asíncrona: luego que una aplicación envía un mensaje a otra, el MOM permite que la aplicación cliente siga trabajando sin tener que esperar que el mensaje sea procesado por el destinatario del mismo. Soporte transaccional: el uso de transacciones es soportado, y además en general se proveen mecanismos de integración con otros recursos, de forma que las transacciones contra el MOM se puedan incorporar a transacciones globales. Entrega en orden, y una sola vez: un MOM garantiza que los mensajes serán entregados una sola vez, y que además los mismos serán entregados respetando el orden en que fueron enviados. Servicios de ruteo de mensajes: permiten definir reglas de ruteo a nivel de configuración mediante las cuales al enviar un mensaje a un determinado canal, los mismos son enrutados según las configuraciones indicadas. Servicios de notificación: en algunos casos las aplicaciones que envían los mensajes necesitan tener una forma de saber si el mensaje enviado ya fue procesado por el consumidor u obtener el resultado generado en este. Para esto, los MOM s proveen mecanismos de notificación, de forma que al ser procesado el mensaje por su receptor se pueda entregar el resultado de este procesamiento al productor del mismo. Después de conocer los conceptos básicos y los elementos que componen un sistema de mensajería, se procederá a la explicación de los patrones de integración empresarial y su categorización. 41

42 Los patrones de integración empresarial fueron descritos por primera vez en la conferencia de Patrones de Lenguaje de Programación [27], en el año 2002 por Gregor Hohpe [26]. Dichos patrones, son una evolución de los patrones de diseño de software tradicionales, a un contexto especifico, como lo es la integración de aplicaciones empresariales. Estos patrones representan las decisiones que deberán tomarse al momento de integrar dos o más aplicaciones en un contexto empresarial y las consideraciones que implica tomar esas decisiones. En la actualidad, se consideran 65 patrones de integración empresarial [16], cuyo planteamiento se basa en la mensajería asíncrona como piedra angular para la integración. A continuación se describen las categorías que componen estos patrones y que parte del problema de comunicación dentro de la mensajería solucionan Categorización de Patrones de Integración Empresarial Los patrones de integración empresarial han sido agrupados en seis (6) categorías [16], como se muestra en la Figura 9, las cuales reflejan el alcance (scope) y la abstracción de los patrones. Resolviendo de esta manera una situación específica dentro del proceso de integración. 42

43 Figura 9. Categorización de Patrones de integración empresarial [16]. Patrones de canal del mensaje Estos patrones describen los aspectos que deben ser tenidos en cuenta a la hora de escoger el canal de comunicación entre las aplicaciones, cuando se desea integrar dos o más sistemas de software. Por lo tanto estos patrones resuelven distintos problemas de transporte de los mensajes entre aplicaciones. Por ejemplo, las aplicaciones que envían información por un canal no tienen por qué conocer cuál es el receptor final de los datos que produce, sin embargo seleccionando un canal en particular el productor puede asegurarse que quien reciba la información es quien la esperaba. Apuntan a especificar características de los canales de comunicación a utilizar, como por ejemplo: si el mensaje es enviado a uno o a muchos receptores, garantía de entrega de los mensajes que se transportan por el canal, expiración de los mensajes enviados al canal, entre otros. Los patrones que integran la categoría son: 43

44 Point-to-Point Channel. Publish-Subscribe Channel. Datatype Channel. Invalid Message Channel. Dead Letter Channel. Guaranteed Delivery. Channel Adapter. Messaging Bridge. Message Bus. Patrones de construcción del mensaje Estos patrones, contemplan los aspectos que se encargan de envolver los datos de interés en un mensaje, para que pueda ser transmitido a través de los canales, que llevaran la información hacia los interesados en el mensaje. De esta manera abordan el diseño de los mensajes que envían los diferentes participantes de una comunicación. Por ejemplo, en el intercambio que se realiza entre dos aplicaciones, la información se envía insertándola en un mensaje. Apuntan a especificar la información que contienen los mensajes, su semántica, información adicional para permitir su procesamiento adecuado, entre otros. Los patrones que integran esta categoría son: Command Message. Document Message. Event Message. Request-Reply. Return Address. Correlation Identifier. Message Sequence. 44

45 Message Expiration. Format Indicator. Patrones de enrutamiento del mensaje Estos patrones, describen las distintas soluciones para proveer enrutamiento e intermediación para una solución de integración. Dichos patrones están relacionados con el ruteo de los mensajes desde una aplicación a otra. Por ejemplo, permiten desacoplar los componentes que realizan en conjunto el procesamiento en etapas de determinada información, logrando que la secuencia de pasos a realizar dependa de un conjunto de condiciones. Apuntan a la configuración de rutas por las que deben pasar los mensajes para su procesamiento, independizando a quien envía o recibe los mensajes de esta lógica. Cabe anotar que muchos de los patrones agrupados en esta categoría son refinamientos o combinaciones del patrón Message Router [16]. Los patrones que componen esta categoría son: Content-Based Router. Message Filter. Dynamic Router. Recipient List. Splitter. Aggregator. Resequencer. Composed Message Processor. Scatter-Gather. Routing Slip. Process Manager. Message Broker. 45

46 Patrones de transformación del mensaje Estos patrones, identifican y dan solución a las diferentes situaciones que generalmente se presentan cuando se tiene la necesidad de operar entre sistemas que usan diferentes formatos, por lo tanto estos patrones permiten definir el manejo de transformaciones que pueden realizarse sobre los mensajes que se intercambian, en lo que refiere a los diferentes formatos requeridos por cada aplicación. Así como también modificaciones automáticas que se realizan sobre los mensajes. Los patrones que integran esta categoría son: Message Translator. Envelope Wrapper. Content Enricher. Content Filter. Claim Check. Normalizer. Canonical Data Model. Patrones de puntos de acceso (EndPoint) Estos patrones, describen cómo las aplicaciones involucradas en la integración, pueden conectarse al sistema de mensajería, para que puedan enviar y recibir mensajes. Es decir estos patrones entregan pautas relacionadas a la generación y el consumo de mensajes, especificando por ejemplo como un productor puede interactuar con el canal para producir un mensaje o como un receptor puede comportarse ante la ocurrencia de un nuevo mensaje. Los patrones que integran la categoría son: Message Endpoint. Messaging Gateway. Messaging Mapper. Transactional Client. 46

47 Polling Consumer. Event-Driven Consumer. Competing Consumers. Message Dispatcher. Selective Consumer. Durable Subscriber. Idempotent Receiver. Service Activator. Patrones de gestión del sistema Indican cómo atacar las necesidades de administración, monitoreo y testeo de los componentes del sistema y de los canales de comunicación. Un claro ejemplo de esto es la necesidad de extraer información sobre los datos que circulan por los canales, con el fin de monitorear cual es la capacidad de procesamiento del sistema en general y poder así detectar caídas en el rendimiento. Los patrones que integran la categoría son: Control Bus. Detour. Wire Tap. Message History. Message Store. Smart Proxy. Test Message. Channel Purger. La solución de mensajería, está asociada al estilo de integración empresarial de mensajería (Messaging) [16]. Cuando este estilo es usado como solución a un problema de integración, es necesario una infraestructura de mensajería, que 47

48 además de proveer el canal de comunicación entre la aplicación emisor y destino involucradas en la integración, provea los mecanismos de reintentos necesarios para que los mensajes enviados entre las aplicaciones, sean entregados y no se pierdan, además en caso que la aplicación receptor no se encuentre disponible, la infraestructura deberá estar en la capacidad de almacenar los mensajes enviados en un datastore, y entregarlos a su receptor cuando este se encuentre de nuevo disponible. Claramente se observa que este tipo de soluciones, están soportadas por infraestructuras que promueven la fiabilidad de la comunicación, además de un esquema de comunicación asíncrona entre las aplicaciones involucradas en el proceso de integración, lo que a su vez permite que las soluciones de integración puedan cada vez mas tener un comportamiento más parecido a la naturaleza de los negocios, pues es posible modelar los eventos de negocio necesarios para la ejecución de los procesos internos y la de aquellos que requieran de la comunicación de otras aplicaciones con las que se desea integrar. Recomendación: Después de tomar la decisión que la solución escogida será el estilo de integración de mensajería, se sugiere tener en cuenta, estas mínimas consideraciones: Debe definirse un canal o Message Channel, el cual se utilizara como medio de comunicación del mensaje. A donde deben ser enviados los mensajes. Qué tipo de formato utilizar para el mensaje. Implementar un traductor para desacoplar las aplicaciones a integrar. Conectar las aplicaciones a la infraestructura de mensajería por medio de un Message Endpoint. 48

49 La búsqueda de las soluciones conocidas permitió refinar las variables de entrada al método definidas en el grupo de necesidades encontrando que mas que necesidades estos cuatro (4) estilos de integración son soluciones y básicamente las necesidades se pueden clasificar como: compartir datos y compartir funcionalidad Etapa III Determinar el conjunto de buenas prácticas El objetivo de la etapa es determinar el conjunto de buenas prácticas aplicables a la integración de aplicaciones empresariales, basado en la recopilación a través de la consulta directa a un grupo de expertos y recopilación de información en la literatura existente. El resultado del trabajo realizado se detalla a continuación Consulta a expertos La selección de los miembros de este grupo se realizó fundamentalmente porque son personas con una trayectoria que supera los 5 años en la construcción de importantes proyectos de integración de aplicaciones empresariales, definición de estándares y mecanismos de integración de las aplicaciones del core de los negocios para las empresas en que ellos trabajan. Al consultar las buenas prácticas, que estos expertos aplican en su trabajo diario, se observó que las respuestas se enfocaban a cada una de las necesidades de integración que se identificaron en la caracterización de los casos de negocio. En la mayoría de los casos los expertos resaltaron los pros y los contras de la buena práctica. Por lo anterior la descripción de estas buenas prácticas, se hace agrupada por cada una de las necesidades de integración y se identifican las ventajas y desventajas de utilizarla: 49

50 Datos Para la necesidad de integración compartir datos, las buenas prácticas, entregadas por el grupo de expertos, se resume a continuación: Uso de formato: por estándar, a nivel mundial el formato de los archivos para hacer integración debe ser XML. Las ventajas están en la facilidad para realizar las validaciones de los datos a través del uso de XSD o DTD, en la facilidad que tienen para ser leídas por parte de los humanos y rapidez con la que son validados por las maquinas. La desventaja está en el tamaño de los archivos, los archivos en formato XML siempre son de mayor tamaño que los archivos de otros formatos; esto se debe a que la meta-data está inmersa en los archivos. Generación de archivos: la recomendación entregada en este sentido es que los archivos deben ser generados por los sistemas dueños de los datos, en lugar que la aplicación destino o una tercera aplicación, genere el archivo ingresando a los datos de la aplicación origen. Transporte: para este propósito existen en el mercado herramientas que utilizan como medio de transporte protocolos especializados como son: FTP, SFTP o SCP. El uso de buses de servicios no se recomienda para realizar el transporte de archivos. Bases de datos: Como buenas prácticas en el caso cuando existe la misma entidad de base de datos en ambos sistema se recomienda: Realizar sincronización con replicación. Definir las políticas de sincronización como por ejemplo la periodicidad. Utilizar en lo posible los tipos de datos nativos del motor de base de datos. 50

51 Definir un buen gobierno de datos. Quien es el dueño de los datos. Si están en la misma instancia se debe usar sincronización en línea ya que no es necesario hacer uso de la red de datos. La práctica más usada y recomendada por los expertos es utilizar gatillos, también conocidos por la palabra en inglés trigers, siempre y cuando se tengan bien establecidos los accesos y permisos sobre las tablas. Si están diferente instancias se recomienda crear una tabla temporal de trabajo, para posteriormente, a través de un proceso asíncrono, realizar la integración Funcionalidades Para la necesidad de integración compartir funcionalidad, las buenas prácticas, entregadas por el grupo de expertos, se resume a continuación: Mecanismo de exposición: para realizar la exposición de funcionalidades el estándar adoptado por la industria son los servicios web usando SOAP o Restful. Consulta de información: Los servicios web son muy útiles para consumir lógica de negocio de otras aplicaciones, sin embargo si los servicios retornan bloques de datos mayores de 5MB, los servicios web no son recomendados. Para retornar bloques de resultados de más de 5MB es mejor usar protocolos binarios tales como RMI-IIOP, DCOM o RPC. Llamado a procedimientos: es el mecanismo recomendado para realizar la invocación de funcionalidades de forma síncrona. 51

52 Datos y funcionalidades El grupo de expertos entregó un conjunto de buenas prácticas aplicables a las necesidades compartir datos y compartir funcionalidad, las cuales se describen a continuación: Los sistemas de mensajería entre aplicaciones Message Oriented Middleware son el mejor mecanismo asíncrono de integración en las aplicaciones empresariales. El principal problema de este mecanismo es que los protocolos no son abiertos y cada proveedor tiene su mecanismo propietario de integración. Formato de los mensajes: Si la integración es entre sistemas que tienen el soporte nativo para el MOM lo mejor es usar mensajes binarios y no mensajes en modo texto. Si la integración es entre sistemas que no tiene soporte nativo para MOM, se deben usar mensajes de texto en formato XML o JSON. Mecanismo de entrega de los mensajes: para entrega del mismo mensaje desde una aplicación hacia diferentes aplicaciones se debe usar Publish and Subscribe. Para la entrega de mensajes solo entre dos aplicaciones, no se conoce en el mediano plazo la inclusión de otras aplicaciones interesadas en consumir este mensaje, se debe usar Point to Point Buenas prácticas extraídas de la literatura En la revisión de la literatura se encontraron las siguientes buenas prácticas o recomendaciones para cada una de los estilos de integración: Buenas prácticas para la transferencia de archivos La transferencia de archivos, ha sido una de las tecnologías comúnmente más utilizadas en el mundo, por las empresas de TI para intercambiar información [29], 52

53 Sin embargo la complejidad de los negocios y la necesidad continua de tener respuestas con tiempos cada vez más ajustados a las necesidades reales, han desplazado a los antiguos procesos en batch, que comúnmente se ejecutan fuera de línea y normalmente son concebidos para procesar grandes volúmenes de información [30], debido a su naturaleza desatendida. Todo lo anterior unido a la aparición de las herramientas de EAI [16], como respuesta a las necesidades cada vez mas crecientes de integrar las aplicaciones de una o múltiples negocios, generaron el surgimiento de tecnologías tales como la mensajería, que permitió una comunicación con solicitudes y operaciones más granulares que las que se alcanzaban con los procedimientos anteriores [29]. Sin embargo, la existencia de sistemas legados de misión crítica, en las empresas actuales, renovaron el enfoque de la transferencia de archivos, y le ha permitido mantenerse como un elemento fundamental dentro de las herramientas de EAI [29], debido a que su uso puede ser estratégico para: Reducir los riesgos del negocio. Entregar un nivel de retorno (RoI) atractivo. Mayor velocidad de entrega para nuevas implementaciones y/o servicios. Permitir rápidamente la intercomunicación con los sistemas de otras empresas (B2B). A continuación se describen cinco (5) buenas prácticas para la implementación de este estilo de integración: Confirmar la transmisión de los archivos: todos aquellos que están involucrados en la transferencia de uno o varios archivos generalmente desean saber si estos han arribado satisfactoriamente a su destino final, por esta razón una confirmación explicita es bastante útil para saber si el o los 53

54 archivos han sido recibidos correctamente [32]. Para esto se puede generar un mensaje de retroalimentación al cliente a través de: Colocando un archivo con la información de confirmación en un FTP del emisor. Enviando un correo electrónico. Haciendo una invocación a un servicio web, informando la confirmación. Colocando un mensaje en una cola. Almacenando el registro en una tabla de base de datos. Fallas en la transmisión y avisos: cuando la transferencia de un archivo falla, puede deberse a causas muy comunes como son [32]: Problemas de red. El servidor con el que se tiene la conexión no se encuentra disponible. No es posible autenticarse al servidor. La ruta del archivo, no se encuentra disponible. No hay permisos suficientes para acceder al archivo. Una buena práctica en este caso es la de las soft fail [32], que consisten en el reintento de la operación sin intervención humana, en un período de una hora, sin embargo después de cinco (5) soft fail seguidas, deberá generarse una hard fail que de inmediato generara una notificación al personal encargado de los servidores de archivos, tanto los de recepción como los de emisión de los archivos. Verificación de falla de archivos: aún después de transferir el archivo satisfactoriamente, es posible que dicho archivo no tenga el formato esperado, o que el archivo esté corrupto. En este escenario las soft fail y 54

55 las hard fail no son útiles, y por ende se sugiere seguir las siguientes buenas prácticas: Verificar los archivos después de recibidos, por parte del receptor. Verificar los archivos de gran tamaño, antes de transmitirlos, por parte del emisor. Enviar notificación a los encargados de recibir el archivo y al receptor en caso que la verificación falle en cualquiera de los casos anteriormente descritos. Mejor protocolo: a menudo se presentan ciertas restricciones sobre los protocolos que podrán ser usado para la transferencia de los archivos, sin embargo cuando dicha restricción no exista y se pueda escoger SFTP (SSH File Protocol) [32], se recomienda este protocolo debido a que es ampliamente usado, soportado y bien conocido por un gran número de comunidades en Internet, además de su seguridad. Usar fechas, horas y minutos en la convención de nombramiento de archivos: generalmente nuevos archivos son generados diariamente y en algunos casos son generados son generados cada hora, en este caso para evitar confusión y para prevenir que los viejos archivos sean sobre escritos con los últimos datos, por esta razón el uso de fechas, hora y minutos en los nombres de los archivos permiten alcanzar esta meta [32]. Finalmente siguiendo estas buenas prácticas, pueden ser construidos ambientes robustos para la transferiría de archivos dentro de una organización o entre sus proveedores o clientes (B2B). 55

56 Buenas prácticas para bases de datos compartidas Cuando se requiere que varias aplicaciones, almacenen los datos que quieren compartir en una base de datos en común, es necesario dar acceso a la base de datos a cada una de las aplicaciones involucradas, sin embargo esto no es un enfoque favorable, debido a que expone los datos a diferentes clientes, quienes pueden no respetar las restricciones que se han establecido, pero no codificado [33]. Por esta razón un par de buenas prácticas para evitar esta situación son: Limitar el acceso de los clientes, solo a los objetos de interés para el. Utilizar vistas o snapshots, para la extracción de la información, esto previene que los clientes observen las estructuras de las entidades y la información que no es de su interés [33]. Permitir la manipulación de los datos a través del uso de procedimientos almacenados, que permitan un manejo transparente de las transacciones y brinden encapsulamiento de las operaciones y entidades que se ven afectadas [33]. El uso de estas prácticas para compartir bases de datos, no son por si solas la mejor solución, pues deben estar acompañadas por una correcta verificación del administrador de la base de datos, quien definirá con ayuda de lo descrito por el cliente, la información que este realmente necesita y la definición de posibles casos que llevarían a abortar la transacción al momento de modificar los datos, además de identificar los posibles escenarios, que podrían generar inconsistencias y como evitarlas pues no se debe olvidar que la información puede estar siendo manipulada por varias aplicaciones al tiempo Buenas prácticas para invocación remota de procedimientos En la revisión de la literatura realizada no se encontraron buenas prácticas para este estilo de integración. Por lo tanto en lo que sigue del desarrollo del método trabajaremos con las buenas prácticas para invocación remota de procedimientos identificadas en la consulta directa a expertos. 56

57 Buenas prácticas para mensajería En la actualidad, los sistemas de mensajería, se muestran como los medio de comunicación más adecuados para la intercomunicación de aplicaciones empresariales [16], por esta razón y después de su uso intensivo por parte de millones de desarrolladores, se encuentra en la literatura [16] las buenas prácticas en un grupo de patrones que se han denominado patrones de integración empresarial, como se expuso en la etapa II de esta fase, y que se basan en el uso del estilo de integración de mensajería como pilar principal para la integración. Como se mostró en esta etapa, existen buenas prácticas conocidas para cada estilo de integración, por lo tanto no existe un estilo mejor que otro, sino que cada situación indica qué estilo debe ser usado, o en algunos casos, cuáles estilos deben ser combinados [31]. A continuación se presentan en la Tabla 1, algunos pros y contras de cada uno de los estilos. Estilo de integración Ventajas Desventajas Transferencia de archivos Bases de datos compartidas Invocación remota de procedimientos Mensajería Simple, Interoperable. Simple, transaccional. Simple, puede ser rápido. Asíncrono, escalable. No es transaccional, ni para necesidades en tiempo real. Puede ser lento y difícil de evolucionar. No es interoperable, síncrono y altamente acoplado. Complejo. Tabla 1 Ventajas y desventajas de los estilos de integración [31]. 57

58 Para finalizar esta sección de buenas prácticas, se presenta a continuación un cuadro que ofrece una primera alternativa hacia el uso de Frameworks, en caso de requerir alguno de estos estilos. Estilo de integración Transferencia de archivos Bases de datos compartidas Invocación 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 Mensajería listeners, Spring Integration, Message Driver Bean, EJB Tabla 2 Estilos de integración y los Frameworks que los implementan. 4.2 Fase II Diseño del método Conforme a la metodología establecida, se desarrolló la fase II del proyecto. El resultado de las actividades realizadas se detalla a continuación: Etapa I: Definición de categorías Para la definición de las categorías en las que se pueden clasificar los casos de negocio que son objeto del método diseñado, se tomó la decisión de categorizarlos de acuerdo a la necesidad de integración que se busca resolver. La decisión se tomó en un inicio teniendo en cuenta que la necesidad de integración es la que prácticamente define el caso de negocio y que las otras características son complementos que permiten particularizar aspectos del mismo. Durante la etapa de definición de filtros se validó completamente la decisión aquí tomada; pues en esta etapa se pudo evidenciar que la necesidad de integración es una 58

59 sola para cada caso de negocio y que las otras variables se pueden presentar simultáneamente en la caracterización de este; siendo la necesidad de integración la que determina la combinación que se puede presentar entre demás variables. Por lo anterior en esta etapa se definieron: Categoría 1: casos de negocio para compartir datos. Categoría 2: casos de negocio para compartir funcionalidad Etapa II: Soluciones conocidas aplicables por categoría Para la Categoría 1, casos de negocio regidos por datos, las soluciones conocidas aplicables son [16]: Transferencia de Archivos Bases de datos compartidas Mensajería Para la Categoría 2, casos de negocio regidos por funcionalidad, las soluciones conocidas aplicables son [16]: Invocación Remota de procedimientos Mensajería Etapa III: Buenas prácticas aplicables por categoría Esta etapa de la metodología, básicamente se resolvió en la Etapa III de la Fase I en la que las buenas prácticas quedaron clasificadas de acuerdo a las necesidades de integración y en la Etapa I de la Fase II en la que las necesidades de integración se definieron como las categorías del método Etapa IV: Definición de filtros Como se definió, en la Etapa I de la Fase I, determinar el conjunto de variables con las que se puede caracterizar un caso de integración de aplicaciones empresariales se identificaron cuatro (4) grupos de variables. El objetivo de esta etapa de la metodología fue identificar cuáles variables son excluyentes y cuáles son complementarias; identificación que corresponde al insumo necesario y 59

60 suficiente para la creación de los filtros que conducirán a la correcta la caracterización del caso de negocio Combinación de variables La identificación de estas exclusiones o complementos se realizó en dos niveles: En las variables pertenecientes al mismo grupo y entre las variables que pertenecen a grupos distintos. A continuación se muestra el proceso realizado y el resultado de esta identificación, para lo cual es importante resaltar que los casos en que las variables se subdividen en varias sub-variables, el análisis se realizó a nivel de sub-variables Entre el mismo grupo El propósito de esta actividad fue evaluar la compatibilidad entre las variables de un mismo grupo. El resultado de este trabajo se muestra a continuación: Grupo I: Tipos de Aplicaciones Para realizar esta actividad se parte de dos premisas fundamentales: Una aplicación solo puede tener un único tipo y se excluyen las aplicaciones tipo Tiempo Real que al ser evaluadas por la encuesta no obtuvieron una calificación promedio relevante para este estudio; Como se trabaja con un aplicación origen y una aplicación destino el análisis se centró en identificar las posibles combinaciones de tipos de aplicaciones entre ellas. Para ello se elaboró una matriz en la que las filas corresponden a los tipos de aplicación origen y las columnas a los tipos de aplicación destino; así, la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 2.1 Tipos de aplicaciones. Después de realizar el análisis de cada una de las combinaciones se encuentra que no hay limitantes en cuanto al tipo de la aplicación origen y destino, por lo cual el resultado de esta actividad arroja una matriz con todas las posiciones con valor 60

61 uno (1) lo que define que todas las combinaciones son posibles y que en esta actividad no se identificaron filtros. Grupo II: Necesidades Como se ha expuesto en el planteamiento del problema, cada necesidad de integración puede tener una o varias soluciones conocidas; por lo cual el alcance del diseño del método se restringe al manejo de una única necesidad de integración por cada caso de negocio; en la ocasión en que el mismo caso de negocio contemple diferentes necesidades de integración, el caso de negocio debe ser caracterizado tantas veces como necesidades de integración contemple. Por lo anterior en esta actividad no se identificaron filtros. Grupo III: Criterios y Restricciones Se elaboró una matriz en la que las que tanto las filas como las columnas corresponden a cada uno de los criterios y restricciones; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 2.2 Criterios y restricciones. En el análisis realizado se encontraron criterios y restricciones que son mutuamente excluyentes, a continuación se detallan las exclusiones resultantes: Cada variable consigo misma: Debido a que la herramienta utilizada para el análisis es una matriz en la intersección de filas y columnas surgió esta relación. Sin embargo en el diseño del método esta relación no existe así que la diagonal de la matriz se marcó con valor cero (0). En este análisis no hubo identificación de filtros. Sub-variables asociadas a la misma variable: Por la definición de cada subvariable, en el análisis se encontró que las sub-variables son mutuamente excluyentes entre sí cuando están asociadas a la misma variable. Por lo anterior las casillas de intersección entre sub-variables asociadas a la misma variable se marcaron con cero (0). En este análisis se identificó el 61

62 Filtro 1. Es importante resaltar que esta exclusión tiene contenida la exclusión del numeral anterior. Intrusión no permitida: Por definición de la sub-variable Intrusión no permitida y de la sub-variable Modificar la aplicación para usar un formato de datos común, se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 2. Formato de los datos: Por definición de la variable Formato de los datos y de la sub-variable Funcionalidad se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 3. Latencia en el intercambio de datos: Por definición de la variable Latencia en el intercambio de datos y de la sub-variable Funcionalidad se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 4. Destino NO siempre disponible y síncrona: Por definición de la sub-variable Síncrona y de la sub-variable Destino NO siempre disponible se encuentra la mutua exclusión. Es este análisis se identificó el Filtro 5. Destino NO siempre disponible y Funcionalidad: Por definición de la subvariable Funcionalidad y de la sub-variable Destino NO siempre disponible se encuentra la mutua exclusión. En este análisis se identificó el Filtro 6. Además en el análisis también se identificó que la aplicación que provee la funcionalidad siempre es la aplicación destino lo cual llevó a identificar el Filtro 6 Funcionalidad y destino. Como resultado de este análisis se obtuvo una matriz simétrica debido a que las exclusiones encontradas entre las sub-variables son mutuas. Grupo IV: Características de calidad En este grupo el análisis se orientó con la revisión de la literatura [25], en la que se encuentra ampliamente documentada la exclusión entre las características de calidad. Se identificaron cuatro (4) filtros como resultado de esta revisión: 62

63 Filtro 7: Características de calidad que se ven afectados negativamente al definir funcionalidad como requerimiento Filtro 8: Características de calidad que se ven afectados negativamente al definir eficiencia de rendimiento como requerimiento Filtro 9: Características de calidad que se ven afectados negativamente al definir Capacidad de operación como requerimiento Filtro 10: Características de calidad que se ven afectados negativamente al definir seguridad o compatibilidad o capacidad de transferencia como requerimiento Se elaboró una matriz en la que las que tanto las filas como las columnas corresponden a cada uno de las características de calidad; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 2.3 Características de calidad Entre los diferentes grupos Como parte del análisis se definió la siguiente premisa fundamental: Las variables del grupo características de calidad no son excluyentes con las variables de ningún otro grupo, porque las características de calidad pueden ser requeridos independientemente de la necesidad de integración, los tipos de aplicaciones y los criterios y restricciones. Por lo anterior solo se evaluaron las exclusiones entre los siguientes grupos: Criterios y Restricciones Vs. Tipo de Aplicación Origen Se elaboró una matriz en la que las que las filas corresponden a los criterios y restricciones y las columnas corresponden a los tipos de aplicaciones origen; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), para este análisis se separaron los tipos de aplicaciones transaccionales 1 y 2 que se habían venido 63

64 manejando, en los anteriores análisis como uno solo; lo anterior debido a que la diferencia entre estos dos tipos de aplicaciones es el tipo de estructuras de datos que manejan y que para este análisis es requerido revisar por separado, ver Anexo 2.4 Criterios y restricciones tipo de aplicación origen. En el análisis realizado se encontró que en por la definición de aplicación tipo batch, es excluyente con las sub-variables: funcionalidad y aplicación destino no siempre disponible en este segundo caso solo se puede resolver cuando hay tecnología disponible que lo permita. En este análisis se identificaron los filtros 11A y 11B. Y el filtro 12 que corresponde al tipo de aplicaciones transaccionales 1 que no procesan datos complejos, por tanto buscar un formato de datos extensible en el tiempo se considera excluyente. Criterios y Restricciones Vs Tipo de Aplicación Destino Se elaboró una matriz en la que las que las filas corresponden a los criterios y restricciones y las columnas corresponden a los tipos de aplicaciones destino; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), para este análisis se separaron los tipos de aplicaciones transaccionales 1 y 2 que se habían venido manejando, en los anteriores análisis como uno solo; lo anterior debido a que la diferencia entre estos dos tipos de aplicaciones es el tipo de estructuras de datos que manejan y que para este análisis es requerido revisar por separado, ver Anexo 2.5 Criterios y restricciones tipo de aplicación destino. En el análisis realizado se encontró el Filtro 13. En el cual se define: Filtro 13A: Batch y criterios y restricciones necesarias: si se define que el tipo de aplicación origen es batch, se encontró que las siguientes subvariables del grupo criterios y restricciones deben estar presentes: intrusión permitida, compartir datos, comunicación síncrona y destino siempre disponible. 64

65 Filtro 13B: Batch y criterios y restricciones excluyentes: el resultado del numeral anterior implica que las sub-variables: intrusión no permitida, compartir funcionalidad, comunicación asíncrona y destino No siempre disponible; son excluyentes con la variable bases de datos compartidas. Filtro 13C Batch criterios y restricciones que no aplican: las variables formato de los datos, latencia en el intercambio de datos y selección de la tecnología no son requeridas ni excluyentes con la necesidad bases de datos compartidas; pues no es relevante que estén presentes o ausentes al analizar este tipo de aplicación. El filtro 14 que corresponde al tipo de aplicaciones transaccionales 1 que no procesan datos complejos, por tanto buscar un formato de datos extensible en el tiempo se considera excluyente Utilización de Filtros: En esta actividad se muestran los filtros identificados en la actividad anterior de manera consolidada. Se parte como premisa que la necesidad de integración es la que determina la caracterización del caso de negocio y por ende es la que define los valores que pueden tomar las demás variables y sub-variables. A continuación se muestran los filtros y el orden en que se aplicarán Identificar necesidad de integración: Como se había expuesto anteriormente, se parte de la premisa que la necesidad de integración es una sola para el caso de negocio. Una vez identificada la necesidad de integración, datos o funcionalidad, la siguiente variable a identificar es el tipo de aplicación origen; se establece que una aplicación origen solo puede tener un único tipo. Una vez identificada la necesidad de integración y el tipo de aplicación origen, la siguiente variable a identificar es el tipo de aplicación destino; al igual que en el punto anterior la aplicación destino solo puede tener un único tipo, en caso que se requiera integrar una aplicación origen con varias 65

66 destino cada integración se considera un caso de negocio distinto y debe evaluarse por separado en el método. No hay exclusiones a evaluar entre los tipos de aplicaciones origen y destino; Con la necesidad de integración y los tipos de aplicaciones origen y destino identificadas, se pasa a identificar los criterios y restricciones de integración. En este punto se pueden identificar varios criterios y restricciones para un caso de negocio. Las exclusiones que se deben evaluar son: Necesidad de integración identificada vs. Criterios y restricciones. Tipo de aplicación origen identificada vs. Criterios y restricciones. Tipo de aplicación destino identificada vs. Criterios y restricciones. Criterios y restricciones vs. Criterios y restricciones. Características de calidad vs. Características de calidad Etapa V: El método diseñado Como resultado de esta fase de la metodología, se resume en los siguientes pasos: Paso1: Documentar el caso de negocio determinando los valores para cada una de las variables de caracterización definidas. Con ello se definen las variables de entrada al método. Paso2: Aplicar los filtros, en el orden descrito en la última etapa de esta fase, para con ello encontrar la correcta caracterización del caso de negocio y por consiguiente asociarlo a una de las siguientes categorías: Categoría 1: casos de negocio regidos datos. Categoría 2: casos de negocio regidos por funcionalidad. Paso3: Buscar las soluciones conocidas aplicables a la categoría encontrada. Paso4: Buscar las buenas prácticas aplicables a la categoría encontrada. Paso5: Entregar la soluciones conocidas en el orden de aplicabilidad. 66

67 4.3 Fase III Prueba del diseño del método Conforme a la metodología establecida se desarrollo la tercera y última fase del proyecto. Los resultados se muestran a continuación: Etapa I: Refinamiento del método El objetivo de esta etapa es encontrar una serie de criterios que permitan validar el conjunto de recomendaciones que el método entrega. Para ello se trabajó en elaborar un conjunto de filtros adicionales que trabajan sobre las soluciones conocidas y las demás variables de caracterización. Estos filtros adicionales se describen a continuación Soluciones conocidas Vs. Criterios y Restricciones Se elaboró una matriz en la que las que las filas corresponden a las necesidades de integración y las columnas corresponden a cada uno de los criterios y restricciones; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 3.1 Soluciones conocidas criterios y restricciones. En el análisis realizado se encontraron necesidades de integración con criterios y restricciones que son mutuamente excluyentes, a continuación se detallan las exclusiones resultantes: Transferencia de Archivos y Funcionalidad: Por definición de la sub-variable Funcionalidad y de la variable Transferencia de Archivos se encuentra la mutua exclusión. En este análisis se identificó el Filtro Bases de Datos Compartidas Por definición de la variable Bases de datos compartidas se encuentra la exclusión con la todas las variables del grupo criterios y restricciones. En este análisis se identificó el Filtro 16. En el cual se define: 67

68 Filtro 16A Requisitos de criterios y restricciones necesarios para la solución bases de datos compartidas: si se define que la solución es compartir bases de datos, se encontró que las siguientes sub-variables del grupo criterios y restricciones deben estar presentes: intrusión permitida, compartir datos, comunicación síncrona y destino siempre disponible Filtro 16B Criterios y restricciones excluyentes para la solución bases de datos compartidas: el resultado del numeral anterior implica que las sub-variables: intrusión no permitida, compartir funcionalidad, comunicación asíncrona y destino, no siempre disponible; son excluyentes con la variable bases de datos compartidas Filtro 16C Criterios y restricciones para las que no aplica la solución bases de datos compartidas: las variables formato de los datos, latencia en el intercambio de datos y selección de la tecnología no son requeridas ni excluyentes con la solución bases de datos compartidas; pues no es relevante que estén presentes o ausentes al analizar la solución bases de datos compartidas Invocación Remota de Procedimientos Por definición de la solución Invocación Remota de Procedimientos se encuentra la exclusión con todas las variables y sub-variables del grupo criterios y restricciones asociadas al intercambio de datos: formato de los datos, latencia en el intercambio de datos y datos. En este análisis se identificó el Filtro Mensajería Por definición de la solución Mensajería se encuentra la exclusión la sub-variable del grupo criterios y restricciones selección de la tecnología no disponible. En este análisis se identificó el Filtro

69 Soluciones Conocidas Vs. Tipo de Aplicación Origen Se elaboró una matriz en la que las que las filas corresponden a las soluciones conocidas de integración y las columnas corresponden a los tipos de aplicaciones origen; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 3.3 Soluciones conocidas tipo de aplicación origen. En el análisis realizado se encontró que la solución conocida de integración invocación remota de procedimientos es excluyente con el tipo de aplicación origen batch. En este análisis se identificó el filtro Soluciones Conocidas Vs. Tipo de Aplicación Destino Se elaboró una matriz en la que las que las filas corresponden a las soluciones conocidas de integración y las columnas corresponden a los tipos de aplicaciones destino; la casilla de intersección entre fila y columna marcada con un uno (1) indica que la combinación es posible en caso contrario se marca con un (0), ver Anexo 3.4 Soluciones conocidas tipo de aplicación destino. En el análisis realizado se encontró que en por la definición de aplicación tipo batch, la única solución conocida de integración que puede tener como aplicación destino tipo batch es la de bases de datos compartidas. En este análisis se identificó el filtro 20. En este punto se define incluir un nuevo paso para realizar la aplicación de los filtros encontrados en esta etapa. El método refinado se define en los siguientes pasos: Paso1: Documentar el caso de negocio determinando los valores para cada una de las variables de caracterización definidas. Con ello se definen las variables de entrada al método. Paso2: Aplicar los filtros para con ello encontrar la correcta caracterización del caso de negocio y por consiguiente asociarlo a una de las siguientes categorías. La aplicación de los filtros debe realizarse en el siguiente orden: 69

70 Identificar necesidad de integración: La necesidad de integración es una sola para el caso de negocio Con la necesidad de integración definir la categoría del caso de negocio Una vez identificada la necesidad de integración, la siguiente variable a identificar es el tipo de aplicación origen Una vez identificada la necesidad de integración y el tipo de aplicación origen, la siguiente variable a identificar es el tipo de aplicación destino Con la necesidad de integración y los tipos de aplicaciones origen y destino identificadas, se pasa a identificar los criterios y restricciones de integración. En este punto se pueden identificar varios criterios y restricciones para un caso de negocio. Las exclusiones que se deben evaluar son: o Tipo de aplicación origen identificada vs. Criterios y restricciones o Tipo de aplicación destino identificada vs. Criterios y restricciones o Criterios y restricciones vs. Criterios y restricciones o Características de calidad vs. Características de Calidad Paso3: Buscar las soluciones conocidas aplicables a la categoría encontrada Paso4: Aplicar los filtros: Soluciones conocidas vs. criterios y restricciones Soluciones conocidas vs. tipo de aplicación origen Soluciones conocidas vs. tipo de aplicación destino Paso5: Buscar las buenas prácticas aplicables a la categoría encontrada. Paso6: Entregar la soluciones conocidas y buenas prácticas aplicables a la categoría 70

71 4.3.2 Etapa II: Aplicación del método diseñado Para la prueba del método se recolectaron diez (10) casos reales de integración de aplicaciones presentados en los dos últimos años en los proyectos de integración de aplicaciones del grupo empresarial Coomeva. Cada uno de los casos de negocio se sometió a los seis (6) pasos del método diseñado. La documentación de la aplicación del método para los diez (10) casos de negocio probados se encuentra detallada en el Anexo3.5 Caracterización de los casos de negocio y soluciones Paso1: Durante la ejecución del Paso1 se observó que las variables identificadas y los valores definidos para ellas, fueron las necesarias y resultaron suficientes para la caracterización de los casos de negocio. Paso2: Durante la ejecución del Paso2 se encontró que en la definición de los filtros faltó la evaluación de la existencia de una posible exclusión entre los criterios Formato de datos y Selección de la tecnología, en cuanto a que en algunos casos puede ser requerido utilizar un mediador que homologue los datos lo que implica que deba existir tecnología para realizarlo. En este análisis y por tratarse de solo algunos casos se agregó a la matriz de combinación de variables de criterios y restricciones la Evaluación 1. La matriz actualizada se muestra en el Anexo 3.2 Criterios y restricciones refinado. Adicional a lo anterior, durante la aplicación de filtros, se encontró que es necesario caracterizar el caso de negocio con una característica de calidad principal que determinará la inclusión o exclusión de las restantes características en la caracterización del caso de negocio. Paso3: Durante la ejecución se observó que realizar el Paso3 se obtiene como consecuencia inmediata una vez se ha realizado el paso2 de manera adecuada. 71

72 Paso4: Durante la ejecución del paso4 se observó que los filtros identificados, fueron los adecuados para refinar la caracterización de los casos de negocio. Paso5: Durante la ejecución se observó que realizar el paso5 se obtiene como consecuencia inmediata una vez se han realizado el Paso2 y el Paso4 de manera adecuada. Sin embargo, se evidenció una relación directa de buenas prácticas con soluciones conocidas. Por lo anterior el método se refinó para agrupar las buenas prácticas a cada una de las soluciones conocidas. El Paso 5 quedó entonces definido así: buscar las buenas prácticas asociadas a cada solución conocida aplicable a la categoría encontrada como se muestra en la Tabla 3. Paso6: Durante la ejecución se observó que realizar el Paso6 se obtiene como consecuencia inmediata una vez se han realizado el Paso2, el Paso4 y el Paso5 de manera adecuada. Solución Conocida Transferencia de archivos Bases de datos compartidas Invocación remota de procedimientos Mensajería Buenas prácticas Uso de Formato Generación de Archivos Transporte Sincronización y políticas Tipos de datos nativos Gobierno de datos Mecanismo de Exposición Consulta de información Llamado a procedimientos Formato de los mensajes Mecanismos de entrega de los mensajes Tabla 3 Buenas prácticas agrupadas por cada solución conocida. 72

73 El método final refinado y aplicado quedó definido como lo muestra la Figura 10. Los pasos se describen a continuación: Paso1: Documentar el caso de negocio determinando los valores para cada una de las variables de caracterización definidas. Con ello se definen las variables de entrada al método. Paso2: Aplicar los filtros para con ello encontrar la correcta caracterización del caso de negocio y por consiguiente asociarlo a una de las siguientes categorías. La aplicación de los filtros debe realizarse en el siguiente orden: Identificar necesidad de integración: La necesidad de integración es una sola para el caso de negocio Con la necesidad de integración definir la categoría del caso de negocio Una vez identificada la necesidad de integración, la siguiente variable a identificar es el tipo de aplicación origen Una vez identificada la necesidad de integración y el tipo de aplicación origen, la siguiente variable a identificar es el tipo de aplicación destino Con la necesidad de integración y los tipos de aplicaciones origen y destino identificadas, se pasa a identificar los criterios y restricciones de integración. En este punto se pueden identificar varios criterios y restricciones para un caso de negocio. Las exclusiones que se deben evaluar son: o Tipo de aplicación origen identificada vs. Criterios y restricciones o Tipo de aplicación destino identificada vs. Criterios y restricciones o Criterios y restricciones vs. criterios y restricciones o Características de calidad vs. características de Calidad Paso3: Buscar las soluciones conocidas aplicables a la categoría encontrada Paso4: Aplicar los filtros: Soluciones conocidas vs. criterios y restricciones 73

74 Soluciones conocidas vs. tipo de aplicación origen Soluciones conocidas vs. tipo de aplicación destino Paso5: Buscar las buenas prácticas asociadas a cada solución conocida aplicable a la categoría. Paso6: Entregar la soluciones conocidas y buenas prácticas aplicables a la categoría encontrada. Figura 10. Esquema del método diseñado Al realizar el análisis cualitativo de las soluciones entregadas por el método para los diez (10) casos de negocio caracterizados se encontró que: 74

75 En todos los casos la solución real implementada coincide con una de las soluciones recomendadas por el método. En todos los casos la solución real implementada se encuentra entre las dos soluciones más recomendadas por el método. En el cuarenta por ciento de los casos la solución real implementada es la solución más recomendada por el método. En el sesenta por ciento de los casos la solución más recomendada por el método fue la mensajería, la cual no coincidió con la solución real implementada. Esto se debe a que en el Grupo Empresarial Coomeva, la mensajería no había sido evaluada como una solución viable para los problemas de integración. La Tabla 4 muestra de manera general lo anteriormente descrito: Tabla 4 Comparativo entre solución real y soluciones recomendadas. Al realizar el análisis cualitativo para los casos en los que la solución más recomendada entregada por el método no coincide con la solución real implementada, se encontró en todos los casos la posibilidad de mejorar la implementación real así: En los Caso1 y Caso8, donde la solución real implementada es Transferencia de Archivos y la solución más recomendada por el método 75