Java EE: ¿es solo pelusa o es real?

Question

Estoy familiarizado con la pila LAMP y con los años he implementado con éxito un puñado de sitios web basados ​​en ella. He usado todo, desde Apache + modPerl, a PHP, a Ruby y a Rails. Con un buen uso del almacenamiento en caché, mi sitio Rails puede soportar una carga bastante buena, pero no estoy hablando de masivo.

Nunca me gustó Java como un lenguaje, o XML para el caso, y he estado ignorando todo el lado de Java EE. Para aquellos que han tenido una experiencia real y directa en ambos mundos: ¿hay algo realmente genial acerca de Java EE que me falta, o es solo un montón de aire caliente? ¿Qué justifica el alto precio de los servidores de aplicaciones propietarios?

No estoy buscando aquí: Estoy buscando ejemplos concretos de cosas que Java EE realmente clava que faltan de LAMP frameworks modernos, si tales diferencias existen. (Moderno = Rieles, Django, etc.). Alternativamente, únete a esas cosas que LAMP realmente funciona mejor (menos sit ups XML para uno).

+++++ Actualización 16 de octubre de, 2008

estoy triste reportar que la mayoría de las respuestas aquí no son útiles, y simplemente caen en una de dos categorías: "Se escala porque aquí son tres ejemplos de sitios web grandes "y" Se escala porque en realidad es mucho mejor que la pila LAMP ".

He leído bastante, y he llegado a la conclusión de que Java EE solo tiene un truco realmente bueno: transacciones (gracias a Will) y en cuanto al resto puede tener éxito o fracasar por su propio mérito, no hay nada intrínsecamente en el entorno para hacer que crees un sitio web escalable y confiable, de hecho, Java EE tiene bastantes trampas que hacen que sea fácil fallar (por ejemplo, es fácil comenzar a usar beans de sesión sin darte cuenta de que estás pagando ahora por bastante un poco de tráfico de JMS que tal vez se podría haber evitado con un diseño diferente.)

discusión útil

• http://www.subbu.org/blog/2007/10/large-scale-web-site-development
• http://highscalability.com/
• http://www.oreillynet.com/onlamp/blog/2004/07/php_scales.html
• http://www.schlossnagle.org/~george/blog/index.php?/archives/29-Why-PHP-Scales-A-Cranky,-Snarky-Answer.html
• http://blogs.law.harvard.edu/philg/2003/09/20/

Answer 1

El diferenciador clave que Java EE ofrece sobre la pila LAMP se puede resumir en una sola palabra. Actas.

La mayoría de los sistemas más pequeños simplemente confían en el sistema de transacción proporcionado por la base de datos, y para muchas aplicaciones es (obviamente) bastante satisfactorio.

Pero cada servidor Java EE incluye un administrador de transacciones distribuidas. Esto le permite hacer cosas más complicadas, en diversos sistemas, de forma segura y confiable.

El ejemplo más simple de esto es el simple escenario de tomar un registro de una base de datos, colocarlo en una cola de mensajes (JMS) y luego eliminar esa fila de la base de datos. Este caso simple involucra dos sistemas separados, y no se puede realizar confiablemente al costado de una transacción. Por ejemplo, puede poner la fila en la cola de mensajes, pero (debido a una falla del sistema) no eliminar la fila de la base de datos. Puede ver cómo tener una transacción con el proveedor JMS y una transacción separada con la base de datos no soluciona realmente el problema, ya que las transacciones no están vinculadas entre sí.

Obviamente, este simple escenario se puede solucionar, tratar, etc. Lo bueno de Java EE, sin embargo, es que no tiene que lidiar con este tipo de problemas: el contenedor se encarga de ellos.

Y, de nuevo, no todos los problemas requieren este nivel o el manejo de transacciones. Pero para aquellos que lo hacen, es invaluable. Y una vez que te acostumbres a usarlos, encontrarás que la administración de transacciones de un servidor Java EE es un gran activo.

Answer 2

Amazon.com

, eBay, Google - todos ellos utilizan un subconjunto de Java EE y son bastante éxito. Todos ellos usan servlets y JSP

Si intenta usar EJB 1.1 o EJB 2.0, se aplica la escalabilidad. La productividad del desarrollador también se reduce como resultado de dificultar las pruebas unitarias.

Con EJB 3.0, la productividad del desarrollador y la escalabilidad de la aplicación mejoran.

Por lo tanto, dependiendo de lo que necesite su aplicación, use solo las piezas de Java EE que tengan sentido para usted. Haga un POC de muestra (prueba de concepto) usando solo aquellas piezas que piensa usar. Este POC mostrará qué tan bien funcionará la aplicación.

NUEVO Los servidores de aplicaciones Java EE no siempre necesitan una gran cantidad de XML. Le permitirán usar la anotación para realizar la inyección de dependencias y la asignación de bases de datos.

Más del 50% de todo el desarrollo empresarial ocurre en Java EE (cuando digo eso, principalmente usa subconjunto de la pila Java EE. Alguien podría usar EJB de Beans SESSION sin estado, alguien podría simplemente JNDI, alguien podría usar MESSAGE DRIVEN BEAN EJB).

Espero que ayude.

Answer 3

Puede construir aplicaciones realmente grandes y escalables con Java EE, y es ampliamente utilizado en informática empresarial.

Pero:

Mi experiencia con Java EE era bastante malo porque parecía que el 90% del trabajo de mi equipo estaba haciendo era repetitivo y fontanería. Nuestra productividad en ese momento era mucho, mucho más baja de lo que podría haber sido si hubiéramos utilizado una pila de tecnología diferente.

Answer 4

La gran caña de servidores web Java EE (Jboss, WebSphere, WebLogic, etc.) y Windows Server/IIS/ASP.NET están realmente en una liga diferente en cuanto a escalabilidad y rendimiento que su pila de lámparas típica.

Mi equipo es responsable de uno de los sitios de comercio de telecomunicaciones más grandes en los Estados Unidos, manejando millones de visitas por día (una de nuestras bases de datos tiene más de 1000TB de tamaño, para darle una perspectiva).

Usamos una combinación de ASP.NET y WebSphere, así como SAP ISA (que también es una solución Java EE) para diferentes secciones de nuestro sitio, no hay manera de que la pila LAMP pueda manejar este tipo de carga sin escalar a enormes cantidades de hardware ... La sección de pila .NET maneja la mayor parte de la carga y se ejecuta solo en 32 servidores.

Tampoco hacemos nada sofisticado, como usar una solución de tipo memcached o caché HTTP estática ... hacemos caché de llamadas SOAP y llamadas de bases de datos en los servidores de aplicaciones individuales, pero no usamos una base de datos en memoria etc ... nuestra plataforma puede manejarlo hasta ahora.

Así que sí, sus manzanas a las naranjas para comparar este tipo de cosas a LÁMPARA.

Answer 5

El núcleo de Java EE es simplemente un conjunto de interfaces que tienen implementaciones proporcionadas por un contenedor. La mayoría de las aplicaciones no utilizan todas las especificaciones Java EE.

Hay dos aspectos principales de Java EE que la gente piensa cuando lo discuten: EJB y Servlets.

No tengo experiencia alguna con EJB. Uso el Spring Framework y, como tal, proporciona todo el código de "fontanería y repetición" al que se hace referencia en la respuesta de Ben Collins. Proporciona todo lo que necesitábamos que hicieran los EJB, y luego algunas (las transacciones con acceso a bases de datos son para lo que usamos sus características especiales, aunque usamos su contenedor IOC también para la porción Servlet).

Los servlets, sin embargo, son fantásticos. Son una tecnología muy buena y probada.

El núcleo de un servlet es un ciclo de solicitud y respuesta: un usuario solicita algo, y el servidor intercepta la solicitud y proporciona una respuesta basada en él. Se puede realizar un seguimiento de una cadena de solicitudes y respuestas mediante una sesión para un solo usuario.

En cuanto al alto precio de los servidores de aplicaciones propietarios, no tengo idea de por qué el precio es tan alto, pero Apache Tomcat es un muy buen contenedor Servlet y es gratis. Utilizamos Tomcat para pruebas y WebSphere para implementación (Websphere es proporcionado por nuestro cliente para el uso de las aplicaciones).Desafortunadamente, solo Websphere 6 (actualización 11, como descubrimos con consternación, que no tiene la solución para la actualización 13 que permite que las funciones JSTL funcionen correctamente cuando están dentro de una etiqueta JSP), por lo que estamos obligados a usar Java 1.4x, no Java 1.5+.

También hay varios marcos (ver el marco Spring referenciado anteriormente para un ejemplo) que permiten un desarrollo fácil del servlet. Si solo está utilizando esto para HTTP/HTML, hay una gran cantidad de marcos para ayudarlo fácilmente en este desarrollo.

Answer 6

Casi todas las respuestas mencionan lo que se necesita para crear una aplicación Java EE web. Permítanme mencionar otra consideración importante. La mayoría de las empresas tienen requisitos importantes de back-office, donde una aplicación empresarial tiene que integrarse con otras aplicaciones. Esto puede ir desde conectarse a un viejo programa de mainframe COBOL, a una pila LAMP o a una pequeña aplicación de Access que algún contador puso en marcha por la noche, etc. Por lo general, esto significa que necesitará algún tipo de solución de mensajería para obtener 2 o más aplicaciones para conectar juntas. En mi experiencia, he descubierto que el mundo de Java EE se extiende aún más para lidiar con estos problemas de integración que su típica pila LAMP.

Answer 7

Java EE y otros lenguajes de programa se deben tratar como cualquier otra herramienta. Sí, se ha utilizado en entornos empresariales y se necesita una buena artesanía para que estas herramientas funcionen "perfectamente" y se sepa cuándo usarlas. Actualmente estoy trabajando en un entorno de Mainframe y Java EE se usa hasta cierto punto. Si se trata de una transacción de alta velocidad, Java EE sería mi última opción. Si se necesita interoperabilidad multiplataforma, entonces Java EE, XML y servicios web serían más apropiados.

Answer 8

En términos de escalabilidad, Java EE le ofrece grandes opciones que usted no tiene con una pila LAMP, o RUBY. Todas las opciones giran en torno a las aplicaciones de nivel N, mientras que la mayoría de las aplicaciones LAMP y ruby ​​son de 2 niveles.

Estoy desarrollando una aplicación y planeo permitir que las personas accedan a la API a través de la red. Java EE me permitirá escalar fácilmente el nivel medio, sin afectar el nivel de UI. A medida que agrego interfaces a mi aplicación, puedo escalar el nivel medio muy fácilmente.Una pila LAMP no tiene ningún concepto de este, construida en.

así que tengo que las interfaces, la interfaz web, y la API SOAP. Ahora quiero un API de descanso. De acuerdo ... Construye esa interfaz para llegar al nivel medio también ... y agrega más computadoras al clúster ... o ir multicultivo realmente no importa. Este nivel medio es todo EJB, un protocolo más rápido que SOAP en muchos sentidos.

Ahora vamos a decir que quiero añadir la capacidad de SMS de texto a mis usuarios. También necesito hacer esto en base a lo que establecen, y eso proviene de la base de datos. Escalabilidad, quiero desconectar el envío real del texto, desde la realización que las aplicaciones quieren enviarlo. Esto grita JMS. Puedo usar un Timer Bean para apagar cada X cantidad de tiempo, y averiguar qué mensajes deben enviarse, y poner cada mensaje en JMS. Ahora puedo administrar la cola y cuántos procesadores están trabajando en ella, etc. Puedo ver cuántos textos están saliendo. Incluso puedo poner los receptores en otra caja, lo que tiene poco impacto en el rendimiento de mis otros servidores.

Escalado inteligente, puedo ver cuál de mis EJB están siendo golpeado más, y añadir más recursos a los que, mientras que la eliminación de los recursos forman otros. Puedo hacer eso con las colas JMS y cualquier otra parte de la pila de tecnologías de Java EE. No solo obtengo escalabilidad, recibo administración de los recursos de mi servidor.

Dado que LAMP y Ruby aún no tienen una cola JMS para el procesamiento asincrónico, o la capacidad de poner fácilmente la lógica de negocios en un nivel separado, pueden ser más difíciles de escalar con múltiples interfaces. ¿Qué tienes que hacer para arrancar la lógica y ponerla a disposición de una interfaz diferente? Digamos que ahora no solo proporciona una interfaz de usuario web, sino también una interfaz de usuario de escritorio, una interfaz IVR y una interfaz SOAP para su sitio web.

Answer 9

Escalabilidad y otros asuntos de lado, aquí está una cosa simple que no fue mencionado, el cual puede ser una ventaja: es Java.

• Hay una cantidad asombrosa de bibliotecas de terceros disponibles para Java, tanto de propiedad exclusiva como de código abierto. Ahora, estoy seguro de que hay enormes librerías gratuitas para Perl, Ruby, PHP, etc., pero cuando se trata de bibliotecas comerciales para más áreas de aplicación de nicho, no se acercan a Java (y .NET, y probablemente a C++).) Si usted necesita, cualquier biblioteca de terceros especial, por supuesto, depende únicamente del tipo de aplicación que esté creando.
• Creo que hay más desarrolladores de Java en el mundo que desarrolladores para cualquier otra plataforma. (Tal vez me equivoque, pero esto es lo que he oído a veces.)

Al elegir una plataforma en un entorno comercial, ya sea podría resultar importante.

Answer 10

¿Qué justifica el alto precio de los servidores de aplicaciones propietarias

Nada! Es por eso que la abrumadora mayoría de las aplicaciones web de Java se implementan en Tomcat (que es gratis). Aunque Tomcat no es un servidor de aplicaciones Java EE completo, para la mayoría de las aplicaciones es "lo suficientemente completo". Si realmente necesita un servidor de aplicaciones Java EE completo, Glassfish y JBoss son excelentes y gratuitos.