Invoque servicios más fácilmente a través de un Gateway de Servicios

Un gateway de servicios proporciona más flexibilidad y facilita la invocación de servicios desde otras aplicaciones por parte de los solicitantes de servicios. El gateway de servicios proporciona un punto único de acceso y simplifica posibilidades como enrutamiento, supervisión, registro cronológico, mantenimiento de versiones y seguridad para todo el sistema. Con el WebSphere ®Integration Developer V6.2, puede implementar rápidamente el patrón de integración del Gateway de Servicios. Este artículo describe las funciones y beneficios de un gateway de servicios y luego muestra cómo crear uno.

Richard Gregory, Software Developer , IBM  

Richard Gregory es Desarrollador de Software en el Laboratorio de IBM Toronto. Actualmente está trabajando en el Equipo de Desarrollo del WebSphere Studio Application Developer Integration Edition. Richard Gregory ingresó a IBM en tiempo parcial en 1997 y trabajó en el Centre for Advanced Studies en varios proyectos de reingeniería de software y sistemas distribuidos. Comenzó a trabajar a tiempo integral en 2000 y contribuyó a dos versiones de VisualAge para Java Enterprise Access Builder. Recibió su diplomatura en Ciencias de la Computación en la Universidad de Toronto en 1999 y su Maestría en Ciencias en Ingeniería Eléctrica y Computacional en la Universidad de Waterloo en 2001.



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.



Janette Wong, Senior Technical Staff Member, IBM  

Janette WongJanette Wong es asociada del Personal Técnico Senior de IBM. Lidera el trabajo con patrones en el área de BPM. Actualmente enfoca los patrones de procesos y colabora con otros expertos en el asunto en áreas de patrones como conectividad e integración.



Grace Wong, Software Engineer, IBM  

Grace Wong es desarrolladora en el Laboratorio de IBM Toronto y trabaja en el editor de flujo de mediación de WebSphere Integration Developer.



David Van, Staff Software Engineer, IBM

David Van fue el arquitecto de SVT para el WebSphere Integration Developer y fue responsable de liderar varios escenarios de verificación de sistemas. Actualmente trabaja con el equipo de utilización de IBM WebSphere Integration Developer e IBM WebSphere Message Broker Toolkit. Puede contactar a David en davidvan@ca.ibm.com.



28-07-2011

Introducción

Al usar el WebSphere Integration Developer V6.2, puede comenzar rápidamente a compilar aplicaciones al usar plantillas que representan soluciones de patrones. Uno de los patrones que está disponible en el WebSphere Integration Developer V6.2 es el gateway de servicios, mostrado en la Figura 1.

Figura 1: Un gateway de servicios en un bus de servicios empresariales
Figura 1: Un gateway de servicios en un bus de servicios empresariales

Lo que sigue corresponde a los números en la Figura 1 y describe las funciones y beneficios de un gateway de servicios.

  1. Ofrece a los solicitantes de servicios un punto único de acceso simplificado

    Se obtiene el acceso simplificado al proporcionar un flujo de mediación con una interfaz genérica de gateway de servicios para mediar mensajes provenientes de diferentes solicitantes de servicios. Todas las operaciones unidireccionales que pasan por el gateway son mediados por el flujo requestOnly de la interfaz del gateway de servicios; todas las operaciones de solicitud-respuesta que pasan por el gateway son mediadas por el flujo requestResponse, como muestra la Figura 1.

    Para atender a diferentes solicitantes, el gateway de servicios soporta los siguientes protocolos: servicio web, HTTP, JMS y MQ. Cuando una solicitud de servicio entra en el gateway de servicios, es convertida en un objeto empresarial específico para el protocolo por el enlace de datos o manejador de datos específico para el protocolo del gateway. Por ejemplo: una solicitud de SOAP es encapsulada en un objeto empresarial TextBody, que luego es colocado en el cuerpo del Objeto de Mensaje de Servicio (SMO). El selector de funciones del gateway, que es específico para el protocolo, determina si la solicitud será mediada por el flujo requestOnly o requestResponse. Para obtener más informaciones acerca de la conversión de datos y del selector de funciones, consulte el documento Service Gateway Support en la sección Recursos de este artículo.

  2. Realizar proceso común en todos los mensajes de solicitud y respuesta

    El gateway de servicios soporta registro cronológico de mensajes, al grabar los mensajes en una base de datos, emitir los mensajes a un servidor de eventos como eventos o procesarlos a través de un código Java personalizado. Además, puede añadir posibilidades para realizar acciones como verificaciones de seguridad y validación.

  3. Enrutar solicitudes a los proveedores de servicios

    El flujo de mediación procesa las solicitudes que el gateway de servicios recibe. Después que se realiza el proceso común de la solicitud, se la enruta a un proveedor de servicios. El enlace de datos o manejador de datos específico para el protocolo convierte la solicitud del formato de objeto empresarial específico para el protocolo al formato original del mensaje. En el ejemplo mencionado anteriormente, se convierte la solicitud de TextBody a SOAP. La dirección de punto final del proveedor de servicios puede ser seleccionada dinámicamente en el tiempo de ejecución o definida en el momento del desarrollo. En el caso de una solicitud SOAP, la información de enrutamiento puede estar en la cabecera de SOAP, que normalmente contiene información suficiente para que el gateway de servicios determine el proveedor de servicios adecuado, o bien puede estar en el atributo SOAPAction, en el URL o en la sección WS-Addressing de la solicitud.

Si se determina el punto final del proveedor de servicios en el tiempo de ejecución, se designa el gateway de servicios como gateway de serviciosdinámico (mostrado en la Figura 2), lo que significa que se soportan diferentes formas de consultar el punto final del proveedor de servicios en el tiempo de ejecución, como recuperar la dirección del punto final en el WebSphere Service Registry and Repository o en una base de datos. Un gateway de servicios A dinámico normalmente enruta las solicitudes al proveedor de servicios seleccionado tal como están.

Figura 2: Un gateway de servicios dinámico
Figura 2: Un gateway de servicios dinámico

Si se determina el punto final del proveedor de servicios en el momento del desarrollo, se designa el gateway de servicios como gateway de serviciosestático (mostrado en la Figura 3). Cada nodo de llamada representa un proveedor de servicios cuya dirección de punto final se define en la importación correspondiente en el diagrama de conjunto. El gateway transforma la solicitud del formato específico para el protocolo al formato definido por la interfaz del proveedor de servicios. Opcionalmente, el gateway de servicios puede enriquecer la solicitud transformada antes de enrutarla al proveedor de servicios.

Figura 3: Un gateway de servicios estático
Figura 3: Un gateway de servicios estático

Para decidir si necesita un gateway de servicios dinámico o estático, determine si desea enriquecer o transformar su mensaje de solicitud antes de enrutarlo al proveedor de servicios y si es posible que sea necesario añadir más proveedores de servicios después del despliegue del gateway. Para enriquecer su mensaje de solicitud, debe usar un gateway de servicios estático. Para añadir proveedores de servicios después del despliegue del gateway, use un gateway de servicios dinámico, pues puede añadir proveedores de servicios sin actualizar y volver a desplegar el gateway. Si usa un gateway de servicios estático y desea añadir proveedores de servicios, tiene que actualizarlo con las interfaces de los proveedores de servicios adicionales y volver a desplegarlo. Note que el proceso común, como registro cronológico, está disponible independientemente del tipo de gateway que elige.


Resumen

La lista a continuación muestra los beneficios de un gateway de servicios:

  • Proporciona un punto de acceso único a varios proveedores de servicios al poner a disposición una interfaz única de gateway de servicios genérico (ServiceGateway.wsdl).
  • Centraliza el proceso común — como registro cronológico y validación de todos los mensajes de solicitud y respuesta — lo que elimina la necesidad de repetir el desarrollo de ese proceso entre cada peticionario y proveedor.
  • Proporciona flexibilidad en el enrutamiento de solicitudes a varios proveedores de servicios.

La tabla a continuación resume y compara las funciones y características clave de los gateways de servicio dinámicos y estáticos

Tabla 1: Comparación entre el gateway de servicios estático y dinámico
Detalles Gateway de servicios dinámico Gateway de servicios estático
Proceso común
Número de nodos de llamada 1 (interfaz de gateway genérico) 1 interfaz específica de proveedores de servicios
Necesario para transformar el cuerpo del mensaje No
Qué el gateway hace Un primitivo de mediación — por ejemplo: un primitivo de Búsqueda en el Punto Final o Búsqueda en la Base de datos — usa la información en la cabecera para buscar la dirección del punto final a la cual debe enrutar el mensaje en el tiempo de ejecución y la pone en /headers/SMOHeader/Target/dirección del SMO. Un primitivo de Filtro de Mensaje usa la información en la cabecera para determinar a qué vía de acceso debe enrutar el mensaje de solicitud. Un primitivo de manejador de datos transforma el mensaje de la forma encapsulada — por ejemplo: TextBody — a un formato de objeto empresarial que es definido por la interfaz del proveedor de servicios. Opcionalmente, se puede usar un primitivo de XSLT para enriquecer el mensaje antes del envío al proveedor de servicios.

Ahora que tiene la visión general de un gateway de servicios, vamos a pasar a la configuración del gateway para que proporcione las funciones que se describieron.


Configurando un gateway de servicios

Para crear en su espacio de trabajo un módulo de gateway de servicios que pueda ejecutar en el WebSphere Enterprise Service Bus o el WebSphere Process Server, haga clic en New > Service Gateway (mostrado en la Figura 4) o New > From Patterns (mostrado en la Figura 5).

Figura 4: Seleccionando Service Gateway en el menú
Figura 4: Seleccionando Service Gateway en el menú
Figura 5: Seleccionando el patrón de gateway de servicio
Figura 5: Seleccionando el patrón de gateway de servicio

Después de hacer clic en Next, usted proporciona un nombre para el módulo de gateway de servicios que se creará en su espacio de trabajo. En la página siguiente, elige crear un gateway de servicios estático o dinámico.

Figura 6: Seleccionando un gateway dinámico o estático
Figura 6: Seleccionando un gateway dinámico o estático

Las dos secciones siguientes describen opciones de configuración de un gateway de servicios estático y dinámico, respectivamente. El tipo de gateway que selecciona, estático o dinámico, determina las informaciones que debe facilitar en el asistente New Service Gateway.


Gateway de servicios estático

La Figura 7 muestra la segunda página del asistente, que se ve al seleccionar static como el tipo de gateway de servicio.

Figura 7: Creando un gateway estático
Figura 7: Creando un gateway estático

Para añadir interfaces de proveedor de servicios, haga clic en Add. Puede seleccionar cualquier interfaz de proveedor de servicios que esté en las bibliotecas. El asistente New Service Gateway añade automáticamente una dependencia del módulo de gateway de servicios a la biblioteca de cada interfaz que añadió.

En el mismo asistente, también puede registrar los mensajes o emitirlos como eventos al seleccionar Log messages in a database, Log messages using custom Java, o Emit messages as common base events to a CEI server (mostrado en la Figura 7).

Seleccionando el protocolo de gateway de servicios para un gateway de servicios estático

La Figura 8 muestra cada uno de los protocolos de transporte de gateway que puede seleccionar. Al crear un gateway estático, también necesita un formato de datos de la solicitud que es específico para el protocolo, como XML para el protocolo Web Services. Dada esa información de formato de datos específica para el protocolo, el enlace o manejador de datos del gateway de servicios puede recortar el cuerpo de la solicitud como un objeto empresarial, como TextBody. Para conocer más detalles acerca del formato de datos específico para el protocolo, consulte el documento Service Gateway Support en la sección Recursos de este artículo.

Figura 8: Seleccionando el protocolo de transporte del gateway
Figura 8: Seleccionando el protocolo de transporte del gateway

Al hacer clic en Finish, se genera el módulo del gateway de servicio estático.


Gateway de servicios dinámico

Para evitar la gateway de servicios tenga que estar asociado a un conjunto fijo de interfaces de servicio, puede construirlo en forma independiente de los servicios a los cuales se puede acceder a través de él ahora o en el futuro. Cuando el gateway está ejecutando en un servidor, puede buscar qué servicio se debe llamar de acuerdo con la solicitud de servicio. Por ejemplo: puede publicar un URL de dirección de servicio web externo como

http://mycompany.com:9080/GatewayWeb/sca/GatewayModule?targetService=InsQuote

donde el nombre del servicio es un parámetro, pero la dirección real es

http://internal.mycompany.com:9080/InsuranceQuoteService/InsuranceQuoteHttpService

Cuando una solicitud de servicio llega al gateway, se puede realizar la búsqueda de InsQuote a través de una base de datos o del WebSphere Service Registry and Repository para determinar cuál es la dirección real. Si la dirección real cambia, sólo es necesario actualizar la base de datos o el repositorio. Verá un ejemplo de la necesidad de actualizar sólo la base de datos en la sección de ejercicio de ese artículo, donde el gateway usa la dirección real para enrutar la llamada de servicio.

Figura 9: Seleccionando la lógica de gateway dinámico
Figura 9: Seleccionando la lógica de gateway dinámico

La Figura 9 muestra la segunda página del asistente New Service Gateway cuando se seleccionó un gateway dinámico en la primera página. Al comparar esta segunda página con la segunda página de la Figura 7, note que no asocia interfaces de servicio específicas al gateway de servicios.

Vamos a examinar rápidamente lo que se creará en cada opción de selección de proveedor de servicios en el tiempo de ejecución.

La selecciónQuery a WebSphere Service Registry and Repository (WSRR) crea un primitivo de Consulta de Punto Final que se debe configurar para que se conecte a WebSphere Service Registry and Repository para buscar la dirección del punto final. Se almacena la dirección de punto final recuperada en el valor de SMO /headers/SMOHeader/Target/address.

La selección de Retrieve from database crea un primitivo de Búsqueda en la Base de Datos que debe ser configurado para que se conecte a una base de datos para buscar la dirección del punto final. Se almacenará la dirección de punto final recuperada en /headers/SMOHeader/Target/address.

Si desea su propia forma de seleccionar un servicio, seleccione Write my own logic. Eso crea un primitivo de mediación personalizado en el cual puede escribir código Java o usar Java visual para configurar la dirección del punto final para que el enrutamiento ocurra dinámicamente.

Por fin, la selección Use an element from the request message crea un primitivo Message Element Setter en el flujo de mediación. En el ejemplo mostrado en la Figura 10, el primitivo Message Element Setter llamado RouteMessage copia todo después de ?targetService=en el URL de dirección de servicio a la dirección del punto final en la cabecera de SMO.

Por ejemplo: un cliente puede enviar una solicitud al gateway a través del URL http://localhost:9080/DynamicGatewayModuleWeb/sca/DynamicGatewayModuleExport?targetService=http://localhost:9080/InsuranceQuoteService/InsuranceQuoteHttpService. El nodo RouteMessage copiaría http://localhost:9080/InsuranceQuoteService/InsuranceQuoteHttpService a la dirección de destino del SMO.

En ese caso, el nodo de llamada en la mediación usa la dirección de destino para invocar el servicio.

Figura 10: Usando un primitivo de Message Element Setter para configurar la dirección de punto final en un gateway de servicios dinámico
Figura 10: Usando un primitivo de Message Element Setter para configurar la dirección de punto final en un gateway de servicios dinámico

Seleccionando el protocolo de gateway de servicios para un gateway de servicios dinámico

El próximo paso es seleccionar el protocolo del gateway de servicios. La página del asistente (Figura 11) es muy semejante a la Figura 8 pero sin la opción de formato de datos específico para el protocolo. No se espera que un gateway de servicios dinámico acceda al cuerpo del mensaje o lo modifique, pues el enrutamiento se basa sólo en la cabecera de la solicitud; por tanto, no es necesario seleccionar el formato de datos específico para el protocolo.

Figura 11: Seleccionando el protocolo de transporte de gateway para un gateway dinámico
Figura 11: Seleccionando el protocolo de transporte de gateway para un gateway dinámico

Cuando concluya el asistente, se genera el módulo de gateway de servicios para usted.


Uniendo todo con un ejemplo

Ahora que ha visto los fundamentos del uso del patrón de gateway de servicios, he aquí un escenario — puede intentar crear su propio gateway de servicios y verlo en acción. Imagine que tiene cinco servicios web y ahora quiere registrar cada solicitud a los servicios web a través de un gateway de servicios. En la sección Descargas de este artículo hay un enlace a un archivo de intercambio de proyectos que contiene cinco servicios web. Hay también un enlace a un proceso empresarial que está conectado a importaciones de servicios web. Cada importación tiene su punto final configurado para el módulo de gateway de servicios a ser construido en breve.

En el comienzo de la sección Gateway de Servicios Dinámico, explicamos cómo se añade el nombre de servicio como un parámetro al URL del gateway. Como alternativa, puede pasar el nombre del servicio al gateway a través de una cabecera de SOAP, que es lo que mostraremos en este ejemplo. El gateway usará el nombre de servicio para determinar qué servicio real se debe llamar. Comenzará por desplegar la aplicación ClipsAndTacks, que contiene el proceso Order Handling, y los módulos de servicios web para un servidor. Luego compilará el gateway que expone los módulos al mundo (pero sólo en la forma que queremos que el mundo los vea).

He aquí una visión general de la arquitectura del caso de ejemplo y cómo funciona.

  1. El cliente de prueba emite una solicitud para hacer un pedido con el proceso Order Handling.
  2. El proceso Order Handling tiene una lógica empresarial que usa los servicios web ilustrados en el lado derecho del diagrama.
  3. Surge un nuevo requisito de registrar cada solicitud a los servicios web. El gateway interactúa con el proceso Order Handling para enrutar dinámicamente y correlacionar las solicitudes a los servicios web.
Figura 12: Visión general del proceso Order Handling
Figura 12: Visión general del proceso Order Handling

En este caso de ejemplo, construiremos la parte del diagrama que corresponde a los servicios de Order Handling (es decir, el gateway de servicios). Las otras partes del ejemplo se proporcionan en el archivo de intercambio de proyectos que usted importará al WebSphere Integration Developer V6.2

  1. Vaya a la sección Descargas de este artículo y salve el archivo OrderHandlingService.zip en una ubicación conveniente.
  2. Importe el archivo de intercambio de proyectos OrderHandlingService.zip a un nuevo espacio de trabajo del WebSphere Integration Developer.
  3. Cambie a la vista Servers, inicie el WebSphere Process Server y luego despliegue al servidor los módulos que ahora están en su espacio de trabajo.

Después de importar el archivo de intercambio de proyectos, verá los módulos en su espacio de trabajo como muestra la Figura 13. Note que también hay una biblioteca Resources; contiene sólo los archivos que se usarán para la búsqueda del enrutamiento y las pruebas.

Figura 13: El espacio de trabajo después de la importación del archivo de intercambio de proyectos OrderHandlingService
Figura 13: El espacio de trabajo después de la importación del archivo de intercambio de proyectos OrderHandlingService

El módulo ClipsAndTacksF1 contiene la lógica empresarial Order Handling. Como se puede reconocer, los módulos restantes representan los servicios web mencionados anteriormente.

Está creando un gateway de servicios dinámico — por tanto, no necesita especificar las cinco interfaces de los servicios en el momento del desarrollo.

  1. En la perspectiva Business Integration, seleccione File > New > Service Gateway. El asistente New Service Gateway se abre.
  2. En el campo Service gateway name, escriba OrderHandlingServices.
Figura 14: Creando un nuevo gateway de servicios
Figura 14: Creando un nuevo gateway de servicios
  1. Haga clic en Next.
Figura 15: Seleccionando un gateway dinámico
Figura 15: Seleccionando un gateway dinámico

Como ya se mencionó, el hecho de que el gateway es dinámico significa que necesita alguna forma de buscar la dirección del servicio en el tiempo de ejecución. Para ver cómo funciona, escribirá su propia lógica personalizada en el gateway que simulará una búsqueda en base de datos o repositorio.

  1. En la página Select the type of gateway, deje Dynamic seleccionado y luego haga clic en Next.
  2. Seleccione Write my own logic. Eso creará un primitivo de mediación personalizado llamado RouteMessage en el flujo de mediación. En breve escribirá su propia lógica dentro de ese nodo.
  3. Seleccione Log messages using Custom Java. Cuando ejecute la aplicación, se creará un archivo de registro llamado MessageLog.log en el directorio definido por la variable de entorno TEMP. Puede determinar ese directorio en el Microsoft Windows al escribir set temp en el indicador de comandos).
Figura 16: Seleccionando proveedores de servicios
Figura 16: Seleccionando proveedores de servicios
  1. Haga clic en Next. Seleccione Web Service (SOAP 1.2/HTTP).
Figura 17: Seleccionando el protocolo de transporte
Figura 17: Seleccionando el protocolo de transporte
  1. Haga clic en Finish.

Se crea un módulo de mediación llamado OrderHandlingServices, como muestra la Figura 18. Los pasos siguientes concluirán la lógica del gateway de servicios.

Figura 18: El módulo de gateway de servicios en el espacio de trabajo
Figura 18: El módulo de gateway de servicios en el espacio de trabajo
  1. En el diagrama de conjunto, haga doble pulsación en OrderHandlingServices para abrirlo en el editor Mediation Flow.
  2. Haga clic en la operación de origen requestResponse pues, en este ejemplo, todos los mensajes son de solicitud-respuesta.
Figura 19: El flujo de mediación OrderHandlingServices
Figura 19: El flujo de mediación OrderHandlingServices

La Figura 19 muestra el módulo de mediación del gateway de servicios que creó al concluir el asistente. El nodo LogMessage está allá porque usted eligió registrar los mensajes a través de Java personalizado (consulte la Figura 16). Tenga en cuenta la nota TODO en la Figura 19, que indica que usted necesita proporcionar código Java o visual en el primitivo de mediación personalizado para configurar el punto final de destino en el XPath /headers/SMOHeader/Target/address. Realice los pasos a continuación para concluir esa tarea:

  1. Haga doble pulsación en el nodo de mediación personalizada RouteMessage para abrir la vista Properties referente a él.
  2. Haga clic en la ficha Java Imports y copie las siguientes líneas:
import commonj.sdo.DataObject;
import com.ibm.websphere.sibx.smobo.TargetAddressType;
import com.ibm.websphere.sibx.smobo.ServiceMessageObjectFactory;
import com.ibm.websphere.sibx.smobo.SOAPHeaderType;
import java.io.File;
import java.util.Scanner;
import java.io.FileNotFoundException

Se añaden las importaciones para que los nombres de tipo en el código Java RouteMessage no necesiten calificadores.

Figura 20: Añadiendo las importaciones Java
Figura 20: Añadiendo las importaciones Java
  1. Haga clic en la ficha Details y, en el lugar de la línea abajo del comentario generado, out.fire(smo), pegue el siguiente código Java:
	//
	// Get the requested service name from the SOAP header in the
	// message sent to this service gateway.
	//
	SOAPHeaderType soapHeaderType = 
		(SOAPHeaderType)smo.getHeaders().getSOAPHeader().get(0);
	DataObject soapHeaderValue = (DataObject)soapHeaderType.getValue();
	String reqServiceName = soapHeaderValue.getString("targetService");
	System.out.println("->Gateway service request for: " + reqServiceName);
	//
	// Read the text file to determine the mapping between 
	// endpoints and service names.
	//
	// NOTE: Modify the file name depending on the 
	// actual file location.
	//
	File dbFile = new File("D:\\ServicesDB.txt");
	Scanner fileScanner;
	try {
	 fileScanner = new Scanner(dbFile);
	} catch (FileNotFoundException e) {
	 e.printStackTrace();
	 return;
	}
	try {
	 while (fileScanner.hasNextLine()) {
	  // 
	  // Read each line in the file to get the mapping between
	  // the requested service name and the actual endpoint.
	  // The lines are in the format <service name>=<service URL>
	  //
	  String nameUrlLine = fileScanner.nextLine();
	  Scanner nameUrlScanner = new Scanner(nameUrlLine);
	  nameUrlScanner.useDelimiter("=");
	  if (nameUrlScanner.hasNext()) {
	   String serviceName = nameUrlScanner.next();
	   String serviceURL = nameUrlScanner.next();
	   if (serviceName.equals(reqServiceName)) {
	    //
	    // We found the matching requested service name in
	    // the text file. Set the actual endpoint address.
	    //
	    System.out.println("Routing " + reqServiceName + " to "
	      + serviceURL);
	    TargetAddressType targetAddress = 
	      ServiceMessageObjectFactory.eINSTANCE
	      .createTargetAddressType();
	    targetAddress.setAddress(serviceURL);
	    smo.getHeaders().getSMOHeader().setTarget(targetAddress);
	   }
	  }
	  nameUrlScanner.close();
	 }
	} finally {
	 fileScanner.close();
	}
	//
	// Propagate the service message object to the 
	// primitive that is wired to the 'out' terminal.
	//
	out.fire(smo);
  1. Salve todos los editores en el espacio de trabajo

Para que ese código enrute solicitudes de servicio, necesita una base de datos (en nuestro caso, es un archivo de texto) que determina el servicio correcto a llamar para cada solicitud entrante. Ese ejemplo de código espera que los contenidos del archivo estén en D:\ServicesDB.txt, pero usted puede cambiar eso si desea ponerlo en otra parte (por ejemplo: si está ejecutando en Linux) y modificar el paso 2 a continuación como corresponde.

  1. En el sistema de archivos, vaya al proyecto Resources que se importó con el archivo de intercambio de proyectos y ubique el archivo ServicesDB.txt.
  2. Copie ServicesDB.txt a la raíz de su unidad D: o la ubicación que especificó en su código.

Nota: El puerto 9080 se usa en todos los enlaces de importación y exportación de servicios web y en los URLs en ServicesDB.txt. Su servidor puede no usar 9080 como número de puerto de HTTP. Para verificar el puerto de HTTP que su servidor usa, vaya al archivo WID62_ROOT\pf\wps\logs\AboutThisProfile.txt. Si el puerto de HTTP no es 9080, realice los siguientes pasos para redirigir las solicitudes de servicios web de 9080 a su puerto de HTTP.

En la vista Servers, haga clic con el botón derecho en el servidor y seleccione Monitoring > Properties.

Haga clic en Add.

Seleccione la línea en la tabla con el número de puerto de HTTP de servidor que usted determinó en el archivo WID62_ROOT\pf\wps\logs\AboutThisProfile.txt.

En Monitor port, cambie el valor a 9080 y luego haga clic en OK. Eso redirigirá al puerto de HTTP que su servidor usa las solicitudes que van al puerto 9080.

Seleccione el supervisor en la tabla y haga clic en Start.

Recuerde que se pasará el nombre del servicio al gateway a través de una cabecera de SOAP. Los pasos siguientes proporcionan una definición para la cabecera para que el módulo de mediación del gateway de servicios la entienda.

  1. En la biblioteca Resources, en la carpeta Data Types, ubique el objeto empresarial TargetServiceHeaderType.
  2. Copie TargetServiceHeaderType al módulo OrderHandlingServices. Se listará TargetServiceHeaderType en Data Types en ese módulo.
  3. Despliegue el módulo OrderHandlingServices al servidor.

Ha construido el gateway de servicios. A medida que añade o elimina servicios, o cambia el punto final de los servicios, sólo cambia la base de datos o el repositorio o bien, como en ese ejemplo, el archivo ServicesDB.txt. No será necesario cambiar el módulo OrderHandlingServices.

Ahora está listo para probar su aplicación.

  1. En la vista Business Integration, haga clic con el botón derecho en ClipsAndTacksF1 y seleccione Test > Test Module. El cliente de prueba de integración se abre.
  2. Seleccione la ficha Configurations, haga clic con el botón derecho en Human Task Emulators y luego seleccione Add > Human Task Emulator. Hay una tarea humana que implementa la actividad Ship Order to Customer en el proceso empresarial. Por tanto, puede usar el emulador de tareas humanas para reivindicar y realizar la tarea a través del cliente de prueba de integración.
  3. Haga clic en Next, Select All y luego en Finish para crear el emulador de tareas humanas.
  4. En el cliente de prueba de integración, seleccione la ficha Events. Para el componente, seleccione OrderHanding y en la columna Value, fila CustomerNumber, escriba 123.
  5. Para comenzar a ejecutar la prueba, presione Ctrl-R. Si la ventana User Login se abre, ingrese su ID de usuario del servidor y contraseña y luego haga clic en OK.
  6. Espere que se muestre el evento Claim (OrderHandling.ShipOrdertoCustomer_InputCriterion). Recuerde que ha configurado el emulador de tareas humanas; por tanto, cuando se muestra ese evento para la actividad Ship Order to Customer, es conveniente simular los datos que la tarea humana retornó. Para hacer eso, en Input parameters, haga clic con el botón derecho en Order y seleccione Copy Value. Desplace hacia abajo, si es necesario, hasta Output parameters, haga clic con el botón derecho en Order y seleccione Paste Value.
  7. Para continuar ejecutando la prueba, presione Ctrl-R y luego espere la conclusión de la aplicación.

La Figura 21 muestra la ejecución de la aplicación concluida. Esa prueba está configurada para tomar un camino específico en el proceso empresarial, pero este ejercicio enfoca las llamadas salientes del proceso empresarial al gateway de servicios. Las llamadas salientes del proceso Order Handling se dirigen a las importaciones de servicios web que mencionamos en el inicio del ejercicio. Si cambia a la vista Server Logs, verá entradas de registro provenientes del gateway donde enrutó cada llamada a un servicio específico.

Figura 21: Probando el gateway de servicios
Figura 21: Probando el gateway de servicios

Usted optó por registrar mensajes que pasan por el gateway de servicios. Por tanto, una verificación rápida del archivo <ubicación de TEMP>/MessageLog.log mostrará entradas, como en la Figura 22.

Figura 22: Contenido del archivo de registro del gateway de servicio
Figura 22: Contenido del archivo de registro del gateway de servicio

Probando sólo el módulo del gateway de servicios

Terminó de probar la aplicación que llamó sus servicios a través del gateway de servicios. Esta sección final mostrará cómo puede realizar la prueba unitaria del gateway por sí mismo. En ese caso, usted enviará un mensaje directamente al gateway de servicios, lo que hará que el gateway de servicios enrute el mensaje a uno de los servicios web.

  1. En la vista Business Integration, haga clic con el botón derecho en el módulo OrderHandlingServices y seleccione Test > Test Module.
  2. Para el componente, seleccione OrderHandlingServicesExport; para la operación, seleccione requestResponse, como muestra la Figura 23.
Figura 23: Realizando la prueba unitaria del gateway de servicios
Figura 23: Realizando la prueba unitaria del gateway de servicios
  1. Seleccione la ficha Message y luego, XML Editor.
  2. Haga clic en Import Message, vaya al proyecto Resources en el espacio de trabajo, seleccione Input_CheckOrderHandlingPolicyForAutomaticApproval.xmly luego haga clic en Open. Se muestra el contenido del editor XML, como muestra la Figura 24.
Figura 24: Importando el mensaje de SOAP para probar el gateway de servicios
Figura 24: Importando el mensaje de SOAP para probar el gateway de servicios
  1. Para ejecutar la prueba, presione Ctrl-R. El gateway enrutará la solicitud única y creará una entrada en el registro del servidor, como muestra la Figura 25.
Figura 25: Prueba unitaria del gateway de servicios concluida
Figura 25: Prueba unitaria del gateway de servicios concluida

Resumen

En este tutorial, realizó lo siguiente:

  • Importó cinco servicios web y un proceso Order Handling a su espacio de trabajo y los desplegó a un entorno de prueba unitaria del WebSphere Process Server.
  • A través del asistente Service Gateway Pattern, creó un gateway de servicios dinámico (llamado OrderHandlingServices), que enruta solicitudes del proceso Order Handling a todos los servicios web. Ya que el gateway OrderHandlingServices es dinámico, no fue necesario especificar las interfaces de los servicios web cuando creó el gateway. Además, el gateway realiza las siguientes acciones:
    • Selecciona el servicio web a invocar a través de una lógica personalizada. La lógica personalizada usa el nombre del servicio solicitado en la cabecera de SOAP para buscar la dirección de punto final real en un archivo. Luego se configura el campo /headers/SMOHeader/Target/address con la dirección de punto final real.
    • Registra todas las solicitudes a los servicios web.
  • Probó el gateway de servicios al probar el componente de proceso Order Handling y también lo probó directamente a través del mensaje de SOAP CheckOrderHandlingPolicyForAutomaticApproval.

Conclusión

En este artículo, aprendió las funciones y beneficios de un gateway de servicios y creó y probó un gateway de servicios dinámico para invocar un conjunto de servicios web desde un proceso empresarial. El gateway actúa como un punto único de entrada a los servicios para el proceso empresarial, como también para cualquier otro cliente que necesita acceder al mismo conjunto de servicios. El gateway también proporciona proceso común para los mensajes de solicitud y respuesta y enruta cada solicitud al proveedor de servicios adecuado. Recuerde que lo que crea con el asistente de gateway de servicios es sólo un punto de partida — determina lo que existirá inicialmente en el módulo de mediación que usted crea a través del asistente New Service Gateway. Tras concluir el asistente, puede personalizar el flujo de mediación (específicamente, las funciones del gateway de servicios) para que haga prácticamente cualquier cosa.


Descargar

DescripciónNombretamaño
Código de ejemploOrderHandlingService.zip312 KB

Recursos

Comentarios

developerWorks: Ingrese

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


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


¿Olvidó su Password?
Cambie su Password

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

 


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

Toda la información enviada es segura.

Elija su nombre para mostrar



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

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

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

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

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

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=963365
ArticleTitle= Invoque servicios más fácilmente a través de un Gateway de Servicios
publish-date=07282011