Escribir Clientes RPC
Clientes RPC
Escribir clientes para acceder a servicios basados en SOAP RPC es bastante sencillo. Apache SOAP proporciona un API del lado del cliente para asistirnos en la construcción de la solicitud SOAP, y luego asistirnos en la la interpretación de al respuesta. Conceptualmente, los servicios basados en RPC son relativamente fáciles de entender, porque lo conceptos implicados son aquellos que pueden encontrarse en cualquier lenguaje basado en procedimiento. Para invocar a un procedimiento, necesitamos su nombre y los parámetros a pasarle. Cuando la invocación se completa, necesitamos extraer cualquier información de respuesta desde el valor de retorno y/o desde los parámetros de salida.
Los pasos básicos para crear un cliente que interactúe con un servicio basado en SOAP RPC son los siguientes:
- Obtener la descripción del interface del servicio SOAP, para que podamos conocer las firmas de los métodos que deseamos invocar.
Podemos buscar un fichero WSDL (o algún otro formato de definición de interface) para el servicio, o directamente en su implementación
- Nos aseguramos de que hay serializadores registrados para todos los parámetros que deseamos enviar, y deserializadores para toda la información que recibiremos de vuelta.
Los parámetros deben ser serializados/deserializados hacia/desde XML antes de poder ser transmitidos/recibido, y por eso Apache SOAP proporciona varios serializadores/deserializadores que están disponibles. Si necesitamos transmitir o recibir un tipo que no ha sido registrado, necesitamos escribir y registrar nuestro propio serializador/deserializador.
- Creamos el objeto org.apache.soap.rpc.RPCMessage.Call.
Este objeto es el interface principal para el código RPC SOAP subyacente.
- Seleccionamos la URI objetivo dentro del objeto Call usando el método setTargetObjectURI(...).
Pasado en la URN que el servicio es usado para identificarse a si mismo en su descriptor de despliegue.
- Seleccionamos el nombre del método que deseamos invocar dentro del objeto Call usando el método setMethodName(...).
Este debe ser uno de los métodos expuestos por el servicio que está identificado por la URN dada en el paso anterior.
- Creamos cualquier objeto Parameter necesario para la llamada RPC y los seleccionamos dentro del objeto Call usando el método setParams(...).
Nos aseguramos de que tenemos el mismo número de parámetros y del mismo tipo que está esperando el servicio. También nos aseguramos de que hay registrados serializadores/deserializadores para los objetos que van a ser transmitidos/recibidos (ver paso 2).
- Ejecutamos el método invoke(...) del objeto Call y capturamos el objeto Response que se devuelto desde invoke(...).
El método invoke(...) acepta dos parámetros, el primero es una URL que identifica el punto final en el que reside el servicio (por ejemplo, http://localhost/soap/servlet/rpcrouter) y el segundo es el valor situado en la cabecera SOAPAction. Recuerda que la llamada a RPC es síncrona, y que por eso puede tardar un poco en completarse.
- Chequeamos el objeto Response para ver si se ha generado algún fallo usando el método generatedFault().
- Si ha ocurrido algún fallo, lo recuperamos usando el método getFault(...), de otro modo extraemos cualquier resultado usando los métodos getReturnValue() y getParams() respectivamente.
Aunque la mayoría de los proveedores sólo devolverán un resultado, si hemos creado nuestro propio proveedor (o hemos obtenido uno de algún lugar), también podría devolver parámetros de salida
Como se supone que SOAP es un estándard, deberíamos poder usar los clientes que creemos con el API Apache SOAP para acceder a servicios que se ejecutan en diferentes implemetnaciones, y viceversa.
Nota Especial: Interactúar con Servicios con Estado
Los servicios podrían ser con estado - es decir, una vez que se ha empezado una interacción con un servicio, una seríe de llamadas a él podrían ser independientes unas de las otras. Apache SOAP soporta servicios de autoría con estado (mediante
desplegar con un ciclo de vida de sesión) Así como llamando a servicios con estado. Actualmente el soporte de sesión sólo está disponible para HTTP.
El mantenimiento de sesión HTTP está activo por defecto. Lo que significa que si un servicio con el que estamos hablando mediante HTTP selecciona las cookies HTTP apropiadas para mentener la sesión, estás serán copiadas y almacenadas en el objeto Call, luego la cookie será enviada de vuelta al servidor, así mentenemos la sesión. Así, todo lo que tenemos que hacer es asegurar que sólo se usa un ejemplar del objeto Call a través de las llamadas que deseamos hacer sobre la misma sesión HTTP.
El ejemplo "addressbook2" muestra un ejemplo de esto en acción.
Nota Especial: Usar RPC sobre SMTP
Para hacer RPC sobre SMTP en Apache-SOAP se necesita tener disponible una cierta infraestructura de e-amil. Necesitamos un servidor SMTP, un servidor POP3 y una dirección de e-mail que podamos usar para ser el equivalente del router HTTP del lado del servidor. Es decir, todas las llamadas SOAP RPC son enviadas a una dirección específia que procesa las solicitudes de alguna forma y envía el resultado al emisor. Para evitar duplicidad de la infraestructura en el lado del servidor, hemos implementado el SMTP de lado del servidor como un puente que recibe los correos enviados a la dirección e-amil del router SOAP mediante POP3, postea el sobre SOAP a una infraestructura HTTP SOAP existente y envía la respuesta de vuelta al emiso de la petición mediante SMTP.
En el lado del cliente, la aplicación envía la solicitud SOAP mediante SMTP a la dirección e-mail del router SOAP indicando la dirección a la que se debería enviar la respuesta. Luego, arranca un servidor POP3 para ver si la respuesta ha llegado. Cuando lo hace, el sobre es analizado y la respuesta es extraída. Estamos usando un
Bean POP3 de alphaWorks para el esqueleto POP3 y este bean no soporta descarga selectiva de e-mail. como resultado de la implementación actual que trata sobre el "next message" que llega a la dirección de respuesta del cliente para ser un mensaje que contiene la respuesta a la solicitud. La implicación es que la implementación actual no permite que hagamos múltiples llamadas RPC usando la misma dirección de retorno al mismo tiempo.
NOTA:
Recomendamos fuertemente que NO utulices tu propia dirección de e-mail para probar RPC sobre SMTP. Hay muchos proveedores gratuitos de correo POP3 en la Web (como www.mailandnews.com, por ejemplo) si no puedes configurar varias cuentas POP3 por tí mismo.
|
Tutoriales
