Archivo

Archivo del autor

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

Automatizar pruebas funcionales con soapUI

SoapUI-rest-testingLa utilización cada vez más extendida de servicios en los sistemas de información nos recuerda la necesidad de disponer de herramientas capaces de probar todos los servicios de forma exhaustiva. Además, la naturaleza propia de reutilización de los servicios hace que un error en un servicio pueda afectar a varias aplicaciones o sistemas.  Esto obliga a reducir al máximo la tasa de errores buscando que la ejecución de las pruebas garantice una gran calidad de servicio.

En primer lugar es imprescindible definir un plan de pruebas funcionales con el mayor número posible de casos de prueba. Posteriormente se deben probar todos los casos de prueba mediante algún mecanismo o herramienta.

Pruebas de la implementación o de la ejecución

El servicio está escrito en un lenguaje de programación determinado. Por lo tanto, las pruebas de la implementación nos llevan a realizar pruebas del código implementado. Para entendernos, sería la ejecución de las JUnit para código Java. Con esto podemos verificar la calidad del código y detectar errores de programación. Pero un servicio normalmente va a estar desplegado en un servidor de aplicaciones y, por lo tanto, nos interesa en este caso probar la ejecución del servicio.

La herramienta soapUI nos permite definir estos casos de test para poder ejecutarlos de forma agrupada. Los casos de test pueden llevar consigo múltiples tipos de validaciones para garantizar el correcto funcionamiento del servicio.

Pruebas Funcionales en soapUI

Las pruebas funcionales en soapUI se crean a partir del WSDL del servicio (podéis encontrar más información en el post soapUI: Probar Web Services de forma rápida y efectiva). Una vez que se han creado todos los casos de prueba para todas las operaciones del servicio, podemos probar de forma muy sencilla todos los casos con un sólo click.

Test Suite sin ejecutar

Test Suite sin ejecutar

En la imagen anterior tenemos una test suite que realiza los casos de prueba de las tres operaciones que tiene este servicio concreto. La ejecución de la test suite lanza todos sus casos de prueba y muestra el resultado de cada uno de ellos.

Ejecución de Test Suite

Ejecución de Test Suite

Leer más…

Cómo implantar una arquitectura SOA (III): ¿Cómo controlamos los servicios?

avanttic_SOA_3-3El é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:

Áreas y Beneficios del Gobierno SOA

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:

Fases del ciclo de vida de un servicio

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.

Cómo implantar una arquitectura SOA (II): ¿Qué debemos hacer?

avanttic SOAAl 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:

Ejemplo de Tareas en el área de Organización

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.

Hoja de Ruta

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.

Objetivos de la Hoja de Ruta

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?

avanttic_SOA_1-3La 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.

Niveles SOA según los Modelos de Referencia

  1. Oportunista: Utilización de servicios en un proyecto muy concreto porque se le prevé un beneficio inmediato.
  2. Sistemático: La arquitectura SOA se utiliza ampliamente en los proyectos. Proyectos de integración, ciclo de despliegue de los servicios, estandarización…
  3. Empresarial: Automatización de procesos. BPM, BPEL, Gestión SOA se incorpora a la dirección.
  4. Medición: Cuantificar y cualificar SOA. SLAs de servicio, BAM para indicadores de negocio. Los conocedores del proceso dirigen la optimización.
  5. 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.

Areas del Modelo de Referencia SOA

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:

Resultado del estudio de Niveles SOA

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.

Categorías:Tech - Integration 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.

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.

Clase que implementa la función getEnvironmentVariables

Leer más…