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.
Cómo implantar una arquitectura SOA (III): ¿Cómo controlamos los servicios?
El éxito de la implantación de una arquitectura orientada a servicios depende en gran medida de realizar de forma adecuada las acciones definidas en la Hoja de Ruta SOA (ver post Hoja de Ruta SOA), cuyo contenido se ha podido determinar gracias al conocimiento exacto del Nivel de Madurez SOA de la organización (ver post Nivel de Madurez SOA).
Pero sólo con esto no es suficiente. Una vez que se ha instalado la plataforma que da soporte a la arquitectura SOA, es necesario instaurar un Modelo de Gobierno SOA que gestione y controle los servicios que poco a poco se irán desplegando en los sistemas.
Según Gartner: El Gobierno SOA sigue siendo crucial.
”El Gobierno SOA trata sobre la disciplina y el aseguramiento para que las decisiones muy importantes pasen por las personas adecuadas y que éstas personas tengan la información adecuada para tomar esas decisiones. Eso es la mitad del problema de la gobernabilidad de SOA. La segunda mitad viene cuando se han tomado dichas decisiones, y el Gobierno SOA tiene que asegurar su aplicación efectiva.”
El Gobierno SOA tiene como propósito ejercer el control sobre los procesos de definición, creación y explotación de los servicios en una Arquitectura SOA. Esto implica definir una serie de procedimientos que aseguren y permitan controlar que se cumplen una serie de normativas y especificaciones cuyo cumplimiento garantice el éxito de la adopción de una Arquitectura SOA.
Las áreas sobre las que se deben especificar las normativas y procedimientos son las siguientes:
El Gobierno SOA debe establecer controles sobre cada una de las fases del ciclo de vida de un servicio. El ciclo de vida de un servicio se inicia cuando se estudia la posibilidad de creación de un servicio hasta que entra en retirada productiva. A continuación se muestra cada una de estas fases:
Hasta el momento, hemos indicado qué es lo que deberíamos hacer para la adecuada explotación de una Arquitectura SOA. El Gobierno SOA nos va a decir cómo debemos hacerlo. Los procesos de control del Gobierno SOA establecen acciones sobre cada una de las fases del ciclo de vida de un servicio.
Tras la especificación y definición de mecanismos de control de las distintas fases y etapas del ciclo de vida de los servicios, hay que poder ejecutarlos de forma adecuada y solvente. Para ello, se recomienda la creación de una Oficina Técnica SOA que garantice y articule el cumplimiento de las normativas y procedimiento establecidos en el Modelo de Gobierno. Si no hay suficiente volumen de servicios para la creación de una oficina técnica, bastará con disponer de al menos una persona que se encargue de las tareas de gestión y control del ciclo de vida de los servicios. De lo contrario, se corre el riesgo de desperdiciar todo el trabajo realizado en el modelo de gobierno y, lo que es todavía peor, que la implantación de la arquitectura SOA no se realice con éxito.
Cabeceras personalizadas y procesos Oracle BPEL
En el momento de definir nuestros servicios web, nos podemos encontrar con la necesidad de incluir cabeceras personalizadas que aporten información añadida a las distintas operaciones del mismo.
Si estos servicios van a ser consumidos por una aplicación SCA, como puede ser un proceso BPEL, recomiendo seguir el siguiente consejo: incluir nuestra cabecera en la definición el mensaje.
Seguimos el orden de definición del WSDL para explicar nuestro caso. Si nos ceñimos a los elementos del contrato que nos conciernen, empezamos por la definición de mensajes.
Es común crear un mensaje que represente nuestra cabecera personalizada para reutilizarlo e implementar el siguiente formato:
<wsdl:message name="HeaderPersonalizado"> <wsdl:part name="cabecera" element="client:miCabecera"/> </wsdl:message> ... <wsdl:operation name="operacion1"> <soap:operation style="document" soapAction="http://xmlns.Avanttic.com/Blog/HeaderPersonalizado/operacion1"/> <wsdl:input> <soap:body use="literal" parts="payload"/> <soap:header message="client:HeaderPersonalizado" part="cabecera" use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal" parts="payload"/> </wsdl:output> </wsdl:operation>
Aún siendo correcto, generar un contrato con este formato implica que el envío de la cabecera desde un proceso BPEL sea ligeramente más complejo. Veamos los pasos que realizaríamos para este caso:
- Generar una variable del tipo miCabecera:
<variable name="miCabecera" element="client:miCabecera"/>
- Asignar los valores correspondientes a la cabecera mediante la actividad Assign.
- Asignar esta variable a la cabecera de la actividad Invoke.
En este punto nos encontramos con la particularidad de que la IDE de JDeveloper no permite realizar este paso y es necesario acceder al código fuente de la actividad y agregar la propiedad bpelx:inputHeaderVariable:
<invoke name="Ejecutar" partnerLink="ServicioWeb" portType="client:HeaderPersonalizado" operation="operacion1" inputVariable="Ejecutar_InputVariable" outputVariable="Ejecutar_OutputVariable" bpelx:invokeAsDetail="no" bpelx:inputHeaderVariable="miCabecera"/>
Veamos ahora otra forma de pasar nuestra cabecera siguiendo la recomendación inicial: incluir la cabecera en la definición del mensaje.
Leer más…
Cómo implantar una arquitectura SOA (II): ¿Qué debemos hacer?
Al implantar una Arquitectura Orientada a Servicios (SOA), el primer paso en el camino es determinar cuál es la situación real de la empresa respecto a la orientación a servicios (como vimos en el post anterior ¿De dónde partimos?). Con esa información en nuestro poder, se define una serie de tareas y acciones que se deben realizar para implantar la arquitectura. Es lo que se denomina Hoja de Ruta SOA. La Hoja de Ruta SOA proporciona respuesta a aquellas cuestiones que surgen antes de iniciar la implantación:
- ¿Qué pasos tenemos que dar para adoptar SOA en nuestra organización?
- ¿Cómo tengo que dar esos pasos para asegurar el éxito?
- ¿A quién necesito para hacer la implantación?
- ¿Qué hardware y software me da garantías?
- ¿Recuperaremos la inversión?
- …
Las tareas y acciones que se definen están orientadas a mejorar en cada una las áreas del Modelo de Referencia SOA, y por tanto, a aumentar el nivel de madurez SOA. Recordemos que se llega al nivel más alto de la escala de niveles cuando las aplicaciones dan soporte al negocio de forma rápida y barata. Las áreas del Modelo de Referencia SOA son las siguientes (encontraréis más información en el post anterior ¿De dónde partimos?):
- Estrategia
- Procesos
- Gobierno
- Organización
- Métodos
- Arquitectura
- Infraestructura
- Aplicaciones
Un posible ejemplo de acciones a realizar para mejorar el área de Organización podría ser el siguiente:
Estas tareas y acciones se deben realizar en un plazo concreto de tiempo que determinará el alcance la hoja de ruta. El plazo de cobertura de una hoja de ruta debe oscilar entre 1 y 3 años en función de las necesidades y objetivos de la empresa. Por lo tanto, en base al plazo establecido, el número de acciones variará sensiblemente.
Una vez establecidas todas las tareas a realizar, se deben ordenar en el tiempo para facilitar su elaboración de forma adecuada. El ritmo de tiempo tiene que estar adaptado a la dinámica de la empresa y a los recursos asignados para su realización.
Adicionalmente al calendario de acciones, en la Hoja de Ruta se debe especificar de forma clara cuál es el objetivo de madurez que se pretende alcanzar para cada una de las áreas del Modelo de Referencia SOA. Este avance en cada área depende de las acciones que hayan sido especificadas para cada una de las mismas.
Además de todo lo indicado hasta ahora referente a aumentar el nivel de madurez SOA, la hoja de ruta debe incluir información sobre distintos aspectos que son necesarios para justificar y facilitar la implantación de esta arquitectura:
- Objetivos de negocio. Hay que establecer de forma precisa los objetivos de negocio que se persiguen al implantar esta arquitectura, por ejemplo, mayor competitividad al reducir los tiempos y costes de desarrollo de aplicaciones de empresa.
- Solución tecnológica. La arquitectura SOA se apoya en un software de base. Se debe elegir entre las distintas opciones que hay en el mercado.
- Metodología SOA. Se debe establecer una metodología a utilizar para la gestión del ciclo de vida de los servicios.
- Proyectos iniciales. Definir qué proyectos serán los primeros en hacerse con la nueva arquitectura.
- Formaciones necesarias. Fijar las formaciones necesarias en el corto plazo para facilitar el aprendizaje sobre la nueva tecnología.
- Gobierno SOA. Fijar las bases de un Modelo de Gobierno SOA que será el encargado de gestionar y controlar el ciclo de vida de los servicios.
- Recursos necesarios. Definir los recursos que van a ser necesarios para llevar a cabo la hoja de ruta.
- Estimaciones económicas. Realizar una estimación económica del coste de la ejecución de la hoja de ruta.
En resumen, la hoja de ruta SOA no sólo va a marcar el camino a seguir, sino que también deja claro cuál es el objetivo y qué implicaciones tiene sobre la empresa. Se trata de tener bien definido todo el trabajo durante el periodo de cobertura de la hoja de ruta. No obstante la hoja de ruta debe revisarse de forma periódica para comprobar si se está llevando a cabo de la forma esperada. Si no fuera así, sería necesario hacer una revisión para adecuar su ejecución a la realidad.
Cómo implantar una arquitectura SOA (I): ¿De dónde partimos?
La implantación de una arquitectura orientada a servicios (SOA) es una tarea compleja y multidisciplinar que requiere realizarse de forma metódica y ordenada para tratar de garantizar el éxito de la adopción.
Por este motivo se necesita realizar la incorporación de este tipo de arquitectura en la empresa mediante tareas muy concretas, al ritmo adecuado para cada caso y con un objetivo claro y conciso a medio/largo plazo.
Para poder definir apropiadamente las acciones que debe realizar una empresa para implantar y explotar este tipo de arquitectura, es necesario conocer cuál es la situación real de la empresa antes de empezar.
La industria ha determinado, según la experiencia acumulada y tras la especificación de modelos de referencia de arquitectura, una escala de niveles de madurez SOA que delimitan la situación de la empresa respecto a la orientación a servicios.
- Oportunista: Utilización de servicios en un proyecto muy concreto porque se le prevé un beneficio inmediato.
- Sistemático: La arquitectura SOA se utiliza ampliamente en los proyectos. Proyectos de integración, ciclo de despliegue de los servicios, estandarización…
- Empresarial: Automatización de procesos. BPM, BPEL, Gestión SOA se incorpora a la dirección.
- Medición: Cuantificar y cualificar SOA. SLAs de servicio, BAM para indicadores de negocio. Los conocedores del proceso dirigen la optimización.
- Industrializado: La organización es capaz de adoptar iniciativas de soporte al negocio de forma rápida y barata.
En función de la situación en la que se encuentre la empresa en el inicio, las acciones para realizar la implantación pueden variar sensiblemente. Para determinar en qué nivel se clasifica la empresa, existen ocho áreas que, según los modelos de referencia de arquitectura SOA, deben ser analizadas y evaluadas. La cuantificación se realiza analizando indicadores en cada una de las siguientes áreas.
Estrategia - Contiene las capacidades que ofrecen las construcciones de alto nivel que permiten la implantación de una iniciativa SOA.
Procesos - La gestión de una compañía por procesos representa un cambio organizativo importante respecto a la organización tradicional.
Gobierno – Estructuras de gobierno y procesos que apoyan y guían los esfuerzos de SOA. La madurez y la adopción de una cantidad adecuada de gobierno es un indicador general del éxito de SOA.
Organización – Desarrollo de la competencia empresarial en torno a SOA como la estructura organizativa y del desarrollo de habilidades.
Métodos – Contiene las capacidades relativas a los aspectos posteriores a la implementación de soluciones basadas en una arquitectura orientada a servicios, es decir, las operaciones, la administración y los aspectos de gestión de SOA.
Arquitectura – Definiciones de la estructura general y las directrices para los profesionales de diversas especialidades para garantizar la adopción de la arquitectura.
Infraestructura – Infraestructura de servicios y herramientas que proporcionan la base técnica para la iniciativa SOA.
Aplicaciones – Las aplicaciones facilitan el acceso a la información como servicios.
Tras analizar detalladamente cada uno de los distintos indicadores, de cada una de las áreas indicadas, deberíamos determinar el nivel real de la empresa dentro de la escala de niveles de madurez SOA. En el siguiente gráfico vemos un ejemplo:
El objetivo de las acciones que se lleven a cabo para la implantación de la arquitectura SOA debe estar encaminado a aumentar el nivel de madurez en un periodo de tiempo determinado. El ritmo de las acciones debe ser adecuado al ritmo de trabajo de la empresa para que no impacte en el funcionamiento de la misma, de modo que garantice que las acciones se realizan en tiempo y forma. Para concretar estas acciones, y para establecer un calendario a medio plazo, se debe elaborar una hoja de ruta SOA.
Ahora que realmente ya sabemos dónde se encuentra la empresa, las acciones que se lleven a cabo serán más adecuadas para poder cumplir nuestro objetivo.
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.
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.
typeswitch: XQuery con elementos de tipo choice
El desarrollo de servicios en OSB (Oracle Service Bus) suele conllevar la necesidad de transformar datos mediante XQuery. En este post se presenta un caso concreto, con el fin de agilizar dichos desarrollos.
La función typeswitch nos permite tratar elementos XML de tipo choice. Estos elementos proporcionan un conjunto limitado de posibles elementos de nivel inferior al consumidor de dicho contrato.
En el momento de acceder al contenido del documento generado, podemos hacer uso de esta función XQuery. Se define el conjunto de posibles elementos que puede contener y el valor a devolver en cada caso:
- Definición:
<xsd:complexType name="telefono"> <xsd:choice> <xsd:element name="fijo" type="xsd:string"/> <xsd:element name="movil" type="xsd:string"/> <xsd:element name="extension" type="xsd:string"/> </xsd:choice> </xsd:complexType>
- Función XQuery:
...
typeswitch ($telefono/( ns0:fijo | ns0:movil | ns0:extension ))
case $fijo as element(ns0:fijo)
return
concat("El teléfono fijo es: ",$fijo)
case $movil as element(ns0:movil)
return
concat("El teléfono movil es: ",$movil)
case $ext as element(ns0:extension)
return
concat("La extensión telefónica es: ",$ext)
default
return ()
...
Incluido dentro de un bucle, nos permitiría obtener todos los datos de contacto de un usuario con repeticiones de cada uno de los elementos, por poner un ejemplo.
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).
Nuestra red social |
|
|
