Konfiguration allgemein (DMZ)
Auf dem inneren Server muss Lobster Integration, auf dem DMZ-Server der CommunicationForwardManager gestartet werden.
Die Verwaltung der Partner-Kanäle wird vom AuthenticationService übernommen.
Der CommunicationLogService protokolliert Kommunikations-Ereignisse als Log in der Datenbank von Lobster Integration, z. B. das Eintreffen einer Datei per AS2 und deren Message ID, etc.
Auf einem DMZ-Server wird jeweils eine spezielle Variante beider Dienste verwendet, da die DMZ aus Sicherheitsgründen über keine Datenbank verfügt: Der MessageAuthenticationService und der MessageCommunicationLogService, die mit dem jeweiligen Dienst des inneren Servers durch den Austausch von Messages zusammenarbeiten.
Der MessageAuthenticationService stellt dem DMZ-Server prinzipiell die gleichen Funktionen bereit, wie der AuthenticationService auf dem inneren Server. Er wird in der Service Factory des DMZ-Servers (./etc/factory_dmz.xml) unter dem Namen AuthenticationService registriert. Die Kommunikationsdienste halten ihn deshalb für den AuthenticationService. Dieser Name kann aber durch Konfiguration geändert werden. Das gleiche gilt analog für das Dienste-Paar MessageCommunicationLogService und CommunicationLogService.
In der folgenden Abbildung wird die Zusammenarbeit zwischen dem MessageAuthenticationService im DMZ-Server und seinem AuthenticationService im inneren Server für einen Empfang per FTP durch den DMZ-Server beschrieben. Dies gilt ähnlich auch für den MessageCommunicationLogService und den CommunicationLogService.
(1) Der Partner will per FTP über den DMZ-Server eine Datei hochladen, die dann von einem Profil verarbeitet wird. Der FTP-Client verbindet sich mit dem FtpService des DMZ-Servers (Port 21). Der FTP-Service fordert vom Client die Authentifizierung. Der Client sendet den Usernamen.
(2) Der FtpService wendet sich an seinen MessageAuthenticationService, um zu erfragen, ob dem Kommunikationspartner ein FTP-Kanal zugeordnet ist und welche Kommunikationsparameter dazu gespeichert sind. Der MessageAuthenticationService leitet die Anfragen als synchrone Message an den inneren Server weiter, weil nur dieser die geforderte Information zentral verwaltet.
(3) Der MessageAuthenticationService wendet sich an seinen MessageService, um die Anfrage über die konfigurierte Message Queue als synchrone Message zu versenden. Dabei kann er dem MessageService zusätzliche Informationen, wie das defaultTarget (IP und Port) und den defaultTargetService (Name des inneren AuthenticationService) übergeben. Synchrone Messages arbeiten nach dem Anfrage-Antwort-Prinzip, wobei die Antwort über die gleiche Queue zurückgesendet wird. Der MessageAuthenticationService wartet auf die Antwort.
(4) Der MessageService muss (durch Konfiguration) die Route zum internen Service kennen. Andernfalls übernimmt er die Routing-Information vom defaultTarget, siehe (3). Er übergibt nun eine synchrone Message an die TCP/IP-Schicht, um sie zu der Remote-Schnittstelle des MessageServices des inneren Servers zu senden und wartet auf die Antwort.
(5) Die TCP/IP-Schicht des DMZ-Servers erzeugt eine TCP-Verbindung zu der IP-Adresse des inneren Servers und der Ziel-Portnummer. Dort hört die Remote-Schnittstelle des MessageServices des inneren Servers auf Verbindungswünsche.
(6) Die Firewall muss den Verbindungsaufbau vom DMZ-Server zur Remote-Schnittstelle des inneren MessageServices erlauben.
(7) Die Verbindung wird von der Remote-Schnittstelle akzeptiert und die Message empfangen. Die TCP-Verbindung bleibt dabei bestehen, um die Antwort zurück senden zu können.
(8) Die Remote-Schnittstelle übergibt die Message dem inneren MessageService, der sie in die richtige Message Queue einordnet. Dadurch wird sie den Message Consumern, die für diese Queue registriert sind, übergeben.
(9) Der innere AuthenticationService ist durch seinen Parameter consumeMessages an dieser Message Queue als Message Consumer registriert worden und empfängt die Message mit der darin enthaltenen Anfrage.
(10) Aus der Anfrage wird durch Zugriff auf die Datenbank eine Antwort formuliert und als Message auf dem umgekehrten Weg wieder zurückgesendet. Nachdem die Antwort den DMZ-Server erreicht hat, wird sie über den MessageService dem MessageAuthenticationService zugestellt, der nun die angeforderten Kommunikations-Parameter des FTP-Kanals dem FtpService übergibt, damit dieser das Login des Clients akzeptieren oder abweisen kann. Wenn keine Partnerinformationen für das Client-Login gefunden werden oder die Anfrage aus anderen Gründen nicht beantwortet werden kann, wird das Login abgewiesen.
(11) Der FtpService übernimmt nach erfolgreichem Login vom Client die eingelieferte Datei und sendet sie über den MessageService an den inneren Server. Dabei wird eine andere Message Queue verwendet, als die vom AuthenticationService verwendete.
(12) Wenn ein passendes Profil auf diese Message Queue registriert ist, wird die Datei diesem Profil zur Verarbeitung zugestellt.
Hinweis: Die Schritte (11) und (12) sind nicht Gegenstand dieser Abschnitte.
Nach der Standardinstallation des DMZ-Servers ist bereits alles vorkonfiguriert. Die Einträge für die IP-Adressen in den folgenden Dateien müssen allerdings noch manuell angepasst werden.
• ./etc/startup.xml beziehungsweise ./etc/startup_dmz.xml
• ./etc/auth.xml beziehungsweise ./etc/auth_dmz.xml
• ./etc/commlog.xml beziehungsweise ./etc/commlog_dmz.xml