Enterprise Service Bus

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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 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:http://mycompany.com/mule/services/MyUMO 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" "http://www.symphonysoft.com/dtds/mule/mule-jbi-configuration.dtd"> <jbi-container id="mule" xmlns:foo="http://www.mulejbi.org/foo/"> <!-- Mule Reciever that looks for files in the inbox directory --> <mule-component name="foo:filereceiver" classname="org.mule.providers.jbi.components.mulereceiver"> 20

Somos su empresa de. Soporte a Desarrollo Informático. Ese apoyo que siempre quiso tener.

Somos su empresa de. Soporte a Desarrollo Informático. Ese apoyo que siempre quiso tener. Qué ofrece Autentia? Somos su empresa de Soporte a Desarrollo Informático Ese apoyo que siempre quiso tener. Desarrollo de componentes y proyectos a medida. Auditoría de código y recomendaciones de mejora.

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

JavaEE. www.javasoft.com

JavaEE. www.javasoft.com JavaEE Java Enterprise Edition www.javasoft.com Por qué Java en el servidor? Ventajas Independencia de la plataforma portabilidad Gran conjunto de APIs Reusabilidad y modularidad Seguro en la ejecución

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

Curso de Java EE Todos los Derechos Reservados Global Mentoring Experiencia y Conocimiento para tu Vida 1

Curso de Java EE Todos los Derechos Reservados Global Mentoring Experiencia y Conocimiento para tu Vida 1 1 Los Enterprise Java Beans (EJB) es código Java del lado del Servidor. Normalmente tienen la lógica de negocio de nuestra aplicación, y por lo tanto cubren el rol de la capa de servicio de nuestras aplicaciones

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

Enterprise JavaBeans

Enterprise JavaBeans Enterprise Java Beans y JBoss Enterprise JavaBeans Es una de las API que forman parte del estándar de construcción de aplicaciones empresariales J2EE (ahora JEE 5.0) de Oracle Corporation (inicialmente

Más detalles

CARRERA TITULO DEL TRABAJO CURSO

CARRERA TITULO DEL TRABAJO CURSO CARRERA Ingeniería Informática TITULO DEL TRABAJO SOA CURSO Tópicos de Ingeniería del Software CÉSAR ESTRADA CONDORI MAYRA GOMEZ QUEVEDO LUIS MUǸOS ESCAPA ALAN A. ROJAS MARROQUIN SEMESTRE IX 2010 Los alumnos

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

La aplicación práctica en el mundo empresarial de los estándares Web

La aplicación práctica en el mundo empresarial de los estándares Web La aplicación práctica en el mundo empresarial de los estándares Web El problema de la integración inter/intra empresas y la familia "XML" Enrique Bertrand XML Business Integration, Regional Director Software

Más detalles

DESARROLLO WEB EN ENTORNO SERVIDOR

DESARROLLO WEB EN ENTORNO SERVIDOR DESARROLLO WEB EN ENTORNO SERVIDOR CAPÍTULO 7: Programación de servicios Web Marcos López Sanz Juan Manuel Vara Mesa Jenifer Verde Marín Diana Marcela Sánchez Fúquene Jesús Javier Jiménez Hernández Valeria

Más detalles

La integración de información. Presente y futuro de la empresa moderna

La integración de información. Presente y futuro de la empresa moderna La integración de información. Presente y futuro de la empresa moderna Ing. Josue Carralero Iznaga, MSc. ISPJAE, Facultad de Ingeniería Informática, Departamento de Ingeniería de Software. Complejo de

Más detalles

MARCANDO LA DIFERENCIA

MARCANDO LA DIFERENCIA MARCANDO LA DIFERENCIA INTEGRACIÓN RÁPIDA Y CONFIABLE entre sus sistemas Simplifique la integración y el mantenimiento de su lógica de negocio con nuestra arquitectura orientada a servicios. Ahorre dolores

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

WebSphere Message Broker como Entreprise Service Bus

WebSphere Message Broker como Entreprise Service Bus IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta

Más detalles

Taller de Sistemas de Información 3. Presentación SCA

Taller de Sistemas de Información 3. Presentación SCA Taller de Sistemas de Información 3 Presentación SCA Integrantes: Gustavo Fava Diego Salido Marcos Techera agosto de 2008 TSI 3 1 Introducción a SCA Aplicación: conjunto de componentes de software trabajando

Más detalles

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos.

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. I JORNADAS DE SIG LIBRE Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. Alejandro Guinea de Salas (1), Sergio Jorrín Abellán (2) (1) Director de Geograma

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

Más detalles

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes

Más detalles

Tema 5. Plataforma Java EE

Tema 5. Plataforma Java EE Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs enero 2009 FJRP, FMBR 2008/09 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise

Más detalles

OpenESB FEMI Sofis Solutions - PMA

OpenESB FEMI Sofis Solutions - PMA OpenESB FEMI Sofis Solutions - PMA Página 1 de 22 1 BPMS... 3 1.1 Introducción... 3 1.2 Modelado de Procesos... 5 1.2.1 Editor Gráfico de Procesos... 5 1.2.2 Gestión de Tareas... 6 1.2.3 Interacción Humana...

Más detalles

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz

Más detalles

Oracle Service Bus Enrique Martín Casado Presales Manager

<Insert Picture Here> Oracle Service Bus Enrique Martín Casado Presales Manager Oracle Bus Enrique Martín Casado Presales Manager Partimos de una Necesidad Para mejorar la productividad y la competitividad de nuestras organizaciones, cada día es más necesario

Más detalles

Documentación Técnica Conector

Documentación Técnica Conector Documentación Técnica Conector Torre Ejecutiva Sur Liniers 1324, piso 4 Montevideo Uruguay Tel/Fax: (+598) 2901.2929* Email: contacto@agesic.gub.uy www.agesic.gub.uy Indice 1 Introducción...4 2 Casos

Más detalles

Silenus Consultoría. SOA Silenus SOA/09009. Mayo de 2009. Análisis SOA Silenus

Silenus Consultoría. SOA Silenus SOA/09009. Mayo de 2009. Análisis SOA Silenus SOA Silenus SOA/09009 Mayo de 2009 Análisis SOA Silenus Índice 1 Introducción...4 2 Contexto del Proyecto...7 3 Casos de Uso...11 3.1 CU 1: Creación y Modificación de Cuentas...11 3.2 CU 2: Creación de

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Web Services en Java. Taller de Programación. Instituto de Computación Facultad de Ingeniería Universidad de la República

Web Services en Java. Taller de Programación. Instituto de Computación Facultad de Ingeniería Universidad de la República Web Services en Java Taller de Programación Instituto de Computación Facultad de Ingeniería Universidad de la República Contenido Motivación y Conceptos Funcionamiento Annotations Desarrollando una aplicación

Más detalles

Servicios Web. Capítulo 5: Introducción a los Servicios Web. Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es

Servicios Web. Capítulo 5: Introducción a los Servicios Web. Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es Servicios Web Capítulo 5: Introducción a los Servicios Web Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es http://diis.unizar.es/postweb/ Departamento de Informática e Ingeniería de

Más detalles

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx Contenido Middleware: Introducción Definición Genealogía Aplicaciones actuales: Servicios Web Computación

Más detalles

5.1 Introducción a Servicios Web

5.1 Introducción a Servicios Web 5.1 Introducción a Servicios Web Introducción Continuando con el ejemplo de intercambio de información de películas... => Actualmente ya no es necesario implementar la solución sugerida a mano Se han estandarizado

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo

Más detalles

Módulo 2. Arquitectura

Módulo 2. Arquitectura Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Aplicaciones web construidas a base de componentes:

Aplicaciones web construidas a base de componentes: Java EE Aplicaciones Web/Sistemas Web Juan Pavón Mestras Dep. Ingeniería del Software e Inteligencia Artificial Facultad de Informática Universidad Complutense Madrid Material bajo licencia Creative Commons

Más detalles

Tema 5. Plataforma Java EE

Tema 5. Plataforma Java EE Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs septiembre 2011 FJRP, FMBR 2008-2011 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise

Más detalles

Service Oriented Architecture: Con Biztalk?

Service Oriented Architecture: Con Biztalk? Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación

Más detalles

Talend Integration Suite

Talend Integration Suite Talend Integration Suite Talend Integration Suite es un sistema que mejora considerablemente la eficiencia del trabajo de integración de datos a través de un entorno de desarrollo gráfico fácil de usar.

Más detalles

Cómo lograr una implementación exitosa de SOA?

Cómo lograr una implementación exitosa de SOA? Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas

Más detalles

DESPLIEGUE DE SENTINET

DESPLIEGUE DE SENTINET DESPLIEGUE DE SENTINET INTRODUCCIÓN Sentinet es una solución que proporciona gestión y gobierno de infraestructuras SOA desplegadas tanto on-premise, en la nube o en entornos híbridos. Sentinet está desarrollada

Más detalles

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Arquitectura Java para el Cuarto Ejercicio José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Sumario Introducción Arquitectura en n-capas Arquitectura y el Cuarto Examen Java y su modelo

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

El Framework de desarrollo del Consejo

El Framework de desarrollo del Consejo El Framework de desarrollo del Consejo Superior de Investigaciones Científicas Director de la OPCSIC Centro Técnico de Informática (CSIC) Directora Centro Técnico de Informática (CSIC) Palabras clave Framework,

Más detalles

AGESIC Gerencia de Proyectos

AGESIC Gerencia de Proyectos AGESIC Gerencia de Proyectos Tutorial sobre configuración del componente Conector de la PGE Historial de Revisiones Fecha 10/11/2011 Versión 1.0 Descripción Versión inicial Autor Marcelo Caponi Aprobado

Más detalles

6.1 Introducción a los sistemas EAI

6.1 Introducción a los sistemas EAI 6.1 Introducción a los sistemas EAI Integración de Aplicaciones (1) El problema de la integración de aplicaciones consiste en hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente

Más detalles

Curso: Programación con JAVA SE Estándar Edition.

Curso: Programación con JAVA SE Estándar Edition. Curso: Programación con JAVA SE Estándar Edition. Código: 1062 Familia Profesional: Programación. Acreditación: Formación reconocida a través de vías no formales Modalidad: Distancia Duración: 150 horas

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Tesina Licenciatura en Informática (UNLP) Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Boccalari Cristian Temario General Visión

Más detalles

COMUNICACIÓN TECNIMAP SEDE ELECTRÓNICA DEL MINISTERIO DE MEDIO AMBIENTE, Y MEDIO RURAL Y MARINO

COMUNICACIÓN TECNIMAP SEDE ELECTRÓNICA DEL MINISTERIO DE MEDIO AMBIENTE, Y MEDIO RURAL Y MARINO COMUNICACIÓN TECNIMAP SEDE ELECTRÓNICA DEL MINISTERIO DE MEDIO AMBIENTE, Y MEDIO RURAL Y MARINO ÍNDICE 1 INTRODUCCIÓN... 1 2 ARQUITECTURA TECNOLÓGICA DEL MARM... 2 2.1 ARQUITECTURA DE SEDE ELECTRÓNICA...3

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

Facultad de Sistemas e Informática

Facultad de Sistemas e Informática Escuela Politécnica del Ejército Sede Latacunga Facultad de Sistemas e Informática Galarza Maira Tapia Cevallos Paulina DESARROLLO DE APLICACIONES DISTRIBUIDAS UTILIZANDO PATRONES DE DISEÑO MODELO/VISTA

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Capacitación Efectiva SOA y Web Services con Java

Capacitación Efectiva SOA y Web Services con Java Descripción: SOA es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones SOA han sido creadas para satisfacer los objetivos de negocio las cuales incluyen facilidad

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

Oracle Application Server 10g

Oracle Application Server 10g Oracle Application Server Oracle Application Server 10g La plataforma de aplicaciones más completa e integrada del mercado Puntos a comparar Lo más importante antes de realizar un análisis comparativo

Más detalles

Oracle Service Bus: Entorno de Desarrollo

Oracle Service Bus: Entorno de Desarrollo Oracle Service Bus: Entorno de Desarrollo Mayo 2012 Versión 1.1 ÍNDICE 1. Introducción al Oracle Service Bus I. Conceptos II. Ventajas del OSB III. Arquitectura Mensajería adaptable Seguridad Unificada

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

JAVA ENTERPRISE EDITION (J2EE) ARQUITECTURA TECNOLOGÍAS (1/2) (L1)

JAVA ENTERPRISE EDITION (J2EE) ARQUITECTURA TECNOLOGÍAS (1/2) (L1) TECNOLOGÍAS (1/2) (L1) EJB ( Enterprise Java Beans ) JSP ( Java Server Pages ) JNDI ( Java Naming and Directory Interface ) JDBC ( Java Data Base Connectivity ) Java Mail JSF ( Java Server Faces ) TECNOLOGÍAS

Más detalles

Service Oriented Architecture

Service Oriented Architecture Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos

Más detalles

Técnico Superior en Programación con Java SE Standard Edition

Técnico Superior en Programación con Java SE Standard Edition Código: M087_04 Técnico Superior en Programación con Java SE Standard Edition Modalidad: Distancia Duración: 120 horas Objetivos: Este pack de materiales formativos proporcionará al alumnado la base que

Más detalles

Planos de ejecución en Velneo V7

Planos de ejecución en Velneo V7 Planos de ejecución en Velneo V7 Por Jesús Arboleya Introducción 3 Arquitectura Cliente/Servidor 4 1. Objetos que siempre se ejecutan en el servidor 5 2. Objetos que siempre se ejecutan en el cliente 6

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Integración al Servicio de la Empresa

Integración al Servicio de la Empresa Integración al Servicio de la Empresa Las Arquitecturas SOA permiten abordar los nuevos retos empresariales, ser más competitivos y disponer de sistemas de información integrados. Además, tecnologías como

Más detalles

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias

Más detalles

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web.

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web. Microsoft Office SharePoint Server 2007 es un conjunto integrado de características de servidor que puede contribuir a mejorar la eficacia organizativa al ofrecer completas funciones de administración

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

Introducción a Javato

Introducción a Javato Introducción a Javato Fº. Javier Pereñiguez Steria Iberica 20/02/2008 Índice Introducción Arquitectura Ejemplo arquitectura Plataforma Desarrollo Ejemplo de entorno de desarrollo Vías futuras Casos de

Más detalles

API DE INTEROPERACION ENTRE TELCEL Y MOVILTEK PARA EL REGISTRO DE EQUIPOS AVL

API DE INTEROPERACION ENTRE TELCEL Y MOVILTEK PARA EL REGISTRO DE EQUIPOS AVL MANUEL J. CHAVIRA INS-035R04 10-Nov-06 1 de 23 TABLA DE CONTENIDO 1 1 INTRODUCCIÓN 2 1.1 COMUNICACIÓN 2 1.2 INTERCAMBIO DE DATOS 2 1.3 SOAP 3 1.4 SEGURIDAD 4 1.5 FASES OPERATIVAS 4 2 REFERENCIA PARA CONSUMIR

Más detalles

1. Definición. Open Source. Escalable. Alto desempeño. Arquitectura Modular. Producto de licencia de código abierto sin coste adicional.

1. Definición. Open Source. Escalable. Alto desempeño. Arquitectura Modular. Producto de licencia de código abierto sin coste adicional. 1. Definición JBoss es un proyecto de código abierto, con el que se consigue un servidor de aplicaciones basado en J2EE, e implementado al 100% en Java. Por lo tanto al estar basado en Java, JBoss puede

Más detalles

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO MF0492_3 PROGRAMACION WEB EN EL ENTORNO SERVIDOR (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 240 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 217 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

Taller de Sistemas de Información 1. Clase 5 WCF

Taller de Sistemas de Información 1. Clase 5 WCF Taller de Sistemas de Información 1 Clase 5 WCF Que es WCF? Windows Communication Foundation (WCF) es un SDK para el desarrollo y puesta en producción de servicios en plataforma Windows WCF provee un runtime

Más detalles

Sustitución de certificados administrativos en soporte papel por medios telemáticos

Sustitución de certificados administrativos en soporte papel por medios telemáticos Sustitución de certificados administrativos en soporte papel por medios telemáticos I Congreso Español de Informática Jornadas Científico-Técnicas en Servicios Web Granada, Septiembre 2005 Francisco Lova

Más detalles

Embarcadero Delphi XE 3. Desarrollando Aplicaciones con DataSnap. Contenido del Material

Embarcadero Delphi XE 3. Desarrollando Aplicaciones con DataSnap. Contenido del Material Contenido del Material Introducción... 2 Descripción y Arquitectura de DataSnap... 3 Descripción:... 3 Arquitectura:... 4 Ejemplo de DataSnap Simple (Como en Primero)... 5 Servidores DataSnap que podemos

Más detalles

Indizen Labs imade. Marco de Desarrollo Aplicaciones de Indizen

Indizen Labs imade. Marco de Desarrollo Aplicaciones de Indizen Indizen Labs imade Marco de Desarrollo Aplicaciones de Indizen Índice de contenidos Indizen Labs Introducción a imade Metodología imade Arquitectura imade Herramientas imade Indizen Labs Indizen Labs Son

Más detalles

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect IT Insight podcast Este podcast pertenece a la serie IT Insight Pueden suscribirse al podcast a través de itunes. El material

Más detalles

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.

Más detalles

Módulo 2 Comunicación

Módulo 2 Comunicación Sistemas Distribuidos Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia San Juan Bosco Comunicación en Sistemas Distribuidos Modelos de Comunicaciones

Más detalles

CEP/ESP: Procesamiento y correlación de gran cantidad de eventos en arquitecturas SOA

CEP/ESP: Procesamiento y correlación de gran cantidad de eventos en arquitecturas SOA CEP/ESP: Procesamiento y correlación de gran cantidad de eventos en arquitecturas SOA Víctor Ayllón 1 y Juan M. Reina 1 1 Novayre {vayllon, jmreina}@novayre.es Abstract. El matrimonio entre ESP/CEP y las

Más detalles

Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1. Gerardo Lecaros Felipe Díaz

Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1. Gerardo Lecaros Felipe Díaz Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1 Gerardo Lecaros Felipe Díaz Problemática Petición de salas de forma tradicional Solución J2EE Java 2 Platform, Enterprise Edition

Más detalles

Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16

Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16 Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16 (Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado) Los nuevos escenarios de programación con SAP Netweaver (serie de varios

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores.

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores. GLOSARIO Glosario Acoplamiento. Posibilidad que tiene un servicio de funcionar de forma autónoma. Se dice que un servicio o aplicación es bajamente acoplado cuando puede funcionar de forma independiente

Más detalles

con certif icado de profesionalidad

con certif icado de profesionalidad CARACTERÍSTICAS El diseño web está cambiando en poco tiempo. Las nuevas tecnologías y estándares de programación están revolucionando tanto la forma de crear web como de interactuar con ellas. En nuestro

Más detalles

MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD

MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD Francisco Tous Llull, Antoni Reus Darder, Felip Salas Suau Fundació Illes Balears per la Innovació Tecnològica (IBIT) Parc

Más detalles

Arquitectura de aplicaciones

Arquitectura de aplicaciones Arquitectura de aplicaciones Arquitectura en capas API API dic-08 alb@uniovi.es 2 Layers y Tiers Layer: capa arquitectónica de la aplicación software Presentación, lógica, persistencia Tier: capa física

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Aproximación al CONCEPTO

Aproximación al CONCEPTO 18 Aproximación al CONCEPTO LA NECESIDAD DE INTERCAMBIAR INFORMACIÓN ENTRE DEPARTAMENTOS Y ÁREAS DE NEGOCIO SE HA VUELTO CRUCIAL Y HA HECHO QUE LAS EMPRESAS VEAN LA INTEGRACIÓN COMO UN ELEMENTO CLAVE PARA

Más detalles

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 17/08/2005 1.0 Se hace la

Más detalles

Integración de Oracle WebLogic con Oracle Real Application Cluster

Integración de Oracle WebLogic con Oracle Real Application Cluster Oficina de Calidad Subdirección de Tecnologías de la Información Integración de Oracle WebLogic con Oracle Real Application Cluster Referencia documento: InfV5_JASAS_WLS_vs_RAC_V310.doc Fecha: Versión:

Más detalles

Service Broker. Bind. Service Consumer. Service Provider

Service Broker. Bind. Service Consumer. Service Provider En este capítulo, usted podrá empezar por mirar a la arquitectura orientada al servicio como un concepto en arquitectura para aplicaciones distribuidas. A continuación usted examinará cómo estas arquitecturas

Más detalles

1.264 Tema 16. Middleware heredado

1.264 Tema 16. Middleware heredado 1.264 Tema 16 Middleware heredado Qué es el middleware heredado? Cliente (interf. de usuario, aplic. local) Cliente (interf. de usuario, aplic. local) Cómo conectamos clientes y servidores? Middleware

Más detalles

Modelo de Objetos Distribuidos

Modelo de Objetos Distribuidos Remote Method Invocation Modelo de Objetos Distribuidos Un objeto remoto es un objeto cuyos métodos pueden ser invocados desde otra máquina virtual de java, potencialmente en un host diferente. Modelo

Más detalles

Servicios web. Contenido. Programación en Internet Curso 2007-2008. Introducción Los pilares (SOAP, WSDL, UDDI) Desarrollo de un servicio web

Servicios web. Contenido. Programación en Internet Curso 2007-2008. Introducción Los pilares (SOAP, WSDL, UDDI) Desarrollo de un servicio web Departamento de Lenguajes y Sistemas Informáticos Servicios web Programación en Internet Curso 2007-2008 Contenido Introducción Los pilares (SOAP, WSDL, UDDI) Desarrollo de un servicio web DLSI - Universidad

Más detalles