Discussion :

[KiLVaiDeN]

Bonjour,

Pour les besoins d'une de mes applications, je souhaiterais utiliser hibernate, car il offre un système de requetage independant des SGBDR. Donc je peux développer mon application sans me soucier des spécificités de chacune des bases de données.

Oui mais voila, je voudrais également que mon application puisse discuter avec une base de données uniquement accessible en PHP par exemple, cela pour des raisons de sécurité ( je n'ai pas envie que tout le monde se connecte directement avec mon appli à la base de données ).

Donc dans le principe, je voudrais faire quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
// Code aller
Mon appli ---communique en HTTP--> (une page php) ---requête---> SGBDR
 
// Code retour
SGBDR ---résultat---> (une page php) ---communique en HTTP---> Mon appli

Donc mon but est d'utiliser hibernate pour me produire le code SQL qui va bien, transférer ce code SQL à ma page php, qui elle se chargera de l'executer sur le SGBDR, et de retourner les résultats.

Hors, bien que je sache comment communiquer avec le protocole HTTP avec ma page PHP ( ce n'est qu'un exemple, il faudrait aussi que ça fonctionne sous d'autres types de serveurs d'applications ) je ne sais pas si je peux me servir d'hibernate pour uniquement créer la requête, et utiliser hibernate pour récuperer le flux HTTP venant de ma page PHP contenant les résultats... Je ne sais pas non plus comment "formatter" le resultat pour qu'hibernate le comprenne et l'interprète..

Avez-vous une piste à ce sujet ?

Merci

PS : voici un lien vers ces mêmes questions que j'ai posé sur le forum hibernate, au cas où ce ne soit pas clair en français

[dlemoing]

Juste une question comme ca...ton appli, c'est une webapp ou une application type client lourd ?
Si c'est une appli web, je vois pas pourquoi tu t'embettes.
Si c'est un client lourd, pourquoi ne pas tout faire sous ton serveur d'appli java et rendre tes services disponibles en utilisant la techno de ton choix (Web Services, RMI, Burlap, Hessian...). En utilisant les interfaces des services depuis ton code client, tu ignoreras tout de la base de données (gestion au niveau serveur). Tu utiliseras les interfaces et des DTO (ou un domain model serializable) pour communiquer entre ta couche cliente et ta couche serveur.
Je trouve ton choix assez "exotique" mais peut-être y a t'il une autre raison ?

[KiLVaiDeN]

Il s'agit d'une application client lourd, mais qui doit permettre à quelqu'un de l'installer sur un serveur d'application de n'importe quel type ( à terme ).

Par exemple, il suffirait d'installer quelques pages PHP sur un compte PHP/MySQL, de lancer mon outil client lourd d'administration et de fournir cette page en url puis les données relatives à la base de données ( adresse de connection, login, pass ), puis grâce à ca, il y aurait une "installation" des tables necessaires, et quelqu'un utilisant l'outil client lourd de consultation pourrait utiliser l'application.

Il y a en fait deux outils différent, sachant que celui de visualisation ne doit connaitre uniquement QUE l'url ( par exemple http://unsite.com/page.php ) et un login/password DIFFERENT de ceux utiles pour se connecter à la base de données, en fait ces identifiants seraient dans une des tables de la base

Le but ? Une application qui utilise un serveur relais, et qui soit suffisament sûre pour qu'aucun petit malin ne s'amuse à "hacker" la base, en envoyant des requêtes bidons, en modifiant les fichiers class par exemple. Mais surtout de rendre la base de données innaccessible directement au travers de mon appli client lourd, tout en utilisant un serveur de type quelconque ( php, asp, coldfusion, autres.. )

[mauvais_karma]

pourquoi ne pas distribuer tous les traitements de ton client lourd sur un serveru d'application
le client lourd se contente alors d'afficher et de mettre en forme les résultats, de la meme manière qu'un client léger.

Je l'utilise actuelemtn sur une appli:

Client lourd(swing/ .NET) ou client léger (jsp, struts...) <-------->Server(pool de connexion) <---> services <----> base de donnée

les 2 clients ne voient pas la bd mais seulement des services

[dlemoing]

pourquoi ne pas distribuer tous les traitements de ton client lourd sur un serveru d'application
le client lourd se contente alors d'afficher et de mettre en forme les résultats, de la meme manière qu'un client léger.

Je l'utilise actuelemtn sur une appli:

Client lourd(swing/ .NET) ou client léger (jsp, struts...) <-------->Server(pool de connexion) <---> services <----> base de donnée

les 2 clients ne voient pas la bd mais seulement des services

En gros, c'est ce que je disais plus haut.

[KiLVaiDeN]

Je ne veux pas faire les traitements sur un serveur d'application, pour la simple raison que j'ai envie de proposer à l'utilisateur d'installer mon application sur son propre serveur sans passer par le mien.

Et il faut que ça marche sur un serveur PHP par exemple, ou tout autre type de serveur d'application.

De plus, je ne compte pas coder les traitements dans tous les langages de serveurs d'application disponibles ( le but est de faire une application robuste et évolutive, donc multiplier les langages de deploiement n'est pas une bonne solution ).

Finalement, le but de mon application, est de déchargé le serveur au maximum, pour permettre une charge minimale. Idéalement donc, le serveur n'aura qu'un traitement minime de vérification d'identification et d'encodage des données reçues par la base de données, et ce sera mon application client lourd de type "visualisation" qui se chargera d'exploiter ces données.

[KiLVaiDeN]

Je n'ai toujours pas de piste sérieuse, mis à part "implémenter la classe java.sql.Connection"... Personne n'a une idée ?

[trungsi]

Ca peut être une piste :

client -------> http (requet sql) -----> serveur -------> bdd
client <------- http (xml) <------- serveur (resultSet vers xml) <----- bdd

[KiLVaiDeN]

Oui j'avais pensé à quelque chose en XML, mais est-ce qu'hibernate saurait l'interpreter ? Je n'ai jamais creusé la question

Merci pour l'aide en tout cas j'attend encore l'aide d'autres personnes, si ils ont des pistes ou (par une chance incroyable) des exemples de mécanisme similaire