Explorando el Feature Pack for SCA de WebSphere Application Server: Parte 5: Enlaces de protocolos para los servicios Service Component Architecture

La Parte 5 de esta serie sobre el Feature Pack for SCA de® WebSphere® Application Server V7 IBM describe los enlaces de SCA (Service Component Architecture / Arquitectura de componentes de servicio) que están disponibles para escribir conjuntamente diferentes componentes SCA. Los enlaces definen el mecanismo de acceso de transporte/protocolo para los servicios y las referencias SCA, permitiendo que la elección de protocolo sea independiente de la interfaz de programación de las aplicaciones. Los tres tipos de enlaces soportados por el Feature Pack for SCA son: enlace predeterminado, enlace de servicios web y enlace EJB. La Parte 1 de esta serie brinda una descripción general de los enlaces SCA en el modelo de ensamblaje.

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



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.



Stephen Kinder, Senior Technical Staff Member, IBM

Stephen Kinder es Senior Technical Staff Member y Lead Architect de la prestación de Service Component Architecture en WebSphere Application Server. Trabaja en IBM desde hace 20 años y participa en productos WebSphere desde hace 10 años.



28-07-2011

Introducción

Este artículo, Parte 5 de la serie sobre Feature Pack for SCA de WebSphere Application Server V7 IBM, describe los detalles de los enlaces SCA que suministra el paquete de funciones, específicamente el enlace predeterminado, el enlace de servicios web y el enlace EJB. Estos enlaces SCA (Arquitectura de Componentes de Servicios) se usan para definir el mecanismo de acceso de protocolo/transporte para referencias y servicios remotos. Los enlaces encapsulan todos los datos de configuración y directivas, de esta manera se aísla a la aplicación de estos detalles. Los enlaces se especifican en servicios SCA remotos y en cada referencia.

Consulte la Parte 1 de esta serie para conocer las generalidades de los enlaces SCA en el modelo de ensamblaje de SCA.


Generalidades de los enlaces

Los servicios y las referencias le permiten a un componente comunicarse con otras aplicaciones. Sin embargo, por diseño, no informan cómo se realiza la comunicación. Los enlaces cumplen la tarea de especificar esta comunicación.

El enlace especifica exactamente cómo debería realizarse la comunicación entre un componente SCA y sus consumidores y proveedores de servicio. Según la relación que tengan los componentes con los servicios que están brindando o usando, el componente podría o no haber especificado explícitamente los enlaces. En la Figura 1, que muestra cómo SCA integra intentos y directivas, aquel componente que se comunica con otro componente en el mismo dominio, incluso con uno en otro proceso u otra máquina, no necesita tener enlaces explícitos especificados. En cambio, el tiempo de ejecución de SCA determina qué enlaces usar, liberando al desarrollador de esta tarea.

Figura 1. Generalidades de los enlaces
Generalidades de los enlaces

Para establecer comunicaciones fuera de su dominio SCA, ya sea a una aplicación que no sea SCA o a una aplicación SCA que se ejecuta en algún otro dominio SCA, el componente debe especificar uno o varios enlaces para esta comunicación. Cada enlace define un protocolo específico que se usa para comunicarse con el servicio o la referencia. Un servicio o referencia individual puede tener múltiples enlaces, permitiéndole a los distintos softwares remotos que se comuniquen con los mismos de diferentes maneras.

Sepa que la aplicación SCA que se comunica con otra aplicación SCA en un dominio diferente lo hace usando un protocolo específico (como servicios web) y por ende visualiza esa aplicación como una aplicación que no es SCA, su uso de SCA no se puede ver fuera de su dominio. Esto demuestra una correcta separación de temas entre el consumidor del servicio y la implantación del proveedor; la aplicación SCA tampoco necesita conocer los detalles de su implantación, sólo cómo comunicarse entre sí.

Como se muestra en la Figura 1, el enlace especifica exactamente cómo debería realizarse la comunicación entre un componente SCA y su consumidor o proveedor. El enlace se puede configurar como un mecanismo de acceso ofrecido por un servicio o solicitado por una referencia. Los ejemplos de enlace incluyen:

  • Enlace SCA predeterminado
  • servicios web
  • Sesión EJB sin estado.

Las referencias usan enlaces para describir el mecanismo de acceso usado para invocar un servicio (que puede ser un servicio suministrado por otro componente SCA). Los servicios usan enlaces para describir el mecanismo de acceso que deben usar los consumidores (que puede ser un cliente de otro componente SCA) para invocar el servicio. En general, SCA le permite a cada servicio remoto y a cada referencia especificar los protocolos que soporta el uso de enlaces. El servicio o la referencia se pueden configurar con múltiples enlaces.

Cómo especificar enlaces

Los enlaces que no son elegidos por el tiempo de ejecución, para comunicación intradominio, se definen explícitamente en el archivo de configuración compuesta del componente. Es interesante observar que los enlaces específicos no se pueden especificar directamente en una implantación Java™. (SCA Java Component Implementation V1.00 Service Component Architecture Specifications, Versión 1.0 no define forma alguna para que usted especifique un enlace directamente en Java.)

Aquí se muestra un ejemplo de la forma en que se puede especificar un enlace para una determinada referencia de componente:

Listado 1. Enlace de referencia de muestra
<reference name="StockQuoteService">
<interface.java interface="services.stockquote.stockquoteService"/>
<binding.ws uri= http://www.sqs.com/StockQuoteService
requires="soap/1.2"/> </reference> ..

En este ejemplo, el elemento del enlace especifica dos cosas:

  • Qué protocolo usa el enlace.
  • La cadena de caracteres URI mediante la cual se puede acceder al servicio usando este protocolo.

La expresión binding.ws en el nombre del elemento indica la primera de ellas, especificando el enlace de servicios web. El atributo URI del elemento indica el segundo punto, especificando la URI en la cual se puede encontrar el servicio. También es posible y mucho más probable que el enlace de servicios web use una URL relativa en lugar de la forma absoluta que se muestra aquí.

Por lo tanto, el enlace es definido por un elemento de enlace en el archivo compuesto, que es un elemento secundario de un elemento de servicio o de referencia al cual pertenece. El elemento de enlace es descripto formalmente por SCDL de tal manera que sea similar para todos los elementos de enlace.

Figura 2. Utilidad de los enlaces
Utilidad de los enlaces

Como se mencionó anteriormente, los enlaces permiten que la elección de protocolo sea independiente de la interfaz de programación de la aplicación. Analicemos cómo las aplicaciones usan protocolos diferentes en Java EE 5 y sus predecesores J2EE™. Cada protocolo está provisto de una tecnología específica, por lo tanto cada uno tiene su propia interfaz de programación de aplicaciones. Por ejemplo, usar SOAP en HTTP normalmente significa construir en JAX-WS (o JAX-RPC en J2EE 1.4). Usar IIOP normalmente significa usar componentes EJB. Este enfoque combinó la lógica de negocio con la selección de protocolo.

SCA aplica un enfoque más simple. En lugar de incorporar diferentes protocolos a diferentes tecnologías con distintas API, SCA permite a cada servicio remoto y a cada referencia especificar los protocolos que soportan el uso de enlaces que han sido abstraídos de la implantación. El modelo de programación observado por la aplicación se mantiene igual independientemente de qué protocolo se use. Esto permite la capacidad de reemplazar los enlaces y configurarlos durante la implementación sin afectar la lógica de negocio. Efectivamente, esto mejora la capacidad de reutilizar la lógica de negocio.

Por ejemplo, para poder acceder a través de SOAP en HTTP, el servicio SCA puede usar el enlace de los servicios web. Asimismo, el enlace bean de sesión EJB permite acceder a los beans de sesión usando el protocolo Internet Inter-ORB Protocol (IIOP).

Ningún tipo de enlace soporta interfaces conversacionales.

SCA define varios tipos diferentes de enlaces, incluyendo servicios web, sesión sin estado EJB, JMS, JCA, enlace SCA predeterminado, etc. Sin embargo, esta versión inicial de Feature Pack for SCA incluye soporte para el enlace (SCA) predeterminado, enlace de servicios web, y enlaces EJB 2 y EJB 3. Estos enlaces se describen más detalladamente en las siguientes secciones.


Enlace predeterminado

Todos los tiempos de ejecución de SCA suministran el enlace SCA, también conocido como enlace predeterminado. Esto significa que es el enlace que se usa cuando no se especifica ningún otro enlace, para una referencia o servicio de componente. Es el enlace natural a usar para invocaciones SCA-a-SCA tales como un cliente SCA que invoca un servicio SCA.

El protocolo que usa este enlace está determinado por cada tiempo de ejecución SCA y por lo tanto sólo se encuentra disponible para los clientes y los proveedores de SCA que están implementados en el mismo dominio SCA. Por arquitectura, se deja que cada proveedor diseñe el concepto del dominio, por ende, los dominios son específicos para cada proveedor, esto significa que no hay una forma, desde el punto de vista de arquitectura, de usar un enlace predeterminado para invocar u ofrecer un servicio que esté implementado en otro dominio. El tiempo de ejecución de SCA en WebSphere Application Server V7 elegirá el mecanismo más eficaz para invocar servicios, basándose en las especificaciones de la implementación (como ubicación de la referencia), pero respetará el comportamiento de la semántica (como pase por valor) al invocar a través de interfaces remotas.

Figura 3. Dominios y enlace predeterminado SCA
Dominios y enlace predeterminado SCA

El dominio representa un importante concepto de facilidad de uso en SCA. El dominio representa un alcance mediante el cual se pueden ensamblar entre sí los servicios usando nombres lógicos. Esto cumple dos funciones importantes:

  • Simplifica enormemente la tarea de implementar SCA compuestos, ya que el implementador no necesita conocer las especificaciones acerca de la configuración del dominio SCA.
  • Los cambios de infraestructura (como aplicaciones que se transfieren de un servidor a otro) pueden realizarse sin la necesidad de reconfigurar el ensamblaje SCA.

Enlace de servicios web

El enlace de servicios web SCA define la manera en la cual se puede ofrecer un servicio como servicio web, y la forma en la cual se puede hacer una referencia para invocar un servicio web. Este enlace está diseñado para suministrar y consumir servicios web basados en SOAP, que cumplen con WS-I (interoperable).

SCA feature pack soporta SOAP 1.1 y 1.2 y WSDL 1.1.

El enlace del servicio web es un enlace basado en Web Services Description Language (WSDL) 1.1 (Lenguaje de descripción de servicio web), lo cual significa que o bien se refiere a un enlace WSDL existente o le permite al ensamblador especificar la información suficiente para generar uno durante la implementación.

El elemento de enlace de servicios web <binding.ws> se puede usar tanto en una definición de servicio de componente o una referencia de componente:

  • Cuando se usa con un servicio de componente, este tipo de enlace permite a los clientes acceder al servicio SCA como servicio web estándar.
  • Cuando se usa con una referencia de componente, este enlace le permite a un componente consumir un servicio web externo de la misma manera que consume cualquier otro servicio.

Los enlaces de servicio web SCA también pueden personalizarse a través del uso de las configuraciones de directivas de WebSphere Application Server.

La Figura 4 muestra la definición de SCA compuesto para un compuesto denominado MyValueComposite, el cual contiene una definición de componentes para MyValueComponent, que contiene una referencia a un servicio de cotización de acciones. StockQuoteComponent ofrece un servicio de cotización de acciones. Tanto el servicio como la referencia usan un enlace de servicios web. Como recordatorio, estos servicios también podrían ofrecerse y conectarse a través de otros enlaces, como el enlace SCA predeterminado.

Figura 4. Ejemplo de enlace de servicios web
Ejemplo de enlace de servicios web

Implementación de aplicaciones SCA sin un WSDL

Las contribuciones de SCA se pueden empaquetar sin un documento WSDL. Omita el atributo wsdlElement en binding.ws y no se le requerirá empaquetar un documento WSDL con su contribución. En este escenario, todo documento WSDL necesario se generará dinámicamente en tiempo de ejecución. Los clientes de servicios web deben especificar un punto final usando un método diferente al del atributo de ubicación WSDL ya que no existe un WSDL estático. Es importante saber que los argumentos de métodos de la interfaz de servicio, los tipos de retorno y las excepciones deben cumplir con las especificaciones de JAX-WS y EJB.

Normalmente, tanto el cliente, como el servicio de los servicios web necesita usar el mismo WSDL, por lo tanto si un servicio está implementado sin un WSDL, se puede consultar el servicio web usando "? wsdl" anexado a la URL del servicio para que se use WSDL para el acceso cliente.

El Listado 2 muestra cómo especificar una implementación para un servicio sin WSDL. Para servicios con interfaces de devolución de llamada, especifique sólo una etiqueta <binding.ws> vacía. Se requieren los elementos de servicio interface.java y un callbackInterface adecuado.

Listado 2. Implementación sin WSDL para un servicio
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsdl="http://www.w3.org/2004/08/wsdl-instance" name="helloworldws" >
<component name="HelloWorldServiceComponent">
<implementation.java class="helloworld.HelloWorldImpl"/>
<service name="HelloWorldService"> <interface.java
interface="helloworld.HelloWorldService"
callbackInterface="helloworld.HelloWorldCallback"/>
<binding.ws/> <callback> <binding.ws/>
</callback> </service> </component>
</composite>

El Listado 3 muestra cómo especificar una implementación sin WSDL para una referencia. Este ejemplo muestra cómo especificar una URL de punto final de servicio absoluta en el atributo URI <binding.ws>. Para referencias con interfaces de devolución de llamada, especificar sólo una etiqueta <binding.ws> vacía. Se requieren los elementos de servicio interface.java y un callbackInterface adecuado.

Listado 3. Implementación sin WSDL de una referencia
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:system="http://
tuscany.apache.org/xmlns/system/1.0-SNAPSHOT" name="helloworldwsclient" >
<component name="HelloWorldServiceClientComponent">
<implementation.java class="helloworld.HelloWorldServiceComponent"/>
<reference name="HelloWorldService"> <interface.java
interface="helloworld.HelloWorldService"
callbackInterface="helloworld.HelloWorldCallback"/> <binding.ws
uri=”http://localhost:9080/HellowWorldServiceComponent/HelloWorldService”/>
<callback> <binding.ws/> </callback>
</reference> </component>
</composite>

El Listado 4 muestra el uso de una referencia que especifica el atributo de destino para resolver el punto final de servicio, como en <reference target="HellowWorldServiceComponent/HelloWorldService">. Esto sólo es aplicable si la referencia va dirigida a un servicio en el mismo dominio SCA (celda WebSphere Application Server) que la referencia.

Listado 4. Referencia: ComponentName/Service
<?xml version="1.0"
encoding="UTF-8"?> <composite
xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:system="http://
tuscany.apache.org/xmlns/system/1.0-SNAPSHOT" name="helloworldwsclient" >
<component name="HelloWorldServiceClientComponent">
<implementation.java class="helloworld.HelloWorldServiceComponent"/>
<reference name="HelloWorldService"
target="HelloWorldServiceComponent/HelloWorldService"> <interface.java
interface="helloworld.HelloWorldService"
callbackInterface="helloworld.HelloWorldCallback"/>
<binding.ws/> <callback> <binding.ws/>
</callback> </reference> </component>
</composite>

SCA feature pack y el documento WSDL

El Feature Pack for SCA no requiere que usted le suministre un documento WSDL formal para exponer un componente SCA como un servicio web. Esto es útil para un desarrollo rápido del servicio cuando se comienza con una implantación Java que va a exponerse como un servicio web. Una vez que el servicio ha sido desarrollado y la interfaz del servicio está finalizada, usted debería capturar el WSDL del servicio y usarlo como la definición formal de la interfaz. Esto asegura que se respecte correctamente la formalidad de la interfaz en su SOA, y ayudará a evitar cambios en los servicios que podrían aparecer inadvertidamente ante los consumidores de su nuevo servicio.

Uso de los documentos WSDL

Hasta ahora, las dos áreas en las cuales WSDL participa en el paquete de funciones de SCA son:

  • Definición de una interfaz de servicio

    Al definir una interfaz de servicio, las clases Java provienen de un WSDL mediante la ejecución del comando wsimport en el WSDL para generar la interfaz Java y los tipos JAXB. Para un cliente, use estas clases generadas para establecer el tipo de su invocación proxy (por ejemplo, junto con @Reference). Para un servicio, escriba una implantación Java que ejecute la interfaz generada (junto con @Service, etc.) El Listado 5 muestra un ejemplo.

    Listado 5. Definir una interfaz de servicio usando un documento WSDL
    <wsdl:service
    name="BackEndComponentService"> <wsdl:port
    binding="intf:BackEndComponentServiceSoapBinding"
    name="BackEndComponentService"> <wsdlsoap:address
    location="http://localhost:9080/BackEndComp/BackEndComponentService"/>
    </wsdl:port> </wsdl:service>
  • Uso del enlace de servicios web

    Usted puede desarrollar clientes de servicio SCA que puedan acceder a un servicio SCA e invocarlo según la especificación de SCA. El cliente SCA puede consumir una variada gama de servicios, como por ejemplo beans de empresas, servicios web y otros servicios SCA, a través de las capacidades de los respectivos enlaces SCA, y usando el modelo de programación de cliente llamado POJO (Plain Old Java Object – Antiguo objeto Java plano).

    Para desarrollar clientes de servicio SCA, usted puede comenzar con un archivo WSDL existente, usando la herramienta wsimport para generar la interfaz Java, o puede comenzar con una interfaz Java existente. También puede desarrollar un componente que consuma o actúe como un cliente del servicio de destino usando una referencia de componente.

    Además de consumir un servicio de otra referencia de componente, el Feature Pack for SCA brinda un mecanismo para consumir un servicio SCA en el enlace predeterminado desde un componente que no sea de SCA. Para hacer esto, necesitará crear una definición de componente, usando la implantación Java. En el archivo SCDL, agregará un elemento <reference> que se vinculará a la interfaz original y al campo o al establecedor de su implantación SCA. La referencia se agrega como un elemento secundario de su componente. El componente forma parte de una definición compuesta.

    El Listado 6 muestra un ejemplo de SCDL de servicio de cliente. Este ejemplo muestra sólo una de las varias formas que existen para especificar binding.ws. Usted debe empaquetar la definición WSDL y especificar un elemento wsdlElement=<namespace>#wsdl.port en SCDL como se muestra.

    Listado 6. SCDL de servicio de cliente
    <composite
    xmlns="http://www.osoa.org/xmlns/sca/1.0"
    xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0"
    name="FrontEndComponentComposite"> <component
    name="FrontEndComponent"> <implementation.java
    class="test.sca.bindings.ws.components.FrontEndComponentImpl"/>
    <reference name="aBackEndComponentServiceRef"
    target="BackEndComp/BackEndComponentService">
    <interface.javainterface=
    "test.sca.bindings.ws.components.BackEndComponentService"
    callbackInterface="test.sca.bindings.ws.components.BackEndComponentCallback"/>
    <binding.ws
    wsdlElement="http://components.ws.bindings.sca.test#wsdl.port
    (BackEndComponentService/BackEndComponentService)"/>
    <callback> <binding.ws
    wsdlElement="http://components.ws.bindings.sca.test#wsdl.binding
    (BackEndComponentCallbackSoapBinding)"/> </callback>
    </reference> </component>
    </composite>

Por último el <binding.ws> se define en términos de un puerto WSDL, y este puerto se puede definir explícitamente por un WSDL suministrado por el desarrollador de aplicaciones, o definirse implícitamente, en cuyo caso el tiempo de ejecución SCA generará el puerto para usted. Por ejemplo, si usted empaqueta un documento WSDL con su cliente/servicio que defina un puerto WSDL, podrá simplemente referirse a él en SCDL en su definición <binding.ws/>.

Puntos finales

Usted puede configurar un punto final personalizado URI para componentes SCA que exponga servicios en el vínculo de servicios web.

Normalmente, cuando un servicio se expone en el enlace de servicio web SCA, el punto final de servicio es específico para el servidor en el cual se aloja el servicio. Los clientes que no son SCA usan este URI de punto final para acceder al servicio. En algunos casos, usted quizás prefiera que los clientes se vinculen al servicio indirectamente mediante el uso de un servidor proxy como el punto final de servicio. Por ejemplo, se requiere un servidor proxy para implantar puntos finales de enlaces de servicios web. Hay dos formas de permitirles a los clientes que usen puntos finales en proxy:

  • Si sus puntos finales se especifican en un SCA compuesto o en un documento WSDL, usted debe asegurarse que se configure el punto final de proxy en lugar del punto final específico de WebSphere Application Server.
  • Si su cliente resuelve el punto final usando el atributo <sca:reference target=""> en su documento SCDL de cliente, use la consola de administración para configurar los puntos finales personalizados para SCA compuestos a los cuales se accede por el protocolo HTTP.

Aquí se ofrece un ejemplo que muestra cómo especificar puntos finales personalizados para ofrecer un servicio en un servidor proxy:

  1. Desde la consola de administración de WebSphere Application Server, navegue a: Applications (Aplicaciones) => Application Types (Tipos de aplicaciones) => Business-level applications (Aplicaciones a nivel negocios) =>YourBLA (SuBLA)=>YourCU (SuCU) luego haga clic en Provide HTTP endpoint URL information (Suministrar información URL de punto final HTTP (Figura 5).
    Figura 5. Especificar punto final personalizado
    Especificar punto final personalizado
  2. En la página siguiente (Figura 6), seleccione uno de los prefijos URL predeterminados disponibles, o especifique un punto final URL personalizado. La muestra que aparece en la figura es para un servidor proxy.
    Figura 6. Suministrar información URL de punto final HTTP
    Suministrar información URL de punto final HTTP

Este enfoque es el más flexible para los clientes SCA que se encuentran en el mismo dominio que sus proveedores de servicio. Cuando use el atributo <sca:reference target="">, se pueden resolver las referencias SCA a puntos finales de servicio sin que el cliente especifique puntos finales en el SCDL o el documento WSDL.

Obtención de puntos finales

El cliente cuenta con tres formas para obtener un punto final para su servicio:

  • el elemento binding.ws en el archivo de configuración compuesta del componente
  • puerto WSDL
  • anotación @target

Cuando se usa la anotación de destino (@target), el punto final utilizado por el cliente se obtiene del dominio SCA. Esto tiene prioridad sobre los puntos finales especificados en WSDL o en el elemento binding.ws. Por lo tanto, cuando use @target no necesitará especificar ningún punto final de referencia.

Servicios de clustering

Los servicios de clustering están soportados. Cuando use servicios SCA agrupados en clústeres expuestos como servicios web, se debe configurar el servidor proxy WebSphere como con cualquier otro servicio web agrupado en clústeres alojado por WebSphere Application Server. Usted también debe configurar los puntos finales del servidor proxy WebSphere para los puntos finales usados por los clientes SCA. Esto se aplica tanto si usted especifica puntos finales de cliente usando @target, como si sus puntos finales están especificados en binding.ws o en el atributo de ubicación de WSDL.

Para el método @target, usted necesita especificar los puntos finales del proxy en la consola de administración de WebSphere Application Server después de la implementación de sus servicios:

  1. En la consola de administración, navegue hasta la unidad de composición.
  2. En el cuadro de texto Custom Http Endopoints URL (URL puntos finales HTTP personalizados), ingrese un punto final HTTP seguro y uno no seguro que correspondan a los puntos finales en los cuales su servidor proxy WebSphere está escuchando. El servidor proxy luego enrutará la solicitud a un servidor de aplicaciones específico que aloje su servicio.
  3. Para binding.ws o los puntos finales especificados con WSDL, ingrese la misma información básica de URI (protocolo, host y puerto) que ingresó en el cuadro de texto URL puntos finales HTTP personalizados. La clave es que los puntos finales deben ser aquellos del servidor proxy.

Soporte optimizado para conjuntos de directivas

Antes de esta versión, los servicios expuestos a los enlaces de servicios web siempre estaban disponibles en puntos finales seguros y no seguros. Actualmente, si un servicio está descripto con una directiva de seguridad que requiere SSL, el servicio no estará disponible en un punto final no seguro.

El Feature Pack for SCA soporta directivas de seguridad en servicios y referencias mediante la integración con la función de conjuntos de directivas de WebSphere Application Server. Los conjuntos de directivas de WebSphere Application Server se definen a través de la consola de administración y se les asignan nombre simples. Los conjuntos de directivas SCA se especifican como nombre XML aprobados. Para mitigar esta diferencia, el Feature Pack for SCA incluye una extensión que permite adjuntar conjuntos de directivas de WebSphere Application Server a los servicios y referencias SCA. La extensión es un atributo XML global llamado wsPolicySet, el cual se define en un espacio de nombres específico de WebSphere (http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06). En el Listado 7 se muestra un ejemplo de cómo usar este atributo en SCDL. (El atributo policySet de la especificación SCA Policy Framework no está soportado en el Feature Pack for SCA.)

Listado 7. Ejemplo de wsPolicySets en referencia SCDL
<reference
name="EchoTimeServiceReferenceFromEchoClient"> <interface.java
interface="test.ws.soa.sca.qos.policy.echoRealyServiceTest.echoService.EchoTimeService"/>
<binding.ws
wsdlElement="http://echoTime#wsdl.port(EchoTimeService/EchoTimeServiceSoapPort)"
qos:wsPolicySet="WSHTTPS default" /> </reference>

Además, cuando se use <reference target="">, los puntos finales determinados por el sistema respetarán una directiva de QoS (Calidad de Servicio) segura ya sea del lado del servicio o de la referencia, como se muestra en el Listado 7. El Listado 8, que muestra cómo se aplica la directiva SSL al servicio binding.ws, indica cómo se resuelve qos:namespace. Aquí la clave es que se use el atributo xmlns:qos para especificar el espacio de nombres XML que contiene la definición del atributo de extensión wsPolicySt de WebSphere. La configuración de referencias es similar.

Listado 8. Ejemplo de directiva SSL en el servicio binding.ws
<composite
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsdl="http://www.w3.org/2004/08/wsdl-instance"
xmlns:qos=http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06
targetNamespace=http://www.ibm.com/samples/sca/wsusecase”
name="EchoServiceWSComposite"> <component
name="EchoServiceWSComponent"> <service name="EchoService">
<binding.ws qos:wsPolicySet="WSHTTPS default"
qos:wsServicePolicySetBinding="Provider sample"/> </service>
<implementation.java
class=”test.sca.bindngs.ws.components.EchoServiceImpl”/>
</component> </composite>

Limitaciones

El enlace de servicios web incluye las siguientes limitaciones:

  • WSDL 2.0 no está soportado, lo cual implica que el punto final wsdl.endpoint no está soportado.
  • wsdlLocation no se cumple y es ignorado actualmente.
  • Los servicios no se pueden exponer directamente en binding.ws desde los componentes en los compuestos usados como implantaciones, ni en los servicios promocionados. Sin embargo, los componentes que usan compuestos como implantaciones podrían definir un enlace de servicios web para los servicios que suministran.
  • Las interfaces conversacionales no son soportadas por los enlaces de servicios web, ni por ningún enlace.
  • No se pueden vincular múltiples enlaces de servicios web en el mismo servicio.

Enlace EJB

El enlace EJB le permite a SCA integrarse con las aplicaciones basadas en Java EE existentes exponiendo los servicios SCA como beans de sesión sin estado. El enlace para bean de sesión EJB le permite tratar a los beans de sesiones implementados como servicios SCA, escribiéndolos en un SCA compuesto como una referencia SCA con el enlace EJB. La Figura 7 muestra el enlace EJB de SCA usado en servicios y referencias.

Figura 7. Enlace EJB
Enlace EJB

Un servicio SCA se puede exponer como un bean de sesión para el consumo por parte de las aplicaciones Java EE. El elemento de enlace usado en un servicio de componentes o una referencia de componentes para un enlace EJB es <binding.ejb>.

Listado 9. Ejemplo de uso del elemento de enlace EJB
<component
name="HelloWorldServiceComponent"> <implementation.java
class="helloworld.HelloWorldImpl"/> <service
name="HelloWorldService"> <binding.ejb…ejb-version=/>
</service> <reference name =”” > <binding.ejb
…> </ reference > </component>

El Feature Pack for SCA suministra soporte de enlace EJB para los estilos 2.x y 3.0 para servicios y referencias. También se brinda soporte para el destino de la referencia.

Enlace EJB del lado del servicio

El enlace EJB del lado del servicio sólo se encuentra disponible para las aplicaciones SCA del paquete JAR.

  • EJB 2: El servicio SCA se expone a través de EJB sin estado para el consumo de los clientes de EJB 2. El EJB sin estado para el servicio está vinculado a JNDI en ejb/sca/ejbbinding/<componentName>/<serviceName>.
  • EJB 3: El servicio SCA se expone a través de EJB sin estado para el consumo de clientes de EJB 3. El EJB sin estado para el servicio está ligado a JNDI en ejb/sca/ejbbinding/SOAAssureServiceComponentViaAny/SOAAssureServiceSCA#<package qualified SCA service interface with SUFFIX Remote or Local>

Enlace EJB del lado de la referencia

El enlace EJB del lado de la referencia está disponible para las aplicaciones de paquete JAR y las aplicaciones de paquete WAR. Se usa la URI para búsqueda ya sea de interfaz de negocio EJB 2.x home o EJB 3.0, siguiendo la convención para establecer nombres de Java EE si usted está conectándose a un módulo Java EE EJB ya existente. Si usted se conecta a un servicio SCA con binding.ejb, entonces use estos valores:

  • homeInterface: no se usa
  • session-type: valor predeterminado "stateless“ (sin estado)
  • ejb-version: valor predeterminado "EJB2"

Usted puede conectar una referencia a un servicio con un enlace EJB, aunque éste no es el caso de uso típico. El enlace de servicio EJB existe principalmente para exponer el componente SCA a los clientes Java EE puro o a quienes llaman. El enlace de referencia EJB puede acceder a EJB sin estado que se ejecute en un entorno puramente Java EE.

La interfaz de referencia usada con el enlace EJB puede ser una interfaz de bean de sesión remota o local. La lógica de implementación SCA y la implantación de enlace analizarán la clase de interfaz de la referencia para determinar si es local o remota. Si un componente SCA necesita acceder a la interfaz local y también a la remota de un bean de sesión, entonces esto debería modelarse en el ensamblaje de SCA a través de dos referencias, una con la interfaz local y otra con la interfaz remota.

Enlace EJB 3.0

Antes de iniciarse una aplicación SCA en WebSphere Application Server, todas las referencias EJB y las referencias de recursos definidas en la aplicación no necesitan estar vinculadas a los artefactos reales (beans o recursos de la empresa) definidos en el servidor de aplicaciones. Al definir enlaces, usted especifica nombres JNDI para los artefactos referenciales y referenciados en una aplicación. Los valores jndiName especificados para artefactos deben ser nombres de búsqueda autorizados.

Usted no necesita asignar manualmente nombres de enlace JNDI para cada una de las interfaces o inicios de EJB en los beans de su empresa en los módulos EJB 3.0. Si usted no asigna explícitamente enlaces jndiName bindings, el contenedor EJB asigna enlaces predeterminados.

La Figura 8 muestra un enlace de referencia EJB que consume un servicio EJB dentro de un archivo Java EE EAR. El enlace de referencia EJB brinda el acceso a un servicio ofrecido por un bean de sesión sin estado.

Figura 8. Enlace de referencia EJB de muestra
Enlace de referencia EJB de muestra

Se desarrolla un servicio SCA que se invocará desde un entorno Java EE. Supongamos que usted necesita invocar el servicio desde un entorno Java EE que no está optimizado con SCA y por lo tanto requiere el uso del modelo de programación Java EE. En este caso, el servicio SCA se implementa dentro de un tiempo de ejecución SCA que es capaz de alojar el enlace EJB (Figura 9).

Figura 9. Exposición del servicio SCA con un enlace EJB
Exposición del servicio SCA con un enlace EJB

El Listado 10 muestra un ejemplo sobre cómo podría accederse al servicio anteriormente mencionado como un bean de sesión EJB.

Listado 10. Servicio en el archivo SCA compuesto (default.composite)
<service
name=”CompanyInfo”> <interface.java
interface=”com.app.jobbank.CompanyInfo”/> <binding.ejb
ejb-version=”EJB2”/>
<reference>CompanyInfoComponent/CompanyInfo</reference>
</service>

Como el cliente usará el modelo de programación Java EE estándar, el cliente necesita saber la interfaz de inicio del servicio SCA. El servicio en el archivo sca.composite aparecerá como se muestra en el Listado 11.

Listado 11. Código "lookup" (búsqueda) del cliente
(CompanyHome)initialContext.lookup("ejb/sca/ejbbinding/CompanyComponent/Company");

Resumen

Los servicios y las referencias le permiten a un componente comunicarse con otras aplicaciones. Por diseño, no obstante, no informan cómo se realiza la comunicación. Los enlaces realizan la tarea de especificar esta comunicación. Los tres enlaces soportados en WebSphere Application Server Feature Pack for SCA IBM son el enlace predeterminado (o SCA), el enlace de servicios web y el enlace EJB. Al separar los detalles de comunicación de la lógica de negocio, los enlaces pueden simplificarle la vida al desarrollador de aplicaciones SCA.

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, SOA y servicios web
ArticleID=458387
ArticleTitle=Explorando el Feature Pack for SCA de WebSphere Application Server: Parte 5: Enlaces de protocolos para los servicios Service Component Architecture
publish-date=07282011