Die Idee der EJBs ist die Bereitstellung einer Bausteinarchitektur für Geschäftsanwendungen (business applications), die üblicherweise besondere Anforderungen z.B. im Bereich der Skalierbarkeit, der Transaktionssicherheit oder der persistenten Datenhaltung stellen. Ausgehend von der Beobachtung, daß unterschiedliche Varianten von Anwendungsservern (z.B. Transaktionsmonitore, Datenbanksysteme, etc.) am Markt existieren, auf denen die entsprechenden Geschäftsanwendungen ausgeführt werden, ist die Idee, eine generische Ablaufumgebung zur Verfügung zu stellen, die die wesentlichen Basisdienste an einer generischen Schnittstelle bereitstellt. Innerhalb dieser Ablaufumgebung können dann EJBs installiert und zu Geschäftsanwendungen verknüpft werden, die somit auf unterschiedlichen Anwendungsservern identisch ausgeführt werden können. Ein Anwendungsentwickler muß bei der Erstellung einer Geschäftsanwendung keine besonderen Kenntnisse z.B. über die Realisierung von Transaktionsüberwachung haben, sondern kann auf die vom Container angebotenen Dienste zurückgreifen.
Unter EJBs werden in mehreren Anwendungen verwendbare Softwarebausteine verstanden, die auf unterschiedlichen Anwendungsservern installiert und ausgeführt werden können. Im Gegensatz zu den JavaBeans stellen die EJBs ausschließlich relativ grobgranulare Geschäftsobjekte, wie z.B. einen kompletten Bestellvorgang, dar.
Man kann drei grundsätzliche Arten von EJBs unterscheiden: Session Beans , Entity Beans und Message-driven Beans . Im Gegensatz zu den Entity Beans sind Session Beans in ihrer Lebensdauer an ihren Client gebunden und besitzen keinen persistenten Zustand. Die Message-driven Beans halten keinen Zustand und unterscheiden sich von den anderen Typen dadurch, daß sie mit Hilfe des Java Messaging Service (JMS) JMS Java Messaging Service aufgerufen werden (siehe unten).
Session Beans und Entity Beans können mittels Remote Method Invocation (RMI) RMI Remote Method Invocation über ihr Remote Interface aufgerufen werden. An dieser Schnittstelle stellt eine EJB die von ihr angebotene Funktionalität zur Verfügung. Ein Client kann darüber hinaus über das Home Interface der EJB Instanzen des Bausteins erzeugen oder zerstören sowie eine Referenz auf das Remote Interface erfragen.
Wie bereits erwähnt, erfolgt der Aufruf einer Message-driven Bean im Gegensatz hierzu nicht über ihr Remote Interface, sondern über den JMS. Somit wird es möglich, asynchron aufrufbare EJBs zu implementieren.
Im Rahmen der EJB-Spezifikation ist keinerlei standardisierter Mechanismus vorgesehen, über den eine EJB Änderungen ihres Zustands ihrer Umwelt bekannt macht.
Die Anpassung einer EJB an spezielle Anwendungen kann über den Deployment Descriptor erfolgen. Hierbei handelt es sich um eine XML XML Extensible Markup Language -basierte Datenstruktur, die zu jeder EJB Metainformationen enthält, die bei der Installation der EJB in einem konkreten Container ausgewertet werden. Beim Zusammenstellen mehrerer EJBs zu einem Anwendungspaket ist es dem Anwendungsersteller möglich, Eintragungen im Deployment Descriptor vorzunehmen und so die EJB anwendungsspezifisch zu konfigurieren. Dies erstreckt sich insbesondere auf Sicherheitseinstellungen und die Konfiguration der Transaktionsüberwachung.
Da im Gegensatz zu den JavaBeans bei den EJBs kein generischer Mechanismus vorgesehen ist, um Zustandsänderungen an die Umwelt zu propagieren, ist auch keine einfache Verknüpfung von EJBs möglich. Stattdessen erfolgt die Verknüpfung von Beans durch explizite Aufrufe des Remote Interface der jeweils aufzurufenden EJB. Die Verknüpfung gegebener EJBs zu einer Anwendung muß somit im Client durch den Anwendungsentwickler manuell programmiert werden. Somit sind zum heutigen Zeitpunkt auch keine Entwicklungsumgebung en, die eine einfache grafische Verknüpfung von EJBs zu einer Anwendung gestatten, verfügbar.
Da es eines der wesentlichen Ziele bei der Entwicklung der EJBs war, die Entwicklung von Geschäftsanwendungen wesentlich zu erleichtern, werden sehr hohe Anforderungen an die Container gestellt, in denen die EJBs ausgeführt werden. Diese müssen zusätzlich zur Java-Ablaufumgebung eine große Anzahl an Basisdiensten, wie z.B. die Transaktionsüberwachung oder das Persistenzmanagement, anbieten.
Aus diesem Grund erzeugt der Container Klassen, die die Home bzw. Remote Interfaces der EJBs repräsentieren und eingehende Aufrufe an die entsprechende EJB weiterleiten. Es ist also nicht möglich, EJBs direkt ohne Einbeziehung des Containers aufzurufen. Durch diese sogenannte Interception wird der Container somit z.B. in die Lage versetzt, die Transaktionsüberwachung für die jeweilige EJB transparent durchzuführen. Diese muß selbstverständlich geeignete Schnittstellen, wie z.B. für das Rollback einer fehlgeschlagenen Transaktion, anbieten. Wie bereits erwähnt könnte diese Tatsache ausgenutzt werden, um durch Instrumentierung des Containers ebenfalls eine Automation der Managementinstrumentierung zu erreichen.