Questions à propos de Java

Version imprimable

13/12/2007, 23h08
Pgs

Questions à propos de Java

Bonjour,

Je développe depuis plusieurs années (lentement mais surement) une application métier.

a) J'ai commencé par C++ attaquant Mysql en local via l'API C
b) Je suis ensuite passé à php/mysql sur le web.
c) Je ressens le besoin, tout en restant sur le net, de revenir à une application cliente un peu plus performante qu'un simple browser web.

Je me permets de vous poser plusieurs questions :
a) un client développé en java ou c++ s'exécutant en local et manipulant des données distantes Mysql via l'API C ou un connecteur J vous semble t'il aujourd'hui une solution pertinente ?
b) je voudrais protéger mon programme. J'ai entendu dire qu'il était possible de faire un ".exe" à partir de code JAVA. Est ce vrai ? Celà fonctionnerait il avec du code JAVA utilisant le connector/J et générant des états en pdf ?
c) est ce que je me pose les bonnes questions ou bien suis-je à côté de la plaque ?

Merci pour toute aide : je dois faire un choix : le bon serait le mieux !

Philippe
14/12/2007, 10h07
gifffftane

Java me parait un excellent choix TECHNIQUE, et je ne pense pas que ce soit ici qu'on te dira le contraire.

Par rapport à tes questions :

- les clients lourds, mi-lourds, riches, légers, super-légers, etc etc etc etc, sont tous des solutions pertinentes dès l'instant qu'il est pertinent pour l'utilisateur. Après, pour ce qui s'agit de la technique... L'avantage non négligeable de Java est que tu peux réaliser toutes ces sortes de clients en Java, et même le serveur.

- pour protéger ton programme, la transformation en .exe est une mauvaise piste. Préfère l'obfuscation.

- si tu te poses les bonnes questions ?... oui, si, par ailleurs, tu réponds à une évolution utile à l'utilisateur (et on ne rit pas).
14/12/2007, 10h18
Pgs

Merci pour ces éléments
14/12/2007, 10h24
CyberChouan

Citation:

Envoyé par Pgs

a) un client développé en java ou c++ s'exécutant en local et manipulant des données distantes Mysql via l'API C ou un connecteur J vous semble t'il aujourd'hui une solution pertinente ?

Lorsque l'on développe en java, on utilise plutôt un programme client/serveur (en utilisant RMI par exemple), la partie serveur du programme se chargeant de la communication avec la base de donnée.

Pour aller plus loin dans la "mode", les clients/serveurs lourds ont tendance à être remplacés par des applications web (J2EE, .NET, etc.)

Donc ta solution de client attanquant directement une base de données ne paraît plus "pertinente", au vu des technologies "à la mode". Maintenant, pour une toute petite structure, en intranet, ça peut être une solution.
Par contre, dès lors que tu passes par le réseau internet, c'est très déconseillé point de vue sécurité, car tu laisses ouvert à l'extérieur un accès à une base de données. Enfin, si tu comptes sur les hébergeurs pour te fournir une base MySQL distante, c'est compromis d'avance... la quasi-totalité des hébergeurs n'autorisent la connexion aux bases QUE depuis leurs serveurs.

Citation:

Envoyé par Pgs

b) je voudrais protéger mon programme. J'ai entendu dire qu'il était possible de faire un ".exe" à partir de code JAVA. Est ce vrai ? Celà fonctionnerait il avec du code JAVA utilisant le connector/J et générant des états en pdf ?

Oui c'est possible mais déconseillé. En transformant un programme java en exécutable, on perd en portabilité pour un gain quasi nul par rapport à un jar.
Pour la protection du code en java, on utilise généralement des obfuscateurs.

Citation:

Envoyé par Pgs

c) est ce que je me pose les bonnes questions ou bien suis-je à côté de la plaque ?

Ca dépend des réponses que tu veux.......

[EDIT] Grilled... ça m'apprendra à laisser mes réponses en attente et à vouloir travailler au lieu de poster :mouarf:
14/12/2007, 10h36
fr1man

@CyberChouan

Je suis assez d'accord avec toi, mais je modererais légèrement tes propos.
Quand tu parles de problèmes de sécurité, en théorie, tu as raison.
Maintenant, il faut déjà voir la criticité des données présentes dans la base.
Ensuite, on peut filtrer les connexions entrantes pour limiter les risques.
Et enfin, même s'il peut y avoir des risques, je ne pense pas que le premier venu soit capable d'intercepter les trames TCP pour aller pirater la base de données. Il n'y a pas de hackers ou autres emmerdeurs compétents à chaque coin de rue, ou derrière chaque PC.

EDIT: Tout ça pour dire, que du coup, si on a pas trop de contraintes de sécurité absolue (encore que ça n'existe pas), le client Java qui se connecte directement à la base, peut-être une bonne idée. On evitera ainsi de développer une partie serveur, et selon le choix, d'avoir à installler, configurer, maintenir un serveur d'application.
15/12/2007, 09h41
Pgs

Mon application tourne actuellement en php/mysql sur un serveur hébergé. Effectivement, il est impossible de se connecter aux bases à partir de l'extérieur.

C'est pourquoi je viens de louer, en parallèle, un serveur dédié. Je viens de tester la connection en https via l'API C de mysql : c'est tout bon.

Si j'ai bien compris vos infos, les différentes solutions s'offrant à moi sont :
- le client Java qui se connecte directement à la base,
- java avec l'api rmi,
- l'application web en j2EE.

C'est ça ?

Je rajouterai que :
- mon application n'est pas en intranet mais sur internet,
- les données que je vais manipuler ne sont pas hypercritiques, mais quand même,
- je n'ai aucune expérience dans la gestion d'un serveur (mais j'aime apprendre).

Pour la solution "client Java qui se connecte directement à la base", j'ai l'impression qu'il me suffit de passer de C++ à JAVA (jouable, non ?).

Pour les deux autres solutions :
- sont elles "compatible" avec mon serveur dédié, préinstallé par l'hébergeur avec gentoo etc. ?
- sont elles complexes à mettre en oeuvre (j'ai entendu dire que JAVA côté serveur était trop lourd pour les petits projets) ?

Merci encore pour toutes vos infos.

Philippe
15/12/2007, 11h00
gifffftane

Citation:

Envoyé par Pgs

Mon application tourne actuellement en php/mysql sur un serveur hébergé. Effectivement, il est impossible de se connecter aux bases à partir de l'extérieur.

C'est pourquoi je viens de louer, en parallèle, un serveur dédié. Je viens de tester la connection en https via l'API C de mysql : c'est tout bon.

Si j'ai bien compris vos infos, les différentes solutions s'offrant à moi sont :
- le client Java qui se connecte directement à la base,
- java avec l'api rmi,
- l'application web en j2EE.

C'est ça ?

Oui.

Citation:

Envoyé par Pgs

Je rajouterai que :
- mon application n'est pas en intranet mais sur internet,

Alors je pense que la meilleure solution est un JEE coté serveur. Coté client, tu gardes le choix entre les différente sortes de clients, mais t'oblige à un dialogue HTTP avec le serveur. Sur internet, le dialogue HTTP n'est pas le plus mauvais...

Citation:

Envoyé par Pgs

- les données que je vais manipuler ne sont pas hypercritiques, mais quand même,
- je n'ai aucune expérience dans la gestion d'un serveur (mais j'aime apprendre).

Pour la solution "client Java qui se connecte directement à la base", j'ai l'impression qu'il me suffit de passer de C++ à JAVA (jouable, non ?).

Techniquement cela ne pose aucun problème, mais pratiquement c'est semé d'embûches pour ce qui concerne la connexion directe à la base.

Citation:

Envoyé par Pgs

Pour les deux autres solutions :
- sont elles "compatible" avec mon serveur dédié, préinstallé par l'hébergeur avec gentoo etc. ?
- sont elles complexes à mettre en oeuvre (j'ai entendu dire que JAVA côté serveur était trop lourd pour les petits projets) ?

Une solution type servlets seule, ou JSP très simple n'est pas plus lourde que d'autres.

Les petits projets s'accomodent très bien de pouvoir écrire serveur, client, base de données, etc, dans un seul et même langage.

Les occupations mémoires, temps de réaction, etc, sont parfaitement corrects sur un PC de supermarché. Pour les PC de spécialistes hébergeurs hakers, je ne sais pas.
15/12/2007, 12h57
Pgs

Merci.

Si j'ai bien compris, tu me conseilles la solution JEE côté serveur.

Je vais creuser dans cette voie.

Merci encore et à bientôt.