[Conseils] WebServices plutôt que Client/Serveur classique ?

Bonjour à tous,

Après avoir mené une première réflexion sur l'architecture de développement de mon projet (dans ce thread), je contacte les experts WebServices pour me conseiller dans mes choix.

Je commence par vous donner le contexte de mon projet :

• L'architecture se compose d'un serveur Web avec base de données pour la partie IHM, d'un serveur de communication, des différents clients sur les machines du réseau.
• J'avais imaginé une communication classique client/serveur : le serveur doit en effet contacter tous les clients à intervalles réguliers pour qu'ils déclenchent une opération.
• L'interface Web doit également permettre de déclencher une opération à la demande. Pour éviter de développer deux fois les fonctions de communication, j'avais pensé à ce que le serveur écoute sur un port réservé les éventuelles demandes de l'application Web, pour déclencher en conséquence une demande vers un client.
• Le client peut avoir à récupérer des fichiers volumineux (jusqu'à 30 Mo).

Je n'ai pas encore eu l'occasion d'utiliser les WebServices dans un contexte projet, et j'ai imaginé le fonctionnement suivant :

• La communication se ferait entre le WebService et les clients.
• Pour déclencher à intervalles réguliers les demandes vers les clients, le serveur de communication ferait simplement appel au WebService.
• En cas de demande forcée, l'interface Web appelerait également le WebService.

Mes interrogations sont donc les suivantes :

• Une solution par WebService est-elle mieux adaptée qu'une communication client/serveur traditionnelle dans mon cas (évite de faire relayer une demande forcée du serveur web vers le client par le serveur de communication) ?
• Les performances de transfert de fichiers sont-elles bonnes à travers un WebService (comme indiqué précédemment, les fichiers peuvent faire jusqu'à 30 Mo)
• Un WebService correspondra-t-il a une fonctionnalité de l'application (exemple : lister les fichiers de tel répertoire => un WS, récupérer un fichier sur le serveur => un autre WS) ?
• Les accès simultanés aux WebServices sont-ils bien gérés (plusieurs clients essaient de s'y connecter à la fois, mais aussi l'inverse : plusieurs demandes forcées émises par l'interface Web arrivent au même moment sur le client)

Je vous remercie d'avance d'apporter votre expérience à ma réflexion.

Bonjour,

je ne suis pas un spécialiste des Web Services, mais je ne pense pas qu'ils apporteront un avantage fonctionnel ou structurel à ton architecture. Les Web Services apportent un réel gain pour l'intégration d'applications dans un environnement hétérogène en permettant l'aggrégation de modules métiers, donc à l'échelle d'un SI. A l'échelle intra-applicatif, je doute que le jeu en vaille la chandelle, vu la complexité de la couche d'abstraction ajoutée (SOAP, WSDL, etc.)... A la limite, il faudrait peut-être envisager l'emploi commun à tous tes éléments (Frontend Web, serveur, clients) de XML-RPC, beaucoup plus léger et qui te masquera la complexité liée à la manipulation des sockets.

Merci GrandFather pour ton avis.

Si d'autres personnes souhaitent partager leur expérience, je suis preneur ;)