CONCLUSIONES

6.1.1. Sistemas de Gestión de Workflow en la interoperabilidad de aplicaciones

La interoperabilidad de aplicaciones heredadas es un problema planteado desde hace mucho tiempo que no ha encontrado una solución que satisfaga a la mayoría de desarrolladores de Sistemas de información. A partir de los esfuerzos por crear estándares de datos, modelos, mecanismos de interoperabilidad con servicios web, etc; siempre será un dolor de cabeza para administradores de sistemas. Los Sistemas de Gestión de workflow se plantean como una de tantas soluciones, con la ventaja de su potencialidad para integrar cualquier tipo aplicación heredada en un tiempo mínimo.

6.1.2. Implementación de un Sistema de Gestión de workflow

La aplicación de gestión workflow fue implementada haciendo uso de herramientas libres sobre una plataforma libre. Se utilizó el motor workflow JBPM con lenguaje de programación Java sobre la plataforma Linux Slackware.

JBPM es un motor workflow cumple con todas las especificaciones planteadas en el Modelo de Referencia Workflow [WfMC95], está desarrollado en el lenguaje de programación JAVA y trae todas las herramientas necesarias para integración con el servidor de aplicaciones JBoss.

JGPD (JBPM Graphical Process Designer) es la herramienta de definición de procesos que trae el motor workflow JBPM para diseñar procesos y exportarlos en el lenguaje de definición de procesos JPDL (ver anexo B) interpretado por el motor JBPM a través de su interfaz de intercambio de definición workflow.

JGPD y los procesos definidos en el lenguaje JPDL son los componentes requeridos para comunicación con la interfaz de intercambio de definición workflow, interfaz 1 del motor [WfMC95].

La interfaz de aplicaciones workflow cliente (interfaz 2) se puede implementar incorporando en las aplicaciones cliente componentes de gestión workflow que se encarguen de cumplir con las tareas presentes en la lista trabajo al tiempo que mantienen actualizada la lista. Los módulos agregados sirven como puente entre las aplicaciones workflow cliente y el motor workflow.

La interfaz de aplicaciones externas (interfaz 3) permite la comunicación del motor con aplicaciones existentes, liberándolo de implementar toda una lógica de negocios que puede llegar a ser muy compleja dependiendo del servicio que se desea desarrollar, proporcionando de esta manera una modularidad esencial en aplicaciones flexibles y mantenibles, además de propiedades distribuidas que permiten que el servicio sea implantado en diferentes componentes físicos dando cobertura a diversos entornos de

ejecución.

La API de JBPM incluye las clases necesarias para implementación de la tercera interfaz (según el modelo de referencia workflow) del motor workflow, las cuales soportan el envío de mensajes workflow hacia las aplicaciones y la notificación de eventos que se presentan en las aplicaciones externas.

Las diferentes actividades de los flujos de trabajo son ejecutadas por el personal de la organización y por las aplicaciones que permiten que estos usuarios tengan acceso a los servicios. Dentro del contexto del motor, los roles son asignados a diferentes actores que normalmente son usuarios del sistema y a través de la tercera interfaz estos roles pueden ser asumidos por aplicaciones externas que realizan tareas que automatizan los diferentes procesos y facilitan a los usuarios el uso de los servicios. La implementación de un prototipo de integración de servicios con el motor workflow JBPM fue muy positivo debido principalmente a que se tuvo acceso al código fuente del motor workflow, lo cual permitió conocer y abstraer conceptos acerca de su funcionamiento, una gran ayuda en el momento de desarrollar el puente entre el motor y los servicios de correo electrónico y vigilancia epidemiológica.

Los procesos de vigilancia epidemiológica están soportados por el servicio de correo electrónico el cual se presta sobre la infraestructura que ofrece la red EHAS que está formada por radio enlaces de VHF y de WiFi. Los primeros no ofrecen disponibilidad total, lo cual pone en tela de juicio la confiabilidad del servicio, sin embargo, gracias al control que ejerce el motor workflow sobre los flujos de trabajo representados en procesos, se minimiza el riesgo de pérdida de mensajes, ya que en el caso que ocurra un evento de este tipo, el motor notifica a las partes involucradas para que reenvíen los mensajes, hasta verificar en el destino que la prestación del servicio ha sido completada con éxito.

Con las bondades que brinda la tercera interfaz del motor, se puede establecer comunicación con diversas aplicaciones externas que forman los servicios del programa EHAS e incorporarlas dentro de un mismo proceso, proporcionando de esta manera un marco de integración de los servicios de salud que se prestan en el programa. Estas aplicaciones abarcan los servicios actualmente desarrollados y dejan un sendero abierto para otros servicios como chat, P2P, vides, etc. que se pueden implementar e integrar haciendo uso de la API que ofrece JBPM. En el caso de la aplicación de gestión se integraron los servicios de vigilancia epidemiológica y de correo electrónico, que son los servicios que actualmente se están prestando en el programa.

Existen diversos servicios implementados con distintas tecnologías o sobre distintas plataformas, los cuales operan normalmente sobre motores workflow diferentes al que integra los servicios del programa EHAS. En consideración a esto el motor JBMP implementa la interfaz de funciones de interoperabilidad con la API workflow para integrarse con motores workflow heterogéneos u homogéneos en el caso que se requieran para distribuir la funcionalidad del motor JBPM.

En el presente proyecto se presenta una solución basada en un motor workflow de código abierto y libre distribución, frente a las diversas soluciones workflow propietarias existentes que on muy costosas y estarían lejos del alcance del programa EHAS.

6.1.3. Importancia de las arquitecturas de software

En proyectos de pequeña escala es una práctica común diseñar arquitecturas de software ajustadas a los requerimientos de un sistema y muchas veces solo para completar la documentación del sistema. El diseño de arquitecturas de software va ganando importancia en la medida que el tamaño del proyecto crece, así como sus potencialidades de interoperabilidad y escalabilidad. La tendencia actual en el diseño de arquitecturas es la consideración de los procesos de las organizaciones para las cuales son construidas. Las arquitecturas de Sistemas de gestión de workflow ayudan a cumplir este objetivo en la medida que los sistemas de gestión workflow involucran los procesos de negocio de las organizaciones.

6.1.4. Metodologías de desarrollo

En los proyectos de gran escala es importante establecer una metodología de desarrollo que permita obtener un producto con calidad, escalabilidad y flexibilidad. Los procesos de desarrollo como el Proceso Unificado de Rational (RUP, Racional Unified Process) y el Modelo de Construcción de Soluciones (MCS) están orientados hacia la obtención de prototipos que incrementalmente se van mejorando de acuerdo a las necesidades del cliente. Ofrecen características de flexibilidad y escalabilidad, y utilizan un lenguaje estándar para representación de los elementos de diseño, el Lenguaje Unificado de Modelado (UML, Unified Modelling Languaje).

La importancia de utilizar UML en conjunto con MCS o RUP reside en que se puede obtener un diseño independiente de las tecnologías de implementación, característica que expande la cobertura del MCS más allá de los proyectos de software.

Estas metodologías sirven como un modelo de referencia del cual se pueden extraer los elementos aplicables a cada proyecto, permitiendo proponer un modelo personalizado para el desarrollo de aplicaciones similares.

6.2. Recomendaciones