@@ -51,12 +51,14 @@ Bei einem positiven Ergebnis des PoC wird angestrebt, die föderale Integrations
...
@@ -51,12 +51,14 @@ Bei einem positiven Ergebnis des PoC wird angestrebt, die föderale Integrations
![PoC_Integrationarchitecture]("Integrationsarchitektur für den PoC")
![PoC_Integrationarchitecture]("Integrationsarchitektur für den PoC")
Für den PoC werden zwei zentrale Komponenten bereitgestellt:
Für den PoC werden zwei zentrale Komponenten bereitgestellt:
- XFall-Zustelldienst: Dieser Dienst stellt die `Application Sender API` und `Application Subscriber API` und die dahinter liegenden fachlichen Funktionen bereit.
-**XFall-Zustelldienst:** Dieser Dienst stellt die `Application Sender API` und `Application Subscriber API` und die dahinter liegenden fachlichen Funktionen bereit.
- API-Gateway: Das API-Gatway regelt den Zugriff (Authorisierung, Rate-Limiting, Sicherheitsüberprüfungen, etc.) auf die APIs des XFall-Zustelldienstes und stellt die Authentifizierung für den Zugriff auf die API. Für einen API-Client ist das API-Gatway im Rahmen der Zustelldienstes nicht direkt sichtbar.
-**API-Gateway: **Das API-Gatway regelt den Zugriff auf die API (Authorisierung, Rate-Limiting, Sicherheitsüberprüfungen, etc.) des XFall-Zustelldienstes und stellt mit der angebundenen IdM-Komponente die Authentifizierungsfunktion für den API-Zugriff bereit. Für einen API-Client ist das API-Gatway im Rahmen der Zustelldienstes nicht direkt sichtbar.
Die Integrationsarchitektur sieht vor, dass eine empfangende Behörde oder ein Dienstleister (bspw. eine kommunales Rechenzentrum) über die `Application Subscriber API` eine Zustellpunkt mit einer eindeutigen `destination-id` anlegen. Diese wird im Rahmen des PoC mit der Antragssenderseite bilateral ausgetauscht bzw. über einen vereinbaren Kanal veröffentlicht. Diese ID wird dann durch die Anwendung auf der Senderseite in der API genutzt, um die korrekte Stelle zu adressieren und bei deren Zustellpunkt den Antrag abzugeben. Die empfangende Behörde oder der Dienstleister können mit beliebigen technischen Systemen diesen Antrag beim angelegten Zustellpunkt abholen.
Die Integrationsarchitektur sieht vor, dass eine empfangende Behörde oder ein Dienstleister (bspw. eine kommunales Rechenzentrum) über die `Application Subscriber API`initial eine Zustellpunkt mit einer eindeutigen `destination-id` anlegt.
Die Integrationsarchitektur vereinfacht jedoch einige zentrale Aspekte, die für die zukünftige Integrationsplattform im Rahmen der Antragsstellung vorgesehen sind:
Diese `destination-id` wird im Rahmen des PoC mit der Antragssenderseite bilateral ausgetauscht bzw. über einen vereinbaren Kanal veröffentlicht. Diese ID wird dann durch die Anwendung auf der Senderseite in der `Application Sender API` genutzt, um die korrekte Stelle zu adressieren und den Antrag beim Zustellpunkt abzugeben. Die empfangende Behörde oder der Dienstleister können dann mit beliebigen technischen Systemen diesen Antrag beim angelegten Zustellpunkt abholen.
Die Integrationsarchitektur wird im Rahmen des PoC um einige zentrale Aspekte vereinfacht, die für die zukünftige Integrationsarchitektur fest eingeplant sind:
-**Nutzung von Zuständigkeitsfindern: **Langfristig ist angedacht, die `destination-id` über die bestehenden und etablierten Zuständigkeitsfindern von Bund und Ländern und deren Redaktionsprozesse zu veröffentlichen. Damit steht ein skalierbarer Ansatz bereit, bei dem Antragsdienste in Echtzeit während der Antragsstellung die `destination-id` der fachlich und örtlich zuständigen Stelle beim einem Zuständigkeitsfinder ermitteln können. Durch diesen Ansatz sind keine aufwendigen bilateralen Absprachen in der Entwicklung mehr notwendig, sondern die Antragsdienste können einen universellen zuständigkeitsbasierten Ansatz auf Basis föderaler Basisinfrastukturen nutzen!
-**Nutzung von Zuständigkeitsfindern: **Langfristig ist angedacht, die `destination-id` über die bestehenden und etablierten Zuständigkeitsfindern von Bund und Ländern und deren Redaktionsprozesse zu veröffentlichen. Damit steht ein skalierbarer Ansatz bereit, bei dem Antragsdienste in Echtzeit während der Antragsstellung die `destination-id` der fachlich und örtlich zuständigen Stelle beim einem Zuständigkeitsfinder ermitteln können. Durch diesen Ansatz sind keine aufwendigen bilateralen Absprachen in der Entwicklung mehr notwendig, sondern die Antragsdienste können einen universellen zuständigkeitsbasierten Ansatz auf Basis föderaler Basisinfrastukturen nutzen!
-**Standardisierte XTA-Einbindung: **Mit XTA steht ein in vielen Teilen der Verwaltung etablierter Standard bereit, um standardisiert Transportverfahren anzubinden, welche die eigentliche Übertragung von Fachdaten über diverse Protokolle und Kommunikationsinfrastrukturen für das Fachverfahren übernehmen. Während es schon im PoC prinzipiell möglich sein sollte, technische Intermedäre für die XFall RESTful API Anbindung per XTA-SOAP Webservice anzusprechen, wird zukünftig eine vollumfängliche Unterstützung alle XTA Bestandteile (wie bspw. Reports) angestrebt.
-**Standardisierte XTA-Einbindung: **Mit XTA steht ein in vielen Teilen der Verwaltung etablierter Standard bereit, um standardisiert Transportverfahren anzubinden, welche die eigentliche Übertragung von Fachdaten über diverse Protokolle und Kommunikationsinfrastrukturen für das Fachverfahren übernehmen. Während es schon im PoC prinzipiell möglich sein sollte, technische Intermedäre für die XFall RESTful API Anbindung per XTA-SOAP Webservice anzusprechen, wird zukünftig eine vollumfängliche Unterstützung alle XTA Bestandteile (wie bspw. Reports) angestrebt.
-**Anbindung von Servicekonten und Antragsmanagementkomponenten:** Zukünftig soll der XFall-Zustelldienst alle antragsrelevenaten Daten (Kopien der Antragsdaten und Statusinformationen) bei definierten Ereignissen (Abgabe beim Zustelldienst und Abholung am Zustellpunkt) in den Hohheitsbereich des Antragsstellers übermitteln und damit Antragsdienst und Fachverfahren von dieser Querschnittsaufgabe entlasten. Hierfür ist angedacht, die zukünftig verfügbaren interoperablen Postfächer als standardisierten Übertragsweg in den Hohheitsbereich des Antragsstellers zu nutzen.
-**Anbindung von Servicekonten und Antragsmanagementkomponenten:** Zukünftig soll der XFall-Zustelldienst alle antragsrelevenaten Daten (Kopien der Antragsdaten und Statusinformationen) bei definierten Ereignissen (Abgabe beim Zustelldienst und Abholung am Zustellpunkt) in den Hohheitsbereich des Antragsstellers übermitteln und damit Antragsdienst und Fachverfahren von dieser Querschnittsaufgabe entlasten. Hierfür ist angedacht, die zukünftig verfügbaren interoperablen Postfächer als standardisierten Übertragsweg in den Hohheitsbereich des Antragsstellers zu nutzen.
