Explorando Feature Pack for SCA del servidor de aplicaciones WebSphere: Parte 3: Intenciones y directivas disponibles en Feature Pack for SCA

La Parte 3 de esta serie sobre IBM®WebSphere®Application Server V7 Feature Pack for SCA describe el soporte necesario para especificar los requisitos de Calidad de Servicio (QoS por su sigla en inglés) para que el paquete de funciones cumpla con el marco de directivas SCA y especificaciones de transacciones SCA. El Feature Pack ofrece el marco necesario para describir los requisitos de directivas abstractas a través de intenciones, y aplica capacidades o limitaciones especiales a los servicios y a las referencias mediante el uso de conjuntos de directivas. Cuando sea necesario, la muestra de uso de estas características estará destacada.

Chao M Beck, Software Engineer, IBM

Chao Beck es Technical Lead del paquete de funciones para el programa inicial de SCA (Service Component Architecture). Desde hace tiempo es miembro del equipo de programas iniciales de Application Integration Middleware, responsable de la ejecución de programas iniciales para los productos IBM WebSphere Application Server. Chao se dedica a desarrollar y dar capacitación en nuevas funciones de productos y brindar soporte al cliente en programas previos a la disponibilidad general (pre-GA o iniciales) y programas posteriores a la disponibilidad general (post-GA o aceleración del cliente).



Anbumunee Ponniah, Software Engineer, IBM

Anbumunee Ponniah es senior tester/developer en el equipo SCA Feature Pack.



Mark B Coats, Advisory Software Engineer, IBM

Mark Coats es senior developer para WebSpere Application Server, donde se epecializa en servicios web y en la consola de administración. Antes se desempeñó como desarrollador de CORBA Object Request Broker y como ingeniero en sistemas de comunicación en Attachmate Corporation.



28-07-2011

Introducción

El IBM WebSphere Application Server Feature Pack for Service Component Architecture (SCA) provee un marco para describir los requisitos de directivas abstractas a través de intenciones de SCA, y para aplicar capacidades o restricciones especiales a los servicios y a las referencias mediante el uso de conjuntos de directivas SCA. Una intención SCA es una aserción abstracta sobre la Calidad de Servicio (QoS) usada para describir los requisitos de los componentes, el servicio y las referencias de SCA. Una directiva define una capacidad o restricción especial. Las directivas en SCA se asocian a los servicios y a las referencias a través del elemento PolicySet . Los desarrolladores generalmente usan las intenciones para especificar las aserciones amplias que se necesitan para lograr el comportamiento de servicio deseado. El ensamblador y el implementador disponen de opciones para asociar la directiva concreta adecuada usando estas intenciones como guía.

El paquete de funciones soporta:

  • Intenciones
    • Interactividad:
      • Autenticación
      • Confidencialidad
      • Integridad
      • Mensajería confiable
    • Implementación:
      • Transacciones
  • Directivas
    • Interactivas (según los estándares existentes para Especificación WS y adjunciones de Especificación WS):
      • Autenticación
      • Confidencialidad
      • Integridad
      • Mensajería confiable
    • Implementación:
      • Directiva de seguridad
        • Autorización
        • Identidad de seguridad
      • Directiva de transacciones

Interactiva las intenciones y las directivas se refieren a restricciones que afectan la interacción entre servicios y referencias. Implementación estos tipos especifican cómo el contenedor SCA debería condicionar al entorno para que se realice la ejecución correcta de los componentes.


Directivas e intenciones interactivas

Autenticación, confidencialidad e integridad

Las aplicaciones usan intenciones de seguridad cuando es necesario proteger el acceso a datos y servicios o proteger los datos transferidos entre los clientes y los servicios:

  • La intención de autenticación indica que el cliente debe identificarse a si mismo para invocar un servicio SCA.
  • La intención de confidencialidad indica que el contenido de un mensaje está protegido y sólo pueden acceder al mismo aquellas personas que están autorizadas.
  • La intención de integridad indica la necesidad de asegurarse que un mensaje no hay sido alterado con o durante la transmisión entre el remitente y el destinatario.

Las intenciones de autenticación, confidencialidad, integridad y seguridad de mensajería confiable son actualmente soportados por el Feature Pack for SCA usando solamente el enlace WS. Estas intenciones de seguridad se pueden habilitar con el calificador "transporte" si la intención se realiza a nivel del transporte del protocolo de comunicaciones, y con el calificador "mensaje" si la intención se efectúa a nivel del mensaje.

En el caso de la intención de confidencialidad, especificar el calificador transporte hace que los datos se encripten mediante el protocolo de transporte (como https), en tanto que especificar el calificador mensaje encriptará al mensaje propiamente dicho (sólo el cuerpo o con los encabezados).

La Figura 1 muestra cómo SCA integra intenciones y directivas.

Figura 1. Integración QoS
Integración QoS

Las intenciones de seguridad se especifican en el elemento binding.ws (enlace.ws). Por ejemplo, cuando los datos que se transfieren a y de un servicio con referencia deben ser confidenciales, y esta confidencialidad se debe lograr mediante la encriptación del mensaje, usted especificará las siguientes líneas (para el servicio "sampleReference") en su archivo SCDL:

Listado 1
<reference name="sampleReference"> <binding.ws
                requires="confidentiality.message" ... /> </reference>

Para especificar un requisito para que todos los accesos a un servicio sean autenticados por el protocolo de transporte, el archivo SCDL se vería así (para el servicio "AccountService"):

Listado 2
<service
                name="AccountService"> <binding.ws requires="authentication.transport"
                ... /> </service>

La directiva concreta que garantiza esta aserción es suministrada por WebSphere Application Server V7.0 y puede ser usada por los servicios, las referencias y los componentes SCA.

Usted puede adjuntar estos conjuntos de directivas concretas a proveedores de servicio y referencias de servicio usando la consola de administración del WebSphere Application Server. Una instancia de conjunto de directivas está compuesta por una recopilación de directivas. Por ejemplo, el conjunto de directivas preconfiguradas WS-I RSP consta de instancias de los tipos de de directivas WS-Security, WS-Addressing, y WS-ReliableMessaging. Cada conjunto de directivas se identifica mediante un nombre exclusivo en toda la celda.

Los servicios se pueden configurar adjuntándolos a un proveedor, sus puntos finales u operaciones. Asimismo, un conjunto de directivas se puede adjuntar a una referencia de servicio, sus puntos finales u operaciones. WebSphere Application Server también permite adjuntar conjuntos de directivas a todas las referencias o a todos los proveedores en una unidad de composición.

WebSphere Application Server ofrece conjuntos de directivas preconfiguradas que usted puede usar como puntapié inicial y adaptar luego a sus necesidades específicas. Además usted puede personalizar el conjunto de directivas adjunto usando enlaces que sean específicos para la unidad de composición (enlaces específicos para la aplicación) o usando enlaces generales. Los enlaces generales son globales en el dominio de seguridad y pueden ser compartidos por todas las aplicaciones y unidades de composición.

Figura 2. Importación de conjuntos de directivas adicionales del repositorio preconfigurado
Importación de conjuntos de directivas adicionales del repositorio preconfigurado

Un servicio o referencia de componentes SCA se puede configurar para solicitar conjuntos de directivas para servicios web específicos, especificando sus requisitos en el atributo qos.wsPolicySet del elemento del enlace. Los siguientes fragmentos de SCDL especifican el conjunto de directivas "WSHTTPS Default" adjuntado a un elemento de servicio (Listado 3) y un elemento de referencia (Listado 4):

Listado 3
<service
                name="AccountService"> <binding.ws qos.wsPolicySet="WSHTTPS default"
                ... /> </service>
Listado 4
<reference name="AccountServiceReference">
                <binding.ws qos.wsPolicySet="WSHTTPS default" ... />
                </reference>

Varios conjuntos de directivas comunes ya están importados y listos para que usted los adjunte a su servicio y unidad de composición de cliente. Para su referencia, la presente lista de conjuntos de directivas preconfiguradas ya importadas para su uso se muestra en la Figura 3.

Figure 3. Conjuntos de directivas que están importadas en la consola de administración de WebSphere Application Server
Figure 3. Conjuntos de directivas que están importadas en la consola de administración de WebSphere Application Server

Mensajería confiable

La política de mensajería confiable le permite controlar la confiabilidad de las solicitudes entre los servicios, incluyendo secuencia y garantía de entrega. Las intenciones se aplican a nivel de la operación mediante el elemento del enlace, y las directivas concretas se suministran en el conjunto de directivas WS-ReliableMessaging de WebSphere Application Server. El nivel de QoS alcanzado por WS-ReliableMessaging depende del nivel de durabilidad y del soporte de transacciones provisto por el almacenamiento de datos que se usa para administrar el estado de mensajería confiable. El Feature Pack for SCA reconoce estas calidades de servicio, suministradas por el Servidor de aplicaciones WebSphere, usando SOAP sobre los enlaces HTTP:

  • No administrado no persistente es no transaccional y permite reenviar los mensajes perdidos en la red; aunque perderá las solicitudes pendientes cuando se caiga el servidor, y no funciona en un cluster.
  • Administrado no persistente usa un motor de mensajes para almacenar solicitudes, y así puede recuperar mensajes perdidos debido a fallas en la red o el servidor. Sin embargo, los mensajes que son administrados no persistentes se pierden al reiniciarse el motor de mensajes. Estos tipos de solicitudes se pueden implementar usando clusters, así como también con una configuración de servidor única.
  • Administrado persistente es la forma más confiable, usando un motor y un almacenamiento que conserva los mensajes luego de todos los reinicios del servidor y del motor de mensajes.

El caso de uso que requiera que los mensajes de un servicio se almacenen en un motor de mensajes y persistan en todos los reinicios del servidor necesitará especificar lo siguiente en su SCDL (para el servicio "OrderStatusService"):

Listado 5
<binding.ws wsdlElement="http://jdbc.sca.orderstatus#wsdl.port
                (OrderStatusServiceWebService/OrderStatusServiceSOAP11port)"
                qos:wsPolicySet="WSReliableMessaging persistent" />

Aquella aplicación que se ejecute dentro de un contenedor Web y que use un QoS administrado puede utilizar WS-ReliableMessaging para que la transacción cuente con mensajes recuperables. Las propiedades soportadas incluyen:

  • Un mapa de contexto de solicitud JAX-WS contiene la propiedad enableTransactedOneWay que se puede activar si se requiere este comportamiento.
  • La propiedad enOrderDelivery se encuentra disponible como una opción en la consola de administración o configurando la propiedad en “true” (verdadero) mediante la herramienta wsadmin al configurar la directiva WS-ReliableMessaging.

Consulte la sección Recursos para obtener más información.


Directivas de implementación

Directiva de seguridad

La directiva de autorización SCA controla a los usuarios, los grupos y los roles que pueden acceder a los recursos SCA. SCA usa aserciones de directivas <allow> (<permitir>), <deny> (<denegar>), <permitAll> (<permitir todos>) y <denyAll> (<denegar todos>) en los roles de usuario para controlar el acceso. La identidad de seguridad declara el rol bajo el cual se realizará la operación. SCA define un™modelo de permiso basado en un rol Java de tipo EE. Estas aserciones de seguridad se crean en un archivo definición.xml usando un elemento policySet (conjunto de directivas) de SCA. El archivo definición.xml debe estar empaquetado dentro del mismo archivo JAR que contiene los recursos SCA que necesitan control de acceso.

El administrador de directivas crea un archivo denominado definición.xml con policySets de SCA:

Listado 6
<?xml
version="1.0" encoding="UTF-8"?> <definitions
xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://application.workload"
xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"> <policySet
name="ERWW1AdminPolicy" appliesTo="sca:implementation.java">
<authorization> <allow roles="policyadmin
superintendent"/> </authorization>
<securityIdentity> <runAs role="policyadmin"/>
</securityIdentity> </policySet>
lt;/definitions>

El ensamblador luego adjunta este policySet de SCA al SCA compuesto; la porción del código de SCDL que adjunta policySet se muestra a continuación:

Listado 7
<component name="ConvertInputOutputServiceComponent">
<implementation.java class="convert.inputoutput.sca.ConvertServiceImpl"
policySets="erww:ERWW1AdminPolicy" />

El archivo definición.xml en el Listado 7 ilustra un policySet de SCA que se aplicará a implementation.java y, una vez adjuntado, le permitirá a los roles de usuario policyadmin y superintendent invocar el servicio y efectuar la operación ConvertService() bajo la identidad de seguridad “policyadmin”.

El implementador luego asigna usuarios o grupos a los roles definidos para el compuesto, y asigna un usuario a los roles runAs definidos en el compuesto.

El archivo definition.xml debe estar empaquetado en el mismo recurso (un archivo JAR o EAR) que el compuesto al que se refiere el mismo. Las asignaciones de Roles se realizan en el alcance de la unidad de configuración y la directiva que hereda de su elemento de origen, y se aplicará si no hay una aserción de directiva explícita adjuntada al elemento. Cuando no se adjuntan policiySets, de manera predeterminada se ejecutan sin protección. Cuando se encuentran varias combinaciones de policySets o allow/deny, los roles de denegación anulan a los roles de autorización y los elementos contradictorios, como denyAll y permitAll, producirán errores de validación.

Tenga en cuenta que la directiva de autorización de SCA no es soportada en compuestos empaquetados como archivos Web (WAR por su sigla en inglés).

Directiva de transacciones

El Feature Pack for SCA suministra directivas de implementación e interacción para ofrecer QoS transaccional tanto para componentes como para interacciones. La directiva de transacciones se puede especificar usando intenciones en implementaciones de componentes, enlaces en el SCDL, o anotaciones específicas a cada lenguaje. El tiempo de ejecución de SCA brinda un entorno de transacciones para que los componentes interactúen y se coordinen entre sí.

Implementación de intenciones transaccionales

Las intenciones relacionadas con las transacciones se especifican en el elemento de implementación en SCDL.

  • Transacciones globales

    La intención managedTransaction.global de SCA se usa para indicar que un componente operará bajo una transacción global. Esta intención define el alcance de una unidad de trabajo, dentro de la cual la transacción es atómica. La transacción puede usar múltiples recursos transaccionales o múltiples proveedores de servicio remoto que ejecuten solicitudes distribuidas. El contenedor de SCA usa una confirmación en dos fases para lograr la atomicidad cuando se usan múltiples administradores de recursos transaccionales. Las transacciones Globales se pueden expandir a servicios usados por este componente. El Listado 8 muestra un ejemplo de uso de managedTransaction.global.

    Listado 8
    <component name="PaymentComponent">
    <implementation.java class="payment.PaymentServiceImpl"
    requires="managedTransaction.global"/>
    </component>
  • Transacciones locales

    Una transacción local es aquella cuyo componente necesita operar en una transacción local de administrador de recursos (Resource Manager Local Transaction o RMLT) ampliada sin una transacción global en vigencia. Se dice que esta transacción se ejecuta en una contención de transacciones locales (Local Transaction Containment o LTC) que finaliza cuando finaliza el método de servicio:

    • managedTransaction.local define el alcance de una transacción que permite acceder a administradores de múltiples recursos. Todas las interacciones deben confirmar la finalización correcta del método de servicio de alcance, o de lo contrario revertirse implícitamente cuando se encuentra una excepción no relacionada con negocios. Sin embargo, las RMLT individuales pueden fallar sin afectar las interacciones con otras RMLT. Las transacciones locales no se pueden propagar. A continuación se muestra un ejemplo de un componente de SCA que usa managedTransaction.local:
      Listado 9
      <component
      name="PaymentComponent"> <implementation.java
      class="payment.PaymentServiceImpl"
      requires="managedTransaction.local"/>
      </component>
    • noManagedTransaction son componentes que se ejecutan sin una transacción administrada, ni global ni LTC. La aplicación o el administrador de recursos individuales es el responsable de confirmar o revertir interacciones. Por ejemplo:
      Listado 10
      <component
      name="PaymentComponent"> <implementation.java
      class="payment.PaymentServiceImpl"
      requires="noManagedTransaction"/>
      </component>
    El alcance preconfigurado de las transacciones para el Feature Pack for SCA V1.0 es managedTransaction.global.

Intenciones de transacciones de interacción

Estas intenciones se especifican a nivel de la interacción, normalmente en los elementos de enlace del SCDL. Las intenciones de interacción soportadas son las siguientes:

  • La intención suspendsTransaction hará que el contexto de transacción del llamador no se propague al servicio invocado. Cuando se especifica en el elemento de referencia, esta intención produce el efecto de no propagar el contexto de transacción del servicio que llama. Cuando se especifica en el elemento de servicio, produce el efecto de no participar en la transacción del llamador y comenzar una nueva transacción global.
  • Cuando se especifica en una referencia, la intención propagatesTransaction indica que el contexto de la transacción actual se propagará al servicio llamado. Cuando se especifica en un servicio, la intención indica que el servicio se ejecutará bajo la transacción global del llamador, si hubiera una presente, o comenzará una nueva si no hubiera una transacción global presente. Es un error propagar transacciones en servicios unidireccionales. También es un error especificar intenciones de interacción cuando el componente está debajo de la intención de implementación noManagedTransaction.

Resumen

El marco de directivas de SCA le permite especificar restricciones de servicio a un nivel más amplio, usando intenciones de SCA, ofreciéndole al ensamblador, implementador o administrador la posibilidad de elegir la directiva concreta que aplicará. Este artículo describió las características principales de las intenciones de SCA y los policySets soportados por el Feature Pack for SCA, su comportamiento en el Servidor de aplicaciones WebSphere V7 y las formas comunes de usarlos. Estas capacidades le permiten al ensamblador brindar una combinación de servicios que se puedan comportar de manera diferente según su entorno operativo y sus necesidades, sin cambiar la lógica subyacente de la empresa propiamente dicha, y manteniendo los conceptos de SCA. Se ilustra un caso de uso de muestra y una implementación típica en el siguiente escenario de usuario de muestra.


Escenario de muestra

  • Caso de uso: Pago por artículos

  • Descripción: Este caso de uso ilustra cuando un cliente completa una transacción de pago. La transacción involucra al cliente que suministra información confidencial para permitirle a la aplicación que aplique un cobro a la cuenta preconfigurada, y luego marcar una orden como pagado.

  • Condiciones previas: Este caso de uso se muestra sólo para la porción del pago de la aplicación determinada. La información sobre inicio de sesión de usuario y la contraseña ya ha sido configurada y activada. El pago se realizara mediante la selección de cuentas de clientes con fondos suficientes para completar la transacción.

  • Flujo básico:

    1. El cliente ingresa la URL del sitio.
    2. El cliente inicia sesión con un ID de usuario y una contraseña válidos.
    3. La aplicación muestra una lista de mercadería para que el cliente seleccione.
    4. El cliente selecciona uno o varios artículos de la lista para comprar.
    5. El cliente indica su intención de pago por los artículos seleccionados.
    6. La aplicación muestra una lista de cuentas de pago preconfiguradas habilitadas según el monto a pagar.
    7. El cliente selecciona la forma de pago.
    8. La aplicación le solicita al cliente información de pago segura.
    9. El cliente suministra la información de pago segura.
    10. El sistema realiza el cobro de la cuenta.
    11. La aplicación marca el pedido como pagado.
    12. El sistema registra la transacción de pago y le brinda al cliente un número de confirmación.
  • Alternativa de flujo1: Falla el paso 2. El usuario es redireccionado a los avisos de inicio de sesión.

  • Alternativa de flujo 2: Falla la autenticación del paso 9. El usuario vuelve al paso 6.

  • Alternativa de flujo3: Fallan los pasos 10 a 12. El usuario vuelve al paso 6.

El caso de uso ilustra un escenario en el cual algunos de las intenciones y las directivas de QoS de SCA se pueden demostrar. En el flujo anterior:

  • El requisito de autenticación en el paso 2 se puede cumplir usando el conjunto de directivas WS, WSHTTPS.
  • La información transmitida por el cliente en el paso 8 es confidencial y la intención de la directiva de confidencialidad de SCA garantizará la protección de la información sensible.
  • Las operaciones entre los pasos 10 y 12 debe ser una operación atómica única, y se puede especificar la intención de la transacción de SCA para lograrlo.

Una implementación típica incluirá los siguientes componentes:

  • Interfaz de usuario del cliente
    • InputPortlet: Obtiene los datos que ingresa el cliente y muestra los datos de salida basándose en el flujo de control.
  • Servicios de servidor
    • WelcomeService: Brinda información para que el InputPortlet la muestre como parte de su pantalla de bienvenida.
    • ListItemsService: Recupera una lista de artículos de un almacenamiento permanente para ser mostrados al cliente.
    • PaySessionService: Organiza la sesión de pago.
    • ProcessPayment: Registra y autoriza el pago. Este servicio devuelve un ID de pago.
    • updateItems: Marca los artículos como pagados si el pago fue procesado exitosamente.
    • LogHistory: Registra una pista de auditoría para la transacción de pago.

Esta implementación típica tendría un flujo técnico similar a éste:

  1. InputPortlet muestra el panel de bienvenida del sitio.
  2. InputPortlet usa el conjunto de directivas preconfiguradas WSSecurity para servicios web LTPA. El SCDL para el lado de servicio se parecería al Listado 11, y el SCDL para el lado de referencia se parecería al Listado 12.
    Listado 11
    <service name="WelcomeService"> <binding.ws
    wsdlElement="http://session.pay.WecomeService/#wsdl.port
    (WecomeService/WecomeService)" requires="authentication.transport"
    qos:wsPolicySet="LTPA WSSecurity default" ... />
    </service>
    Listado 12
    <reference name="WelcomeService"
    target="WelcomeServiceComponent/WelcomeService"> ...
    <binding.ws wsdlElement="http://sca.WelcomeService#wsdl.port
    (WelcomeServiceWebService/WelcomeServiceSOAP11port)" qos:wsPolicySet="LTPA
    WSSecurity default"/> </reference>

    El conjunto de directivas WSSecurity LTPA concreto se adjunta al servicio a tiempo de ejecución. Para el lado de servicio, usted puede adjuntar el conjunto de directivas yendo a la consola de administración y navegando a Applications (Aplicaciones) => Application Types (Tipos de aplicaciones) => Business-level applications (Aplicaciones a nivel de la empresa) . Navegue a la aplicación a nivel empresa que contiene el WelcomeService, luego a la unidad de composición (UC) que contiene el WelcomeService, y haga clic en Service provider policy sets and bindings (Conjuntos de directivas y enlaces del proveedor de servicio) (Figura 4).
    Figura 4. Panel para administrar UC, para adjuntar conjunto de directivas
    Panel para administrar UC, para adjuntar conjunto de directivas
    En el panel siguiente (Figura 5), verifique la fila WelcomeService y haga clic en Attach Policy Set (Adjuntar conjunto de directivas) del menú desplegable. Seleccione LTPA WSSecurity default (LTPA WSSecurity preconfigurado) de la lista y siga los avisos que aparecen para guardar la configuración.
    Figure 5. Adjuntar juego de directivas
    Figure 5. Adjuntar juego de directivas
    En el lado del cliente, acceda al panel de conjuntos de directivas y enlace siguiendo la misma ruta que para el lado del servicio, pero seleccione el cliente BLA, compuesto, y servicio.
  3. La información que se muestra en las siguientes llamadas de servicio debe ser confidencial. ListItemsService puede especificar la intención de confidencialidad:
    Listado 13
    <service name="listItemsService">
    <binding.ws requires="confidentiality.message" qos:wsPolicySet="LTPA
    WSSecurity default" ... /> </service>

    El paso para adjuntar la directiva y el enlace concretos es exactamente igual al paso 2.
  4. PaySessionService recopila la información del cliente y llama a los servicios processPayment (procesarPago), updateItems y logHistory, en esa secuencia. El servicio luego devuelve un ID paymentconfirmation al cliente si se completa sin errores. Se requiere que los servicios processPayment y updateItems formen parte de una única transacción atómica. Por lo tanto, PaySessionService contiene lo siguiente en su archivo SCDL:
    Listado 14
    <component
    name="PaymentComponent"> <implementation.java
    class="payment.PaymentServiceImpl"
    requires="managedTransaction.global"/> <reference
    name="processPayment" target="ProcessComponent"
    requires="propagatesTransaction" /> <reference
    name="updateItems" target="UpdateComponent" requires="propagatesTransaction"
    /> <reference name="logHistory" target="AuditComponent"
    requires="suspendsTransaction" />
    </component>

    Las intenciones de las transacciones no necesitan una adjunción de conjunto de directivas explícito si los servicios y las referencias no están usando binding.ws. Sin embargo, cuando se requiere un comportamiento transaccional sobre WS binding, deberá configurarse el atributo qos:wsPolicySet en un valor de "WSTransaction," o de lo contrario este conjunto de directivas WS se debe adjuntar mediante la consola de administración usando el mismo paso.
  5. La entrega de mensajes a PaySessionService necesita ser garantizada mediante la configuración del policySet SCA persistente de WS-ReliableMessaging:
    Listado 15
    <component name="PaymentComponent">
    <service name="PaySessionService "> <interface.wsdl
    xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance"
    interface="http://session.pay#wsdl.interface(PaySessionService)"
    wsdli:wsdlLocation="http://session.pay PaySessionService.wsdl"/>
    <binding.ws
    wsdlElement="http://session.pay#wsdl.port(PaySessionWebService/
    PaySessionServiceSOAP11port)" qos:wsPolicySet="WSReliableMessaging
    persistent"/> </service> <reference
    name="processPayment" target="ProcessComponent"
    requires="propagatesTransaction" /> <reference
    name="updateItems" target="UpdateComponent" requires="propagatesTransaction"
    /> <reference name="logHistory" target="AuditComponent"
    requires="suspendsTransaction" />
    </component>

    Además del procedimiento anteriormente analizado para adjuntar el conjunto de directivas, el conjunto de políticas persistente WS-ReliableMessaging requiere el uso de un bus y un motor de mensajería. Entonces necesitan crearse los enlaces de directivas tanto para el servicio, como para el cliente. Por ejemplo, se necesita crear un bus y se necesita configurar un motor de mensajería:
    1. Para crear un bus, desde la consola de administración, navegue a Service Integration (Integración de servicios) => Buses => Nuevo . Ingrese un nombre, luego haga clic en Finalizar .
      Figura 6. Bus después de la creación
      Bus después de la creación
    2. Luego, usted creará un miembro de bus. Haga clic en el bus recientemente creado, luego seleccione Bus members (Miembros de bus) => Agregar . Del menú desplegable, seleccione el servidor o el cluster que agregará al bus. Haga clic en Siguiente .
    3. En el siguiente panel, marque Enable messaging engine policy assistance (Habilitar ayuda para directivas de motor de mensajería) y las opciones High availability (Alta disponibilidad) , luego haga clic en Siguiente .
    4. Seleccione un archivo o un almacenamiento de datos para persistencia, luego Siguiente .
    5. Haga clic en Is the message store configured (Está configurado el almacenamiento de mensaje) . Modifique los valores según fuera necesario, luego haga clic en Siguiente .
    6. Ajuste los parámetros de rendimiento si fuera necesario, luego haga clic en Finalizar para agregar el miembro de bus y crear el motor de mensajería. Ahora debe reiniciar los servidores.

    Siguiente, crear los enlaces de conjunto de directivas para el servicio y el cliente:

    1. Para crear el enlace de conjunto de directivas para el servicio, navegue desde la consola de administración a Servicios => Conjuntos de directivas => General Provider policy set bindings (Enlaces generales para conjunto de directivas de Proveedor) . Haga clic en Nuevo . Ingrese un nombre de configuración de enlaces, comoPayServiceBind(Figura 7) luego haga clic en Add (Agregar) .
    2. Seleccione WS-ReliableMessaging de la lista. Seleccione el bus previamente creado y el motor de mensajería, luego haga clic en OK .
    3. Repita estos pasos para crear enlaces de conjunto de directivas para el cliente: desde la consola de administración seleccione Servicios => General client policy set bindings (Enlaces generales de conjunto de directivas de cliente) , y creará así un nuevo enlace de cliente.
      Figura 7. Creación de nuevo enlace para conjunto de directivas de servicio
      Creación de nuevo enlace para conjunto de directivas de servicio
    4. Luego, adjuntar los enlaces de conjuntos de directivas para el cliente y el servicio. Desde la consola de administración, navegue a Application types (Tipos de aplicaciones) => Business Level Application (Aplicación a nivel de negocios) => Paymentcomposite => PaySessionComposite =>Conjuntos de directivas y enlaces para el proveedor de servicio .
    5. Seleccione PaySessionService , haga clic en AssignBinding , y de la lista desplegable, seleccione el enlace de servicio creado anteriormente PayServiceBind .
      Figura 8. Asignación de enlaces al servicio
      Asignación de enlaces al servicio
    6. Realice el mismo paso que para el cliente navegando al cliente BLA, UC y los paneles de enlace de cliente.

    Esto completa los pasos de configuración necesarios para adjuntar el conjunto de directivas WS-ReliableMessaging a la aplicación.

  6. Se devuelve un nuevo ID de pago como confirmación de la terminación exitosa de todos los pasos.

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=458199
ArticleTitle=Explorando Feature Pack for SCA del servidor de aplicaciones WebSphere: Parte 3: Intenciones y directivas disponibles en Feature Pack for SCA
publish-date=07282011