Política de mediación para servicios objetivo: construcción de una mediación dinámica para WebSphere ESB V7 en base al servicio objetivo seleccionado

Este artículo muestra cómo usar la función de políticas de mediación extendida proporcionada en WebSphere ESB V7 para aplicar mediación de políticas condicionalmente en base al servicio objetivo invocado y cómo adjuntar y usar políticas de mediación en servicios objetivo, tanto a nivel de servicio como de operación. Este artículo incluye un escenario basado en el patrón de puerta de enlace de servicios, el cual resulta ideal para las políticas de mediación de servicios objetivo, y otro que muestra cómo simplifican el flujo de mediación estas políticas de mediación.

Callum Jackson, Software Engineer, IBM

Photo of Callum Jackson Callum Jackson is a Software Engineer on the WebSphere ESB team at the IBM Hursley Software Lab in the UK. He has worked on the WebSphere ESB team since 2005, and before that he worked in Software Services on SOA applications for the telecommunications industry. You can contact Callum at callumj@uk.ibm.com.



Brian Hulse, Senior Software Engineer, WebSphere Service Registry and Repository, IBM

Brian Hulse photoBrian Hulse es Senior Software Engineer de WebSphere Enterprise Service Bus en Hursley, Reino Unido. Brian ha trabajado en el desarrollo de software desde Hursley durante 20 años y en los últimos cinco se ha dedicado a temas SOA.



01-08-2011

Introducción

Este artículo muestra cómo usar la función de políticas de mediación extendida proporcionada en IBM® WebSphere® Enterprise Service Bus (en adelante, “WebSphere ESB”) V7. El artículo explica cómo adjuntar y usar políticas de mediación en servicios objetivo. Los ejemplos muestran cómo usar políticas de mediación adjuntadas al nivel de servicio y al nivel de operación. Los escenarios descriptos se basan en un patrón de puerta de enlace de servicios, el cual se presta para el uso de políticas de mediación de servicios objetivo. El uso de políticas de mediación en un escenario de puerta de enlace de servicios se traduce en una simplificación del flujo de mediación.

WebSphere ESB V6.2 incorporó la habilidad de controlar la configuración de un flujo de mediación usando documentos de políticas de mediación almacenados en WebSphere Service Registry and Repository (WSRR). Para obtener más información sobre este tema, consulte el artículo What's new in WebSphere ESB V6.2, Part 3: Mediation Policy. En WebSphere ESB V6.2, las políticas de mediación se referenciaban en WSRR a través del módulo SCA que contenía el flujo de mediación en cuestión; éste podría considerarse el “alcance” que tenían las políticas de mediación. WebSphere ESB V7 extiende el concepto de alcance para abarcar al servicio objetivo del flujo de mediación. Además, permite la aplicación de políticas de mediación en los siguientes puntos de alcance de servicios objetivo:

  • Servicio
  • Punto final
  • Operación

Estos puntos de alcance permiten configurar el flujo de mediación condicionalmente en base al servicio, al punto final o a la operación que se invoque. Este artículo muestra ejemplos de la vida real de los niveles de servicio y operación. Los ejemplos se basan en un patrón de puerta de enlace de servicios, patrón muy poderoso en lo que respecta a las políticas de mediación de servicios objetivo. Una opción posible es establecer una puerta de enlace para numerosos servicios de back-end con un patrón estándar de funcionalidad, registro y transformación de mediación donde el registro y el tipo de transformación dependan del servicio o la operación llamada. De esta manera, es posible tener un flujo de mediación único y simplificado con políticas de mediación aplicadas condicionalmente, en lugar de tener flujos o ramas múltiples para los distintos servicios a los que se apunta.

WebSphere ESB V7 también incorpora la habilidad de administrar las políticas de mediación en WSRR a través de widgets de Business Space, los cuales se referencian a lo largo de todo este artículo.

Diseño del flujo

Ambos escenarios incluyen una puerta de enlace al frente de dos servicios del área de RR.HH. Uno de los servicios administra solicitudes de empleo (Application) y el otro administra consultas generales de RR.HH. (Employee). Cada uno de estos servicios construye un identificador de solicitudes de distinta manera y, por consiguiente, cada uno requiere de una transformación diferente a aplicarse en el flujo de transformación. Asimismo, en el primer escenario existe una necesidad de negocios: todas las interacciones con el servicio Application deben registrarse con fines de auditoría, mientras que en el servicio Employee esto no es necesario. El registro puede realizarse mediante un único flujo con una primitiva de registro que se active o desactive a través de una política de mediación y una primitiva XLST para aplicar una transformación diferente para cada servicio basándose en información contenida por una política de mediación externamente almacenada.

Interfaces y tipos de datos

Por tratarse de un patrón de puerta de enlace de servicios, la interfaz usada deberá ser la interfaz de puerta de enlace de servicios:

Figura 1. Interfaz de puerta de enlace de servicios
Interfaz de puerta de enlace de servicios

A continuación se describen los servicios objetivo:

Figura 2. Interfaz de servicio Application de RR.HH.
Interfaz de servicio Application de RR.HH.
Figura 3. Interfaz de consulta Employee de RR.HH.
Interfaz de consulta Employee de RR.HH.

Los tipos de datos referenciados son:

Figura 4. Tipo de datos de Application
Tipo de datos de Application

El flujo de mediación construye el applicationID anexando el campo dateTime al apellido del solicitante:

Figura 5. Tipo de datos de Employee
Tipo de datos de Employee

El flujo de mediación construye el queryID anexando el campo dateTime al employeeID del empleado:

Figura 6. Tipo de datos de HRInput (entrada)
Tipo de datos de HRInput (entrada)
Figura 7. Tipo de datos de HROutput (salida)
Tipo de datos de HROutput (salida)

Si bien en este flujo podría usarse la primitiva de mediación Endpoint Lookup (búsqueda de puntos finales) estándar, esto requeriría que el flujo de mediación proporcionase el portType para la interacción, en cambio, la primitiva de mediación Gateway Endpoint Lookup (búsqueda de puntos finales en la puerta de enlace) usada en el modo Action (Acción) se complementa mucho mejor con este patrón de uso. Para realizar el trabajo de rutina en base a Action, se requiere de una pequeña adición a los WSDL que describa los servicios a los que se apunta. En los WSDL producidos por WebSphere Integration Developer para los servicios objetivo, cada operación se anota con un atributo soapAction. En servicios generados en WebSphere Integration Developer, el valor predeterminado aparece vacío, pero en estos escenarios lo actualizaremos manualmente para poder usar la primitiva de mediación Gateway Endpoint Lookup en el modo Action. A continuación se muestra un ejemplo del WSDL original correspondiente a una operación de uno de los servicios:

Figura 8. Atributo soapAction original
Atributo soapAction original

Para modificar este WSDL, abra la perspectiva Java EE y el WSDL que representa el enlace de este servicio en particular. Es necesario cambiar de perspectiva porque la perspectiva Business Integration (Integración de negocios) no muestra el enlace WSDL. Modifique soapAction para que contenga una cadena de forma operationName/portType. En este caso, la cadena es la siguiente:

Figura 9. Atributo soapAction modificado
Atributo soapAction modificado

El orden (operación seguida por portType) es importante, ya que facilitará el procesamiento en el segundo escenario de flujo de políticas de mediación a nivel de operación. Realice este cambio en las cuatro operaciones referenciadas en este escenario. Ahora está listo para construir el flujo en sí. Como se explicó anteriormente, el flujo usa la interfaz de puerta de enlace de servicios. Solamente se usará la operación requestResponse. El flujo es muy sencillo y esta simplicidad se debe a la menor complejidad que confiere el uso de configuración dinámica mediante políticas de mediación:

Figura 10. Flujo de solicitudes
Flujo de solicitudes
Tabla 1. Resumen de las primitivas de mediación del flujo de solicitudes
Nombre de la primitivaDescripción
findEndpointByActionLa primitiva de mediación Gateway Endpoint Lookup (Búsqueda de puntos finales en la puerta de enlace) extrae la información del servicio objetivo de WSRR basándose en soapAction.
getPolicyLa primitiva de mediación Policy Resolution (Resolución de políticas) extrae las políticas de mediación asociadas con un servicio objetivo seleccionado por findEndpointByAction y las ubica en el mensaje para que puedan actuar en base a las otras primitivas de mediación.
logMessageLa primitiva de mediación Message Logger (Registro de mensajes) registra el mensaje sujeto al control de las políticas de mediación.
buildIdentifierLa primitiva de mediación XSLT construye un identificador (usado por el servicio objetivo) a partir de los detalles del mensaje. La política de mediación controla qué transformación se usa.
reassertMessageTypeLa primitiva de mediación Set Message Type (Establecimiento de tipo de mensaje) reafirma el tipo del mensaje en la puerta de enlace de servicios antes de llamar al servicio objetivo.

Las siguientes secciones explican el uso de cada una de estas primitivas de mediación. En primer lugar, debemos configurar el nodo de entrada.

Nodo de entrada

El mensaje llega a este flujo de mediación como un servicio de la puerta de enlace de servicios, es decir que su tipo no se ha establecido en base al servicio objetivo. Como en una etapa posterior del flujo se deberá examinar el contenido del cuerpo para construir el identificador, será necesario informar al flujo que se requiere de una conversión a un tipo de mensaje específico. Esta acción tiene el efecto de analizar automáticamente el TextBody entrante a la representación de objeto concreto que se esperaría en un módulo con fuerte establecimiento de tipos. Para que esto sea posible, toda la información de esquemas debe estar disponible para los tipos de mensajes que se transmiten a través de la puerta de enlace de servicios. Esta función se realiza mediante una casilla de verificación dentro de las propiedades del nodo de entrada:

Figura 11. Propiedades del nodo de entrada
Propiedades del nodo de entrada

findEndpointByAction

Esta primitiva de mediación ofrece varios modos de operación. En este caso, le pediremos que busque puntos finales a través de Action:

Figura 12. Propiedades de Gateway Endpoint Lookup
Propiedades de Gateway Endpoint Lookup

Esta primitiva de mediación está configurada para usar una instancia WSRR específica y su definición debe configurarse en la consola de administración de WebSphere. En este caso, se usa la definición predeterminada de WSRR. Para obtener más información sobre esta tarea, consulte el Centro de información de WebSphere ESB V7.

getPolicy

Esta primitiva de mediación también ofrece varios modos de operación. En este caso, se buscará extraer las políticas asociadas con el servicio objetivo:

Figura 13. Propiedades de Policy Resolution
Propiedades de Policy Resolution

Esta primitiva de mediación usa la definición predeterminada del registro. La definición del registro debe coincidir con la usada en Gateway Endpoint Lookup.

logMessage

Es necesario que el registro de mensajes sea dependiente de la política de mediación, para lo cual deberá promoverse la propiedad enabled (activado) de la primitiva de mediación. En este ejemplo, se promovió la propiedad con el nombre de grupo Audit (Auditoría), el alias enabled y un valor predeterminado false. Veremos estos valores más adelante, cuando creemos una política de mediación para establecer el valor de uno de los servicios en true (verdadero).

Figura 14. Propiedades de Message Logger
Propiedades de Message Logger

buildIdentifier

Esta es la segunda primitiva de mediación que controlará la política de mediación, por consiguiente, para lograr una configuración dinámica, se requerirá de la promoción de una propiedad. En este ejemplo, se promueve la propiedad Mapping File (Archivo de mapeo) con el nombre de grupo Transform (Transformación), el alias xslFile y un valor predeterminado xlst/Employee.xsl. Veremos estos valores más adelante, cuando creemos una política de mediación para cargar un archivo xsl diferente para cada servicio, lo que permitirá establecer un identificador distinto para cada servicio. También será necesario crear un archivo xsl diferente para cada transformación. Para obtener más información sobre esta tarea, consulte el artículo de developerWorks What's new in WebSphere ESB V6.2, Part 3: Mediation Policy.

Figura 15. Propiedades de XSLT
Propiedades de XSLT

reassertMessageType

Al seleccionar el mensaje Automatically convert the ServiceGateway (Convertir automáticamente la puerta de enlace de servicios) en el nodo de entrada, se estableció con éxito el tipo de mensaje para que sea específico al servicio objetivo en particular. Sin embargo, el flujo continúa siendo un flujo de puerta de enlace servicios, por lo cual será necesario reafirmar el tipo de mensaje ServiceGateway antes de llamar al servicio:

Figura 16. Propiedades de Set Message Type
Propiedades de Set Message Type

Importación a WSRR

El flujo ahora está listo para la interacción con WSRR. WebSphere ESB V7 ofrece una nueva habilidad para crear y adjuntar políticas de mediación usando widgets de Business Space pero, antes que nada, es necesario hacer que WSRR tenga conocimiento de:

  • El vocabulario de los dominios de las políticas de mediación que se encuentran dentro de este flujo de mediación (en este caso son los grupos Audit y Transform).
  • Los WSDL que definen los servicios junto con nuestras anotaciones soapAction, para que Gateway Endpoint Lookup pueda encontrarlos.

Para que WSRR tenga conocimiento de estos aspectos, necesitará acceso a la consola de administración de WSRR.

Módulo SCA

Desde la perspectiva Business Integration, seleccione Export (Exportar) y use la opción Integration modules and libraries (módulos y bibliotecas de integración) seguida de la opción Files for server deployment (archivos para implementación de servidor) para crear un archivo EAR que contenga el módulo SCA que contiene al flujo de mediación. Importe este archivo EAR al sistema WSRR para ser usado por las primitivas de mediación Policy Resolution y Gateway Endpoint Lookup en el flujo de mediación.

WSDL y esquemas

Desde la perspectiva Business Integration, seleccione Export y elija la opción WSDL and XSD seleccionando todos los WSDL y XSD usados en el flujo. Importe estos WSDL al mismo sistema WSRR donde se encuentra el módulo SCA. Con esta acción hemos terminado con la consola WSRR; todo el resto del trabajo administrativo lo realizaremos a través de Business Space.

Creación y adjunción de políticas de mediación

Antes de usar Business Space para administrar las políticas de mediación, se deberá instalar el módulo SCA en un sistema del tiempo de ejecución de WebSphere ESB (WebSphere Process Server). Siga los procesos locales necesarios para instalar el módulo SCA que contiene el flujo de mediación de la puerta de enlace de servicios.

Abra la direcciónhttp://localhost:9080/BusinessSpace/en un navegador soportado por Business Space (use la raíz de direcciones apropiada para su tiempo de ejecución). Se abrirá la página de bienvenida de Business Space. Cree un nuevo espacio para administrar sus políticas de mediación: seleccione Actions => Create space (Acciones=> Crear espacio). Luego de proporcionar un nombre adecuado para el nuevo espacio, seleccione Service Administration (Administración de servicios) del desplegable de Create a new space using a template (Crear un espacio nuevo usando una plantilla). Cuando el espacio se haya creado, seleccione la pestaña Service Administration, la cual le permite crear y adjuntar nuevas políticas de mediación. El widget izquierdo es el Navegador de servicios y muestra los servicios que están siendo ejecutados por el sistema de tiempo de ejecución. En este ejemplo, los dos servicios de back-end poseen las siguientes etiquetas:

  • Export1_EmployeeHttpService
  • Export1_ApplicationHttpService

Deberá adjuntar políticas de mediación a estos dos servicios. En la figura a continuación, el primer servicio aparece expandido para mostrar los distintos puntos de adjunción disponibles. Estos aparecen bajo la etiqueta Mediation Policies (Políticas de mediación):

Figura 17. Navegador de servicios
Navegador de servicios

Seleccione la definición WSRR antes de comenzar a trabajar con las políticas de mediación. En este caso, la definición WSRR se llama radcliffe y aparecerá con este nombre en la consola de administración de WebSphere. La siguiente tabla explica en detalle los puntos de adjunción mostrados:

Tabla 2. Puntos de adjunción de políticas de mediación
Nombre del adjuntoAlcanceDescripción
Export1_EmployeeHttpServiceServicioToda política de mediación adjuntada en este nivel de alcance se aplica a todas las invocaciones del servicio.
Export1_EmployeeHttpPortPunto finalToda política de mediación adjuntada en este nivel de alcance se aplica a todas las invocaciones del punto final específico.
askHROperaciónToda política de mediación adjuntada en este nivel de alcance se aplica a todas las invocaciones de la operación nombrada.
addEmployeeOperaciónToda política de mediación adjuntada en este nivel de alcance se aplica a todas las invocaciones de la operación nombrada.

En este primer escenario, se busca que las políticas de mediación se apliquen en base al servicio invocado, para lo cual deberá seleccionar el nivel de servicio en el Navegador de servicios, en este caso: Export1_EmployeeHttpService bajo el encabezado Mediation Policies. Con el nivel de alcance seleccionado en el widget izquierdo, el widget derecho con la etiqueta Mediation Policy Administration (Administración de políticas de mediación) indicará que se encuentra cargando los adjuntos. En principio, el resultado será una lista vacía, ya que no hemos adjuntado ninguna política de mediación – antes de adjuntarlas, debemos crearlas. En el primer escenario, el registro del servicio Employee debe estar desactivado. Aunque el registro se encuentra desactivado de manera predeterminada en esta primitiva de mediación en particular, deberá crear una política de mediación para controlarlo y que luego sea posible realizar cambios dinámicos en la estrategia sin tener que volver a implementar el flujo.

Creación de un adjunto de políticas

Ingrese el nombre del nuevo adjunto de políticas en el campo de entrada con la etiqueta New Policy Attachment (Nuevo adjunto de políticas), en este caso se ingresó el nombre EmployeeServiceAttachment. Elija un nombre pertinente para este adjunto. Luego haga clic en Create (Crear):

Figura 18. Creación de un adjunto de políticas
Creación de un adjunto de políticas

El widget muestra el nivel de alcance en el que se crea el adjunto (en este caso, nivel de servicio) junto con el punto de adjunción específico (Export1_EmployeeHttpService).

Creación de una política de mediación

El próximo panel demora unos segundos en cargar porque debe mostrar los nombres de grupos de políticas de mediación disponibles en el tiempo de ejecución. Esto lo logra contrastando los módulos con los mismos módulos SCA en el WSRR referenciado; este es uno de los motivos por los cuales el módulo SCA debe ser importado a WSRR además de instalarse en el sistema de tiempo de ejecución. La Figura 19 muestra que existen sólo dos grupos disponibles en este caso: Audit y Transform. También muestra qué módulos soportan estos grupos, ya que los módulos pueden soportar grupos múltiples y los grupos pueden estar disponibles a lo largo de módulos múltiples:

Figura 19. Creación de una política de mediación
Creación de una política de mediación

Luego de seleccionar un grupo, el widget carga todas las políticas de mediación existentes dentro de ese grupo para permitirle usar una política existente o crear una nueva. Este ejemplo usa el grupo Audit y, en lugar de usar la política predeterminada de este grupo, crea una nueva, ingresa el nombre AuditDisabled como nombre de política de mediación y hace clic en Next (Siguiente). Nuevamente, se recomienda usar nombres pertinentes para la creación de políticas mediación. Para usar una política de mediación existente, seleccione Use Existing (Usar existente) y se abrirá un desplegable que mostrará todas las políticas de mediación que se encuentran dentro del grupo seleccionado en el sistema WSRR especificado.

Adición de una aserción

El próximo panel demora unos segundos en cargar porque debe buscar el vocabulario (la lista de aserciones) disponible en el grupo de políticas de mediación seleccionado. Existe una sola aserción en el grupo Audit denominada enabled. Esto es exactamente lo mismo que se especificó en las propiedades promovidas del flujo de mediación. En esta política de mediación, el valor debe ser false. La Figura 20 muestra el panel con la aserción a punto de agregarse. Haciendo clic en Add Assertion (Agregar aserción), la nueva aserción aparecerá en la lista. Este panel también permite incorporar condiciones de puerta, las cuales no se usan en este escenario porque la condicionalidad se relaciona con servicios objetivo y no con contenidos de mensajes.

Figura 20. Adición de una aserción dentro de una política de mediación
Adición de una aserción dentro de una política de mediación

La siguiente figura muestra la nueva política de mediación con la aserción recién agregada. El panel también muestra los siguientes datos:

  • Nombre de adjunto de políticas -- EmployeeServiceAttachment
  • Nombre de política de mediación -- AuditDisabled
  • Nivel de alcance -- Service
  • Punto de adjunción -- Export1_EmployeeHttpService
  • Aserciones dentro de esta política de mediación -- activadas en el grupo Audit

Haga clic en Save (Guardar) para crear todos los documentos en el WSRR referenciado:

Figura 21. Nueva aserción dentro de una política de mediación
Nueva aserción dentro de una política de mediación

El widget vuelve al panel original y ahora muestra el adjunto de políticas que acabamos de crear:

Figura 22. Nuevo adjunto de políticas
Nuevo adjunto de políticas

Ahora ha adjuntado una política de mediación que desactivará el registro en todas las invocaciones del servicio Employee. Aún queda trabajo por hacer: resta crear y adjuntar tres políticas de mediación más para soportar este escenario. El proceso para hacerlo es básicamente igual el descripto anteriormente. A continuación se detalla un resumen de todas las políticas de mediación requeridas en este escenario:

Tabla 3. Escenario de políticas de mediación basadas en servicios
PolíticaGrupoAserciónPunto de adjunción (alcance)
AuditDisabledAuditenabled=falseExport1_EmployeeHttpService
AuditEnabledAuditenabled=trueExport1_ApplicationHttpService
EmployeeTransformTransformxslFile=xslt/Employee.xslExport1_EmployeeHttpService
ApplicationTransformTransformxslFile=xslt/Application.xslExport1_ApplicationHttpService

Con todas estas políticas de mediación en funcionamiento, cada vez que se llame al servicio Employee no se realizará registro y se usará xslt/Employee.xsl en la transformación. Asimismo, cada vez que se llame al servicio Application, se realizará registro y se usará xslt/Application.xsl en la transformación.

Extensión al alcance de operación

El segundo escenario se basa en el primero y se muestra a efectos de demostrar cómo se pueden aplicar políticas de mediación condicionalmente en base a la operación llamada. Los pasos de creación del flujo, anotación de WSDL, exportación desde WebSphere Integration Developer, importación a WSRR e instalación en el tiempo de ejecución son iguales a los del primer escenario. En este segundo escenario, se usarán las mismas transformaciones que definimos anteriormente, ya que la creación del identificador se vincula mejor con el alcance de servicio. Sin embargo, se efectuarán cambios en lo que respecta al registro, como se muestra a continuación:

  • registerApplicant en el servicio Application deberá tener el registro activado
  • addEmployee en el servicio Employee deberá tener el registro activado
  • getApplicantStatus en el servicio Application deberá tener el registro desactivado
  • askHR en el servicio Employee deberá tener el registro desactivado

El proceso es igual al del primer escenario, con excepción de que, cuando se crean los adjuntos de políticas de registro, se selecciona la operación relevante. Por ejemplo, para crear un adjunto de políticas para addEmployee se procederá de la siguiente manera:

Figura 23. Adjunción de políticas en el nivel de alcance de operación
Adjunción de políticas en el nivel de alcance de operación
Tabla 4. Escenario de políticas de mediación basadas en operaciones
PolíticaGrupoAserciónPunto de adjunción (alcance)
AuditEnabledAuditenabled=trueaddEmployee
AuditEnabledAuditenabled=trueregisterApplicant
EmployeeTransformTransformxslFile=xslt/Employee.xslExport1_EmployeeHttpService
ApplicationTransformTransformxslFile=xslt/Application.xslExport1_ApplicationHttpService

Si este escenario se desarrolla inmediatamente después del primero, deberá eliminar los adjuntos de políticas en los dos niveles de servicio que controlan el registro.

Eliminación de adjuntos de políticas

La figura a continuación muestra el adjunto de políticas creado antes en el nivel de servicio para el servicio Employee. Seleccione el adjunto y mueva el cursor hacia la esquina derecha de la selección. Aparecerán dos íconos. Seleccione el ícono de lápiz para abrir el adjunto y ver las aserciones y las condiciones de puerta en aplicación. El ícono de la cruz elimina el adjunto de políticas. Para lograr que el registro de este escenario sea completamente impulsado por las operaciones, elimine los dos adjuntos de nivel de servicio que controlan el registro:

Figura 24. Eliminación de adjunto de políticas
Eliminación de adjunto de políticas

Flujo de mediación que usa políticas de mediación de nivel de operación

El flujo de mediación es básicamente igual al flujo antes descripto para las políticas de mediación de nivel de servicio. Se requiere de una primitiva de mediación adicional: debe informarse a Policy Resolution (Resolución de políticas) la operación que se encuentra activa. Esto se lleva a cabo verificando el campoOperation en el SMOHeader. En el patrón de puerta de enlace, esta es la operación generalizada es requestResponse; el flujo debe ocuparse de proporcionar el nombre de la operación servicio objetivo que se llama. Se trata de una tarea trivial, porque, de hecho, ya conocemos la operación porque se encuentra codificada en Action en forma operationName/portTypeName. Entonces, coloque una primitiva Message Element Setter (Establecimiento de elementos de mensaje) antes de la primitiva de mediación para interpretar el campo Action y cargue el campo Operation. El nuevo flujo se verá así:

Figura 25. Flujo de solicitud de políticas de mediación de nivel de operación
Flujo de solicitud de políticas de mediación de nivel de operación

setOperation

Message Element Setter simplemente copia la primera parte del campo Action al campo Operation; ambos campos se encuentran en el SMOHeader:

Figura 26. Propiedades de Message Element Setter
Propiedades de Message Element Setter

La primitiva de mediación Policy Resolution actúa en base al campo Operation, extrayendo todas las políticas de mediación asociadas a él en WSRR. También extrae y usa todo el resto de las políticas de mediación que resultan relevantes, como las políticas de mediación de nivel de servicio.

El segundo escenario es simplemente una extensión del primero que requiere que la primitiva de mediación Policy Resolution esté informada de la operación en funcionamiento. Más allá de esto, ahora puede configurar el flujo en base al servicio o la operación simplemente cambiando las políticas de mediación a través de Business Space; no será necesario reimplementar el flujo de mediación.

Conclusión

La incorporación de políticas de mediación basadas en servicios en WebSphere ESB V7 crea una herramienta muy poderosa que simplifica los flujos de mediación y aporta configuración dinámica a través de metadatos externos almacenados en WSRR. Este artículo explicó cómo crear un flujo de mediación dinámico y demostró que el patrón de puerta de enlace de servicios se presta perfectamente para usar políticas de mediación basadas en servicios u operaciones dentro de esta configuración dinámica.


Descargas

DescripciónNombretamaño
Code sampleDummyWebServices_PI.zip25 KB
Code sampleHR_Operation_PI.zip127 KB
Code sampleHR_Service_PI.zip125 KB

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=475929
ArticleTitle=Política de mediación para servicios objetivo: construcción de una mediación dinámica para WebSphere ESB V7 en base al servicio objetivo seleccionado
publish-date=08012011