Pourquoi les applications Java ont-elles besoin d'un serveur d'applications et de .Net IIS Serveur Web?
Pourquoi y a-t-il tant de confusion dans le monde Java avec divers serveurs comme Apache, Tomcat, JBoss, Jetty, etc. et dans le monde .Net, c’est IIS qui fait ce travail. Je voudrais comprendre la nécessité et l'utilisation de celui-ci et je ne commence pas un Java contre .net.
Il existe plusieurs raisons.
Un serveur d'applications Java EE est un moniteur de transactions pour les composants distribués. Il fournit un certain nombre d'abstractions (nom, regroupement, cycle de vie des composants, persistance, messagerie, etc.) (aide à la création de noms, etc.) pour vous aider à atteindre cet objectif.
Beaucoup de ces services font partie du système d'exploitation Windows. Java EE a besoin de l'abstraction car il est indépendant du système d'exploitation.
Il convient également de noter que la spécification Java EE complète n'est pas nécessaire pour développer des applications Web. JDBC, la partie de Java qui traite des bases de données relationnelles, fait partie de Java SE proprement dit. Java EE ajoute des servlets, qui sont des écouteurs HTTP, et Java Server Pages, un langage de balisage permettant de générer des servlets. Vous pouvez développer des applications Web entièrement fonctionnelles en utilisant uniquement ces technologies et Java SE. Tomcat et Jetty sont deux moteurs de servlet/JSP pouvant remplacer des serveurs d'applications Java EE complets.
Si vous prenez note du fait que .NET a des écouteurs HTTP intégrés dans le module System.Net, vous réalisez que c'est comme si .NET prenait une page de Java et intégrait la fonctionnalité javax.servlet dans la structure.
Si vous ajoutez Spring et une fonctionnalité de messagerie comme ActiveMQ ou RabbitMQ, vous pouvez écrire des applications complètes sans devoir recourir à WebLogic, WebSphere, JBoss ou Glassfish. Vous n'avez pas besoin d'EJB ou de la spécification Java EE complète.
METTRE À JOUR:
Spring Boot offre la possibilité de développer et d'exécuter des applications Java complètes en tant que fichier JAR exécutable. Aucun serveur d'application Java EE n'est nécessaire, uniquement JDK version 8 ou supérieure.
En effet, Sun et Microsoft avaient des objectifs très différents avec leurs logiciels et des moyens de les atteindre.
Dès le début, le mantra de Sun pour Java consistait à "écrire une seule fois, exécuter partout", ce qui a permis de créer autant d'efforts pour la création de _API_s qui spécifient à quoi l'environnement devrait ressembler pour permettre à un morceau de code minimaliste de le faire. emploi.
L'API pour "traiter une requête Web et renvoyer une réponse Web" s'appelait Servlets et a rencontré un franc succès, car elle comble un vide et est bien spécifiée. All Les serveurs Web basés sur Java que je connais permettent d'exécuter des servlets. Une première implémentation d'un serveur Web complet capable de servlets ne comporte que 1500 lignes Plus tard, elle a été étendue pour inclure les JSP afin de fournir du HTML avec un code côté serveur (comme PHP).
Pour que toute solution soit véritablement évolutive, y compris les solutions Web, cela signifie que la charge est si élevée qu’un ordinateur n’est plus assez puissant pour fonctionner seul. Une solution évolutiveDOITêtre capable de s'étendre sur plusieurs ordinateurs conscients les uns des autres, et cette seule exigence apporte BEAUCOUP d'autres choses à la table:
- Le code doit pouvoir invoquer le code exécuté sur un autre ordinateur (EJB).
- Les données doivent être disponibles pour tous les ordinateurs de manière cohérente (base de données).
- L'accès à cette base de données doit être efficace (mise en commun des connexions de base de données). ... et bien plus encore
Sun a ensuite créé des API pour toutes les fonctions jugées nécessaires à son exécution, et l'a baptisée "Java Enterprise Edition" (ces jours-là, le mot "Entreprise" était utilisé pour beaucoup de choses) et a créé un système mettant en œuvre toutes ces fonctions. API que les gens pourraient acheter et utiliser.
La différence entre Microsoft et Sun entre maintenant en jeu. Ici, Microsoft rendrait simplement IIS publique et dirait "utiliser ces API" dans les clients, mais ne souhaite en réalité que quiconque crée un autre serveur fournissant ces API. Parce qu'ils veulent vendre Windows pour l'exécuter!
Sun souhaitait que les gens utilisent le langage à la place. Ils ont donc permis à quiconque d’implémenter la spécification Java EE, mais ils ont dû passer une suite de tests rigoureuse de Sun (et payer) pour pouvoir utiliser use the Marque Java EE. Cela a rendu un grand nombre de serveurs Java EE disponibles, où vous pouvez généralement réutiliser la logique métier principale, mais vous devez configurer le serveur Java EE pour fournir les ressources dont l'application a besoin.
Voir http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers pour connaître l'état des serveurs actuels. Les sources commerciales et les sources ouvertes sont disponibles en fonction de vos besoins. Choisissez celui qui vous convient le mieux.
La raison en est que Java EE est un ensemble d’API bien définies que tout le monde peut implémenter, et qu’ils possèdent.
Tout d’abord, vous pouvez exécuter du code .NET à partir d’Apache avec mod_mono. Il s’agit donc de not / limité à IIS. Il existe également plusieurs autres serveurs Web (Cassini et XPS viennent à l’esprit) qui exécuteront également ASP.NET.
Pour exécuter une application Web dynamique, vous avez besoin d’un serveur Web et d’un serveur d’applications. Parfois, ceux-ci s'intègrent si bien qu'ils semblent être identiques, parfois non.
En ce qui concerne Java, il a toujours pris en charge davantage de plates-formes que .NET et a été plus ouvert. Il a donc été intégré à plus de serveurs Web (sur la pile Linux).
Comme .NET et IIS sont des technologies fournies par Microsoft, ASP.NET et ses aspects de serveur d'applications (aspnet_isapi.dll) ont été fournis avec IIS et les différents programmes d'installation .NET. intégrer avec IIS. Bien entendu, Microsoft ne l’a implémenté que sur leur système d’exploitation et sur leur serveur Web.
Apache est très analogue à IIS et n'a pas grand-chose à voir avec Java.
Les serveurs d'applications en Java fournissent des services supplémentaires fournis par .NET de différentes manières, avec différents produits ou à partir du système d'exploitation Windows.
Apache est généralement utilisé dans les déploiements Java en tant que proxy pour un serveur d'applications situé derrière, et sert potentiellement de contenu statique, ou gère SSL, et des problèmes similaires. C'est totalement facultatif, bien qu'il y ait de bonnes raisons de l'utiliser.
Tomcat et Jetty sont essentiellement des serveurs Web Java, qui fournissent un cadre défini (entre autres des servlets) pour créer des sites Web dynamiques avec du code Java. Ce sont souvent des composants d'un serveur d'applications plus important, ou peuvent être déployés seuls.
JBoss est un exemple de serveur d'application (Glassfish et Weblogic sont deux autres très communs), qui fournit la spécification J2EE complète. L'idée sous-jacente à la spécification J2EE est de permettre à un moyen défini de créer un serveur d'applications afin qu'une application puisse être commutée entre différents serveurs d'applications de différents fournisseurs conformes à la spécification. La spécification concerne la façon d'interagir avec des services définis utiles pour les programmes côté serveur.
Parce que Java EE est une spécification, pas un produit lui-même. N'oubliez pas que Java est beaucoup plus ouvert que .NET (au sens de la spécification).
Chaque serveur d’application a des fonctionnalités différentes, des performances différentes, des utilisateurs/entreprises cibles différents, des étiquettes de prix différentes, s’exécute sur des plates-formes différentes, nécessite un matériel différent. La différenciation est la raison pour laquelle tous les serveurs d’applications existent, une taille unique ne convient pas à tous.
Une des raisons est que l'écriture d'un servlet est aussi simple que l'implémentation de l'interface javax.servlet.Servlet dans une classe concrète. Les conteneurs de servlets ne doivent donc prendre en charge qu’une API assez simple pour s’appeler eux-mêmes serveurs Web. Cela facilite énormément le développement d'un conteneur de servlets en raison de ce contrat de fonctionnalité limité.
Le choix des outils est l’un des avantages et inconvénients de Java. Regardez les cadres de développement Web Java disponibles, vous pouvez les évaluer à volonté, rien que pour décider. en .Net c'est à peu près MVC. Avec les serveurs, c'est relativement simple. La plupart vont à Tomcat s’ils ont besoin d’un serveur Web et JBoss s’ils ont besoin d’un serveur d’applications gratuit. Les raisons en ont déjà été exposées, J2EE est une spécification.