Richtlinie: Beschreibung der Laufzeitarchitektur für J2EE-Anwendungen
Diese Richtlinie beschreibt, wie die Laufzeitarchitektur einer J2EE-Anwendung modelliert wird.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

Die Laufzeitarchitektur einer Anwendung wird in der Prozess-Sicht beschrieben. Dies ist eine Architektursicht, die die gleichzeitig ausgeführten Elemente eines Systems beschreibt. Diese Richtlinien enthalten eine spezielle Anleitung zum Modellieren der Prozess-Sicht für eine J2EE-Anwendung.

Lesen Sie hierzu auch den Abschnitt Konzept: Prozess-Sicht.

Prozess-Sicht modellieren

J2EE-Komponenten (siehe Konzept: Überblick über J2EE: J2EE-Komponenten) werden in Umgebungen implementiert, die als Container bezeichnet werden. Eine Beschreibung aller durch J2EE definierten Containertypen finden Sie unter Konzept: Überblick über J2EE: J2EE-Container.

Jeder Container ist ein gleichzeitig ausgeführtes Element und sollte daher in der Prozess-Sicht der Architektur erscheinen. Weitere wichtige gleichzeitig ausgeführte Elemente, die normalerweise in der übergeordneten Prozess-Sicht erscheinen, sind externe Systeme.

Nachfolgend ist ein typisches Diagramm der übergeordneten Prozess-Sicht für eine J2EE-Anwendung aufgeführt.

Im Begleittext beschriebenes Diagramm.

In einem realen Beispiel würden eine herstellerspezifische MOM (Message Oriented Middleware) sowie bestimmte traditionelle Systeme und Anwendungsclients dargestellt werden. Webcontainer und EJB-Container sind hingegen Standardcontainer, die in jeder J2EE-Prozess-Sicht enthalten sein sollten.

Beachten Sie, dass die physische Verteilung dieser Systeme auf bestimmten Hardwareknoten in diesem Diagramm nicht dargestellt ist. Sie finden dies im Implementierungsmodell (siehe Richtlinie: Beschreibung der Verteilung für J2EE-Anwendungen).

In diesem Beispiel ist der ausgewählte Mechanismus für die Interprozesskommunikation zwischen den Containern dargestellt. J2EE stellt folgende spezielle Mechanismen für die Interprozesskommunikation bereit:

  • Java Remote Method Invocation (RMI) für die synchrone Kommunikation zwischen Java-Klassen
  • RMI-IIOP für die Zusammenarbeit mit CORBA-Clients (normalerweise traditionelle Anwendungen)
  • HTTP/HTTPS für die Kommunikation mit webbasierten Clients (obwohl auch andere Webprotokolle unterstützt werden können, beispielsweise bei der Interaktion mit XML-Web-Services)
  • Java Message Service (JMS) für Messaging (Nachrichtenaustausch) und Interaktionen mit Message Oriented Middleware (MOM)

Bei der Definition der Prozess-Sicht muss eine wichtige Entscheidung bezüglich der Verwendung von JMS versus RMI oder RMI-IIOP getroffen werden. In diesem Beispiel verwenden der Anwendungsclient, der EJB-Container und ein weiteres traditionelles System das Messaging zur Kommunikation. Allerdings ist nicht klar, welche Elemente mit welchen anderen Elementen kommunizieren. Um diese Mehrdeutigkeit aufzulösen, könnten Sie in Erwägung ziehen, das MOM-System aus dem Diagramm zu entfernen, und JMS als Zuordnung zwischen den Elementen darzustellen, die über Messaging kommunizieren.

Eine weitere Unklarheit besteht darüber, ob EJBs untereinander über Messaging kommunizieren. Diese Unklarheit kann beseitigt werden, indem eine JMS-Zuordnung vom EJB-Container auf diesen selbst dargestellt wird. Das endgültige Diagramm sieht dann wie folgt aus:

Im Begleittext beschriebenes Diagramm.

Die Prozess-Sicht besteht jedoch nicht nur aus Containern und übergeordneten Systemen. Sie beschreibt auch gleichzeitig ablaufende Prozesse (Parallelität) innerhalb dieser Container und Systeme.

Die Prozess-Sicht sollte folgende Arten von aktiven Klassen festlegen und modellieren.

  • Java-Threads
  • Nachrichtenziele
  • Nachrichtengesteuerte Beans (weil sie asynchron über Nachrichten aufgerufen werden). Spezielle Stereotypen, die zum Modellieren von nachrichtengesteuerten Beans verwendet werden, finden Sie unter Richtlinie: Enterprise JavaBeans festlegen.
  • Zusätzliche Prozesse, die Teil des Designs des Gesamtsystems sind. Ein Beispiel für einen solchen Prozess ist ein separater Zeitgeberprozess.

Bei Verwendung von JMS können Sie Nachrichtenproduzenten und -konsumenten einander direkt zuordnen oder ihre Beziehung genauer modellieren, indem Sie Topics und Warteschlangen modellieren.

Interaktionsdiagramme werden verwendet, um sowohl synchrone als auch asynchrone Übertragungen zwischen Designelementen darzustellen. Sie können auch dazu verwendet werden, das Verhalten von gleichzeitig ablaufenden Prozessen auf Leistungsprobleme und logische Probleme hin zu analysieren. Insbesondere kann der Softwarearchitekt anhand dieser Diagramme häufiges Messaging oder hohe Datenübertragungsmengen über das Netz feststellen. Der Architekt kann daraufhin Schnittstellen neu entwerfen oder Designelemente zwischen Steuerungs-Threads, zwischen Servern oder zwischen Client und Server neu zuordnen.

Beachten Sie, dass Threads und Prozesse innerhalb eines EJB-Containers vom EJB-Container verwaltet werden - EJBs können keine Threads erstellen oder verwalten. Logischerweise sollte jede EJB als aktive Klasse betrachtet werden. Weil Aufrufe an Session-Beans und Entity-Beans jedoch synchrone Blockungsaufrufe sind, werden diese Beans normalerweise nicht als aktive Klassen dargestellt. Die Prozess-Sicht für einen EJB-Container ist normalerweise auf den einen verfügbaren Mechanismus für gemeinsamen Zugriff beschränkt: JMS mit nachrichtengesteuerten Beans des JMS.

Obwohl Session-Beans und Entity-Bean im allgemeinen nicht als aktive Klassen modelliert werden, gibt es das Problem der gleichzeitig ablaufenden Prozesse, beispielsweise wenn eine EJB die Datenbank liest, während eine andere in die Datenbank schreibt. Dieses Problem kann mittels Transaktionen gelöst. Der Einsatz von Transaktionen sollte in den projektspezifischen Richtlinien dokumentiert werden.

Zuordnung von Designelementen zu aktiven Klassen

In Aufgabe: Beschreibung der Laufzeitarchitektur wird erläutert, dass die Designelemente Prozessen und Threads zugeordnet werden müssen. In einer J2EE-Anwendung sind alle Webkomponenten dem Webcontainer zugeordnet und alle EJBs dem EJB-Container. Aufgrund dieser einfachen Beziehung muss diese Zuordnung nicht modelliert werden.

Wenn Ihr Design jedoch weitere gleichzeitig ablaufende Prozesse beinhaltet (z. B. zwei unterschiedliche Anwendungsclients), dann kann es sinnvoll sein anzugeben, welche Designelemente in welcher Anwendung ausgeführt werden.

Bei Java-Threads, nachrichtengesteuerten Beans und JMS-Topics und -Warteschlangen ist es wichtiger festzustellen, wie diese untereinander kommunizieren, um gegenseitiges Sperren, inkonsistente Daten usw. zu vermeiden. Dies kann am besten untersucht werden, indem Anwendungsfälle analysiert werden, die diese Elemente enthalten.

Weitere Alternativen der Modellierung

Aufgrund der Affinität zwischen der Prozess-Sicht und der Deployment-Sicht, werden die übergeordneten Diagramme für diese Sichten häufig kombiniert.

Weil jeder J2EE-Container nicht nur ein Prozess sondern auch eine Ausführungsumgebung ist, kann er außerdem als "logischer Knoten" anstatt als aktive Klasse modelliert werden.