Einführung
Diese Richtlinie konzentriert sich auf das Festlegen von nachrichtengesteuerten Beans. Weitere Anleitungen zu
nachrichtengesteuerten Beans finden Sie unter Richtlinie: Nachrichtengesteuerte Beans. Allgemeine Anleitungen zu EJBs finden Sie
unter Richtlinie: Enterprise JavaBeans.
Nachfolgend sind einige Merkmale von nachrichtengesteuerten Beans aufgeführt:
-
Sie sind statusunabhängig (stateless).
-
Sie geben keine Werte oder Ausnahmen an die Clients zurück.
-
Sie haben keine Schnittstellen, da die Clients nicht direkt auf nachrichtengesteuerte Beans zugreifen, sondern
indirekt, indem sie Nachrichten an die von der Bean bediente Zieladresse (oder den Endpunkt) senden. Es gibt eine
Listener-Methode ("onMessage()" bei nachrichtengesteuerten Beans des JMS), die alle Nachrichten generisch
behandelt. Dies bedeutet, dass die Typprüfung während der Laufzeit stattfinden muss, indem die Operation
"instanceOf()" zum Bestimmen des Typs der empfangenen Nachricht verwendet wird.
Nachrichten können aus allen Komponenten an den Container gesendet werden, einschließlich von anderen EJBs, von
Webkomponenten und von Anwendungsclients. Der Container ruft bei Bedarf nachrichtengesteuerte EJBs zur Behandlung der
ankommenden Nachrichtenereignisse auf. Nachrichtengesteuerte EJBs können direkt auf andere Session- oder Entity-EJBs
oder auf die EIS-Schicht zugreifen, um Nachrichten zu verarbeiten.
Nachrichtengesteuerte Beans festlegen
Nachrichtengesteuerte Beans bieten eine Möglichkeit zur asynchronen Nachrichtenbehandlung. Session- und Entity-Beans
können nur synchron aufgerufen werden. Nachrichtengesteuerte Beans werden im Zuge der Definition des gemeinsamen
Zugriffs für das Gesamtsystem festgelegt. Allgemeine Richtlinien bezüglich des gemeinsamen Zugriffs, z. B. Designmuster
zur Entkopplung von Aufrufendem und aufgerufenem Code, finden Sie unter Richtlinie:
Prallelität. Nachrichtengesteuerte Beans werden normalerweise als Teil der Aufgabe: Beschreibung der Laufzeitarchitektur festgelegt, um den
gemeinsamen Zugriff im EJB-Container zu ermöglichen. Als solche werden sie im allgemeinen nicht direkt aus
Analyseklassen ermittelt, sondern werden so festgelegt, dass sie bestimmte Designprobleme lösen, z. B. das Problem von
Leistung und Verkoppelung.
Gründe für die Einführung von nachrichtengesteuerten Beans:
-
Unterschiedliche Problemstellungen in verschiedenen Softwarebereichen - eine Nachricht kann an eine Warteschlange
gesendet werden, ohne an den Konsumenten dieser Nachrichten gekoppelt zu sein. Außerdem können mehrere Sender und
Empfänger unterstützt werden.
-
Die Leistung wird verbessert, weil sich der Nachrichtensender mit der Verarbeitung befassen kann, anstatt durch
einen synchronen Aufruf blockiert zu werden (wie dies z. B. beim Aufruf einer Entity- oder Session-Bean geschieht).
-
Erhöhte Zuverlässigkeit, weil der Nachrichtensender auch dann funktioniert, wenn die Nachrichtenkonsumenten offline
sind.
-
Weitere Vorteile kann die MOM (Message-oriented Middleware) hinter der Messaging-Schnittstelle bereitstellen, z. B. eine garantierte Nachrichtenübermittlung.
-
Es gibt ein vorhandenes Designelement (z. B. ein traditionelles System), dass Messaging als Kommunikationsmittel
verwendet.
Nachrichtengesteuerte Beans modellieren
Allgemeine Anleitungen zum Modellieren von EJBs finden Sie unter Richtlinie: Enterprise JavaBeans (EJBs) festlegen. Beachten Sie jedoch, dass
nachrichtengesteuerte Beans im allgemeinen als Teil der Prozess-Sicht modelliert werden. Nähere Anleitungen zum
Modellieren von nachrichtengesteuerten Beans in der Prozess-Sicht finden Sie unter Richtlinie: Beschreibung der Laufzeitarchitektur für J2EE-Anwendungen.
Ergebnisse an Nachrichtensender zurückgeben
Nachrichtengesteuerte Beans können Antworten nicht direkt an den Nachrichtensender senden.
Eine typische Strategie für das Senden einer Antwort ist die Einführung einer anderen Zieladresse oder eines anderen
Endpunktes für Antworten. Nähere Einzelheiten zu dieser Strategie finden Sie unter [ROM02].
|