Topologien
In diesem Kapitel wird ein Überblick über die grundlegenden Elemente und deren Anordnung gegeben.
Services
Wie bereits erwähnt, sind Services das grundlegende Strukturierungsmittel. Dieses sind organisiert in Geschäftsprozess-Komponenten und Länder. GP-Komponente greifen über den Service Bus auf Länder zu oder werden von Ländern über Events benachrichtigt. Die Abhängigkeitsbeziehung ist in nachstehendem Bild von oben nach unten.
Jedes dieser Länder greift auf eine Datenbank zu, die sich je nach Konfiguration die Länder teilen können. Jedes Land hat aber ein eigenes Datenbankschema.
Welche Datenbank konkret verwendet ist, ist abhängig von der Systemstruktur. Die Services eines Landes oder einer Geschäftsprozess-Komponente sind einer konfigurierten Serviceimplementierungsgruppe zugeordnet, die wiederum einem Systemstrukturelementknoten zugeordnet ist. Unter einem solchen Knoten kann es eine oder mehrere Datenbanken geben und in genau einer dieser muss das DB-Schema des Bausteins zugeordnet sein.
Aus Hosting-Sicht ruft ein Service-Client über den lokalen Broker den Endpunkt im IIS auf einem spezifischen Host auf. Hierbei wird die dem Host zugeordnete Deploymentrolle berücksichtigt.
Die Services eines Bausteins sind dann im Workerprozess des IIS, dem w3wp.exe-Prozess, zugeordnet. In diesem sind die Assemblys des Bausteins, also des Landes oder der Geschäftsprozess-Komponente eingeladen.
Workflows werden im Prozess "Schleupen.CS.PI.BPE.Workflows.MassTransit.WorkflowHostCli.exe" gehostet. Diese Prozesse wiederum werden über den sogenannten ProcessHost, dem Windows-Dienst "Schleupen ProcessHost Service" verwaltet.
Messaging
Die Messaging-Topologie basiert auf folgenden grundlegenden Eigenschaften:
- Business Events werden als Schnittstellen abgebildet, die im RabbitMQ als Exchanges ausgeprägt werden. Die Schnittstelle wird des EventInterfaces hat einen sogenannten Artifact Identifier, das ist die bereits erläuterte ServiceId. Der Publisher genauso wie der Subscriber ist ein Land oder auch eine GP-Komponente. Subscriber sind die Implementierungen dieser Schnittstelle. In der folgenden Abbildung sind die Subscriber A, B, C abgebildet. Stellen wir uns der Einfachheit halber ein Land darunter vor. Jedes Land hat eine Queue pro Systemstrukturelement. Für das Land A trägt dann die Queue den Name A_W wenn das entsprechende Systemstrukturelement den Namen W hat. Entsprechend hat jedes Land pro Systemstrukturelement eine Exchange mit identischem Namen. Davor geschaltet ist ein Exchange, das den Namen des Ziel-Landes plus den Eventnamen hat. Diese drei Bausteine im RabbitMQ gehören dem Land.
Davor ist ein allgemeines Exchanges für das Event definiert, welches dem Publisher gehört. Das gesamte Routing erfolgt dann über Bindings, was sehr performant ist. - Bei Command Services ist die Topologie prinzipiell äquivalent strukturiert. Dabei gehört das Exchange des ServiceInterface allerdings dem Land.