Archivo
Regular los registros procesados por un DBAdapter polling
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
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.
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 viceversa. El 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:
- Sin optimizar.
- Optimizados.
- 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
Escenario con Xquery optimizadas: 12100 peticiones procesadas en 1 minuto
Escenario con Xquery optimizadas y con Cacheo de Resultados: 15388 peticiones procesadas en 1 minuto
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.
Calendario de webinars avanttic (noviembre 2012)
Oracle y avanttic le ofrecemos un ciclo de tres Seminarios Web para el próximo mes de noviembre, con el que le acercaremos al mundo SOA (Arquitectura Orientada a Servicios) de manera cómoda, ágil e interactiva. No pierda esta oportunidad y reserve su plaza.
Martes, 06 de noviembre de 2012, 10:00 am
|
|
Martes, 13 de noviembre de 2012, 10:00 am
|
Martes, 20 de noviembre de 2012, 10:00 am
|
Preferencias en Oracle Service Bus mediante funciones XPath personalizadas
A lo largo del desarrollo de un proyecto de Oracle Service Bus, en algún momento, siempre surge la cuestión de las variables de contexto en función del entorno de ejecución. Algunas de estas variables, como endpoints, claves de servicio, etc. se pueden modificar entre entornos mediante un Buscar y Sustituir o mediante un Fichero de Personalización en Oracle Service Bus. Pero podemos tener la necesidad de variables de contexto necesarias para nuestros servicios, como por ejemplo, constantes por entorno, flags, etc. que no pueden ser modificadas entre entornos mediante estos mecanismos de Oracle Service Bus.
A partir de esta situación, en los distintos desarrollos, siempre se ha tratado de dar diversas soluciones personalizadas para poder facilitar la utilización de variables de entorno en los servicios de Oracle Service Bus, como por ejemplo:
- Xquery con las variables de entorno. Esta es la solución más sencilla. Consiste en almacenar un XML con las variables de entorno en una Xquery, de tal forma que cualquier Proxy Service puede utilizar esta Xquery para recuperar las variables de entorno. Modificando la Xquery entre entornos, se proporcionan las variables adecuadas para cada entorno sin modificar los servicios. Pero en este caso hay que modificar un componente del proyecto de Oracle Service Bus.
- Servicios que recuperan las variables de entorno. Esta solución consiste en recuperar las variables de contexto a través de un servicio. Este servicio se encargaría de devolver las variables de entorno, pudiendo obtenerlas de una Base de Datos, de archivos de propiedades, etc. Al cambiar de entorno, sólo debería cambiarse la Base de Datos, el archivo de propiedades, etc. para así obtener las variables adecuadas para cada entorno.
A continuación vamos a añadir una nueva solución aprovechando la personalización de funciones XPath/Xquery que proporciona Oracle Service Bus. La solución consiste en la creación de una función XPath personalizada que recupere las variables de entorno. Esta función se podría utilizar en cualquier expresión, transformación, asignación, etc. de cualquier proxy service. Su comportamiento sería similar al que realiza la función getPreferences que sí que incluye BPEL en la SOA Suite.
Para la creación de la función XPath personalizada, en primer lugar, debemos crear la clase Java que será utilizada por la función XPath. En esta clase se puede implementar cualquier mecanismo de acceso a las variables de contexto, como por ejemplo, en un archivo de propiedades, en una base de datos, en un servicio, etc. En nuestro ejemplo, utilizaremos un archivo de propiedades.
En nuestra clase Java, denominada EnvironmentVariables, implementamos la función getEnvironmentVariable, que recibirá como parámetro el nombre de una variable de entorno que se quiere buscar. La función buscará la variable de entorno en un archivo de propiedades y retornará el valor de dicha variable.
Consumir o exponer servicios REST con Oracle Service Bus 11g
Con Oracle Service Bus 11g es posible consumir servicios REST con el fin de integrarlos en la lógica de un proceso de negocio interno o de exponerlos mediante una interfaz SOAP. Cualquiera que sea la intención, el proceso resulta sencillo mediante los pasos expuestos en esta entrada.
En el ejemplo, el servicio REST recibe los parámetros por cadena de consulta (Query string) y devuelve un XML con el resultado de la ejecución.
Primero se ha de crear un servicio de negocio (business service):
- El tipo del servicio ha de ser Servicio de Mensajes (Messaging Service):
Tipología del servicio de negocio
- Para los mensajes, tanto de petición como respuesta, seleccionar XML:
Tipología de los mensajes de petición y respuesta
- Agregar la URI del servidor en el cual se encuentra el servicio a consumir.
- Si se desea o es necesario, modificar el resto de parámetros. En este caso se dejan por defecto.
El Consorci Hospitalari de Vic integra su operativa mediante una arquitectura SOA
El Consorci Hospitalari de Vic (CHV) necesitaba una garantía absoluta de alta disponibilidad en toda su operativa, superando las limitaciones en las funcionalidades propias de la base de datos para integraciones entre sistemas.
Para ello necesitaba llevar a cabo un despliegue masivo de Web Services con la consecuente necesidad de monitorización y trazabilidad, cumpliendo además las políticas de contención de gastos.
A través de este proyecto se ha garantizado la total disponibilidad de las aplicaciones de gestión hospitalaria e historia clínica, estableciéndose una arquitectura SOA con un elevado grado de madurez.
El CHV se ha apoyado en avanttic para la puesta en producción de Oracle Service Bus, el desarrollo de integraciones, la formación del personal y el soporte posterior de todas las soluciones implantadas.
El balance de nuestra colaboración con Oracle y avanttic ha sido muy positivo. Podemos decir que contamos con una infraestructura tecnológica estable, robusta, flexible y duradera, con servicios asociados para dar respuesta a las necesidades funcionales que van surgiendo dentro del marco estratégico de disponibilidad continua.
Sebastià Caro, Jefe de Sistemas y TIC del Consorci Hospitalari de Vic
Lee los detalles del proyecto en el datasheet del caso de éxito (formato pdf).
Esperando SOA & BPM 12c
Si hace relativamente poco que Oracle presentaba la nueva versión de Weblogic (de la cuál un compañero os hizo un breve resumen de las nuevas funcionalidades que incorpora), en el reciente Oracle Community Partner Forum que tuvo lugar en Málaga, tuvimos la oportunidad de conocer de primera mano la evolución prevista para los distintos productos que van a correr sobre esta nueva infraestructura. Así, anunciaron las nuevas características que debían aparecer con la nueva release 11gPS5 de SOA Suite y BPM Suite y el camino que seguirían estos productos hacia su versión 12c.
A continuación, os hago un resumen de las características que encuentro más interesantes de estos productos.
Ejecutar un servicio securizado desde otro Proxy Service
Recientemente nos hemos encontrado con la necesidad de ejecutar, desde un Proxy Service, una operación en un servicio securizado con Oracle Web Service Manager (OWSM). Desde un Proxy Service, no podemos especificar las credenciales a utilizar en la invocación o enrutado a otro servicio proxy.
La solución planteada e implementada ha sido la de crear un Business Service con un Service Account asociado que haga de intermediario entre ambos servicios, consiguiendo así especificar las credenciales para el consumo de dicho servicio
Crear Service Account
Dado que se pretende ejecutar una operación en un servicio securizado, se ha de crear una Service Account (cuenta de servicio si tenemos el entorno traducido) con las credenciales necesarias, en nuestro caso y con la finalidad de simplificar el ejemplo, de tipo estático.
Generar Business Service
Creadas las credenciales, es cuestión de crear un servicio de negocio o Business Service para que haga de puente entre nuestros dos servicios proxy. En el apartado de Configuración de transporte HTTP seleccionamos el tipo de seguridad correspondiente y la cuenta de credenciales creada anteriormente:
Configurar Proxy Service
Una vez podamos consumir las operaciones securizadas del servicio, se puede integrar en cualquier servicio proxy que tengamos creado agregando un routing, publish o service callout a nuestro servicio proxy.
De este modo, con tres sencillos pasos, conseguimos ejecutar servicios securizados desde otros proxy services.
Web Service Security: Consumo de servicios securizados con SAML
La mayoría de modelos de seguridad de servicios web implantados bajo una arquitectura orientada a servicios (SOA) apuesta por los perfiles de seguridad en el mensaje de Web Service Security:
- Username Token Profile para los consumos internos
- X509 Certificate Token Profile para los consumos procedentes del exterior
¿Qué sucede con el perfil SAML Token Profile? La respuesta es que se suele utilizar principalmente en modelos de seguridad de tipo Single Sign On, pero no siempre se va a dar este escenario. Por ejemplo, pongamos por caso que nuestro sistema no pertenece a ningún modelo de seguridad Single Sign On, pero en cambio, necesita consumir un servicio que está securizado con el perfil SAML Token Profile. ¿Qué se debe hacer para poder consumir este tipo de servicio? A continuación se muestran los distintos pasos necesarios para poder consumir un servicio securizado con SAML desde Oracle Service Bus.
Política de Seguridad
En primer lugar hay que definir una política de seguridad para poder asignarla al business service asociado al servicio que se va a consumir. La política de seguridad viene establecida por el proveedor del servicio, que deberá facilitar información sobre la misma. En el caso de SAML, se necesita saber, además, el método de confirmación del token: Bearer, Sender-Vouches o Holder-Of-Key. Las políticas de seguridad en Oracle Service Bus se pueden definir de tres formas:
- Obtenerlas del propio WSDL del servicio, si es que las incluye.
- Con Oracle Web Services Manager. Si se dispone del producto, tiene políticas predefinidas y se pueden definir nuevas políticas a partir de las primeras.
- Con OSB. También incluye políticas predefinidas y se pueden definir otras nuevas a través de un recurso de tipo Política de Servicio Web. Una vez definida la política de seguridad adecuada para el servicio a consumir, se aplica al business service de acceso al servicio.
Asignación de Credenciales
Tras aplicar la política de seguridad en el business service, éste último, solicita al dominio de seguridad de WebLogic, que genere un token SAML con la información del usuario que está ejecutando la petición. Por lo tanto, WebLogic debe ser capaz de convertir los datos de un usuario autenticado, en un token SAML. Por este motivo se debe crear un proveedor de asignación de credenciales en el dominio de seguridad de WebLogic, que se encargará de convertir la información de un usuario de WebLogic a formato de token SAML.
Nuestra red social |
|
|
