Nachrichtenbroker. Funktionsbeschreibung Version Aktualisiert am: 21. Januar 2014 Florian Muhlack und Dieter Schlüter

Transkript

1 Funktionsbeschreibung Version Aktualisiert am: 21. Januar 2014 Autoren: Florian Muhlack und Dieter Schlüter Funktionsbeschreibung V1.0.2.docx Seite 1 von 33

2 Dokumentenstatusinformation Dokumentenname Funktionsbeschreibung V1.0.1docx Ersterstellungsdatum Freitag, 2. November 2012 Versionsnummer Historie Datum Änderung Person Erstellung Funktionsbeschreibung Version 1.0 Auslieferung an die fachlichen Leitstellen Abnahme durch die fachlichen Leitstellen Anpassung an das verbindliche Corporate Design Kleinere Korrekturen auf Rückmeldung von Fr. Coenen Anpassungen aufgrund der Ergebnisse der XTA AG und der Bestrebungen für weite Nachfolgelösungen für den Stammdatenservice Aktualisierungen z.b. Auflistung der neu hinzugekommenen Dienste, Erweiterung um den XTA 2.0 Webservice Florian Muhlack und Dieter Schlüter Herr Nadler (FB FHH) und Herr Schmidtke (ZIT S-H) Florian Muhlack Dieter Schlüter und Florian Muhlack Dieter Schlüter Florian Muhlack Funktionsbeschreibung V1.0.2.docx Seite 2 von 33

3 1 Kurzbeschreibung Definition Abgrenzung zu anderen Produkten Interessenlage der Kunden Vorteile des s Architektur Systemumgebungen Schutzbedarf Mandantenfähigkeit Begriffsabgrenzung Mandant Mandantenorientiertes Berechtigungskonzept Berechtigungsprüfung Verwaltung von Mandanten Vermittlungswege Kommunikation über das Transportdispatcher Die asynchrone Kommunikation Die synchrone Kommunikation Der XTA-WS Die asynchrone Kommunikation Die synchrone Kommunikation interne Systeme Die Spiegeldatenbank Der Lieferdienst Der VAMS Kommunikation über das Internet OSCI-Transport Die asynchrone Kommunikation Der Versand Der Empfang Die synchrone Kommunikation XTA Gatewaypostfächer Übersicht Funktionen/Schnittstellen Brokerdienste Übersicht Brokerdienste Übersicht Brokerdienste mit den dazugehörigen Schnittstellen...32 Funktionsbeschreibung V1.0.2.docx Seite 3 von 33

4 1 Kurzbeschreibung 1.1 Definition Der (MessageBroker) ist eine zentrale Vermittlungsstelle, die man sich als Datendrehscheibe vorstellen kann. Sie unterstützt und optimiert technisch und organisatorisch Kommunikationsvorgänge unterschiedlichster DV-Verfahren im Auftrag. Aufgabenschwerpunkt ist daher die sichere Maschine (Fachverfahren) zu Maschine (Fachverfahren) Kommunikation für XÖV-Nachrichten. Der ist eine zentrale e-government Infrastrukturkomponente der Länder Hamburg und Schleswig-Holstein. Er steht in einer zone des ZaBI-Rechenzentrums Kiel, so dass er von Systemen über das Landesnetz Schleswig-Holstein, dem FHHNET sowie internen Netzen genutzt werden kann. Um auch für über das Internet ankommende Systeme genutzt werden zu können, bedient sich der anderer egovernmentbausteine wie eines Intermediäres (des Governikus) und des GovernmentGateways. Der bietet diverse Dienste (Brokerdienste) an, wie beispielsweise XMeld Datenübermittlungen oder xdomea elektronischer Aufgrabeschein. Auf Basis der zentralen e-government Infrastrukturkomponente sind diverse fachverfahrensspezifische Brokerdienste implementiert. Dadurch kann den individuellen Fachverfahrensanforderungen Rechnung getragen werden. Der existiert für das Outsourcing von rein kommunikationsbedingten Aufgaben an einen zentralen Auftragnehmer (hier ). Dabei bietet der eine zentrale Infrastruktur zur Kommunikationsabwicklung, einen professionellen Rechenzentrumsbetrieb, eine Sende- und Empfangsbereitsschaft im 7*24 Stunden-Betrieb, eine professionelle Applikationsbetreuung, Brokerdienste, die die Kommunikation technisch und organisatorisch unterstützen und optimieren, diverse Dienstleistungen z.b. fachspezifischer Stammdatenservice. Funktionsbeschreibung V1.0.2.docx Seite 4 von 33

5 1.2 Abgrenzung zu anderen Produkten Der hat keine eigene Internetempfangsschnittstelle, sondern bedient sich beim Empfang aus dem Internet anderer E-Government-Komponenten z.b. Governikus, GovernmentGateway. Im Gegensatz zum Intermediär (Governikus) darf der Nachrichteninhalte im Rahmen der Auftragsdatenverarbeitung lesen. Außerdem bietet der über OSCI-Transport hinaus eine Vielzahl weiterer Transportprotokolle. Im Gegensatz zum Governikus MultiMessenger ( liegt der Schwerpunkt nicht auf der Mensch zu Mensch Kommunikation, sondern auf die Maschine zu Maschine Kommunikation. Im Gegensatz zu EGVP (Elektronisches Gerichts- und verwaltungspostfach) liegt der Schwerpunkt nicht auf der Mensch zu Mensch Kommunikation, sondern auf die Maschine zu Maschine Kommunikation. Außerdem bietet der über OSCI-Transport hinaus eine Vielzahl weiterer Transportprotokolle. 1.3 Interessenlage der Kunden Die Kunden wollen die rein kommunikationsbedingten Aufgaben ihrer Fachverfahren (Stichwort: Maschine zu Maschine) an einen zentralen Auftraggeber outsourcen. Damit werden insbesondere folgende Ziele bezweckt: Erhöhung der Zuverlässigkeit Datensicherheit z.b. durch Protokollierung Kostenersparnis Standardisierung 1.4 Vorteile des s Der ist eine vergleichsweise preiswerte und extrem leistungsfähige Vermittlungsplattform, da außer den Applikations- und Datenbankservern keine weiteren Server und Lizenzen benötigt werden. Durch die Clusterfähigkeit und direkte Queue-Programmierung ist das System ausbaufähig. Ein weiterer Vorteil des s sind fachspezifische Stammdatenservices. Der stellt seine Daten (Behördendaten, Funktionsbeschreibung V1.0.2.docx Seite 5 von 33

6 Gemeindedaten, gebuchte Dienste) anderen E-Government-Basislösungen zur Verfügung z.b. GovernmentGateway, Spiegeldatenbank Meldewesen, Spiegeldatenbank egewerbe. Durch den eigens für die Applikationsbetreuung erstellten Brokerclient ist eine professionelle Applikationsbetreuung möglich. Da es sich beim um eine Eigenentwicklung handelt, können Softwareanpassungen flexibel und schnell gehandhabt werden. Es besteht eine DVDV-Anbindung für Routing, Behördenanfragen und Verifikation. Mittels synchroner und asynchroner OSCI-Transport-Anbindung und synchroner und asynchroner Anbindung aller Behörden in Hamburg und Schleswig-Holstein über das Landesnetz, FHHNet oder interne Netze ist die Nutzung des s möglich. Diverse Zustellungsoptionen bzw. Schnittstellen werden angeboten wie z.b.: OSCI- Transport, XTA-WS 1.1.1, XTA-WS 2.0, Transportdispatcher, FTP, SFTP, Gatewaypostfächer und andere Webservices. Der bietet Konvertierungsmöglichkeiten wie z.b. EdiFact DatMLRaw, DatMLRAW - PDF Eine verhältnismäßig schnelle Realisierung von neuen Fachdiensten ist durch die Nutzung vorhandener Bausteine möglich ( Generischer ). Durch umfangreiche Konfigurationsmöglichkeiten (z.b. welcher Kunde darf welchen Dienst nutzen, welchen Datenumfang und welches Datenformat erhält der Empfänger, wie lange sollen bei Nichterreichbarkeit des Empfängers die Zustellversuche laufen) können kundenspezifische und rechtliche Anforderungen berücksichtigt werden. Rechtskonformer Transport von Nachrichten Sicherheitsnachweis auf Basis der sich an die BSI Systematik orientierenden IT-Sicherheitsleitlinie Funktionsbeschreibung V1.0.2.docx Seite 6 von 33

7 Abbildung 1 Generischer 2 Architektur 2.1 Systemumgebungen Die Stage- (Abnahme-) und Produktions-Umgebungen des s stehen im ZaBI-Rechenzentrum Kiel. Der ist eine Eigenentwicklung von. Er wurde programmiert in MS.NET und basiert auf dem Queuing des MS SQL-Servers. Es gibt folgende umgebungen: Entwicklungs-Umgebung Fachtest-Umgebung Stage- (Abnahme-)Umgebung Produktions-Umgebung Die Produktionsumgebung besteht aus folgenden Servern: 3 virtuelle, geclusterte Applikationserver auf Basis der Microsoft Internet Information Services (II S) 2 hardwarebasierte, failover Datenbank-Cluster ( = Verbund von Computern (Cluster)), in dem bei einem Ausfall eines Rechners ein zweiter Rechner dessen Aufgaben übernimmt) mit dem MS SQL Server Funktionsbeschreibung V1.0.2.docx Seite 7 von 33

8 2.2 Schutzbedarf Der besitzt den Schutzbedarf hoch. Einer der Hauptgründe dafür ist die Vermittlung von personenbezogenen Daten mit entsprechendem Schutzbedarf wie z.b. Religion, Steuerdaten, Adoptionsdaten, Auskunftssperren, biometrische Daten für Ausweisanträge und Volkszugehörigkeiten. Um den Schutzbedarf zu gewährleisten, gibt es diverse Sicherheitsmaßnahmen auf Seiten des s z.b.: SSL-Authentifizierung nicht nur für alle Kundenbeziehungen, sondern auch bei der Kommunikation zwischen den verschiedenen Systemen bei z.b. Spiegeldatenbank Meldewesen für die Applikationsbetreuung SSL-Authentifizierung mit gesonderter Sub-CA und Prüfung gegenüber Fachidentifikation und Kundenaccount Ein für den erstellter OSCI-Proxy, der vor dem Governikus den Empfang über OSCI-Transport absichert. Verborgener und getunnelter Weiterleitungsauftrag vom Governikus zum Gesonderter Virenscanservice Extrem hoher Standard bei den generischen und fachspezifischen Sicherheitsprüfungen der software Sicherstellung der Protokollierung aller Fälle Umfangreiche Applikationsbetreuung Netztechnische Segmentierung der systeme Server- und Verfahrenshärtung mit an das Verfahren angepasster Härtung Aktuelle Windows-Betriebssysteme und SQL-Server Versionen Administrative Zugriffe nur noch über die Admin-Plattform Integrierte Datenbanksicherheit für die Verbindungen zum SQL-Server Funktionsbeschreibung V1.0.2.docx Seite 8 von 33

9 Area PROD Frontend-Layer Applikation-Layer Database-Layer SQL Server SQL Cluster SQL Server Application Server (1-3) Abbildung 2 Netzarea Produktionssystem des s Funktionsbeschreibung V1.0.2.docx Seite 9 von 33

10 2.3 Mandantenfähigkeit Begriffsabgrenzung Mandant Der ist mandantenfähig. Unter einem Mandanten wird eine am angeschlossene konkrete Institution (Behörde oder Firma) verstanden. Diese nimmt die Rolle als Autor bzw. Leser von Nachrichten wahr. Abbildung 3 Abgrenzung Fachverfahren XTA - Transportmedium Aus Sicht des s handelt es sich bei Mandanten um Accounts (Kundenpostfächer). Der Mandant bedient sich eines Fachverfahrens um Nachrichten mit Hilfe des s zu versenden bzw. zu empfangen. Dabei kann zwischen einem organisatorischen und einem technischen Mandantenbegriff unterschieden werden. Wie der Mandant geschnitten wird, ist allein Entscheidung des Auftraggebers und richtet sich insbesondere an den Möglichkeiten seines Fachverfahrens aus. Beispiel 1: Eine Ausländerbehörde (organisatorischer Mandant) repräsentiert einen Account (technischer Mandant) gemeinsam für die Spezifikationen XAusländer und XhD, weil diese durch ein gemeinsames Fachverfahren abgewickelt werden. Beispiel 2: Eine Ausländerbehörde (organisatorischer Mandant) repräsentiert zwei Accounts (technische Mandanten) getrennt für die Spezifikationen XAusländer und XhD, weil diese Funktionsbeschreibung V1.0.2.docx Seite 10 von 33

11 durch verschiedene Fachverfahren abgewickelt werden oder das Fachverfahren eine Trennung erfordert Mandantenorientiertes Berechtigungskonzept Authentifizierung Zur Authentifizierung sind nur von WS-Interoperability zertifizierte Webservicestandards zugelassen. Die vom angebotenen Webserviceschnittstellen erlauben ausschließlich die SSL-Client-Authentifizierung. Autorisierung Im Regelfall wird über das SSL-Zertifikat der Zugriff auf einen Account beim autorisiert. Wenn dem Zertifikat mehrere Accounts zugeordnet sind, gibt es zusätzlich die Möglichkeit optionale Attribute zu füllen. Diese Parameter zu den Absenderangaben identifizieren zusammen mit dem Zertifikat einen Account beim. Mandant und Account Es tritt immer eine konkrete Institution als Autor (Versand von Nachrichten) oder Leser (Empfang von Nachrichten) einer Nachricht auf. Diese Institution ist aus Sicht des Fachverfahrens ein Mandant. Eine Instanz des Fachverfahrens wird häufig von mehreren Behörden genutzt. Aus Sicht des s werden Accounts verwaltet. Accounts können wie folgt bestimmt werden: Alternative 1: Über ein Zertifikat, das nur für einen einzigen Mandanten gültig ist (Authentifizierung). Alternative 2: Über ein Zertifikat, das für mehrere Mandanten gültig ist (Authentifizierung) und die dazugehörigen mandantenspezifischen Informationen für die Behördenkennung (Autorisierung) Berechtigungsprüfung Es gibt eine mehrstufige Berechtigungsprüfung Schritt 1: Der Zugriff auf Accounts ist nur für netztechnisch auf die Webservices des s freigeschaltete Kunden möglich. Funktionsbeschreibung V1.0.2.docx Seite 11 von 33

12 Schritt 2: Der IIS der Web- und Applikationserver des s lässt nur Anfragen durch, deren SSL-Zertifikate von der -CA speziell für den ausgestellt wurden. Schritt 3: Prüfung ob das SSL-Zertifikat in der datenbank bei den aktiven Accounts hinterlegt ist. Schritt 4: Prüfung ob die mandantenspezifischen Informationen passen. Schritt 5: Prüfung, ob eine Nachricht eindeutig einem Account zugeordnet werden kann. Diese Prüfung geschieht mit Hilfe der Angaben für die Autorisierung, der Authentifizierung und der Dienstebezeichnung Schritt 6: Prüfung ob das verwendete Signaturzertifikat des Absenders im DVDV für die Absenderbehördenkennung hinterlegt ist. Durch diese mehrstufige Berechtigungsprüfung wird gewährleistet, dass technische Mandanten nur eigene Nachrichten versenden und empfangen können. Dies gilt auch für die dazugehörigen Transportquittungen bzw. Transportreports Verwaltung von Mandanten Die Einrichtung, Änderung, Inaktivierung und Löschung von Mandanten geschieht über den Brokerclient. Damit wird sichergestellt, dass nur über freigegebene Programme Änderungen vorgenommen werden. Außerdem gewährleisten zahlreiche Plausibilitäten, dass Mindeststandards bei den Mandantendaten garantiert werden z.b. kann kein Mandant ohne die erforderlichen Authentifizierungs- und Autorisierungsdaten angelegt werden. Ebenso werden Fehlbedienungen verhindert z.b. Löschung eines Mandanten mit noch vorhandenen Nachrichten. Funktionsbeschreibung V1.0.2.docx Seite 12 von 33

13 3 Vermittlungswege Im folgenden Unterkapitel sollen die verschiedenen Vermittlungswege mit allen dazugehörigen Komponenten aufgezeigt und kurz erläutert werden. 3.1 Kommunikation über das Transportdispatcher Der Transportdispatcher ist ein Webservice des s. Er ist der Vorläufer der bundesweit einheitlichen XTA-WS Schnittstelle. Der Transportdispatcher kommt bei den Brokerdiensten zum Einsatz, bei denen die Fachverfahren noch keinen XTA-Client implementiert haben und folglich die XTA-WS Schnittstelle des s noch nicht bedienen können Die asynchrone Kommunikation In asynchronen Kommunikationsszenarien empfängt der Transportdispatcher eine Nachricht und der führt folgende Aktionen durch: Generierung einer Nachrichtennummer Virenprüfung Sofern erforderlich Extraktion aus dem Zip-File Prüfung, ob Absender ein Kunde des s ist Festlegung Eingangszeit Sicherung im Protokoll Prüfung, ob für den übermittelten Nachrichtentyp ein Dienstpaket hinterlegt ist Prüfung ob die Absender- und die Empfängerbehördenkennung einem Kunden über Präfix, Behördenkennung und gebuchtes Dienstpaket zugeordnet werden kann Prüfung, ob der Kunde das ermittelte Dienstpaket gebucht hat Prüfung, ob ein Dienstpaketadapter für den übermittelten Nachrichtentyp hinterlegt ist Aufruf einer dienstpaketspezifischen Komponente zur fachlichen Prüfung Sollten alle generischen Prüfungen des s erfolgreich gewesen sein, erfolgt die Zustellung der empfangenen Nachricht entsprechend den Vorgaben des fachlichen Brokerdienstpaketes. Der Transportdispatcher kann von den Fachverfahren direkt aufgerufen werden. Im Regelfall haben die Kunden des s für unterschiedliche Dienstpakete sogenannte Transportagents lokal auf ihren Servern installiert. Diese Transportagents werden vom für diese Kommunikationswege bereitgestellt und arbeiten datei- und verzeichnisbasiert. Funktionsbeschreibung V1.0.2.docx Seite 13 von 33

14 Die bei den Kunden installierten Transportagents versuchen in definierten Intervallen Nachrichten in ihren Postfächern beim abzuholen. Dadurch wird gewährleistet, dass die vom ins Postfach des Kunden übermittelte Nachricht zur weiteren Bearbeitung beim Kunden in regelmäßigen Abständen auch abgeholt wird Die synchrone Kommunikation In synchronen Kommunikationsszenarien empfängt der Transportdispatcher vom Fachverfahren eine Anfragenachricht (request). Die Prüfungen und die Steuerung des Ablaufs sind analog zur asynchronen Kommunikation. Sollten alle Prüfungen des s erfolgreich gewesen sein, leitet der die Anfrage entsprechend des fachlichen Brokerdienstpaketes an das Empfängersystem z.b. Spiegeldatenbank Meldewesen in Schleswig-Holstein oder den Sperrdienst beim Bundesverwaltungsamt weiter. Die vom Empfängersystem zurückgelieferten Antwortnachricht (response) wird vom an das Fachverfahren weitergeleitet. Da die Kommunikation synchron erfolgt, ist das Fachverfahrens der Behörde nach dem Senden seiner Anfrage so lange blockiert bis es eine Antwort auf die Anfrage empfangen hat. Dies dauert im Regelfall nur wenige Sekunden Der XTA-WS Die XTA-WS-Schnittstelle ist für die Kommunikation innerhalb geschlossener Netze vorgesehen. Sie ist eine bundesweit einheitliche Schnittstelle und bietet daher den Vorteil, alle mit einem XTA-Client implementierten Fachverfahren ohne größeren Aufwand an den anschließen zu können, da diese Schnittstelle bundesweit spezifiziert ist. Die Spezifikation XTA-WS gibt es in zwei Versionen: XTA-WS 1: Die Dokumentation steht unter der Adresse zum Download zur Verfügung XTA-WS 2: Die Dokumentation steht unter der Adresse zum Download zur Verfügung Die Version XTA-WS 1 ist ein sogenannter Industriestandard. Die Nachfolgeversion XTA WS 2 ist ein Projekt des IT-Plaungsrates. Mittelfristig sollen alle bisher noch über den Transportdispatcher ablaufenden Kommunikationen auf den XTA umgestellt werden. Sollten Fachverfahren zu diesem Zeitpunkt noch nicht in der Lage sein, den XTA-WS des s durch einen Funktionsbeschreibung V1.0.2.docx Seite 14 von 33

15 implementierten XTA-Client anzusprechen, werden XTA-fähige Transportagenten zur Verfügung gestellt Die asynchrone Kommunikation In asynchronen Kommunikationsszenarien empfängt der XTA-WS eine Nachricht und der führt folgende Aktionen durch: Prüfung, ob Absender ein Kunde des s ist Prüfung der übergebenen Parameter o Dienstebezeichnung o Empfängerkennung o Nachricht o MessageID Festlegung Eingangszeit Virenprüfung Sicherung im Protokoll Prüfung, ob für den übermittelten Nachrichtentyp ein Dienstpaket hinterlegt ist Prüfung, ob der Kunde das ermittelte Dienstpaket gebucht hat Ermittlung des fachspezifischen Transportadapters Als Rückgabewert übergibt der übergibt die MessageId an den Absender Sollten alle generischen Prüfungen des s erfolgreich gewesen sein, erfolgt die Zustellung der empfangenen Nachricht entsprechend den Vorgaben des fachlichen Brokerdienstpaketes Die synchrone Kommunikation Auch bei synchronen Kommunikationsszenarien empfängt der XTA-WS eine Anfragenachricht (request). Der einzige Unterschied ist hier, dass der Absender statt der MessageID als Rückgabewert eine Antwortnachricht (response) erhält interne Systeme Der kommuniziert mit diversen internen Systemen z.b. egewerbe, diversen Goverment-Gatewayfachverfahren, FTP- und SFTP-Servern. Als ein typisches Muster soll hier die Kommunikation mit der Spiegeldatenbank für die schleswigholsteinischen Meldebehörden aufgezeigt werden Die Spiegeldatenbank Funktionsbeschreibung V1.0.2.docx Seite 15 von 33

16 Zwischen dem und der Spiegeldatenbank existieren viele Kommunikationsbeziehungen. An dieser Stelle beschränken sich die folgenden Ausführungen auf den Lieferdienst als asynchrone Kommunikation sowie den VAMS (Vorausgefüllten Meldeschein) als synchrone Kommunikation Der Lieferdienst Der Lieferdienst ist ein asynchrones Kommunikationsszenario. Die Meldebehörden generieren werktäglich Deltalieferungen. Diese dienen dazu, die jeweiligen Änderungen der Spiegeldatenbank mitzuteilen, so dass die Spiegeldatenbank für Auskünfte stets aktuell gehalten wird. Außerdem werden auf Basis dieser Deltalieferungen diverse Mitteilungsdienste erzeugt. Die Transportagenten der Meldebehörden übermitteln dazu die aus den Fachverfahren erzeugten Nachrichten an den Transportdispatcher des s. Es finden dabei die unter Punkt beschriebenen Prüfungen statt. Zusätzlichen kommen noch die fachspezifischen Prüfungen dieses Brokerdienstpaketes z.b. ob eine Lieferung alle dazugehörigen Pakete enthält. Soweit alle Prüfungen erfolgreich waren, übermittelt der die Deltalieferungen an das Spiegeldatensystem. Der erhält bei erfolgreicher Lieferung an das Spiegeldatensystem eine Antwort (Fachquittung). Der generiert zudem für jede gesendete Nachricht eine Transportquittung und übergibt Fach- sowie Transportquittung in das Postfach der betroffenen Meldebehörde. Der Transportagent der Meldebehörde holt diese Nachrichten dann in definierten Intervallen für die Meldebehörde ab. Funktionsbeschreibung V1.0.2.docx Seite 16 von 33

17 Abbildung 4 Lieferung an Spiegeldatenbank für Meldedaten Darüber hinaus erzeugen Meldebehörden in Ausnahmefällen noch Gesamtlieferungen. Diese unterscheiden sich fachlich dadurch, dass der Datenbankeintrag des Spiegeldatensystems der betroffenen Meldebehörde durch die Gesamtlieferung komplett überschrieben wird und nicht, wie bei der Deltalieferung, nur aktualisiert wird. Außerdem sind bei Gesamtlieferungen die Mitteilungsdienste de-aktiviert. Aus Transportsicht wird dieses Szenario aber genauso behandelt wie eine Deltalieferung. Aus diesem Grund erfolgen an dieser Stelle auch keine weiteren Ausführungen zur Gesamtlieferung. Dieses Kommunikationsszenario ist auch über den XTA-WS nutzbar. Es entfällt die Transportquittung, da der XTA-WS stattdessen einen Transportreport zur Verfügung stellt, den sich der Absender aktiv holen muss Der VAMS Der VAMS ist ein synchrones Kommunikationsszenario. Die Meldebehörden richten über den Webservice Ihres Fachverfahrens eine Anfrage über den XTA-WS. Der leitet die Anfrage an die Spiegeldatenbank weiter. Funktionsbeschreibung V1.0.2.docx Seite 17 von 33

18 Die von der Spiegeldatenbank zurückgelieferte Antwort leitet der über den XTA-WS an das Fachverfahrens der Meldebehörde weiter. Da die Kommunikation synchron erfolgt, ist das Fachverfahrens der Meldebehörde A nach dem Senden seiner Anfrage so lange blockiert, bis es eine Antwort auf die Anfrage empfangen hat. Dies dauert im Regelfall nur wenige Sekunden. Abbildung 5 VAMS Funktionsbeschreibung V1.0.2.docx Seite 18 von 33

19 3.2 Kommunikation über das Internet OSCI-Transport Die asynchrone Kommunikation Der Versand Der XTA-Client des Fachverfahrens der Behörde A bzw. der Transportagent sendet die Nachricht an einen der Webservices des s (siehe 3.1). Der führt folgende Aktionen durch: Generierung einer Nachrichtennummer Virenprüfung Extraktion aus dem Zip-File (Transportagent kann Nachrichten nur gezippt übersenden) Prüfung, ob Absender ein Kunde des s ist Festlegung Eingangszeit Sicherung im Protokoll Prüfung, ob für den übermittelten Nachrichtentyp ein Dienstpaket hinterlegt ist Prüfung, ob der Kunde das ermittelte Dienstpaket gebucht hat Prüfung, ob ein Dienstpaketadapter für den übermittelten Nachrichtentyp hinterlegt ist Aufruf einer dienstpaketspezifischen Komponente zur fachlichen Prüfung Das Dienstpaket ermittelt über das DVDV die benötigten Informationen zu den Verschlüsselungs- und Signaturzertifikaten, sowie zur URI des Intermediäres. Entsprechend dem OSCI-Transportprofil des Fachstandards baut der Nachrichtbroker die benötigten OSCI- Nachrichtenstrukturen und führt die geforderten Zertifikatsprüfungen, Verschlüsselungen und Signaturen durch. Der übergibt nach der Authentifizierung des Intermediärs die Nachricht an das entsprechende Intermediärpostfach. Die Empfängerbehörde holt sich anschließend die in ihrem Intermediärpostfach eingegangene Nachricht ab Im Folgenden soll beispielhaft anhand des Fachszenarios XPersonenstand ein asynchrones Kommunikationsszenario über den XTA skizziert werden. Funktionsbeschreibung V1.0.2.docx Seite 19 von 33

20 Abbildung 6 XPersonenstand Der Empfang setzt als Intermediär den Governikus der Fa. BOS ein. Auf dem - Governikus befinden sich neben hunderter anderer Postfächer auch die Intermediärspostfächer des s. Diese sind nach Diensten getrennt. Der holt eingegangene Nachrichten aus seinen Interemdiärspostfächern in voreingestellten Zeitintervallen ab.und führt folgende Aktionen durch: Generierung einer Nachrichtennummer Entschlüsselung des gesendeten Inhaltscontainers undauslesen der Nachricht Virenprüfung Prüfung, ob es sich um ein XML handelt Prüfung des Signaturalgorithmus des Inhaltsdatencontainers Auswertung der Zertifikate: o Online-Prüfung Funktionsbeschreibung V1.0.2.docx Seite 20 von 33

21 o Offline-Prüfung o Mathematische Prüfung Prüfung, ob für den übermittelten Nachrichtentyp ein Dienstpaket hinterlegt ist und der Empfang erlaubt ist Prüfung, ob die Absenderbehördenkennung im DVDV vorhanden ist Prüfung ob das Signaturzertifikat des Absenders zur Kategorie und Behördenschlüssel der Absenderbehördenkennung (DVDV-Client-Zertifikat) passt Prüfung ob die Empfängerbehördenkennung einem Kunden zugeordnet werden kann Prüfung, ob ein Dienstpaketadapter für den übermittelten Nachrichtentyp hinterlegt ist Prüfung ob der Service-Typ Empfang für diesen Nachrichtentyp zugelassen ist Sicherung im Protokoll Prüfung ob eine Fehlermeldung zu einer RTS führt Aufruf einer dienstpaketspezifischen Komponente zur fachlichen Prüfung Sollten alle Prüfungen des s erfolgreich gewesen sein, übergibt der die Nachricht in das Brokerpostfach der Behörde A. Die Verwaltung holt dann die Nachricht mittels eines XTA-Clients oder des Transportagents ab Die synchrone Kommunikation Bei diesem Kommunikationsszenario empfängt der synchrone Webservice des s eine Anfragenachricht (request) über einen OSCI-Account auf dem -Governikus und antwortet mit einer Antwortnachricht (response) über OSCI- Transport. Die vom durchgeführten Aktionen sind mit der asynchronen Kommunikation vergleichbar. Sollten alle Prüfungen des s erfolgreich gewesen sein, leitet der die Anfrage ein anderes internes -System z.b. den Spiegeldatenbankserver fürs Meldewesen weiter. Der Response von diesem System wird an die anfragende Verwaltung weitergeleitet. Ein typisches Szenario wäre eine VAMS-Anfrage einer Meldebehörde außerhalb von Hamburg und Schleswig-Holstein an eine schleswigholsteinische Meldebehörde XTA Die Schnittstelle XTA basiert auf der universellen, bundesweiten Schnittstelle XTA-WS in der Version (XTA-WS für XÖV Transport-Adapter- WebService). Wie oben beschrieben, ist die XTA-WS-Schnittstelle nur für die Kommunikation innerhalb geschlossener Netze vorgesehen. Damit diese Schnittstelle auch übers Internet nutzbar ist, wurde, basierend auf der XTA-WS-Schnittstelle, die spezifische Schnittstelle XTA geschaffen. Die Schnittstelle Funktionsbeschreibung V1.0.2.docx Seite 21 von 33

22 XTA ist nur mit Hilfe der Infrastruktur des GovernmentGateways nutzbar. Daher beinhaltet die Schnittstelle XTA auch die Erfordernisse der GovernmentGateway Ticketverwaltung. Bei diesem Szenario kommunizieren der XTA-Client als Komponente des Fachverfahrens und der XTA miteinander. Dabei nimmt der XTA alle Aufträge vom Webservice-Client synchron entgegen und transportiert diese je nach XÖV- Spezifikation synchron oder asynchron weiter. Der Versand von XÖV-Nachrichten kann zum Beispiel an einen anderen vom XTA verwalteten Account erfolgen oder an extern verwaltete Behörden/Institutionen. Für den sendenden XTA-Client ist vollkommen transparent, wie die Nachricht versandt wird und welches Transportszenario zur Anwendung kommt. Es werden unabhängig von der Versandart immer die gleichen Methoden, Parameter und Rückgabewerte genutzt. Die konkret genutzte Versandart kann dem abgeholten Transportprotokoll entnommen werden. Der XTA kann durch mehrere Webservice-Clients gleichzeitig angesprochen werden und deren Anfragen parallel verarbeiten. Der Zugang aus dem Internet erfolgt über die Infrastruktur des GovernmentGateways. Die Berechtigung zur Teilnahme an diesem Dienst wird über die Benutzerverwaltung einer Fachanwendung des GovernmentGateways geprüft. Bisher wird dieses Szenario von der GovermentGateway Fachanwendung Aufgrabeschein Maschinenschnittstelle genutzt. Damit eine Teilnahme möglich ist, muss die teilnehmende Organisation/Firma durch einen sogenannten Masteruser im HamburgService registriert sein und den Dienst abonniert haben. Der Masteruser kann die Benutzer einrichten und verwalten, welche den Dienst tatsächlich nutzen sollen. Die Kommunikation mit dem XTA erfolgt ausschließlich mittels SSL- Verschlüsselung. Diese Schnittstellenversion erlaubt eine Authentifizierung und Autorisierung mittels Benutzerkennung und Passwort mit Hilfe der Methode Login, die das für die Nutzung der weiteren Methoden notwendige Sessionticket zur Verfügung stellt Gatewaypostfächer Der Versand an Gatewaypostfächer ist ein asynchrones Kommunikationsszenario. Als Beispiel für diesen Vermittlungsweg soll das Fachszenario egewerbe dienen. Die Transportagenten der Gewerbeämter übermitteln die aus dem Fachverfahren erzeugten Gewerbelieferungen an den Transportdispatcher des s. Sobald die unter Punkt beschriebenen Prüfungen erfolgreich waren, übermittelt der die Gewerbelieferungen an die Spiegeldatenbank. Funktionsbeschreibung V1.0.2.docx Seite 22 von 33

23 Der erhält eine Antwort der Spiegeldatenbank (Fachquittung), sobald die Gewerbelieferungen erfolgreich gespiegelt worden sind. Nach Erhalt der Fachquittung der Spiegeldatenbank erzeugt der Duplikate der gespiegelten Gewerbelieferungen und übergibt diese Duplikate an das betroffene Gatewaypostfach der sogenannten Weiterleitungsempfänger. Die für jeden Weiterleitungsempfänger hinterlegte Konfiguration bestimmt dabei den Datenumfang und das Format (PDF, DatMLRaw oder edifact). Parallel generiert der für jede Nachrichte eine Transportquittung und übergibt Fach- sowie Transportquittung in das -Postfach des betroffenen Gewerbeamtes. Der Transportagent des Gewerbeamtes holt diese Quittungen dann in definierten Intervallen für das Gewerbeamt ab. Abbildung 7 Gateway-Postfächer Dieses Kommunikationsszenario ist auch über den XTA-WS realisiert. Funktionsbeschreibung V1.0.2.docx Seite 23 von 33