Archivo
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.
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.
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 |
|
|
