Cómo exponer servicios RESTful usando un Bus de Servicios Empresariales

La misma lógica de negocios… más tipos de consumidores

A medida que REpresentational State Transfer (REST) se vuelve cada vez más popular, surgen más consumidores y proveedores de servicios que no son RESTful que deben adaptarse para hacer uso del estilo de invocación REST. Para esta adaptación, el Bus de Servicios Empresariales es capaz de brindar la mediación requerida para exponer servicios que no son RESTful para que sean invocados por esta arquitectura sin necesidad de realizar cambios a los mismos. Este artículo muestra cómo se pueden exponer los servicios con REST mediante IBM WebSphere Enterprise Service Bus, IBM WebSphere Message Broker y IBM WebSphere DataPower, y brinda ejemplos de cómo se verifica este trabajo y a los consumidores de la muestra usando distintas plataformas de programación.

Ahmed Abbas, Senior IT Architect, IBM  

Ahmed AbbasAhmed Abbas는 Cairo Technology Development Center 소속의 IT Architect이며 랩 서비스에서 고객의 비즈니스 요구에 부응하기 위해 기술의 이론과 실제 구현 사이의 차이를 줄여나가는 데 많은 관심을 두고 있다.



Mohab El-Hilaly, Staff Software Engineer, IBM  

MohabMohab El-Hilaly works as a Staff Software Engineer at IBM Cairo Technology Development Center, Egypt, where he develops and designs custom solutions using Websphere Enterprise Service Bus technology for various customers. Prior to that he developed custom solutions using various Microsoft Technologies, mainly ASP.NET. He obtained a bachelors degree in Computer Science from the American University in Cairo. In his spare time he enjoys watching and playing soccer.



Hany Harraz, WebSphere Consultant, IBM  

HanyHany Harraz works as a WebSphere Consultant for ISSW Tech Practice team at Cairo lab, Egypt, he is specialized in working with WebSphere Transformation Extender, DataPower, and WebSphere Message Broker. Prior to that he developed custom solutions using various Microsoft Technologies, mainly C#. He obtained a bachelors degree in Computer Engineering from Cairo University in Cairo. In his spare time he enjoys traveling and diving.



08-08-2011

Introducción

Como componente arquitectónico estratégico, un Bus de Servicios Empresariales (Enterprise Service Bus o ESB) proporciona una variedad de opciones para que los proveedores de servicios mejoren la consumabilidad de los servicios que brindan. Estas opciones permiten la reutilización de la lógica existente como servicios, mientras se atiende a una nueva clase de consumidores. La Transferencia de Estado Representacional usa las capacidades de interacción que normalmente ofrece el protocolo HTTP. WebSphere Enterprise Service Bus, WebSphere Message Broker y WebSphere DataPower son, todas ellas, capaces de manejar solicitudes en HTTP. Por lo tanto, todas ellas le brindan la capacidad de exponer servicios RESTful.


Características de los servicios RESTful

En términos claros, un servicio RESTful deberá ser accesible como un recurso localizable en la red que acepta un conjunto de verbos definidos por el implementador de dicho servicio. Estos conjuntos de verbos usualmente se mapean a métodos HTTP (por ejemplo: GET, POST, PUT y DELETE). Este mapeo constituye la práctica común, si bien no es obligatorio. El siguiente diagrama de secuencia muestra una típica interacción RESTful en la cual un cliente invoca a un servicio RESTful pasando un verbo y cierto contenido (como por ejemplo parámetros) para que sean procesados por dicho servicio.

Figura 1. Interacción RESTful típica
Interacción RESTful típica

TLa respuesta del servicio podría sumir una de varias representaciones. XML se encuentra dentro de estas representaciones, si bien podría consistir en cualquier otro formato que tenga sentido para el proveedor y el consumidor del servicio. Por ejemplo, si lo que se debe comunicar con el servicio es una aplicación Asynchronous JavaScript and XML (AJAX), tendrá mucho más sentido usar JavaScript Object Notation (JSON) que XML. Por otro lado, el ejemplo que se brinda más adelante en este artículo usa un formato binario en bruto para el intercambio de datos entre el cliente y el servicio con el fin de acentuar el hecho de que este formato es arbitrario.


Tecnologías Web 2.0 de relevancia

Existen otras tecnologías Web 2.0 que enriquecen las interacciones RESTful con el fin de simplificar la implementación. Las más comunes son JavaScript Object Notation “JSON” (que se puede usar para definir el formato de los objetos que devuelve un servicio) y Asynchronous JavaScript and XML “AJAX” (que usa un conjunto de tecnologías existentes para definir un modo de intercambio de datos desde un cliente hasta un servicio RESTful).

Debido a que el ejemplo que se describe en este artículo muestra el intercambio de datos en bruto, el intercambio de datos en formato JSON y la invocación del servicio desde un cliente AJAX constituirían un caso especial del ejemplo provisto.


Rol del Bus de Servicios Empresariales

Un Bus de Servicios Empresariales brinda capacidades de mediación a fin de proporcionar más opciones a los proveedores y consumidores del servicio. Una de las capacidades clave consiste en cambiar el modo en que se invoca un servicio sin tener que realizar cambios al servicio en sí mismo. Por ejemplo, usando uno de los productos de IBM Enterprise Service Bus, usted puede hacer que los servicios web basados en SOAP sean accesibles a los clientes de REST (el artículo se refiere a este escenario como el escenario Nº 1). Además, usted puede utilizar las capacidades del Bus de Servicios Empresariales para exponer servicios RESTful como servicios basados en SOAP para los clientes de servicios web (el artículo se refiere a este escenario como el escenario N 2). El siguiente diagrama muestra los dos escenarios tratados poniendo énfasis en el hecho de que la mediación implementada en el Bus de Servicios Empresariales funciona como una fachada para los recursos existentes: los servicios o componentes de servicios que comprenden la lógica del negocio.

Figura 2. El ESB puede exponer un servicio RESTful
El ESB puede exponer un servicio RESTful

Desde el punto de vista del negocio, si usted cuenta con servicios existentes que exponen todas las operaciones requeridas por los consumidores, no deberá realizar cambios a dichos servicios solamente para que se los pueda llamar utilizando otro modo, como por ejemplo, para que puedan ser invocados por REST cuando originalmente fueron programados para clientes basados en SOAP. Todo lo que se necesita es producir el artefacto de mediación adecuado y ponerlo a disposición de los consumidores en el ESB.

Las siguientes secciones de este artículo muestran cómo se implementa este tipo de mediación para ambos escenarios usando WebSphere ESB, WebSphere Message Broker y WebSphere DataPower. Más tarde, usted podrá ver algunas herramientas útiles que se usan para probar los artefactos de mediación que usted ha creado. También podrá ver ejemplos de consumidores que se implementan usando distintas plataformas de programación: Java, .NET y PHP.


Cómo implementar las mediaciones

Veamos cómo se implementan las mediaciones requeridas para los dos escenarios mencionados anteriormente con WebSphere Enterprise Service Bus, WebSphere Message Broker y WebSphere DataPower.

Ejemplos de servicios de back-end

Con el fin de mostrar los pasos de la implementación, supondremos la existencia de dos servicios: uno de ellos es un servicio web que se invoca usando SOAP/HTTP para ser usado en el escenario N 1, y el otro es un servicio RESTful que se usará en el escenario Nº 2. Ambos servicios brindan solo una operación simple que toma un número de cuenta como parámetro y devuelve un puntaje de crédito que corresponde a dicho número de cuenta en base a una regla trivial que representa la lógica del negocio. El siguiente listado WSDL muestra la interfaz del servicio web que se usa para el escenario Nº 1.

Listado 1. WSDL del servicio de back-end de muestra para el escenario Nº 1
<?xml version="1.0" encoding="UTF-8"?>
                <wsdl:definitions 
                name="AccountScore"
                targetNamespace="http://www.example.org/AccountScore/"
                xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                xmlns:tns="http://www.example.org/AccountScore/"
                xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
                <wsdl:types>
                <xsd:schema 
                targetNamespace="http://www.example.org/AccountScore/">
                <xsd:element name="getAccountScore">
                <xsd:complexType>
                <xsd:sequence> <xsd:element 
                name="accountNumber"
                type="xsd:string"/> 
                </xsd:sequence>
                </xsd:complexType> 
                </xsd:element> 
                <xsd:element
                name="getAccountScoreResponse">
                <xsd:complexType>
                <xsd:sequence> 
                <xsd:element name="score"
                type="xsd:string"/> 
                </xsd:sequence>
                </xsd:complexType> 
                </xsd:element>
                </xsd:schema> 
                </wsdl:types> <wsdl:message
                name="getAccountScoreRequest"> 
                <wsdl:part
                element="tns:getAccountScore"
                name="parameters"/>
                </wsdl:message> 
                <wsdl:message
                name="getAccountScoreResponse"> 
                <wsdl:part
                element="tns:getAccountScoreResponse"
                name="parameters"/>
                </wsdl:message> <wsdl:portType 
                name="AccountScore">
                <wsdl:operation name="getAccountScore">
                <wsdl:input
                message="tns:getAccountScoreRequest"/> 
                <wsdl:output
                message="tns:getAccountScoreResponse"/>
                </wsdl:operation>
                </wsdl:portType> 
                <wsdl:binding name="AccountScoreSOAP"
                type="tns:AccountScore"> 
                <soap:binding style="document"
                transport="http://schemas.xmlsoap.org/soap/http"/>
                <wsdl:operation
                name="getAccountScore"> 
                <soap:operation
                soapAction="http://www.example.org/AccountScore/NewOperation"/>
                <wsdl:input>
                <soap:body use="literal"/>
                </wsdl:input> 
                <wsdl:output> 
                <soap:body
                use="literal"/> 
                </wsdl:output> 
                </wsdl:operation>
                </wsdl:binding> 
                <wsdl:service name="AccountScore">
                <wsdl:port binding="tns:AccountScoreSOAP"
                name="AccountScoreSOAP">
                <soap:address location=
                "https://localhost:9446/AccountScore/services/AccountScoreSOAP"/>
                </wsdl:port> </wsdl:service>
                </wsdl:definitions>

El servicio RESTful usado para el escenario Nº 2 de nuestro ejemplo es un simple servlet cuyo método doPost() se muestra en el siguiente listado.

Listado 2. doPost()del servicio de back-end de muestra para el escenario Nº 2
BufferedReader br = new BufferedReader(new InputStreamReader(request
                .getInputStream()));
                String inputString=br.readLine();
                System.out.println(inputString); 
                String outputString="";
                if(inputString.equals("AccountNum=123")) 
                outputString="Score=4000"; 
                else
                if(inputString.equals("AccountNum=456"))
                outputString="Score=6000";
                else
                outputString="Score=N/A";
                OutputStream os = response.getOutputStream(); byte[]
                buffer = new byte[outputString.getBytes().length];
                response.setContentType(request.getContentType()); 
                buffer=outputString.getBytes();
                os.write(buffer, 0, buffer.length);
                os.flush(); os.close();

Para invocar a este servlet, usted sólo debe enviar una solicitud POST HTTP al URL donde se encuentra implementado el servlet con un cuerpo que incluya el texto “AccountNum=123” o “AccountNum=456”.

Observe que los ejemplos que se tratan en este artículo sólo manejan un verbo (POST) por razones de simplicidad. Quizás usted deba agregar más complejidad al frente de recepción, en caso que haya varios verbos que se deban soportar.

El resto de la presente sección le muestra los pasos a seguir para implementar la mediación para que estos dos servicios comprendan ambos escenarios.


Uso de WebSphere Enterprise Service Bus

Debido a que las interacciones RESTful utilizan las capacidades del protocolo HTTP, WebSphere Enterprise Service Bus soporta interacciones RESTful usando enlaces normales HTTP. El resto de esta sección se ocupa de explicar la idea y la implementación de los escenarios Nº 1 y 2 en el WebSphere Enterprise Service Bus.

Cómo entender el escenario Nº 1

Para poder implementar el escenario Nº 1, usamos una exportación con enlace HTTP para aceptar las solicitudes HTTP de los clientes de REST. Vale la pena mencionar que usted puede configurar la exportación HTTP para que use uno de los selectores de funciones incorporados o para que desarrolle un selector de funciones personalizado para decidir qué operación deberá realizarse en función del mensaje de solicitud. En nuestro ejemplo, el servicio web de back-end ofrece solamente una operación. Por lo tanto, no será necesario ningún selector de funciones. Puede consultar el tema “Function selectors in export bindings” [Selectores de funciones en enlaces de exportación] del WebSphere Integration Developer Information Center.

La siguiente ilustración muestra que la exportación HTTP se conecta a un flujo de mediación que realiza la transformación requerida de la carga útil (cuerpo de la solicitud HTTP) enviada desde el cliente de REST. Como se mencionara anteriormente, el ejemplo que brindamos envía los datos de la carga útil como datos binarios. En consecuencia, el flujo de mediación transforma el contenido binario de la carga útil al formato de cadena para que forme parte del XML que elabora la solicitud SOAP que pasa al servicio de back-end.

Figura 3. Provisión de una interfaz RESTful para un servicio web
Provisión de una interfaz RESTful para un servicio web

Es posible que el flujo de mediación invoque distintos tipos de back-ends. Sin embargo, para poder implementar el escenario Nº 1, el flujo de mediación invoca al servicio web de back-end de muestra usando una importación con enlace a servicios web.

Cómo implementar el escenario Nº 1

Esta sección muestra los pasos a seguir para implementar el escenario Nº 1 con WebSphere Integration Developer. Para permitir que el módulo Mediation pueda tratar la solicitud HTTP y responder como datos binarios, deberán seguirse algunos pasos con anterioridad a la implementación.

  1. Asegúrese de estar en la perspectiva Business Integration (Integración de negocios). En la vista Business Integration, cree un módulo de mediación, y luego haga clic sobre el mismo con el botón derecho del mouse. En el menú contexto seleccione Open Dependencies (Abrir dependencias), como se muestra a continuación.
Figura 4. Selección de "Open Dependencies" en el menú contexto
Selección de
  1. En Predefined Resources (Recursos predefinidos), seleccione Schema for predefined HTTP bytes data binding (Esquema para el enlace predefinido de los datos HTTPbytes). Guarde su trabajo y cierre el editor de dependencias.
Figura 5. Selección de "Schema for predefined HTTP bytes data binding"
Selección de
  1. Verifique que se hayan creado dos nuevos tipos de datos en la sección Data Types (Tipos de datos), como se muestra a continuación.
Figura 6. Los dos tipos de datos creados
Los dos tipos de datos creados
  1. Cree una interfaz que se usará para exponer nuestro modulo de mediación recientemente generado. Los datos de entrada y de salida de la interfaz deben ser del tipo HTTPBytes (uno de los dos tipos de datos creados en el paso anterior) para que la carga útil pueda ser tratada como datos binarios.
Figura 7. Los datos de entrada y salida de la interfaz del modulo de mediación deben aceptar datos binarios
Los datos de entrada y salida de la interfaz del modulo de mediación deben aceptar datos binarios

Ahora que ha creado una interfaz lista para aceptar datos binarios, usted está listo para usarla con una Exportación para exponer el módulo en HTTP siguiendo estos pasos.

  1. Cree una nueva Exportación en el Assembly Editor (Editor de ensamblaje) y arrastre y suelte en dicha Exportación la interfaz creada anteriormente.
Figura 8. Creación de una nueva exportación con la interfaz generada
Creación de una nueva exportación con la interfaz generada
  1. Con el botón derecho del mouse, haga clic en la Exportación creada en el Assembly Editor. Seleccione Generate Binding > HTTP Binding en el menú contexto.
Figura 9. Generación de un enlace HTTP para la exportación
Generación de un enlace HTTP para la exportación
  1. Ingrese la Ruta de acceso del contexto, que formará parte del URL, al módulo de mediación que represente el servicio RESTful. Por ejemplo, el URL del servicio RESTful podría ser http://your_server_ip:your_server_port/RestIntegration_MediationModuleWeb/Export1
Figura 10. Configuración de la “ruta de acceso del contexto” de la exportación
Configuración de la “ruta de acceso del contexto” de la exportación
  1. Conecte la exportación a la primitiva del flujo de mediación.
Figura 11. Conexión de la exportación al flujo de mediación
Conexión de la exportación al flujo de mediación

En este momento, el módulo de mediación es capaz de acceder a los datos binarios en HTTP. Los siguientes pasos le enseñarán a hacer que el módulo de mediación invoque un servicio web de back-end basado en SOAP para completar el escenario Nº 1.

  1. En el Assembly Editor, arrastre y suelte el archivo WSDL del servicio web de muestra para el escenario Nº 1 sobre el lienzo y seleccione Import with Web Service Binding (Importar con enlace al servicio web). Con este paso se crea una nueva importación basada en el WSDL del ejemplo.
Figura 12. Selección de "Import with Web Service Binding"
Selección de
  1. Conecte la primitiva del flujo de mediación a la importación recientemente creada.
Figura 13. Conexión del flujo de mediación a la importación
Conexión del flujo de mediación a la importación
  1. Haga doble clic sobre el flujo de mediación para mapear la operación que usted está proporcionando a los consumidores de REST a la operación provista por el servicio web de back-end.
Figura 14. Mapeo de operaciones entre las interfaces de la exportación y la importación
Mapeo de operaciones entre las interfaces de la exportación y la importación
  1. Cree una nueva primitiva para el Business Object Mapper (Mapeador de objetos de negocios) en el lienzo, cuya función será la de convertir los datos de entrada binarios a una cadena para poder manipularlos. Lo que hará es simplemente traducir el mensaje proveniente de la operación de solicitud getScore de la exportación a la operación de solicitud getAccountScore de la importación. Otros modos de hacerlo consisten en usar una mediación a medida o una primitiva XSLT.
Figura 15. Creación de un Business Object Mapper que contenga el mapeo de los mensajes entre la exportación y la importación
Creación de un Business Object Mapper que contenga el mapeo de los mensajes entre la exportación y la importación
  1. Cree un mapa a medida para que realice el mapeo dentro del Business Object Mapper creado en el paso anterior.
Figura 16. Creación del mapa para la solicitud
Creación del mapa para la solicitud
Listado 3. Mapa a medida para procesar la solicitud
                String inputString= new
                String((byte[])ServiceMessageObject_body_getScore_input1_value);
                String
                accNum=inputString.split("=")[1];
                ServiceMessageObject_1_body_getAccountScore_accountNumber=accNum;
  1. Cree un mapa similar en la ruta de respuesta para que convierta la cadena de la respuesta del servicio web a formato binario.
Figura 17. Creación del mapa para la respuesta
Creación del mapa para la respuesta
Listado 4. Mapa a medida para el procesamiento de la respuesta
String
  Score="Score=";
  Score+=ServiceMessageObject_body_getAccountScoreResponse_score;
                ServiceMessageObject_1_body_getScoreResponse_output1_value=
				Score.getBytes();

En este momento, usted posee una mediación RESTful equivalente al servicio web de muestra provisto anteriormente. Esta mediación es accesible a través del URL especificado en la exportación (paso 7) y acepta la acción POST HTTP. Además, el servicio también realiza una operación que verifica la evaluación crediticia para un número de cuenta que se pasa como parámetro en el cuerpo de la solicitud HTTP que sigue el formato: "AccountNum=XYZ". la respuesta aparece en código binario e incluye una cadena que representa la evaluación crediticia que corresponde al titular de la cuenta cuyo número se especifica como parámetro.

Cómo entender el escenario Nº 2

la implementación del escenario Nº 2 es similar a la del escenario anterior en términos de los artefactos creados y su uso, como se muestra en la siguiente figura.

Figura 18. Cómo proporcionar una interfaz a servicio web para un servicio RESTful
Cómo proporcionar una interfaz a servicio web para un servicio RESTful

Las únicas diferencias son que la exportación usa un enlace de servicio web, la importación usa un enlace HTTP y el flujo de mediación extrae la carga útil de la solicitud SOAP y la envía como carga útil binaria al servicio RESTful de back-end de muestra.

Implementación del escenario Nº 2

Los siguientes pasos le muestran de qué manera usted puede usar un módulo de mediación para mediar entre los clientes basados en SOAP y los servicios RESTful de back-end usando WebSphere Integration Developer.

  1. Cree una nueva interfaz para usarla con la exportación con el fin de exponer el módulo de mediación como un servicio web.
Figura 19. Creación de la interfaz que se usará con la exportación
Creación de la interfaz que se usará con la exportación
  1. Arrastre y suelte la interfaz sobre el lienzo del Assembly Editor y elija Export with Web Service Binding (Exportar con enlace de servicio web).
Figura 20. Creación de una exportación basada en la interfaz
Creación de una exportación basada en la interfaz
  1. Use la interfaz que ha creado cuando implementó el escenario N 1 en los pasos 1 a 4. Esta vez, usted la usará con la importación para invocar el servicio RESTful de back-end de muestra que se usará en el escenario Nº 2. Arrastre y suelte la interfaz en el lienzo y seleccione Import with no Binding (Importar sin enlace). Usted definirá el enlace en el siguiente paso.
Figura 21. Creación de una importación
Creación de una importación
  1. Con el botón derecho del mouse, haga clic en la importación creada y seleccione Generate Binding > HTTP Binding.
Figura 22. Generación de un enlace HTTP para la importación
Generación de un enlace HTTP para la importación
  1. Especifique el URL donde figura la dirección del proveedor de REST. En nuestro ejemplo, usamos el servlet simple para el cual anteriormente en este artículo se brindó el método doPost().
Figura 23. Cómo fijar el URL de punto final a la dirección del servicio RESTful
Cómo fijar el URL de punto final a la dirección del servicio RESTful
  1. Conecte el flujo de mediación con la Importación y la Exportación, y estará listo para implementar el flujo de mediación en sí mismo.
Figura 24. Conexión de la exportación y la importación al flujo de mediación
Conexión de la exportación y la importación al flujo de mediación

En este momento, usted tiene una mediación del servicio web equivalente al servicio RESTful de muestra proporcionado anteriormente (como servlet simple). Esta mediación realiza la misma funcionalidad que la provista por la que usted creó para el escenario Nº 1, aunque esta vez con una interfaz basada en SOAP.


Uso de WebSphere Message Broker

WebSphere Message Broker soporta interacciones RESTful usando tres primitivas dentro de un flujo de mensajes: HTTPInput, HTTPRelpy y HTTPRequest. El resto de esta sección se ocupa de explicar la idea y la implementación de los escenarios Nº 1 y 2 en WebSphere Message Broker.

Cómo entender el escenario Nº 1

La implementación del escenario Nº 1 en WebSphere Message Broker no difiere demasiado en el aspecto conceptual del WebSphere Enterprise Service Bus. Se puede usar un nodo HTTPInput para aceptar las solicitudes HTTP de los clientes REST, como se muestra en la siguiente figura.

Figura 25. Cómo proporcionar una interfaz RESTful para un servicio web
Cómo proporcionar una interfaz RESTful para un servicio web

HTTPInput reenvía las solicitudes a un nodo Compute (Calcular) que realiza la transformación necesaria de la carga útil de la solicitud del tipo binario al de cadena para poder realizar cualquier otro procesamiento que resulte necesario. El nodo Compute invoca el servicio web de back-end de muestra para el escenario Nº 1 a través de un nodo SOAPRequest para manejar la comunicación basada en SOAP. Un nodo HTTPReply es le encargado de elaborar la respuesta HTTP para reenviarla al cliente REST que la solicitara.

Implementación del escenario Nº 1

Esta sección muestra los pasos a seguir para la implementación del escenario Nº 1 usando la caja de herramientas de WebSphere Message Broker.

  1. Cree un flujo de mensajes, luego arrastre y suelte un nodo HTTPInput en el lienzo e ingrese el sufijo de la ruta de acceso para el URL correspondiente a HTTPInput que formará parte del direccionamiento del URL al flujo que representa el servicio RESTful. El acceso al nodo de datos de entrada para la dirección de la solicitud será algo similar a http://localhost:7080/Rest
Figura 26. Configuración del "sufijo de la ruta para URL"
Configuración del
  1. Asegúrese de que el tipo de mensaje sea Binary Large Object (Gran Objeto Binario)" BLOB" para evitar que el nodo analice la carga útil del mensaje entrante del cliente de REST. Luego, la carga útil pasa como está (datos binario) al nodo compute que usted creará en un momento.
Figura 27. El dominio del mensaje HTTPInput es BLOB
El dominio del mensaje HTTPInput es BLOB
  1. Aquí viene la parte que invoca el servicio web de back-end de muestra. Arrastre y suelte en el lienzo el archivo WSDL importado del servicio web de back-end de muestra para el escenario Nº 1. Se creará un sub-flujo denominado Service Invocation (Invocación de servicio). Para poder verificar que se ha creado, haga doble clic sobre el sub-flujo: deberán aparecer las primitivas de la invocación.
Figura 28. Sub-flujo de invocación del servicio
Sub-flujo de invocación del servicio
  1. Agregue un nodo compute antes y después de la Invocación del servicio para traducir el mensaje de BLOB a SOAP y viceversa. Luego, coloque un nodo HTTPReply para devolver la respuesta requerida.
Figura 29. Flujo del mensaje completo
Flujo del mensaje completo
  1. Para poder agregar el código que realiza la transformación, haga doble clic sobre el nodo Compute antes de la Invocación del servicio. Para ello, usted podrá usar el siguiente snippet de código.
Listado 5. Código para transformar la carga útil binaria en XML
DECLARE
                InputString CHARACTER; 
                DECLARE OutString CHARACTER; DECLARE CCNum CHARACTER;
                SET
                InputString = CAST ( InputRoot.BLOB.BLOB AS CHAR CCSID 1208); 
                SET OutString =
                OVERLAY(InputString PLACING '' FROM 1 FOR POSITION('=' IN InputString));
                SET
                OutputRoot.SOAP.Body.ns:getAccountScore.accountNumber=OutString; 
                RETURN TRUE;
  1. Agregue el código para el nodo Compute después de la invocación del servicio, como se muestra en el siguiente Listado 5.
Listado 6. Código para transformar SOAP en binario
                DECLARE OutString CHARACTER
                'Score='; Set OutString= OutString ||
                InputRoot.XMLNSC.ns:getAccountScoreResponse.score; 
                SET OutputRoot.BLOB.BLOB=CAST
                (OutString AS BLOB CCSID 1208); 
                RETURN TRUE;

Luego de completar los pasos anteriores, usted tundra una mediación RESTful que se comportará de la misma manera que la mediación RESTful que usted creara cuando implementó el escenario Nº 1 en el WebSphere Enterprise Service Bus. La dirección URL del nuevo servicio RESTful es la que usted especificó en el paso Nº 1 anterior.

Cómo entender el escenario Nº 2

WebSphere Message Broker brinda nodos SOAPInput para aceptar solicitudes basadas en SOAP de los clientes de servicios web. La siguiente figura muestra que la solicitud se reenvía luego a un nodo Compute que realizará la transformación de la solicitud entrante de SOAP a binario.

Figura 30. Provisión de una interfaz de servicio web para un servicio RESTful
Provisión de una interfaz de servicio web para un servicio RESTful

El mensaje binario se usa para invocar el servicio RESTful de muestra anteriormente mencionado en este artículo para ser utilizado en el escenario Nº 2 a través de un nodo HTTPRequest. Luego, se usa un nodo Compute para transformar el resultado nuevamente a SOAP para que pueda ser enviado nuevamente al cliente del servicio web que lo solicitara a través de un nodo SOAPReply.

Implementación del escenario Nº 2

Esta sección muestra los pasos a seguir para implementar el escenario Nº 2 con la caja de herramientas de WebSphere Message Broker.

  1. 1. Para exponer el flujo como un servicio web, importe el archivo WSDL del servicio web de muestra a un nuevo conjunto de mensajes. Arrastre y suelte el WSDL en el lienzo para poder comenzar a usarlo en los siguientes pasos.
Figura 31. Cómo importar el archivo WSDL del servicio de muestra
Cómo importar el archivo WSDL del servicio de muestra
  1. Coloque un nodo Compute para convertir los datos del mensaje entrante de SOAP a BLOB (binarios) de manera que puedan ser enviados al servicio RESTful de back-end.
Listado 7. Código para transformar SOAP en binario
                DECLARE OutString CHARACTER
                'AccountNum='; Set OutString= OutString ||
                InputRoot.SOAP.Body.ns:getAccountScore.accountNumber;
                SET OutputRoot.BLOB.BLOB=CAST
                (OutString AS BLOB CCSID 1208); RETURN TRUE;
Listado 8. Código para transformar binario en SOAP
                DECLARE InputString CHARACTER;
                DECLARE OutString CHARACTER; 
                SET InputString = CAST ( InputRoot.BLOB.BLOB AS CHAR
                CCSID 1208); 
                SET OutString = OVERLAY(InputString PLACING ''
                FROM 1 FOR POSITION('='
                IN InputString)); 
                Set OutputRoot.XMLNSC.ns:getAccountScoreResponse.score=OutString;
                RETURN TRUE;
Figura 32. Agregado de un nodo compute para transformar SOAP en BLOB
Agregado de un nodo compute para transformar SOAP en BLOB
  1. Coloque un nodo HTTPRequest que invocará el servicio RESTful de back-end de muestra.
Figura 33. Agregado de un nodo HTTPRequest
Agregado de un nodo HTTPRequest
  1. Para el nodo HTTPRequest, ingrese la dirección URL del servicio RESTful. En nuestro ejemplo, usamos el servlet simple para el cual se proporcionó anteriormente en este artículo el método doPost().
Figura 34. Cómo especificar el punto final del servicio de back-end
Cómo especificar el punto final del servicio de back-end
  1. Por último, coloque un nodo Compute para convertir la respuesta proveniente el servicio RESTful de back-end en una respuesta SOAP que se enviará al cliente de servicio web que llamara a través de un nodo SOAPReply que usted agregará.
Figura 35. Agregado de un nodo Compute y de un nodo SOAPReply
Agregado de un nodo Compute y de un nodo SOAPReply

En este momento, usted tiene un servicio web equivalente que se comporta exactamente igual que el que creara anteriormente con el WebSphere Enterprise Service Bus cuando implementó el escenario N 2.


Uso de WebSphere DataPower

WebSphere DataPower soporta interacciones RESTful de distintas maneras. Esta sección explica un modo de implementar los escenarios Nº 1 y 2 en WebSphere DataPower.

Cómo entender el escenario Nº 1

Existen diversas maneras de implementar el escenario N 1. Aquí le mostramos el modo de implementación recomendado que usa un Firewall XML para aceptar las solicitudes HTTP de un cliente de REST, como se muestra más adelante.

Figura 36. Provisión de una interfaz RESTful para un servicio web
Provisión de una interfaz RESTful para un servicio web

Debido a que las solicitudes entrantes contienen una carga útil binaria, el Firewall XML utilizará un mapa de WebSphere Transformation Extender para transformar la carga útil binaria en SOAP para que pueda ser aceptada por los servicios web. También se realiza una transformación en sentido inverso al transformar la respuesta en SOAP del servicio web en binaria, para que pueda ser enviada al cliente REST que la solicitara. Además de estas transformaciones, el Firewall XML usa una función XSLT para invocar el servicio web de back-end por medio de un Web Service Proxy. En consecuencia, en este escenario usamos la opción de bucle invertido para el Firewall XML. Como opción, esto podría lograrse usando un back-end estático que llamara al Web Service Proxy.

Para ver otra transformación de esta implementación sin manipulación de la carga útil binaria, consulte el siguiente artículo: http://www.ibm.com/developerworks/websphere/techjournal/0903_peterson/0903_peterson.html.

Implementación del escenario Nº 1

Esta sección le muestra los pasos necesarios para implementar el escenario Nº 1 en WebSphere DataPower. En primer lugar, realice el mapa de transformación entre binario y XML. Luego, configure el Web Service Proxy para que maneje la comunicación con el servicio web de back-end. Por último, use el mapa que ha creado con el Firewall XML, que será el responsable de recibir las solicitudes REST, transformar la carga útil de binaria a XML y de ingresarla al Web Service Proxy que, a su vez, la pasará al servicio web de back-end de muestra.

En primer lugar, construyamos dos Árboles de Tipos con WebSphere Transformation Extender Design Studio para definir cómo serán tanto el mensaje de solicitud entrante como los mensajes SOAP enviados al servicio web de back-end de muestra.

Para los datos de entrada que no sean xml generaremos el árbol de tipos de manera manual; esperamos que los datos de entrada ingresen en este formato: AccountID=123.

  1. Cree un nuevo árbol de tipos para los mensajes entrantes del cliente de REST, los cuales usted tratará como binarios (o que no son XML).
Figura 37. Creación del Árbol de tipos
Creación del Árbol de tipos
  1. Cree un Grupo y dos Artículos en el recientemente creado Árbol de tipos, como se muestra más adelante.
Figura 38. Creación de descendientes
Creación de descendientes
  1. Debido a que se espera que la carga útil del cliente de REST tenga el formato AccountNum=123, fije el terminador para Artículo denominado "Property (Propiedad)" en "=", de manera que el motor WTX interprete la parte anterior al signo '=' como del tipo "Property", y reconozca que el valor es la parte que sigue al digno igual.
Figura 39. Cómo definir el separador
Cómo definir el separador
  1. Seleccione Tree > Analyze, y luego Save.
  2. Cree otro árbol de tipos para que se envíe el mensaje en SOAP al servicio web de back-end de muestra. Usted podrá crear este Árbol de tipos importando el archivo WSDL del servicio web de back-end de muestra.
Figura 40. Importación del WSDL del servicio de back-end
Importación del WSDL del servicio de back-end
  1. Acepte los valores predeterminados, y presione el botón Finish. Abra el árbol generado, luego presione Analyze y Save.

En este momento, usted ha creado los dos archivos Map Type Tree (MTT). En los siguientes pasos, los encontrará como Binary.mtt para el que describe el mensaje binario del cliente y como AccountScore.mtt para el que describe el mensaje basado en el archivo WSDL del servicio web de back-end de muestra. Ahora, usted está listo para usar estos Árboles de tipo con el fin de crear el mismo Mapa para poder seguir los pasos que aparecen a continuación.

  1. Cree un nuevo mapa con una Tarjeta de Entrada y una Tarjeta de Salida, como se muestra a continuación.
Figura 41. Creación de un nuevo mapa
Creación de un nuevo mapa
  1. Configure las propiedades para la Tarjeta de Entrada "Binary" con los valores que se muestran más adelante, donde binary.txt es un archivo de texto que incluye AccountID=123 con fines de prueba. Observe que usted está estableciendo el Árbol de tipos con el nombre del Árbol de tipos que creara anteriormente para los mensajes binarios.
Figura 42. Cómo configurar las propiedades de la Tarjeta de Entrada
Cómo configurar las propiedades de la Tarjeta de Entrada
  1. Configure las propiedades de la Tarjeta de Salida "XML_OUT" como se muestra más adelante. Esta tarjeta utiliza el otro árbol de tipos que usted creara anteriormente para los mensajes del servicio web basados en SOAP.
Figura 43. Cómo configurar las propiedades de la Tarjeta de Salida
Cómo configurar las propiedades de la Tarjeta de Salida
  1. Complete el mapeo usando los valores que se muestran a continuación.
Figura 44. Mapeo de los campos
Mapeo de los campos
  1. Seleccione Map > Build, Map > Run para probar el mapa.
  2. Cambie la propiedad MapRuntime de Map Settings en el mapa a DataPower en lugar de WebSphere Transformation Extender, de manera que se pueda implementar el mapa compilado en DataPower con la extensión ".dpa". Por ejemplo, usted puede denominar al archivo "BinaryToXML.dpa". Seleccione Map > Build para generar el archivo.
Figura 45. Preparación para la implementación
Preparación para la implementación

Ahora que usted ha realizado todo el mapeo de tipos, está listo para implementar los artefactos que ha creado en el dispositivo SOA de WebSphere DataPower. Antes de aplicar el mapeo, usted deberá crear un Web Service Proxy y un Firewall XML en WebSphere DataPower siguiendo estos pasos.

  1. En el panel de Control, haga clic en el ícono Web Service Proxy, y luego sobre Add. Escriba el nombre del Web Service Proxy, por ejemplo WS-BinaryToSOAP, y presione el botón Create Web Service Proxy.
  2. Si todavía no tiene cargado el WSDL del servicio web de back-end de muestra, ingrese el File to upload (Archivo para cargar) y presione Upload (Cargar).
Figura 46. Cómo cargar el archivo WSDL
Cómo cargar el archivo WSDL
  1. Luego de cargar el archivo, presione Next.
Figura 47. Cómo completar las configuraciones del Web Service Proxy
Cómo completar las configuraciones del Web Service Proxy
  1. Cree un nuevo Front Side Handler (Controlador de la parte frontal). Asigne un IP, un Puerto y los verbos de soporte, y luego haga clic en Add.
Figura 48. Cómo crear un Front Side Handler
Cómo crear un Front Side Handler
  1. Antes de presionar Next, configure el IP, el Puerto y el URI remoto para el servicio web de back-end de muestra.

El Web Service Proxy se encuentra ahora configurado y está listo para invocar el servicio de back-end de muestra. Los siguientes pasos le muestran cómo se configure un Firewall XML con bucle invertido que se encargará de ingresar las solicitudes entrantes al Web Service Proxy que usted ha creado.

  1. En el panel de control de DataPower elijaXML Firewall. Luego, presione Add.
  2. Seleccione Pass Thru, como se muestra a continuación. Luego presione Next.
Figura 49. Cómo crear un Firewall XML con bucle invertido
Cómo crear un Firewall XML con bucle invertido
  1. Ingrese un nombre. RESTtoSOAPService, por ejemplo.
  2. Seleccione el Firewall Type (Tipo de firewall) para que sea loopback-proxy.
  3. Ingrese la Device Address (Dirección del dispositivo) y el Puerto que reibirá las solicitudes entrantes de los clientes. No se aconseja establecer la IP como 0.0.0.0. Haga clic en Next.
Figura 50. Configuración de la dirección del Firewall XML
Configuración de la dirección del Firewall XML
  1. Seleccione Commit, y luego Done.
  2. Abra las configuraciones del Firewall XML y modifique el Request Type (Tipo de solicitud) para que sea Non-XML, debido a que esperamos una carga útil binaria del cliente de REST.
  3. Abra la Firewall Policy (Política de Firewall) para editarla. Como se tratará a continuación, existen cuatro acciones posibles.
Figura 51. Edición de la Política de Firewall XML
Edición de la Política de Firewall XML
  1. Una regla de correspondencia, que acepta todas las solicitudes entrantes para cualquier URI en el Puerto y la dirección IP especificados.
  2. Una acción de transformación binaria, que llama a uno de los mapas WTX que fuera creado en un paso anterior, y convierte los datos de entrada binarios en una Solicitud SOAP, como se muestra más adelante.
Figura 52. Configuración de la acción de transformación binaria
Configuración de la acción de transformación binaria
  1. Una acción de transformación que usa un simple XSLT para llamar al servicio de back-end de muestra por medio del Web Service Proxy, y crea el mensaje de respuesta que será enviado al cliente que lo solicitara. A continuación se muestra la plantilla para esta transformación.
Listado 9. Plantilla que llama al Web Service Proxy
                <?xml version="1.0"
                encoding="UTF-8"?> 
                <xsl:stylesheet
                xmlns:dp="http://www.datapower.com/extensions"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                extension-element-prefixes="dp"
                exclude-result-prefixes="dp" version="1.1"> 
                <xsl:template
                match="/"> <xsl:copy-of
                select="dp:soap-call
                ('http://the_address_of_wsproxy:the_port
                _of_wsproxy/mockAccountScoreSOAP',/,'',0)"/>
                </xsl:template>
                </xsl:stylesheet>
  1. Una acción de transformación binaria que usa una hoja XSL que transforma la respuesta SOAP en una respuesta que no es XML para ser enviada al cliente. A continuación se muestra la plantilla para esta transformación.
Listado 10. Plantilla que realiza la transformación de SOAP a binario
                <?xml
                version="1.0" 
                encoding="UTF-8"?> 
                <xsl:stylesheet version="1.0"
                xmlns:xsl=
                "http://www.w3.org/1999/XSL/Transform"
                xmlns:fo=
                "http://www.w3.org/1999/XSL/Format"> 
                <xsl:output
                method="text"/> <xsl:template
                match="/">score=<xsl:value-of 
                select="//score"/>
                </xsl:template> 
                </xsl:stylesheet>

Al seguir los pasos anteriores, usted obtendrá un servicio RESTful que se comportará igual que el servicio RESTful que usted creó cuando implementó el escenario Nº 1 en WebSphere Enterprise Service Bus y WebSphere Message Broker. La dirección URL del nuevo servicio RESTful corresponde al Firewall XML.

Cómo entender el escenario Nº 2

Para el escenario Nº 2, básicamente intercambiamos el Web Service Proxy con el Firewall XML y viceversa, como se muestra a continuación.

Figura 53. Provisión de una interfaz de servicio web para un servicio RESTful
Provisión de una interfaz de servicio web para un servicio RESTful

El Web Service Proxy acepta las solicitudes SOAP de clientes de servicios web basadas en el WSDL del servicio web de back-end de muestra, luego pasa la solicitud al Firewall XML para realizar la transformación necesaria entre SOAP y el código binario. El Firewall XML también invoca el servicio RESTful de back-end de muestra.

Implementación del escenario Nº 2

Como lo hiciera para el escenario Nº 1, usted comenzará por crear los artefactos necesarios para realizar el mapeo entre los contenidos basados en XML y los binarios con WebSphere Transformation Extender Design Studio. Afortunadamente, usted puede usar los dos tipos de árboles de tipo creados para el escenario Nº 1. Sin embargo, los usará de manera diferente. Los siguientes pasos muestran cómo se crea un Mapa de Respuestas para que realice el mapeo de la respuesta binaria devuelta desde el servicio RESTful de back-end de muestra a SOAP de manera que pueda ser enviada nuevamente al cliente de servicio web que la solicitara a través del Web Service Proxy.

  1. Siga los mismos pasos que siguió para la creación del mapa de solicitudes del escenario Nº 1 para crear un Mapa de Respuestas. Para la Tarjeta de Salida XML_OUT, seleccione el grupo Envelope (Sobre) para la respuesta como se muestra en la siguiente instantánea.
Figura 54. Creación del Mapa de Respuestas
Creación del Mapa de Respuestas
  1. Complete el mapeo como se muestra a continuación. Puede también seleccionar Rules > Insert NONE if Empty para configurar automáticamente los campos vacíos en NONE (NINGUNO).
Figura 55. Mapeo de los campos
Mapeo de los campos
  1. Select Map > Build, the Map > Run to test map.
  2. Modifique MapRuntime a WebSphere DataPower en Map Settings (Configuraciones del Mapa), como lo hizo en el escenario Nº 1.

En este momento, los artefactos de mapeo están listos para ser usados con WebSphere DataPower. Los siguientes pasos muestran las configuraciones requeridas en WebSphere DataPower.

Para crear el Web Service Proxy, siga los mismos pasos que en el escenario N 1. Sin embargo, en lugar de establecer el back-end en un servicio web, fíjelo en la Dirección IP y el Puerto del Firewall XML que creará a continuación, el cual transformará la solicitud/respuesta SOAP de o a datos binarios para que se puedan comunicar con el servicio RESTful de back-end de muestra.

Además, deberá crear un Firewall XML. Los siguientes pasos le muestran los detalles para hacerlo.

  1. Cree el nuevo Firewall XML con un back-end estático (en lugar del bucle invertido que usó para el escenario N 1). Ingrese la Dirección de Servidor y el Puerto del servidor que aloja al servicio RESTful de back-end de muestra.
Figura 56. Creación de un PassThru para el Firewall XML
Creación de un PassThru para el Firewall XML
  1. Abra el Firewall XML recientemente creado y fije el Request Type (Tipo de Solicitud) para front-end en SOAP, y para back-end en Non-XML.
  2. Abra la Processing Policy (Política de Procesamiento) para crear una Request Rule (Regla de Solicitud) y una Response Rule (Regla de Respuesta), como se muestra a continuación.
    1. Para la Request Rule, defina las siguientes acciones.
    2. Para la Response Rule, cree solamente una Acción de transformación binaria que use el Mapa de Respuesta de WebSphere Transformation Extender que usted creó para transformar la respuesta binaria en una respuesta SOAP que será enviada al cliente del servicio web solicitante a través del Web Service Proxy.
Figura 57. Edición de la Política del Firewall XML para la Solicitud
Edición de la Política del Firewall XML para la Solicitud
Listado 11. Ejemplo
<?xml version="1.0" 
                encoding="UTF-8"?>
                <xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:fo="http://www.w3.org/1999/XSL/Format"> 
                <xsl:output
                method="text"/>
                <xsl:template
                match="/"
                >AccountID=<xsl:value-of 
                select="//accountNumber"/>
                </xsl:template>
                </xsl:stylesheet>
Figura 58. Edición de la Política del Firewall XML para la Respuesta
Edición de la Política del Firewall XML para la Respuesta

En este momento, usted tiene un servicio web equivalente que se comporta exactamente igual que el que creara anteriormente con el WebSphere Enterprise Service Bus y WebSphere Message Broker cuando implementó el escenario Nº 2.


Verificación de los proveedores de servicios

Ahora que usted se ha ocupado de las diferentes interfaces de los servicios, algunos de los cuales se basan en SOAP mientras que otros son RESTful, analizaremos algunas herramientas de muestra para asegurarnos de que estos servicios funcionan correctamente. Si bien esta lista no es una lista integral de todas las herramientas, descubrirá que las mismas resultan útiles para verificar tanto las mediaciones que usted ha creado como los servicios de back-end. La siguiente ilustración muestra un resumen de las herramientas que trataremos y cómo usarlas adecuadamente para examinar a los proveedores de servicios en los dos escenarios que usted ha implementado.

Figura 59. Uso de las herramientas para examinar a los proveedores de servicios
Uso de las herramientas para examinar a los proveedores de servicios

Monitor TCP/IP

El Monitor TCP/IP es una herramienta útil que viene con WebSphere Integration Developer, muchos otros productos de Rational Software Delivery y la plataforma Eclipse. El Monitor TCP/IP le permite monitorear el tráfico entre un cliente y un servidor de aplicaciones. Usted puede usar el Monitor TCP/IP para ver el tráfico en ambos sentidos entre los servicios RESTful y los servicios web que usted ha creado según este artículo. Los siguientes pasos muestran un ejemplo de monitoreo de tráfico entre un cliente RESTful y un proveedor de servicios usando WebSphere Integration Developer. Observe que el proveedor de servicios puede ser el servicio RESTful de back-end de muestra, que es el servlet que usted usó en el escenario Nº 2, o puede ser la mediación que usted creó para contener el servicio en el escenario Nº 1.

  1. Haga clic en Window > Show view > TCP/IP Monitor
Figura 60. Cómo exhibir la vista del Monitor TCP/IP
Cómo exhibir la vista del Monitor TCP/IP
  1. Con el botón derecho del mouse, haga clic en la vista TCP/IP Monitor, y luego seleccione Properties (Propiedades).
Figura 61. Visualización de las propiedades del monitor
Visualización de las propiedades del monitor
  1. Agregue un servidor de monitoreo TCP/IP y cambie los puertos para que se correspondan con el entorno en el cual usted está probando el servicio.
Figura 62. Configuración del servidor de monitoreo
Configuración del servidor de monitoreo
  1. Con esta configuración, usted podrá monitorear el tráfico a su servidor. Envíe una solicitud de cualquier cliente de REST que tenga al servicio RESTful. Observe que usted está enviando la solicitud al puerto en el cual está implementado el servicio RESTful, y no al del servidor de monitoreo TCP/IP. Por ejemplo, si usted ha implementado el servicio RESTful de back-end en el Puerto 9090, entonces permita que el cliente envíe las solicitudes a ese puerto en lugar de hacerlo al puerto del monitor que usted creara, que es el 9083 como se muestra en la imagen de pantalla anterior. Si usted no cuenta con un cliente de REST que esté listo, no se preocupe, ya verá una herramienta que puede utilizar con este fin, además de algunos fragmentos de código de muestra para los clientes que usted puede utilizar con el fin de probar sus servicios.
  2. En cuanto usted envíe la solicitud al servicio, podrá ver los contenidos en la vista del Monitor TCP/IP, donde se muestra la solicitud proveniente del cliente y donde está disponible la respuesta del módulo de mediación.
Figura 63. Visualización del contenido de las solicitudes y respuestas
Visualización del contenido de las solicitudes y respuestas

Como se mencionara anteriormente en esta sección, usted también podrá usar el Monitor TCP/IP para monitorear servicios web siguiendo los pasos mencionados anteriormente.


cURL

cURL es una popular herramienta de la línea de comandos de código abierto creada por terceros para la transferencia de archivos y datos a un URL, lo cual la convierte en adecuada para probar a los proveedores RESTful que usted ha creado. A continuación verá un comando de muestra que se puede usar para enviar solicitudes al ejemplo de flujo de mediación que usted ha creado en el WebSphere Enterprise Service Bus.

                curl -H "Content-type: 
                text/plain" -X POST -d
                "AccountNum=123" 
                http://your_server_ip:your_server_port/RestIntegration_Medi
                ationModuleWeb/Export1

Basado en la lógica del servicio RESTful de muestra que se provee, la respuesta devuelta por el servicio deberá ser Score=4000. Quizás desee monitorear la solicitud y la respuesta intercambiadas entre el cURL y su servidor como resultado del uso de este comando con el Monitor TCP/IP, como se describe en la sección anterior.

Además, puede usar cURL para enviar solicitudes SOAP al proveedor de servicios web que usted ha creado.


RESTClient

RESTClient es otra aplicación Java de código abierto creada por terceros que se puede usar para probar las aplicaciones RESTful. Los siguientes pasos le muestran cómo se usa para probar servicios RESTful.

  1. Ejecute RESTClient con el siguiente comando:
$ java –jar [path to RESTClient jar]
Figura 64. Ejecución de la herramienta RESTClient
Ejecución de la herramienta RESTClient
  1. Ingrese el URL del proveedor de servicios RESTful que usted va a probar. Por ejemplo, el URL del flujo de mediación que usted creó en el escenario Nº 1 en el WebSphere Enterprise Service Bus.
Figura 65. Cómo ingresar el URL del servicio RESTful
Cómo ingresar el URL del servicio RESTful
  1. Cambie el método HTTP aPOST.
Figura 66. Cómo establecer el método HTTP en POST
Cómo establecer el método HTTP en POST
  1. Haga clic en la pestaña Body y escriba “AccountNum=123”, que es la carga útil que será enviada al servicio RESTful.
Figura 67. Ingreso de la carga útil
Ingreso de la carga útil
  1. Presione el botón Send ubicado al lado del campo URL y observe la respuesta del servicio RESTful.
Figura 68. Visualización de la respuesta
Visualización de la respuesta

Como se mencionara anteriormente para el cURL, usted puede monitorear el tráfico enviado desde el Cliente de REST al proveedor de servicios RESTful usando el Monitor TCP/IP.


Web Service Explorer

Al igual que el Monitor TCP/IP, Web Service Explorer es una herramienta que se entrega con WebSphere Integration Developer y que forma parte de la plataforma Eclipse. Web Service Explorer permite al desarrollador invocar servicios web si se cuenta con el WSDL del servicio y con su ubicación. Los siguientes pasos le muestran cómo probar a sus proveedores de servicios web con Web Service Explorer desde dentro de WebSphere Integration Developer.

  1. Con el botón derecho del mouse, haga clic en el archivo WSDL del servicio a verificar. Seleccione Web Services > Test With Web Service Explorer.
Figura 69. Ejecución del Web Service Explorer
Ejecución del Web Service Explorer
  1. Si no aparece el punto final del servicio web, agréguelo usando el vínculo Add (Agregar).
Figura 70. Inclusión del punto final del servicio web
Inclusión del punto final del servicio web
  1. Haga clic en la operación que intenta invocar. Por ejemplo, getAccountScore() del servicio web de muestra provisto o de la mediación creada para el escenario Nº 2, como se muestra en la imagen anterior.
  2. Seleccione el punto final y agregue los parámetros del servicio web que se deberán enviar. Por ejemplo, “123”. Luego presione el botónGo (Ir a).
Figura 71. Selección del punto final y paso del parámetro
Selección del punto final y paso del parámetro
  1. Usted deberá ver el resultado que devuelve el proveedor de servicios web.
Figura 72. Respuesta del servicio web
Respuesta del servicio web

Proveedores de servicios que consumen RESTful

Una de las ventajas que usted obtiene al exponer los servicios RESTful es que estos pueden ser consumidos por una variedad de lenguajes de programación de los clientes sin tener problemas de interoperabilidad. Esto se debe a que las interacciones RESTful se basan en el protocolo HTTP, que es bastante estable para los distintos proveedores de diversos productos de software. A continuación figuran los fragmentos de código escritos en JAVA .NET y PHP para invocar a los mismos servicios RESTful que usted ha creado para el escenario Nº 1 y también el servicio RESTful de back-end de muestra que usted usó en el escenario Nº 2.

Consumidor de Java

Un consumidor basado en Java podría ser, por ejemplo, un JavaServer Page (JSP) o un Servlet. El siguiente listado muestra cómo se invoca al servicio RESTful que usted ha expuesto.

Listado 12. Llamado al servicio RESTful desde Java
                //(1) URL url = new
                URL(the_URL_address_of_the_REST_provider); 
                HttpURLConnection con =
                (HttpURLConnection)url.openConnection();
                //(2) con.setRequestMethod("POST"); //(3)
                con.setRequestProperty("Content-Type", "text/plain");
                //4 String
                content=”AccountNum=123” byte[] contentBytes=content.getBytes();
                //5 OutputStream
                out = con.getOutputStream(); 
                out.write(contentBytes);
                out.flush(); out.close(); //6
                BufferedReader br =new BufferedReader
                (new InputStreamReader(con.getInputStream()));
                String result = br.readLine(); 
                con.disconnect();

El Paso (1) abre una conexión con el proveedor RESTful. El Paso (2) establece el método HTTP para POST que determina la operación que será llevada a cabo por el servicio RESTful. Los encabezados de HTTP se determinan en el Paso (3). El Paso (4) prepara la solicitud que será enviada por el flujo al convertir la cadena en un conjunto de bytes, es decir, en binaria. La solicitud se envía en el Paso (5). El Paso (6) lee la respuesta devuelta por el servicio.

Consumidor de .NET

De manera similar, los consumidores de .NET podrían basarse en la Web o ser una aplicación de Windows. Los basados en la Web podrían ser un clásico ASP o un moderno ASP.NET.

Listado 13. Llamado al servicio RESTful desde C#
                //(1) // url is the address of the
REST provider HttpWebRequest myReq 
=(HttpWebRequest)WebRequest.Create((String)
                url
                ); //(2) myReq.Method = "POST";
                String content=”AccountNum=123” byte[] 
				contentdata =
                Encoding.UTF8.GetBytes(content); 
                myReq.ContentLength = contentdata.Length ;
                myReq.ContentType = "text/plain ;
                myReq.Credentials =
                CredentialCache.DefaultCredentials;
                //(3) Stream strm = myReq.GetRequestStream();
                strm.Write(contentdata,0,contentdata.Length); 
                strm.Close(); //4 HttpWebResponse
                myres =( HttpWebResponse)myReq.GetResponse(); 
                Stream recStream =
                myres.GetResponseStream();
                StreamReader strRead = new StreamReader(recStream,
                Encoding.UTF8); string result = 
				strRead.ReadToEnd();
                strRead.Close();
                myres.Close();

El Paso (1) abre una solicitud Web al proveedor RESTful. El Paso (2) determina los encabezados de la solicitud HTTP y prepara la carga útil que será enviada en el Paso (3) por el flujo al servicio. El Paso (4) lee la respuesta del servicio y libera los recursos retenidos.

Consumidor de PHP

Un consumidor que está programado en PHP tendrá la siguiente apariencia.

Listado 14. Llamado al servicio RESTful desde PHP
                //(1) $properties = array(
                'http'=>array( 'method'=>"POST" ,'header'=>
                "Content-Type:
                text/plain; charset= utf-8\r\n" ,"content"=>
                "AccountNum=123" ) ); //(2)
                $context = stream_context_create($properties);
                //(3) // $url is the address of the
                REST provider $result = file_get_contents($url, false, $context);

El Paso (1) establece las propiedades necesarias para crear el flujo entre el cliente y el servidor, lo cual se realiza en el Paso (2). El Paso (3) envía la solicitud al servicio RESTful y recibe el resultado que el servicio devuelve.


Agradecimientos

Los autores desean agradecer a Greg Flurry, quien revise el artículo y proporcionó valiosos comentarios.


Conclusión

La responsabilidad de exponer sus aplicaciones de legado como servicios RESTful puede delegarse al Bus de Servicios Empresariales. Los servicios RESTful en sí mismos también pueden exponerse de manera diferente usando el Bus de Servicios Empresariales. En este artículo, usted ha visto dos escenarios; uno de ellos expone un servicio web de back-end como un servicio RESTful, y el otro expone un servicio RESTful de back-end como un servicio web. Ambos escenarios fueron implementados en WebSphere Enterprise Service Bus, WebSphere Message Broker y WebSphere DataPower. Además, usted aprendió cómo se prueban las interfaces de los servicios web y RESTful. Por último, usted ha disfrutado de la interoperabilidad inherente a la interacción RESTful al implementar consumidores en distintos lenguajes de programación que consumen el mismo servicio RESTful.

Recursos

Aprender

Obtener los productos y tecnologías

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=SOA y servicios web
ArticleID=452107
ArticleTitle=Cómo exponer servicios RESTful usando un Bus de Servicios Empresariales
publish-date=08082011