Utilisateur:INFO EB12 2015/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

Comparaison des plateformes Java Enterprise Edition et Microsoft .NET[modifier | modifier le code]

Java Enterprise Edition (ou Java EE) et Microsoft .NET (lu "dot net") sont deux plateformes de développement spécialisées dans la création d'application Web. Java EE est une spécification pour la technique Java d'Oracle, créée en 1998 sous le nom de JPE, elle prit le nom de Java EE en 2006. Microsoft .NET est le nom de la plateforme créée en 2002 par Microsoft afin de permettre la portabilité de nombreuses applications sur Internet, le but étant de générer un serveur local afin de gérer des services tout en évitant d'externaliser des informations privées.

Historique[modifier | modifier le code]

Java EE[modifier | modifier le code]

Version Date de Sortie Nom
1 Mai 1998 JPE
1.2 12 décembre 1999 J2EE
1.3 24 septembre 2001 J2EE
1.4 11 novembre 2003 J2EE
5 11 mai 2006 Java EE
6 10 décembre 2009 Java EE
7 12 juin 2013 Java EE
8 attendue fin 2016 Java EE

Microsoft .NET[modifier | modifier le code]

Version Date de sortie Visual Studio Par défaut dans Windows
1.0 13 février 2002 Visual Studio.NET 2002 Windows XP
1.1 24 avril 2003 VIsual Studio .NET 2003 Windows Server 2003
2.0 7 novembre 2005 Visual Studio 2005 Windows Server 2003 R2
3.0 6 novembre 2006 Visual Studio 2005 Windows Vista, Windows Server 2008
3.5 19 novembre 2007 Visual Studio 2008 Windows 7, Windows Server 2008 R2
4.0 12 avril 2010 Visual Studio 2010 Windows Server 2008 R2 SP1
4.5 12 septembre 2012 Visual Studio 2012 Windows 8, Windows Server 2012
4.5.1 17 octobre 2013 Visual Studio 2013 Windows 8.1, Windows Server 2012 R2
4.6 20 Juillet 2015 Visual Studio 2015 Windows 10, Windows Server 2016

Multilingue[1][modifier | modifier le code]

Définition[modifier | modifier le code]

Le caractère multi-linguale d'une plateforme de développement correspond au nombre de langages que cette plateforme accepte afin de développer une application.

Comparaison des offres[modifier | modifier le code]

L'offre de Microsoft possède le point fort d'être multilingue[2] tandis que J2EE est unilingue (Java). Le multilangage permet aux sociétés de tirer parti de leur expert informatique dans chacun des langages afin de développer une application web répondant le mieux aux besoins des clients et utilisateurs. .NET propose aux utilisateurs de développer dans une douzaine de langages réputés différents ce qui permet de créer une application Web avec des connaissances minimales dans plusieurs langages à défaut d'être expert dans un seul (Java).

Interopérabilité des programmes[3][modifier | modifier le code]

Définition[4][modifier | modifier le code]

L’interopérabilité en informatique est la capacité que possède un système informatique à fonctionner avec d’autres produits ou systèmes informatiques, existants ou futurs, sans restriction d’accès ou de mise en œuvre.

Java Enterprise Edition[modifier | modifier le code]

Java est une technologie mono-langage mais multiplateformes (Unix/Linux, OS X, Windows). Cependant, les évolutions depuis permettent le support dynamiques tels que Python (avec Jython), Ruby et même PHP (avec Quercus).

Microsoft .NET[5][modifier | modifier le code]

Microsoft quant à lui apporte .NET qui ne fonctionne en pratique que sur Windows et est donc mono-plateforme. Il existe cependant le projet Mono développé sur Linux qui ne cesse d’évoluer au fil des nouvelles versions. Il supporte notamment le Visual Basic, le C++, et le C#.

De plus, Java et .NET étant deux plateformes en plein essor et toujours en plein développement, elles sont donc amenées à cohabiter dans le futur.  

Le langage XML[modifier | modifier le code]

L’interopérabilité a pour but de simplifier les communications entre différents systèmes afin d’en faciliter les échanges. Le langage qui permet de réaliser au mieux cette interopérabilité, surtout dans un contexte hétérogène, est le XML. Ce langage est indépendant des outils qui l’utilisent. Il permet de structurer sémantiquement les données ainsi que de rendre le contenu indépendant de toute mise en forme.

Usability[modifier | modifier le code]

Définition[modifier | modifier le code]

La notion d'Usability ou "User Friendly" (Usabilité en français) est définie par la norme ISO 9241-11 comme "le degré selon lequel un produit peut être utilisé par des utilisateurs identifiés, pour atteindre des buts définis, avec efficacité, efficience et satisfaction, dans un contexte d'utilisation spécifié".

Comparaison[modifier | modifier le code]

L’usabilité dépend notamment du logiciel utilisé pour la programmation des applications Web, d’un logiciel à l’autre, ce facteur peut-être totalement différent. De plus, du point de vue utilisateur des applications, l’usabilité dépend fortement de la manière dont celle-ci est programmée.

Sécurité[modifier | modifier le code]

La sécurité désigne l'ensemble des techniques mises en oeuvre afin de protéger les ressources des logiciels créés. Le but est de rendre disponible la ressource uniquement au moment voulu et à la personne désirée.

Java Enterprise Edition[modifier | modifier le code]

La sécurité avec JAVA

Lors du déploiement d'une application classique sur la plateforme J2EE, les fichiers sources passent par plusieurs étapes que sont les suivantes.

Les fichiers sources (.jar)[modifier | modifier le code]

Les fichiers sources sont regroupés sous la forme d'une archive .jar, ou Java Archive ce qui permet de faciliter le déploiement de ceux-ci en ensembles cohérents.

Compilation[modifier | modifier le code]

Les fichiers sources sont compilés par la plateforme en fichiers .class. Cette compilation aura pour effet de produire un code, appelé bytecode. Celui-ci a pour fonction d'être un langage intermédiaire, interprétable par les différentes machines virtuelles de tous les systèmes d'exploitation disposant d'une machine virtuelle Java. Cette opération fait ainsi de Java un langage portable.

Le chargeur de classe Java[modifier | modifier le code]

Les fichiers .class sont ensuite chargés dynamiquement dans la machine virtuelle Java grâce au chargeur de classe Java (classloader en anglais). Ce dernier est capable de:

  • retrouver les bibliothèques
  • lire le contenu des bibliothèques
  • charger les classes à la demande

Le vérifieur de syntaxe[modifier | modifier le code]

Les fichiers .class sont interprétés par le vérifieur de syntaxe Java qui va générer les exceptions lorsqu'une erreur est rencontrée.

La machine virtuelle Java[modifier | modifier le code]

La machine virtuelle Java (JVM, Java Virtual Machine) se charge d'exécuter les programmes compilés sous forme de fichiers bytecode (.class). Celle-ci va générer des exceptions de sécurité lorsqu'un programme tente d'accéder à des ressources non-sécurisées.

D'autre part, le programme s'exécutant au sein d'une machine virtuelle, elle a la capacité de ne pas pouvoir altérer le fonctionnement du système hébergeant la machine virtuelle.

Quant aux applications distantes telles que les applets, on ne parle plus de machine virtuelle mais de sandbox. En effet, l'application sera lancée dans un environnement de tests dans le but de sécuriser le système comme pour les machines virtuelles.

Ainsi, les systèmes bénéficient de protection tel que la gestion de mémoire permettant de pallier les attaques par dépassement de capacité (buffer overflow).

Microsoft .NET[modifier | modifier le code]

La sécurité avec .NET

La plateforme .NET va suivre le même fonctionnement. Cependant, elle va amener aux étapes précédentes une couche supplémentaire : le Policy Manager. Elle va ainsi permettre d'avoir un niveau de sécurité supplémentaire à la plateforme J2EE.

Assembly[modifier | modifier le code]

L'assembly consiste en un regroupement cohérent de fichiers sources, il peut être assimilé au fichier .jar de la plateforme Java.

Compilation[modifier | modifier le code]

Les assembly sont transformés grâce à un compilateur JIT (compilateur Just In Time) qui transforme les fichiers sources en code CIL (Common Intermediate Language) ou bytecode. Ce processus assure, de même que la plateforme Java, une portabilité des application disposant d'une machine virtuelle .NET.

Policy Manager[modifier | modifier le code]

Niveaux de sécurité du Policy Manager

Le Policy Manager[6] est la couche située avant le chargeur de classe permettant d'avoir un niveau de sécurité supplémentaire à la plateforme Java. En effet, celui-ci produit un ensemble de permissions pour les différents assembly de l'application. Les différents niveaux de permissions[7] attribuables sont les suivants :

  • Domaine d'application : s'applique au domaine d'application, niveau le plus haut d'autorisation
  • Utilisateur : s'applique sur l'utilisateur
  • Ordinateur : s'applique uniquement à l'ordinateur
  • Entreprise : s'applique à l'environnement de l'entreprise, niveau le plus bas d'autorisation

Chacun des niveaux possède ses propres autorisations. Ainsi, si un assembly tente d'accéder à une ressource et qu'il ne possède pas le niveau d'autorisation nécessaire, une exception de sécurité sera déjà lancée à ce niveau.

Le chargeur de classe .NET[modifier | modifier le code]

De la même manière que le chargeur de classe Java, le chargeur de classe .NET va permettre d'insérer les fichiers compilés dans la machine virtuelle .NET (CLR, Common Language Runtime).

Le vérifieur de syntaxe[modifier | modifier le code]

Le code CIL sont interprétés par le vérifieur de syntaxe .NET qui, de même, va générer les exceptions lorsqu'une erreur de syntaxe est rencontrée.

Le CLR[modifier | modifier le code]

La machine virtuelle .NET (Common Language Runtime, abrégée CLR) a pour objectif d'exécuter les applications compilées dans un environnement clos qu'est la machine virtuelle. Au niveau de la sécurité, il permet de la même manière que pour la plateforme Java l'empêchement des attaques par débordement de mémoire (buffer overflow).

Architecture multitiers[modifier | modifier le code]

Définition[modifier | modifier le code]

Les systèmes logiciels complexes sont séparés en plusieurs couches, ou tiers. Cette façon de faire offre beaucoup d’avantages. L’un d’eux est qu’un développeur peut ne s’occuper que d’une couche, sans trop se soucier du reste. Un modèle classique d’architecture multi-tiers est le 3-tiers

Les différentes couches sont alors séparées de la manière suivante :

La couche de présentation[modifier | modifier le code]

La couche de présentation contient les différents types de clients (Web, ASP, JSP, Swing, WinForm…).

Java Enterprise Edition[modifier | modifier le code]

La technologie J2EE possède les APIs standard Java Servlet et Java Server Pages (JSP). Il existe des Framework comme Struts qui sont mis à disposition pour améliorer l’architecture de la couche de présentation.

Microsoft .NET[modifier | modifier le code]

Les ASP.NET représentent l’équivalent des JSP. Le modèle de développement est basé sur les WebForms. Les WebForms permettent de développer une interface graphique Web en séparant les traitements de la présentation. Ainsi, le formulaire représente la page Web et les traitements sont contenus dans une seconde page appelé Code Behind.  Microsoft adopte donc une stratégie d’intégration des outils et permet de simplifier le modèle de développement en proposant les WebForms au-dessus des ASP.NET. Cependant, il est tout à fait possible d’utiliser les ASP.NET sans les WebForms tout comme il est possible d’utiliser les JSP dans Struts en J2EE.

Schéma d'une architecture multitiers
Schéma d'une architecture multitiers

La couche de service[modifier | modifier le code]

La couche de service contient les traitements qui représentent les règles métier (créer un compte, recherche un produit, calculer un montant…).

Java Enterprise Edition[modifier | modifier le code]

Le choix de l’implémentation de cette couche réside dans l’utilisation ou non des EJB ou JavaBean. Les composants concernés par cette couche sont les EJB Session.

Microsoft .NET[modifier | modifier le code]

Tout comme J2EE, .NET propose le même ensemble de services sous l’appellation de ServiceComponent.

La couche d'objet métier[modifier | modifier le code]

La couche d'objet métier est représentée par l’ensemble des entités persistantes de l’application, c’est-à-dire ayant besoin d’être stocké en base. (Facture, bon de commande, client …).

Java Enterprise Edition[modifier | modifier le code]

Cet objet est représenté par les EJB Entity dans le spécification J2EE.

Microsoft .NET[modifier | modifier le code]

Les objets métier persistants dans .NET sont des objets C# ou VB simple sans aucune caractéristique particulière.

La couche d'accès aux données[modifier | modifier le code]

La couche des données contient les classes chargées de créer les objets métier de manière transparente et indépendamment de leur stockage (SGBD, Objet, Fichiers …).

Java Enterprise Edition[modifier | modifier le code]

L’API JDBC (Java Database Connecivity) est en charge de la communication de l’accès aux données. Contrairement à .NET qui propose des API OLE dB ciblant aussi bien des bases relationnelles qu’un annuaire distribué, JDBC s’adresse uniquement aux bases de données SQL. 

Microsoft .NET[modifier | modifier le code]

Microsoft tant qu’à lui propose ADO.NET pour l’accès aux données. Il fonctionne de manière similaire à JDBC.

Aspect commerciaux[8] (Maintenabilité, coût, portabilité etc)[modifier | modifier le code]

Définition[modifier | modifier le code]

Les aspects commerciaux regroupent tous les facteurs de comparaison relatifs à une étude de performance, sont regroupés ici, la maintenabilité, le coût de développement, les langages supportés etc.

Temps de développement[9][modifier | modifier le code]

De nos jours, un retard de quelques mois dans le lancement d'un produit peut être un facteur significatif de la réussite d'une entreprise. C'est pourquoi, il est nécessaire de bien choisir sa plateforme de développement Web, en fonction de la vitesse de développement. Les deux plateformes que nous comparons (J2EE et .NET) disposent de puissants IDEs (Integrating Developing Environments) qui permettent de réduire le temps de développement. Cependant, la plateforme de Windows est directement prête au développement alors que de son côté J2EE est un ensemble de standard qu'il nous sera nécessaire d'implémenter.

L'utilisation de frameworks spécifiques permet aux deux plateformes de proposer un développement rapide et répondant correctement aux attentes des clients.

Disponibilité de module complémentaire[modifier | modifier le code]

Sur ce point, le nombre d'API (Application Program Interfaces) dont dispose initialement la plateforme de Microsoft est important. Néanmoins, dû à une maturation de langage, la plateforme J2EE possède une évolution du nombre d'API disponible plus importante dont la plus part sont prêts à l'emploi, facile d'utilisation ou open-source.

Portabilité[modifier | modifier le code]

La portabilité désigne l'aptitude d'une application à s'exécuter sur différents environnements. Afin d'assurer cette portabilité, les deux plateformes se basent sur un code intermédiaire appelé bytecode. Ce code n'est pas destiné à être exécuté par le système d'exploitation mais est interprété par la machine virtuelle de destination. Ainsi, si le système d'exploitation possède la machine virtuelle, elle sera capable de transformer ce bytecode en un code machine lisible par le système d'exploitation.

Java Enterprise Edition[modifier | modifier le code]
La portabilité en J2EE

La machine virtuelle faisant office de relais entre le code Java et le système d'exploitation se nomme JVM (Java Virtual Machine). Le slogan de Sun étant "Write once, Run everywhere", la machine virtuelle Java est disponible pour la quasi-totalité des systèmes d'exploitation[10]. Ceci lui permet donc d'avoir une portabilité très importante.

La portabilité en .NET
Microsoft .NET[modifier | modifier le code]

La CLR (Common Language Runtime) de Microsoft, quant à elle, n'a pas été prévue pour fonctionner sur d'autres systèmes d'exploitation que celui de Microsoft, à savoir Windows. Des tentatives d'adaptation ont été menées et a permis à cette machine virtuelle d'être partiellement disponible sur des systèmes d'exploitation tels que Linux et OS X. Ces tentatives ont donné naissance au projet Mono[11]. En effet, ce projet open-source, basé sur le framework .NET est en cours de développement et met d'ores et déjà à disposition une plateforme permettant le développement/l'exécution d'application sur des systèmes autres que Windows. Cependant, sans ce projet mené par une grande communauté, la portabilité grâce à la plateforme .NET n'est pas assurée. De plus, l'implémentation de Mono peut donner des résultats différents de la plateforme initiale sur Windows.

Maintenabilité[modifier | modifier le code]

La facilité de maintenance est fortement liée à l’environnement de développement, mais aussi par le design des logiciels utilisés pour la programmation et le respect des normes de programmation. Grâce à la séparation de la plateforme J2EE en Modèle Vue Contrôleur, la maintenabilité des applications J2EE est plus facile que sur .NET. De plus, les nombreux langages de programmation qui peuvent être utilisé sur .NET diminue la maintenabilité, dû à la nécessité d’expert dans chacun des langages pour certaines applications.

Coût de développement[modifier | modifier le code]

Concernant le coût de développement d'une application Web, celui-ci est fortement lié au temps de développement et à la maintenance de l'application. Les facteurs à prendre en compte lors du calcul du coût de développement sont donc la durée de développement, la maintenabilité, le prix des différents softwares et hardwares nécessaire au développement. Sur le dernier facteur, la plateforme développée par Sun est plus rentable, étant donné qu'une application J2EE s'exécute sur la quasi-totalité des systèmes d'exploitation contrairement à .NET qui n'est compatible qu'avec des systèmes d'exploitation développés par Microsoft.

Références[modifier | modifier le code]

  1. SUPINFO - Ecole Informatique - Formation en Informatique - Paris, Lyon, Strasbourg, Bordeaux, Toulouse, Nantes, Nice, Montpellier, Marseille, Grenoble, Macon, Lille, Valenciennes, Caen, Rennes, Tours, Orléans, Troyes, Reims, Metz, Clermont-Ferrand,..., « J2EE vs .net : le choix dépend de vos besoins | SUPINFO, École Supérieure d'Informatique », sur www.supinfo.com (consulté le )
  2. (en) « List of CLI languages », Wikipedia, the free encyclopedia, {{Article}} : paramètre « date » manquant (lire en ligne, consulté le )
  3. Jean Michel DOUDOUX, « Développons en Java - Les plate-formes Java et .Net », sur www.jmdoudoux.fr (consulté le )
  4. « XML et interopérabilité des systèmes | Techniques de l'Ingénieur », sur www.techniques-ingenieur.fr (consulté le )
  5. « Interopérabilité Java / .NET : rêve ou réalité ? », sur www.journaldunet.com (consulté le )
  6. (en) Damien Watkins, Mark J. Hammond et Brad Abrams, Programming in the .NET Environment, Addison-Wesley Professional, (ISBN 9780201770186, lire en ligne), page 134
  7. « Niveaux de stratégie de sécurité »
  8. (en) Raquel V.Clark, « J2EE vs. Microsoft Dot Net: A Qualitative and Quantitative Comparison for Building Enterprises Supporting XML-based Web Services », {{Article}} : paramètre « périodique » manquant,‎
  9. (en) The middleware company, « J2EE vs. Microsoft.NET A comparison of building XML-based web services », {{Article}} : paramètre « périodique » manquant, paramètre « date » manquant
  10. « Liste des machines virtuelles Java », Wikipédia, {{Article}} : paramètre « date » manquant (lire en ligne, consulté le )
  11. « About Mono | Mono », sur www.mono-project.com (consulté le )