Version imprimable
Bonjour,
Je dois developper une application client-server et je ne sais pas encore comment je vais faire pour qu'ils communiquent ensemble. J'ai deja entendu bcp de gens parler de WCF , Web Service, RPC, .Net Remoting, Socket etc... est ce que qqun peut m'expliquer la difference et comment je dois choisir entre tout ca ce qui convient le mieux a mon application?
Merci d'avance.
Détaille un peu plus ce que tu dois faire.
Le serveur doit generer des rapports a partir d'une BD et de les garder dans sa propre BD. Les clients ne se connectent que depuis le reseau interne.
Ils peuvent creer des "schedule report" pour que les rapports soient generes automatiquement (ex. generer un rapport tout les premiers du mois). Et chaque client peut modifier/supprimer/consulter les "schedule" ou downloader les rapports generes.
Merci
Ok.
Comment les clients créent leur rapport? via une page web?
Je crois que je me suis mal explique: Les Clients a travers leur GUI envoie au serveur les details pour planifier la generation de rapport (ex. le client demande la generation d’un rapport tout les 1er du mois etc...).
Je ne sais pas si j’ai bien compris ta question mais je veux developper une GUI cliente qui se connecte au serveur (et donc je crois que la reponse a ta question est non).
Bonjour
Est ce que tu pourrais nous montrer ce que tu as deja fais? Cela nous permettrait de mieux comprendre ce que tu voudrais faire.
Merci.
Bonne continuation sur DVP.
Je pense avoir compris ce que tu veux faire et l'une des possibilites est la connexion des clients a l'intranet de ton entreprise puis via une page web l'interaction avec ton serveur.
Enfaîte j’ai pas encore commencée a coder, pour l’instant je fais la conception et la spec technique de ce que je vais développer.
L’application (le Serveur) doit générer des rapports automatiquement et les Clients doivent pouvoir télécharger ces rapports. Les Clients sont tous internes, donc ils sont tous connectes a l’intranet.
Pour planifier quand le Serveur généra un rapport et ce qu’il contient, les Clients doivent pouvoir créer des « schedules ». Un schedule est définit par une période (ex. toutes les 2 semaines, tous les mois etc..), et un ensemble de paramètres qui définissent ce qu’il y aura dans le rapport génèré.
Considérant tout cela, j’ai pensé développer une application client-serveur qui n’est pas web based c'est-à-dire qu’il faudra installer sur les machines clientes le GUI client et coté serveur ça serait un process qui tourne tant qu’ on a besoin du serveur.
Enfaîte ce que je voulais savoir, c’est vu la description de l’application, quelle serait la meilleure méthode de communication pour faire communiquer le Client et Serveur.
Je ne sais pas si mon explication est plus claire qu'avant ou pas... ;)
Bon cette fois c'est clair :D
Pour moi le web service te serait tres utile. Il te "suffit" de le creer puis de le referencer dans ton GUI et de faire appel a ces methodes.
Tu peux me dire pkoi tu utiliserais les Web Services plutôt que du Remoting ?
Juste pour la simplicité ou il y a d'autres raisons?
Merci
En fait je te parle de ce que je connais. Et je ne me suis jamais servi du remoting. :aie:
Par contre a premiere vue, je te deconseille les sockets qui ne me semblent pas adapte a ce que tu veux faire.
Ok merci pour tes conseilles! :)
Disons plutôt que c'est très bas niveau ; pour une utilisation simple, autant utiliser des librairies qui t'encapsulent mieux toutes les basses couches, comme remoting, WCF ou les webservices. Après, le choix dépend de la volumétrie, des outils à disposition (WCF n'est dispo qu'avec les framework >= 3), le besoin d'être interopérable avec d'autres univers (java ou ++ au hasard :)), etc...Citation:
Envoyé par Quatre_Couleurs
Exactement.
Et c'est quoi les + et - de Remoting par rapport aux Web Services? :)
Merci encore.
Pour une question aussi générale, je suis un peu tenté de t'emmener aller voir notre ami google :) Parce comme je le disais :Citation:
Envoyé par vigiElf
Citation:
Envoyé par moi-même y'a 10 minutes
Bonjour vigiElf,
La performance (rapidité) est associée à la technologie que tu va utiliser, au dépend d'un nombre plus important de ligne de code à écrire.
On parle de très bas niveau pour les sockets et de bas niveau pour la class dérivé tcpclient tcplistener.
Ensuite tu as du haut niveau avec .net remoting et web service
Puis très haut niveau avec les services WCF.
Plus la technologie est importante, plus le shell est long à effectuer des opérations.
Donc dans ton cas, si c'est une opérations par mois, le wcf suffira. En revanche, si ton client (personne physique)interroge la base de temps en temps, je ne pense pas qu'il soit satisfait d'attendre 3 secondes pour avoir une reponse du serveur!
Je te conseil donc un compromis entre les deux: .net remoting et web service.
Nb: Je suis dans le meme cas que toi depuis un mois, mais pour des raisons de perf, j'ai choisi la class dérivée des sockets: tcpclient et tcplistener.
Malheureusement, personne jusqu'ici n'a été capable de me montrer comment passer une méthode avec évènement du client vers le serveur.
Les seuls exemples sont des messages qu'on fait passer de l'un à l'autre!
Je cherche encore...
Euh, WCF et remoting ne sont pas que des jouets, ils permettent beaucoup plus que ça... Dans mes projets (qui ont rien d'exceptionnel), un serveur remoting prend des centaines de clients, leur balance des notifications, leur ramène des centaines de milliers de records de la base, etc.Citation:
Envoyé par kisscool14
D'autant plus que l'un comme l'autre permettent de basculer simplement d'un mode de communication à l'autre, par un simple paramétrage : http / tcp / ipc, binaire ou pas, compressé ou pas, etc.
Donc comme d'hab : à moins d'avoir des besoins spécifiques, la techno la plus haut niveau est la première vers laquelle se diriger. Surtout quand on est débutant dans le domaine (ce qui est mon cas aussi, hein :))