Développement d'une application client-serveur : .Net ou Java ?

mouillette_1_1 · Mai 17, 2010, 4:07

Bonjour,

Je travaille avec un ami depuis plusieurs mois maintenant à l’élaboration d’un projet de montage de société. Cette société, pour rester dans le secret, a pour objectif de fournir un service de ré-analyse en ligne, dans le domaine de l’imagerie. La cible de ce service, pour rester vague encore une fois, est les industriels. Désolé, je ne peux pas donner de détail. Du coup, vous aurez peut-être du mal à me répondre…

Essayons tout de même. Voilà, comment pourrait fonctionner le système :
–> poste de travail du client : ordinateur du client, se connecte au serveur de gestion client et données pour créer un compte, envoyer des données à ré-analyser, récupérer les résultats
–> serveur de gestion client et données : reçoit les demandes du client, envoie les données au serveur de calcul, reçoit les résultats du serveur de calcul, envoie les résultats au client
–> serveur de calcul : effectue les calculs demandés par le serveur de gestion client et données, et renvoie les résultats à ce dernier

Nous avons donc ici un système à trois entités physiques (client, serveur de gestion, serveur de calcul), et donc 3 entités logiciels (nous l’avons défini de cette façon).
La grande question que nous nous posons depuis plusieurs semaines, c’est “sur quelle technologie s’appuyer ?”. Pour des raisons d’efficacité de développement et de déploiement, ainsi que par expérience, nous pensons nous tourner vers une technologie “managée” telle que Java ou Dotnet(C#). Je vais être franc, je viens du monde Dotnet, et donne actuellement l’avantage à Microsoft, notamment pour le développement d’applications client lourd. En effet, notre logiciel client sera un client lourd. Je vais faire ci-dessous un comparatif tout à fait subjectif pour que vous comprenniez mieux mon point de vue.

Points:

Développement client lourd --> avantage Dotnet
Développement serveur --> avantage Java
Simplicité d’utilisation générale --> avantage Dotnet
Compatibilité avec les systèmes --> avantage Java
Coût --> avantage Java

Voilà ce que je pense actuellement. Mis à part le prix induit par le choix Microsoft, la connaisance de la plateforme, la présence de WPF et de son éditeur graphique d’IHM, l’ergonomie de Visual Studio, la simplicité d’utilisation, et la majorité des clients utilisants un OS Windows me pousseraient pour l’instant à choisir Dotnet.
Du côté Java, j’ai exploré :

Netbeans --> sympa, mais interface grapique assez peu réactive
l’éditeur Swing de Netbeans --> que j’ai trouvé moins pratique que l’équivalent WPF sur Visual Studio (normal, puisque je connais l’un et pas l’autre…)
Eclipse --> que je trouve assez complexe pour un début

Ma question est la suivante : y-a-t il une raison qui devrait me pousser à me tourner vers la technologie Java, même si je dois perdre du temps à tout ré-apprendre ?

Désolé pour le pavé de texte.
En vous remerciant par avance,
Mouillette.
Edité le 20/05/2010 à 11:47

JlS666 · Mai 18, 2010, 1:35

fonce sur le java!

multi-plateforme, efficace, et tout ré-apprendre ne te prendra pas tant de temps si tu connais déjà bien la programmation orientée objet

mouillette_1_1 · Mai 18, 2010, 2:29

Ce n’est pas l’apprentissage du “langage” Java qui me freine pour l’instant. C’est plutôt l’apprentissage de la “plateforme” Java.
C’est à dire :

le choix d’un Environnement de Développement Intégré : Netbeans, Eclipse, autre ?
l’apprentissage de cet EDI : création d’application graphiques client lourd, création d’application graphique client léger, création d’application serveur, création de service (Visual Studio est quand même assez simple à utiliser)
trouver une bibliothèque graphique performante côté développement et côté exécution (à la hauteur de WPF) et disposant d’un éditeur graphique de qualité : l’éditeur Swing sous Netbeans ne me satisfait pas
tous les trucs spécifiques à la plateforme tels que Applet, Servelet, EJB, J2EE, JavaWebStart, …

En parlant de WPF, quelqu’un aurait-il essayé “eFace”, l’équivalent Java apparemment ?

C’est tout cet ensemble qui me fait encore hésiter.

JlS666 · Mai 18, 2010, 2:53

je n’ai jamais testé eFace…

par contre je connais plutôt bien Eclipse et je le trouve excellent, efficace, simple d’utilisation.
c’est vrai que les premières fois que je l’ai lancé j’ai eu un peu de mal avec l’interface mais au bout de quelques temps tu ne décroches plus

maintenant niveau bibliothèques c’est notre ami Google qui te sera d’une grande aide^^

mouillette_1_1 · Mai 18, 2010, 10:09

En ce qui me concerne, les avantages principaux de Java sont :

la compatibilité avec un maximum de système
une utilisation totalement libre (une société peut commercialiser une application Java/Swing sans rien demander à personne)

Mon gros problème actuellement reste le développement d’application client lourd avec GUI (équivalent application de bureau WPF). DU côté de Java, j’ai trouvé des renseignements sur :

AWT, contenu dans le framework Java, ancien
Swing, contenu dans le framework Java, remplaçant de AWT
SWT, distribué avec le SDK d’Eclipse, plus léger et donc plus réactif que AWT et Swing
JFace, distribué avec le SDK d’Eclipse, sur-couche de SWT, plus simple

Quelqu’un aurait-il essayé Visual Editor Project sous Eclipse ?

kookiz33_1_1 · Mai 18, 2010, 11:22

Côté .NET, tu peux aussi ajouter WCF pour faciliter la communication avec le client, et PLINQ pour faciliter la parallélisation des traitements côté serveur. Également, la facilité de conversion de WPF vers Silverlight peut être un plus.

Niveau coûts, à moins que tu veuilles mettre un front-end en asp.net (donc : licence Windows Server), ça ne me parait pas délirant. Vu que c’est un client lourd, je suppose qu’un “simple” service tournant sur une machine Windows et exposant des webservices doit faire l’affaire.

Donc je pense que la véritable question à te poser est : as-tu besoin d’une solution multiplateforme ? Si oui, la question ne se pose même pas -> Java. Si non, tourne toi vers l’environnement que tu maitrises le mieux.

mouillette_1_1 · Mai 19, 2010, 3:39

Effectivement, je me suis renseigné sur les architectures orientées services. Que ce soit .Net ou Java, ça a l’air de simplifier grandement les interactions “client-serveur”, si je puis me permettre de le dire ainsi.

Si j’ai bien compris le système :
–> exemple d’architecture client-serveur vue par le développeur :
- le logiciel client envoie des requêtes http au serveur
- le logiciel serveur réceptionne les requêtes http du client
- le logiciel serveur traite les requêtes
- le logiciel serveur envoie les résultats au client via une requête http ou ftp
- le logiciel client réceptionne la réponse http ou ftp du serveur

–> exemple d’architecture orientée service vue par le développeur :
- le logiciel client se connecte au service web présenté par le serveur
- le logiciel client appelle une fonction de ce service web
- le logiciel serveur exécute la fonction et retourne un résultat
- le logiciel client récupère ce résultat

Un avantage des architectures orientées services réside dans le fait de ne pas se soucier des communications entre le client et le serveur.
Par contre, du coup, est-il possible de paramétrer les types de protocoles utilisés ? Comme TLS/SSL par exemple pour faire du https et du sftp au lieu du http et du ftp ?
Et est-il possible de paramétrer des restrictions d’accessibilité (que tout le monde ne puisse pas se connecter au service…) directement dans l’implémentation du service web ?
Edité le 20/05/2010 à 09:56

Martopioche · Mai 20, 2010, 2:32

Bonjour,

Mouillette, je ne comprends même pas pourquoi tu t’entête à ces comparaisons si ton objectif est le développement d’une application cur de métier dune société dans les conditions que tu a décrites… D’après ce que je lis, tu veux développer le logiciel seul (pas absolu, mais vous sous-traitez pas cette partie là) et tu connait .Net et pas du tout Java. Bon, ben à moins que votre projet ne soit pour la prochaine décennie, la question ne se pose même pas => .Net :neutre:

Je présume également que vous avez fait une vrai étude aussi bien de marché et d’acceptation client (tes clients vont devoir utiliser une “appli lourde” juste pour de l’upload ? Comme le permettrai un simple formulaire web avec 20 lignes de PHP ? Pas d’utilisation de connecteurs pour s’intégrer dans un système existant ? ) que sur le déploiement de votre infrastructure (sécurisation données client ? ) et donc ces couts associés.

Dans tous les cas, le choix Java/.Net ne se pose pas en simples termes de ce qui est sympa ou pas mais de leur intégration avec un écosystème et des compétences des développeurs.

Martopioche · Mai 20, 2010, 2:46

Une architecture orientée services est indépendante des technos. Après, chaque techno arrive plus ou moins facilement à les utiliser (point de vue du développeur).

Après, ta compréhension de l’architecture orientée service est plutôt une perception de la techno SOAP (l’autre étant REST). Tous tes échanges seront en http/https, pas ftp. Et oui c’est sécurisable (voir WS-Security).

mouillette_1_1 · Mai 20, 2010, 3:25

L’étude de marché n’est pas encore faite. Nous avons eu des premiers contacts avec les industriels. Nous mettons en forme le cahier des charges de l’étude de marché en ce moment même. Ensuite, nous nous adresserons à un tiers pour corriger ou pas notre cahier des charges et qu’il mène cette étude de marché.
En fait, le projet sur lequel nous travaillons amènera au montage d’une startup, au plus tôt pour fin d’année. Avant cela, rien ne sera fait côté développement. Du coup, je prend le temps de réfléchir en ce moment à la façon dont les choses pourraient être faites.
Je me pose beaucoup de questions sur Java, car :

développement sous linux possible --> pas de licence Windows à payer
développement avec Netbeans ou Eclipse --> pas de licence Visual Studio à payer
serveurs interne sous linux --> pas de licence Windows server à payer
SGBD qui tourne sous linux --> pas de SQL server à payer

Le choix Java permettrait quand même quelques économies. Cependant, entre le temps perdu à apprendre cette technologie et l’économie que ça apporte, je cherche à faire un choix intelligent. Enfin, j’essaie…

Après, effectivement, j’ai réfléchi à la question “client lourd / client léger”. Ça fera partie de l’étude de marché.

Merci de ta réponse.

Martopioche · Mai 20, 2010, 4:01

TREEEEEEES mauvaise considération… Tu le souligne toi même :

Surtout que :

SGBD qui tourne sous Linux ne veut pas dire base gratuite. Quelle base , PostgreSQL ? Ok. MySQL ? Payant (pour utilisation industrielle, à moins qu’Oracle ai changé quelque chose). Oracle (justement) ? Payant.
Serveur sous Linux gérés par vous ? Par un prestataire ? Quelle assistance ?
Serveur physique ok, mais serveur d’appli ? Tomcat ? GlassFish, Jboss ? Weblogic ?
Les IDEs, ok (note : pour du Java, j’utilise les 3 simultanément, le 3eme étant IntelliJIdea)
Développement sous Linux : là aussi ok (les postes de dev contrairement aux serveurs, ne sont pas aussi critiques).

Linux n’est pas une solution pour économiser des bouts de chandelles, pas plus que le choix de Java en terme de techno. Question : quelle est ta possibilité de tuner Windows/SII/.Net par rapport à Linux/Apache + {Tomcat|GlassFish|JBoss|Weblogic}/Java ?

Bref : évaluer la techno c’est une chose. Pour vos besoins, l’un et l’autre conviennent (même Python + Django ou Php + C++). Le choix doit se faire sur tous les autres critères, mais c’est à toi de les évaluer ou demander une audite sérieuse (= pas simplement un forum où, désolé JlS666 mais ta réponse sonne comme ça, un FanBoy te dira de faire comme lui).

mouillette_1_1 · Mai 20, 2010, 4:38

Tes réponses sont très constructives. Merci beaucoup.
Pour l’instant, j’en suis vraiment aux balbutiements de ce que pourrait être une solution.
J’avais pensé au départ à une solution de la forme suivante :

client .Net WPF ClickOnce
serveur de gestion Windows Server/SII
serveur de calcul --> on verra, je ne sais pas sous quoi tournera le calculateur que nous utiliserons (comme je l’ai dit, on en est au début)

Je me pose tout de même une question. L’avantage d’un client lourd, WPF/ClickOnce par exemple, est de pouvoir contrôler le nombre de postes client qui pourront utiliser notre logiciel, via l’empreinte matérielle de leur poste de travail. Cette contrainte peut permettre par exemple de vendre N abonnements à un seul client s’il veut que ses N ingénieurs puissent avoir accès à notre système.
Je me demande du coup, puisque que je n’ai jamais fait de développement client léger : le fait que le logiciel s’exécute dans un navigateur n’apporte-t-il pas des contraintes au niveau de l’accès aux informations et données du poste client ?

Encore merci pour tes réponses.

Martopioche · Mai 20, 2010, 5:10

Pour info, l’équivalent Java serait
-> Client Swing avec JavaWebStart (JWS) (que ClickOnce copie )
-> Serveur Os ce que tu veux + Serveur d’appli Tomcat ou GlassFish ou JBoss ou Weblogic. Dans ton cas, ça suffit. Un Apache en front ne coute rien et est plus efficace pour le load balancing et servir les contenu statiques donc grandement conseillé.

Sauf que si tu ne fait qu’exposer des WebServices, à la place d’un serveur d’applications tu pourrai envisager l’utilisation d’un EAI ou un simple ESB (= un middleware) qui te permettrai dagréger des services et de gérer des process de manière asynchrone… Aha là je viens de te pourrir tes prochaines nuits (si les concepts t’intéressent, les produits Java de référence sont ServiceMix et Mule ESB)

Quel intérêt ??? Tu vend quoi comme service ? Des abonnements de connexion ou un service de traitement ? Tu facture au nombre de machines connectées ou au nombre de fichiers traités ?

Il me semble que ClickOnce est comparable à JWS, donc une fois rapatrié, l’application est totalement indépendante du navigateur. Dans le cas d’une WebApp, tu a accès à tout ce qu’a accès le navigateur.

De rien, si ça peut aider.

mouillette_1_1 · Mai 20, 2010, 5:27

L’intérêt de l’empreinte matérielle, et donc du contrôle du poste de travail, c’est de pouvoir louer un abonnement mensuel (10 calculs) par poste de travail. L’intérêt c’est l’argent, comme toujours… Mais cela fait partie de l’étude de marché.

Encore merci.

mouillette_1_1 · Mai 25, 2010, 5:14

J’ai continué à me renseigné sur la possibilité de mettre en place notre système via une architecture orientée service, dans le cas de l’adoption de la gamme Microsoft .Net. Ça s’embrouille un peu dans ma tête, et j’ai du mal à voir comment faire ça proprement.

Je recommence donc du début. Les entités physiques sont :

un serveur/cluster de calcul (une grosse boîte avec des lames dedans)
des postes clients
un ou plusieurs serveur pour s’interfacer entre le client et le serveur/cluster de calcul

1- Le serveur/cluster de calcul
Aujourd’hui, nous n’avons aucune idée du cluster qui sera utilisé. Ca pourrait être du IBM, du HP, du Apple…
Aucune idée de l’OS qui tourne dessus. Aucune idée de comment communiquer avec. Aucune idée tout court. Désolé.

2- Les postes clients
Partons du principe où les postes clients tournes sous Windows XP et Windows 7. L’application client serait développée en .Net 4.0, dans le langage C#, et serait déployée via “ClickOnce” (par exemple distribuée sur le site Web Produit).

3- Les serveurs pour s’interfacer
C’est là que, n’étant pas spécialiste du truc, je me perds. J’ai du mal à savoir s’il y a besoin de 1 ou plusieurs serveurs. On va partir du principe où tout se trouve en interne. Et que nous disposons d’une ligne professionnelle, afin que les communications “client <–> interne” soient rapides.
Le rôle de cette entité, c’est :

recevoir toutes les requêtes de l’application client (déployée sur plusieurs postes clients)
gérer la BDD clients/calcul (ID, nom société client, infos clients, abonnement choisi, options choisies, nombre de calcul achetés, nombre de calculs restants, …)
gérer les données de calculs (données envoyées par le client, résultats retournés par le calculateur, …)
permettre la communication sécurisée entre l’interne et le logiciel client (protocoles sécurisés)
permettre de bloquer les intrusions (à la manière d’un pare-feu)
permettre d’exposer au logiciel client un ensemble de services Web, comme par exemple pour effectuer une demande de calcul

Est-ce que tu aurais encore dans ta besace de quoi éclaircir ma vision. Une idée de comment faire ça bien, sans aller dans le trop lourd (car au final, c’est moi qui vais devoir gérer…) ?

Une idée de "où me renseigner" serait tout à fait intéressante pour moi :) Merci d'avance.

mouillette_1_1 · Mai 26, 2010, 2:33

Je viens de relire mon poste, et je me suis rendu compte du manque d’information… du coup, il n’y a rien à répondre.
Je vais donc faire une proposition technique. Il sera plus facile d’améliorer quelque chose d’existant que de le créer de toute pièce.

1- Serveur de calcul
–> rien à dire. Je ne sais même pas comment communiquer/interagir avec.

2- Les postes clients
Là, j’ai deux choix :

Solution 1: .Net/WPF/C#/ClickOnce sous Visual Studio 2010 Professional, avec utilisation potentielle de WCF pour les échanges avec les services Web, et potentiellement une BDD SQLite ou Access
Solution 2 : Java/Swing ou JavaFX(application de bureau)/JavaWebStart sous Netbeans 6.8 ou supérieur, et potentiellement une BDD SQLite

3- Le serveur de gestion, supposé en interne

Solution 1 : Windows Server/IIS/SQLServer/WebService .Net sous forme de DLL
Solution 2 : Linux/Apache Tomcat ou Glassfish/MySQL/WebService Java sous forme de .jar je suppose

Ça tient la route d’après-vous ?

Une dernière petite question : Quel est l’intérêt du protocole REST par rapport à SOAP pour les communications client-service ?

Martopioche · Mai 26, 2010, 3:34

'lut

Bah oui ça tient la route (modulo remarques ci-dessous). Mais que veux tu de plus ? Tu met en parallèle les deux manières strictement identiques de faire en .Net ou en Java… Tout pareil…

Ben tout dépend de ce qu’il fait, comment, tout ça… Moi je dirai que tu ninteragît pas avec, c’est lui qui le fait : en fonction de sa disponibilité, il interroge un gestionnaire de taches, récupère la plus prioritaire, l’exécute, rend les résultats et passe à la suivante. Autour tu brode (envoi de mail, mise à jour du dashboard client…).

Fx n’est pas encore robuste à mon sens, et Java interagit mal avec SQLite (si tu veux du pur natif, préférer HSQLdb).

Non, war (Web ARchive) mais techniquement c’est presque la même chose. Et voir ce que j’ai déjà dit :

J’ai filé ce lien que je trouve pas mal sur un autre sujet : www.clever-age.com…
Edité le 26/05/2010 à 15:36

mouillette_1_1 · Mai 26, 2010, 4:47

Je suis un peux perdu, et effrayé du coup…
FrontEnd veux dire “poste client” ou “serveur communiquant directement avec le client” ?
La deuxième solution, hein ?

--------EDIT--------
Non mais en fait j’ai oublié de réfléchir avant d’écrire.
Merci pour le lient REST.
Edité le 26/05/2010 à 16:59

vitamin1981 · Juin 3, 2010, 4:13

Salut,

Avis perso…

Tu cherches à établir une architecture technique à une solution dont :

tu n’en maitrises pas toutes les possibilités techniques
on a vaguement une idée des exigences du secteur d’activité sous jacent.

Si ton projet est très concret et que vous êtes très motivés par le sujet, je ne te saurais te recommander de :

consulter un architecte technique qui sera être en mesure de te conseiller finement sur une solution viable économiquement
ne pas trop t’attarder sur les contraintes de développement spécifique car :
1. es tu sur que la solution passe forcément par du développement spécifique en Java / .NET / Ruby / and co ?
2. en général, et à moyen terme, la charge de maintenance dépasse largement celle de l’investissement initial en développement

Toujours avis perso, et étant donné que tu as l’air de te preter à établir toi meme cette architecture technique, je ne saurais trop te recommander de regarder autour de toi ce qui peut se faire pour des applications similaires à la tienne. Exemple, si tu veux monter une application sur base d’architecture distribuée, alors tu peux te renseigner sur les services REST comme indiqué, mais aussi les gros machins à base de WebSphere, les trucs clé en main en PHP, le cloud computing, etc etc.

vitamin1981 · Juin 3, 2010, 4:28

1- Le serveur/cluster de calcul

Partir de l’objet des calculs à effectuer, des entrants et sortants (fichiers, base de données, communication externe, etc). Par défaut, tu peux utiliser n’importe quelle machine, n’importe quel OS … et surtout n’importe quel fournisseur correspondant.

2- Les postes clients

Pourquoi un client lourd ? Pourquoi se limiter au .Net / Java ? Pourquoi pas en C++ Winform (sur cet exemple, je dis potentiellement n’importe quoi, l’idée est pourquoi se limiter à ces technos) ?

3- Les serveurs pour s’interfacer

Perso, la solution BDD ne devrait pas s’imposer de facto.

Pour ma part j’aurais tendance à te retourner qqs questions :

Quel est le niveau de confidentialité des données de calcul ? Est ce qu’il utilise des données personnelles ?
Quel est le niveau de service attendu par le poste client ?

Tu devrais éventuellement orienter tes choix en fonction de tes moyens financiers (serveurs à acheter / louer, licences à payer, etc etc).

Bon courage