Diferencia Entre EJB Container Y Web Container

supongo que por EJB container te refieres ya a un contenedor JEE. A menos que exista algo como un contenedor de EJB puro, es decir, que puedes meter puros EJB's pero no servlets ni jsp (pero no creo que haya algo asi en la practica, al menos no en forma de un sistema completo; ciertamente es un subsistema de los contenedores JEE).

En Java, web container son los servlet containers. Metes aplicaciones web que tienen servlets y jsp, nada mas. Muy simples en su naturaleza. Como Jetty o Tomcat.

Un contenedor JEE es mas sofisticado, como glassfish o jboss. Jboss por ejemplo, tiene Tomcat como un subsistema para el contenedor de servlets, pero aparte tiene varios servicios adicionales. Un contenedor JEE puede manejar EJB's como servicios para tenerlos disponibles para varias aplicaciones; puede tener tambien un servicio de autenticacion global, pools de conexiones a bases de datos (JCA), manejador de transacciones (JTA), tareas de ejecucion periodica, colas de mensajes JMS, etc.

Gracias Ezamudio,

Muy completo tu comentario sin embargo quisiera preguntarte Si es conveniente cambiar
de JPS Y Servlet A EJB Es decir cambiar a un contenedor JEE para manejar EJB´s Services ????

Gracias por tus comentarios.

Odio los EJB. Los odio con odio jarocho.

En parte Spring nació porque hay gente que los odia todavía más que yo. Y Sun al darse cuenta de lo odiados que eran los EJB's, cuando sacaron la versión 3.0 los hicieron menos odiosos, pero para entonces ya era muy tarde en algunos casos.

Cuando necesito un servicio tipo EJB, normalmente defino una interfaz con lo que necesito, la implemento por medio de un componente normalito (un POJO) y lo meto en un application context de mi aplicación. Los que necesiten referencia al servicio, deben tener una variable privada del tipo de la interfaz y que se auto-conecte (o se conecte manual) con Spring. Si varias aplicaciones necesitan tener el servicio, pues que cada una tenga su instancia singleton del mismo y ya. Y si por alguna razón se necesita tener una sola instancia en todo el contenedor y que todas las aplicaciones utilicen exactamente la misma instancia, entonces simplemente publico el POJO en JNDI con los proxies de Spring (normalmente en una de las aplicaciones, o en un servicio aparte), y en las aplicaciones cliente solamente tengo que definir un proxy JNDI que se conecte al POJO, esto también con ayuda de Spring, nada más indicándole la interfaz que implementa dicho POJO.

Todo esto lo puedo hacer en un contenedor de servlets, no necesito un contenedor JEE. Y en algunos casos ni siquiera necesito contenedor de servlets; todo lo anterior se puede hacer en una aplicación JSE utilizando Spring (lo que se conoce como un contenedor ligero).

@ezamudio: ¿Y como se le hace cuando se necesita consumir ese objeto desde otro nodo? Supongo que habrá una alternativa spring para eso.

Parte del problema de los EJB's es que pretendían ser a prueba de todo y tal como pasa con un auto blindado termina siendo muy pesado. Ya en la v2. algo había una "interfaz local" que servia para precisamente indicar que el ejote lo ibas a consumir localmente ( en el mismo nodo ).

Lo que está padre de lo que dice Enrique, es que la alternativas más ligeras han resultado muy buenas.

@Cesar Sobre la pregunta original, un EJB container, contiene ejb's y un webcontainer, jsp's y servlets ( y otros recursos web ).

Y como se le hace cuando se necesita consumir ese objeto desde otro nodo? Supongo que habrá una alternativa spring para eso.
Yo no soy ezamudio, pero no entendí muy bien tu pregunta, ¿a que te refieres con consumir?, ¿manejar un estado?

Saludos

No, digamos, tienes un objeto en la máquina A y quieres invocarlo desde la máquina B.

Los ejb's soportan esto, pero no sé si con spring haya algo similar.

Los escenarios que menciona Enrique son ( por lo que entiendo ) para llamar dentro de la misma máquina.

Muchas aplicaciones distribuidas no usan al Web para exponer sus servicios. Existen desde hace muchos años y utilizan mecanismos diferentes para la comunicación y para exponer sus servicios a clientes remotos.

Java incorporó desde hace mucho tiempo un middleware para aplicaciones distribuidas, haciendo uso de RMI para la invocación remota de métodos.
RMI fue ideado para aplicaciones distribuidas con componentes escritos estrictamente en Java, como una alternativa ligera de CORBA, que además de un middleware definió muchos de los servicios que las aplicaciones distribuidas necesitan, como los servicios de nombres, servicios de concurrencia, de replicación, de eventos, etc. CORBA sigue vivo y muchas aplicaciones que no hacen uso del Web, están diseñadas con esa tecnología.

EN CORBA se definen IDL´s para casi todos los lenguajes de programación existentes, e igualmente se definen los mapeos correspondientes a esos lenguajes, con el propósito de escribir aplicaciones distribuidas con componentes diseñados y construidos con diferentes lenguajes de programación, como debe ser.

En CORBA se diseña el protocolo IIOP como el protocolo de "alambre" (wire prototocol) que permite la comunicación entre componentes "instalados" en diferentes ORBs (Object Request Brokers).

EJB surge como una alternativa de modelo de componentes de negocio que requieren de los servicios de un contenedor para solucionar los problemas "ajenos" a la lógica de negocio y para ofrecer a los programadores la programación declarativa de esos servicios brindados por el contenedor, haciendo uso de XML en los descriptores de despliegue de la aplicación.

Inicialmente EJB surge como un modelo estrictamente remoto. Los componentes ofrecen sus servicios a los clientes mediante RMI, sean estos clientes delegados de negocio residentes en un Web Tier o aplicaciones standalone.

Muy pronto EJB incorpora el estilo "local" para los componentes de negocio, de suerte que ellos puedan ser usados por aquellos clientes que residen en el mismo espacio de direcciones que el contenedor de EJB, sin la carga de generar proxies.

Muy pronto también se "inventa" RMI over IIOP" como una opción de protocolo de alambre para los EJB remotos, para poder consumir de forma remota componentes de negocio en Java, desde clientes escritos en otros lenguajes de programación.

Lo más relevante de las últimas versiones de EJB es hacer más ligero ese modelo, siguiendo las buenas prácticas de varios marcos de trabajo que surgieron para precisamente hacer menos pesado el diseño del Business Tier de una aplicación empresarial.

Entre las "partes" que componen un servidor de aplicaciones con la tecnología de Java Enterprise Edition está precisamente el contenedor de EJB, que para el Biz Tier cumple funciones similares a un contenedor de servlets en el Web Tier, más otra muchas funciones no necesarias en la grada de gestión de la presentación.

Muchas aplicaciones están diseñadas para consumir funciones de negocio desde clientes remotos usando RMI/IIOP para llegar directamente al Biz Tier. Esas mismas aplicaciones ofrece también algunos de sus servicios a través del Web.

Con Spring puedes tener un POJO en tu application context, registrarlo en el directorio JNDI del contenedor, y con eso queda accesible a otras aplicaciones del contenedor (y con la configuración apropiada, es visible desde fuera del contenedor - por eso mencioné desde el principio que hay que definir una interfaz e implementarla en el POJO).

Spring por supuesto que puede exponer servicios remotos por diferentes vías. De no hacerlo estaría en una gran desventaja con EJB y otros modelos de componentes de negocio que exponen la lógica de negocio a clientes remotos por vías diferentes a Http.

Si se va a usar la capacidad de Spring Remote hay que tener en cuenta sus "desventajas" para aplicaciones que necestian propagar el contexto de seguridad y/o la propagación de transacciones remotas.

Uno de los métodos para exponer remotamente los componentes es precisamente RMI, el cual es usado por muchas aplicaciones que integran componentes hospedados en un contenedor de EJB y también usan Spring en algunos de sus subsistemas.

Con consumir el objeto me daba la idea de que ese guardaba algun tipo de estado y un cliente podria actualizarlo y dejarlo en ceros, jeje.

Pues como te dicen, una buena practica es que por ejemplo en spring tu defines un bean con un id especifico y ese bean debe implementar metodos que tus clientes ocupan. Ya sea que implementes ese bean usando RMI, o una conexion directa a la bd, o usando un web service o abriendo socket TCP o usando el protocolo HTTPInvoker de Spring, a la aplicacion cliente realmente no le interesa, mientras tenga una implementación de esos metodos.

Para la seguridad, si estas utilizando spring puedes hacer uso de la libreria spring-security, que es bastante bueno y te hace la propagación en automático, y de la forma correcta dependiendo el protocolo que estes utilizando.

Sobres

Using Spring's support for RMI, you can transparently expose your services through the RMI infrastructure. After having this set up, you basically have a configuration similar to remote EJBs, except for the fact that there is no STANDARD support for security context propagation or remote transaction propagation.

Spring does provide hooks for such additional invocation context when using the RMI invoker, so you can for example plug in security frameworks or custom security credentials here.

En ocasiones el soporte estándar es un requerimiento de diseño.

Gracias por todos sus comentarios, me ha quedado un poco mas claro todo lo relacionado con mi pregunta original, Gracias @OscarRyz por tu explicacion.

Entonces @ezamudio que me recomiendas usar en luga de EJB, He leido tus comentarios y al parecer Spring es muy bueno pero esto con que se utliza ????

Saludos

al parecer Spring es muy bueno pero esto con que se utliza? [sic]

No entiendo la pregunta. Con qué se utiliza Spring? [insertar aquí la cantaleta estándar de "spring es un framework que hace muchas cosas para que teclees menos códido, porque ya implementa muchos patrones de diseño para que solamente los utilices en vez de tener que implementarlos desde cero" etc etc] En springframework.org encontrarás bastante documentación, puedes bajarla y bajar el framework y ver algunos tutoriales. Aquí mismo en varios blogs (incluyendo el mío) y en varios foros se habla de Spring y todo lo que hace y cómo lo hace.

Lo que te recomiendo es que si vas a usar EJB, uses EJB 3.0 al menos, pero dado que le quisieron copiar a Spring, pues mejor define tus componentes como POJOs y luego los metes en un application context donde conectes todo y los publiques y queden como si fueran EJB pero con menos problemas. Una de las ventajas de Spring sobre EJB's es que puedes probar tus componentes hasta dentro de una aplicación JSE, es mucho más fácil hacer pruebas unitarias con contextos de prueba, no tienes que estar levantando un contenedor y recargando tus componentes cada vez que vas a probar o corregir algo.

Disculpa @ezamudio lo que pasa es que creo que estoy confundiendo los conceptos, como yo apenas estoy adentrandome al mundo Java
Entonce me he dificil comprenderlos, Basicamente mi pregunta sobre lo siguiente yo tengo mi aplicacion hecha en JSP y servlets lo que quiero es mejorarla y pense que utilizando EJB Seria lo ideal, pero ya veo que hay muchas otras cosas.

Entonces mi pregunta es mas orientada a que mas podria utilizar ademas de lo que te mencione, y por lo que veo podria iniciar con un FrameWork como Spring. se que sera dificil pero con la ayuda de este gran foro puedo hacer Cosas interesantes.

Gracias !!!!!!!!!!!!!

Hay un punto importante a entender antes de comenzar a preguntarse qué es mejor, y este punto es que todo depende del uso que le vayas a dar.
Si tienes una aplicación hecha solamente de Servlets la mayoría te podría afirmar que sería mejor si usas JSP's y Servlets, pero si analizamos la aplicación y encontramos que no requiere generar contenido HTML, entonces veremos que la afirmación es incorrecta.
Cada tecnología, marco de trabajo, biblioteca e incluso lenguaje de programación resuelven un determinado tipo de problema. En algunos casos resulta adecuado escoger algunas, en otros casos resulta excesivo, como salir a cazar patos con cañones.
EJB es una tecnología que cubre una necesidad totalmente diferente que los Servlets y JSP's, En algunos casos resulta conveniente usarlos conjuntamente, en otros no, es por eso que tenemos contenedores web como tomcat, contenedores EJB como OpenEJB y servidores de aplicaciones, como Galssfish, que incluyen además de otras tecnologías, los contenedores mencionados anteriormente.
En particular a mí también me gusta mucho Spring, el cual también tiene muchos módulos como el core, Web, AOP, Security, etc, y no necesariamente una aplicación ocupará todos los módulos.
Antes de comenzar a juzgar qué puede ser mejor, resuélvenos las siguientes preguntas:
¿Qué hace tu aplicación?
¿Por qué consideras que la manera la que está hecha tu aplicación no te satisface?
¿Qué quieres mejorar exactamente de tu aplicación?

Que tal amigo, muy buen comentario !!!!

¿Que hace Tu aplicacion ?

Esta hecha en Servlet's y Jsp's y es un formulario inicial donde el usuario ingresa su ID y le muestra informacion de una base de datos.

similar a un estado de cuenta de un banco, donde el usuario ingresa su cuenta y le muestra su estado de cuenta.

¿Por qué consideras que la manera la que está hecha tu aplicación no te satisface?

R= no tanto porque no este satisfecho con mi aplicacion lo que pasa es que quiero mejorarla o implementar nuevas Tecnologias.

¿Qué quieres mejorar exactamente de tu aplicación?

R= La aplicacion funciona bastante bien, lo que quiero es incorporar nuevas tecnologias a mi aplicacion logicamente JAVA.

Espero a ver sido claro con mi idea, Saludos !!!!!!!!!!!!!

Una opción si lo que quieres es adentrarte en otras tecnologías cambiar la forma de acceder a la base de datos.
¿Actualmente usas JDBC?
Si usas JDBC puede considerar explorar utilizar Spring para facilitar el acceso a JDBC:

con lo que aprenderás a familiarizarte con Spring.
Otra opción es explorar las posibilidades de los ORM's

Aquí sería bueno que buscaras un poco de información sobre los ORM's existentes y las ventajas que te ofrece cada uno. Con esto te podrás familiarizar con la especificación JPA, frameworks como Hibernate, Top-Link e incluso iBatis.
Es un buen punto de entrada para explorar otras tecnologías. ¿Qué opinas?

Muchas Gracias por comentar las diferente opciones para adentrarnos a otras tecnologias para acceder a las bases de datos, ya que esto es la esencia de mi aplicacion.

Entonces primero buscar y estudiar las referencias y despues comenzar a cambiar la aplicacion.

!!!!!!

Hola estoy con una gran confusión, debo hacer un requerimiento de envío de correos en una aplicación java y quiero saber si es conveniente utilizar colas de mensajes, ya sea utilizando EJB's con los message Driven Bean ó con Spring usando MDP´s, la verdad soy nuevo en esta onda.
gracias!

hola ezamudio yo quisire saber si me puedes ayudar con unas dudas de J EE? soy nuevo y me confundo con algunos conceptos

Si pones tus dudas en el foro correspondiente, puedes recibir respuestas no solamente mías sino de otros miembros de la comunidad.

mauricio_: si es envío masivo de correos, puedes usar los MDP's como dices, o simplemente hacer tu propio componente que tenga una cola de mensajes a enviar, y los vaya enviando constantemente (cuando haya mensajes), o le pones horarios, etc. Y una interfaz pública para agregar mensajes a dicha cola y es todo.