java-ee - the - java ee tutorial español

Java EE: ¿es solo pelusa o algo real? (10)

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 las cosas 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 busco aquí: estoy buscando ejemplos concretos de cosas que Java EE realmente clava y que faltan en los marcos modernos de LAMP, si existen tales diferencias. (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

Me entristece informar que la mayoría de las respuestas aquí no son útiles, y simplemente se clasifican en una de dos categorías: "Se escala porque aquí hay 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 muy bueno: las 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 cree 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 darse cuenta de que está pagando ahora un poco de JMS tráfico que quizás podría haberse evitado con un diseño diferente).

Discusión útil

Escalabilidad y otras cuestiones aparte, aquí hay una cosa simple que no se mencionó, que 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 alguna biblioteca especial de terceros, 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 estoy equivocado, pero esto es lo que he escuchado a veces).

Al elegir una plataforma en un entorno comercial, cualquiera puede resultar importante.

Amazon.com, ebay, google: todos usan un subconjunto de Java EE y tienen bastante éxito. Todos usan servlets y JSP

Si intenta usar EJB 1.1 o EJB 2.0, entonces la escalabilidad es golpeada. 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.

Entonces, dependiendo de lo que necesite su aplicación, use solo las partes 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.

NUEVOS 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, se utiliza principalmente un 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 EJB DE BEBE CONDUCIDO POR MENSAJES) .

Espero eso ayude.

Casi todas las respuestas mencionan lo que se necesita para construir una aplicación web Java EE. 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.

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 escenario simple 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 las arregla.

Y, nuevamente, no todos los problemas requieren este nivel de 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.

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 en los que las personas piensan cuando lo debaten: EJB y Servlets.

No tengo experiencia alguna con los EJB. Utilizo 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 algunas (las transacciones con acceso a la base de datos es para lo que usamos sus características especiales, aunque también usamos su contenedor IOC 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.

En términos de escalabilidad, Java EE te ofrece opciones enormes que no tienes 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 un concepto de esto, incorporado.

Así que tengo que las interfaces, la interfaz de usuario web y la API de 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 digamos que quiero agregar la capacidad de enviar mensajes 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.

En términos de escalabilidad, puedo ver cuáles de mis EJB son los más golpeados, y agregar más recursos a esos, mientras elimino recursos de 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.

Como 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 comercial en un nivel separado, puede ser más difícil 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.

Java EE y otros lenguajes de programa deben tratarse 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.

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

Mi equipo es responsable de uno de los mayores sitios de comercio de telecomunicaciones 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 en absoluto de que la pila LAMP pueda manejar este tipo de carga sin escalar a cantidades masivas. 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 utilizar una solución de tipo memcached o caché HTTP estática ... hacemos caché de llamadas SOAP y llamadas a bases de datos en los servidores de aplicaciones individuales, pero no se usa una base de datos en la memoria, etc. nuestra plataforma puede manejarlo hasta ahora.

Así que sí, sus manzanas a las naranjas para comparar este tipo de cosas con LAMP.

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

Pero:

Mi experiencia con Java EE fue bastante mala porque me pareció que el 90% del trabajo que mi equipo estaba haciendo era repetitivo y de plomerí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.

Lo que 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.