Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
77 Cards in this Set
- Front
- Back
|
Wie sieht die 6-Schichten-Architektur mit allen im Kurs besprochenen Themen aus? |
|
|
|
Was ist eine EJB? |
eine spezielle Javaklasse, deren Methoden Anwendungslogik implementieren |
|
|
Sie zusätzlichen Möglichkeiten bieten EJBs gegenüber gewöhnlichen Javaklassen? |
- wahlweise synchroner oder asynchroner Zugriff |
|
|
Welche Arten von EJBs gibt es? |
Session Beans und Message-Driven Beans. |
|
|
Was sind Session Beans? |
Vor der EJB Version 3.1 unterstützten Session Beans ausschließlich synchrone Methodenaufrufe: der aufrufende Thread -Seit der EJB Version 3.1 unterstützen Session Beans auch asynchrone Methodenaufrufe: der |
|
|
Was sind Message Driven Beans? |
- unterstützen ausschließlich asynchrone Methodenaufrufe und werden stets bei einer Nachrichtenwarteschlange angemeldet. - Über einen vom Application Server bereitgestellten Nachrichtendienst kann ein Client so Nachrichten an die - Diese Reaktion erfolgt asynchron, d.h. der Aufrufer sendet lediglich seine Nachricht und arbeitet dann parallel weiter, ohne auf eine Rückmeldung der Bean zu warten. |
|
|
Wann sind asynchrone Aufrufe sinnvoll? |
- insbesondere für langwierige Abläufe, während derer der aufrufende Thread nicht blockiert bleiben soll. -Bei Web-Anwendungen kann so z.B. ein langes Warten des Browsers auf die Response vermieden werden |
|
|
Welche Arten von SessionBeans gibt es? |
- Stateless Session Beans - Stateful Session Beans |
|
|
Was ist eine Stateless Session Bean? |
- Eine Instanz einer Stateless Session Bean wird einem Client lediglich zur Ausführung - Nach der Abarbeitung der Methode wird diese Zuordnung zum Client wieder gelöst - die Instanz verbleibt in einem Pool, bis sie wieder zur Bearbeitung der Anfrage irgendeines Clients benötigt oder zur Freigabe von Ressourcen zerstört wird. - Eine solche Stateless Session Bean könnte zwar, wie jedes Java-Objekt, einen Zustand haben. - Dies ist jedoch in der Regel nicht empfehlenswert, da mehrere parallel existierende Instanzen einer sonst derartigen Session Bean unterschiedliche - Folglich wird man in einer Stateless Session Bean im Normalfall lediglich Methoden, jedoch keine Attribute implementieren |
|
|
Was ist eine Stateful Session Bean? |
- Eine Instanz einer Stateful Session Bean ist immer exklusiv einem bestimmten Client zugeordnet - für jeden neuen Client wird eine neue Instanz erzeugt und bleibt bis zu ihrer Zerstörung diesem Client zugeordnet. - Falls die Bean-Klasse Attribute besitzt, |
|
|
Wann sollten Session Beans als stateful und wann als stateless realisiert werden? |
- Eine Session Bean sollte nur dann als stateful realisiert werden, wenn das Speichern eines Client-spezifischen Zustands auch tatsächlich benötigt wird. - Beans ohne Zustand sollten dagegen stets stateless sein, da durch die Wiederverwendung der Instanzen für mehrere Clients deutliche Ressourcen-Einsparungen erzielt werden können. - Das Pooling von gerade nicht benötigten Instanzen von Stateless Beans reduziert darüber hinaus den ansonsten durch Zerstören und Neu-Erzeugen von Instanzen verursachten Aufwand, was sich positiv auf die Performanz auswirkt. |
|
|
Was ist ein Pool? |
eine Menge von Ressourcen (z.B. Instanzen von Klassen), die jederzeit einsatzbereit sind und bei Bedarf verwendet werden können. Nach der Verwendung werden sie nicht zerstört, sondern in den Pool zurückgelegt. |
|
|
Ist eine Message Driven Bean grundsätzlich stateless oder stateful? |
grundsätzlich stateless: Alle Nachrichten in der Warteschlange werden an die angemeldeten Instanzen der Bean-Klasse verteilt, dabei findet |
|
|
Aus welchen Gründen können EJBs auf verschiedene Server verteilt werden? |
- Ausfallsicherheit - Verteilen der Rechenlast |
|
|
Wie wird der Zugriff auf Beans, die auf verschiedenen Server gespeichert sind, geregelt? |
- der EJB-Container regelt die transparente Zuteilung von Anfragen der Clients an Instanzen passender EJBs auf erreichbaren, möglichst niedrig ausgelasteten Servern. -Ein Client fordert lediglich eine EJB-Instanz an, deren Anwendungslogik er anschließend ausführt (bzw. er sendet eine Nachricht). - Und selbst wenn (zunächst) die |
|
|
Inwiefern wird bei Session Beans zwischen lokalem und entferntem Zugriff unterschieden? |
- Eine Session Bean musste vor der EJB Version 3.1 ihre Routinen für die Anwendungslogik grundsätzlich über eine Schnittstelle, das so genannte Business Interface, anbieten. - Das heißt, jede Session Bean musste zwangsläufig entweder ein Local Interface (für einen lokalen Zugriff) oder ein Remote Interface (für einen Remote-Zugriff) implementieren und dadurch die Anwendungslogik-Methoden exportieren. |
|
|
Welchen Vorteil hat es, wenn ein Client eine Session Bean über ein Remote Interface anspricht? |
Zugriff auf Beans wird möglich, die auf anderen Servern installiert sind |
|
|
Welchen Nachteil hat es, wenn ein Client eine Session Bean über ein Remote Interface anspricht? |
- alle Parameter müssen serialisiert werden - Parameter werden als Kopie übergeben - Referenzübergabe ist nicht möglich - Dadurch fällt ein Aufwand an, der sich nur lohnt, wenn Bean tatsächlich auf einem anderen Server liegt, sonst ist lokaler Zugriff effizienter |
|
|
Warum ist ein lokaler Zugrif effizienter? |
- Keine Kommunikation über Netzwerk - normale Java-Methodenaufrufe |
|
|
Was bedeutet no-interface-view? |
- Für lokale Zugriffe sind keine Interfaces mehr notwendig (seit EJB 3.1) - Dem Client stehen alle öffentlichen Methoden der Bean zur Verfügung, und die Bean kann direkt, anstatt über ein Interface, angesprochen bzw. referenziert werden. |
|
|
Was ist eine Transaktion? |
eine Folge von Ausführungsschritten, die eine logische Einheit bilden. |
|
|
Was sind die ACID-Eigenschaften einer Transaktion? |
- A: Atomarität - eine Transaktion wird entweder ganz oder gar nicht ausgeführt und ist somit nicht teilbar - C: Konsistenz - eine Transaktion überführt eine Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand - I: Isolation - Transaktionen sind voneinander isoliert und somit dürfen sich zwei Transaktionen nicht gegenseitig beeinflussen - D: Dauerhaftigkeit - Daten müssen nach erfolgreicher Durchführung der Transaktion dauerhaft gespeichert sein |
|
|
Was ist das automatische Transaktionsmanagement des EJB-Containers? |
Container startet eine Transaktion, wenn eine EJB-Methode von einem Client aufgerufen wird und beendet die Transaktion beim Beenden der Methode wieder (implizites Transaktionsmanagement) |
|
|
Was ist explizites Transaktionsmanagement? |
Das Verhalten des Transaktionsmanagements kann konfiguriert werden |
|
|
Was sind Platform Roles? |
Rollen im Prozess der Entwicklung der Plattform selbst, der Werkzeugentwic klung, der Anwendungsentwicklung für die Plattform und für den Anwendungsbetrieb |
|
|
Welche Platform Roles gibt es bei JavaEE und welche Aufgaben haben sie? |
- Enterprise Bean Provider: Erstellung einer oder mehrerer Java Enterprise Beans. Bereitstellung der Enterprise Java Beans für - Application Assembler: Zusammenstellung einer Enterprise Application aus einzelnen Anwendungskomponenten. Bereitstellung für den Deployer - Deployer: Installation von Web-Anwendungen und EJBs in - System Administrator: Einrichtung, Betrieb, Überwachung des Systems. |
|
|
Welche Vorteile hat die Verwendung von Annotationen zur Konfiguration? |
- einfacher und konfortabler, da die Meta-Annotationen direkt an die entsprechenden Quellcodeteile geheftet werden - Damit ist der Bezug zu den Programmteilen direkt vorhanden, was bei einer externen Datei erst noch hergestellt werden müsste |
|
|
Welche Vorteile hat die Verwendung einer xml-Datei zur Konfiguration? |
Änderung der Konfiguration ohne Neuübersetzung möglich |
|
|
Haben Annotationen oder der xml-Deskriptor Vorrang und warum? |
- xml-Desktripor - Das soll insbesondere dem Application Assembler bzw. dem Deployer ermöglichen, bei Bedarf die vom Komponenten-Entwickler per Annotationen vorgenommenen Voreinstellungen einfach über Deskriptoren zu modifizieren. |
|
|
Was ist das Business Interface? |
- ein gewöhnliches Java-Interface, das über eine Annotation als Business Interface ausgezeichnet wird - lokales Interface: javax.ejb.Local - entferntes Interface: javax.ejb.Remote |
|
|
Wann kann die Local-Annotation entfallen? |
wenn z.B. die EJB-Klasse nur ein einziges Interface implementiert und dieses keine der beiden Annotationen aufweist, wird es automatisch als Local Interface interpretiert - Es ist jedoch besserer Programmierstil, immer |
|
|
Wie sieht die grundlegende Syntax eines EJB-Interfaces aus? |
@Local public interface MyEjbInterface { } |
|
|
Welche Einschränkungen gibt es bei Business-Methoden? |
- die Methodenbezeichner dürfen nicht mit ejb beginnen, da es dabei zu Konflikten mit internen Methoden kommen könnte - BusinessMethoden dürfen nicht statisch sein, - alle Methoden müssen als public und dürfen nicht als final deklariert sein - die Parameter von Business-Methoden eines Remote Interface müssen serialisierbar sein. |
|
|
Mit welcher Annotation werden Beans als stateful oder stateless markiert? |
- javax.ejb.Stateful - javax.ejb.Stateless |
|
|
Was besagt die Namens-Konvention von Oracle bzgl. Bean-Klassen? |
Bezeichner enden mit dem Zusatz Bean |
|
|
Woran erkennt das Framework Beanklassen? |
Beanklassen müssen seit EJB 3.0 nicht von einer abstrakten Klasse abgeleitet werden o.ä., sondern das Framework erkennt die Klassen an der Annotation und nicht am Typ |
|
|
Mit Hilfe welcher Mechanismen können nicht mehr benötigt Beans wieder zerstört werden? |
- Timeout Mechanismus - Remove-Methode |
|
|
Wie funktioniert der Timeout-Mechanismus? |
jede für eine gewisse Mindestzeitspanne nicht mehr von ihrem Client benutzte Stateful Session |
|
|
Wie funktioniert die Remove-Methode? |
- Ressourcenverbrauch durch schon längst nicht mehr benötigte Instanzen soll so weit wie - Methode wird mit folgender Annotation versehen: javax.ejb.Remove - Nach Ausführung dieser Methode wird die Instanz durch Container zerstört - Im Standardfall findet die Zerstörung unabhängig davon statt, ob die Ausführung der Remove-Methode fehlerfrei verlief. - Über den optionalen BooleanParameter retainIfException des Remove-Annotationstyps kann eingestellt werden, dass der Container die Instanz nur zerstören darf, wenn beim Aufruf der Remove-Methode kein Fehler (Exception) aufgetreten ist, andernfalls wird die Instanz behalten |
|
|
Was ist eine Callback-Methode? |
- wird nicht vom Client, sondern vom Container beim Auftreten eines gewissen Ereignisses im Lebenszyklus der Bean aufgerufen, so dass die Bean auf dieses Ereignis reagieren kann. - Die EJB-Spezifikation bezeichnet dies als Lifecyle Event Callback. - Ein Ereignis, über das der EJB-Container die Bean durch einen solchen Callback informieren kann, wird als Callback-Ereignis bezeichnet - Eine Rückruffunktion ist eine Funktion, die einer anderen Funktion als Parameter übergeben wird. Von dieser wird sie dann unter bestimmten Bedingungen aufgerufen. |
|
|
Welche Zustände kennt eine Stateless Session Bean? |
- nur den Zustand bereit - sie wartet auf Aufrufe ihrer Business-Methoden |
|
|
Wie sieht der Lebenszyklus einer Stateful Session Bean aus? |
zwei Callback-Ereignisse: das Eintreten in den Bereit-Zustand nach Konstruktion (PostConstruct) und das Verlassen des Bereit-Zustands vor Zerstörung (PreDestroy). |
|
|
Wie sieht der Lebenszyklus einer Stateless Session Bean aus? |
- hat auch einen Bereit-Zustand, in dem sie direkt Anwendungslogik ausführen kann - auch hier gilt, dass bei der Instanziierung zunächst die Dependency Injection und danach der PostConstruct-Callback ausgeführt werden. - Bei ihrer Zerstörung findet ebenfalls ein PreDestroy-Callback statt. - Da für jeden Client eine eigene Instanz der Stateful Session Bean angelegt wird und - In diesem Fall kann der EJB Container - Ruft der Client einer passivierten Bean eine Business-Methode auf, so wird die Bean zunächst vom Container wieder aktiviert, und anschließend wird die Business-Methode ausgeführt |
|
|
Welche Callback-Ereignisse hat eine Stateless Bean zusätzlich? |
Ein PrePassivate-Callback findet statt, bevor die Passivierung eingeleitet wird, ein PostActivate-Callback wird nach Abschluss der Reaktivierung ausgelöst, aber noch vor der Ausführung der Business-Methode, deren Aufruf |
|
|
Was geschieht bei der Passivierung einer Bean? |
dann findet eine Serialisierung und Auslagerung des gesamten Conversational State der Stateful Session Bean statt |
|
|
Wann kann es sinnvoll sein, die Callback-Methoden für die Passivierung zu implementieren? |
- Wenn im Conversational State gehaltene so genannte open resources wie z.B. offene Socketverbindungen zur TCP/IP-Kommunikation nicht passiviert werden können. - Sie werden später wieder hergestellt - Eine solche Verbindung muss vielmehr vor der Passivierung geschlossen und kann nach der Reaktivierung wieder geöffnet werden. |
|
|
Was geschieht, wenn der Zustand einer zu passivierenden Bean nicht serialisierbar ist? |
Der Container darf sie zerstören statt sie zu passivieren |
|
|
Was sind Interceptors? |
- Objekte, die einen Methodenaufruf abfangen und vor / nach Ausführung der Methode bestimmte Aktionen durchführen - Einfache Java-Klassen - Zur Laufzeit wird automatisch eine Instanz - Dieses Interceptor-Objekt muss über eine (oder mehrere) Methoden verfügen, die an die Business-Methoden von EJBs angehängt oder ihnen vorangestellt werden. |
|
|
Wann ist der Einsatz von Interceptoren sinnvoll? |
- redundanter Code kann vermieden werden, wenn er sonst für mehrere Methoden aufgerufen werden müsste - Es kann verhindert werden, dass die Geschäftsmethoden Code enthalten, der gar nicht zur eigentlichen Aufgabe gehört |
|
|
Welche Alternative gibt es zur Implementierung einer Interceptor-Klasse? |
- Anstatt eine Interceptor-Klasse zu implementieren, ist es ebenso möglich eine Interceptor-Methode direkt in eine EJB-Klasse zu integrieren. - Eine solche Methode wird dann |
|
|
Wie muss eine Interceptor-Methode aussehen? |
- markiert durch javax.Annotation.AroundInvoke - erhält als Übergabe ein Objekt vom Typ javax.interceptor.InvocationContext - darf beliebigen Zugriffsmodifikator tragen - darf nicht static oder final sein - Damit die so erstellte Interceptor-Methode nicht anstelle einer Business-Methode, sondern, um sie herum“ ausgeführt wird, muss die Stelle im Code der Interceptor-Methode, an der die Business-Methode eingeschoben werden soll, durch einen Aufruf der Methode proceed() des als Parameter übergebenen InvocationContext-Objekts markiert werden. - Alle Anweisungen der Interceptor-Methode, die vor diesem proceed-Aufruf stehen, werden also vor der Anwendungslogik eingeschoben, alle Anweisungen nach dem proceed-Aufruf danach. - Da die eingeschobene Business-Methode ein Funktionsergebnis zurückgeben könnte, gibt die proceed-Methode ein Object aus, das seinerseits von der Interceptor-Methode zurückzugeben ist |
|
|
Welchen Vorteil haben Interceptor-Klassen? |
Sie können von mehr als einer EJB-Klasse verwendet werden |
|
|
Wie erhält der Client eine Instanz einer EJB? |
- er darf new nicht selbst aufrufen - er muss eine Instanz vom EJB-Container anfordern - Implementiert die Bean ein Business Interface, wird dabei keine direkte Referenz auf die Bean-Instanz erworben (was bei entfernten EJBs auf anderen Servern auch gar nicht möglich wäre). - Dieser ganze Mechanismus wird vom EJB-Container bereitgestellt und ist für den Client transparent: Aus seiner Sicht wird ein Objekt vom Typ des Business Interfaces bezogen, auf welchem die Business-Methoden aufgerufen werden können |
|
|
Was ist ein Stub? |
Ein Stub bezeichnet Programmcode, der einen anderen Programmcode ersetzt, z.B. wenn sich dieser Programmcode auf einem anderen Computer befindet. Unter einem Stub Objekt versteht man einen (Client-seitigen) Stellvertreter für ein entferntes Objekt, das auf einem Server |
|
|
Welche Möglichkeiten gibt es für einen Client, eine EJB vom Container anzufordern? |
- Dependency Injection - Lookup-Anweisungen |
|
|
Was ist Dependency Injection? |
- Client enthält ein Attribut vom Typs des Business Interfaces oder der zu beziehenden Klasse - Das Attribut wird mit einer Annotation des Typs javax.ejb.EJB - Wird ein Business Interface verwendet, bestimmt dessen Art (Local oder Remote) die Zugriffsart. - Falls zu einer Session Bean sowohl - Der Container sorgt dann zur Laufzeit - Damit die Dependency Injection funktionieren kann, muss der Client in einem Java EEContainer ausgeführt werden, der seine Komponenten introspiziert und dabei nach solchen EJB-Annotationen sucht |
|
|
Welche Container introspizieren ihre Komponenten? |
- Webcontainer - EJB Container - Client Container |
|
|
Was ist Introspektion? |
- Programm kennt seine eigene Struktur - In der objektorientierten Programmierung erlaubt Introspektion die Sammlung von Info rmationen über Klassen oder deren Instanzen zur Laufzeit des Programms |
|
|
Was ist JNDI? |
- Java Naming and Directory Interface - ein server-übergreifend arbeitender Namens- und Verzeichnisdienst zur Referenzierung von Ressourcen, die über mehrere Server verteilt sind - Ressourcen werden unter einem JNDI-Namen verzeichnet und können anhand dieses Namens über einen Lookup lokalisiert werden - Namenszuordnungen werden in |
|
|
Was ist ein Kontext? |
- eine Menge von Paaren aus jeweils einem Namen und einer an diesen Namen gebundenen Ressource. - Dabei kann eine solche Ressource wieder ein Kontext (Subkontext) sein, d.h. die Kontexte können hierarchisch organisiert werden. |
|
|
Was ist der InitialContext? |
Ausgangspunkt für JNDI-Lookups |
|
|
Wann wird zu Remote Interface im Glassfish ein JDNI-Eintrag angelegt? |
- Automatisch bei deren Deployment - qualifizierter Klassenname wird als JNDI-Name verwendet, sodass der Client sie darüber direkt mit einem Lookup ansprechen kann |
|
|
Wie arbeitet der Container beim Verwenden einer Session Bean über ein Local Interface? |
- er legt nicht automatisch einen JNDI-Namen an - Client muss eine – beim Deployment durch seinen Container ausgewertete – Deklaration vornehmen, welche EJB-Klasse er benötigt und unter welchem JNDI-Namen er sie im Namensverzeichnis erwartet |
|
|
Wie kann der Client angeben, unter welchem Namen er welche EJB-Klassen erwartet? |
- Falls Teile des Clients introspiziert werden (bei einer Web-Anwendung z.B. - Bei einer Web-Anwendung kann ein Eintrag im Deployment Decriptor web.xml angelegt werden, der insbesondere die EJB-Klasse und den gewünschten JNDI-Namen spezifiziert |
|
|
Wie wird eine Message Driven Bean angesprochen? |
- verfügt nicht über ein Business Interface - wird angesprochen über einen Nachrichtendienst - wird dazu bei einer Nachrichtenwarteschlange als Nachrichtenempfänger registriert - JavaEE bietet als Nachrichtendienst Java Message Server (JMS) an - Die Implementierung der Message Driven Bean ist vom Nachrichtendienst abhängig |
|
|
Welche Klassen können als Nachrichtenempfänger fungieren? |
- alle Klassen, die das Interface - Dieses Interface exportiert eine einzige Methode, die von der Empfängerklasse zu implementieren ist und zur Übergabe der - In dieser Methode ist die Reaktion auf die Nachricht zu implementieren. - Natürlich darf die Empfängerklasse zusätzlich weitere Methoden implementieren, die ihrerseits durch die Methode onMessage aufgerufen werden können. |
|
|
Wie wird ein Nachrichtenempfänger zu einer Message Driven Bean? |
durch Annotation des Typs javax.ejb.MessageDriven |
|
|
Wie wird eine Message Driven Bean an einer Nachrichtenwarteschlange angemeldet? |
- Diese Aufgabe gehört laut EJB-Spezifikation zwar in den Verantwortungsbereich des Deployers und nicht des die Bean implementierenden und bereitstellenden Bean Providers. - Jedoch kann der Bean Provider Vorschläge unterbreiten, und ein Application Server kann (muss jedoch nicht) in der Lage sein, diese Vorschläge auszuwerten und umzusetzen, so lange der Deployer sie nicht überstimmt. - Der Bean Provider kann im optionalen Parameter mappedName des MessageDrivenAnnotationstyps den JNDI-Namen der Warteschlange angeben, von der die Bean mit Nachrichten versorgt werden soll - dies ist jedoch produktspezifische Notation ist, die nicht von jedem Application Server unterstützt wird |
|
|
Welche Methodenaufrufe werden bei Message Driven Beans durch den AroundInvoke-Interceptor abgefangen? |
nur die Aufrufe der onMessage-Methode, nicht die durch onMessage ausgelösten Sub-Aufrufe von Methoden |
|
|
Wie wird eine Message Driven Bean angesprochen und zur Ausführung von Anwendungslogik veranlasst? |
- eine Nachricht wird an Warteschlange gesendet - Dabei ist es für den Client irrelevant, ob es sich bei dem Nachrichtenempfänger überhaupt um eine EJB handelt oder um irgendeinen anderen Nachric htenempfänger. - Falls eine Message-Driven Bean immer dieselbe Aktion ausführen soll und dazu auch - Erwartet sie jedoch Eingaben oder soll sie gar mehrere alternative Aktionen anbieten, so müssen alle benötigten Informationen als Nachrichteninhalt übermittelt werden. - Der vom Empfänger erwartete Aufbau einer Nachricht, also seine Eingabeschnittstelle, sollte gut dokumentiert werden |
|
|
Welche Inhalte hat eine Nachricht? |
- Message Body als Nachrichteninhalt - Weitere Message Properties, die jeweils |
|
|
Wie wird eine Verbindung zur Nachrichtenwarteschlange hergestellt? |
- zwei Ressourcen werden benötigt - Die Warteschlange selbst sowie eine zur Herstellung der Verbindung zu dieser |
|
|
Welche Rückmeldung erhält ein Client direkt nach dem Senden einer Nachricht? |
- sie informiert ihn darüber, ob der Nachrichtenversand an die Message Queue funktioniert hat (falls nicht, wird eine Exception ausgelöst). - Danach arbeitet der Client parallel weiter, während die Nachricht letztendlich von der Queue an die Message-Driven Bean - Es existiert also kein direkter Rückkanal von |
|
|
Wie kann der Client ausführlichere Rückmeldungen nach dem Senden einer Nachricht erhalten? |
- Über Einträge in Logdateien - Überwachung eines Datenbankstatus - Beans schreiben Rückmeldungen in ein temporäres Verzeichnis, aus dem der Client dieses dann auslesen kann |
|
|
Was ist beim Hinterlegen von Informationen für Clients zu beachten? |
- mehrere Instanzen einer Message-Driven Bean können parallel für verschiedene Clients arbeiten - somit können Informationen für mehrere Clients gesammelt werden. - Es wird daher ein Mechanismus benötigt, der einem Client ermöglicht, genau die für ihn bestimmten Rückmeldungen abzurufen. |
|
|
Wie funktioniert der optimistische Zeitstempel-Mechanismus? |
- aktueller Zeitstempel wird beim Senden einer Nachricht im Client gespeichert und in die Nachricht integriert - Die Message-Driven Bean, die auf die Nachricht reagieren soll, erstellt ein - Nun kann der Client anhand des Zeitstempels eines Ergebnis-Objektes überprüfen, ob es sich um das Ergebnis-Objekt seiner Berechnungs-Anfrage handelt. - Dieser Mechanismus ist sehr optimistisch, da es passieren kann, dass zwei Clients den gleichen Zeitstempel verwenden. |
|
|
Warum ist es in Webanwendungen nicht möglich, dass die Message Driven Bean Nachrichten an eine Warteschlange sendet, die auf der Clientseite durch einen Nachrichtenempfänger abgefangen wird? |
- Der Client einer Message-Driven Bean ist eine Web-Komponente - diese kann lediglich auf Requests des Web-Clients reagieren. - Hat sie einmal ihre Response an den Web-Client zurückgeschickt, kann sie mit - sie kann nicht ihrerseits asynchron den Web-Client nachträglich kontaktieren. - Vielmehr erfolgt die Kommunikation zwischen Web-Client und Web-Server ausschließlich synchron und Client-gesteuert. - Die einzige Möglichkeit des Web-Clients, nachträglich Informationen zu einem früher asynchron gestarteten Vorgang zu bekommen, ist das so genannte Polling, d.h. regelmäßiges aktives Nachfragen, ob inzwischen Ergebnisse (z.B. im Log, einer Datenbank oder einem wie oben beschriebenen Rückmeldungsverzeichnis) vorliegen. |
