Garantie de livraison des services Web B2B : modèle d'utilisation point à point

La solution technique existante

Historiquement, l'"e-commerce" B2B (business-to-business) repose sur EDI (Electronic Data Interchange). EDI est un ensemble de normes destinées au contenu et à la mise en forme des messages business-to-business.

Si les identités des partenaires de communication sont connues et non modifiées, l'utilisation des définitions de message normalisées n'est pas strictement nécessaire. Bien que d'autres normes basées sur XML soient disponibles pour la conduite du commerce électronique d'entreprise à entreprise (telles que les spécifications OASIS Electronic Business using eXtensible Markup Language (ebXML) ), le fabricant a décidé d'étudier l'utilisation des technologies de services Web et utilise des documents WSDL provenant de diverses sources pour définir les interfaces de service.

Les interactions entre le fabricant et ses distributeurs pour le projet pilote initial relèvent des deux catégories suivantes :

• Demandes d'informations. L'interaction est bidirectionnelle, dans la mesure où un message de demande d'informations est envoyé et un message de réponse contenant les informations demandées est envoyé dans le sens inverse. Un exemple de demande d'informations d'un distributeur au fabricant peut être "getOrderStatus".
• Demandes de mise à jour. Ces interactions sont unidirectionnelles, dans la mesure où l'émetteur d'une demande de mise à jour ne dépend pas de la réception de réponse pour poursuivre ses autres travaux. Un exemple de demande de mise à jour d'un distributeur au fabricant peut être "placeOrder". Un exemple de demande de mise à jour d'un fabricant au distributeur peut être "deliveryConfirmed".

Le fabricant utilise WebSphere® Application Server pour traiter les demandes d'informations à l'aide de SOAP sur HTTP et SOAP sur JMS. Les distributeurs sont libres de choisir leur propre technologie d'implémentation ; ils n'ont pas à utiliser WebSphere Application Server.

Le fabricant implémente les demandes de mise à jour selon les deux méthodes suivantes :

• Via SOAP sur HTTP. Dans ce cas, le service est représenté sous la forme d'une interaction de demande/réponse considérée comme ayant réussi lorsque le demandeur reçoit une réponse. Les services doivent être implémentés pour détecter et répondre correctement aux demandes en double (il s'agit d'une opération idempotent), et le client doit être implémenté pour refaire une tentative si la communication est interrompue après l'envoi de la demande mais avant la réception de la réponse.
• Pour éviter les limitations précédentes, le fabricant utilise également le support SOAP sur JMS de WebSphere Application Server et WebSphere MQ. Dans ce cas, la demande est représentée sous la forme d'un service unidirectionnel et les messages sont livrés de manière fiable. Le fabricant utilise WebSphere MQ comme fournisseur JMS et met cette solution à la disposition de tous les distributeurs qui utilisent également WebSphere Application Server et WebSphere MQ. Il n'est pas nécessaire que le distributeur et le fabricant soient connectés pour que le message soit envoyé.

Les messages sont transmis sur des réseaux privés virtuels pour garantir l'intégrité et la confidentialité des messages transmis entre les deux métiers et dans le cadre de l'établissement de l'identité de l'émetteur.

Le problème métier

Bien que le fabricant et ses distributeurs soient satisfaits de l'implémentation des services de demande d'informations, le scénario de demande de mise à jour comporte un certain nombre de problèmes :

• Via SOAP sur HTTP :
  • Pour le fabricant, l'implémentation de services idempotent est compliquée, donc plus coûteuse en termes de temps développeur. Elle augmente la probabilité des erreurs de codage, ce qui réduit la robustesse de la solution et introduit la possibilité de commandes supprimées ou dupliquées coûteuses.
  • Pour les distributeurs, l'implémentation de la logique de relance est complexe, coûteuse et génératrice d'erreurs.
  • Pour le fabricant et les distributeurs, l'exigence de leur disponibilité à tous les deux afin d'appeler le service constitue un aspect critique. En particulier, la plupart des distributeurs ne gèrent pas la disponibilité de leurs systèmes sept jours par semaine alors que, pour le fabricant, les week-ends représentent le moment idéal pour transmettre des mises à jour de prix aux distributeurs. De même, l'incapacité de passer des commandes lorsque la connectivité entre le distributeur et le fabricant est indisponible est un réel problème métier.
• Via SOAP sur JMS :
  • Bien que la nécessité d'utilisation de WebSphere Application Server et WebSphere MQ soit acceptable par l'ensemble des distributeurs actuels, à mesure que le projet évolue, il existe peut-être d'autres partenaires qui refusent ou qui sont incapables d'utiliser une plateforme logicielle commune.

Solution en utilisant WS-ReliableMessaging

Grâce à la prise en charge de WS-ReliableMessaging dans WebSphere Application Server, le fabricant peut remplacer ses solutions de relance personnalisée existantes pour la messagerie unidirectionnelle fiable à l'aide de la messagerie unidirectionnelle SOAP sur HTTP standard. La suppression de la logique de relance de l'application simplifie le code d'application, ce qui permet un développement d'application plus simple et plus rapide.

Avec WS-ReliableMessaging, il n'est pas nécessaire que le distributeur et le fabricant soient connectés pour que le message soit envoyé.

La norme WS-ReliableMessaging ajoute de la fiabilité à la messagerie SOAP sur HTTP, ce qui réduit le besoin d'utiliser SOAP sur JMS.

Dans la mesure où WS-ReliableMessaging avec SOAP sur HTTP est une norme interopérable, il n'est pas nécessaire que le réseau de distributeurs utilise une plateforme logicielle commune.