Service-Gateway
Das Service-Gateway dient u.a. der Anbindung von Reporting-Lösungen wie servBIRD, um folgende Ziele zu erreichen:
- Da derzeit für die .NET-Implementierungen ein spezieller Service-Client verwendet wird, der aktuelle WCF-Services und künftige WebAPIs während der Migrationsphase koexistent ansprechen kann, wird eine entsprechend Implementierung in den Java-Plugins des servBIRD benötigt. Um diese nicht pro Programmiersprache implementieren zu müssen, verwenden wir hier Server-seitige Service Discovery mithilfe des Service-Gateways, um diese "Weiche" in .NET bereitstellen zu können.
- Künftige Änderungen müssen nicht Team-übergreifend ausgeliefert und organisiert werden, was zu einer deutlich geringeren Team-Kopplung führt.
- Da das Service-Gateway durch Schleupen.CS.PI.SB.GTW_Gateway implementiert und nur anders deployed sowie konfiguriert wird, können die Bereitstellungs- und Wartungskosten auch hier deutlich reduziert werden.
- Die Migration der Reports auf die neue Anbindung kann sofort begonnen werden.
Einen architekturellen Überblick gibt folgendes Diagramm, in dem insbesondere erkennbar ist, dass das Java-Plugin das Service-Gateway aufruft, das wiederum den dynamischen Service-Client mit den Zielen WCF-Service oder Web-API anspricht. Das Service-Gateway ist ein Executable, das durch den ProcessHost verwaltet wird.
Das Service-Gateway ist im Standard-Lieferumfang enthalten und wird automatisch deployed. Technisch unterscheiden sich API-Gateway und Service-Gateway lediglich darin, dass das Service über den ProcessHost gehostet wird und mit SessionTokens arbeitet (reine Konfiguration).
Aktuell wird das Service-Gateway auf Servern mit der Deployment-Rolle "BirtServer" oder "ServBirdServer" deployed.
In Deployments, die durch Kubernetes orchestriert werden, werden Service-Gateway und Reporting-Lösung gemeinsam in einem Pod ausgeführt.