Uso de adjuntos en aplicaciones SOA con WebSphere Integration Developer V7

Los adjuntos son una forma eficaz de transmitir datos relacionados con aplicaciones en aplicaciones SOA, por ejemplo, transmitir una foto de un empleado como adjunto de un archivo WSDL junto con su currículum. Recientemente, WebSphere® Integration Developer agregó soporte para trasmitir datos como adjuntos. Este artículo le muestra cómo agregar adjuntos a sus aplicaciones usando las características de WebSphere Integration Developer V7.

John Vandenbroek, Software Developer, IBM

John Vandenbroek es Software Developer en el IBM Canada Lab y trabajó en numerosos proyectos, entre ellos el desarrollo de WebSphere Integration Developer. John fue un colaborador arquitectónico clave en el desarrollo del soporte de adjuntos.



Shu Tan, Staff Software Developer, IBM  

Shu Tan es integrante del personal de desarrollo software en el laboratorio de IBM Toronto en Toronto, Ontario. Ella trabaja en el depurador para Websphere Message Broker.



Flannan Lo, Software Developer, IBM

Flannan Lo es Software Developer en el IBM Canada Lab. Trabajó principalmente en el desarrollo del cliente de prueba de integración en WebSphere Integration Developer y desarrolló el soporte del cliente de prueba para adjuntos.



Nita Maheswaren, Software Developer, IBM

Photo of Nita MaheswarenNita Maheswaren es Team Lead del equipo IBM WebSphere Integration Developer Quality Assurance (QA). Contribuyó en el diseño y la implementación de una serie de escenarios de Prueba de Verificación de Sistemas (SVT por su sigla en inglés) que usan adjuntos referenciados.



Gary Bist, Staff Technical Writer, IBM

Gary Bistes Technical Writer en el IBM Canada Lab. Es autor de documentos de información sobre varias funciones de WebSphere Integration Developer y escribió la información del producto del soporte de adjuntos.



03-08-2011

Introducción

En aplicaciones de Arquitectura orientada a servicios (SOA) suele requerirse que los datos relacionados con aplicaciones se encuentren asociados con los archivos XML (Lenguaje de marcado extensible) usados en la aplicación. Por ejemplo, la foto de un empleado podría estar asociada con el currículum del empleado o una serie de archivos de datos financieros podrían estar asociados con una aplicación que analice los registros financieros. Una forma eficaz de transmitir estos datos asociados es mediante un adjunto en Protocolo simple de acceso a objetos (Simple Object Access Protocol o SOAP). Desde el punto de vista del desarrollo, los adjuntos aportan una mayor adaptabilidad y mejoran el rendimiento de las aplicaciones, lo cual se traduce en aplicaciones más usables.

Los adjuntos permiten a sus aplicaciones solicitar los tipos de archivos que sus usuarios podrían asociar a su aplicación adaptando la aplicación al entorno específico de cada usuario. Como la configuración y administración de adjuntos se realiza a través de herramientas IBM® WebSphere Integration Developer Version V7.0, usted podrá agregar considerable valor a su aplicación a cambio de un costo de desarrollo mínimo. Otro beneficio del uso de adjuntos es la mejora del rendimiento. Los datos binarios que conforman el adjunto en sí se encuentran separados del cuerpo de mensaje SOAP, por lo tanto, no se analizan como parte del mensaje y esto elimina la costosa sobrecarga de procesamiento.

En este artículo definiremos tres tipos de adjuntos: adjuntos con enlace explícito, adjuntos referenciados usando elementos de tipo swaRef y adjuntos no referenciados. Las próximas secciones le mostrarán cómo configurar interfaces y enlaces que usen adjuntos a través de herramientas de WebSphere Integration Developer V7.0 (en adelante denominado “Integration Developer”). También le explicaremos cómo realizar pruebas sobre aplicaciones que usan adjuntos dentro de un entorno de prueba.


Tipos de adjuntos

Un adjunto es un conjunto de datos asociados con una aplicación; es decir que estos datos se encuentran “adjuntos” al mensaje que usa la aplicación. Integration Developer soporta tres tipos de adjuntos:

  • Adjunto con enlace explícito: Un adjunto con enlace explícito es un adjunto modelado como una parte WSDL (Lenguaje de Descripción de servicios web) que está enlazada como parte MIME (Extensiones de Correo de Internet Multipropósito) en un enlace SOAP WSDL. El sobre SOAP no contiene ningún elemento que haga referencia al adjunto y el adjunto se encuentra fuera del sobre SOAP. Por consiguiente, no existe ningún elemento parte en el cuerpo SOAP. Para leer la definición de los adjuntos con enlace explícito, consulte WS-I Usage Scenarios for the WS-I Attachments Profile 1.0. El Consorcio World Wide Web (W3C) explica en profundidad cómo referirse a un adjunto de un mensaje SOAP en su especificación SOAP Messages with Attachments (Mensajes SOAP con Adjuntos).
  • Adjuntos referenciados mediante elementos de tipo swaRef: Un adjunto referenciado mediante un elemento swaRef (Referencia SOAP con adjuntos) es un adjunto que usa el tipo de adjunción (wsi:swaRef) definido por WS-I. El cuerpo SOAP incluye una referencia al adjunto. El adjunto se encuentra fuera del cuerpo SOAP pero está modelado dentro del archivo WSDL. Para leer la definición de los adjuntos referenciados, consulte WS-I Usage Scenarios for the WS-I Attachments Profile 1.0. WS-I proporciona una descripción del elemento swaRef en su especificación Attachments Profile(Perfil de los Adjuntos).
  • Adjunto no referenciado: un adjunto no referenciado no posee una referencia dentro del cuerpo SOAP. Con este tipo de adjuntos, usted debe ocuparse de garantizar que el cliente envíe el formato esperado por el servidor y viceversa. Los adjuntos no referenciados son casos especiales en los que usted deberá codificar y mantener el código en lugar de que Integration Developer lo haga por usted.

Estilos de enlaces y enlaces WSDL usados con adjuntos

Un estilo de enlace determina la forma en que un servicio se enlaza con un protocolo de mensajería como SOAP. También se denomina estilo WSDL o estilo de codificación. Para obtener más información sobre este tema, consulte Which WSDL style should I use? El estilo de enlace se establece en el nivel de operación de una interfaz en Integration Developer.

Si usa un adjunto con enlace explícito, deberá usar un estilo de enlace no ajustado de literal de documento o un estilo de enlace de literal de RPC (Llamada a procedimiento remoto) con la operación que transmitirá el adjunto. Sin embargo, es posible usar tanto un estilo de enlace no ajustado de literal de documento como un estilo de enlace ajustado de literal de documento con el adjunto referenciado con un elemento de tipo swaRef. En Integration Developer, el estilo predeterminado de enlace es el segundo.

Los enlaces toman datos de un formato en un entorno y los convierten en un formato usado en otro entorno. En aplicaciones SOA que usan adjuntos, esto implica convertir el formato de datos usado por un servicio web al formato de datos usado por una aplicación SOA y viceversa. Para los adjuntos, deberá usar la API Java™ para enlaces con servicios web XML (JAX-WS) con un protocolo SOAP 1.2/HTTP o SOAP 1.1/HTTP.

Visualización de adjuntos

En el tiempo de ejecución, los adjuntos ingresan a una aplicación junto con un mensaje a través de una importación o una exportación con un enlace de servicios web. Este mensaje y adjunto provienen típicamente de un cliente o servicio web. El adjunto se encuentra separado del sobre SOAP, como muestra la Figura 1.

Figura 1. Relación entre servicios, módulos y adjuntos
Relación entre servicios, módulos y adjuntos

Como muestra la Figura 1, se posible usar un flujo de mediación para procesar el adjunto. Por ejemplo, un flujo de mediación podría reducir el tamaño de una foto antes de que ésta se envíe a la aplicación.


Desarrollo de aplicaciones que usan adjuntos

En este artículo, nos centraremos en los adjuntos con enlace explícito y en los adjuntos referenciados que usan un elemento de tipo swaRef. Agregue soporte a alguno de estos dos tipos de adjuntos en su aplicación siguiendo el proceso detallado a continuación:

  1. Primero, cree una interfaz que requiera el uso de adjuntos. La interfaz que crearemos aquí corresponde a una aplicación de seguridad. Enviaremos el nombre de un empleado junto con su foto (la cual constituirá nuestro adjunto) y recibiremos una respuesta con la verificación del nombre y de la foto. La respuesta también incluirá la foto.
  2. Luego, agregue una operación a la interfaz y especifique el estilo de enlace correcto para soportar la transmisión de un adjunto a una aplicación.
  3. Cree los parámetros de entrada y salida de la operación. Estos datos de entrada y salida incluirán tipos binarios (base64Binary o hexBinary) o el tipo swaRef, los cuales representarán adjuntos. En nuestro caso, usaremos un parámetro de entrada y un parámetro de salida para una foto, la cual constituye nuestro adjunto.
  4. Finalmente, agregue la interfaz con una exportación o importación. Las exportaciones e importaciones son los componentes usados para el intercambio de datos entre aplicaciones externas, como servicios web o aplicaciones SCA. Luego, agregue el enlace a la exportación o importación. En nuestra aplicación, usaremos una exportación.

Creación de una interfaz para una aplicación que use un adjunto con enlace explícito

Los siguientes pasos le indican cómo crear una interfaz con una operación que transmita un adjunto al ser invocada:

  1. En la vista Business Integration de su módulo, haga clic derecho en Interfaces y seleccione New > Interface(Nueva > Interfaz) del menú. Nombre la interfaz como EmployeeCheck y haga clic en Finish(Finalizar).
  2. En el editor de interfaces, junto a Operations(Operaciones), seleccione el ícono Add Request Response Operation(Agregar operación de respuesta de solicitud). Observe que una vez realizada la selección, podrá cambiar el estilo de enlace, como muestra la Figura 2.
    Figura 2. Cambio del estilo de enlace
    Cambio del estilo de enlace
  3. Cambie el estilo de enlace a document literal non-wrapped(literal de documento no ajustado). Cambie el nombre de la operación a verifyRecord. Cambie el nombre de los datos de entrada por name con un tipo string(cadena). Cambie el nombre de los datos de salida por nameVerified con un tipo string. Tome en cuenta que si usted ya había creado esta operación, los datos de entrada y los datos de salida, deberá usar una función de refactorización. La refactorización en Integration Developer cambia los elementos especificados y todas sus referencias.
  4. Agregue más datos de entrada usando el ícono Add Input(Agregar datos de entrada). Esto agregará datos como adjunto. Tome en cuenta que el editor supone que usted está agregando un adjunto y selecciona el tipo base64Binary. Cambie el nombre por photo. Otra posibilidad sería seleccionar un tipo hexBinary. Agregue más datos de salida usando el ícono Add Output(Agregar datos de salida). Estos también se agregarán como adjunto. Cambie el nombre por photoVerified como muestra la Figura 3. Guarde su trabajo.
    Figura 3. Interfaz con adjunto con enlace explícito
    Interfaz con adjunto con enlace explícito
  5. Seleccione photo y abra la vista Properties(Propiedades). Haga clic en Add(Agregar) junto al campo Binary content type(Tipo de contenido binario). En el cuadro de diálogo, seleccione image/gif del menú. Haga clic en OK. Haga clic en Add nuevamente y agregue image/jpeg(Figura 4), ya que podría enviar una foto de cualquiera de estos dos formatos.
    Figura 4. Selección de tipo de contenido binario
    Selección de tipo de contenido binario
  6. Repita el paso anterior con el parámetro photoVerified. Guarde su trabajo y cierre el editor de interfaces.

Agregar la interfaz y el enlace a una exportación

Los siguientes pasos le indican cómo agregar la interfaz y el enlace a una exportación:

  1. Integration Developer V7.0 ha simplificado la creación de importaciones y exportaciones. Simplemente arrastre una importación o exportación de una paleta y suéltela en el lienzo del editor de montaje. En Inbound Exports(Exportaciones entrantes), seleccione Web Service(servicio web) y arrástrelo al lienzo del editor de montaje como muestra la Figura 5.
    Figura 5. Selección del enlace de servicio web
    Selección del enlace de servicio web
  2. En el cuadro de diálogo Select an Interface(Seleccione una interfaz), elija la interfaz EmployeeCheck. En el cuadro de diálogo Select a Transport Protocol(Seleccione un protocolo de transporte), seleccione SOAP1.2/HTTP. También podría seleccionar SOAP1.1/HTTP. Haga clic en Finish(Finalizar). La exportación se creará y aparecerá en el lienzo. Cambie el nombre de la exportación por EmployeeCheck. Guarde su trabajo.

Prueba en el tiempo de ejecución

Para verificar el funcionamiento de sus adjuntos en el tiempo de ejecución, haga eco de los adjuntos transmitidos como datos de entrada en los datos de salida. Esto puede llevarse a cabo a través de un componente de flujo de mediación. Observe el flujo de mediación creado en el código de muestra proporcionado con este artículo. Se incluye un flujo de mediación y un proceso de negocios. Ahora cree un flujo de mediación similar para probar sus aplicaciones con sus respectivos adjuntos.

Trabajo sobre el código de muestra

Para trabajar sobre el código de muestra, descárguelo a un directorio y siga los siguientes pasos:

  1. Inicie WebSphere Integration Developer Version 7.0.
  2. Seleccione File > Import(Achivo > Importación) del menú.
  3. En la ventana Import, seleccione Other > Project Interchange(Otros > Intercambio de proyectos). Haga clic en Next(Siguiente).
  4. Haga clic en Browse(Navegar) junto al campo From zip file(Desde archivo zip) y navegue al código de ejemplo (attachments.zip). Selecciónelo y haga clic en Open(Abrir).
  5. Haga clic en Select All(Seleccionar todo) y en Finish.
  6. El código de la sección de pruebas de este artículo se agregará a la vista Business Integration.

Usando el código de muestra, pruebe sus adjuntos referenciados siguiendo los pasos detallados a continuación:

  1. Inicie el servidor haciendo clic derecho en WebSphere Process Server y seleccionando Start(Iniciar).
  2. Haga clic derecho en el servidor en ejecución y seleccione Add and Remove Projects(Agegar y eliminar proyectos). Haga clic en Add All > Finish(Agregar todos > Finalizar).
  3. Abra el diagrama de montaje en el módulo EmployeeInformation.
  4. Haga clic derecho en la exportación EmployeeCheck y seleccione Test Component(Componente de prueba).
  5. En el editor de valores, dentro de Body(Cuerpo), abra el campo string de la columna Value(Valor) y agregue Donna Dedicated.
  6. En el campo base64Binary, abra el cuadro de diálogo Browse for File(Navegar en busca de archivo). Como únicamente agregamos una imagen de tipo de datos JPG en la muestra, cambie el campo Files of type(Tipo de archivos) a *.jpg. En la ruta EmployeeInformation > employeephotos, seleccione DonnaDedicated.jpg y haga clic en Finish. Tome en cuenta que el adjunto debe encontrarse en su espacio de trabajo actual.
  7. Haga clic en el ícono Continue(Continuar), como muestra la Figura 6.
    Figura 6. Selección del ícono Continue
    Selección del ícono Continue
  8. El entorno de prueba usa la URL de punto final del código WSDL de enlace. El punto final predeterminado tiene el número de puerto 9080. Si su tiempo de ejecución está instalado en otro número de puerto, recibirá una excepción del tiempo de ejecución. En este caso, verifique el número de puerto expandiendo Web Service Ports(Puertos de servicios web) en su módulo y abriendo el código en el editor WSDL.
  9. Acepte el servidor predeterminado (WebSphere Process Server v7.0) y haga clic en Finish. Acepte el ID de usuario y la contraseña predeterminados en el cuadro de diálogo de inicio de sesión y haga clic en OK. Si cambia estas configuraciones, use su propio ID de usuario y contraseña.
  10. En la sección Return parameters(Parámetros de devolución), Donna Dedicated aparece en el campo NameVerified. Al pasar el mouse sobre el campo PhotoVerified, verá una serie de caracteres aleatorios que representan datos binarios. Si usted tiene instalado un visor de imágenes como Microsoft® Office Picture Manager, haga clic derecho en el campo Value, seleccione View Source > View Raw Data(Ver fuente > Ver datos sin procesar) y seleccione su visor de imágenes para ver la imagen. Otra alternativa es seleccionar el elemento Binding(Enlace) devuelto en el recuadro Events(Eventos) y luego hacer clic en View SOAP Attachment(Ver adjunto SOAP) en el editor de valores.
  11. En el recuadro Events, observe el elemento attachment to inline(adjunto a inline) en la solicitud y el elemento inline to attachment(inline a adjunto) en la respuesta. Estos forman parte de un flujo de mediación que describiremos más adelante en este artículo. La Figura 7 muestra el resultado de la prueba.
  12. Cuando haya terminado, cierre la prueba que ejecutó. Elimine los proyectos del servidor de manera similar agregándolos a Removal All(Eliminar todo) y detenga el servidor.
    Figura 7. Cliente de prueba con adjunto con enlace explícito
    Cliente de prueba con adjunto con enlace explícito

Tras bambalinas

Si mira tras bambalinas de la interfaz, lo cual se logra en Integration Developer abriendo la interfaz con el editor WSDL, verá código que podría sorprenderle. El Listado 1 muestra elementos múltiples para cada tipo. El Listado 2 muestra que cada mensaje WSDL posee dos partes WSDL y cada una de ellas se refiere a un elemento global. Si examina el elemento de mensaje, verá que el adjunto corresponde a una parte (no a un elemento) y que existen partes múltiples, si bien un WSDL correcto sólo cuenta con una parte por mensaje. El adjunto de imagen aparece identificado por una etiqueta de contenido MIME (Extensiones de Correo de Internet Multipropósito).

Este código inesperado se debe a que estamos usando el estilo de enlace no ajustado de literal de documento en lugar del típico estilo de enlace ajustado de literal de documento de Integration Developer. En un caso de exportación, el editor de interfaces se referirá al parámetro de adjunto con el nombre photo, pero el editor de pruebas se referirá a él con el nombre VerifyRecordInputParameter1, como muestra el Listado 2.

Listado 1. Elementos múltiples para cada tipo
Elementos múltiples para cada tipo
Listado 2. Partes múltiples de un mensaje
Partes múltiples de un mensaje

Aunque los adjuntos con enlace explícito funcionan correctamente, estos tienen una apariencia poco convencional. Por ejemplo, el campo del adjunto debe representarse como una parte WSDL aunque, en muchos casos, este no puede modelarse como parte WSDL. El adjunto se anida como elemento de Definición de esquemas XML (XSD); sin embargo, un adjunto referenciado no logrará encontrarlo si estuviese anidado de esta manera. La siguiente sección explica una mejor forma de uso de adjuntos con el elemento de tipo swaRef creado por la organización WS-I.


Creación de un adjunto referenciado con el elemento de tipo swaRef

El adjunto de tipo swaRef se usa cuando un adjunto cumple con la especificación de tipo swaRef creada por WS-I. El uso de elementos de tipo swaRef podría ser un requisito obligatorio en una empresa de gran envergadura que imponga la especificación WS-I para todos los adjuntos como estándar de la empresa o en el caso de una aplicación que abarque varias empresas.

swaRef es un tipo XML para adjuntos. Al ser un tipo XML, puede usarse con complexTypes como objetos de negocios y con el estilo de enlace ajustado de literal de documento, que es el estilo de enlace más común para archivos WSDL. En resumen, con el elemento de tipo swaReft, los adjuntos se convierten en otro elemento WS-I estándar del esquema.

Siga los siguientes pasos para crear una aplicación que use un adjunto referenciado con el elemento de tipo swaRef:

  1. Integration Developer proporciona un recurso predefinido que lo ayudará a cumplir con la especificación de WS-I. Para usar este recurso predefinido, abra la sección Dependencies(Dependencias) de su módulo y expanda Predefined Resources(Recursos predefinidos). Seleccione WS-I attachment profile 1.0: swaRef schema file(Adjunto WS-I perfil 1.0: archivo de esquema swaRef), como muestra la Figura 8. Guarde su trabajo y cierre el editor de dependencias.
    Figura 8. Selección del archivo de esquema swaRef
    Selección del archivo de esquema swaRef
  2. Al agregar este recurso predefinido, se creará un tipo swaRef para ser usado en su aplicación. Cree una interfaz como lo hizo antes, pero esta vez mantenga el estilo de enlace document literal wrapped. Cree la misma operación y los mismos datos de entrada y salida, pero seleccione swaRef como tipo de photo y datos de entrada y salida photoVerified, como muestra la Figura 9. No necesitará definir un tipo de contenido binario.
    Figura 9. Interfaz con adjunto referenciado usando un elemento de tipo swaRef
    Interfaz con adjunto referenciado usando un elemento de tipo swaRef
  3. Agregue la interfaz y el enlace a una exportación igual que antes.

Prueba en el tiempo de ejecución

La prueba de los adjuntos en el tiempo de ejecución es similar a la realizada anteriormente. Sin embargo, al realizar la selección del archivo en el campo swaRef, el cliente de prueba le permitirá elegir cualquier tipo de archivo, ya que éste no puede determinar el tipo de archivo. Luego de la ejecución, el identificador de contenidos (cid) se muestra como valor devuelto. Como el cliente de prueba no puede determinar el tipo, éste no podrá verse en un visor de imágenes.

Sin embargo, puede mostrar o guardar la imagen como JPG seleccionando el evento de enlace de respuesta o en el editor de valores seleccionando íconos para ver o guardar el adjunto (Figura 10). La ayuda que aparece al pasar el mouse le indicará si puede View SOAP Attachment(Ver el adjunto SOAP) o Save SOAP Attachment(Guardar el adjunto SOAP).

Figura 10. Cliente de prueba con un adjunto referenciado que usa un elemento de tipo swaRef
Cliente de prueba con un adjunto referenciado que usa un elemento de tipo swaRef

Tras bambalinas

Observemos el esquema que resulta con el uso de un elemento de tipo swaRef en sus adjuntos. A diferencia de los adjuntos con enlace explícito, aquí vemos elementos complexType que incluyen el tipo swaRef esperado en el código WSDL (Listado 3).

Listado 3. Tipos swaRef contenidos en complexTypes
Tipos swaRef contenidos en complexTypes

A diferencia de los adjuntos con enlace explícito, aquí se usa un estilo ajustado de literal de documento. El mensaje WSDL contiene sólo una parte, como muestra el Listado 4.

Listado 4. El mensaje WSDL contiene sólo una parte
El mensaje WSDL contiene sólo una parte

El uso de un elemento de tipo swaRef en un adjunto tiene por resultado un código WSDL XML que cumple con la especificación del estándar abierto de WS-I. Por ejemplo, el contenido del adjunto no se divide en múltiples partes, como sucede en los adjuntos con enlace explícito. El artículo Web programming tips and tricks: Attachments using the wsi:swaRef XML type from WSI Explica las diferencias entre los adjuntos con enlace explícito y los adjuntos referenciados usando el elemento de tipo swaRef.


Uso de flujos de mediación para manipular adjuntos

Los flujos de mediación se usan para transformar mensajes y resultan de utilidad cuando se necesita realizar procesamiento adicional relacionado con adjuntos. Observe que en el código de muestra hemos incluido un flujo de mediación con los módulos EmployeeInformation y EmployeeInformationswaRef. En estos módulos, se envía un adjunto a un proceso de negocios.

Sin embargo, los procesos de negocios en realidad reciben únicamente la referencia al adjunto en el código WSDL, no el código en sí mismo. Necesitábamos cerciorarnos de que el adjunto se enviase al proceso de negocios de la solicitud y de que el adjunto procesado fuera devuelto a la aplicación. Por lo tanto, usamos un flujo de mediación para convertir el adjunto en un esquema en línea para el proceso de negocios.

Mire el módulo EmployeeInformation dentro de las carpetas Integration Logic > Mediation Flows(Lógica de intregración > Flujos de mediación) y haga doble clic en el flujo de mediación TestHarness para abrirlo. En la pestaña Request(Solicitud), haga doble clic en attachment to inline para ver el mapeo que creamos para la solicitud. Mapeamos los elementos operation1Parameters0 y verifyRecordInputParameter1 con los elementos id y image del Objeto de Mensaje de Servicio (SMO) transmitido al proceso de negocios. El mapeo se realiza arrastrando un controlador visual de un elemento en un extremo a un elemento en el otro extremo, como muestra la Figura 11.

Figura 11. Solicitud de flujo de mediación
Solicitud de flujo de mediación

En la pestaña Response del flujo de mediación, podrá ver cómo el adjunto verificado por la aplicación vuelve a transmitirse de forma similar. En este caso, verified_id y verified_image se devuelven al servicio llamante como elementos operation1Parameters0 y verifyRecordInputParameter1. Observe que, contrario a lo esperado, no se mapean verified_id y verified_image con los elementos dentro de attachments. A tales fines, deberemos asignar actividades. En particular, debemos asignar un valor (como muestra la Figura 12) al elemento bodyPath para lograr que el adjunto se devuelva en la respuesta como se espera.

Figura 12. Respuesta del flujo de mediación
Respuesta del flujo de mediación

En este artículo no centramos en un flujo de mediación para adjuntos con enlace explícito. Los flujos de mediación para adjuntos referenciados con elementos swaRef son diferentes. Para ver la mediación personalizada creada para el módulo EmployeeInformationswaRef, abra el flujo de mediación. En la sección Request, seleccione attachment to inline. Luego seleccione la pestaña Properties y la pestaña Details dentro de la vista Properties. Navegue el código Java para ver cómo se administró el flujo de mediación para el caso con el elemento swaRef.


Prueba de aplicaciones con adjuntos en suites de prueba

Probar seriamente las aplicaciones SOA significa construir varios casos de prueba a lo largo del tiempo y dividirlos en conjuntos de suites de prueba relacionados lógicamente que se ejecuten continuamente. A medida que vaya creciendo el número de aplicaciones que usen adjuntos para transmitir datos, podrá incorporar estas aplicaciones a la combinación de suites de prueba ejecutada por el editor de suites de prueba, el cual también soporta adjuntos.

El ejemplo de suite de prueba de adjuntos mostrado en la Figura 13 está incluido en el código de muestra proporcionado en este artículo. Para ejecutar esta prueba, expanda el proyecto de prueba del componente SwAComponentTest. En Test Suites > TestSuite > AttachmentTests(Suites de prueba > Suite de prueba > Pruebas de adjuntos), seleccione todas las pruebas usando el botón Ctrl. Haga clic derecho en las pruebas creadas y seleccionadas y luego seleccione Run Test(Ejecutar prueba). Ejecute la suite de pruebas usando la función continua como lo hizo anteriormente.

Al igual que en la prueba de adjuntos referenciados, en el caso de que reciba una excepción que indique que la URL de punto final es incorrecta, deberá verificar el número de puerto de su tiempo de ejecución para cada caso de prueba.

Figura 13. Adjuntos en la suite de prueba
Adjuntos en la suite de prueba

La seguridad en los adjuntos no referenciados

Integration Developer admite adjuntos no referenciados, es decir, adjuntos que no poseen una referencia en el cuerpo SOAP. Sin embargo, en estos adjuntos quedará bajo su responsabilidad el crear, probar y mantenerlos manualmente. Como los adjuntos no referenciados no se modelan en WSDL o en el enlace WSDL, usted deberá ocuparse de garantizar que el cliente y el servidor envíen y reciban documentos en un formato acordado. Su aplicación deberá determinar cuáles archivos WSDL contienen adjuntos y deberá contar con una forma de eliminarlos y procesarlos.

Si bien es posible aplicar un conjunto de políticas de seguridad de servicios web (WS-Security) al usar adjuntos, las configuraciones de privacidad o integridad no se aplicarán a los datos de los adjuntos. Para proteger el mensaje en su totalidad cuando trabaja con adjuntos, emplee la seguridad del nivel de transporte mediante HTTPS en lugar de HTTP. De esta manera, el mensaje HTTP en su totalidad, adjuntos inclusive, quedará protegido.

Los adjuntos suelen ser archivos de grandes dimensiones, por lo cual una práctica de programación recomendable es no usar adjuntos en su aplicación a menos que realmente los necesite; en lugar de adjuntos, use tokens para representarlos.


Limitaciones

Hasta la fecha en que se escribió este artículo, existían las siguientes limitaciones en el uso de adjuntos en Integration Developer V7.0.

Adjuntos con enlace explícito:

  • Integration Developer V7.0 no soporta la característica de mensajes MTOM (Mecanismo de optimización de transmisión de mensajes).
  • Integration Developer V7.0 n permite usar una exportación con enlace JAX-WS junto con un transporte SOAP 1.2/HTTP o SOAP 1.1/HTTP en el mismo módulo que una exportación con enlace JAX-RPC con transporte SOAP 1.1/HTTP.
  • Integration Developer V7.0 no soporta el tipo combinado de WSDL.
  • Cree un flujo de mediación similar al aquí mostrado cuando use un adjunto con un proceso de negocios. Esta nota técnica explica la consecuencia de no usar un flujo de mediación.
  • Aunque defina partes binarias en un mensaje WSDL y las enlace con las partes MIME en la definición WSDL, los adjuntos correspondientes no se crearán automáticamente cuando los mensajes se envíen mediante una importación o exportación en la respuesta. Para ello, deberá mapear los adjuntos en el encabezado usando un flujo de mediación. Esta nota técnica explica este problema inesperado del uso de partes binarias de mensajes.

Los adjuntos referenciados con elementos de tipo swaRef poseen restricciones similares con las siguientes diferencias:

  • La operación de interfaz no se limita únicamente a un estilo de enlace no ajustado literal de documento o un estilo de enlace literal RPC.
  • El tipo de datos de entrada o salida es swaRef.

Conclusión

El uso de adjuntos en aplicaciones SOA puede conferir mayor adaptabilidad y, al mismo tiempo, mejorar el rendimiento. En este artículo, hemos explicado los distintos tipos de adjuntos que pueden usarse y las especificaciones de código abierto en las cuales se basan estos adjuntos. Este artículo también describe las herramientas en WebSphere Integration Developer V7.0 que lo ayudarán a desarrollar y probar de forma rápida y sencilla una aplicación con adjuntos. Proporcionamos una serie de aplicaciones de muestra para que pueda realizar pruebas. Si usted se encontraba evaluando la posibilidad de incluir adjuntos en su aplicación y esperaba las herramientas que pudieran ayudarlo en esta tarea, éste es el momento para comenzar con su implementación.


Descargar

DescripciónNombretamaño
Code sampleattachments.zip161KB

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=485114
ArticleTitle=Uso de adjuntos en aplicaciones SOA con WebSphere Integration Developer V7
publish-date=08032011