Primeramente cabe aclarar que:
Un "Java Bean" es un componente utilizado en Java que permite agrupar funcionalidades para formar parte de una aplicación, esto puede ser: un "Java Bean" agrupando información personal, datos sobre un pedimento, requerimientos de ordenes,etc.
Un "Enterprise Java Bean" también agrupa funcionalidades para una aplicación, sin embargo, a diferencia de un "Java Bean" un "Enterprise Java Bean" es un "deployable component", el término "deployable component" implica que existe un ambiente de ejecución , éste ambiente es precisamente un "EJB(Enterprise Java Bean) Container" parte de un java application server .
Un "Java Bean" requiere ser integrado con otros componentes para que éste sea funcional, mientras un "Enterprise Java Bean" a través de un "EJB Container" puede ser activado("deployed").
Un EJB a través de un "EJB Container" ofrece varios servicios y funcionalidades no disponibles en un "Java Bean", algunas son las siguientes:
Esta posiblemente sea la mayor ventaja de un EJB. Cuando se diseña un componente de Software se deben definir varios servicios para su funcionamiento, algunos pueden ser:
Si ocurre un error que procedimiento debe ejecutarse ?
Si la base de datos especificada se encuentra desactivada, existe otra alternativa ?
No fue posible cumplir exitosamente "x" procedimiento, se deben retractar sus acciones parciales o reinvocar la transacción ?
Estos Servicios (comúnmente llamados "Middleware") por lo general son requeridos además de la lógica contenida en los componentes principales, obviamente estos servicios ("Middleware") aún deben ser diseñados, sin embargo, mediante un "EJB Container" se ofrecen estos servicios y es a través de un "Enterprise Java Bean" que es posible desarrollar los componentes principales ("lógica de negocios").
La posibilidad de dividir "Servicios"(EJB Container) de "Componentes Principales"(EJB'S) permite una clara división de trabajo, esto es, un diseñador de "componentes"(EJB's) puede concentrar sus esfuerzos en la "lógica de proceso" sin preocuparse del diseño de servicios. Y de la misma manera un "diseñador" de servicios("Middleware") concentrarse en su área.
Esta división de trabajo trae consigo otra pregunta: Como se logra la interoperabilidad ? La interoperabilidad entre "Servicios" y "Componentes" se debe a la existencia de especificaciones para EJB's, estas especificaciones (parte primordial de J2EE ) definen los requerimientos para un "EJB Container" y los requisitos para un "Enterprise Java Bean".
El uso de especificaciones para EJB's permite que existan diversos vendedores tanto de "EJB Containers" los cuales son incluidos en un java application server , así como "Enterprise Java Bean's" los cuales resuelven algún tipo de lógica.
Lo anterior permite ejecutar cualquier "EJB" en cualquier "EJB Container", esto es, puede adquirir un conjunto de EJB's producidos por Inprise o inclusive desarrollarlos dentro de su empresa y estos podrán ser ejecutados en un "EJB Container" de IBM,Inprise o JBoss.
En lo que se refiere a diferencias en costo y calidad, generalmente estas dependen de las funcionalidades que van más allá de las especificaciones EJB. El "EJB Container" de IBM ofrece una integración más eficiente con sus productos (Domino, DB2), mientras Inprise puede desarrollar su "EJB Container" orientado hacia ambientes financieros, Oracle hacia manufactura y sus productos en "Bases de Datos",etc.
Debido a la solución que intentan ofrecer EJB ("Enterprise Java Beans") su diseño gira alrededor de procedimientos remotos (Vea RMI , lo cual permite la operación de un sistema distribuido.)
Un EJB puede interactuar con una gran gamma de clientes desde: JSP o Servlets , bases de datos , Applets , sistemas ERP (SAP,JDEdward's).
El desarrollar un Sistema con EJB's es sumamente complejo, aunque para ciertas empresas puede presentar una solución ideal, debido a la complejidad-tiempo de ( traduciéndose en costo) para muchas corporaciones EJB's resultan una solución sobrada , denominada en Ingles: "overkill".
EJB's es uno de los principales componentes de J2EE y por esta razón también depende fuertemente de otras partes de J2EE: Como RMI , JNDI y JDBC.
Un Session EJB permite realizar cierta lógica solicitada por un cliente ya sea un JSP|Servlet, Applet e inclusive otro EJB. Existen dos tipos de Session EJB's:
Este tipo de EJB como su nombre lo indica no mantiene estado("Stateless") en el "EJB Container", estos EJB's son utilizados para realizar tareas rutinarias que no requieren identificar o rastrear al cliente, algunos EJB's de este tipo son: operaciones matemáticas complejas, búsquedas generales, etc.
A diferencia de "Stateless (Session) EJB's" este tipo de EJB's permiten mantener la sesión del cliente en el "EJB Container", de esta manera el cliente puede trabajar con cierto juego de datos especifico administrado por el "EJB Container", la aplicación ideal para este tipo de EJB es un componente de compra ("Shopping Cart") el cual puede identificar artículos e información personal del cliente a través de un lapso de tiempo extenso ("Session").
Un Entity Bean a diferencia de un "Session Bean" trabaja en conjunción con un deposito de información (generalmente una base de datos ), esto permite que el EJB manipule información residente en sistemas ajenos al "EJB Container"; en un "Statefull (Session) EJB" si ocurre una falla en el "EJB Container" se pierde toda información, mientras si se utiliza un "Entity EJB" aún permanecerá esta información en el sistema aledaño (generalmente una base de datos ). En otras palabras, un "Entity EJB" manipula una copia | reflejo de información que reside en otro sistema.
Al igual que "Session EJB's" existen dos tipos de "Entity EJB's":
Este tipo de "Entity Bean" requiere que la lógica necesaria para accesar el sistema de información ( base de datos ) se definida manualmente, por lo general esta lógica se encuentra en JDBC y define: como y cuando debe ser accesada|actualizada|guardada la información entre el EJB y la base de datos.
Este "Entity Bean" como su nombre lo indica es manejado por el "EJB Container", a diferencia de un "Bean Managed EJB" donde se requiere definir lógica de acceso manualmente, en un "Container Managed EJB" el "EJB Container" genera toda lógica de acceso para el sistema de información ( base de datos ).
Aparentemente un "Bean Managed EJB" no tiene mucha razón de ser, sin embargo, hay casos donde es empleada lógica de acceso sumamente compleja la cual no es posible generar a través del "EJB Container", es por esto que los "Bean Managed EJB's" permanecerán en existencia a pesar de las facilidades ofrecidas por "Container Managed EJB's"
Un "Messaging EJB" ofrece las funcionalidades de (valga la redundancia) sistemas "Messaging" como MQSeries de IBM o Rendez-Vous de Tibco. A muy grandes rasgos un sistema "Messaging" ofrece el funcionamiento de intermediario para recibir y publicar mensajes ("Messages"), una de las ventajas de un "Messaging System" es que opera en forma asincrónica ("asynchroynous") o "non-blocking".
Un EJB esta compuesto de 4 partes (con la excepción de "Messaging EJB's") las cuales son:
"Enterprise Bean Class"
"Home Interface"
"Remote Interface"
"Deployment Descriptor"