EJB-Glossar
Unser EJB (3.0)-Glossar entzaubert und erklärt die vielen Fachbegriffe wie beispielsweise Inversion of Control, Configuration by Exception, POJO, POJI, Dependency Injection etc., die durch alle möglichen eZines und Printmedien geistern, und erklärt, was hinter den Begrifflichkeiten steckt. Lesen Sie auch unser Buch EJB 3 komplett, in dem wir die Themen ausführlich erläutern.
Wenn Sie Begriffe vermissen, die Ihrer Meinung nach erklärt gehören oder falls Sie Fragen haben, mailen Sie uns doch einfach unter
Index
A·B·C·D·E·F·G·H·I·J·K·L·M·N·O·P·Q·R·S·T·U·V·W·X·Y·Z·Alle
| A nach oben | ||
| Annotation | Java 5 | Eine Annotation ermöglicht es, Klassen, Methoden und Attribute zu markieren und ggf. mit Zusatzinformationen zu versehen, z. B. @Deprecated oder @Stateless(description=“Eine tolle Bohne”). EJB 3.0 ermöglicht die Verwendung von Annotationen zur Konfiguration von Beans.
|
| Attached Object | EJB 3.0 | siehe JPA-Glossar |
| B nach oben | ||
| Bean-Klasse | EJB 1.x EJB 2.x | Die Bean-Klasse ist das Software-Artefakt einer EJB-Komponente, in der die eigentliche Implementierung der Geschäftslogik vorhanden ist. In der gängigen OO-Schreibweise würde man diese Klasse als Implementationsklasse bezeichnen (z.B. KundeImpl). Im EJB-Bereich wird der Begriff Bean-Klasse verwendet (z.B. KundeBean). |
| Bean- managed Persistence | EJB 2.x | Einer der beiden Persistenzmechanismen für Entity Beans vor EJB 3.0. In EJB 3.0 gibt es den Begriff Bean-managed Persistence so nicht mehr.
Bei den Entity Beans, die Bean-managed Persistence (BMP) verwenden, ist der Entwickler dafür verantwortlich, diese Aufgabe durch Implementierung des entsprechenden Java-Codes zu lösen. Das bedeutet im Wesentlichen, dass der Entwickler die persistenten Attribute der Entity Bean in geeigneter Weise der Persistenzschicht (z.B. den Feldern einer Datenbanktabelle) zuordnen muss. Hierzu implementiert er die Logik für den Zugriff auf die Persistenzschicht (z.B. Datenbank per JDBC oder andere Dritt-Systeme wie SAP per JCA ) in der Bean-Klasse.
|
| BMP | EJB 2.x | Akronym für Bean-managed Persistence |
| Business Interface | EJB 3.0 | Business Interface bezeichnet in EJB 3 POJI-Typ Interfaces. D.h. diese Interfaces dürfen nicht mehr von EJB[Local]Object erben wie dies bei den so genannten Component Interfaces der Fall war.
Session Beans erfordern ein Business Interface. Im Gegensatz zu Entity Beans müssen EJB 3 Entities kein Business Interface mehr aufweisen. |
| C nach oben | ||
| Callback-Methoden | EJB 2.x EJB 3.0 | Bei EJB 2.x wird bei der Implementierung der Bean-Klasse einer EJB-Komponente verlangt, dass diese Klassen entsprechend dem Typ der EJB-Komponente das entsprechende Callback Interface (javax.ejb.SessionBean, javax.ejb.MessageDrivenBean oder javax.ejb.EntityBean) implementieren. Zum Einen kennzeichnen diese Interfaces, um was für einen Typ einer EJB es sich handelt. Zum Anderen definieren diese Interfaces Callback-Methoden, die vom EJB-Container im Lebenszyklus einer EJB-Komponente aufgerufen werden. Der Entwickler ist verpflichtet, die im jeweiligen Interface deklarierten Callback-Methoden in seiner Bean-Klasse zu implementieren.
Bei EJB 3.0 müssen die zuvor genannten Callback Interfaces nicht mehr von der Bean-Klasse implementiert werden. Dies führt zu einer Reduzierung von Entwicklungszeiten und -aufwänden. Um das Einklinken in den Ablauf der Steuerung des Lebenszyklus einer EJB-Komponente zu ermöglichen, gibt es ein Set von vordefinierten Meta-Annotationen. Diese erlauben, beliebige Methoden in der Bean-Klasse zu kennzeichnen, sodass diese in Abhängigkeit der verwendeten Meta-Annotation zu definierten Zeitpunkten aufgerufen werden. Angewendet werden können diese Meta-Annotationen auf alle EJB-Typen. Für das Einklinken in die Steuerung des Lebenszyklus von Session Beans und Message-driven Beans stehen die Meta-Annotationen Siehe auch JPA-Glossar |
| CMP | EJB 2.x | Akronym für Container-managed Persistence |
| Component Interface | EJB 1.x EJB 2.x | Das Component Interface ist die Geschäftsschnittstelle einer EJB-Komponente vor EJB 3.0. Diese kann es in zwei Ausprägungen geben: als lokale Schnittstelle (Zugriffe sind hierbei nur innerhalb des selben Prozesses möglich → siehe Local Interface) und/oder als remote Schnittselle (hierbei können die Client über Rechner- und Prozessgrenzen hinweg auf die EJB-Komponente zugreifen → siehe Remote Interface). Ein Component Interface muss zwangsweise von EJB[Local]Object erben. |
| Configuration by Exception | EJB 3.0 | Der Configuration by Exception-Ansatz ist mit EJB 3.0 eingeführt worden. Ziel dieses Ansatzes ist die Reduzierung von Entwicklungszeiten und Aufwänden für die Konfiguration bzw. Entwicklung von EJB-Komponenten. Der Entwickler soll nur noch in Ausnahmefällen (daher: Configuration by Exception) konfigurierende oder laufzeitsteuernde Angaben für eine EJB-Komponente vornehmen müssen. Nämlich nur in den Fällen, in denen das gewünschte Verhalten von dem definierten und vorgegebenen Standardverhalten für EJB-Komponenten eines Typs abweicht. Es wird also das Ziel verfolgt, die Notwendigkeit der expliziten Angabe von Konfigurationsparametern für allgemein gültiges, erwartetes Verhalten von EJB-Komponenten und Anforderungen an den EJB-Container zu minimieren bzw. zu reduzieren.
Konkret bedeutet dies, dass mit EJB 3.0 eine Menge von Funktionalitäten bzw. Verhaltensweisen von EJB-Komponenten per default voreingestellt sind. Dieses Defaultverhalten sollte den Großteil (80–90%) der typischen Anwendungsfälle der EJB-Komponenten (bzw der jeweiligen EJB-Typen) abdecken. Trifft das Standardverhalten nicht das Anforderungsprofil, dann kann der Entwickler diese Standardwerte bzw. das Standardverhalten leicht übersteuern. Siehe auch JPA-Glossar |
| Container-managed Persistence | EJB 2.x | Einer der beiden Persistenzmechanismen für Entity Beans vor EJB 3.0. In EJB 3.0 gibt es den Begriff Container-managed Persistence so nicht mehr.
Bei der Verwendung von Container-managed Persistence (CMP), brauchen Sie als Entwickler die Logik zur Synchronisation zwischen Entity Beans und Persistenzschicht nicht zu implementieren. Sie wird durch Werkzeuge des Applikationsservers generiert. Die Aufgabe des Entwicklers beschränkt sich auf die Deklaration der persistenten Attribute sowie der Beziehungen zwischen Entity Beans. Die Synchronisation zur Laufzeit wird durch einen speziellen Teil des EJB-Containers - den so genannten Persistenz-Manager - sichergestellt. |
| D nach oben | ||
| DD | EJB 1.x EJB 2.x | Akronym für Deployment Descriptor |
| Detached Entity | EJB 3.0 | siehe JPA-Glossar |
| Detached Object | EJB 3.0 | siehe JPA-Glossar |
| Dependency Injection | EJB 3.0 | Der Begriff Dependency Injection (DI) ist eine spezialisierte Version des Inversion-of-Control-Musters. Martin Fowler hat diesen Begriff in http://martinfowler.com/articles/injection.html eingeführt, da die Charakteristik der Verwendung der Inversion of Control in den aktuell in den Medien stark vertretenen leichtgewichtigen Containern/Frameworks eher den Charakter der Injektion von Referenzen über benötigte Objekte/Klassen hat.
Die Motivation für die Einführung von DI in EJB 3 ist es, für EJB-Komponenten den Zugriff auf Ressourcen bzw. den Erhalt von Referenzen auf Ressourcen zu vereinfachen und damit letztlich auch die Notwendigkeit des Implementierens von Code für den Zugriff über die JNDI API. Dependency Injection bedeutet für die EJB-Technologie, dass der Entwickler den Code für den Erhalt von Referenzen auf Ressourcen mittels der Nutzung der JNDI API nicht mehr selbst implementieren muss, sondern die benötigten Referenzen durch die Verwendung von Annotationen bzw. die Hinterlegung im XML von Deployment-Deskriptoren anfordert. Der Container stellt dann zur Laufzeit die benötigten Referenzen auf Ressourcen zur Verfügung. D.h. EJB-Komponenten fragen nicht mehr aktiv den sie umgebenden Container nach Referenzen, sondern bekommen Referenzen auf Ressourcen von außen durch den Container injiziert. Der Entwickler annotiert dazu mittels Meta-Annotation wahlweise Instanzvariablen oder Setter-Methoden einer EJB-Komponente, wo der EJB-Container die gewünschten Referenzen injizieren (einfügen) soll. Optional kann der Entwickler diese Informationen auch in XML als Deployment-Deskriptor hinterlegen. Der Container sorgt automatisch dafür, dass spätestens vor der Ausführung der ersten Methode der EJB-Komponente die entsprechenden Referenzen der EJB-Komponente zur Verfügung gestellt werden. Die für EJB 3 bevorzugte Variante ist die Nutzung von Annotationen. |
| Deployment-Deskriptor | EJB 1.x EJB 2.x | Der Deployment Deskriptor enthält im XML-Format Informationen für die Generierung und Ausführung von EJB-Komponenten zur Lauf- und Kompilierungszeit. Hierbei handelt es sich um deklarative Programmierung, da der Entwickler Features/Funktionalitäten der EJB-Komponenten durch “einfaches” Angeben bestimmter Schlüsselwörter innerhalb eines Deployment Deskriptors erreichen kann, ohne programmieren zu müssen. Beispielsweise lässt sich darüber die Transaktionalität von EJB-Komponenten steuern. |
| E nach oben | ||
| Eager Load | EJB 3.0 | siehe JPA-Glossar |
| EJB | EJB 1.x EJB 2.x | Akronym für Enterprise JavaBeans, der Bezeichnung des serverseitigen Komponentenmodells der Java EE-Plattform. |
| EJB 3 Entity | EJB 3.0 | In der frühen Phase der Spezifikation von EJB 3.0 wurde der EJB-Typ zur Abbildung und Umsetzung von persistenten Entitäten als EJB 3 Entity bezeichnet. Das hat sich dann zum Begriff Persistent Entity gewandelt. Letzteres ist dem Ansatz geschuldet, dass die Persistenz nicht mehr nur für Java EE, sondern auch für Java SE nutzbar sein soll.
siehe |
| EJB- Komponente | EJB 1.x EJB 2.x | Generelle Bezeichnung der Komponenten. |
| EJB-Typen | EJB 1.x EJB 2.x | EJB stellt ab EJB 2.x drei EJB-Typen zur Verfügung:
Ab EJB 3 gibt es die EJB-Typen oder Ausprägungen:
Anzumerken ist, dass Session Bean und Message-driven Bean mit EJB 3 genereller gesprochen als Enterprise Beans bezeichnet werden und die EJB 2.x Enity Beans nun als als Persitent Entity bezeichnet werden. Siehe auch JPA-Glossar |
| EJB QL | EJB 1.x EJB 2.x | Akronym für EJB Query Language. Beschreibung siehe EJB Query Language |
| EJB Query Language | EJB 1.x EJB 2.x | Die Datenabfragesprache der Enterprise JavaBeans-Komponenten. Angelehnt an SQL, jedoch auf Objekte fokussiert.
Mit EJB 3.0 neu- und weiterentwickelt. Wird ab EJB 3.0 als Java Persistence Query Language (Java Persistence QL) bezeichnet. Siehe JPA-Glossar |
| Embeddable Class | EJB 3.0 | siehe JPA-Glossar |
| Enterprise Bean | EJB 3 | Genereller gesprochen werden Session Beans und Message-driven Beans in EJB 3 als Enterprise Beans bezeichnet.
Anmerkung:EJB 3 Entities oder Persistent Entities werden nicht als Enterprise Beans bezeichnet. Da sie auch in Java SE eingesetzt werden können, wäre die Verwendung des Oberbegriffes Enterprise Bean an dieser Stelle irreführend. Siehe auch JPA-Glossar |
| Entity Bean | EJB 2.x | In EJB 2.x wird der EJB-Typ für persistente Entitäten als Entity Bean bezeichnet.
Mit EJB 3 wird eine persistente Entität nicht mehr als Entity Bean, sondern als EJB 3 Entity oder Persisten Entity bezeichnet. |
| Entity Manager | EJB 3.0 | siehe JPA-Glossar |
| F nach oben | ||
| Fetching-Strategie | EJB 3.0 | siehe JPA-Glossar |
| G nach oben |
| H nach oben | ||
| Home Interface | EJB 1.x EJB 2.x | Das Home Interface einer EJB-Komponente enthält alle Methoden zur Steuerung des Lebenszyklus der EJB-Komponente. Da Clients rein technisch keine Möglichkeiten besitzen, Instanzen von EJB-Komponenten über Rechner- und/oder Prozessgrenzen hinweg erzeugen, löschen oder laden zu können, müssen sie sich dazu an das jeweilige Home Interface der gewünschten EJB-Komponente wenden. Dieses stellt die entsprechenden Funktionalitäten zur Verfügung. Durch die Verwendung vom Home Interface wird eine Entkopplung von Clients und EJB-Komponenten erreicht. Das Home Interface entspricht dem Entwurfsmuster der “Factory Method”.
Konkret gibt es von einem Home Interface zwei Varianten:
 Im Rahmen von EJB 3 sind Home Interfaces für Session Beans keine Verpflichtung mehr. D.h. sie müssen nicht zwingend implementiert werden, jedoch besagt die Spezifikation auch nicht, dass es die Home Interfaces gar nicht mehr gibt. Im Rahmen von EJB 3 besitzen EJB 3 Entities keine Home Interfaces mehr. |
| I nach oben | ||
| Interceptor | EJB 3.0 | Mit EJB 3.0 ist es analog zu CORBA-basierten Systemen, in denen Interceptor-Mechanismen seit langem bekannt sind und eingesetzt werden, möglich, Methodenaufrufe von Geschäftsmethoden abzufangen, die darin enthaltenen Parameterwerte zu untersuchen, bei Bedarf zu manipulieren und die Aufrufe weiterzuleiten oder bei Bedarf abzubrechen bzw. zu verhindern.
Mit dem Interceptor-Mechanismus hält die aspektorientierte Programmierung - zumindest in Ansätzen - Einzug in die EJB-basierte Entwicklung. Interzeptoren ermöglichen das transparente Einflechten von Funktionalitäten (z.B. Logging, Tracing, Zeitmessung, Sicherheitsprüfungen), die Fachliche von technischen Aspekten entkoppeln. Der Entwickler eines Interzeptors kann für eine abgefangene Methode innerhalb des aktivierten Interzeptors beliebigen von ihm hinterlegten Code ausführen zu lassen.  |
| Inversion of Control | EJB 3.0 | Inversion of Control (IoC) ist eine allgemeine Eigenschaft von Frameworks, wird gemeinhin gerne mit dem Satz “don’t call us, we call you” umschrieben. Sie soll ausdrücken, dass die Verantwortlichkeiten bei der Programmausführung beim Framework liegen und nicht bei den Komponenten, die auf Basis eines Frameworks entwickelt und ausgeführt werden.
D.h. das die Komponenten umgebende Framework verlangt von den Komponenten, dass bestimmte Callback-Methoden durch sie implementiert werden, über die das Framework bzw. der Container zur Laufzeit Informationen in die Komponenten injiziert ober bestimmtes Verhalten (über Methodenaufrufe) auslöst. Im Kontext von EJB 3.0 werden IoC und Dependency Injection vielfach synonym verwendet, auch wenn es im Detail sehr wohl Unterschiede gibt (siehe hierzu auch Dependency Injection). Bei EJB 3.0 kommt eine spezialisierte Form von Inversion of Control zum Einsatz. Diese wird als Dependency Injection bezeichnet. |
| J nach oben | ||
| Java Persistence API | EJB 3.0 | Im Rahmen von EJB 3.0 (JSR220 im Java Community Process) ist die so genannte Java Persistence API entwickelt worden. Sie wird der Standard für die Persistenzabbildung im Java EE- und Java SE-Bereich werden.
siehe JPA-Glossar |
| Java Persistence QL | EJB 3.0 | Akronym für Java Persistence Query Language.
siehe JPA-Glossar |
| Java Persistence Query Language | EJB 3.0 | siehe JPA-Glossar |
| K nach oben |
| L nach oben | ||
| Lazy Load | EJB 3.0 | siehe JPA-Glossar |
| Local Home Interface | EJB 2.x EJB 3 | Die lokale Variante des Home Interfaces ist das Local Home Interface. Es ist sozusagen die “Hochgeschwindigkeits-Variante” des Home Interfaces. Das Local Home Interface kommt ausschließlich dann zum Einsatz, wenn sich Client und zu rufende EJB-Komponente im selben EJB-Container (bzw. Prozess) befinden. Analog dem Remote Home Interface dient auch das Local Home Interface dazu, EJB-Komponenten erzeugen, löschen und ggf. laden zu lassen.
Das Local Home Interface ist “schlanker” als das Remote Home Interface, da es nicht über RMI angesprochen werden kann und keine Funktionalitäten für das Packen, Entpacken und Transferieren von Methodenaufrufen zum Transport über das Netzwerk zur Verfügung stellen muss. Die Kommunikation zwischen Client und EJB-Komponente erfolgt mittels In-Prozess-Methodenaufrufen und ist somit schneller als unter Verwendung eines Remote Home Interfaces. Das Local Home Interface ist nicht in der Lage, entfernte Methodenaufrufe zu empfangen.  |
| Local Interface | EJB 2.x EJB 3 | Die technische Ausprägung der Geschäftsschnittstelle einer EJB-Komponente, die ausschließlich die lokale Kommunikation ermöglicht, wird als Local Interface bezeichnet. Lokal bedeutet hier, dass die Kommunikation zwischen Client und EJB-Komponente im selben Prozessraum erfolgt. Wenn eine EJB-Komponente nur ein Local Interface besitzt, so ist es nicht möglich, dass ein Remote-Client auf die entfernte EJB-Komponente zugreifen kann. |
| M nach oben | ||
| Managed Object | EJB 3.0 | siehe JPA-Glossar |
| Message-driven Bean | EJB 2.x EJB 3.0 | Message-driven Beans werden für die Implementierung asynchroner Kommunikation in J2EE bzw. Java EE-basierten Systemen eingesetzt. Message-driven Beans sind Nachrichtenkonsumenten von Message-Brokern. Sie sind in der Lage asynchrone Nachrichten von diesen entgegenzunehmen und zu verarbeiten. Im Kontext von Messaging-Systemen agieren Message-driven Beans somit als Nachrichtenendpunkte, die vom EJB-Container bzw. originär vom JMS-Provider beim Eintreffen von Nachrichten asynchron benachrichtigt werden.
Message-driven Beans besitzen weder ein Home- noch ein Component Interface bzw. auch kein Business Interface. Dies impliziert, dass Message-driven Beans keine Client-Sichtbarkeit haben, d.h. Message-driven Beans (MDB) können niemals direkt von einem Client angesprochen werden. Gänzlich ohne Clients sind MDBs natürlich nicht sinnvoll. Die Clients von MDBs sind Nachrichtensender, die indirekt mit den Instanzen einer Message-driven Bean kommunizieren, indem sie Nachrichten an bestimmte Message Destinations senden. MDB werden für Message Destinations registriert. Diese Registrierung geschieht über die Deployment-Deskriptoren. Damit wird letztlich die Verbindung zwischen einer Message Destination und einer oder mehrerer MDBs hergestellt, welche die Nachrichten aus der Message Destination verarbeiten können. MDBs werden beim Eintreffen dieser Nachrichten benachrichtigt, indem der EJB-Container eine Methode zur Nachrichtenverarbeitung einer Bean-Instanz der registrierten MDB aufruft. Diese Methode implementiert die Geschäftslogik der Bean und erhält als Parameter die empfangene Nachricht aus der Message Destination. MDBs sind zustandslos (aus Client-Sicht) und nicht persistent. Sie ermöglichen die parallele Verarbeitung von Nachrichten durch eine Vielzahl von Instanzen einer MDB. Dies ist ein Performance Booster für die Abarbeitung von hohen Aufkommen von Nachrichten in MOM-basierten Systemen. Message-driven Beans gibt es als JMS Message-driven Bean und Connector-based Message-driven Bean. |
| Meta- Annotationen | EJB 3.0 | Meta-Annotationen sind dynamische Spracherweiterungen der Java-Programmiersprache. Sie sind mit dem JDK 1.5 eingeführt worden. Meta-Annotationen ermöglichen es, direkt im Java-Code Meta-Informationen unterzubringen, die sowohl zur Compile- als auch zur Laufzeit ausgewertet werden können. Diese Informationen können u.a. dafür genutzt werden, um Code zu generieren oder das Laufzeitverhalten eines Objektes bzw. einer Komponente zu steuern. |
| Multi-table Mapping | EJB 3.0 | siehe JPA-Glossar |
| N nach oben |
| O nach oben |
| P nach oben | ||
| Persistence Provider Runtime | EJB 3.0 | siehe JPA-Glossar |
| Persistent Entity | EJB 3.0 | siehe JPA-Glossar |
| Plain Old Java Interface | EJB 3.0 | Der Begriff taucht verstärkt seit 2004 in Fachzeitschriften und eZines im Java-Bereich auf. Mit Plain Old Java Interface (POJI) wird ein normales - nicht durch technischen oder infrastrukturellen Code “verschmutztes” - Java Interface bezeichnet.
Im Kontext von EJB 3.0 wird der Begriff Plain Old Java Interface (POJI) nun auch angewandt. Eine Kernidee von EJB 3.0 ist, dass die EJB-Komponenten aus Sicht des Entwicklers - in ihrer Nutzung und in ihrer Mikroarchitektur so weit vereinfacht werden, dass die Business Interfaces (die Geschäftsschnittstellen) nicht mehr durch technische Codefragmente “verschmutzt” sind, sondern rein fachliche Methodendeklarationen enthalten. Bei EJB-Versionen vor 3.0 war es so, dass in den Component Interfaces |
| Plain Old Java Object | EJB 3.0 | Der Begriff taucht verstärkt seit 2004 in Fachzeitschriften und eZines im Java-Bereich auf. Mit Plain Old Java Object wird eine normale, einfache Java-Klasse (na ja, vielleicht sollte POJO dann lieber POJC heißen ;-) bezeichnet, die nicht durch infrastrukturellen Code, technische Code etc. “verschmutzt” ist, wie dies beispielsweise bei komplexeren Komponenten vorkommt.
Im Kontext von EJB 3.0 wird der Begriff Plain Old Java Object bzw. POJO nun auch angewandt. Eine Kernidee von EJB 3.0 ist, dass die EJB-Komponenten - aus Sicht des Entwicklers - in ihrer Nutzung und in ihrer Mikroarchitektur so weit vereinfacht werden, dass die Bean-Klassen (die Implementierungs-Klassen der EJB-Komponenten) von ihrem Typ her - im Vergleich zu EJB-Vorgängerversionen - als POJOs bezeichnet werden können. |
| POJI | EJB 3.0 | Akronym für Plain Old Java Interface |
| POJO | EJB 3.0 | Akronym für Plain Old Java Object |
| Q nach oben |
| R nach oben | ||
| Remote Home Interface | EJB 1.x EJB 2.x | Das Remote Home Interface ermöglicht es entfernten Clients, über das Netzwerk Anfragen zum Erzeugen, Laden und Löschen von Instanzen zu stellen. Clients kommunizieren mit einem Remote Home Interface über entfernte Methodenaufrufe, die über das RMI/IIOP-Protokoll transferiert werden. Diese Art der Kommunikation ist langsamer als die Kommunikation mittels In-Prozess-Methodenaufrufen innerhalb eines Prozesses. Die Verwendung dieser Ausprägung des Home Interfaces ist notwendig, wenn man Clients, die sich in einem verteilten System auf einem beliebigen Rechner in einem Netzwerk befinden können, eine EJB-Komponente offerieren möchte.
 |
| Remote Interface | EJB 1.x EJB 2.x | Die technische Ausprägung der Geschäftsschnittstelle einer EJB-Komponente, welche die Remote-Kommunikation (also entfernte Kommunikation) ermöglicht, wird als Remote Interface bezeichnet.
Wenn eine EJB-Komponente ein Remote Interface besitzt, ist es Clients in anderen Prozessräumen möglich über das Netzwerk und Rechner- und Prozessgrenzen hinweg auf eben diese EJB-Komponete zuzugreifen. Die Kommunikation erfolgt dabei über RMI/IIOP. Selbst wenn sich Client und EJB-Komponente im selben Prozessraum befinden (z.B. ist der Client auch eine EJB-Komponente, die eine andere EJB-Komponente verwendet), und der Client die EJB-Komponente über ihr Remote Interface anspricht, so erfolgt die Kommunikation für gewöhnlich über RMI/IIOP. Das wäre in diesem Fall eine unnötige Verlangsamung der Zugriffs. Dies könnte durch das Anbieten einer lokalen Geschäftsschnittstelle (Local Interface) sehr einfach behoben werden und somit zu Performanzsteigerungen führen. |
| S nach oben | ||
| Session Bean | EJB 1.x EJB 2.x | TBD |
| SFSB | EJB 1.x EJB 2.x | Akronym für Stateful Session Bean |
| SLSB | EJB 1.x EJB 2.x | Akronym für Stateless Session Bean |
| Stateful Session Bean | EJB 1.x EJB 2.x | TBD |
| Stateless Session Bean | EJB 1.x EJB 2.x | TBD |
| T nach oben |
| U nach oben |
| V nach oben |
| W nach oben |
| X nach oben |
| Y nach oben |
| Z nach oben |
Copyright © 2005–2009 Holisticon AG
Dieses Glossar darf in vollständiger Form und unverändert jederzeit kopiert und kostenlos weitergegeben werden. Der Hinweis auf die Originalquelle http://www.holisticon.de/cms/EJBGlossar/Startseite muss ebenso wie dieser Copyright-Hinweis stets angegeben werden. Es ist nicht zulässig, das Glossar kommerziell zu vertreiben, gegen Entgelt weiterzugeben oder Inhalte zu verändern. Im Rahmen nicht-kommerzieller Verwendungen, beispielsweise Diplomarbeiten, darf das Glossar gerne übernommen werden. Die Verwendung in kommerziellen Zusammenhängen, beispielsweise in öffentlichen oder internen Schulungen, firmeninternen Netzwerken, Publikationen, Produkten etc. ist prinzipiell gestattet, wenn eine entsprechende Meldung an gesendet wird. Die Weitergabe ist sowohl in elektronischer als auch gedruckter Form zulässig. Im Internet zugängliche Kopien sind ebenfalls zu melden.
Hinweis zu den Urhebern der dargestellten Abbildungen: Alle hier wiedergegebenen Grafiken wurden von uns erstellt und sind NICHT von Dritten bezogen!
Nehmen Sie Kontakt mit uns auf!
Ihre Ansprechpartner:
| Stefan M. Heldt | Oliver Ihns |
| Telefon: +49 40 5074 2722 |