SOAP architecture de rappel de service Web?
Je suis assez novice dans les services Web, JAX-WS, etc.
Je souhaite donc implémenter un service Web pour faire communiquer deux systèmes. Le système "client" s'intéresse aux événements générés sur le système "serveur". Mais le "système client" est lui-même un serveur pour une application différente. Le serveur est Java (WAR dans Tomcat). Le client est .Net.
Il devrait y avoir un seul système client, mais plusieurs processus client dans le système client, chacun étant intéressé par des catégories d'événements distinctes.
Je vais implémenter le côté serveur et un client test. Quelqu'un d'autre implémentera le code .Net.
La séquence en cours devrait être le long de cette ligne:
- Le serveur est en cours d'exécution ...
- Le client initie la conversation, "s'enregistre" sur le serveur et demande des données initiales.
- Le serveur conserve une liste des points de terminaison des clients enregistrés
- Le serveur contient un auditeur qui est averti lorsque certains événements se produisent. Il passera ensuite à la liste des clients inscrits et transmettra l'événement à chacun d'eux.
- À un moment donné, le client peut "désinscrire". Aucune notification au serveur qu'il ne veut plus recevoir d'événements.
Tout d’abord, cela ressemble-t-il à quelque chose de raisonnablement faisable?
Et existe-t-il un mécanisme intégré standard, utilisant SOAP (JAX-WS sur le serveur, tout ce qui est disponible avec .Net sur le client) - que le serveur peut utiliser pour obtenir un point de terminaison de rappel à partir du client?
Par exemple, j'ai utilisé quelque chose de très similaire avec RMI. Dans ce cas, le client peut simplement s'envoyer une référence distante, que le serveur peut simplement stocker et faire référence ultérieurement.
Enfin, existe-t-il une bibliothèque standard pour stocker les références des points de terminaison, effectuer des rappels (collectifs) et éventuellement maintenir la liste à jour, en supprimant les clients qui ne répondent pas afin de lancer un appel "ping"?
Remarque pour plus de clarté: il me faut plus qu'une méthode asynchrone avec rappel: un message du client générera de nombreux messages de rappel du serveur au client.
On dirait que vous souhaitez implémenter une fonction de notification pour informer les clients anonymes arbitraires.
Je vous suggère tout d’abord d’examiner comment transmettre les informations à l’aide de messages SOAP. Ensuite, vous pouvez déterminer comment y parvenir à l'aide de Java - JAX-WS ou de bibliothèques supplémentaires non standard. Le fait est que des restrictions ou hypothèses importantes peuvent être nécessaires pour transférer les messages SOAP. Par exemple. les pare-feu peuvent bloquer vos messages HTTP, les clients peuvent "juste des clients" sans possibilité d'agir dans un rôle de serveur pour recevoir SOAP demandes de notification
Remarque: Un mécanisme de rappel asynchrone est défini dans JAX-WS 2.0, dans lequel le service obtient la référence de noeud final du client. Il s’agit du même type de fonctionnalité que celle fournie par la solution exclusive WebLogic/Fusion décrite par Deepak Bala. Websphere dispose d'une solution asynchrone propriétaire similaire. Aucune de celles-ci ne répond à vos exigences, car elles ne permettent qu'une seule réponse par demande.
Options SOAP:
Messages SOAP propriétaires - l'option "100% à faire soi-même"
Vous concevez des schémas de charge utile et un modèle d'échange de messages complets SOAP.
Vous pouvez envoyer la notification du serveur au client si vous connaissez l'adresse du noeud final SOAP du client. Le client peut transférer sa SOAP adresse de noeud final dans la charge _ de la demande SOAP originale. Un peu plus tard, le serveur peut envoyer une demande SOAP au client.
Problèmes/hypothèses: (1) besoin d'un chemin de communication SOAP/HTTP pour les demandes de serveur à client - non garanti en présence de pare-feu; (2) le client doit connaître votre schéma de notification. En fait, il doit agir en tant que point de terminaison Service pour recevoir la demande de notification SOAP. C’est deux grandes hypothèses SI vous essayez de prendre en charge des clients anonymes arbitraires - ce n’est pas une chose SOAP "ne fait que supporter" les deux extrémités doivent concevoir tout cela en détail. En fait, pour effectuer cela de manière sécurisée, le client doit en fait déclarer sa propre interface WSDL de service afin que vous puissiez l'appeler. (3) Comme indiqué précédemment, de nombreux clients ne sont "que des clients" - ils n'ont peut-être pas de serveur HTTP pour accepter les demandes SOAP.
Donc, pour que les notifications "Push" propriétaires fonctionnent, les deux côtés ont besoin des serveurs et doivent publier leurs interfaces SOA.
Vous pouvez également extraire la notification au client. Le client peut utiliser une demande de notification au serveur qui bloque ou interroge. Le serveur peut répondre avec la notification ou rien ou une erreur.
Problèmes/Hypothèses: (1) Les serveurs HTTP (c’est-à-dire le serveur SOAP) ne prennent pas en charge le blocage des demandes. En règle générale, vous devez interroger; (2) le client doit connaître votre schéma de notification. En fait, il doit agir en tant que point de terminaison Service pour recevoir la demande de notification SOAP. C’est deux très grandes hypothèses pour un client anonyme arbitraire - ce n’est pas quelque chose que SOAP "prend en charge", mais que les deux extrémités doivent concevoir tout cela en détail. En fait, pour effectuer cela de manière sécurisée, le client doit en fait déclarer sa propre interface WSDL de service afin que vous puissiez l'appeler.
Comme ci-dessus, mais incluez les données d’adressage WS dans les en-têtes SOAP pour informer l’un des côtés de l’adresse du noeud final de l’autre.
Fondamentalement les mêmes problèmes/hypothèses que la première option. Les adresses d’adresse WS vous aideront à diriger intelligemment les messages SOAP vers la bonne adresse URL, mais sans plus.
Utiliser la notification WS
Cette spécification a été conçue pour votre scénario.
La sous-norme WS-BaseNotification répondrait à vos besoins. Il fournit des définitions de port WSDL pour les producteurs et les consommateurs de notifications. Il fournit une solution conforme aux normes WS pour la souscription d'un consommateur à un producteur et une notification des producteurs aux consommateurs.Problèmes/Limitations: (1) Il ne définit PAS le format des données utiles de notification. La charge de notification est spécifique à un domaine d'application (conception exclusive). La norme ne définit aucune situation ou message de notification "standard" ou "intégré". (2) Il a les mêmes problèmes avec les notifications HTTP passant par les pare-feu que ceux mentionnés ci-dessus. (3) WS-Notification n'est pas une norme prise en charge de Java EE/JAX-WS (mais il existe de nombreux serveurs d'applications, open source et commerciaux, qui la prennent en charge comme une extension).
Utilisez une solution de mise en file d'attente des messages (JMS, par exemple) avec un trafic encapsulé dans HTTP. Ceci nécessite une conception exclusive des charges utiles échangées entre le client et le serveur, ainsi que des contrats de rétro-formation entre les deux parties. Un avantage est que le client peut être un client pur, avec un écouteur de message appelé dans un fil de discussion lorsqu'un message est reçu.
Problèmes/Limitations: (1) Il a les mêmes problèmes avec les notifications HTTP passant par les pare-feu que mentionné ci-dessus. (2) Est une implémentation à faire soi-même. (3) Utilise plus de technologie que vous utilisez actuellement.
Résultat final:
Au moins une partie de votre solution doit être une conception brevetée - les normes SOAP/WS ne répondent pas à toutes vos exigences. En théorie, cette conception brevetée pourrait exploiter un produit pour fournir une bonne partie des démarches, MAIS la conception du schéma de notification devrait être créée et intégrée par vous.
Si vous souhaitez envoyer des notifications, il vous faut n pe sorte de contrat pour les notifications transmises au client, ce dernier doit agir en tant que serveur SOA et vous devez disposer des pare-feu ouverts. votre trafic. La plupart des entreprises interdisent les demandes HTTP quittant un serveur et les transmettant à un client - vous avez normalement besoin d'une très bonne raison pour ouvrir les ports de pare-feu et même dans ce cas, de nombreuses entreprises l'interdisent ...
Si vous souhaitez que les clients interrogent les notifications, vous avez simplement besoin d'une interface WSDL de base côté serveur, pouvant être appelée fréquemment par les clients.
Option future: Sockets Web HTML5
SI votre client est une application HTML5, les serveurs activés pour les sockets Web peuvent envoyer du trafic au navigateur. Il est donc possible que les sociétés ouvrent des pare-feu. SOAP les messages pourraient voyager sur les sockets Web HTTP, vous permettant ainsi d'envoyer des notifications.
Les clients asynchrones sont pris en charge pour les services WSDL via l'utilisation de polling et callbacks . Dans votre cas, je pense que l'exigence est relativement plus compliquée.
Le middleware de fusion Oracle page de doc présente un scénario qui vous aidera. Il détaille une méthode qui permet aux clients d'envoyer des requêtes générant un HTTP 202 (accepté). Les clients attendent ensuite une réponse sur les files d'attente de messages. Dans votre cas, le scénario peut être modifié par rapport à celui présenté ci-dessous.
Initiez plusieurs files d'attente de réponses pour chaque catégorie de rappel. Les clients peuvent les filtrer en fournissant un client et un ID de catégorie pour la file d'attente. Cela servira de mécanisme de rappel pour chaque client ou pour les processus régis par chaque client. La MDB peut être sauvegardée par un magasin de fichiers ou par une base de données pour assurer la fiabilité et une livraison unique.
Bien entendu, Oracle Fusionware n’est pas nécessaire pour mettre cela en œuvre. Vous pouvez utiliser RabbitMQ ou Redis (avec transactions) pour accuser réception d'un message sur le client. Si votre client souhaite l'annuler, passez un appel et arrêtez d'écouter la file d'attente.
Je ne connais aucune norme de l'industrie qui convienne à votre scénario, mais je pense que cette solution devrait bien fonctionner pour vous.
Avez-vous envisagé l’approche la plus simple consistant à utiliser "pub-sub" avec un produit de messagerie? .__ (comme MQ, EMS ou ActiveMQ)
Les exigences que vous décrivez ne semblent pas correspondre aux scénarios de service Web "classique" de requête/réponse sync/async SOAP.
Dans une solution Pub/Sub, les clients s'abonnent une fois à un sujet et les éditeurs (dans votre cas, le serveur) peuvent envoyer un nombre quelconque de messages pertinents à tous les abonnés.
En prime, la plupart des produits de messagerie incluent un support pour les "abonnés durables", de sorte que le client puisse parfois être hors ligne et recevoir tous les messages après la reconnexion.
Dans votre cas, le serveur pourrait héberger un serveur ActiveMQ (gratuit) ... Fournissant la plupart des fonctionnalités que vous semblez rechercher.
Si vous choisissez cette méthode, je vous suggère de choisir un produit compatible JMS prenant en charge .Net.
Pour ceux qui arrivent ici des moteurs de recherche:
De nos jours, vous pouvez utiliser un WebHook pour les API Web, qui fonctionne essentiellement comme décrit par OP.
Dans REST par exemple, le client aura un point de terminaison HTTP lui-même dédié à la réception d'événements POST/notifications du serveur réel. Le client enregistre son noeud final auprès du serveur actuel en lui attribuant un URI sur son noeud final de notification. À partir de ce moment, le serveur actuel peut POST sur le point de terminaison de notification du client. Il s'agit essentiellement d'un rappel compliqué, si vous connaissez la terminologie asynchrone.
Peut-être que Java ou .Net ont déjà des bibliothèques pour WebHooks.
Cela dit, les normes SSE et Websockets fournissent des messages Push réels et en temps réel, tout en étant compatibles avec HTTP et la plupart des navigateurs.
Les longues variations d'interrogation étaient également utilisées dans le passé et s'appellent parfois parfois Comet en tant qu'agrégat.