Juste qu'est-ce que Java EE vraiment? [fermé]

Voici quelques réponses rapidement composées à vos questions...

• Pourquoi les bibliothèques JavaEE ne peuvent-elles pas fonctionner sans serveur d'applications? Les services fournis par JavaEE (container managed transactions, container managed dependency injection, timer service, etc..) impliquent intrinsèquement des serveurs d'applications compatibles JavaEE (par exemple: GlassFish, JBoss, WebSphere, etc...). Par conséquent, les bibliothèques JavaEE ne servent à rien sans un tel conteneur. "Pourquoi ai-je besoin quelque chose d'aussi massif que JBoss juste pour compiler du code simple pour envoyer un e-mail?" Vous ne le faites pas. Il existe des moyens d'envoyer un e-mail sans JavaEE... Mais si vous voulez le faire de la manière JavaEE, vous avez besoin d'un conteneur JavaEE.

• Pourquoi les bibliothèques JavaEE ne sont-elles pas incluses dans le téléchargement JavaSE? La même raison que de nombreuses bibliothèques ne sont pas incluses: ce serait exagéré. Puisque vous ne pouvez même pas utiliser les bibliothèques JavaEE sans serveur d'applications, pourquoi prendre la peine de les inclure? JavaEE doit être téléchargé si et quand un développeur installe un serveur d'applications et décide d'utiliser JavaEE.

• Pourquoi y a-t-il tant d'offres JavaEE? Y a-t-il vraiment" tant de " offres JavaEE? Si oui, veuillez en énumérer quelques-uns. Plus précisément, je crois qu'il existe plusieurs implémentations des mêmes API.

• Que peut-on faire avec JavaEE qu'ils ne peuvent pas faire sans Java standard? Beaucoup. Vous ne pouvez pas compter sur un serveur d'applications pour gérer les transactions ou les contextes de persistance sans JavaEE. Vous ne pouvez pas autoriser un serveur d'applications à gérer l'injection de dépendances EJB sans JavaEE. Vous ne pouvez pas utiliser un service de minuterie géré par application sans JavaEE. La réponse à cette question devrait rendre la réponse à la première question assez claire... La plupart des services fournis par JavaEE nécessitent un conteneur JavaEE.

• Que pouvez-vous faire avec JavaSE que vous ne pouvez pas faire avec JavaEE? La messagerie unifiée... Je ne sais pas.

• Quand un développeur décident qu'ils besoin d' JavaEE? Cette question est complètement subjective... Mais si vous avez besoin de l'un des services fournis par JavaEE, vous commencez à y penser. Si vous ne savez pas ce qu'est JavaEE... vous n'avez probablement pas besoin.

• Quand un développeur décident qu'ils n'ont pas besoin de JavaEE? Voir réponse précédente.

• Pourquoi la version de la bibliothèque JavaEE n'est-elle pas synchronisée avec la version JavaSE? Bien question. Je ne prétendrai pas savoir comment y répondre... Mais je suppose que la réponse est: "parce qu'ils ne sont pas synchronisés".

À vol d'oiseau, Java EE est une plate-forme, c'est-à-dire quelque chose sur lequel nous pouvons construire.

Dans une perspective plus technique, la norme Java Enterprise Edition définit un ensemble d'API couramment utilisées pour la création d'applications d'entreprise. Ces API sont implémentées par des serveurs d'applications - et oui, différents serveurs d'applications sont libres d'utiliser différentes implémentations des API Java EE.

Cependant, la bibliothèque java ee ne fonctionnera pas, ni compiler sauf si votre le code est exécuté sur ou a accès à un serveur d'applications Java EE (tel que JBoss, GlassFish, Tomcat, etc.).

Vous compilez avec les API Java EE, vous n'avez donc besoin que de ces API au moment de la compilation. Au moment de l'exécution, vous aurez également besoin d'une implémentation de ces API, c'est-à-dire d'un serveur d'applications.

Pourquoi ai - je besoin de quelque chose d'énorme comme JBoss juste pour compiler du code simple pour envoyer un e-mail?

Vous ne le faites pas. Cependant, si vous souhaitez utiliser l'API Java EE pour l'envoi de courrier, vous aura besoin d'une implémentation de cette API au moment de l'exécution. Cela peut être fourni par un serveur d'applications ou par une bibliothèque autonome que vous ajoutez à votre classpath.

Pourquoi les bibliothèques Java EE ne sont-elles pas "standard" et incluses dans le téléchargement JVM normal et/ou le SDK?

Car seules les API sont standardisées, pas les implémentations.

Pourquoi y a-t-il tant d'offres Java EE

Parce que les gens ne sont pas d'accord sur la bonne façon de mettre en œuvre certaines caractéristiques. Parce que différents fournisseurs se disputent des parts de marché.

Que peut-on faire avec Java EE qu'ils ne peuvent pas faire avec Java standard?

Puisque les implémentations Java EE sont construites avec "Java standard": Rien. Cependant, tirer parti des bibliothèques existantes peut vous faire économiser beaucoup d'efforts si vous résolvez des problèmes d'entreprise typiques, et l'utilisation d'une API standardisée peut empêcher le verrouillage du fournisseur.

Que peut-on faire avec Java standard qu'ils ne peuvent pas faire avec Java EE?

Rien, puisque Java EE inclut Java SE.

Quand un développeur décide-t-il qu'il "a besoin" de Java EE? Quand un développeur décide-t-il qu'il n'a pas besoin de Java EE?

De manière générale, les API Java EE résolvent des problèmes typiques et récurrents dans l'informatique d'entreprise. Si vous avez de tels problèmes, il est logique d'utiliser les solutions standard, mais si vous avez des problèmes différents, différentes solutions peuvent être appelé pour. Par exemple, si vous avez besoin de parlez à une base de données relationnelle, vous devriez envisager d'utiliser JPA. Mais si vous n'avez pas besoin d'une base de données relationnelle, JPA ne vous aidera pas.

Qu'est-ce que Java EE?

Commençons par la définition de canonicité sur wiki:

Java Platform, Enterprise Edition ou Java EE est l'entreprise d'Oracle Plateforme informatique Java. La plateforme fournit une API et un runtime environnement pour le développement et l'exécution de logiciels d'entreprise, y compris réseau et services Web, et d'autres à grande échelle, à plusieurs niveaux, des applications réseau évolutives, fiables et sécurisées.

Le point principal ici est que Java EE est une plate-forme fournit une API, pas une bibliothèque concrète.

Que faut-il pour Java EE?

La portée principale de Java EE est les applications basées sur le réseau, contrairement à Java SE orienté vers le développement d'applications de bureau avec un support réseau simple. C'est la principale diference entre eux. Évolutivité, messagerie, transactionnement, support de base de données pour chaque application... la nécessité dans tout cela, a augmenté avec l'évolution du réseau. Bien sûr beaucoup de solutions prêtes que Java SE fournit sont utile pour le développement de réseau, Java EE étend donc Java SE.

Pourquoi avons-nous besoin de serveurs d'applications pour exécuter notre code?

Pourquoi avons-nous besoin de systèmes d'exploitation? Parce qu'il y a beaucoup de travail douloureux avec le matériel que nous devons faire pour faire une application encore plus simple. Et sans OS, vous devez le faire encore et encore. Oversimplified OS est juste un conteneur programmatique, qui nous fournit un contexte global pour exécuter nos applications.

Et voici ce que sont les serveurs d'applications. Ils are nous permet d'exécuter nos applications dans leur contexte et nous fournit de nombreuses fonctionnalités de haut niveau nécessaires aux applications réseau d'entreprise à haut niveau de charge. Et nous ne voulons pas écrire nos propres vélos pour résoudre ces problèmes, nous voulons écrire du code qui satisfera nos besoins commerciaux.

Un autre exemple ici pourrait être JVM pour Java.

Pourquoi Java EE ne contient pas de serveur d'applications intégré?

Difficile à dire pour moi. Je pense que cela a été fait pour plus de flexibilité. Java EE dit ce qu'ils doivent faire, ils décident comment le faire.

Pourquoi JVM n'inclut pas Java EE?

Parce qu'ils s'adressaient à différents secteurs du marché. Java EE a un tas de fonctionnalités qui n'est pas nécessaire pour les bureaux habituels.

Pourquoi y a-t-il tant d'offres Java EE?

Parce que Java EE ne décrit que le comportement. Tout le monde peut le mettre en œuvre.

Que peut-on faire avec Java EE qu'ils ne peuvent pas faire avec Java SE?

Pour conquérir Internet. C'est vraiment difficile à faire avec les applets et les sockets Java SE:)

Que peut-on faire avec Java SE qu'ils ne peuvent pas faire avec Java EE?

Comme mentionné ci-dessus, Java EE étend Java SE, donc avec Java EE, vous devriez pouvoir faire tout ce qui est disponible pour Java SE.

Quand un développeur décide-t-il qu'il "a besoin" de Java EE?

Quand ils ont besoin de la puissance de Java EE. Tout ce qui est mentionné ci-dessus.

Quand un développeur décide-t-il qu'il n'a pas besoin de Java EE?

Quand ils écrivent un console ou application de bureau.

Pourquoi les versions de Java SE et Java EE ne sont pas synchronisées?

Java a toujours eu des problèmes avec ses technologies nommant et versionnant. Cette situation n'est donc pas une exception.

Java EE est tout au sujet du concept de conteneur.
Container est un contexte d'exécution dans lequel s'exécutera votre application et qui fournira à ce dernier un ensemble de services. Chaque type de service est défini par une spécification nommée JSR. Par exemple, JSR 907, JTA (java transaction Api) qui fournissent un moyen standard de gérer les transactions distribuées contre différentes ressources.
Il existe généralement de nombreuses implémentations différentes pour un JSR donné, l'implémentation que vous utiliserez dépend du fournisseur de conteneurs, mais cela ne vous dérange pas vraiment car vous êtes sûr que le comportement respecte le contrat prédéfini : l'API JSR.
Donc, pour profiter de Java EE, vous devez exécuter votre application dans un conteneur. Les deux principaux sont EJB et le conteneur de servlet qui sont tous deux présents sur n'importe quel serveur d'applications certifié Java EE.

Le but de tout cela est de définir un environnement d'exécution standard pour permettre d'empaqueter votre application avec seulement l'essentiel, id.heure de l'est. votre affaires. Cela évite de dépendre d'un ensemble inconnu et varié de bibliothèques tierces que vous auriez à empaqueter et à fournir avec votre application autrement, et qui peuvent être des sources de conflit avec d'autres applications sur le serveur. En Java EE, vous savez que toutes les exigences non fonctionnelles standard telles que la sécurité, la transaction, l'évolutivité, l'invocation à distance et bien d'autres seront fournies par le conteneur (factorisé pour toutes les applications s'exécutant à l'intérieur) et vous devez simplement baser votre travail sur son.