Entrega garantizada de servicios web de B2B: patrón de uso de punto a punto
En este patrón de uso, un fabricante vende sus productos a través de una red de concesionarios afiliados. Este fabricante ha iniciado un proyecto piloto para mejorar la integración de IT entre su propia organización de venta al por menor y media docena los concesionarios más grandes e importantes.
La solución técnica existente
Históricamente, el comercio electrónico de empresa a empresa se ha realizado utilizando el intercambio electrónico de datos (EDI). EDI es un conjunto de estándares para el contenido y formateo de mensajes de empresa a empresa. Por obtener ejemplos de estos estándares y mensajes, consulte United Nations Directories for Electronic Data Interchange.
Si las identidades de los socios de comunicación son conocidas y no cambian, el uso de definiciones de mensajes de estándares del sector no es estrictamente necesario. Aunque para el comercio electrónico de empresa a empresa (como las especificaciones OASIS Electronic Business using eXtensible Markup Language (ebXML)) hay disponibles otros estándares basados en XML, el fabricante ha decidido investigar el uso de tecnologías de servicios Web y utiliza documentos WSDL de distintas fuentes para definir las interfaces de servicio.
Las interacciones entre el fabricante y sus concesionarios para el proyecto piloto inicial se incluyen en dos categorías:
- Solicitudes de información. La interacción es bidireccional, lo que significa que se envía un mensaje de solicitud solicitando información y en la dirección inversa se envía un mensaje de respuesta que contiene la información solicitada. Un ejemplo de una solicitud de información de un concesionario al fabricante puede ser "getOrderStatus".
- Solicitudes de actualización. Estas interacciones son unidireccionales, lo que significa que un remitente de una solicitud de actualización no depende de recibir una respuesta para poder continuar con otro trabajo. Un ejemplo de una solicitud de actualización de un concesionario al fabricante puede ser "placeOrder". Un ejemplo de una solicitud de actualización de un fabricante al concesionario puede ser "deliveryConfirmed".
El fabricante utiliza WebSphere Application Server para implementar solicitudes de información utilizando SOAP sobre HTTP y SOAP sobre JMS. Los concesionarios pueden elegir su propia tecnología de implementación; no tienen que utilizar WebSphere Application Server.
El fabricante implementa solicitudes de actualización de dos formas distintas:
- Si se utiliza SOAP sobre HTTP. En este caso, el servicio se representa como una interacción de solicitud y respuesta que se considera satisfactoria cuando el solicitante recibe correctamente una respuesta. Se deben implementar los servicios para detectar y responder de manera satisfactoria a las solicitudes duplicadas (esto se denomina operación idempotente) y se tiene que implementar el cliente para intentarlo de nuevo si se ha interrumpido la comunicación después de que se haya enviado la solicitud pero antes de que se haya recibido la respuesta.
- Para evitar las limitaciones anteriores, el fabricante también utiliza el soporte de SOAP sobre JMS desde WebSphere Application Server y WebSphere MQ. En este caso, la solicitud se representa como un servicio unidireccional, y los mensajes se entregan de forma fiable. El fabricante utiliza WebSphere MQ como proveedor de JMS y pone esta solución a disposición de todos los concesionarios que también utilizan WebSphere Application Server y WebSphere MQ. Para enviar el mensaje no es necesario que el concesionario y el fabricante estén conectados.
Los mensajes se transmiten sobre redes privadas virtuales (VPN) para garantizar la integridad y la confidencialidad de los mensajes transmitidos entre las dos empresas, y como parte del establecimiento de la identidad del remitente.
El problema empresarial
Aunque tanto el fabricante como sus concesionarios están satisfechos con la implementación de los servicios de solicitud de información, hay varias cuestiones en el caso de la solicitud de actualización:
- Si se utiliza SOAP sobre HTTP:
- Para el fabricante, la implementación de servicios idempotentes es complicada y, por ello más costosa en tiempo de desarrollador. Aumenta la probabilidad de errores de codificación, reduce la robustez de la solución e introduce la posibilidad de que se dupliquen o eliminen pedidos.
- Para los concesionarios, la implementación de la lógica de reintento es igualmente compleja, costosa y propensa a errores.
- Tanto para el fabricante como para los concesionarios, el requisito de que los dos estén disponibles para poder invocar el servicio es un problema. En concreto, muchos concesionarios no mantienen una disponibilidad de siete días en sus sistemas, mientras que para el fabricante los fines de semana representan el momento perfecto para proporcionar actualizaciones de precios a los concesionarios. De forma parecida, el no poder formular pedidos cuando la conectividad entre el concesionario y el fabricante no está disponible es un verdadero problema.
- Si se utiliza SOAP sobre JMS:
- Aunque si se requiere el uso de WebSphere Application Server y WebSphere MQ es aceptable en el conjunto actual de concesionarios, a medida que el proyecto se expanda puede haber otros socios que no deseen o no puedan utilizar una plataforma de software común.
Solución al utilizar WS-ReliableMessaging
Con el soporte de WS-ReliableMessaging en WebSphere Application Server, el fabricante puede sustituir sus soluciones existentes de reintento personalizado para la mensajería unidireccional fiable por la mensajería unidireccional estándar de SOAP sobre HTTP. La eliminación de la lógica de reintento de la aplicación simplifica el código de aplicación, y permite un desarrollo de la aplicación más fácil y rápido.
Con WS-ReliableMessaging, no es necesario que el concesionario y el fabricante estén conectados para que se envíe el mensaje.
El estándar de WS-ReliableMessaging añade fiabilidad a la mensajería de SOAP sobre HTTP, y reduce la necesidad de utilizar SOAP sobre JMS.
Dado que WS-ReliableMessaging con SOAP sobre HTTP es un estándar interoperable, la red de concesionarios no necesitan utilizar una plataforma de software común.