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