Richtlinie: Nachrichtengesteuerte Bean festlegen
Diese Richtlinie beschreibt, wie nachrichtengesteuerte Beans für eine J2EE-Anwendung festgelegt und modelliert werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

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].