Garantie de livraison des services Web B2B : modèle d'utilisation point à point
Dans ce modèle d'utilisation, un fabricant vend ses produits via un réseau de concessionnaires affiliés. Ce fabricant a initié un projet pilote pour améliorer l'intégration de la technologie de l'information entre sa propre organisation de distribution et une demi-douzaine des concessionnaires les plus importants.
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. Pour consulter des exemples de ces normes et messages, voir United Nations Directories for Electronic Data Interchange.
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 XML soient disponibles pour la réalisation du commerce électronique business-to-business (par exemple, les spécifications OASIS Electronic Business using eXtensible Markup Language (ebXML)), le fabricant a décidé d'étudier l'utilisation de technologies de services Web et utilise des documents WSDL 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 implémenter les demandes d'informations en utilisant SOAP sur HTTP et SOAP sur JMS. Les distributeurs sont libres de choisir leur propre technologie d'implémentation ; ils ne sont pas obligés d'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 de 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 rend cette solution accessible à 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'utiliser WebSphere Application Server et WebSphere MQ soit acceptable pour l'ensemble des distributeurs actuels, alors que le projet prend de l'envergure, d'autres partenaires peuvent ne pas vouloir ou pouvoir utiliser une plateforme logicielle commune.
Solution en utilisant WS-ReliableMessaging
Avec le support WS-ReliableMessaging dans WebSphere Application Server, le fabricant peut remplacer ses solutions de nouvelle tentative personnalisées pour la messagerie unidirectionnelle fiable par la messagerie unidirectionnelle SOAP sur HTTP. 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.