Java Reference
In-Depth Information
wird. Sie ist der Standard, falls für eine Singleton-Bean-Klasse nichts anderes angegeben
ist. Die Deklaration erfolgt durch die Angabe von Annnotationen in Form von Lese- und
Schreibsperren (Read-Write-Locks). Alle Methoden, die mit einer Annotation für eine
Lesesperre versehen sind, können gleichzeitig und auch mehrfach parallel aktiv sein,
sofern keine Methode mit einer Schreibsperre ausgeführt wird. Eine Methode, die mit
einer Schreibsperre annotiert ist, kann niemals parallel mit anderen Methodenaufrufen
auf diesem Objekt ausgeführt werden. Wenn keine Annotation angegeben wird, ist die
Wirkung so, als wäre eine Schreibsperre angegeben. Wenn man sich also bei einer Single-
ton-Bean-Klasse überhaupt nicht um die Synchronisation kümmert, gilt automatisch
Container-Managed Concurrency mit lauter Schreibsperren, die bewirken, dass keinerlei
Parallelität für das Singleton-Bean-Objekt möglich ist. Damit ist die Parallelität so stark
wie irgend möglich eingeschränkt; man ist dafür aber auf der sicheren Seite.
!
Bean-Managed Concurrency: Wenn man eine Singleton-Bean-Klasse entsprechend anno-
tiert, gibt man bekannt, dass sich der EJB-Container nicht um die Synchronisation küm-
mern soll. Man muss in diesem Fall die Synchronisation selbst ausprogrammieren (durch
Verwendung von synchronized, Locks, Semaphoren oder anderen Synchronisationsmit-
teln). Wenn man außer der Angabe der Bean-Managed Concurrency nichts weiter unter-
nimmt, hat man den maximalen Grad der Parallelität, die einer Container-Managed Con-
currency mit Lesesperren für alle Methoden entspricht.
Wenn man den minimalen Grad an Parallelität (Container-Managed Concurrency nur mit
Schreibsperren) erhöht, sollte man sich mit dem Thema Parallelität gut auskennen, denn
Synchronisationsfehler lassen sich in der Regel nur sehr schwer erkennen und beheben.
■
135 Komponentenmodell
Eine EJB-Komponente besteht aus beliebig vielen Klassen der in Abschnitt 13.3 erwähnten
Sorten, wobei es bei den Session Beans die in Abschnitt 13.4 dargestellten Untersorten gibt.
Die Bean-Klassen müssen durch entsprechende Annotationen als solche gekennzeichnet
werden (in früheren EJB-Versionen gab es dafür eine spezielle Konfi gurationsdatei). Für die
Methoden einer Session-Bean-Klasse, die „von außen“ (d. h. von Clients oder von anderen
Komponenten) genutzt werden sollen, muss eine Schnittstelle mit der Annotation @Remote
defi niert werden, die von der Session-Bean-Klasse implementiert wird. Die Schnittstellen
und Klassen werden — wie für Java-Komponenten üblich — in eine Jar-Datei gepackt, in der
sich ein Verzeichnis namens META-INF befi ndet mit einer Manifest-Datei. Diese Manifest-
Datei muss so gut wie nichts enthalten. Für speziellere Anwendungen kann die Jar-Datei
zusätzliche Konfi gurationsdateien enthalten, deren Inhalt aber unglücklicherweise von der
Art des verwendeten Java-EE-Servers abhängig ist. Das Ziel, Komponenten von einem Ser-
ver auf einen Server eines anderen Herstellers unverä ndert zu übernehmen, ist in einem
solchen Fall nicht erreichbar. Wir werden im Rahmen dieser Besprechung auf solche Server-
spezifi schen Konfi gurationsdateien nicht eingehen.
Die Installation (Deployment) einer EJB-Komponente kann bei vielen Servern durch das
Kopieren der Jar-Datei in einen speziellen Ordner des Servers erfolgen. Alternativ bieten
