Cada tanto, nos llaman algunos clientes con una variedad de esquemas de interoperabilidad, es decir: poner a hablar unas aplicaciones con otras, a veces se integran a través de envíos de archivos de texto a un servidor FTP, que luego termina, a través de tareas programadas, siendo integrado a la aplicación. A veces tienen complicadísimos esquemas en donde usan una variedad de técnicas que no funcionan muy bien juntas, como CORBA o sockets abiertos con esquemas personalizados de codificación. En mi experiencia, las soluciones complicadas están mal hechas. Para salvar el problema de interoperabiliad se crearon los Servicios Web XML. La idea es, que dos o más aplicaciones orientadas a la Web intercambien información, lo cual, a nivel conceptual, es fácil de entender y sólo algunos aspectos puntuales requieren consideración adicional:
- Cómo nos aseguramos de que nuestra información no se encuentra viajando libremente y visible para cualquiera con un sniffer en el sitio adecuado?
- Cómo podemos ponerle algo de seguridad a la comunicación, de tal forma que no cualquiera pueda ingresar o extraer datos de nuestra aplicación o bien disparar procesos que en últimas sobrecarguen nuestros servidores en lo que se conoce como un ataque de Negación de Servicio (DoS)?
Hay muchas soluciones para las anteriores incógnitas, a mi personalmente me gustan las señaladas a continuación:
- Si la información que se transporta es muy sensible (hay quienes sostienen que TODA la información es sensible, pero eso es otro tema), siempre podemos usar SSL. Esto encripta los mensajes bastante bien, aunque incrementa la carga en el servidor (por las operaciones de criptografía) y su implementación no es trivial. Pero una vez implementado, y con algo de conocimiento en certificados SSL, tendrá una integración de datos más que razonablemente segura.
- Normalmente, se espera que las comunicaciones se den entre distintos servidores, si este es el caso, puede usar una técnica llama IP Lockdown, es decir que sólo recibe comunicaciones de una lista de direcciones IP registradas en la configuración de su aplicación. Puede incluso mejorar esto un poco usando algún esquema de autenticación provisto por Apache (o su servidor Web de preferencia), como por ejemplo autenticación básica. Hay mucha referencia extensiva a este respecto, y de seguro mejorará la seguridad de su aplicación. Eso si: SIEMPRE DEJE UN LOG DE LAS TRANSACCIONES REALIZADAS, la idea es que si se presenta cualquier eventualidad, pueda usted ver desde donde y cuándo se generan las peticiones, junto con la mayor cantidad de información relevante (algunos desarrolladores incluyen todo el mensaje de entrada, con sus cabeceras XML y demás, normalmente yo llego hasta una representación JSON de los parámetros de entrada y opcionalmente el tiempo de ejecución de la tarea asociada - de tal forma que sea posible estimar las peticiones que realmente afecten el servicio). Lockdown y autenticación Apache son óptimos porque aíslan el acceso a los recursos de cómputo, es decir: petición errada o inválida ni siquiera entra a ser evaluada, simplemente se rechaza. Por la anterior razón también es importante analizar los logs que deja Apache (o su Web Server de preferencia)
- En el caso en el cual se implemente un servicio web abierto, es importante pensar en otras restricciones, por ejemplo el uso de autenticación SOAP, que en si representa tema suficiente para otro post.
- Personalmente, prefiero los servicios usando SOAP en lugar de REST o XML-RPC, me parece que la formalidad de SOAP y el complique de hacer un buen WSDL para el servicio son de lejos sopesados por la extensibilidad y robustez que ofrece.
- Haga una buena especificación de su Web Service. Hay desarrolladores que planean poco y resuelven todo sobre la marcha, sin embargo a la hora de integrar datos uno NO DEBE improvisar (en general uno no debe improvisar si está desarrollando, esto hace que no sea posible dimensionar el costo y tiempo de un proyecto y por lo tanto alguien salga perjudicado, usted o su cliente, además de ser muy poco profesional). Una buena especificación, que muestre todo el API SOAP que usted va a implementar y los servicios que su aplicación consumirá de otros servidores es de la máxima utilidad, defina certeramente los parámetros de entrada de cada método así como las salidas, de esta forma no improvisará sobre la marcha. Una buena planeación es crucial para entregar un buen producto.
