Enterprise Service Bus

Transcripción

1 Enterprise Service Bus Ingeniería Informática 5º Curso Sistemas Distribuidos Víctor Cabrera Cañizares

2 ESB (Enterprise Service Bus) También conocido como message broker. ESB es un estándar abierto basado en mensajería síncrona o asíncrona como elemento middleware, que proporciona interoperabilidad segura entre aplicaciones de empresa por medio de XML, interfaces de Servicios Web y reglas de enrutamiento estandarizado de documentos. En la práctica esto significa que los ficheros de datos son transferidos hacía y desde sus destinatarios basados en directrices preestablecidas que son comunes a todos los grupos que comparten la información, para asegurar que los datos se mantienen tal y como son enrutados. El diseño multilenguaje y multiplataforma de un ESB permite a las empresas procesar datos entre aplicaciones de varias fuentes. Dos arquitecturas distribuidas de computación comunes usadas por ESB son J2EE y.net. Es la plataforma que brinda los servicios de enrutamiento y transformación de mensajería para la arquitectura SOA basado en XML. ESB tiene diversas funciones clave: - Transformación: La capacidad de transformar documentos XML, de un formato de datos a otro de modo que el grupo receptor pueda hacer uso de la interfaz con los datos en un formato de aplicación que es diferente del que se envió. - Portabilidad: La capacidad de compartir los datos entre diferentes sistemas y entornos de operación. - Balanceo de carga / agrupamiento (Load balancing/clustering): La capacidad de distribuir procesamiento entre varios dispositivos para que ninguno se sobrecargue. - Failover: La capacidad para transferir funciones de mensajería hacia otro servidor si falla uno de ellos durante el intercambio de datos. 2

3 Implementaciones Open Source ESB MULE Mule es una plataforma de mensajería basado en arquitecturas ESB. El núcleo de Mule está basado en el servicio contenedor SEDA, que gestiona servicio de objetos, conocido como Universal Message Objects (UMOs), que son simples objetos Java. Todas las comunicaciones entre UMOs y otras aplicaciones son realizadas a través de mensajes endpoints. Estos endpoints proporcionan un simple y consistente interfaz para tecnologías tan dispares como JSM, SMTP, JDBC, TCP, HTTP, XMPP, ficheros, etc. Visión general de la arquitectura La meta última de Mule es proporcionar un método unificado de interactividad con datos de fuentes dispares, sin estorbar al desarrollador con detalles sobre cómo los datos son enviados o recibidos o protocolos implicados. El resultado es un servidor ESB, que es altamente escalable, light-weight, rápido y simple. La arquitectura de Mule fue diseñada con el modelo ESB en mente y el primer enfoque es simplificar y acelerar el proceso de desarrollo de redes de servicios distribuidos. Sin embargo, como su nombre sugiere, el modelo ESB usualmente se asocia con proyectos importantes de integración donde hay un conjunto de aplicaciones de empresa dispares. Mule crea arquitecturas de servicios de nivel de empresa, posible para proyectos más pequeños donde recursos, coste de desarrollo y TTM necesitan un mínimo de manenimiento. El objetivo primero es posibilitar la integración entre aplicaciones estándares, protocolos abiertos y diseños bien definidos. Para alcanzar este objetivo Mule define un conjunto de componentes que pueden ser usados para realizar la mayor parte del duro trabajo necesario para conseguir aunar aplicaciones dispares y comunicación de servicios. Este diagrama muestra una topología end-to-end simple de cómo se encajan los componentes Mule. 3

4 El canal puede tener cualquier método de comunicación de datos entre dos puntos. Los canales se emplean en Mule para conectar componentes UMO así como para conectar diferentes Mule Nodes a través de red local o internet. El recibidor de mensajes se usa para leer o recibir datos desde la aplicación. En Mule un recibidor es un elemento de un Transport provider y Mule proporciona muchos transportes, como JMS, SOAP, HTTP, TCP, XMPP, SMTP, file, etc. Mucha de la magia de Mule está en la capacidad para comunicar sistemas dispares sin su lógica de negocio (componentes UMO) nunca necesario para conocer la localización del sistema, el formato de los datos, el mecanismo de reparto o protocolos. Asimismo, cuando el componente UMO ha hecho su trabajo no necesita preocuparse de dónde van después los datos o en qué formato se esperan. El conector entiende cómo enviar y recibir datos sobre un canal particular. Un recibidor de mensajes se une con un conector para registrar datos de interés procedentes de una fuente que entiende el conector. El transformador se usa para transformar mensajes o cuerpos de eventos hacia y desde diferentes tipos. Mule no define un formato de mensaje estándar (aunque Mule puede soportar en el futuro un estándar de tipos de mensajes de definición de procesos de negocio). La transformación proporcionada hacia fuera del transformador es un tipo de transformación como Mensajes JMS-a-Objetos y transformadores XML estándares. La transformación de datos es muy subjetiva a la aplicación y Mule provee un simple y poderoso framework de transformación. El inbound router se puede usar para controlar cómo y qué eventos son recibidos por un componente suscribiéndose en un canal. Los inbound routers se emplean para filtrar, dividir un conjunto y reordenar la secuencia de eventos antes de que los reciba el componente UMO. Un endpoint es en realidad una configuración envoltorio que liga un conector, URI endpoint, transformadores, filtros e información transaccional para proporcionar un adaptador de canal (Channel Adapter). El proveedor también guarda información transaccional para la instancia proveedora. El adaptador actúa como un cliente de mensajería para el sistema de mensajería e invoca funciones de aplicación a través de una interfaz de application-supplied (aplicación suministrada). Asimismo, el adaptador de canal puede escuchar un evento de una aplicación interna e invocar al sistema de mensajería en respuesta a este evento. Los endpoints son fundamentales para la capacidad de comunicación de Mule. Un endpoint define el canal de comunicación entre dos o más componentes, aplicaciones o repositorios. Ellos proporcionan un modo potente de permitir a los objetos hablar sobre cualquier protocolo de un modo único.un endpoint puede ser configurado con filtros de mensaje, interceptores de seguridad e información de transacciones para controlar quién, qué y cómo son enviados o recibidos los mensajes por medio de los endpoints. Una vez 4

5 ha sido procesada la orden por el componente, un mensaje JMS puede enviarse sobre un asunto para notificar que el sistema está escuchando y responde sobre HTTP. Los endpoints son usados para conectar componentes en el servidor y sistemas externos o a otros localmente o sobre la red. El outbound router se usa para publicar mensajes/eventos para diferentes proveedores, dependiendo de diferentes aspectos de eventos u otras reglas definidas en la configuración. Las aplicaciones Mule constan usualmente de muchas instancias Mule a través de la red. Cada instancia es un contenedor light-weight que hospeda uno o más componentes UMO. Cada componente UMO tendrá uno o más endpoints que enviarán y recibirán eventos. El contenedor proporciona un rango de servicios para componentes UMO tal como gestión de transacciones, transformación de eventos, enrutado, correlación de eventos, logging, auditoría y gestión. Que la construcción de objetos Mule esté separado de la gestión implica que los populares contenedores IoC/DI, tal como Spring, PicoContainer o Plexus, pueden usarse para construir componentes UMO. El siguiente diagrama muestra una descomposición simplificada de los componentes de un servidor Mule. 5

6 Estudiaremos cada parte del diagrama para alcanzar una mayor comprensión del funcionamiento de Mule. Mule Manager Mule Manager es la parte central de una instancia servidor Mule (también conocido como Nodo o Nodo Mule). Su primer papel es gestionar los objetos tales como conectores, endpoints y transformadores para una instancia Mule. Estos objetos son empleados para controlar flujos de mensaje hacia y desde los servicios/componentes y proporciona servicios al Mule Model y los componentes que maneja. 6

7 Mule Model Model es el contenedor en el que los componentes son gestionados y ejecutados. También controla el flujo de mensajes hacia y desde los componentes, maneja hilos, ciclo de vida y pooling. El Mule Model por defecto está basado en SEDA, por lo que usa un modelo eficiente de encolamiento basado en eventos para maximizar el rendimiento y el ancho de banda. El Mule Model encapsula y controla el comportamiento de una instancia de servidor Mule en tiempo de ejecución. Es responsable del mantenimiento de las instancias UMO y su configuración. La intefaz org.mule.umo.model.umoentrypointresolver define a la parte llamada EntryPointResolver, que se usa para determinar qué método invocar en un componente UMO cuando se recibe un evento. Hay un ExtendedEntryPointResolver que se usa si no hay otro configurado en el modelo. El ExtendedEntryPointResolver proporciona resolución del punto de entrada para uso común, los pasos que toma son: 1. Controla si el componente implementa el interfaz Callable, entonces el método oncall (evento UMO) se usará para recibir eventos. 2. Si el componente tiene un transformador configurado para esto, el tipo devuelto por el transformador será comprobado con los métodos en el componente para ver si hay un método que acepte el tipo devuelto por el transformador. 3. Si hay un método en el componente que acepte un org.mule.umo.umoevent se usará. Observar que si hay más de una coincidencia se puede lanzar una excepción. 4. La última comprobación determina si hay algún método en el componenete qu acepte java.util.event. Si es así se usa. Igualmente, si hay más de una coincidencia se lanzará una excepción. 5. Si no se encuentra ninguna coincidencia se lanzará una excepción y el registro del componente fallará. Naturalmente hay muchos escenarios donde el ExtendedEntryPointResolver es apropiado. Por ejemplo, se estás migrando desde otro framework puedes querer restringir o cambiar el modo en que un punto de entrada se resuelve. El adaptador del ciclo de vida (Lifecycle adapter) está definido por la interfaz org.mule.umo.umolifecycleadapter, y es responsable de mapear el ciclo de vida de los componentes Mule. The DefaultLifecycleAdapter simplemente delega eventos del ciclo de vida a componentes donde se implementan cero o más interfaces de ciclo de vida UMO. Evidentemente, esto no es apropiado para los componentes existentes que se quieran manejar con Mule, lo más probable es que ellos tengan sus propios métodos de 7

8 ciclo de vida que necesitarán ser invocados en el framework Mule. Por suerte, org.mule.umo.lifecycle.lifecycleadapater es muy sencillo de implementar. Los adaptadores de ciclo de vida son configurados usando una implementación de org.mule.umo.lifecycle.umolifecycleadapterfactory. La factoría está declarada en la configuración del modelo. Una por defecto es DefaultLifecycleAdapterFactory. Proveedor de transporte Un proveedor de transporte (Transport provider) es un plugin Mule que permite que componentes Mule envíen y reciban información sobre un protocolo particular, repositorio de mensajes u otra tecnología. A continuación se describe su arquitectura. El conector proporciona la implementación para conectar con sistemas externos. El conector es responsable de enviar datos al recibidor externo y manejar un listener para recibir datos de un sistema externo. Por ejemplo, un conector HTTP crea una conexión HTTP y envía el payload sobre la conexión y devolverá un evento UMO con el estado devuelto (si se está ejecutando síncronamente). Los recibidores del conector HTTP son objetos que recibirán avisos cuando se reciba algo en el puerto servidor HTTP. Un conector tiene dos objetos responsables de enviar y recibir enventos: Recibidor de mensajes Usado para escuchar en un endpoint en la tecnología subyacente. El recibidor es usualmente bastante simple con toda la configuración realizada en el conector y el recibidor es sólo un hilo escuchando. Repartidor de mensajes Se usa para enviar eventos en la tecnología subyacente. El repartidor de mensajes puede funcionar con un pool de hilos que puede usarse para repartir eventos o realizar una recepción sobre la tecnología subyacente para recuperar un evento, si lo hay. El interfaz UMOMessageDispatcher define tres métodos importantes: 8

9 o o o dispatch() envía datos a un sistema externo asíncronamente send() envía datos a un sistema externo síncronamente y devuelve una respuesta como un evento UMO. recieve() hará peticiones de eventos desde la tecnología subyacente y devolverá el resultado. Este método tiene un parámetro de timeout. Los conectores son responsables de controlar sesiones de la tecnología subyacente, por ejemplo, el JmsConnector proporciona una sesión Jms para el recibidor de mensajes del conector y para el repartidor de mensajes para publicar o enviar eventos sobre JMS. Un endpoint se define por una dirección (endpoint address), y ésta define cualquier forma de destino o fuente de datos y está siempre expresada como una URI. Ejemplos de endpoints podrían ser: transport Description Example normalmente username POP3/SMTP password y un hostname pop3://user:password@mail.mycompany.com JMS Un nombre de un topic o queue jms://topic:mytopic HTTP Un host y posiblemente un puerto, path y query string File VM SOAP El path de un file:///tmp/data/in directorio o fichero El nombre de otro componente UMO vm://myumo ejecutándose en el mismo VM La localización de un componente UMO expuesto como un Axis: servicio o una localización de servicio a invocar Las direcciones endpoint son siempre expresadas como URIs válidas con el protocolo del conector. Los proveedores de transporte Mule tienen constructores endpoint conectables que permiten a los desarrolladores personalizar el modo en que un endpoint es leído por Mule. Aquí se describe el proceso empleado en Mule para resolver una URI endpoint. Para este ejemplo usaremos la siguiente URI jms://topic:mytopic?durable=true. 9

10 1. La ConnectorFactory es invocada con la URI. 2. Buscará en META-INF/services/org/mule/providers un descriptor de servicio que coincida con jms. 3. Para esto se crea un objeto ConnectorServiceDescriptor. 4. Se puede especificar en la URI si bien crear un nuevo conector para la URI o bien usar una conexión existente. Cuando no hay señales de una conexión existente se buscará una basada en el protocolo. 5. El ConnectorServiceDescriptor contiene el constructor de endpoint a usar y el endpoint se pasa al constructor de endpoint. 6. Esto es entonces hasta el constructor de endpoint para descomponer la URI en partes acorde con la especificación URI. Los recibidores de mensajes (Message Receivers) o message listeners son responsables de recibir datos desde sistemas externos. La responsabilidad del conector es controlar el registro y baja de los recibidores. La complejidad del recibidor de mensajes variará dependiendo del sistema externo usado. Por ejemplo, el recibidor de mensajes para el proveedor JMS simplemente implementa el javax.jms.messagelistener y el conector JMS registra el listener con esta conexión JMS. Sin embargo, el recibidor de mensajes HTTP implementa un servidor HTTP que escucha en un puerto específico para peticiones de llegada. Los adaptadores de mensajes (Message Adapters) se requieren para leer de un modo común objetos de datos dispares en el formato que son recibidos desde la aplicación externa. El interfaz UMOMessageAdapter especifica un pequeño conjunto de métodos necesarios para leer el payload y las propiedades del cualquier objeto java. Los adaptadores de mensajes son específicos de un conector; cuando un conector recibe datos, un adaptador de mensaje también es necesario para traducir esos datos de un tipo concreto usado por el conector en un array de bytes o en un string. Las transacciones son controladas por el proveedor; Las transacciones se inician o perpetran cuando un recibidor de mensajes recibe un mensaje o un repatidor de mensajes envía un mensaje. Algo principal de las transacciones Mule es el TransactionCoordinator, que es responsable del mantenimiento del estado de la transacción. Para que Mule trate igual todas las transacciones hay una pequeña API que los proveedores deben definir. 10

11 org.mule.umo.umotransaction Un envoltorio en torno a la transacción subyacente. Algunos sistemas no definen explícitamente un objeto transacción, en cambio, la demarcación de la transacción puede alcanzarse con la llamada a métodos en una conexión o sesión. La API UMOTransaction define un conjunto de métodos que pueden usarse para examinar cualquier recurso transaccional. org.mule.umo.umotransactionfactory Una factoría usada para crear una implementación de UMOTransaction. Vamos a hablar ahora de los contextos de un contenedor (Container contexts). El componente resolver es la puerta para usar un framework contenedor externo, que controlaría la instanciación y configuración de los componentes UMO o sus objetos dependientes. Mule no proporciona su propio contenedor de componentes, ya que hay una riqueza de muy buenos contenedores IoC que están testeados. En cambio, Mule proporciona algún Component Resolver por defecto, como Spring Component Resolver y Pico Component Resolver. Spring se puede integrar en Mule en distintos niveles. Se puede usar Spring como una factoría de componentes, se puede configurar un servidor Mule desde un contexto Spring, se puede configurar un contexto de Spring usando XML Mule, etc. Para usar un componente de un contenedor externo como tu componente UMO simplemente configura el ComponentResolver deseado en el modelo, y cuando se define el descriptor Mule en el fichero de configuración, establece el atributo implementación al componente clave (o clase en el case de contenedor Pico) en el contenedor. Si la configuración no especifica un Component Resolver se usa el MuleComponentResolver. Esta implementación espera un nombre de clase para instanciar, en lugar de una clave del componente con la que resolver el componente. Esto se comporta del mismo modo que una implementación real exceptuando que no soporta búsqueda de componentes en un contenedor. Para implementar un ComponentResolver personalizado se necesita implementar dos interfaces: org.mule.umo.model.umocomponentresover Esta hace la resolución real de componentes en el contenedor. org.mule.umo.model.umocontainercontext Esta es responsable de crear e inicializar el contenedor. El Component Resolver preguntará al framework externo a través de este contexto. Componentes UMO Lo principal de la arquitectura Mule son componentes autónomos simples que pueden interactuar con la existencia vinculada a la fuente, transporte o entrega de datos. Estos componentes se llaman componentes UMO y se pueden organizar para trabajar con otro 11

12 de varias maneras. Estos componentes puedes configurarse para aceptar datos de un número diferente de fuentes y puede enviar datos de vuelta a estas fuentes. La implementación UMO real espececíficada referencia a un objeto. Este objeto puede ser cualquiera, un JavaBean o un componente de otro framework. Éste es tu código cliente que hace algo con los eventos recibidos. Mule no hace sitio para ninguna restricción en tus objetos excepto que si se configura con Mule directamente, debe tener un constructor por defecto (si se configura vía Spring o Pico, Mule no impone convenciones en los objetos que se manejan). Obviamente, con esta clase de flexibilidad, Mule necesita saber un poco más sobre los objetos. Éste es el trabajo de dos capas externas enseñadas para controlar cómo lo eventos son utilizados por tus objetos. El adaptador de ciclo de vida es usado por el Mule Model para disparar métodos de ciclo de vida en tus objetos (si existen). Los ciclos de vida personalizados pueden ser introducidos en la base del modelo permitiendo diferentes modelos para manejar el ciclo de vida de sus componentes de diferentes modos. Mule define un ciclo de vida por defecto para los componentes que maneja. Los componentes puede participar en ningún, alguno o todos estos eventos de ciclos de vida por medio de la implementación de los interfaces de ciclo de vida requeridas. El ciclo de vida es el siguiente: 12

13 Los componentes manejados por Mule no necesitan seguir el ciclo de vida definido por Mule. Usando el DefaultLifecycleAdapter un componente puede implementar cualquier de las interfaces de ciclo de vida. Los transformadores (Transformers) son usados para convertir datos de la fuente a un objeto del tipo requerido por el componente UMO. Los transformadores pueden configurarse en endpoints que reciben datos para asegurar que el tipo de objeto esperado se reciba siempre por un componente UMO. Los transformadores configurados en un outbound endpoint aseguran que un endpoint reciba el tipo de objeto correcto antes de enviar el evento. Los transformadores múltiples pueden ser encadenados para permitir mejores implementaciones de transformadores que son más fáciles de reutilizar. Para configurar un endpoint que se use en más de un transformador, se especifica un espacio separado para una lista de transformadores en el fichero de configuración o encadenar los transformadores usando el método settransformer() en el transformador. Por ejemplo, un transformador inbound puede parecerse a esto: Y un transformador outbound puede parecerse a esto: 13

14 Todo transformador Mule debe implementar org.mule.transformer.umotransformer. Hay una implementación de transformador abstracta que define métodos para el control de tipos de objetos, este transformador soporta y valida el tipo de retorno esperado, dejando al desarrollador para implementar un simple método transform(). También está el EntryPointResolver, que se usa por el Mule Model cuando el componente UMO es registrado, para encontrar el método a llamar en el objeto cuando se recibe un evento para ello. Si un método no se encuentra se lanzará una excepción. Eventos Mule es una arquitectura basada en eventos, esto es, acciones sin una red Mule son disparadas por otros eventos ocurridos en Mule o en sistemas externos. Los eventos siempre contienen cosas como datos, el payload, que será usado y/o manipulado por uno o más componentes y un conjunto de propiedades que están asociados al procesado del evento. Estas propiedades son arbitrarias y puede establecerse en cualquier momento en que se cree el evento. Los datos del evento pueden ser accedidos en su estado original o en su estado transformado. El evento usará el transformador asociado con el Endpoint que recibe el evento, y transforma su payload en un formato que el componente recibidor comprende. En el procesamiento de eventos Mule puede enviar y recibir eventos usando tres modelos: 1. Asíncronamente Muchos eventos puede procesarse por el mismo componente a la vez en hilos diferentes. Cuando el servidor Mule está ejecutando asíncronamente instancias de un componente en diferentes hilos, todos aceptan eventos de entrada, aunque el evento sólo será procesado por una instancia del componente. 2. Síncronamente Cuando un componente UMO recibe un evento en este modo toda la petición es ejecutada en un simple hilo. 3. Petición-Respuesta Éste permite a un componente UMO hacer una petición específica de un evento y esperar un tiempo determinado para conseguir la respuesta. Se puede controlar el sincronismo del procesamiento de eventos fijando la propiedad síncrono en el endpoint (o de forma programática en el evento). El sincronismo de la llamada puede ser propagado a lo largo de la red donde aquellos transportes que estén siendo usados soporten un canal de respuesta. Por ejemplo, una petición síncrona JMS 14

15 establecerá una cola de respuestas temporal cuando se haga una petición y esperará una respuesta en esa cola. Lo mismo puede aplicarse a transporte basado en sockets. El flujo real del evento es gobernado por la propiedad síncrona, si el endpoint está dentro de los límites o fuera de ellos y si hay una transacción en progreso. Se aplican las siguientes reglas. El procesado de enventos asíncronos ocurre cuando el flag endpoint inbound está a false. Asynchronous inbound and outbound En este esceranio el mensaje se envía a una cola y se consume por el hilo worker en un pool que en realidad ejecuta el trabajo del componente UMO. El endpoint outbound es también asíncrono. El outbound enpoint también es asíncrono y el mensaje resultante será despachado por un hilo despachador. Asynchronous inbound, synchronous outbound En este escenario el mensaje se envía a una cola y se consume por el hilo worker en un pool que realiza la ejecución real del componente UMO. El endpoint outbound es síncrono, por lo que el envío sucede en el mismo hilo que el de la ejecución del componente. Este escenario lo usa la transacción outbound de tal suerte que todos los repartidores del componente ocurren en el mismo hilo. Este comportamiento es manejado automáticamente por Mule. 15

16 Synchronous inbound only Un evento se recibe y procesa por el componente UMO en el mismo hilo y cualquier resultado devuelto por el componente UMO lo cogerá el recibidor donde, si hay un canal de respuesta, un resultado será enviado. Synchronous inbound and outbound Un evento se recibe y procesa en el mismo hilo. El outbound dispatch también se ejecuta en el mismo hilo del recibidor. Aquí si el transporte del outbound endpoint se usa para soportar un canal de respuesta con sockets o JMS, una respuesta será interceptada desde el dispatch (o saltará un timeout) y aquella respuesta será pasada de nuevo al recibidor cuando si hay un canal de respuesta, por ejemplo, Socket outputstream se enviará un resultado. Synchronous inbound and outbound with transaction Las transacciones sólo pueden ser (actualmente) manejadas sobre endpoints síncronos. Así si un endpoint ha sido configurado por transacciones éste será automáticamente síncrono. Cuando se está dispatching y una transacción está en progreso el dispatch también correrá en el mismo hilo. 16

17 Enrutadores de mensajes Los enrutadores de mensajes son usados para controlar cómo los eventos son enviados y recibidos por componentes en el sistema. Mule define Inbound routers que se aplican a los eventos cuando son recibidos y que son invocados cuando un evento está siendo enviado. Los inbound routers pueden usarse para controlar y manipular eventos recibidos por un componente. Típicamente, un inbound router puede usarse para filtrar enventos de llegada o un conjunto de eventos de llegada. Se puede encadenar inbound routers, en este escenario cada router se liga antes de que el evento sea enviado al componente Mule. Se puede especificar una estrategia match-all que será invocada si algún router no acepta el evento actual. Un inbound router puede configurarse en un elemento descriptor de Mule en el fichero config.xml. <inbound-router> <catch-all-strategy classname="org.mule.tck.testmodels.mule.testcatchallstrategy"/> <router classname="org.mule.routing.inbound.selectiveconsumer"> <filter expectedtype="java.lang.string" classname="org.mule.routing.filters.payloadtypefilter"/> </router> <router classname="org.mule.routing.inbound.aggregator"> </router> </inbound-router> Si no hay requerimientos de procesamiento especiales para los mensajes recibidos por un componente, no hay necesidad de configurar un inbound router. Los outbound routers se usan para controlar que proveedores se usan para enviar eventos una vez que ha finalizado el procesamiento de un componente UMO. Los routers de mensajes son configurados en el componente UMO y permite al desarrollador definir restricciones para enrutamiento múltiple para un evento determinado. Se puede especificar una estrategia catch-all que será invocada si ninguno de los routers acepta el evento actual. Un ejemplo de un outbound message router es el siguiente. <outbound-router> <catch-all-strategy classname="org.mulerouting.forwardingcatchallstrategy" provider="catchall"/> <router providers="testapple-out" classname="org.mule.routing.outbound.filteringoutboundrouter"> <filter expectedtype="java.lang.string" classname="org.mule.routing.filters.payloadtypefilter"/> </router> <router providers="watermelonprovider" classname="org.mule.routing.outbound.filteringoutboundrouter"> <filter classname="org.mule.routing.filters.logic.andfilter"> <left-filter pattern="the quick brown (.*)" classname="org.mule.routing.filters.regexfilter"/> <right-filter pattern="(.*) brown (.*)" 17

18 classname="org.mule.routing.filters.regexfilter"/> </filter> </router> </outbound-router> La estrategia catch-all recibe el evento si ningún router lo acepta. La estrategia debe implementarse en org.mule.umo.rounting.umoroutingcatchallstrategy que defina un método: public void catchmessage(umomessagemessage, UMOSessionsession, boolean synchronous) throws RoutingException; Notar que este método void, que no devuelve evento puede pasarse de nuevo al código de llamada. Esto es importante cuando se está ejecutando síncronamente así como cuando la cadena de eventos síncrona se rompe. Esto se considera una condición de error cuando un estrategia catch-all es invocada. Interceptores Los interceptores Mule son útiles para adjuntar comportamiento común a múltiples UMOs. El interceptor o el modelo de órdenes son frecuentemente eliminados como un práctico AOP (Aspect Oriented Programming), como esto permite al desarrollador interceptar el procesamiento en un objeto y potencialmente cambiar el procesamiento y el resultado. Los interceptores son muy útiles para adjutar perfiles, permiso, inspecciones de seguridad, etc, a un componente en Mule. Mule tiene dos tipos de interceptores: 1. org.mule.interceptors.envelopedinterceptor Sobre filtros que se ejecutarán antes y después de que el evento sea procesado. Bueno para logging y profiling. 2. org.mule.umo.umointerceptor Simplemente se invoca y entonces reenvía el procesamiento al próximo elemento. Un interceptor puede detener el procesamiento si no reenvía el control al siguiente interceptor, por ejemplo los comprobadores de permisos del interceptor. A continuaciónse muestra una pila de interceptor típica y el flujo del evento. 18

19 Aplicaciones externas Las aplicaciones externas pueden ser cualquiera, desde aplicaciones de servidores hasta sistemas de nómina heredados, hasta grandes aplicaciones de comercio o una aplicación cliente. Básicamente, cualquier aplicación que tiene un modo de servicio o consumo de datos. Un Mule realiza toda la comunicación vía endpoints, los componentes UMO no tienen la noción de qué aplicación produce los datos, dónde está localizada ni el protocolo de transporte usado. Integración JBI Hay dos componentes JBI para usar endpoints Mule: Mule Receiver: Recibirá datos sobre cualquier transporte Mule y entregarlos como mensaje JBI. Property Type Description Required endpoint java.lang.string A Mule Endpoint URI on which to receive events Yes endpointproperties java.util.map Any properties to set on the endpoint. These are any properties supportedby the transport provider being used. No 19

20 This allows you to specify a Mule endpoint object instead of an EndpointURI muleendpoint org.mule.impl.endpoint.muleendpoint string. This gives you greater flexibility to specify filters, transactions and No transformerson the endpoint. targetservice javax.xml.namespace.qname The target service to be invokedafter this component Yes A string representationof the 'targetservice'qnamein the form of [prefix]: targetservicename java.lang.string [localname]:[namespace]. This can be set insteadof the targetservice No property. The manager that will managethreads for this component. You can configure workmanager javax.resource.spi.work.workmanager all resource managementconfiguration for Mule using the No MuleConfigComponent(see below) Mule Dispatcher: Enviará mensajes JBI normalizados sobre cualquier transporte Mule. Property Type Description Required endpoint java.lang.string A Mule Endpoint URI on which to receive events Yes endpointproperties java.util.map Any properties to set on the endpoint. These are any properties supportedby the transport provider being used. No This allows you to specify a Mule endpoint object insteadof an muleendpoint org.mule.impl.endpoint.muleendpoint EndpointURIstring. This gives you greater flexibility to specify No filters, transactions and transformerson the endpoint. targetservice javax.xml.namespace.qname The target service to be invokedafter this component Yes A string representationof the 'targetservice'qnamein the form of targetservicename java.lang.string [prefix]:[localname]:[namespace]. This can be set insteadof the No targetservice property. The managerthat will managethreads for this component. You can workmanager javax.resource.spi.work.workmanager configure all resource managementconfiguration for Mule using the No MuleConfigComponent(see below) Ambos endpoints son un endpoints Mule y es independiente del contenedor JBI usado. Ejemplo Mule JBI <?xml version="1.0" encoding="utf-8"?> <!DOCTYPEjbi-container PUBLIC "-//SymphonySoft //DTD mule-jbi-configuration XML V1.0//EN" " <jbi-container id="mule" xmlns:foo=" <!-- Mule Reciever that looks for files in the inbox directory --> <mule-component name="foo:filereceiver" classname="org.mule.providers.jbi.components.mulereceiver"> 20