© Christian Kracke 10/2001 PSI-Kommunikation und -Szenarien.ppt 1 PSI - Überblick und Szenarien P S I Middleware für heterogene IT-Strukturen

1© Christian Kracke • 10/2001 PSI-Kommunikation und -Szenarien.ppt

PSI - Überblick und Szenarien

P S I

Middleware für heterogene

IT-Strukturen



Inhalt

PSI - Kommunikation

Fallback - Mechanismen

Fallback - Szenarien



• Ein lokaler PSI-Bereich besteht aus einer Menge von PSI-Prozessen, die von einem Objekt (z.B. Shared-Memory, PSI-Admin, ...) kontrolliert werden.

• Standardmäßig setzt sich ein PSI-Bereich aus allen PSI-Prozessen, die auf einem Rechner gestartet sind, zusammen. Ausnahmen:– PSI unter UNIX kann auf einem Rechner mehrere unabhängige

PSI-Bereiche unterscheiden (Area-ID in Prozeß-Start-Tabelle).

– PSI 32-Bit und PSI 16-Bit auf einem Win32-Rechner sind unabhängig.

PSI-Kommunkation in einem lokalen Bereich



• Alle PSI-Prozesse in einem PSI-Bereich kommunizieren mittels ihrer lokalen PSI-Prozeß-ID direkt (ohne PSI-Broker) miteinander.

• Ausnahme: Requests an die eigene Prozeß-ID werden nicht lokal bearbeitet. Requests an den eigenen PSI-Prozeß müssen als Server-Prozeß-ID 0 verwenden.

PSI-Kommunkation in einem lokalen Bereich



• Die Kommunikation zwischen PSI-Prozessen ist asynchron.

• Es werden Request-Events von einem PSI-Prozeß (Rolle: Client) an einen anderen PSI-Prozeß (Rolle: Server) gesendet.

• Request können als Oneway gesendet werden. Achtung: keine Kontrolle über weiteren Ablauf.

• Request können eine Response erzwingen. Die Resonse wird asynchron mittels eines Callback gemeldet.

PSI-Kommunkation allgemein



• Request, die eine Response erzwingen, werden bis zum Eingang der Response überwacht.

• Request müssen vom Server nicht sofort beantwortet werden. Sie können sogar unendlich lange ‚gehalten‘ werden.

• Störungen während eines aktiven Requests werden sowohl an den Client als auch den Server gemeldet.

• Synchrone Request sind prinzipiell möglich, sollten aber nicht benutzt werden. Achtung: In Multithreaded PSI-Prozessen (Type 2) funktionieren synchrone Requests nur aus dem PSI-Thread.




• Request können als Registrierung beim Server benutzt werden (Hot-Link).

• Der Server kann zu jedem Request beliebig viele Zwischen-Ergebnisse senden, bevor er den Request selbst beendet.

• Der Client kann erkennen, ob er zu einem Request ein Zwischenergebnis oder die Response erhält.

• Die Registrierungen können zur Überwachung von PSI-Prozessen benutzt werden.

• Bemerkung: Dieses könnte im PSIOO noch besser, schöner, weiter gekapselt werden.




Lokale Kommunikation

MCCProcess

PSI-Bereich

AgentProcess

TimerProcess

ACD-TCProcess

Request Request

Request

Response

Response

Response

Client

Client/Server

Server

Server

Zwischen- ergenisse



• Eine PSI-Domain wird von einem PSI-Domain-Broker verwaltet.

• In jedem PSI-Bereich einer PSI-Domain wird ein lokaler PSI-Broker gestartet, der sich bei seinem PSI-Domain-Broker anmeldet.

• Die Verbindungen zwischen lokalem und Domain-PSI-Broker erhalten eine eindeutige Session-ID und werden überwacht.

• Bei Abbruch der Verbindung wird zyklisch versucht die Verbindung unter einer neuen Session-ID neu aufzubauen.

Aufbau einer PSI-Domain



• Eine PSI-Domain ist als sternförmiges Netzwerk aufgebaut. Die Kommunikation zwischen PSI-Bereichen läuft immer über den Domain-Broker.

• Der Domain-Broker akzeptiert Verbindungen von lokalen PSI-Bereichen mit unterschiedlichen LAN-Protokollen (Multiprotokollrouter).

• PSI-Prozesse können ihre Dienste als Domain-Public-Dienste unter einer Domain-Public-Prozeß-ID innerhalb der Domain anbieten.

• Jede Domain-Public-Prozeß-ID kann in einer PSI-Domain zur gleichen Zeit nur einmal verwendet werden.

Kommunikation innerhalb einer PSI-Domain



• Request von einem Client an eine Server-Prozeß-ID, die als lokale PSI-Prozeß-ID im lokalen PSI-Bereich nicht vorhanden ist, wird über den lokalen Broker an den Domain-Broker weitergereicht.

• Der Domain-Broker sendet den Request, in den PSI-Bereich, von dem sich der Domain-Public-Dienst registriert hat.

• Existiert der gesuchte Domain-Public-Dienst nicht, wird der Request mit entsprechendem Status zum Client zurückgesendet.

• Bei Kommunikationsstörungen innerhalb der PSI-Domain werden für die betroffenen PSI-Requests sowohl Client- als auch Server-PSI-Prozesse informiert.

Kommunikation innerhalb einer PSI-Domain



Aufbau einer PSI-Domain

LocalBroker

ConfigServer

StatistikProcess

TimerProcess

PSI-Bereich 3

LocalBrokerTimer

Process

AgentProcess

1

First-screen

PSI-Bereich 2

LocalBroker

MCCProcess

ACD-TCProcess

DomainBroker

PSI-Bereich 1

PSI- Domain

SMTCP/IP

IPX/SPX



• Wenn in einem PSI-Bereich ein PSI-Prozeß mit einer bestimmten lokalen Prozeß-ID aktiv ist, kann ein Client-Prozeß einen PSI-Public-Prozeß gleicher ID nicht erreichen.

• Ausnahme: Requests an die eigene Prozeß-ID werden nicht lokal bearbeitet.

– Dadurch kann ein lokaler Server-Prozeß mit einen Public-Server-Prozeß gleicher ID kommunizieren.

– Der lokaler Server-Prozeß kann in dem PSI-Bereich als Stellvertreter des Public-Server-Prozeß auftreten.

Lokale PSI-Stellvertreter-Prozesse



Lokale PSI-Stellvertreter-Prozesse

LocalBroker

ConfigServer

PublicStatistikProcess

0x77

TimerProcess

PSI-Bereich 3

LocalBrokerTimer

Process

StatistikClient

(wenig Daten)

First-screen

PSI-Bereich 2

LocalBroker

StatistikClient

(viel Daten)ACD-TCProcess

DomainBroker

PSI-Bereich 1

PSI- Domain

LokalerStatistikProcess

0x77

an 0x77

an 0x77

an 0x77



• Eine PSI-Interdomain wird von einem PSI-Interdomain-Broker verwaltet.

• Alle PSI-Domain-Broker, die sich bei einem PSI-Interdomain-Broker anmelden, bilden mit ihren PSI-Domains eine PSI-Interdomain.

• Die Verbindungen zwischen Domain- und Interdomain-PSI-Broker erhalten eine eindeutige Session-ID und werden überwacht.

• Bei Abbruch der Verbindung wird zyklisch versucht die Verbindung unter einer neuen Session-ID neu aufzubauen.

Aufbau einer PSI-Interdomain



• Eine PSI-Interdomain ist als sternförmiges Netzwerk aufgebaut. Die Kommunikation zwischen PSI-Domains läuft immer über den Interdomain-Broker.

• Der Interdomain-Broker akzeptiert Verbindungen von PSI-Domains mit unterschiedlichen LAN-Protokollen (Multiprotokollrouter).

• PSI-Prozesse können ihre Dienste als Interdomain-Public-Dienste unter einer Interdomain-Public-Prozeß-ID innerhalb der Interdomain anbieten.

• Jede Interdomain-Public-Prozeß-ID kann in einer PSI-Interdomain zur gleichen Zeit nur einmal verwendet werden.

Kommunikation innerhalb einer PSI-Interdomain



• Request von einem Client an eine Server-Prozeß-ID, die als lokale PSI-Prozeß-ID im lokalen PSI-Bereich und in der eigenen PSI-Domain nicht vorhanden ist, wird über den Domain-Broker an den Interdomain-Broker weitergereicht.

• Der Interdomain-Broker sendet den Request, in die PSI-Domain, von der sich der Interdomain-Public-Dienst registriert hat.

• Existiert der gesuchte Interdomain-Public-Dienst nicht, wird der Request mit entsprechendem Status zum Client zurückgesendet.

• Bei Kommunikationsstörungen innerhalb der PSI-Interdomain werden für die betroffenen PSI-Requests sowohl Client- als auch Server-PSI-Prozesse informiert.

Kommunikation innerhalb einer PSI-Interdomain



Aufbau einer PSI-Interdomain

DomainBroker

PSI-Domain 3

DomainBroker

PSI-Domain 2

DomainBroker

Inter-DomainBroker

PSI-Domain 1

Interdomain

Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 1



Fallbackmöglichkeiten beim lokalen PSI-Broker

• Der lokale PSI-Broker kann sich alternativ auch zu anderen PSI-Domains verbinden, falls sein primärer Domain-Broker nicht erreichbar ist.

• Er durchsucht der Reihe nach eine Liste von Domain-Broker-Adressen.

• Der lokale Broker kann so konfiguriert werden, daß er sich von einem Alternativ-Domain-Broker wieder zu seinem primären Domain-Broker verbindet, sobald dieser wieder erreichbar ist.



Fallbackmöglichkeiten beim Domain-PSI-Broker

• Zu jedem Domain-PSI-Broker können beliebig viele Fallback-Domain-Broker konfiguriert werden.

• Die Fallback-Domain-Broker müssen jeweils eine unterschiedliche Priorität erhalten.

• Für jeden konfigurierten Fallback-Domain-Broker wird ein Watchdog-Domain-Broker gestartet.

• Stellt der Watchdog-Domain-Broker fest, das kein Domain-Broker höherer-Priorität erreichbar ist, startet er seinen Fallback-Domain-Broker.

• Stellt der Watchdog-Domain-Broker fest, daß ein Domain-Broker höherer-Priorität wieder erreichbar ist, beendet er seinen Fallback-Domain-Broker.



Fallbackmöglichkeiten beim Interdomain-PSI-Broker

• Der Domain-PSI-Broker kann sich alternativ auch zu anderen PSI-Interdomains verbinden, falls sein primärer Interdomain-Broker nicht erreichbar ist.

• Er durchsucht der Reihe nach eine Liste von Interdomain-Broker-Adressen.

• Der Domain-Broker hat die Möglichkeit, seine Verbindung zu einem Alternativ-Interdomain-Broker zu beenden, sobald sein primärer Interdomain-Broker oder ein Alternativ-Interdomain-Broker höherer Priorität wieder erreichbar ist, und stellt eine neue Verbindung zu diesem her.



Fallbackmöglichkeiten beim Interdomain-PSI-Broker

• Zu jedem Interdomain-PSI-Broker können beliebig viele Fallback-Interdomain-Broker konfiguriert werden.

• Die Fallback-Interdomain-Broker müssen jeweils eine unterschiedliche Priorität erhalten.

• Für jeden konfigurierten Fallback-Interdomain-Broker wird ein Watchdog-Interdomain-Broker gestartet.

• Stellt der Watchdog-Interdomain-Broker fest, das kein Interdomain-Broker höherer-Priorität erreichbar ist, startet er seinen Fallback-Interdomain-Broker.

• Stellt der Watchdog-Interdomain-Broker fest, daß ein Interdomain-Broker höherer-Priorität wieder erreichbar ist, beendet er seinen Fallback-Interdomain-Broker.



Fallback in einer PSI-Interdomain

DomainBroker

PSI-Domain 3

DomainBroker

PSI-Domain 2

DomainBroker

Inter-DomainBroker

PSI-Domain 1

Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 1

DomainBroker

PSI-Domain 4

Bereich 1Bereich 2

Bereich 3Watch-

InterdomainBroker

überwach

tFB-Inter-DomainBroker




DomainBroker

PSI-Domain 3

DomainBroker

PSI-Domain 2

DomainBroker

Inter-DomainBroker

PSI-Domain 1

Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 1

DomainBroker

PSI-Domain 4

Bereich 1Bereich 2

Bereich 3Watch-

InterdomainBroker

FB-Inter-DomainBroker




DomainBroker

PSI-Domain 3

DomainBroker

PSI-Domain 2

DomainBroker

Inter-DomainBroker

PSI-Domain 1

Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 3

Bereich 1Bereich 2

Bereich 1

DomainBroker

PSI-Domain 4

Bereich 1Bereich 2

Bereich 3Watch-

InterdomainBroker

überwach

t



PSI-Fallback-Prozesse

• In einer PSI-Domain werden zwei gleiche Public-Server gestartet, von denen der erste als Domain-Public akzeptiert, der zweite abgelehnt wird.

• Der zweite Server-Prozeß kann sich dann beim ersten Public-Server registrieren.

• Sobald der zweite Server-Prozeß signalisiert bekommt, daß seine Registrierung beendet wird, versucht er den Public-Dienst zu übernehmen.

• Hat er die Rolle des Domain-Public-Server übernommen, kann sich der erste Server bei ihm registrieren, sobald er wieder aktiv ist.

• Alternativ kann der erste dem zweiten Server melden, er soll die Public-Rolle aufgeben und sich als Fallback registrieren.




LocalBroker

ConfigServer

ServerProcess 2

TimerProcess

PSI-Bereich 3

LocalBrokerTimer

Process

ServerProcess 1(Public)

First-screen

PSI-Bereich 2

LocalBroker

MCCProcess

ACD-TCProcess

DomainBroker

PSI-Bereich 1

PSI- Domain

(Public)Registrierung



PSI-Fallback-Prozesse (Fall 1)

LocalBroker

ConfigServer

ServerProcess 2

TimerProcess

PSI-Bereich 3

LocalBrokerTimer

Process

ServerProcess 1

First-screen

PSI-Bereich 2

LocalBroker

MCCProcess

ACD-TCProcess

DomainBroker

PSI-Bereich 1

PSI- Domain

(Public)Registrierung

(Public)



PSI-Fallback-Prozesse (Fall 2)

LocalBroker

ConfigServer

ServerProcess 2

TimerProcess

PSI-Bereich 3

LocalBrokerTimer

Process

ServerProcess 1

First-screen

PSI-Bereich 2

LocalBroker

MCCProcess

ACD-TCProcess

DomainBroker

PSI-Bereich 1

PSI- Domain

(Public)Werde Fallback

(Public)




• Achtung: Wenn beim Fallback-Prozeß die lokale und die Public-PSI-Prozeß-ID gleich sind, gehen alle Request im lokalen Bereich zum Fallback-Prozeß, was nicht unbedingt gewollt ist.

• Lösung 1: Lokale ID und Public-ID sind verschieden. Nachteil: Alle lokalen Requests müssen an die lokale ID gesendet werden, da Requests an die Public-ID immer über die PSI-Broker laufen.

• Lösung 2: Nicht der Fallback-Server selbst registiert sich beim Public-Server. Er startet einen Überwachungsprozeß und beendet sich. Im Fallbackfall wird er dann vom Überwachungsprozeß gestartet.



Public-Selbst-Test

• Wenn ein PSI-Prozeß sich als Public-Server anmeldet, weiß er noch nicht, wann dieser Dienst als Public-Dienst nutzbar ist.

• Solange noch keine PSI-Broker-Verbindung zum Domain- bzw. Interdomain-Broker besteht wird die Public-Anmeldung gepuffert. Erst wenn die Broker-Verbindung besteht, wird die Gültigkeit der Public-Erklärung geprüft und im negativen Fall der PSI-Prozeß informiert.

• Um zu prüfen, ob die Public-Erklärung bereits Gültigkeit hat, kann der PSI-Prozeß sich bei sich selbst registrieren. Schlägt die Registrierung fehl, ist die Public-Erklärung noch nicht gültig. Dieser Test kann dann zyklisch solange erfolgen, bis die Registrierung erfolgreich ist.



Public-Selbst-Test

• Sobald die Registrierung wieder ungültig wird, ist auch die Public-Erklärung wieder ungültig.

• Sollte danach die Public-Erklärung negativ beantwortet werden, hat ein anderer PSI-Prozeß sich unter der Public-Prozeß-ID angemeldet.

• Eine Registrierung wird jetzt an den neuen Public-Prozeß gesendet.

• Diese Abläufe gelten sowohl für Domain- als auch Interdomain-Verbindungen.

Documents

© Christian Kracke 10/2001 PSI-Kommunikation und -Szenarien.ppt 1 PSI - Überblick und Szenarien P S I Middleware für heterogene IT-Strukturen