Archivo

Posts Tagged ‘Oracle Service Bus’

Servicios REST: Uso de parámetros en URI y payload

Muchas veces, al diseñar o usar servicios REST externos, nos encontramos con que, a parte de los parámetros del payload, requieren de parámetros en la URI, como el caso común de versionado de los servicios. Un ejemplo de ello sería el siguiente servicio: http://localhost:7001/empleados/{version}/actualizacion/ donde, a parte de los datos del empleado a actualizar, necesitamos informar de la versión del servicio REST.

La versión 12c del Bus de Oracle nos permite configurar estos servicios destinados a mapear uno de los parámetros de entrada del servicio como parámetro de la cabecera. Con ello ya podremos invocar al servicio correspondiente con el payload adecuado, y el objeto json para la actualización de los datos del empleado no tiene por qué contener el valor de la versión del compuesto.

A lo largo del siguiente ejemplo, iremos descubriendo como mapear estos parámetros y configurar el servicio de forma dinámica.

El primer paso sería la generación de un nuevo proyecto.

Seleccionamos Service Bus Project:

Le pondremos como nombre ServicioRestEjemplo y pulsaremos en Finalizar.

Una vez generado el proyecto, configuraremos el servicio REST al que invocar. Para ello, desde el composite, con botón derecho en External Services generamos un binding REST.

Leer más…

Librerías XQuery sobre Oracle Middleware versión 12c

Hasta la versión 11g de Oracle Service Bus (OSB) no se podían usar librerías XQuery en nuestras soluciones OSB. Esto hacia que tuviéramos que reescribir nuestras funciones XQuery, una y otra vez, en cada transformación XQuery que desarrolláramos o que tuviéramos que usar funciones XPath personalizadas con su correspondiente desarrollo en Java y reinicio del servidor; tal y como nos explicaba Antonio Molina en este post.

2209436Con la llegada de la versión 12c de Oracle Middleware esto ha cambiado, ya que en esta nueva versión se da soporte a este tipo de librerías. Con ello, podemos disponer de una batería de funciones customizadas en una librería XQuery que podremos usar desde cualquiera de nuestras transformaciones XQuery. Eso sí, estas funciones no pueden ser usadas directamente desde un proceso OSB, sino sólo usadas por transformaciones XQuery.

Generación de una librería XQuery

Para la generación de una librería XQuery, necesitamos que nuestro proyecto de JDeveloper sea un proyecto OSB o SOA. Una vez cumplimos estas premisas, seleccionaremos “XQuery Library” en la galería de componentes a generar (File -> New):

1

Posteriormente se abrirá un formulario para que insertemos las características de nuestra librería. En él debemos inserta el nombre, namespace y definir una función inicial para nuestra librería.
En nuestro ejemplo, generaremos una función que nos indique la edad de una persona a partir de su fecha de cumpleaños. Leer más…

Comparativa diferentes Enterprise Service Bus (I) – Número de búsquedas en Internet

Recientemente hemos realizado una comparativa sobre los ESBs (Enterprise Service Bus) más destacados en la actualidad. Para iniciar el estudio, nos ha ayudado realizar una búsqueda con Google Trends para establecer una línea base temporal sobre los ESBs objeto del estudio:

  • JBoss Fuse
  • Mule ESB
  • Oracle Service Bus (OSB)
  • Talend ESB
  • WSO2 ESB
ESB Trends 2015

Comparativa Google Trends 2015

De esta comparativa se pueden extraer a primera vista las siguientes conclusiones:

  1. Mule ESB es el bus que lleva más tiempo en el mercado (seguido por Oracle Service Bus).
  2. Tras la aparición de OSB, rápidamente se equiparó en uso y en popularidad con el bus de Mule
  3. WSO2 ESB y JBoss Fuse (dos ESBs open-source puro) llegaron al mercado más tarde pero cogen popularidad rápidamente equiparándose al resto.
  4. Talend ESB se mantiene por debajo (en uso) del resto.

Es necesario destacar que Google Trends es una herramienta de representación numérica/histórica del volumen de búsquedas hechas en Google. Basa su análisis en el impacto que tienen los artículos publicados sobre una temática en cuestión.

Iré publicando varios posts en los que presentaré diferentes aspectos estudiados en la citada comparativa realizada para uno de nuestros clientes.

“Data Source: Google Trends (www.google.com/trends).”

Categorías:SOA / BPM / WebCenter Etiquetas: , ,

Oracle Mobile Suite = Mobile + OSB + App. Adapters

Conjunt

El auge de las aplicaciones de movilidad ha llevado a buscar la mejor arquitectura y tecnología para facilitar y acelerar los desarrollos de este tipo de aplicaciones. La facilidad de consumir servicios web (SOAP o REST), desde dispositivos móviles, ha sido clave para establecer este mecanismo para la integración con los sistemas de BackEnd.

Si los servicios se publican en un Enterprise Service Bus, tendremos una arquitectura del estilo:

Arquitectura Oracle Mobile Suite

Arquitectura Oracle Mobile Suite

Dada esta situación, Oracle acaba de poner a la venta Oracle Mobile Suite. Esta suite se compone de los productos Mobile Development Framework, Enterprise Service Bus y Applications Adapters. La justificación para la creación de esta Suite está basada en la experiencia adquirida con los clientes que ya han implantado aplicaciones de movilidad, junto con la arquitectura, siempre recomendada por Oracle, de posicionar el Bus entre los dispositivos móviles y los sistemas de BackEnd.

Componentes de Oracle Mobile Suite

Componentes de Oracle Mobile Suite

Si unimos todas las piezas tenemos una solución completa de movilidad con un acceso fácil, rápido y seguro a la información de los sistemas de BackEnd de las compañías, desde los dispositivos móviles a través de Enterprise Service Bus con los Adaptadores.

Aquellas compañías que estén pensando incorporar aplicaciones de movilidad, tienen en esta Suite todo lo necesario para un desarrollo altamente productivo y desde el minuto cero. Por un lado, con Mobile Development Framework se pueden desarrollar aplicaciones de movilidad cross-device, que permitirán implementar y mantener una sola aplicación y desplegarla en distintos dispositivos (IOS, Android). Y por otro lado, además se beneficiarán de todas las ventajas de integración que aporta Enterprise Service Bus con Applications Adapters, no sólo con dispositivos móviles si no con múltiples aplicaciones heterogéneas.

Para más información:  http://www.oracle.com/us/technologies/mobile/oracle-mobile-suite-ds-2085011.pdf

Regular los registros procesados por un DBAdapter polling

mayo 21, 2013 2 comentarios

En este post se explicarán las propiedades del adaptador de base de datos de Oracle (para la SOA Suite y el OSB) que nos permiten regular el número de registros procesados en cada poll.

Para configurar de forma óptima la regulación, es necesario tener en cuenta las siguientes 3 propiedades:

<property name="PollingInterval" value="segundos"/>
<property name="MaxRaiseSize" value="elementos"/>
<property name="MaxTransactionSize" value="registros"/>

Veamos el significado de cada una:

  • PollingInterval: Segundos entre consultas a la base de datos.
  • MaxRaiseSize: Cantidad de elementos XML creados por instancia.
  • MaxTransactionSize: Cantidad de registros a procesar en cada consulta a la base de datos.

A modo de ejemplo, si disponemos de 1000 registros a procesar y realizamos la siguiente configuración:

<property name="PollingInterval" value="60"/>
<property name="MaxRaiseSize" value="20"/>
<property name="MaxTransactionSize" value="100"/>

conseguiríamos una ejecución por minuto, que recuperaría 100 registros, generando 5 instancias con 20 registros en cada petición XML (100/20).

Una gran diferencia entre las propiedades de MaxRaiseSize y MaxTransactionSize puede afectar al rendimiento de nuestro proceso, por lo que se recomienda mantener un ratio de hasta 1:10, intentando, siempre que sea posible, acercarse al 1:1.

Cabe mencionar que con bases de datos no-Oracle se han encontrado comportamientos dispares. En estos casos conviene revisar la documentación del driver utilizado, para comprobar que dicho comportamiento esté soportado.

Webinar: Oracle Service Bus

noviembre 8, 2012 1 comentario

Oracle Service Bus transforma arquitecturas complejas y débiles, en redes de integración ágiles y robustas, mediante la conexión, la mediación, y la gestión de las interacciones entre servicios y aplicaciones. Oracle Service Bus ofrece un bajo coste de integración basada en estándares, rendimiento extremo y escalabilidad.
Vea en este Webinar todas las características de Oracle Service Bus: Múltiples protocolos de transporte, configuración vs programación, enrutado de identidad y contenido, seguridad orientada a políticas…

Reserve su plaza y no pierda la oportunidad de asistir a este seminario Web organizado por Oracle y avanttic, que le permitirá conocer estas tecnologías de manera cómoda, ágil e interactiva.

Martes 13 de noviembre de 2012, 10:00 am – 11:00 am

Webinar: Oracle Service Bus (Marc Pérez) [ Presentación ]

Si quieres conocer el resto de webinars incluidos en el ciclo, dedicado a la Arquitectura Orientada a Servicios (SOA), accede a este enlace.

Categorías:Eventos Etiquetas:

Cómo mejorar el rendimiento en Oracle Service Bus

En un flujo de ejecución de un proxy service, los accesos a la información de las variables de contexto como $body, $header, $context, etc. se realizan mediante XQuery/XPath. Las sentencias en Xquery son interpretadas en tiempo de ejecución en un motor de Xquery en WebLogic/OSB. La definición de las sentencias Xquery puede influir en el rendimiento del servicio. Por este motivo, se recomienda siempre tener una serie de buenas prácticas que se si se siguen, se puede mejorar, y mucho, el rendimiento, tal y como veremos más adelante.

  •  Evitar el uso de dobles barras (//) en XPath.  Las búsquedas con doble barra recorren todo el documento xml en el que se realiza la búsqueda incluso después de haber encontrado lo que se buscaba.
  • Las expresiones XPath deben ser indexadas. XPath es un lenguaje declarativo, y una expresión XPath puede devolver más de un nodo. En algunas ocasiones sólo necesitamos el primer o último elemento, de forma que nos evitaríamos recorrer nuevamente todo el documento de búsqueda.
  • Extraer sentencias frecuentemente usadas de un documento XML como variables intermedias en una expresión FLOWR. Si necesitamos acceder a un dato del xml más de una vez, es más eficiente extraerlo en una variable intermedia que hacer más de una búsqueda. 
  • Minimizar las conversiones de un tipo de datos XML a “XML como texto” y viceversaEl marshalling / unmarshalling de mensajes es de las acciones más costosas en OSB, por este motivo, se deben minimizar.
  • Establecer la información de enrutamiento en la cabecera SOAP o la cabecera de transporte.De esta forma, no es necesario acceder al contenido del mensaje para enrutar en función del contenido.

Adicionalemente, y no menos importante, también se puede mejorar el rendimiento en el OSB con las opciones de configuración de la JVM de WebLogic. Con una configuración adecuada a la máquina de ejecución y a los recursos de memoria de la misma, se puede optimizar su rendimiento.

Pero, ¿cuánto se gana con estas buenas prácticas? A continuación mostramos una comparativa que hemos realizado. El caso de uso es un servicio que hace una transformación Xquery para la petición, enruta hacia un servicio web y hace otra transformación Xquery para la respuesta. Tanto las Xquery, como sus parámetros de entrada, han sido establecidos para  los siguientes escenarios:

  1. Sin optimizar.
  2. Optimizados.
  3. Optimizados y con caché de resultados.

La prueba que hemos realizado ha sido comprobar cuántas peticiones en un minuto es capaz de procesar el servicio en cada uno de estos escenarios. El resultado ha sido el siguiente:

Escenario con Xquery sin optimizar: 7642 peticiones procesadas en 1 minuto

1 Minuto con sentencias Xquery sin optimizar

Escenario con Xquery optimizadas: 12100 peticiones procesadas en 1 minuto

Escenario con Xquery optimizadas

 Escenario con Xquery optimizadas y con Cacheo de Resultados: 15388 peticiones procesadas en 1 minuto

Escenario con Xquery optimizadas y cacheo de resultados

Como resultado, hemos procesado sobre 5000 peticiones más en un sólo minuto únicamente optimizando Xquery. Si además cacheamos resultados, la mejora se va a casi 8000 peticiones procesadas. Por lo tanto, merece la pena poner atención en estas prácticas para mejorar el rendimiento de procesamiento de Oracle Service Bus.