Java EE est-il juste une spécification? Ce que je veux dire, c'est: EJB Java EE?
Java EE est en effet une spécification abstraite . Tout le monde est ouvert à développer et à fournir une implémentation fonctionnelle de la spécification. Les implémentations concrètes sont les soi-disant serveurs d'applications, comme WildFly , TomEE , GlassFish , Liberty , WebLogic , etc. Il existe également des conteneurs de servlets qui implémentent uniquement la partie JSP / Servlet de l'énorme API Java EE, tels que Tomcat , Jetty , etc.
Nous, les développeurs Java EE, devrait écrire du code en utilisant la spécification (c. -à importer uniquement javax.* des classes dans notre code au lieu de classes spécifiques de mise en œuvre tels que org.jboss.wildfly.*, com.sun.glassfish.*, etc.) et nous serons en mesure d'exécuter notre code sur une mise en œuvre (ainsi, sur tout serveur d'application). Si vous connaissez JDBC, c'est fondamentalement le même concept que le fonctionnement des pilotes JDBC. Voir aussi ao En termes simples, qu'est-ce qu'une usine?
Le téléchargement du SDK Java EE à partir d'Oracle.com contient essentiellement le serveur GlassFish avec un tas de documentation et d'exemples et éventuellement aussi l'EDI NetBeans. Vous n'en avez pas besoin si vous voulez un autre serveur et / ou IDE.
EJB fait partie de la spécification Java EE. Regardez, c'est dans l'API Java EE . Les serveurs d'applications Java EE à part entière le prennent en charge dès le départ, mais pas les simples conteneurs JSP / Servlet.
Voir également:
Les implémentations EJB / Spring de Java EE sont-elles différentes?
Non, comme dit, EJB fait partie de Java EE. Spring est un framework autonome qui remplace et améliore de nombreuses parties de Java EE. Spring ne nécessite pas nécessairement Java EE pour fonctionner. Un conteneur de servlet simple comme Tomcat est déjà suffisant. En termes simples, Spring est un concurrent de Java EE. Par exemple, "Spring" (autonome) est en concurrence avec EJB / JTA, Spring MVC entre avec JSF / JAX-RS, Spring DI / IoC / AOP avec CDI, Spring Security avec JAAS / JASPIC, etc.
À l'époque de l'ancien J2EE / EJB2, l'API EJB2 était horrible à implémenter et à maintenir. Spring était alors une bien meilleure alternative à EJB2. Mais depuis EJB3 (Java EE 5), l'API EJB a été beaucoup améliorée en fonction des leçons tirées de Spring. Depuis CDI (Java EE 6), il n'y a pas vraiment de raison de revoir un autre framework comme Spring pour rendre les développeurs plus faciles à développer entre autres la couche service.
Ce n'est que lorsque vous utilisez un conteneur de servlet simple tel que Tomcat et que vous ne pouvez pas passer à un serveur Java EE, Spring est plus attrayant car il est plus facile d'installer Spring sur Tomcat. Il n'est pas possible d'installer par exemple un conteneur EJB sur Tomcat sans modifier le serveur lui-même, vous réinventeriez fondamentalement TomEE.
Voir également: