Client Lourd + Serveur + MySQL

Bonjour à tous,
Je sollicite votre expérience face à un pb que je me pose actuellement.
D'un côté j'ai un client lourd (type webstart) qui crée et manipule des données qui sont ensuite stockées dans une BD MySQL que j'attaque direct avec JDBC.
Jusqu'ici tout va bien sauf que je voudrais passer du 2-tiers au 3-tiers.
Donc sur la base d'un serveur Apache, quelle techno me conseilleriez vous d'utiliser de manière à faire communiquer mon client avec la BD sans l'attaquer en frontal ?
Je n'ai pas besoin de faire des choses extraordinaires côté serveur vu que mon client lourd s'occupe de tous les traitements à faire sur les données.
C'est juste un problème de communication quoi.
Je sais pas si je suis bien clair...
Vos avis ?

puisque, apparement, tu as actuellement plein de méthode dans ton client lourd qui retoourne de données de la db, le plus simple (avec le peu d'information que tu fournis) serait d'utiliser un webservice, qui va s'insérer dans ces appel. Les librairies pour webservice aujourd'hui peuvent presque automatiquement exporter sous forme de webservice un ensemble de fonciton existantes et mapper des webservice sur des beans coté client. Ce devrait donc être la solution qui demande le moins de travail.

Merci de ta réponse.
J'ai pas tout compris ceci dit.
Donc je vais détailler un peu plus.
Mon client lourd permet soit d'interroger la BD, d'afficher les résultats des requêtes sous formes diverses et de modifier les données reçues.
Soit, il permet à l'utilisateur de créer de nouvelles données qui seront enregistrées dans la BD. Ces données sont stockées dans une dizaine de tables, rien de révolutionnaire quoi. Ces tables ne sont utilisées que part mon client, pas d'interface web ou autre.
Jusqu'ici j'avais un serveur MySQL que j'attaquais en direct mais c'est pas super comme solution.
Donc du coup, mon serveur MySQL n'est accessible que depuis localhost, et il faut que je rajoute le tiers du milieu pour faire communiquer mon client avec la BD.
J'ai pas envie de sortir l'artillerie lourde juste pour ça et si je comprends bien ta réponse tu me suggères une solution de type : Apache + Tomcat + Axis c'est ça ?

Bonjour,

tu souhaites faire évoluer ton architecture applicative de 2-tiers ( client lourd + serveur bdd ) vers un 3-tiers.
Quels sont les 3 tiers que tu envisages?
- l'ancien client lourd dépouillé de sa logique métier? Ou Client Web?
- Serveur intermediaire contenant la logique métier de l'ancien client lourd? Ou juste un relais de communication vers la bdd?
- La bdd

Est-ce suite à une limitation de l'architecture actuelle que tu veuilles entreprendre ce changement? En comprenant mieux la motivation de cette évolution, les solutions seront plus précises.

Cordialement,

Salut,
Alors mais 3-tiers seraient :
- mon client lourd (adapté pour la cause)
- un relais de communication vers la bd
- la bd

En fait je veux effectuer ce changement dans la mesure où le serveur MySQL héberge d'autres bases utilisées par d'autres applis. Dans un soucis de sécurité je souhaite le placer derrière une interface de connexion côté serveur, ce qui pourrait me permettre également de pooler les connections ce qui n'est pas possible avec mon archi actuelle (mon client peut être utilisé par plusieurs users simultanément évidemment).

Vraiment désolé si je suis pas clair. Si vous voulez je suis vraiment dans un esprit RIA où le client peut fonctionner également en mode déconnecté, dans ce cas j'utilise SQLite en local.
Voilà.

Je précise encore parce que je suis pas tout à fait au clair.
En fait, il ne s'agit pas d'un relais de connexion pur et dur, je ne veux pas pouvoir balancer n'importe quelle requête sur le serveur MySQL, je veux juste une couche de quelques chose côté serveur qui effectue les requêtes que je fais actuellement en direct et qui balance les résultats à mon client.

Salut,
Une solution possible est d'utiliser le remoting (plus simple AMHA que les WS, d'autant plus que le serveur et le client sont en Java).

Je parle ici d'une telle architecture : http://djo-mos.developpez.com/tutori...oting-hessian/

En gros, dans ton cas, tu peux coder la couche DAO/Service côté serveur et les exposer pour me remoting.
Le client se contente de les invoquer, toujours via remoting

Ah tiens j'étais justement en train de regarder cette solution et ça m'avait l'air de correspondre assez bien à mes besoins. Je crois que je vais partir là dessus, sauf rebondissement de dernière minute.
Merci pour vos réponses.

je connais pas hessian, mais si c'est comme le RMI, travailler avec des objet distant qui subissent une joyeuse série de sérialisations désérialisation en veux tu en voilà en utilisant du code qui était au départ prévu en supposant que les objets étaient locaux... c'est la cata coté performances ^^

D'après les benchmarks, Hessian est quand même beaucoup plus performant que RMI.
Voir ici : http://daniel.gredler.net/2008/01/07...ol-benchmarks/
Je vais faire quand même des tests.

Citation:

---

Envoyé par tchize_

je connais pas hessian, mais si c'est comme le RMI, travailler avec des objet distant qui subissent une joyeuse série de sérialisations désérialisation en veux tu en voilà en utilisant du code qui était au départ prévu en supposant que les objets étaient locaux... c'est la cata coté performances ^^

---

Bah pour les webservices, il y'aura toujours de la sérialisation, vers de l'xml mais c'est de la sérialisation. Je ne vois pas pourquoi ce serait plus rapide avec les WebServices qu'avec la sérialisation type RMI ou Hessian ?

Citation:

---

Envoyé par MagicMagnet

D'après les benchmarks, Hessian est quand même beaucoup plus performant que RMI.
Voir ici : http://daniel.gredler.net/2008/01/07...ol-benchmarks/
Je vais faire quand même des tests.

---

Ouep, Hessian est réputé être léger et rapide.
Toutefois, il faut savoir qu'il gère pas tous les cas de figures/type de données.

Entre autre, il cohabite très très mal avec les proxies, comme pour Hibernate par exemple.

Personnelement, j'utilise le HttpInvoker de Spring (qui utilise la sérialisation Java et le transport Http) et j'en suis plus que satisfait.

Citation:

---

Envoyé par djo.mos

Bah pour les webservices, il y'aura toujours de la sérialisation, vers de l'xml mais c'est de la sérialisation. Je ne vois pas pourquoi ce serait plus rapide avec les WebServices qu'avec la sérialisation type RMI ou Hessian ?

---

Disons qu'avec des webservice, comme tu travaille plus sur un modèle que requete / réponse, tu as tendance à bien revoir ton code entre ton tiers client et ton tiers d'accès. Alors qu'avec du RMI ou similaire, tu as tendance à vite tomber dans la pratique du "je rempalce tout mes objet dao par une surcouche RMI vite fait", et si tes objets fesaient des aller/retours fréquent entre ta DAO et ton interface graphique (peu importe les raisons), il continuent à fait la même chose sur la couche réseau. Quand 2 liste de 300 objets font 5 aller/retour juste pour afficher un résultat de filtrage sur une interface graphique, tu comprend ta douleur :D

Intrinsèquement, les webservices sont pas plus rapide que du RMI ou du corba (loin de là). Le problème se situe plus au niveau des pratiques. J'ai l'impression qu'avec des webservice, quand tu code, t'es plus conscient de quand tu traverse la barrière réseau qu'avec du RMI, où tu sais même parfois pas de quel coté se trouve l'objet que tu manipule :D

Bonjour à tous,

moi aussi j'essaye aussi de passer d'une archi 2 tiers à une autre 3 tiers mais je veux toujours garder les clients lourd pour acceder à la BD.

alors que me conseillez vous comme serveur(même si c'est un serveur comercial) et est-ce que c'est possible de faire la migration sans passer par une application web?

merci pour vos reponses et je reste a votre disposition pour t'amples informations

la pluspart des serveur étant relativement légérs, je pense pas qu'on puisse faire de recommandation, c'est plus ton code et tes librairies qui feront les performance du truc.
Bien sur, tu peux toujours te passer d'une serveur J2EE, si tu estime que c'est trop lourd pour ton besoin.

je vous remercie pour votre reponse,donc effectivemen,un serveur J2EE est tres lourd pour mes besoins car les clients font des chargements des planning depuis un BD et ceci prend vraiment beaucoup de temps.
mais comme vous pouvez pas me faire des recommendations sur le type de serveur à implémenter,je voudrais juste vous demandez de me citer quelques serveur que je peux utiliser puis c'est à moi de faire des recherches.

Encore mille merci

je comprend pas, si vous ne voulez pas de serveur J2EE, je vois pas ce que je pourrais vous recommander d'autre qu'utiliser RMI ou les Socket directement, comme déjà mentionné, je pense dans ce fil

une autre question,si je doit mettre en place un serveur J2EE,est-ce que je doit changer le code source de mon application actuelle oui juste je doit rederiger les requettes SQL qui ermettent aux clients lourds d'acceder à la BD par le serveur J2EE?

c'est pas la meme architecture que des clients lourds, t'aura du travail à refaire. Y a pas de méthode magique qui permet de passer d'un client lourd qui fait ses requetes sql directement à une application serveur. Si c'est bien codé, une grande partie de ton buisness sera récupérable, les interfaces, elles, devront vraisemblalblement être revues intégralement pour tenir compte des spécifités du serveur. (Latence de réponse, besoin de faire du caching des données, aspect transactionnel, etc)

je vous remercie pour vos reponses et bonne fin de journée