pooling de connexions sur web service jax-ws

Salut à tous.
Bon voici mon problème: j'ai un serveur web qui se connecte occasionnellement à un autre serveur web via des web services. Comme j'utilise de l'authentification (en utilisant WSIT) la première connexion peut s'avérer très lente (de l'ordre de trois secondes, enfin ça c'est sur mon portable de développement qui date un peu j'avoue).
D'où la nécessité pour moi d'utiliser un pool de connexions suivant le même principe que ceux que tout le monde utilise pour les connexions aux bases de données: maintenir la connexion autant que faire se peut, la réinitialiser automatiquement si elle est tombée, éventuellement gérer plusieurs connexions simultanées (j'ignore si plusieurs threads peuvent se partager la même connexion à un web service) etc....
Donc ma question: est-ce que Jax-Ws est capable de gérer cela automatiquement (si j'instancie un service et que je le stocke en statique par exemple, est-ce que l'objet sera toujours utilisable dans trois semaines?) ou bien faut-il utiliser une quelconque sur-couche comme avec les connexions JDBC? Dans le second cas que pouvez vous me recommander comme biblio?
Merci d'avance.

Citation:

---

Envoyé par zais_ethael

Salut à tous.
Bon voici mon problème: j'ai un serveur web qui se connecte occasionnellement à un autre serveur web via des web services. Comme j'utilise de l'authentification (en utilisant WSIT) la première connexion peut s'avérer très lente (de l'ordre de trois secondes, enfin ça c'est sur mon portable de développement qui date un peu j'avoue).

---

Ceci est du à l'initialisation de la Servlet d'entrée et du framework de webservices, ya rien à faire (à part changer de framework). Je parie que tu utilises Axis1.

Citation:

---

Envoyé par zais_ethael

D'où la nécessité pour moi d'utiliser un pool de connexions suivant le même principe que ceux que tout le monde utilise pour les connexions aux bases de données

---

Il est possible de faire ça avec HTTP/1.1 je crois, avec un client http comme Commons-HttpClient. Ceci ne résoud pas le cas au dessus.

Citation:

---

Envoyé par bugsan

Ceci est du à l'initialisation de la Servlet d'entrée et du framework de webservices, ya rien à faire (à part changer de framework). Je parie que tu utilises Axis1.

---

Non, Metro. Mais ici c'est avant tout dû à la négociation de clé de session qui est toujours très lente si c'est du code java qui s'en charge.

Citation:

---

Envoyé par bugsan

Il est possible de faire ça avec HTTP/1.1 je crois, avec un client http comme Commons-HttpClient. Ceci ne résoud pas le cas au dessus.

---

Heu, je ne pense pas que ça puisse résoudre mon problème. L'initialisation de la connexion dans ce cas-ci dépasse de loin la couche de transport que représente http. Ce qu'il me faudrait c'est un truc qui dés que je fais appel à mon web service vérifie si il est encore en vie et dans le cas contraire le ré-instancie - le tout en utilisant les fonctionnalités de jax-ws (comme les datasources style DBCP avec JDBC quoi).

Ce que tu dis me laisse perplex, car :
1- http n'est pas une communication connectée (alors qu'une connexion bdd maintient une connexion TCP)
2- Tu fais référence à une "négociation" de session, tu parles de SSL ?
3- Je ne comprends pas bien quand tu dis que ton webservice est ou n'est plus "en vie". C'est une servlet avec des messages SOAP, rien de plus..

Citation:

---

Envoyé par bugsan

Ce que tu dis me laisse perplex, car :
1- http n'est pas une communication connectée (alors qu'une connexion bdd maintient une connexion TCP)
2- Tu fais référence à une "négociation" de session, tu parles de SSL ?
3- Je ne comprends pas bien quand tu dis que ton webservice est ou n'est plus "en vie". C'est une servlet avec des messages SOAP, rien de plus..

---

Mais... ça n'a absolument rien à voir avec le fait que ce soit un protocole basé sur un couche de transport en mode connecté ou pas. Il existe d'autres couches de transport que http pour les web services, de même que rien n'oblige les protocoles de communication à une base de donnée d'être conçus sur tcp, ni même sur un quelconque mode connecté.
Dés qu'on fait quelque chose d'un tout petit peu plus évolué qu'un helloWorld il est indispensable de gérer des sessions, avec des Web Services comme avec pratiquement n'importe quel protocole généraliste. Que ce soit une session http avec cookies, une ssl avec négociation de clé de session ou une WS-Security avec... ben clé de session aussi il y a bien des informations mémorisées des deux cotés. Coté serveur il est impossible de les stocker indéfiniment, d'où le fameux paramètre à configurer dans le web.xml indiquant la durée maximale d'une session.
Si on attend trop longtemps, le serveur va inévitablement "oublier" les informations qui le lient au client, d'où la nécessité pour avoir un minimum d'abstraction de posséder un système coté client capable de détecter la chute d'une session et de la réinitialiser automatiquement et de façon transparente. Sans ça il n'y a pas d'autre solution que d'initialiser une nouvelle session à chaque fois que le client doit faire une requête puis à la tuer après, comme on le fait quand on apprend à utiliser JDBC au début. L'ennui c'est que de base c'est déjà très lent, mais si on rajoute de la négociation de clé de chiffrement ça devient abominable.

Vu que personne ne semble s'être posé la question ici je suppose que c'est déjà intégré de base dans Jax-ws. Néanmoins comme je ne l'ai jamais lu nulle part et que le tester aurais un aspect assez aléatoire il faut bien que je sache avant de catapulter mes serveurs en prod :D

Ce que je voulais simplement dire, c'est qu'un id de session n'influence en rien le fait qu'une servlet soit ou non préchargée coté serveur. Après si tu es sur que ce qui est lent c'est bien l'échange de clé et pas l'instanciation du service Axis (ou autre), alors OK :

Il faut que tu utilises une librairies comme Commons-Pool, elle est utilisée par DBCP également.
Dans ton cas ce qui importe c'est que le pool maintienne en permanence une connexion et qu'au bout de X temps IDLE (inférieur à la disparition de la session), il détruise cette connexion et en recréer une nouvelle, de telle manière que cette création se produise en fond de tache (donc sans gêner tes traitements).

J'ai moi même utilisé cette lib pour des connexions RMI-IIOP, et tout ce que je viens d'énumérer est faisable rien qu'avec Commons-Pool.
Pour la mécanique du pool le mieu est de s'inspirer des sources de commons-dbcp.
L'idée c'est d'avoir une Factory capable de créer le client WS, qui sera utilisée par une classe de type PoolableObjectFactory.

Si je devais l'implémenter moi même je choisirais peut-être Common Pools comme base de travail mais ça ne m'apporterait comme avantage que de jolies interfaces pré-conçues, l'aspect technique reste entier.

Par exemple, tu parles de réinitialiser la connexion à intervalle régulier, ça ne solutionne pas le problème. Le client n'est pas supposé avoir la moindre idée du temps pendant lequel le serveur va conserver sa session active. De même pendant mes tests j'ai pu observer des cas d'erreur ou cela n'aurait aucun effet (notamment un ou le serveur a crashé et s'est relancé tout de suite après, le client n'ayant pas oublié ses infos de session il les renvoyait systématiquement au serveur, ce dernier ne les ayant plus en mémoire toutes les tentatives échouaient systématiquement - en implémentant ce que tu proposes il suffirait qu'il y ait suffisamment de demandes pour que la session ne soit jamais réinitialisée, la seule solution serait alors de relancer le client).

Tu vois, tout comme je n'aurais pas la prétention de refaire DBCP en un jour je ne vais pas me lancer dans la conception de ce genre d'api appliquée aux web services. La raison pour laquelle j'ai posté ce message est que ce besoin me semble récurrent, autant que celui qui justifie l'existence de DBCP et autres apis concurrentes.
Mais bon si personne n'a entendu parler d'une biblio permettant de résoudre ce problème je peux aussi bien laisser tomber et établir des session à la demande. Ce sera lent mais je préfère ça à un système bancal bricolé avec deux bouts de ficelle.

Commons-Pool requiert juste que tu définisses comment créer un objet, comment le détruire, et ce qui défini qu'il est invalidé.

Tout le moteur de pooling n'a pas à être refait évidement. C'est max 100 lignes de codes.

Ca serait assez long à expliquer ici tout ce que fournit Commons-Pool. Mais par exemple tu as la possibilité de définir une méthode de test qui peut être appelé avant de récupérer une connexion du pool, ainsi qu'avant de l'y remettre. Cette méthode peut également être appelé à intervalle régulier sur les connexions non utilisées.

Bien sur si ton serveur plante pendant un traitement du client, soit tu geres les exception dans ton métier, soit tu utilises un objet proxy qui retente la connexion de manière transparente.

Le scénario type avec commons-pool :
Je demande une connexion au pool, le pool récupère une connexion existante, il l'a test => appel d'une méthode test du WebService => plantage car plus de session => le pool détruit cette connexion, en recrée une, la test, et enfin la retourne.

Tout ça peut être transparent en utilisant le pattern proxy/adapter (sur l'interface du client de web services)

Tu dis ça comme si c'était d'une simplicité enfantine, ça ne l'est pas. Il y a beaucoup trop de cas d'erreurs auxquels je ne vais pas penser en me penchant sur le problème cinq minutes. Ça me prendrait trop de temps de faire cela de façon nickel, et je n'ai pas que ça à faire.
Or si ce n'est pas absolument parfait ça fonctionnerait moins bien que des connexions à la demande, comme dans le cas que je t'ai cité plus haut où le mode de fonctionnement que tu proposais déservirait le client en empêchant le rétablissement d'une connexion fonctionnelle.