UNIVERSIDAD DE SANTIAGO DE CHILE FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

Transcripción

1 UNIVERSIDAD DE SANTIAGO DE CHILE FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICA Situación actual de la infraestructura Componentes en servidor Huelen Nombre : Iván Abarca B. Asignatura : Taller de Investigación Profesor : Edmundo Leiva Lobos Fecha : 21 de septiembre de 2013

2

3 i Índice de contenido 1. Introducción Situación actual de la infraestructura Aplicaciones componentes Servidor de aplicaciones Motor BPM Bus de servicios empresariales Servidor de identidades Red social y otros componentes Resumen de los componentes existentes Cambios en los componentes Problemas detectados Soluciones propuestas Conclusiones Referencias... 21

4

5 1 1. Introducción El siguiente documento tiene como propósito recopilar la información respecto a la infraestructura puesta en marcha sobre la máquina Huelen por Felipe Quiroz, mostrar aquellas tecnologías que forman parte de esta infraestructura, para luego detallar aquellas situaciones por resolver para que los componentes desplegados obedezcan a la metodología en la cual fueron diseñados, es decir, cumpliendo estándares empresariales como SOA. En las primeras secciones se describe a nivel general cada componente usado actualmente en la infraestructura, con una visión específica a lo que involucra el uso de la arquitectura, mostrando cómo un determinado componente funciona en específico para nuestro caso y de esta forma, cómo interactúa con los demás elementos. A continuación se recopilan los cambios efectuados para poder poner en marcha la infraestructura, o al menos para poder dejarla en su estado actual a partir de una instalación limpia, con el objetivo de poder comenzar a entender aquellos problemas que pudieron existir durante la instalación para evitar que se repitan. En la sección que sigue, se describen algunos de los problemas detectados durante el funcionamiento de la infraestructura en su estado actual en el servidor Huelen, que pueden o no corresponder a problemas temporales o ser parte de una dificultad mayor. Posteriormente, se muestran aquellas acciones que deben realizarse para poder efectuar un traspaso adecuado entre la versión actual de la infraestructura y las posteriores que pudieran venir. El objetivo es que esta transición siempre quede documentada y no se pierda la externalización necesaria para poder comunicar adecuadamente de las dificultades y éxitos durante la implantación de esta infraestructura.

6 2 2. Situación actual de la infraestructura En este capítulo se describe el estado actual de la infraestructura que opera en el servidor Huelen, aquellos componentes que actualmente están en operación con descripciones sobre el funcionamiento de cada elemento en su conjunto. 2.1 Aplicaciones componentes La infraestructura reside en la carpeta /home/fondef/infraestructura.v2/, lugar definido por Felipe Quiroz al final de su trabajo de titulación. A continuación serán descritos de manera general los componentes actualmente activos Servidor de aplicaciones El servidor de aplicaciones actualmente en uso es JBoss AS Final y es el elemento base a ejecutar para poner en marcha la infraestructura. JBoss AS requiere la instalación de Java SE 6 o superior en el sistema y puede operar en cualquier sistema operativo mientras cumpla con este requisito. Para el caso particular de Huelen, que utiliza Ubuntu Server , la versión de Java adecuada se puede instalar a través del administrador de paquetes. El servidor de aplicaciones tendrá el trabajo de mantener aquellas aplicaciones que puedan ser empaquetadas en formato EAR o WAR, donde funcionarán y estarán disponibles para ser llamadas de acuerdo al circuito mostrado en la siguiente figura.

7 3 FIGURA 2.1: Visión general de la solución de arquitectura propuesta por Quiroz De esta forma los principales usos del servidor de aplicaciones es tener funcionando la suite o motor BPM, la red social, el mapper, el disponibilizador y RBox. Para permitir esta interacción JBoss AS provee una serie de tecnologías para construir servicios web REST, para trabajar con persistencia, transacciones, inyección de dependencias, mensajería, servlets, etc. JBoss AS 7 habilita una serie de servicios en distintos puertos del sistema donde opera. Para el caso de la infraestructura, el puerto 8385 sirve como punto de entrada principal para varios de los servicios incluidos, como la consola BPM para el manejo de las tareas y procesos. Otros puertos se describen en la TABLA 2.1, que muestra los puertos que JBoss AS define por defecto, con algunas modificaciones para adaptarse a los puertos ya en uso por la máquina Huelén.

8 4 TABLA 2.1: Puertos utilizados por la infraestructura de Felipe Quiroz Puerto Usado para Descripción 25 mail-smtp Servicio para correo electrónico 4447 Remoting Provee un framework para la comunicación simétrica y asimétrica en una red. Soporta varios modos de interacción, como invocaciones, mensajes unidireccionales y callback asíncronos Transaction recovery Manejo de transacciones environment 4713 Transaction status manager Manejo de transacciones 8009 ajp Puerto para la comunicación utilizando el protocolo Apache JServ. Principalmente usado en ambientes que requieran balance de carga. No aplica actualmente a la infraestructura http Expone ciertos servicios como jbpm-console, gwt-consoleserver y drools-guvnor para el manejo del motor BPM, la interfaz con este y el manejo de los procesos de negocio a través de servicios web, respectivamente osgi-http Interfaz para servicios http basados en el framework OSGi 8443 https Alternativa segura al puerto management-https Alternativa segura al puerto management-http Interfaz para la administración vía HTTP, como la consola de JBoss AS 9999 Native management Punto de ingreso a las aplicaciones que funcionen por línea de comando para administrar el servidor de aplicaciones El servidor de aplicaciones tiene una serie de carpetas en su instalación, que son detalladas en la TABLA 2.2. En particular, tiene una configuración standalone que es la utilizada en la infraestructura actualmente, esto considera otras carpetas dentro de la instalación mostradas en la tabla siguiente. TABLA 2.2: Carpetas de la instalación de JBoss AS 7 Carpeta bin bin/client bundles docs/schema Descripción Scripts de inicio, archivos de configuración y utilidades para diagnóstico y creación de usuarios. Contiene un jar para uso de clientes no basados en Maven (no es el caso de la infraestructura Huelen) Paquetes OSGi Archivos de definición de esquemas XML

9 5 domain modules standalone appclient welcomecontent Archivos de configuración, contenido desplegado, y áreas para escritura usadas por los procesos ejecutados por esta instalación en modo dominio. AS 7 usa una arquitectura modular para cargar clases. Los distintos módulos usados por el servidor se ubican aquí. Archivos de configuración, contenido desplegado, y áreas para escritura usadas el servidor standalone ejecutado por esta instalación. Archivos de configuración, contenido desplegado, y áreas para escritura usadas el contenedor de aplicación cliente ejecutada por esta instalación. Contenido de la página de bienvenida TABLA 2.3: Estructura de la carpeta 'standalone' de JBoss AS Carpeta configuration data deployments lib/ext log tmp tmp/auth Descripción Archivos de configuración para el servidor standalone. Este es el único lugar donde está toda la información para configurar el servidor. Información escrita por el servidor que debe persistir un reinicio del mismo. Despliegues del usuario final se ubican aquí para su detección automática e instalación en el servidor. Ubicación para los jars de las bibliotecas referenciadas por las aplicaciones. Archivos de logging del servidor standalone Ubicación para archivos temporales. Ubicación especial para intercambiar tokens de autenticación con los clientes locales para confirmar que son locales al proceso del servidor de aplicaciones Motor BPM El motor BPM utilizado en la infraestructura es jbpm 5.4 y fue seleccionado por cumplir los criterios de simplicidad, ser ligero e integrable, poder procesar nodos de manera que se permita la invocación de servicios Java o web y soportar transacciones. También es de código abierto y se encuentra en constante soporte y desarrollo de la comunidad.

10 6 FIGURA 2.2: Visión general de jbpm 5 El motor de proceso de negocios jbpm tiene una arquitectura mostrada en la anterior figura. La capacidad de integrarse a distintos sistemas se muestra en la figura como rectángulos grises, permitiendo trabajar con los componentes esenciales sin someterse a otras tecnologías de manera estricta, conformando al paradigma establecido por SOA. El motor de procesos o core engine es el núcleo de jbpm y necesario para ejecutar procesos de negocios. Este es el único componente requerido puesto que los demás elementos se pueden no utilizar. Las aplicaciones, en particular la red social en esta infraestructura, deberán invocar a este motor cuando sea necesario, para poder comenzar los procesos o eventos. Junto al motor existen otros servicios principales como el historial de registro o history log que mantiene información actual y anterior del estado de cada instancia del proceso. Además está el servicio de tareas humanas o human task service, que se encargará de manipular el ciclo de vida de las tareas para los actores humanos que participen en el proceso. Para el caso de la infraestructura

11 7 sobre el servidor en Huelen, estos dos componentes serán utilizados, con el servicio de tareas humanas funcionando como uno de los más importantes ya que el proceso de negocio de generación de noticias tiene como principales actores los periodistas, entre otras personas. El repositorio Guvnor es un componente opcional que funciona como una base de conocimiento o un lugar para almacenar todo lo relacionado con la lógica del negocio, incluyendo a los procesos de negocio. Soporta la colaboración, versiones e integración con el diseñador web y un plugin de Eclipse, pudiendo estar en sincronización con ambas herramientas. Este repositorio será utilizado para almacenar el proceso de negocio de generación de noticias, escrito en notación BPMN2. La consola de administración basada en web permite a los usuarios manejar los procesos de negocio como comenzar un nuevo proceso, inspeccionar instancias en ejecución, administrar la lista de tareas y poder realizar tareas de monitoreo mediante BAM, y ver reportes. Esto será utilizado por el jefe de la sala de prensa, ya que tendrá el punto de conexión con el panel de control necesario para seguir el curso del proceso de negocio. De esta forma, muchos de los componentes de jbpm se utilizarán, a pesar de tener la ventaja de ser modulares lo que permite utilizarlos por separado o en conjunto, por lo que lo hacen una tecnología poderosa para cumplir el rol de suite BPM en la arquitectura. Todos los actores del proceso de negocio interactuarán de alguna forma con este motor por lo que es importante que cumpla con los requisitos de ser integrable y extensible Bus de servicios empresariales La tecnología seleccionada para usar como bus de servicios empresariales es WSO2 ESB. Esta decisión está respaldada por que este producto cumple con los criterios: Tener adaptadores para cada protocolo necesario, como mínimo los protocolos HTTP, FTP, JMS, SOAP, POP3/SMTP y archivos.

12 8 Ser capaz de proveer enrutamiento y encadenar pasos múltiples en un procesamiento, basado en contenido, división, agregación y excepciones. Estas tareas de coreografía y manejo de flujo de datos son encargados al ESB. Debe ser tolerante a fallos y tener la capacidad de funcionar en entornos distribuidos. Debe utilizar un formato estandarizado, como XML, para hacer las transformaciones necesarias para funcionar correctamente. Debe ser extensible para la creación de servicios o adaptadores adicionales. Debe ser de código abierto y tener una comunidad activa que lo respalde. WSO2 ESB se define como un ESB ligero que con la funcionalidad esencial y la capacidad de configurarse mediante XML, cuenta con características de alto rendimiento y alta disponibilidad que lo hacen adecuado para la mediación de mensajes web. En la infraestructura, WSO2 ESB no se encuentra actualmente integrado a JBoss AS, por lo que es un objetivo a cumplir, evitando funcionar con el servidor incluido en la instalación por defecto. Este procedimiento debe ser documentado para facilitar el traspaso a otras personas. FIGURA 2.3: Arquitectura de mensajes en WSO2 ESB La figura anterior describe el ciclo de vida desde la perspectiva de un mensaje al pasar por el ESB. En primer lugar una aplicación publica el mensaje al bus, este mensaje es recibido por un transporte, que tiene como misión llevar mensajes que están en un formato específico.

13 9 Luego el transporte envía el mensaje por un tubo de mensajes que maneja la calidad de servicio y aspectos como la seguridad y la mensajería confiable. Después de este paso comienza la etapa de enrutamiento y transformación, WSO2 ESB tiene la decisión de diseño de no separar de manera clara estos dos componentes y es labor del bus determinar las decisiones que se toman, ya sea transformar antes del enrutamiento, después del enrutamiento o ambas. Esto es llamado el framework de mediación. Luego el mensaje se inyecta a los tubos de acuerdo a sus destinos, donde influyen nuevamente los conceptos de calidad de servicio. Finalmente la capa de transporte de encarga de las transformaciones necesarias por el ESB. El diagrama muestra como una petición viaja, pero no es la única tarea que realiza, también puede ejecutar tareas, que se representan como un trozo de código activados por un temporizador, escritos en lenguaje Java y empaquetados en un JAR. Estas tareas pueden ser programadas periódicamente. También permite el manejo de eventos, siguiendo los conceptos de notificaciones, publicación y suscripción, administrador de suscripciones, entre otros. Todo esto puede ser monitoreado y configurado por el panel de administrador que habilita Servidor de identidades La tecnología usada por la infraestructura para el manejo de identidades es WSO2 IS, que permite reducir el tiempo de manejo de identidades y credenciales a través de todo un sistema integrado, presentando un ambiente de single sign-on (SSO) facilitando el trabajo tanto para los desarrolladores como para los usuarios. Actualmente la infraestructura no cuenta con el servicio de identidades implementado, y solo los archivos están en el servidor, sin integración en absoluto con ningún otro sistema, lo que impactaría al desempeño futuro y presentaría problemas de seguridad, mantención y escalabilidad. En la siguiente figura se muestra la arquitectura del servidor de identidad WSO2 IS, donde queda a la vista la variedad de componentes y tipos de credenciales que soporta, todo manejado

14 10 con una plataforma de monitoreo y administración de estos roles y usuarios. Además soporta fuentes de usuarios de distinto tipo, incluido LDAP y JDBC, por lo que se puede adaptar a los casos que pudiesen existir en la infraestructura. FIGURA 2.4: Arquitectura de WSO2 Identity Server Red social y otros componentes Actualmente se cuenta con el código fuente del componente de red social, componente que se puede compilar y empaquetar en un WAR utilizando Maven y Java SE 6 o superior. Esta operación no presenta dificultades y el objeto obtenido se puede desplegar sin problemas en JBoss AS después de ciertas modificaciones. La red social es un prototipo basado en Spring Framework con funcionalidad básica para operar. Sin embargo, no está documentado el procedimiento para enfrentar los problemas que

15 11 ocurren al intentar ejecutarlo por lo que no se tiene conocimiento de que funcionalidad opera de manera correcta y qué funcionalidad tiene problemas. El código implementa el servicio de noticias soportando la asignación de documentos, tareas, escritura de noticias y mostrar esta información mediante vistas definidas. La futura iteración de esta red social es detectar si se puede reemplazar por una tecnología que favorezca la extensibilidad sin tener grandes trabas o acoplamientos con otros sistemas, de manera de mantener la modularidad en la infraestructura. Se deberá evaluar aquellas opciones existentes, incluida la opción de continuar con lo que se tiene, mejorando los elementos necesarios para permitir mayor colaboración entre los usuarios dentro de esta red social. Sobre los otros componentes aún no se cuenta con versiones wrapper para poder probar el despliegue, por lo que están pendientes las pruebas relacionadas. 2.2 Resumen de los componentes existentes En la siguiente tabla se muestra un resumen de la ubicación para los componentes de la infraestructura. Si bien existen algunos que no están actualmente en el servidor Huelen, se define de todas maneras su ubicación de acuerdo al funcionamiento del servidor de aplicaciones, que requiere que todos los componentes que puedan ser desplegados residan en la carpeta /standalone/deployments. TABLA 2.4: Resumen de tecnologías de la infraestructura actual Componente Tecnología Versión Estado Ubicación relativa a /home/fondef/ Infraestructura.v2/ Servidor de JBoss AS Final Por configurar jboss-as final aplicaciones Motor BPM jbpm 5.4 Final Por configurar jbpm-installer Bus de servicios empresariales WSO2 ESB Por configurar wso2esb-4.6.0

16 12 Servidor de identidades Red Social WSO2 IS Por configurar wso2is Prototipo basado en Spring - No instalado jboss-as final/ standalone/ deployments/ observatorio-social.ear Disponibilizador Wrapper - No instalado jboss-as final/ standalone/ deployments/ observatorio-disponibilizador.ear Mapper Wrapper - No instalado jboss-as final/ standalone/ deployments/ observatorio-mapper.ear Rbox Wrapper - No instalado jboss-as final/ standalone/ deployments/ observatorio-rbox.ear Actualmente solo se dispone del código fuente de los archivos correspondientes a la Red Social, obtenible vía git desde la línea de comando: git clone git@huelen.diinf.usach.cl:/opt/git/observatorio-social-web-2.git Para los siguientes componentes se proponen las rutas de la tabla siguiente como repositorio, a utilizar cuando el código fuente esté disponible. TABLA 2.5: Repositorios para componentes de la infraestructura Red Social (nueva ubicación) Disponibilizador Mapper RBox git clone git@huelen.diinf.usach.cl:/opt/git/observatorio-social.git git clone git@huelen.diinf.usach.cl:/opt/git/observatorio-disponibilizador.git git clone git@huelen.diinf.usach.cl:/opt/git/observatorio-mapper.git git clone git@huelen.diinf.usach.cl:/opt/git/observatorio-rbox.git componente. Finalmente se muestra en la siguiente tabla, los servicios web expuestos por cada

17 13 TABLA 2.6: Servicios web disponibles por la infraestructura URL Componente Descripción o-social-web/ Servidor de aplicaciones Servidor de aplicaciones Motor BPM Motor BPM Motor BPM Motor BPM Motor BPM Servidor de identidades Red Social Página de bienvenida JBoss AS 7 Consola de administración de JBoss AS 7 Página principal para las interfaces REST expuestas por jbpm Login para consola de administración de jbpm Panel para consola de administración de jbpm Panel de administración de recursos de negocio de jbpm Constructor de formularios para usar en conjunto con jbpm Panel de administración de WSO2 IS Punto de ingreso al panel de la versión actual de la red social

18 14 3. Cambios en los componentes La infraestructura en su estado actual tiene ciertas modificaciones en relación a la instalación por defecto de cada componente que utiliza. En esta sección se mostrarán aquellas diferencias de manera de poder replicar una instalación similar y así llevar registro de qué se ha modificado. En la carpeta modules de JBoss AS 7, se cambió la versión originalmente incluida del componente RESTEasy, versión a la versión En la carpeta standalone de JBoss AS 7, se registran varios cambios respecto a la instalación original. Dentro de configuration, el principal cambio es la adaptación del archivo standalone.xml que contiene la mayoría de parámetros para configurar el servidor de aplicaciones. 1. Se agregaron configuraciones de logging para Apache JackRabbit (repositorio de contenido) y para RESTEasy. 2. Se agregaron dos data sources o fuentes de datos, una llamada jbpmds con motor de datos H2, probablemente como repositorio para el motor BPM, y otra llamada observatorio-social, también con motor de datos H2, probablemente con el fin de servir a la red social. 3. Se definió un timeout de despliegue para los componentes instalados en la carpeta /standalone/deployments/. El motivo de esta decisión es para permitir que los recursos EAR/WAR desplegados tengan el tiempo suficiente para iniciarse y no sean interrumpidos. El tiempo por defecto de 60 segundos fue aumentado a 300 segundos. 4. Se aumentó la cantidad de hebras máximo por thread pool de 10 a 20, y se aumentó el tiempo del keep-alive de hebras libres, o el tiempo antes de que las hebras sin trabajo sean finalizados, de 100 a 500 ms. El motivo de esta decisión no está documentado. 5. Para el manejo de transacciones se aumentó un timeout de 300 a 500 segundos. No está documentado para qué tipo de situaciones tiene ventaja este cambio. 6. Se agregaron los dominios de seguridad o información sobre la forma de autenticación para aquellos servicios agregados por jbpm, como drools-guvnor, jbpm-console y jbpmform-builder. Estos utilizarán los usuarios y roles definidos en los archivos users.properties y roles.properties en /standalone/configuration/

19 15 7. Se modificó el puerto por defecto para los servicios HTTP de JBoss, de 8080 a 8385 para evitar conflictos con otros servicios funcionando en el servidor Huelen. 8. También dentro de la carpeta deployments se ubican los componentes necesarios para operar con el motor BPM, resumidos en la siguiente tabla. TABLA 3.1: Recursos desplegados actualmente en la infraestructura Recurso Nombre Descripción designer.war jbpm Designer Editor de procesos de negocios basado en web drools-guvnor.war Drools Guvnor Repositorio de conocimiento, donde se ubican los procesos BPMN2 y otros recursos BPM jbpm Form Builder Editor de formularios basado en web, reutilizables principalmente como frontend para Human Tasks (tareas humanas) dentro de un proceso de negocio jbpm-formbuilder.war jbpm-gwt-consoleserver.war jbpm GWT Console Server Proporciona la capacidad de generar interfaces REST para servicios jbpm-gwt-console.war jbpm GWT Console Consola principal para administrar jbpm jbpm-human-taskwar.war jbpm Human Task Permite utilizar Human Tasks en jbpm 9. En WSO2 ESB, se modificó el archivo de configuración principal ubicado en /wso2esb /repository/conf/carbon.xml. En específico, se definió un offset en los puertos usados para evitar conflictos, este offset es de En WSO2 IS, se modificó el archivo de configuración principal ubicado en /wso2is /repository/conf/carbon.xml. Se definió un offset en los puertos usados para evitar conflictos, este offset es de 3.

20 16 4. Problemas detectados A continuación se describen los problemas existentes en la infraestructura que requieren atención para poder mejorarse en futuras versiones. Estos pueden ser inexistencia de algún elemento, funcionamiento no adecuado o funcionamiento inesperado de un determinado componente. 1. El servidor de identidades o Identity Server, específicamente WSO2-IS, no se utiliza en la infraestructura en conjunto con los otros componentes. En particular se utilizan archivos de texto plano para el control de usuarios y contraseña, lo que conlleva problemas de seguridad, mantención y escalabilidad. 2. La autenticación de usuarios, no es unificada se debe autenticar múltiples veces- y no está bien definido qué tipo de usuario puede acceder a qué panel. En efecto, al intentar ingresar a la autenticación proporcionada no responde, y se ejecuta otra consulta de login desde gwt-console-server. Finalmente no es posible ingresar a la consola de jbpm. 3. La fuente de datos (data source) para observatorio-social definida en JBoss AS 7, archivo ubicado en la ruta: /home/fondef/infraestructura.v2/jboss-as Final/standalone/configuration/standalone.xml es una base de datos en memoria (H2) y no es apropiada para el funcionamiento definitivo de la infraestructura ya que no persiste la información después de un reinicio. 4. El circuito completo de la infraestructura no se puede verificar puesto que no están presentes los despliegues de los componentes como Disponibilizador, Mapper y RBox. Las versiones wrapper no están en la carpeta /standalone/deployments/. 5. Como no está documentado ni estandarizado el sistema de autenticación (LDAP u otro), el ESB o bus de servicios empresariales lanza excepciones al tratar de inicializarse y no comienza, por lo que no se pudo someter a la observación necesaria. 6. El servicio de identidades WSO2-IS y bus de servicios empresariales WSO2-ESB, no están integrados al servidor de aplicaciones JBoss AS, y funcionan con sus servidores Tomcat

21 17 independientes. Esto no es aceptable para mantener un ecosistema adecuado según lo dispuesto por la arquitectura y debe ser corregido. 7. La red social no tiene internamente configurado los puertos de manera dinámica, y aun intenta referirse al puerto 8080 cuando fue modificado a 8385 por la configuración de JBoss AS. Esto causa errores en la operación de crear una noticia. 8. Corrigiendo este problema modificando el código fuente, surgen otros problemas como error 500 al crear una noticia, relacionado con el parsing de JSON en una petición. Corresponderá analizar el código con mayor detalle para encontrar el problema y discutirlo con el autor.

22 18 5. Soluciones propuestas A continuación se muestra una alternativa de solución descrita como una serie de pasos para recuperar el estado diseñado de la infraestructura y así poder utilizarla como base para mejorarla en futuros trabajos. El objetivo es que se pueda lograr la comunicación básica entre cada componente, y que este procedimiento sea documentado para poder ser replicado en otro ambiente sin mayor complicación. 1. Para solucionar los problemas detectados lo primero es tener los principales componentes (servidor de identidad, bus, motor BPM y servidor de aplicaciones) funcionando en sintonía y no como elementos independientes. Esto involucra: a. Encontrar la forma de utilizar credenciales del servidor de identidad en JBoss/jBPM, y no mediante archivos de texto plano, deshabilitando la autenticación mediante esta opción. b. Configurar las fuentes de datos cambiando el motor de base de datos a uno que persista la información entre cada reinicio. c. Documentar el mecanismo de comunicación mediante el ESB, como en qué partes se utiliza y cómo, cuales son las rutas o direcciones a seguir, etc. 2. Documentar el procedimiento para establecer el proceso de negocio correctamente desde el panel de drools-guvnor. El archivo BPMN2 del proceso de negocio existe pero no está cargado por defecto en la infraestructura. 3. Documentar y corregir los problemas para seguir el proceso de negocio con lo que se tiene actualmente de red social, revisando el código fuente si es necesario. 4. Instalar los componentes restantes de la infraestructura en la carpeta de despliegues de JBoss AS: /standalone/deployments/ 5. Asegurarse que cada componente posible funcione integrado a través del servidor de aplicaciones, en particular configurar el bus de servicios empresariales y servidor de identidades para este efecto. a. El bus de servicios empresariales WSO2 ESB debe estar funcionando en la URL dada por o puerto equivalente.

23 19 b. El servicio de identidades WSO2 IS debe estar funcionando en o puerto equivalente. c. Idealmente, buscar integrar estos dos elementos WSO2 en un solo paquete WAR y desplegarlo en JBoss AS obteniendo una ruta de la forma o el puerto equivalente que se le asigne. 6. Construir un pom.xml para Maven que agrupe todos los componentes adicionales, de manera que se puedan compilar y desplegar de manera conjunta, manteniendo la modularidad de los componentes por separado. a. Esto implica adaptar el pom.xml ya existente en el código fuente del componente red social para ser parte de este POM padre o maven de maven.

24 20 6. Conclusiones En este trabajo se ha podido recopilar la información de los componentes que funcionan actualmente en la infraestructura o que están instalados en el servidor Huelen, describiendo además aquellos que no pueden funcionar actualmente. En las secciones siguientes se describen aquellos cambios realizados a las instalaciones por defecto de ciertos componentes y luego se muestran aquellos problemas detectados al poner en marcha la infraestructura. Es claro que más problemas podrían aparecer conforme se incluyen componentes más completos al sistema, pero lo obtenido en esta primera vista es suficiente para poder continuar el trabajo de Felipe Quiroz como una hoja de ruta para adaptarla a los cambios que vienen. El principal problema detectado es la falta de documentos que respalden aquellas decisiones tomadas, no solo a nivel arquitectural, pero a nivel de implementación y despliegue. Ya se han hecho esfuerzos con trabajos de otros memoristas como el trabajo de Álvaro Mendez (2013) lo que muestra que se ha detectado esta debilidad antes y se está actuando para corregirla. Se hace necesario entonces la existencia de una documentación apropiada para lo que se tiene instalado en la infraestructura, y este documento busca ser un avance en esa dirección, de manera que para poder implementar futuras versiones de este sistema en la máquina Huelen u otro servidor, se pueda seguir una línea común que facilite el traspaso del conocimiento. Posterior a la documentación, es lograr la verdadera integración de la infraestructura, y las posibles soluciones planteadas, además de la selección de una apropiada tecnología para el caso de la red social, son el comienzo para este nuevo objetivo.