Java EE contra Java SE para el desarrollo de aplicaciones web

Question

Lo que me interesa es el grado de desarrollo de aplicaciones web del que estamos hablando.

Existen diferentes niveles de desarrollo de aplicaciones web. Por ejemplo, si me pidieron que desarrollara una aplicación web para tratar con información de clientes de vivienda para una pequeña panadería de mamá y papá (definitivamente no es una situación empresarial), ¿hay algo malo con el uso de Java EE en lugar de Java SE si realmente quiero a.

Sé que podría decir que sería excesivo, y puedo entender que, sin embargo, ¿me voy a encontrar con problemas de desarrollo que no me encontraría con Java SE? En otras palabras, estoy tratando de determinar cuándo se convierte una aplicación web para pequeñas empresas en una aplicación web empresarial. Me parece que debería ser capaz de usar el modelo Java que quiero.

¿Estoy equivocado en mi forma de pensar aquí?

Necesita aclaración aquí si me puede ayudar.

Answer 1

No tome Java EE literalmente. Java EE no es solo empresa desarrollo, per-se.

Java EE le ofrece toda la pila para crear aplicaciones web en Java. Simplemente no puedes hacer desarrollo web en Java de lo contrario.

Conclusión: necesita la pila Java EE, incluso si es una pequeña o mediana empresa. No dejes que el nombre te engañe.

Answer 2

Parece haber cierta confusión sobre el uso de las terminologías Java EE y Java SE. El hecho de que EE se amplíe a Enterprise Edition no significa que solo lo utilicen las empresas.

Java EE resulta ser un conjunto de especificaciones que se agrupan para formar una plataforma. En el momento en que necesite escribir una aplicación web, debe usar las especificaciones de Servlet + JSP al mínimo, que es un subconjunto de la especificación Java EE.

Java SE, por sí solo se utiliza generalmente para escribir aplicaciones independientes. Es mejor referirse a Java SE más como una API o una biblioteca, en lugar de como una especificación, a diferencia de Java EE. Se puede considerar como una plataforma para las aplicaciones "no empresariales".

Answer 3

No hay nada malo con el uso de un contenedor completo de Java EE. Sin embargo, esto generalmente ocurre a costa de la complejidad.

El mínimo que necesita es un contenedor de servlet que es un subconjunto de las especificaciones Java EE.

Los contenedores completos de Java EE tienden a tener más para configurar en ellos que los simples contenedores de servlets que pueden agregar gastos generales que no valen la pena.

La otra cosa a tener en cuenta es Si solo usa javax.servlet para compilar archivos .war, estos son compatibles con los contenedores completos de Java EE por lo que no hay nada que lo impida actualizar en un momento posterior.

Otro punto a tener en cuenta es JBOSS/GlassFish, que implementan la pila completa de Java EE, usan más memoria y pueden tener tiempos de inicio más largos que los de decir tomcat.

Sin embargo, si sabe que va a utilizar más de Java EE en un momento posterior como EJB; entonces comenzaría con el contenedor completo de Java EE.

Para resumir

Personalmente me gustaría empezar a cabo utilizando sólo un contenedor de servlets. (no completo Java EE). Si y solo si necesitaba una pila completa de Java EE, me movería a un contenedor completo de Java EE.