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
Applet et requetes SQL
Salut,
Je me pose une question en ce vendredi matin. Si on developpe une applet en Java et qu'on veut utiliser une base de données, existe t il une couche au dessus de jdbc pour acceder à la base sans embarquer directement les requetes (et pire, le login/password pour la connexion à la BDD) ?
Merci
Je connais les procédures stockées (au niveau BDD), mais je n'ai pas l'impression que ça soit réellement ce que tu cherches.
Bonjour,
Le plus propre c'est une couche applicative. Il y a pas mal de solutions pour répondre à ce besoin, tels que: Servlet, WebServices, script cgi, ...Envoyé par hwoarang
Merci pour vos reponses.
Pour acceder à la procedure stockée, il faut le login/mdp de la base donc c'est pas suffisant.
Et c'est quoi la solution la plus efficace pour des transferts important (ce qui exclu les passerelles genre xml ou autre qui multiplie la quantité de données transférées) ?
Pour faire simple le couple login/mdp doit de toute façon être stocké quelque part.
Dans le cas présent il faut se servir d'un serveur intermédiare (donner un accès direct à la base de données à l'applet serait une hérésie au niveau sécurité) qui sera le seul à avoir accès à la base de données et dont le rôle sera d'effectuer les requêtes et de les relayer aux différentes applets. Ce serveur sera le seul à connaître les login/mdp (enfin il est préférable même de passer par un mécanisme à base de datasources, où le mot de passe est uniquement connu par le conteneur web ou le serveur d'application). C'est lui qui aura la charge de faire les requêtes vis à vis de la base, à toi de coir via quelle API (du JDBC pur, du JPA ou tout autre ORM...)
Ensuite pour les échanges entre client (ton applet) et serveur, c'est à toi de définir les moyens d'échange (WebServices, RMI, EJB, envoi de binaire sur des sockets, les solutions de manquent pas).
C'est justement ca ma question. N'aillant pas essayé toutes ces methodes, je me tourne vers ceux qui l'ont peut etre fait pour avoir un retour sur une methode efficace dans le cas de transferts de données important (en quantité). Donc, qu'est ce qui peut etre efficace?
Qu'appelles tu quantité? Volume? Nombre?
Disons plus de 10000 lignes avec une grosse 30aine de colonnes (certaines contenant du texte, d'autres des int)
solution jdbc
Bonjour, si j'ai bien compris tu cherche à accéder aux données hors de ton applet?
Si c'est bien le cas, je te conseille de faire une petite couche de jdbc, qui créé une instance de Connection et fait les requetes dont tu as besoin, les tuto pour savoir comment faire sont très simple à trouver et à réaliser.
Pour externaliser les paramètre de connexion, tu peut créer un fichier de propriété que tu met dans ton classpath, qui contiendra par exemple login/password, nom du driver jdbc, schéma, tables, tous ce que tu peut avoir besoin de changer. Ce qui te permet de modifier à n'importe quel moment.
Tu pourrais même écrire une requête dans ce fichier en limitant le nombre de ligne pour commencer, ou juste les critère de recherche, enfin les possibilités sont nombreuses et pas très compliqué à mettre en place.
Par contre je me pose la question concernant, ton nombre de ligne. Si c'est une applet, tu va pas charger les 10000 lignes dans une seule page, donc pour optimiser le temps de réponse de tes requêtes, tu peut faire de la pagination (de 100 ou 200 lignes par exemple c'est déjà énorme), donc charger au fur et à mesure des besoins de l'affichage, tout en gardait en cache applicatif ou en session les données déjà chargées.
Voilà j'espère que ça répond à ta question, n'hésite pas si des choses ne sont pas clair.
en général, vous n'avez pas besoin de 10.000 lignes en mémoire. Vous faites une requete sur la db et vous sorter une centaine de lignes à la fois (plus est inutile, puisque vous n'aurez pas la place à l'écran pour l'afficher).
Ce qui limite déjà le nombre de données. Ensuite, coté techno, un api basée sur http est la plus facile à mettre en place (ça passe le nat, les firewall et tout contrairement au sockets binaires).
L'appli a laquelle je pense fait des requetes non pas pour les afficher mais c'est plutot des composantes graphiques qui seraient affichés à l'ecran. Mais peu importe. Je pense que je n'ai pas été assez clair dans ma question.
Ce que je voudrais savoir, c'est s'il existe une API/framework/librairie/n'importe quoi qui permet de recuperer un grand nombre de données d'une base de données d'une maniere efficace (c'est à dire pas d'interface xml). Je ne cherche pas un moyen de contournement (pagination ou autre) qui permettrait de diminuer la quantité de données.
C'est plus une question theorique que vraiment pratique. Mais plutot que de perdre 15 jours à tester 50 framework pour me rendre compte qu'ils ne correspondent pas à ce que je cherche, je prefere demander une orientation.
Donc pour resumer, je voudrais quelque chose qui soit aussi proche de l'efficacité de la base de données (en terme de quantité de données envoyées) que possible. Pour imager, si je regarde la quantité de données que mon service (si c'est un service) recupere de la base (j'imagine compressées) soit quasiment egale à la quantité de données qui sera envoyée par le service lui meme. Pour etre plus precis, je cherche juste un tuyau qui me permette de ne pas embarquer le login/mot de passe de la base dans l'applet mais qui penalise le moins possible les performances.
en général on prétraite sur le serveur avant d'envoyer au client:
Exemple:
le client "j'ai besoin de toutes factures de ce dernier mois"
le serveur intermédiaire "J'ai 2500 facture en stock. Voilà les 50 premières"
Le client "ok, ben maintenant j'ai besoin des facture 60 à 100" (parce que mon user a fait défilé"
puis
"J'ai besoin des détails de la facture Machin".
Le serveur, lui aura la logique suivante avec la db
"select * from user where user = .... password = ...."
"select count ......"
"select ...... inner join ...... limit 0,50 order by ....."
Si vous ne voulez pas faire de traitement intermédiaire, votre problème, c'est que l'applet aura tous les droit sur la db, elle aura juste à bidouiller les requetes. Le boulot du serveur intermédiaire c'est de digérer les données (pour limiter les transfert) d'assurer la securité (machin a pas le droit d'éditer une facture, bidule à pas le droit de voir les factures de client X).
Les technique basée sur HTTP, certe augmentent un peu la consommation en ajoutant des headers autout du bazard, mais justement, si vous avez un paquet de 2M de données à transférer, c'est pas 1k de headers autour qui va poser problème.
Le EJB, leur problème, c'est qu'il sont dépendant de ton serveur EJB, chacun ayant son propre protocole, et coté perfs, faut tester. Des apis simples basées sur http seraient, pour moi, la solution la plus simple à mettre en oeuvre. J'ai tendance à éviter le SOAP et cie qui sont lourd à mettre en oeuvre. Si vous avez besoin de récupérer, par exemple, une image à haute définition (imaginons un système médical où faut transférer une radio vers l'applet), rien ne vous empeche d'envoyer une réponse binaire par http
Mouais, dans mon cas, il s'agit d'une appli generique donc qui a besoin de recevoir pas mal d'infos du serveur (pas une simple table a remplir). Et j'ai de plus en plus l'impression qu'il n'y a pas de solution adaptée à mon probleme autre que de tapper directement dans la BDD...
ne jamais ouvrir une base de données aux accès distants. Déjà dans 99% des cas tu va etre confronté à un refus catégorique des DBA de laisser autre chose que le réseau local s'y connecter. Ensuite tu va etre obligé de mettre dans la DB autant de comptes que tu n'aura d'utilisateurs, avec les sécurités qui vont avec. Enfin faudra s'assurer que la DB gère des protocole empechant les man in the middle attack. Je connais pas beaucoup de DB qui fournissent ce genre de service.
En meme temps, si pour m'en proteger, je dois passer par un protocol xml qui va multiplier les quantitées de données envoyées, c'est pas terrible non plus. J'ai le choix entre la peste et le cholera...
Tu peux passer par autre format plus concis que le XML, genre JSON ou tout autre de ton cru. Vu que de toute façon tu implémentes le client et le serveur, tu as le choix.
Oui m'enfin tant qu'à faire, j'aurais aimé passer par un "standard" ce qui m'aurait évité de réinventer la roue et éventuellement une communication optimisée. Pour ceux qui seraient tenté de proposer SOAP ou ses amis, je répondrais que dans "optimisé", j'entends "qui ne multiplie pas par 4 ou 5 les données transmises"
JSON ne serait-il pas un standard par le plus grand des hasards?
C'est du a la verbosité du texte. Tu peux ramener ça à une quantité de l'ordre de la taille de tes données en faisant bêtement de la compression sur ton flux (zip, bzip2, etc), ce qui est standard en HTTP. Seulement je serais plus fan du JSON que du XML, les outils XML on en général beaucoup de rigueur, ce qui peux impacter les performance.Oui m'enfin tant qu'à faire, j'aurais aimé passer par un "standard" ce qui m'aurait évité de réinventer la roue et éventuellement une communication optimisée. Pour ceux qui seraient tenté de proposer SOAP ou ses amis, je répondrais que dans "optimisé", j'entends "qui ne multiplie pas par 4 ou 5 les données transmises"
Si, mais il rentre dans la categorie "qui multiplie les données transmises" puisqu'au format texte
Mais bon, c'est peut etre quand meme le mieux avec un petit coup de zip au passage comme suggéré par tchize. Je regarderais à l'occasion l'impact sur les performances.
Au passage, il n'existerait pas une classe qui gererait les communication entre un webservice (par exemple) et une applet avec un coup de zip ? Ou bien je vais devoir me farcir une socket et tout faire à la main ?
Merci à vous dans tous les cas
Répondre avec citation
Partager