le vrai probleme du client server pur, c'est que ca ne passe pas un proxy ou un firewall... donc pas possible de passer en extranet.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
le vrai probleme du client server pur, c'est que ca ne passe pas un proxy ou un firewall... donc pas possible de passer en extranet.
Envoyé par lunatix
???? Quel est le rapport avec un proxy ou un firewall.
Le projet que Mathieu veut réaliser c'est d'un côté une application cliente qui veut interroger une base de données distantes faire des ajouts , suppressions , modifs etc....
yop
Salut,
C'est exactement celà! Utiliser une base distante. Après c'est le choix de l'interface qui est délicat
Je commence à pencher sur un client logiciel "lourd" plutôt qu'un navigateur. Cependant mon choix n'est pas encore fait.
Cordialement,
Mathieu
Ce que signalait lunatix c'est qu'une appli pure client lourd-base de données ne pourra pas être déployée en extranet, mais uniquement en intranet.
???? Quel est le rapport avec un proxy ou un firewall.
Le projet que Mathieu veut réaliser c'est d'un côté une application cliente qui veut interroger une base de données distantes faire des ajouts , suppressions , modifs etc....
Par contre, un client lourd<-> serveur <-> base de données sera possible en xyz-tranet, mais, comme je le disais précédemment, il faut faire un peu de prog réseau.
ODBC ne permet pas, à ma connaissance, de faire du clientserveur, mais uniquement du client-DB!
Je pense pas que le client de chat de DVP passe par ODBC pour se connecter au serveur de chat
Re lut,
j'ai un utilisateur sous la main: moi-même
Exemple: hotmail. Je ne me verrais pas accéder à hotmail via un client lourd, j'aurais abandonné depuis longtemps! Je suis prêt à sacrifier un peu d'ergonomie (ne pas avoir une loupiote rouge qui clignote dans la seconde) au bénéfice d'une certaine simplicité de déploiement! Je peux y aller depuis n'importe quelle machine et ça marche!
Cette interface web simple et intuitive me propose toutes les fonctionalités qui répondent à mes besoins.
Un client lourd ne m'apporterait que des complications techniques inutiles (réinstall, mises à jour, config de firewall pour accéder au port xxyy avec les probs de sécurité qui vont avec) juste pour quelques détails visuels.
Il y a bien sûr des applications qui requièrent du client-serveur lourd, comme ICQ, qui est un logiciel de messagerie instantanée, ou n'importe quel jeu 3D actuel (puisque le client web est faible pour la 3D).
Mais enfin, bon, bref, voilà voilà...
Exact. Note qu'en Java et .Net si on utilise des serveurs HTTP (Tomcat...) l'aspect technique de communication entre le client et le serveur du milieu c'est vraiment rien. Ce qui est plus long, c'est de bien séparer du reste le code d'accès à la base (code qui se retrouvera sur le serveur du milieu).Par contre, un client <-> serveur <-> base de données sera possible en xyz-tranet, mais, comme je le disais précédemment, il faut faire un peu de prog réseau.
ODBC ne permet pas, à ma connaissance, de faire du clientserveur, mais uniquement du client-DB!
Je pense pas que le client de chat de DVP passe par ODBC pour se connecter au serveur de chat
On peut très bien faire un client lourd et la liaison au serveur de BD via internet au travers d'un VPN par exemple
Et si on l'appelait, au hasard, "serveur d'application"? Comme ça on aura un terme un peu plus élégant et on saura de quoi on parle par la suite
Alors comme ça c'est sympa, on a pas besoin d'avoir ou de configurer ODBC sur le poste client... mais dites moi, c'est le pied pour l'utilisateur...
Question pour le client lourd-ODBC-DB... que se passe-t-il si un client de la version 1.0 attaque la DB version 6.51?
"Serveur d'application", c'est un bien grand titre pour un petit serveur http qui n'existe que dans un but de sécurité et ne contient pas de code métier.
Ben si c'est géré, c'est géré, si c'est pas géré, c'est pas géréQuestion pour le client lourd-ODBC-DB... que se passe-t-il si un client de la version 1.0 attaque la DB version 6.51?
oui oui, enfin je crois que vous voyez tous ce que je veux dire ! si on fait du web light (avec navigateur) ou epais (avec xul/ java webstart/ autre), on peut facilement faire de l'extranet (port 80 et c'est tout), par contre si on commence a ouvrir des connexions a la base de données, ca se complique lourdement. ( on peut effectivement faire peter le VPN, mais c'est pas si simple quand meme)On peut très bien faire un client lourd et la liaison au serveur de BD via internet au travers d'un VPN par exemple
le top (a mon avis), une couche metier bien decouplée, que l'on utilise dans une application web normale, et que l'on utilise via rpc/soap/autre dans un client epais :-)
bon, ca fait faire deux versions du frontal, mais c'est plutot sympa niveau tecno
+1
Comme ça tout le monde il est content
Salut,
Pour moi, les avantages de l'appli Web :
- niveau ergonomie, les difficultés pour réaliser des fonctionnalités graphiques avancées sont largement contrebalancées par la facilité et la rapidité de prise en main du client Web (qui, aujourd'hui, n'a jamais mis les mains sur un navigateur ?).
- niveau portabilité et déploiement, c'est plus qu'évident (à condition de rester dans les standards, côté client, et open source, côté serveur).
- niveau réseau, on est tout de suite multi-utilisateur et partageable, le tout sur le plus gros WAN possible (le boss peut regarder son appli en vacances sur la plage, avec un PDA et une connexion WIFI ;-)).
- niveau maintenance, en plus du déploiement invisible, le développeur peut prendre directement de chez lui le contrôle de l'appli en production, voir les erreurs dans les mêmes conditions que l'utilisateur, ...
- niveau ouverture et échange de données, on travaille déjà avec des standards reconnus : réseau TCP/IP, données XML (la conversion depuis HTML ou un SGBD est une rigolade), interrogations SQL (à condition de ne pas trop utiliser les formats propriétaires des SGBD).
Bref, j'ai le sentiment qu'il n'y a plus aujourd'hui que les contraintes d'extrême rapidité d'exécution qui feraient encore pencher pour le client lourd (calculs scientifiques ou graphiques 3D par ex.).
je pense aussi que bcp d'appli devarit migrer à des interfaces web ( meme office, surtout office, ils restent qqs besoin client un peu pénible en web, par exemple, une appli qui gere des droits d'acces et programmerait des cartes à puce, ben c'est pas top du tout. De toute facon, coté machine client, il faut le driver etc.. et si on doit piloté "le pilote" de puis l'interface web, c'est moins drole
Ce n'est pas le navigateur qui est utilisé en tant que client, mais ce qu'il contient. Si le contenu n'est pas trop convivial, et fonctionnel, g ne crois pas que la prise en main sera aussi rapide que cela.
D'autre part AJAX commence à rendre les clients Web vraiment riche
Tous ces avantages du client Web que vous avez donnés sont possibles à obtenir avec une architecture client-serveur en utilisant un deploiement Citrix/Terminal server, avec néanmoins comme principal inconvénient le coût des licences c'est tout.
Je suis quand même surpris que personne n'ait évoqué celà depuis!
Perso, je travaille dans les applications scientifiques (logiciel de statistique sur des familles génétiques) avec des temps de calculs relativement long, on utilise des interfaces Web avec la structure suivante :
Affichage, saisie et contrôle des données -> HTML/JavaScript/PHP/(MySQL)
Formatage des données -> PERL/PHP/BASH/(MySQL)
Calcul -> C
Ainsi pour ce qui est présentation, on utilise des techniques qui nous évitent de nous casser la tête, pour formatage idem et pour le calcul on va le plus vite possible.
Le gros problème c'est quand le traitement prend des dizaines de minutes ou des heures, vu que l'on ne peut pas vraiment faire réagir le client, l'ergonomie prend un coup, car il faut que l'utilisateur clique sur "Voir les résultats" de temps à autre, mais ces petits problèmes sont minimes comparés aux avantages face aux clients lourds (Déploiement sur plusieurs postes, les utilisateurs changent de machines suivant la phase du traitement, logiciel évoluant presque mensuellement, accessibilité des outils depuis n'importe où, utilisation du cluster, mix Windows/Linux, pas besoin de descendre un étage quand il y a un problème).
Pour les applications financières, gestion de clients et autres, je ferais en Web aussi, mais j'en ai eu une seule à faire dans ma carrière et je l'avais fais en VisualBasic/Access/Word, c'était joli, mais sans plus.
Le vrai avantage du Web, c'est que tu t'occupes du fonctionnel et tu réalise l'ergonomie ensuite et assez rapidement et simplement (de plus tu peux faire pleins de thèmes très cool avec plein de jeux de couleurs différents
Aujourd'hui AJAX résout ce problème pour les applications Web. Il n'est plus nécessaire que l'utilisateur clique sur "voir les résultats". L'asynchrone est bien géré aujourd'hui avec AJAX, et d'autre technologie propriétaire comme Flash, les applets java etc..
Je l'ai déjà dis les technologies Citrix et Terminal server permettent d'obtenir les même résultats avec les clients lourds. Donc la facilité de déploiement, de maintenance, l'utilisation derrière les pare-feux etc est également possible à obtenir avec un client lourd si on utilise le deploiement Citrix/Terminal Server
Ceci est un problème de conception, et de technlogie de développement utilisée. On peut très bien concevoir l'interface d'un client lourd en utilisant des langages de balise ( comme le HTML pour le client léger). Par exemple en java on peut utiliser SwiXML, ThinLet etc., en Winform XAML, en flash Flex etc..Le vrai avantage du Web, c'est que tu t'occupes du fonctionnel et tu réalise l'ergonomie ensuite et assez rapidement et simplement (de plus tu peux faire pleins de thèmes très cool avec plein de jeux de couleurs différents
Et pourquoi pas un client lourd qui utilise des services web? Il pourra très bien migrer vers une application web si besoin est.
J'ai dû développer une application web pour 12 000 postes. Avant, les utilisateurs avaient une application Cobol IBM : quelque chose de moche et de peu efficace niveau ergonomie.
Après cette expérience de 1 an, je peux te dire une chose : l'ergonomie Web, c'est tout un métier.
Principalement parce qu'il n'y a pas de gestion évènementiel, ou presque pas. Exemples :
- Comment savoir quand l'utilisateur a fermé une fenêtre?
- Comment gérer l'utilisation du bouton Précédent du navigateur correctement, après avoir fait un ajout, l'utilisateur refait "Précédent" sur son navigateur, il pense modifier son ajout, refait l'ajout, se retrouve avec 2 éléments alors qu'il n'en voulait qu'un, bref, des exemples y en aurait à la pelle...
- Pas de gestion de push (màj des infos à partir du serveur sur le poste client)
- etc...
En rapport avec ton application, je te conseil fortement une application lourde, avec si possible une couche métier bien indépendante, en prévision de migration/complément de l'interface.
Les possibilités d'un client lourd sont sans communes mesures avec les possibilitées d'une page web.
La solution client riche peut aussi être envisagée.
La réponse à la question repose principalement sur le déploiement, et les machines cibles.
Bon courage.
Parfaitement d'accord avec vous. Je précise que les clients lourds comportent l'UI, la logique métier et une base de donnée légère ( du genre SQL Server Express, OracleXE etc..) déployés sur le poste client. La BD locale se synchronise avec une BD centrale. Donc il va plus loin que le traditionnel client serveur où la BD n'était pas sur les postes clients.
Les clients Lourds peuvent être "allégés" avec les déploiements Citrix/Terminal server, qui ont des clients pour presque tout type de machines cibles ( PDA, mobile, linux etc..)
Et un mix des 2 ???
Pour notre part, notre application est accessible via un client lourd pour les modifications, l'administration etc..
Et un client léger pour la consultation et la modification simple des informations.
Le tout grâce à plusieurs serveurs d'applications.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager