4 Solución Propuesta
4.5 Extensibilidad
La plataforma ESB Adaptativa consta de tres grandes componentes denominados, ESB Adaptativo, Motor de Adaptación y Monitoreo y Consola de Administración, cada uno de estos componentes se encuentran organizados a su vez en sub-componentes. Este diseño basado en componentes y sub-
- 69 -
componentes permite fácilmente la reutilización de las funcionalidades ya existentes, para el desarrollo de nuevas funcionalidades que den soporte a nuevos requerimientos.
Adicionalmente a lo mencionado, los sub-componentes más importantes de la plataforma cuentan con puntos de extensibilidad nativos, lo que permite un gran nivel de flexibilidad. Estas extensiones pueden ser realizadas mediante el registro de nuevos servicios o funcionalidades, configurando adecuadamente los archivos de configuración pertinentes.
En las siguientes sub-secciones se presentan los principales puntos de extensibilidad con los que cuenta la Plataforma ESB Adaptativa.
4.5.1 Extensibilidad a nivel de componentes
Como se detalla en la Sección 4.5.1, los principales componentes de la plataforma (ESB Adaptativo, Motor de Adaptación y Monitoreo, Consola de Administración) se intercomunican a través de interfaces Java MBeans, lo que posibilita el cambio de los distintos componentes por otras implementaciones, así como también la posibilidad de desplegar cada uno de ellos en diferentes servidores físicos o virtuales. La extensibilidad a nivel de componentes está dada por las distintas interfaces que exponen cada uno de ellos. En la Sección 4.5.3 se describen algunas de las operaciones presentes en la interfaz que expone el componente ESB Adaptativo para su administración.
4.5.2 Extensibilidad a nivel de sub-componentes
La extensibilidad a nivel de sub-componentes está dada mediante la configuración de archivos XML, los cuales registran funcionalidades, que son cargadas en tiempo de despliegue, y que pueden ser actualizadas desde la Consola de Administración en tiempo de ejecución. En particular, los componentes ESB Adaptativo y Motor de Adaptación y Monitoreo, cuentan con archivos de configuración XML que permiten fácilmente definir o extender cada una de sus funcionalidades.
La extensibilidad a nivel de sub-componentes, puede estar dada por clases Java que se instancian en tiempo de ejecución utilizando Reflection16, o mediante archivos de configuración, que pueden especificar por ejemplo, nombres de nuevos servicios y condiciones para sus requerimientos.
En las sub-secciones siguientes se detalla el nivel de extensibilidad del ESB Adaptativo y el Motor de Adaptación y Monitoreo, que son los dos principales componentes de la plataforma.
4.5.2.1 Extensibilidad para los componentes del ESB Adaptativo
Los puntos de extensibilidad y los respectivos archivos de configuración de este componente son los siguientes:
16
- 70 -
Mecanismos de monitoreo: El archivo de configuración jboss-adaptative-monitor-
mechanism.xml permite definir nuevos mecanismos de monitoreo, que posibilitan extender el conjunto de los mecanismos brindados por la plataforma.
Propiedades monitoreadas: En el archivo jboss-adaptative-properties.xml, se localizan las
diferentes propiedades que se monitorean en la plataforma, y es posible agregar nuevas propiedades que permitan abordar nuevos requerimientos.
Requerimientos de servicios: En el archivo jboss-adaptative-service-requirements.xml, se
definen los requerimientos de servicios considerados por la plataforma, permitiendo definir en este archivo nuevos requerimientos que posibilitan extender los ya existentes.
Configuración general: En el archivo jboss-adaptative-config.xml, se pueden modificar
propiedades como: nombre de clase que implementa el comparador de WSDL, directorio donde se localizan los archivos para trasformaciones y directorio donde se guardan los contratos de los servicios registrados en la plataforma, entre otros.
4.5.2.2 Extensibilidad para los componentes del Motor de Adaptación y Monitoreo
Los puntos de extensibilidad y los respectivos archivos de configuración de este componente se detallan a continuación:
Eventos monitoreados: Los eventos que son disparados por la plataforma se definen en el
archivo jboss-adaptative-events.xml, donde se pueden especificar nuevos eventos para que la plataforma los considere, y en base a ellos, genere nuevos requerimientos de adaptación.
Requerimientos de adaptación: En el archivo jboss-adaptative-adaptation-requirements.xml se
pueden definir nuevos requerimientos de adaptación que serán generados por el Motor de Adaptación y Monitoreo, a partir de los eventos que son disparados por la plataforma.
Estrategias de adaptación El archivo jboss-adaptative-strategies.xml permite especificar nuevas
estrategias de adaptación, que posibiliten abordar los distintos requerimientos de adaptación que se generan en la plataforma.
4.5.3 Interfaz de Administración del componente ESB Adaptativo
A modo de ejemplo, la Figura 43 presenta las principales operaciones de la interfaz expuesta por el ESB Adaptativo para la administración de los servicios virtuales. En particular, se detallan las operaciones que permiten obtener los servicios de la plataforma, registrar nuevos servicios y almacenar metadata para un determinado servicio virtual. Esta interfaz es la que hace posible la interacción entre el ESB Adaptativo y los componentes Consola de Administración y Motor de Adaptación y Monitoreo, permitiendo el desacoplamiento de los principales componentes de la plataforma.
- 71 -
Figura 43 - Interfaz EsbAdmServicesMBean.
4.6 Limitaciones y mejoras
En esta sección se presentan las limitaciones y las posibles mejoras que se detectaron en cada uno de los componentes de la plataforma. En general, estas limitaciones y mejoras fueron discutidas en la etapa de diseño, decidiendo dejarlas fuera del alcance del proyecto, dado sus tiempos acotados. En las siguientes sub-secciones se presentan las limitaciones y/o mejoras para cada uno de los grandes componentes de la plataforma, detallando en algunos casos el trabajo adicional que estos implicarían.
Limitaciones y mejoras para el componente ESB Adaptativo
Actualmente, el ESB Adaptativo considera un intervalo de tiempo fijo para la obtención y cálculo de los valores de cada uno de los mecanismos de monitoreo, para posteriormente calcular las propiedades monitoreadas a partir de dichos valores. La naturaleza de estos mecanismos de monitoreo y de las propiedades monitoreadas pueden ser muy diversas, lo cual determina que algunas propiedades sean más sensibles al paso del tiempo y deban tener un intervalo de actualización reducido, así como también existirán otros casos donde el tiempo de procesamiento es elevado, y por tal motivo se deberán configurar intervalos de tiempo más extensos. Por dichos motivos, se concluye que establecer tiempos individuales para los intervalos de cálculo de propiedades y mecanismos, sería una mejora significativa en el ESB Adaptativo.
Actualmente el sistema maneja un único hilo para la ejecución de los mecanismos de monitoreo y el cálculo de las propiedades monitoreadas. El cambio propuesto implica mantener distintos hilos de ejecución para cada uno de los mecanismos, y así poder controlar de forma individual sus intervalos de ejecución.
- 72 -
Limitaciones y mejoras para el componente Motor de Adaptación y Monitoreo
El Motor de Adaptación y Monitoreo encapsula la lógica necesaria para procesar la información que recibe del ESB Adaptativo y evaluar qué estrategia de adaptación se debe utilizar para cada servicio. Una de las mejoras a efectuar en este componente, es la reutilización de esta lógica para dar soporte a múltiples ESB Adaptativos. Implementar esta mejora en el sistema no implica grandes esfuerzos, dado que se cuenta con archivos de configuración, donde se establecen los distintos canales de comunicación utilizados, por lo que solamente se deberá extender esta funcionalidad para poder registrar más de un ESB Adaptativo.
Otra de las opciones detectadas para mejorar este componente está directamente relacionada con la toma de sus decisiones. Actualmente, cuando existe más de una estrategia de adaptación para abordar un determinado requerimiento, el motor toma una decisión aleatoria para escoger cuál estrategia aplicar. La toma de este tipo de decisiones podría mejorarse notoriamente si se considerara información histórica de los servicios, o algún algoritmo de aprendizaje automático como una red neuronal, que detecte patrones comunes en el conjunto de servicios registrados en la plataforma.
Limitaciones y mejoras del componente Consola de Administración
Dado que la Consola de Administración consume los servicios expuestos por el resto de los componentes de la plataforma, toda nueva funcionalidad que se desee incorporar deberá ser primero implementada y expuesta por algún otro componente, para luego consumirla y exponerla de forma gráfica al usuario.
A pesar de que la Consola de Administración permite la recarga en tiempo de ejecución de todos los archivos de configuración, éstos no pueden ser editados desde la interfaz gráfica, lo que es una gran limitante para una administración amigable de la plataforma. La implementación de esta nueva funcionalidad implicaría que cada uno de los componentes exponga en su interfaz, métodos que permitan la edición de cada uno de sus archivos de configuración. Además, la Consola de Administración debería proveer gráficamente una vista que simplifique la edición de las distintas configuraciones. Otro conjunto interesante de funcionalidades para integrar a la Consola de Administración, son las que permitan generar y administrar estadísticas de la plataforma, como por ejemplo almacenar información del servicio con más adaptaciones, la cantidad de estrategias utilizadas para cada servicio, estrategias más eficaces y estrategias más utilizadas, entre otras. Esto permitiría visualizar en distintos gráficos la evolución de las adaptaciones de cada uno de los servicios. Una implementación acotada de estas funcionalidades, es posible con las interfaces que actualmente exponen los distintos componentes, las cuales permiten obtener el histórico de los flujos de adaptación de los servicios. Por lo tanto, solo restaría implementar en la consola, aquellas funcionalidades que permitan obtener, almacenar y desplegar la información.
- 73 -
5 Detalles de Implementación
En esta sección se presenta detalladamente la implementación de los componentes más relevantes de la plataforma, describiendo también aquellos componentes que pueden ser reutilizados en otros proyectos que utilicen JBoss ESB. Además, se comentan los principales problemas encontrados durante la implementación de la Plataforma ESB Adaptativa.
5.1 Mecanismos de Adaptación
Los mecanismos de adaptación implementados en la plataforma base son los descriptos en la Sección 4.3.2, los cuales se encargan de realizar las acciones de adaptación en el ESB.
Específicamente, se implementaron mecanismos de adaptación que obtienen dinámicamente la información del itinerario de cada mensaje, y se basan fuertemente en los mecanismos de adaptación provistos por JBoss ESB. En la Tabla 14 se presentan cada uno de los mecanismos de adaptación implementados, describiendo para cada uno de ellos, la acción del producto en la cual se basa.
Mecanismo Acción JBoss ESB Acción Personalizada
Transformación org.jboss.soa.esb.actions.transformation.xslt. XsltAction
org.fing.edu.uy.esbadp.action.transform. TranformAction
Ruteo org.jboss.soa.esb.actions.StaticRouter org.fing.edu.uy.esbadp.action.routing. RoutingAction
Invocación Servicio
Virtual org.jboss.soa.esb.actions.SyncServiceInvoker org.fing.edu.uy.esbadp.action.sync. SyncAction
Lista de
Destinatarios org.jboss.soa.esb.client. ServiceInvoker org.fing.edu.uy.esbadp.action.list. ListAction
Balanceo org.jboss.soa.esb.client. ServiceInvoker y org.jboss.soa.esb.actions.StaticRouter
org.fing.edu.uy.esbadp.action.randomBalance. RandomBalanceAction
Unificador org.jboss.soa.esb.actions. Aggregator org.fing.edu.uy.esbadp.action.aggregator. Aggregator
Cache No existe acción en JBoss ESB org.fing.edu.uy.esbadp.action.cache. CacheLoadAction
Retardador No existe acción en JBoss ESB org.fing.edu.uy.esbadp.action.delayer. DelayerAction
Tabla 14 - Acciones base de JBoss ESB.
En algunos de los mecanismos implementados, el trabajo consistió en tomar el código fuente de las acciones brindadas por JBoss ESB, y a partir del mismo crear nuevas acciones que permitan obtener las propiedades de cada mecanismo desde el itinerario del mensaje, y no de la especificación del servicio definido en el archivo jboss-esb.xml, tal como lo realizan la acciones nativas del producto.
En cuanto a la implementación de los mecanismos lista de destinatarios y unificador de respuestas, se realizaron implementaciones particulares. Para la lista de destinatarios, se realizan copias del mensaje original, para luego distribuir cada una de esas copias al servicio correspondiente, agregándole a cada
- 74 -
una de ellas un identificador único. Este identificador será utilizado posteriormente por el unificador de respuestas, para determinar a qué mensaje pertenece una determinada respuesta. Con respecto al envió de los mensajes, éstos se realizan utilizando la funcionalidad deliverAsync, brindada por el componente Service Invoker de JBoss. En cuanto al unificador de respuestas, se realizan personalizaciones para que esta acción retorne la primera respuesta obtenida para un identificador dado, y descarte el resto. Esta implementación se basó fuertemente en la acción Aggregator de JBoss ESB.
Por otra parte, la implementación del balanceador de carga se basa fuertemente en la cantidad de servicios a los que puede enviar una solicitud, y en base a dicha cantidad selecciona uno de forma aleatoria, para que posteriormente el itinerario dirija el mensaje hacia el servicio seleccionado.
Finalmente, la implementación de los mecanismos de adaptación cache e itinerario se describen con detenimiento en la Sección 5.9.
5.2 Mecanismos de Monitoreo
Como se mencionó en la Sección 0, la Plataforma ESB Adaptativa monitorea la información de las invocaciones a los servicios virtuales y la de los contratos de los Web Services externos. Con respecto al monitoreo de invocaciones a servicios virtuales, JBoss ESB registra diversa información para cada uno de ellos, como por ejemplo el tiempo de respuesta y el éxito de sus invocaciones, entre otros. Esta información es utilizada posteriormente por los mecanismos que monitorean las invocaciones a los servicios virtuales para calcular los valores monitoreados. Por otra parte, el monitoreo de los contratos de los servicios se encarga de detectar cambios en los WSDLs de los servicios externos, los cuales son accedidos por los servicios virtuales registrados en la plataforma.
5.2.1 Mecanismos de monitoreo de invocaciones a Servicios Virtuales
Estos mecanismos de monitoreo contribuyen a la detección de eventos monitoreados por parte de la plataforma, como lo son: la degradación del tiempo de respuesta, la degradación de respuestas exitosas y la saturación de los servicios. A continuación, se describe la implementación de aquellos mecanismos de monitoreo que obtienen información acerca de los servicios virtuales.
Monitoreo de invocaciones exitosas
JBoss ESB monitorea la cantidad de invocaciones exitosas de cada uno de sus servicios y expone ésta información a través de Java MBeans, que pueden ser accedidos desde cualquier cliente que soporte el protocolo de mensajería JMX. Concretamente, este mecanismo de monitoreo obtiene su información desde el MBean MessageCounter, el cual posee un atributo denominado “messages successfully processed count”, que retorna la cantidad de invocaciones exitosas para un servicio virtual.
Monitoreo de invocaciones con fallas
JBoss ESB monitorea de forma nativa la cantidad de fallas que produce cada uno de sus servicios, y expone esta información a través de Java MBeans. En particular, la implementación de este mecanismo,
- 75 -
obtiene su información del atributo “messages failed count” brindado por el MBean MessageCounter de JBoss ESB.
Monitoreo del tiempo de respuesta
JBoss ESB expone de forma nativa, información del tiempo de respuesta de cada uno de sus servicios. Al igual que en los mecanismos anteriores, la información de este mecanismo es obtenida a partir del atributo “overall service time processed” del MBean MessageCounter.
Como se describe anteriormente, todos los mecanismos de monitoreo de servicios virtuales utilizan los atributos brindados por el MBean MessageCounter, lo cual permitió implementar fácilmente estos mecanismos, sin tener la necesidad de crear nuevos servicios que recaben información de cada servicio virtual.
5.2.2 Mecanismo de monitoreo de contratos de Web Services externos
Este mecanismo de monitoreo permite detectar cambios en los contratos de los servicios externos, y por lo tanto, puede contribuir a generar requerimientos de adaptación para manejar los distintos cambios que se producen en los contratos de los servicios.
En cuanto a la implementación, este mecanismo no consume ninguna de las funcionalidades brindadas por JBoss ESB, ya que el producto no realiza ningún tipo de seguimiento sobre los contratos de los servicios a los que accede. Sin embargo, la implementación de esta funcionalidad se basó en la idea presentada en [22], donde se desarrolló una herramienta capaz de comparar documentos WSDL. En particular, la implementación realizada utiliza las funcionalidades brindadas por la biblioteca EasyWSDL [23], que permite manipular fácilmente los documentos WSDL, tanto para las publicaciones DOCUMENT17 como para las RPC.
Cuando el Administrador de Monitoreo invoca a este mecanismo para que chequee el contrato de un servicio, éste se encarga de examinar si existe almacenada en la plataforma alguna versión del WSDL de dicho servicio, para posteriormente proseguir a la comparación de los WSDLs. De no existir una versión previa del WSDL, el mecanismo se encarga de almacenarla en la plataforma y comunicarle al administrador que no existen cambios en el contrato del servicio. En caso que exista un documento previo y el mecanismo detecte algún tipo de diferencia, éste actualiza el contenido del documento WSDL almacenado en la plataforma y le retorna al administrador las diferencias detectadas.
La Figura 44 presenta cómo este mecanismo almacena los contratos de los servicios en la plataforma. Para cada uno de los WSDL de los servicios externos, se genera un archivo XML con el identificador del servicio virtual que lo accede, además de los esquemas auxiliares que utiliza el propio documento WSDL.
17
- 76 -
Figura 44 - Estructura para el almacenamiento de los contratos de los servicios.
Cabe mencionar, que para soportar el tipo de publicación DOCUMENT y RPC se debieron crear dos versiones del comparador, ya que la forma en que éstos organizan la información es muy diferente. La Tabla 15 detalla el comportamiento de este mecanismo frente a los distintos cambios que pueden ocurrir en el contrato de un servicio.
Cambio Observaciones
Agregar operación. Soportado. No afecta comportamiento.
Renombrar operación.
Solamente se detecta este cambio si los parámetros de entrada y de salida de la nueva operación y de la antigua son idénticos, tanto en sus nombres como en sus tipos de datos. Cabe aclarar, que también se valida que la antigua operación no siga existiendo en el nuevo WSDL, ya que en este caso el sistema interpretará que existe una nueva operación en el contrato del servicio.
Quitar operación. No soportado. No es posible manejarlo.
Modificar MEP de operación. No soportado.
Agregar Parámetro.
Soportado siempre y cuando el nuevo parámetro admita un valor por defecto. El sistema interpretará la existencia de un nuevo parámetro, cuando no se elimine un parámetro y se agregue otro con el mismo tipo de dato y en la misma posición.
Renombrar Parámetro.
Soportado. El sistema interpretará un renombre de parámetro cuando en el nuevo WSDL exista un parámetro que no existía en el WSDL antiguo, y además sus tipos de los datos y sus posiciones en ambos WSDL sean iguales.
Cambiar Opcionalidad Parámetro. No soportado.
Cambiar Orden Parámetros. No soportado.
Quitar Parámetro. Soportado.
Tabla 15 - Cambios en los contratos de los servicios soportados por la plataforma.
La información recabada por este mecanismo es utilizada por la estrategia encargada de manejar los cambios de contrato de los servicios, que a partir de dicha información genera transformaciones XSLT, permitiendo seguir invocando a un servicio que sufrió cambios en su contrato.
- 77 -
5.3 Administrador de Monitoreo
Como se menciona en la Sección 0, este componente se encarga de calcular el valor de las distintas propiedades a partir de los valores obtenidos por los mecanismos de monitoreo.
El Administrador de Monitoreo permanece dormido por cierto período de tiempo (configurable), y cada vez que ejecuta, procesa los mecanismos monitoreados para cada uno de los servicios registrados, los