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
Discussion :
Critères d'éligibilité d'une application à la plateforme Java EE ou DotNET
Bonjour,
Je souhaiterais lister les critères qui permettent de dire que telles applications seraient éligibles plutôt à la plateforme DotNet et non Java, et vis versa.
Si vous connaissez des critères (assez discriminants), je suis preneur.
Merci d'avance
premier critère discriminant pour le moment: portabilité du serveur.
Merci.
DotNet n'est vraiment pas portable?
tu veux dire, a part d'un windows à l'autre? Non. Il y a bien le projet mono, mais il n'implémente pas encore toute la couche .NET
Pour ma part, il semble que .Net soit le choix des entreprises et/ou applications d'envergures moyennes et petites. Il est apparemment plus simple à utiliser que J2EE, le codage est plus rapide et .Net est plus performant dans l'ensemble sous des volumes de transaction modérés.
Par contre, la grande entreprise, en particulier les banques, semble arrêter son choix sur le J2EE pour les applications de masse. Celui-ci requiert par contre une expertise assez pointue et des équipes entières pour être utilisé à son plein potentiel. Le J2EE est l'amalgame d'une multitude de standards Java (EJB, Servlets+JSP, SOAP, WSDL, JAAS, JTA, JDBC, RMI/CORBA, etc) qui peuvent être long à apprendre et maîtriser. Il faut donc pouvoir combiner des expertises de plusieurs personnes que de viser à avoir quelques travailleurs omniscients à l'ouvrage. La distribution des équipes de développement fait d'ailleurs parti des spécifications du J2EE, si je ne m'abuse.
Par expérience personnelle, je peut dire que lorsque les équipes sont mal formées au départ, on peut se retrouver facilement avec une architecture boiteuse, qu'il peut-être long et coûteux à corriger par la suite. J2EE n'est pas le choix idéal quand on est du genre à «apprendre sur le tas». Idéalement, dès le départ, les architectes devraient être familiers un minimum avec les BluePrint de Sun. Le J2EE n'est pas seulement un standard de codage, mais une façon de faire. Toujours selon moi.
Merci pour vos réponses.
En fait, dans le cadre de mon stage, je dois déterminer un tableau décrivant les critères qui permettent d'orienter les applications vers la techno J2EE ou DotNet.
Si je résume, mis à part la portabilité, la facilité d'apprentissage, .Net plutot projet de taille moyenne (qu'entend-on par taille moyenne) et plutot pour des applications front ?
Ca fait pas beaucoup de différence si je comprends bien.
Merci pour vos réponses et avis.
si il n'y a pas beaucoup de différence, c'est surtout parce qu'il s'agit de deux produits concurrents, il tentent d'empieter chacun sur le même marché et donc, forcément, les critères de choix sont similaires de chaque coté.
Quand au commentaire sur le "apprendre sur le tas", je ne suis pas tout a fait d'accord. Certes un méconaissance des standard que tu utilise peux amener à des architecture boiteuses, mais la connaissance d'un standard n'est pas le critère principal de sa bonne utilisation. La logique et le bon sens de l'analyste y jouent une bonne part. Si l'analyste / architecte se lance sans prendre d'abord un minimum de marques, quel que soit le language, ca posera problème très vite.
Il est vrai qu'a force de grandir et grandir, une application deviens problématique et on se rends compte d'erreurs de choix technologiques ou d'architecture (ha si j'avais su), mais ce n'est pas pour autant qu'avec une bonne connaissance des framework on aurait fait des choix différents au départ. Prendre en compte trop de besoins d'évolution futures dans le départ, c'est aussi risquer de faire capoter le projet car 'trop lent à développer, rien n'est sorti alors que ca fait déjà trois mois que 4 personnes sont dessus'
Et personnellement, ce que j'aime dans java, c'est la quantité de librairies disponibles en open source pour gagner du temps.
À titre d'exemple, nous avons 1,5 millions d'usagers, avec en simultané 1200-1600 usagers connectés effectuant des requêtes avec une moyenne de 64 transactions/sec aux heures de pointe, distribué sur quatre instances pour le moment. Il peut nous arriver d'atteindre 700/800 usagers par instance simultanément. Et nous nous apprêtons à terminer une migration de code, ce qui signifie que nous devrons augmenter le nombre d'instances d'ici peu.Envoyé par kheyeng
Personnellement, je ne confierais pas cette application à .Net/Windows. Peut-être cette plate-forme est-elle en mesure de prendre en charge ce volume d'affaires, mais Windows a la réputation de geler fréquemment comme serveur Internet à haut volume.
Quand à quantifier précisément ce que représente «haut-volume» pour moi, je n'ai pas de chiffres officiels, ce qui serait intéressant à avoir. Mais j'estime un volume moyen à petit: des systèmes pour acheteurs, des sites commerciaux pour des boutiques, des systèmes opérationnels pour l'entreprise, etc. C'est dans ce domaine que j'ai vu des codeurs .Net œuvrer le plus.
Mais je serais quand même intéressé par d'autres opinions sur le sujet, puisque mes points de vue sont basés sur mon expérience personnelle.
Le J2EE n'a rien d'intuitif. Quoi que j'admet que EJB3.0 vient aider les choses. Je ne crois pas me tromper en disant qu'on est beaucoup plus rapidement à l'aise avec .Net qu'avec J2EE.
bien sur, je dit juste qu'en débutant une application, il n'y a pas nécessité de maitriser touts les framewokrs disponible. Certes les EJBs sont compliqué à appréhener, surtout avant la version 3, mais toutes les applis n'en ont pas nécessité, et savoir ce dont sont capable les EJB est relativement suffisant pour savoir si on va les utiliser ou pas. Après, quand on décide de les utiliser, il est indispensable de le faire correctement ben sur, et donc d'avoir la connaissance associée sur site ^^ . J'ai pas dit que ça s'improviseEt des petites à moyennes applications peuvent très bien se contenter de fonctionnalités de base.
Personne n'a evoque le cout (financier) de developpement qui sera a la base plus eleve pour .net:
- l'IDE (visual studio)
- serveur web (IIS)
- bdd (SQL server)
- serveur de deploiement (windows server)
=> Tout ca est payant!
Tandis que sur j2ee:
- IDE = eclipse
- serveur dappli = tomcat
- bdd = mysql
- serveur de deploiement = linux (ubuntu server pour rester gratuit sinon red hat)
Hum, alors je connais pas trop côté .NET, mais je croyais que le visual studio standard et SQL Server était utilisable gratuitement en environnement professionnelle.
MySQL est sous double licence, et pour l'utiliser en entreprise, il faut éventuellement payer une licence propriétaire (l'autre étant GPL). Mais cela peut dépendre de comment sont fait les liaisons.
Je vois pas quel serait l'interet de microsoft de distribuer gratuitement SQL Server en environnement professionel. C'est pas comme si en environnement non pro les gens en avaient beaucoup besoin. Maitenant tu parle peut etre d'une licence développement (in fine le client devra donc payer une licence lors du déploiement)
Pas tout a fait. Tant que tu utilise une simple connection DB interchangeable (comme un connecteur jdbc) tu n'est pas considéré lié à leur base de donnée. Ca c'est pour la licence de tes logiciel. Le client lui peut installer gratuitement mysql pour servir de base à ton appli si il le veut.MySQL est sous double licence, et pour l'utiliser en entreprise, il faut éventuellement payer une licence propriétaire.
Oui, c'est pour ça que j'avais précisé il y avait quel type de liaison avec MySQL. En cas d'un connecteur, c'est effectivement juste une configuration au niveau du serveur d'applications.
Pour tout ce qui est .NET, je connais pas du tout la politique de Microsoft par contre sur les prix sur les environnements de développement, ou lors d'un déploiement.
de mémoire, pour les plateforme .NET, lors d'une formation UML il y a 3 ans, le prof, qui possédait une boite de dev orientée .NET (C#/VB) nous avais dit qu'un poste développeur .net lui coutait 5000 euros en licences / an (visual studio, outils de profiling, accès msdn, licences OS, etc).
D'après lui, le surcout par rapport à un environnement java était rapidement encaissé non pas avec les temps de développement, mais par le fait que .net était un mot magique qui permettait de vendre plus facilement (et donc plus chers)
Petit bémol quant aux coûts des licence, c'est pas parce qu'un outil ou un serveur est gratuit qu'il est facile à utiliser, administrer ou même configurer. Il faut être sûr de son choix et dès que les applications deviennent conséquente, ce sont pas 500 euros de différence de frais fixe qui vont peser lourd.
Ca va dans les 2 sens, faire le choix de la gratuité de licence ok, mais faut tenir compte de tout ce qui est risque et formation, c'est donc un critère sur lequel il faut être prudent et bien calculer.
Nous sommes une petite société (9 developpeurs) de developpement spécialisé en cartographie.
nous utilisons uniquement du java :
- IDE = Netbeans
- serveur dappli = Glassfish, tomcat
- bdd = postgresql
- serveur et ordinateur de test/deploiement = linux (ubuntu), Mac et windows(dans machine virtuelle)
ainsi que divers outils : maven, mercurial, sonar, hudson, jira ...etc...
Tout étant open-source ou libre.
Glassfish dispose d'une interface de control bien plus complete que tomcat, il est aussi parfaitement bien intégré dans l'ide netbeans, ce qui permet de tester les application web en un seul click.
PostgreSQL et un exellent sgbd, tres robuste meme pour les gros volumes et avec une bonne interface de controle : pgadmin.
La plupart des gens citent des critères externes alors que ce qui importent le plus c'est quelle est la techno que votre équipe maîtrisez le mieux. Parce que 80% des spécifs ne vont poser aucun problème dans l'une ou l'autre techno mais 20% va en poser parce qu'ils sont pointus et là il faut bien maîtriser. Quand je parle de maîtriser il ne s'agit pas que de la syntaxe des langages mais surtout des librairies et frameworks aka ecosysteme.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager