Funktionsbeschreibung Nachrichtenbroker - Dataport

Nachrichtenbroker 

Funktionsbeschreibung 

Version 1.0.2 

Aktualisiert am: 21. Januar 2014 

Autoren: 

Florian Muhlack und Dieter Schlüter 

Funktionsbeschreibung_Nachrichtenbroker_V1.0.2.docx Seite 1 von 33

Dokumentenstatusinformation 

Dokumentenname 

Funktionsbeschreibung_Nachrichtenbroker_V1.0.1docx 

Ersterstellungsdatum Freitag, 2. November 2012 

Versionsnummer 1.0.2 

Historie Datum Änderung Person 

02.11.2012 Erstellung Funktionsbeschreibung 

Version 1.0 

Auslieferung an die fachlichen 

Leitstellen 

12.11.2012 Abnahme durch die fachlichen 

Leitstellen 

14.12.2012 Anpassung an das verbindliche 

Corporate Design 

31.01.2013 Kleinere Korrekturen auf 

Rückmeldung von Fr. Coenen 

19.06.2013 Anpassungen aufgrund der 

Ergebnisse der XTA AG und der 

Bestrebungen für Dataport weite 

Nachfolgelösungen für den 

Stammdatenservice 

20.01.2014 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 


Dieter Schlüter 



1 Kurzbeschreibung Nachrichtenbroker ............................................................................. 4 

1.1 Definition ................................................................................................................. 4 

1.2 Abgrenzung zu anderen Produkten ......................................................................... 5 

1.3 Interessenlage der Kunden ..................................................................................... 5 

1.4 Vorteile des Nachrichtenbrokers.............................................................................. 5 

2 Architektur ...................................................................................................................... 7 

2.1 Systemumgebungen ............................................................................................... 7 

2.2 Schutzbedarf ........................................................................................................... 8 

2.3 Mandantenfähigkeit ................................................................................................10 

2.3.1 Begriffsabgrenzung Mandant ..........................................................................10 

2.3.2 Mandantenorientiertes Berechtigungskonzept .................................................11 

2.3.3 Berechtigungsprüfung .....................................................................................11 

2.3.4 Verwaltung von Mandanten .............................................................................12 

3 Vermittlungswege ..........................................................................................................13 

3.1 Kommunikation über das Intranet ...........................................................................13 

3.1.1 Transportdispatcher ........................................................................................13 

3.1.1.1 Die asynchrone Kommunikation ...............................................................13 

3.1.1.2 Die synchrone Kommunikation .................................................................14 

3.1.2 Der XTA-WS ...................................................................................................14 



3.1.3 Dataport interne Systeme ................................................................................15 

3.1.3.1 Die Spiegeldatenbank ..............................................................................15 

3.1.3.1.1 Der Lieferdienst .....................................................................................16 

3.1.3.1.2 Der VAMS .............................................................................................17 

3.2 Kommunikation über das Internet ...........................................................................19 

3.2.1 OSCI-Transport ...............................................................................................19 


3.2.1.1.1 Der Versand ..........................................................................................19 

3.2.1.1.2 Der Empfang .........................................................................................20 


3.2.2 XTANachrichtenbroker ....................................................................................21 

3.2.3 Gatewaypostfächer .........................................................................................22 

4 Übersicht Funktionen/Schnittstellen...............................................................................24 

5 Brokerdienste ................................................................................................................27 

5.1 Übersicht Brokerdienste .........................................................................................27 

5.2 Übersicht Brokerdienste mit den dazugehörigen Schnittstellen ..............................32 


Produktinformation 


1 Kurzbeschreibung Nachrichtenbroker 

1.1 Definition 

Der Nachrichtenbroker (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 Nachrichtenbroker ist eine zentrale e-Government Infrastrukturkomponente der Länder 

Hamburg und Schleswig-Holstein. 

Er steht in einer Intranetzone des Dataport ZaBI-Rechenzentrums Kiel, so dass er von 

Systemen über das Landesnetz Schleswig-Holstein, dem FHHNET sowie Dataport internen 

Netzen genutzt werden kann. 

Um auch für über das Internet ankommende Systeme genutzt werden zu können, bedient 

sich der Nachrichtenbroker anderer eGovernmentbausteine wie eines Intermediäres (des 

Governikus) und des GovernmentGateways. 

Der Nachrichtenbroker bietet diverse Dienste (Brokerdienste) an, wie beispielsweise XMeld 

Datenübermittlungen oder xdomea elektronischer Aufgrabeschein. 

Auf Basis der zentralen e-Government Infrastrukturkomponente Nachrichtenbroker sind 

diverse fachverfahrensspezifische Brokerdienste implementiert. Dadurch kann den 

individuellen Fachverfahrensanforderungen Rechnung getragen werden. 

Der Nachrichtenbroker existiert für das Outsourcing von rein kommunikationsbedingten 

Aufgaben an einen zentralen Auftragnehmer (hier Dataport). 

Dabei bietet der Nachrichtenbroker 

 

 

 

 

 

 

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_Nachrichtenbroker_V1.0.2.docx Seite 4 von 33 

Dataport 

Niederlassungen 

Anstalt des öffentlichen Rechts 

Altenholzer Str. 10 - 14, Hamburg: 040 42846 0 

24161 Altenholz Bremen: 0421 83558 0 

Telefon: 0431 3295 0 Rostock: 0381 44899 0 

Internet: www.dataport.de Lüneburg 04131 26368 0



1.2 Abgrenzung zu anderen Produkten 

 

 

 

 

Der Nachrichtenbroker 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 Nachrichtenbroker 

Nachrichteninhalte im Rahmen der Auftragsdatenverarbeitung lesen. Außerdem 

bietet der Nachrichtenbroker über OSCI-Transport hinaus eine Vielzahl weiterer 

Transportprotokolle. 

Im Gegensatz zum Governikus MultiMessenger (www.bos-bremen.de) 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 Nachrichtenbroker ü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 Nachrichtenbrokers 

 

 

Der Nachrichtenbroker 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 Nachrichtenbrokers sind fachspezifische 

Stammdatenservices. Der Nachrichtenbroker stellt seine Daten (Behördendaten, 











 

 

 

 

 

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 Nachrichtenbroker 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 Dataport interne Netze ist die Nutzung des 

Nachrichtenbrokers 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 Nachrichtenbroker 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 Nachrichtenbroker“). 

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 

Dataport IT-Sicherheitsleitlinie 











Abbildung 1 Generischer Nachrichtenbroker 

2 Architektur 

2.1 Systemumgebungen 

Die Stage- (Abnahme-) und Produktions-Umgebungen des Nachrichtenbrokers stehen im 

ZaBI-Rechenzentrum Kiel. 

Der Nachrichtenbroker ist eine Eigenentwicklung von Dataport. Er wurde programmiert in MS 

.NET und basiert auf dem Queuing des MS SQL-Servers. 

Es gibt folgende Nachrichtenbrokerumgebungen: 

 

 

 

 

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 











2.2 Schutzbedarf 

Der Nachrichtenbroker 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 Nachrichtenbrokers z.B.: 

 

 

 

 

 

 

 

 

 

 

 

 

 

SSL-Authentifizierung nicht nur für alle Kundenbeziehungen, sondern auch bei der 

Kommunikation zwischen den verschiedenen Systemen bei Dataport z.B. 

Nachrichtenbroker – Spiegeldatenbank Meldewesen für die Applikationsbetreuung 

SSL-Authentifizierung mit gesonderter Sub-CA und Prüfung gegenüber 

Fachidentifikation und Kundenaccount 

Ein für den Nachrichtenbroker 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 Nachrichtenbrokersoftware 

Sicherstellung der Protokollierung aller Fälle 

Umfangreiche Applikationsbetreuung 

Netztechnische Segmentierung der Nachrichtenbrokersysteme 

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 











Area „Nachrichtenbroker PROD“ 

Frontend-Layer 

Applikation-Layer 

Database-Layer 

SQL Server 

SQL Cluster 

SQL Server 

Application Server (1-3) 

Abbildung 2 Netzarea Produktionssystem des Nachrichtenbrokers 











2.3 Mandantenfähigkeit 

2.3.1 Begriffsabgrenzung Mandant 

Der Nachrichtenbroker ist mandantenfähig. 

Unter einem Mandanten wird eine am Nachrichtenbroker 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 Nachrichtenbrokers handelt es sich bei Mandanten um Accounts 

(Kundenpostfächer). Der Mandant bedient sich eines Fachverfahrens um Nachrichten mit 

Hilfe des Nachrichtenbrokers 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 











durch verschiedene Fachverfahren abgewickelt werden oder das Fachverfahren eine 

Trennung erfordert. 

2.3.2 Mandantenorientiertes Berechtigungskonzept 

Authentifizierung 

Zur Authentifizierung sind nur von WS-Interoperability zertifizierte Webservicestandards 

zugelassen. Die vom Nachrichtenbroker angebotenen Webserviceschnittstellen erlauben 

ausschließlich die SSL-Client-Authentifizierung. 

Autorisierung 

Im Regelfall wird über das SSL-Zertifikat der Zugriff auf einen Account beim 

Nachrichtenbroker 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 

Nachrichtenbroker. 

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 Nachrichtenbrokers 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). 

2.3.3 Berechtigungsprüfung 

Es gibt eine mehrstufige Berechtigungsprüfung 

Schritt 1: Der Zugriff auf Accounts ist nur für netztechnisch auf die Webservices des 

Nachrichtenbrokers freigeschaltete Kunden möglich. 











Schritt 2: Der IIS der Web- und Applikationserver des Nachrichtenbrokers lässt nur 

Anfragen durch, deren SSL-Zertifikate von der Dataport-CA speziell für den 

Nachrichtenbroker ausgestellt wurden. 

Schritt 3: Prüfung ob das SSL-Zertifikat in der Nachrichtenbrokerdatenbank 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. 

2.3.4 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. 











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 Intranet 

3.1.1 Transportdispatcher 

Der Transportdispatcher ist ein Webservice des Nachrichtenbrokers. 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 Nachrichtenbrokers noch 

nicht bedienen können. 

3.1.1.1 Die asynchrone Kommunikation 

In asynchronen Kommunikationsszenarien empfängt der Transportdispatcher eine Nachricht 

und der Nachrichtenbroker führt folgende Aktionen durch: 

 

 

 

 

 

 

 

 

 

 

 

Generierung einer Nachrichtennummer 

Virenprüfung 

Sofern erforderlich Extraktion aus dem Zip-File 

Prüfung, ob Absender ein Kunde des Nachrichtenbrokers 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 Nachrichtenbrokers 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 Nachrichtenbrokers für unterschiedliche Dienstpakete sogenannte 

Transportagents lokal auf ihren Servern installiert. Diese Transportagents werden vom 

Nachrichtenbroker für diese Kommunikationswege bereitgestellt und arbeiten datei- und 

verzeichnisbasiert. 











Die bei den Kunden installierten Transportagents versuchen in definierten Intervallen 

Nachrichten in ihren Postfächern beim Nachrichtenbroker abzuholen. Dadurch wird 

gewährleistet, dass die vom Nachrichtenbroker ins Postfach des Kunden übermittelte 

Nachricht zur weiteren Bearbeitung beim Kunden in regelmäßigen Abständen auch abgeholt 

wird. 

3.1.1.2 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 Nachrichtenbrokers erfolgreich gewesen sein, leitet der 

Nachrichtenbroker 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 

Nachrichtenbroker 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. 

3.1.2 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 

Nachrichtenbroker 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 http://www.xoevta.de/ zum 

Download zur Verfügung 

XTA-WS 2: Die Dokumentation steht unter der Adresse http://www.xoev.de 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 Nachrichtenbrokers durch einen 











implementierten XTA-Client anzusprechen, werden XTA-fähige Transportagenten zur 

Verfügung gestellt. 


In asynchronen Kommunikationsszenarien empfängt der XTA-WS eine Nachricht und der 

Nachrichtenbroker führt folgende Aktionen durch: 

 

 

 

 

 

 

 

 

 


Prüfung der übergebenen Parameter 

o Dienstebezeichnung 

o Empfängerkennung 

o Nachricht 

o MessageID 


Virenprüfung 




Ermittlung des fachspezifischen Transportadapters 

Als Rückgabewert übergibt der Nachrichtenbroker übergibt die MessageId an den 

Absender 

Sollten alle generischen Prüfungen des Nachrichtenbrokers erfolgreich gewesen sein, erfolgt 

die Zustellung der empfangenen Nachricht entsprechend den Vorgaben des fachlichen 

Brokerdienstpaketes. 


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. 

3.1.3 Dataport interne Systeme 

Der Nachrichtenbroker 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. 

3.1.3.1 Die Spiegeldatenbank 











Zwischen dem Nachrichtenbroker 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. 

3.1.3.1.1 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 Nachrichtenbrokers. Es finden dabei 

die unter Punkt 3.1.1 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 

Nachrichtenbroker die Deltalieferungen an das Spiegeldatensystem. 

Der Nachrichtenbroker erhält bei erfolgreicher Lieferung an das Spiegeldatensystem eine 

Antwort (Fachquittung). Der Nachrichtenbroker 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. 











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. 

3.1.3.1.2 Der VAMS 

Der VAMS ist ein synchrones Kommunikationsszenario. Die Meldebehörden richten über 

den Webservice Ihres Fachverfahrens eine Anfrage über den XTA-WS. Der 

Nachrichtenbroker leitet die Anfrage an die Spiegeldatenbank weiter. 











Die von der Spiegeldatenbank zurückgelieferte Antwort leitet der Nachrichtenbroker ü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 











3.2 Kommunikation über das Internet 

3.2.1 OSCI-Transport 


3.2.1.1.1 Der Versand 

Der XTA-Client des Fachverfahrens der Behörde A bzw. der Transportagent sendet die 

Nachricht an einen der Webservices des Nachrichtenbrokers (siehe 3.1). Der 

Nachrichtenbroker führt folgende Aktionen durch: 

 

 

 

 

 

 

 

 

 

 


Virenprüfung 

Extraktion aus dem Zip-File (Transportagent kann Nachrichten nur gezippt 

übersenden) 








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 Nachrichtenbroker ü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. 











Abbildung 6 XPersonenstand 

3.2.1.1.2 Der Empfang 

Dataport setzt als Intermediär den Governikus der Fa. BOS ein. Auf dem Dataport- 

Governikus befinden sich neben hunderter anderer Postfächer auch die 

Intermediärspostfächer des Nachrichtenbrokers. Diese sind nach Diensten getrennt. Der 

Nachrichtenbroker holt eingegangene Nachrichten aus seinen Interemdiärspostfächern in 

voreingestellten Zeitintervallen ab.und führt folgende Aktionen durch: 

 

 

 

 

 

 


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 











 

 

 

 

 

 

 

 

 

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 der Service-Typ Empfang für diesen Nachrichtentyp zugelassen ist 


Prüfung ob eine Fehlermeldung zu einer RTS führt 


Sollten alle Prüfungen des Nachrichtenbrokers erfolgreich gewesen sein, übergibt der 

Nachrichtenbroker die Nachricht in das Brokerpostfach der Behörde A. Die Verwaltung holt 

dann die Nachricht mittels eines XTA-Clients oder des Transportagents ab. 


Bei diesem Kommunikationsszenario empfängt der synchrone Webservice des 

Nachrichtenbrokers eine Anfragenachricht (request) über einen OSCI-Account auf dem 

Dataport-Governikus und antwortet mit einer Antwortnachricht (response) über OSCI- 

Transport. Die vom Nachrichtenbroker durchgeführten Aktionen sind mit der asynchronen 

Kommunikation vergleichbar. 

Sollten alle Prüfungen des Nachrichtenbrokers erfolgreich gewesen sein, leitet der 

Nachrichtenbroker die Anfrage ein anderes internes Dataport-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. 

3.2.2 XTANachrichtenbroker 

Die Schnittstelle XTANachrichtenbroker basiert auf der universellen, bundesweiten 

Schnittstelle XTA-WS in der Version 1.1.1 (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 Dataport 

spezifische Schnittstelle XTANachrichtenbroker geschaffen. Die Schnittstelle 











XTANachrichtenbroker ist nur mit Hilfe der Infrastruktur des GovernmentGateways nutzbar. 

Daher beinhaltet die Schnittstelle XTANachrichtenbroker auch die Erfordernisse der 

GovernmentGateway Ticketverwaltung. 

Bei diesem Szenario kommunizieren der XTA-Client als Komponente des Fachverfahrens 

und der XTANachrichtenbroker miteinander. Dabei nimmt der XTANachrichtenbroker 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 

XTANachrichtenbroker 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 XTANachrichtenbroker 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 XTANachrichtenbroker 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. 

3.2.3 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 Nachrichtenbrokers. Sobald die unter 

Punkt 3.1.1 beschriebenen Prüfungen erfolgreich waren, übermittelt der Nachrichtenbroker 

die Gewerbelieferungen an die Spiegeldatenbank. 











Der Nachrichtenbroker erhält eine Antwort der Spiegeldatenbank (Fachquittung), sobald die 

Gewerbelieferungen erfolgreich gespiegelt worden sind. Nach Erhalt der Fachquittung der 

Spiegeldatenbank erzeugt der Nachrichtenbroker 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 Nachrichtenbroker für jede Nachrichte eine Transportquittung und 

übergibt Fach- sowie Transportquittung in das Nachrichtenbroker-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. 











4 Übersicht Funktionen/Schnittstellen 

Schnittstelle 

Versand 

Empfang 

Funktion 

Intranet 

(XTA- 

WS) 

Intranet 

(TD- 

WS) 

Internet 

(OSCI) 

Intranet 

(WS) 

Internet 

(Gateway- 

PF) 

Intranet 

(SFTP) 

Intranet 

(FTP) 

Intranet 

(XTA- 

WS) 

Intranet 

(TD- 

WS) 

Internet 

(XTA 

NB) 

Internet 

(OSCI) 

Internes Routing x x x x x x x x x x 

Externes Routing x x 

Verifikation über XKMS x x 

Encoding-Prüfungen x x x x 

Schemaprüfungen x x x x 

Viren-Scanning x x x x 











Protokollierung/Zeitstempel x x x x x x x x x x x 

Wiederholungsdienst x x x x x x x 

Authentifizierung x x x x 

Autorisierung x x x x 

Verschlüsselung x x x x x x x x x x 

Signatur inkl. Prüfung x x x x x 











Schnittstelle 

Versand 

Empfang 

Funktion 

Intranet 

(XTA- 

WS) 1 

Intranet 

(TD- 

WS) 2 

Internet 

(OSCI) 3 

Intranet 

(WS) 4 

Internet 

(Gateway- 

PF) 5 

Intranet 

(SFTP) 6 

Intranet 

(FTP) 7 

Intranet 

(XTA- 

WS) 8 

Intranet 

(TD- 

WS) 9 

Internet 

(XTA 

NB) 10 

Internet 

(OSCI) 11 

Erläuterungen: 

1 Versand an das Nachrichtenbroker-Postfach, Abholung über die XTA-WS Schnittstelle 

2 Versand an das Nachrichtenbroker-Postfach, Abholung über den Transportdispatcher und die Transportagenten 

3 Versand über OSCI-Transport 1.2 

4 Versand an interne Webservices z.B. an den Webservice der Spiegeldatenbank fürs Meldewesen 

5 Versand über geschlossene Netze an Gatewaypostfächer. Der Gateway-User holt die Nachricht aus seinem Gatewaypostfach allerdings in der 

Regel über das Internet ab 

6 Versand über SFTP 

7 Versand über FTP 

8 Empfang über die bundesweit einheitliche XTA-WS Schnittstelle 

9 Empfang über den Transportdispatcher und die Transportagenten 

10 Empfang über das Internet mittels eines Gateway-Fachverfahrens über die Schnittstelle XTANachrichtenbroker 

11 Empfang über das Internet mittels eines OSCI-Accounts auf dem Governikus 











5 Brokerdienste 

5.1 Übersicht Brokerdienste 

Brokerdienstname Kurzbeschreibung des Brokerdienstes Spezifikation Art der 

Vermittlung 

produktiv 

seit 

XMeld DÜ 

XMeld Meld IT 

Datenübermittlungen (DÜ) auf Basis von XMeld z.B. 

Rückmeldungen, Fortschreibungen, Datenaustausch mit dem 

Bundeszentralamt für Steuern und der Rentenversicherung, 

Führungszeugnisanträge, DÜ an das Bundesverwaltungsamt, GEZ, 

Wehrverwaltung, Bundeszentralregister. 

Erstaufbau und Aktualisierung eines zentral gespiegelten 

Meldedatenbestandes. Außerdem werden die für die Erzeugung 

von zentralen Mitteilungsdienstdateien erforderlichen Daten 

vor/nach Änderung abgeholt. 

XMeld asynchron Jan. 2007 

XMeld asynchron Juni 2007 











Filetransfer 

Mit dem Dienstpaket Filetransfer werden Daten transportiert, für die 

es keine speziellen fachlichen Dienstpakete gibt. Es gibt z.B. 

folgende Anwendungsbereiche: Übermittlung von Druckdateien für 

Wählerverzeichnisse und Wahlbenachrichtigungskarten, 

Datenübermittlungen an die evangelische oder katholische Kirche, 

Anfragen an das Gewerbezentralregister, Datenübermittlungen an 

die Polizei, LaSD und KBA, Früherkennungsuntersuchungen bei 

Kinder, eGewerbe-Weiterleitungen an Gatewaypostfächer, 

Gewerbeanzeigen für den Einheitlichen Ansprechpartner 

Filetransfer asynchron Aug. 2008 

DatMLRaw eGewerbe 

Erstaufbau und Aktualisierung eines zentralen gespiegelten 

Gewerbebestandes. Auf Basis der Aktualisierungen werden 

Weiterleitungen für diverse Empfänger generiert und übermittelt 

z.B. IHK, Statistik, Finanzämter, Arbeitsschutz, Bundesanstalt für 

Arbeit, Berufsgenossenschaft, Eichdirektion , Hauptzollämter, HWK, 

Registergericht, Immissionsschutz. Ebenso werden im 

GovermentGateway erzeugte Gewerbemeldungen an die 

Gewerbeämter weitergeleitet. 

DatMLRaw und 

ediFact 

asynchron Sept. 2008 

XMeld VAMS Vorausgefüllter Meldeschein XMeld synchron Okt. 2008 











xdomea Baupruef 

Weiterleitungen von Daten zwischen den Beteiligten im 

Baugenehmigungsverfahren. Dies sind sowohl Nachrichtenbrokerkunden, 

wie auch GovermentGateway-Fachverfahren. 

xdomea asynchron April 2009 

XhD BDr 

Kommunikationsprozesse zwischen Pass-, Personalausweis- und 

Ausländerbehörden einerseits und der Bundesdruckerei 

andererseits. Dabei handelt es sich um die Abwicklung von 

Bestellvorgängen für Reisepässe, Personalausweise, 

Reiseausweise und elektronische Aufenthaltstitel. 

XhD 

asynchron 

u. synchron 

(Expressbestellungen) 

Juni 2010 

XhD Sperrdienst 

xdomea eAGS 

XAusländer DÜ 

Sperrmeldungen der Personalausweis- und Ausländerbehörden mit 

dem zentralen Sperrdienst beim Bundesverwaltungsamt. 

Weiterleitungen von Daten zwischen den Beteiligten für den 

elektronischen Aufgrabeschein. Dies sind sowohl Nachrichtenbrokerkunden, 

wie auch GovermentGateway-Fachverfahren. 

Datenübermittlungen (DÜ) auf Basis XAusländer z.B. DÜ zwischen 

den Ausländerbehörden, DÜ zwischen Ausländer- und 

Meldebehörden, Datenübermittlungen zwischen 

Ausländerbehörden und dem BAMF (Bundesamt für Migration und 

Flüchtlinge). 

XhD synchron Okt. 2010 

xdomea asynchron Juni 

2011 

XAusländer asynchron Nov. 2011 











XPersonenstand DÜ 

XAusländer BAMFsync 

xdomea ScErVe 

PDOE Datenaustausch 

Datenübermittlungen (DÜ) auf Basis XPersonenstand z.B. DÜ 

zwischen Standesämter, DÜ an Meldebehörden und das zentrale 

Testamentsregister 

Synchroner Versand und Empfang mit dem Bundesamt für 

Migration und Flüchtlinge 

Innerhalb des Kommunikationsprozesses des Dienstes ScErVe 

(Scannen, Erkennen, Verteilen) werden in einer Post- und 

Scanstelle eingehende Dokumente (in schriftlicher oder 

elektronischer Form) an zuständige Fachverfahren oder 

Vorgangsbearbeitungssysteme in elektronischer Form (xdomea- 

Nachrichten) mittels des Nachrichtenbrokers verteilt. 

Systemanbindung zwischen den IT-Verfahren KoPers FHH und 

GovernmentDirectory/HaSI Es werden sowohl Personen- und 

Organisationsdaten von KoPers FHH an GovernmentDirectory/HaSI 

als auch in umgekehrter Richtung übertragen werden. 

XPersonenstand asynchron April 2012 

XAusländer synchron November 

2013 

xdomea asynchron geplanter 

Einsatz in 

2014 

PDOE asynchron geplanter 

Einsatz in 

2014 











xdomea Baupruef Sync 

Filetransfer ZS Sync 

Synchroner Zugriff auf Bauvorlagen für Dienststellen mit eigenem 

Fachverfahren. 

Übermittlung von Informationen der Liefersysteme an das ZS (ZS 

steht für Zentrales Speichersystem. Das ZS ist eine 

Architekturkomponente für die Speicherung von Informationen für 

das Hamburger Informationsregister.) mit Hilfe des 

Nachrichtenbrokers. 

xdomea synchron geplanter 

Einsatz in 

2014 

Filetransfer synchron geplanter 

Einsatz in 

2014 











5.2 Übersicht Brokerdienste mit den dazugehörigen Schnittstellen 

Schnittstelle 

Versand 

Empfang 

Brokerdienste 

Intranet 

(XTA- 

WS) 

Intranet 

(TD- 

WS) 

Internet 

(OSCI) 

Intranet 

(WS) 

Internet 

(Gateway- 

PF) 

Intranet 

(SFTP) 

Intranet 

(FTP) 

Intranet 

(XTA- 

WS) 

Intranet 

(TD- 

WS) 

Internet 

(XTA 

NB) 

Internet 

(OSCI) 

XMeld DÜ (x) x x x x x 

XMeld Meld IT (x) x x x (x) x 

Filetransfer x x x x x x x 

DatMLRaw eGewerbe x x x x x x 

XMeld VAMS x (x) x x x (x) 

xdomea Baupruef x x x x 

XhD BDr x x x x x x 











XhD Sperrdienst x x x 

xdomea eAGS x x x x 

XAusländer DÜ x x x x 

XPersonenstand DÜ x x x x 

XAusländer BAMFsync x x x 

xdomea ScErVe x x 

PDOE Datenaustausch x x x x 

xdomea Baupruef Sync x x x 

Filetransfer ZS Sync x x x 

(x) = Technisch realisiert, wird aber noch nicht genutzt.

Funktionsbeschreibung Nachrichtenbroker - Dataport

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?