Einführung der Gesundheitskarte Spezifikatin Infrastrukturkmpnenten: Versin: 1.1.0 Stand: 04.05.2007 Status: freigegeben gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 1 vn 138
Dkumentinfrmatinen Änderungen zur Vrversin Im Rahmen der Überarbeitung wurde der seit [gemspecttd] v1.0.0 ptinale Charakter vn GTEL:Prvider bei der Bildung lkaler Service Namen (uddi:businessservice) Berücksichtigung. Die Behandlung der Indirect Bindings wurde verdeutlich. Das Dkument wurde an die neue Versin der Gesamtarchitektur angepasst. Zudem wurden detaillierte Aussagen zur Behandlung (Registrierung/Lkalisierung) vn Service und Indirect Bindings (Stichwrt: hstingredirectr) getrffen. Das Cache-Priming Knzept wurde überarbeitet und ein explizites Kapitel zur Service- Deregistrierung ergänzt (Kap. 5.1.2). Die vrgenmmenen Änderungen gegenüber der Vrversin wurden farblich hervrgehben. Bei Ergänzungen vn Kapiteln der Abschnitten wurde der besseren Lesbarkeit wegen lediglich die Überschrift markiert. Referenzierung Dieses Dkument kann durch andere Dkumente der gematik wie flgt referenziert werden: Quelle Herausgeber/Autr (Erscheinungsdatum): Titel [gemregd] gematik (04.05.2007): Einführung der Gesundheitskarte Spezifikatin Infrastrukturkmpnenten:, Versin 1.1.0 http://www.gematik.de/ Dkumenthistrie Versin Stand Kapitel Grund der Änderung, Hinweise Bearbeitung 0.0.1 14.06.06 Rudimentäre Knzeptstruktur gematik, AG8 0.0.2 20.06.06 Verfeinerung Dkumentenstruktur, Spez. UDDIund Telematik-Datenstrukturen 0.0.4 09.08.06 Grundlagen-Infs und Anhänge zu kannischen tmdels hinzugefügt, Einführungskapitel ergänzt 0.0.5 15.08.06 Datenmdellabbildungen, Grundlagen, phys. Design, Datenmapping 0.0.9 20.09.06 4, 5 Terminlgie, MEPs, WSDL-Elemente, UDDI Datenmdell, Registratur-Methdik, gematik, AG8 gematik, AG8 gematik, AG8 gematik, AG8 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 2 vn 138
Versin Stand Kapitel Grund der Änderung, Hinweise Bearbeitung 0.0.10 16.10.06 1, 2, 3, 4, 5, 6, A2 Registraturbeispiel WSDL-UDDI Mapping Registratur-Methdik, UDDI APIs, Lkalisierungsstrategie Zusammenfassung, Einleitung, UDDI APIs, Publisher Accunts, Lkalisierungsstrategie, Prduktauswahlkriterien, Glssar 0.0.12 23.10.06 5, C1, C3 Physische Architektur, (Frntend, Middle und Backend Tier), Healthchecking und Skalierung, Annahmen, Architekturentscheidungen 0.0.13 24.10.06 4, 5, C3, UDDI Server Tplgie, Skalierung, Architekturentscheidungen 0.0.16 31.10.06 Middle Tier Netzwerk Design ergänzt, Prduktauswahlkriterien ergänzt 0.0.17 05.12.06 Kmmentare der gematik-internen QS eingearbeitet gematik, AG8 gematik, AG8 gematik, AG8 gematik, AG8 gematik, AG8 0.9.0 06.12.06 freigegeben zur Vrkmmentierung gematik 1.0.0 29.03.07 Freigegeben gematik 1.0.1 25.04.07 Alle Anpassungen auf Basis [gemgesarch] v0.3.0; neues Kap. 5.1.2 (Deregistrierung); Behandlung vn Indirect Bindings verdeutlicht; Stilistische Überarbeitung gematik, AG8 1.1.0 04.05.07 Freigegeben gematik gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 3 vn 138
Inhaltsverzeichnis Dkumentinfrmatinen...2 Inhaltsverzeichnis...4 1 Zusammenfassung...7 2 Einführung...8 2.1 Zielsetzung und Gliederung des Dkuments...8 2.2 Zielgruppe...9 2.3 Geltungsbereich...9 2.4 Arbeitsgrundlagen...9 2.4.1 Bezugspunkte...9 2.4.2 Rahmenbedingungen...10 2.5 Abgrenzung des Dkuments...11 2.6 Verwendung vn Schlüsselwrten...11 3 Anfrderungen...13 3.1 Funktinale Anfrderungen...13 3.2 Nicht-funktinale Anfrderungen...14 4 Dienstüberblick...15 4.1 Grundlagen...15 4.1.1 Terminlgie...15 4.1.2 Einrdnung des UDDI Registraturdienstes...17 4.1.3 Message Exchange Patterns...19 4.2 Datenbasis...20 4.2.1 Datenbjekte der Telematik...20 4.2.2 WSDL-Definitinen...21 4.2.2.1 Abstrakte Beschreibung...21 4.2.2.2 Knkrete Beschreibung...22 4.3 UDDI-Datenmdell...24 4.3.1 businessentity...25 4.3.2 businessservice...27 4.3.3 bindingtemplate...29 4.3.4 tmdel...30 4.4 UDDI-Benutzerschnittstellen...32 4.4.1 Publishing API...32 4.4.1.1 Authentisierung...32 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 4 vn 138
4.4.1.2 Autrisierung...33 4.4.1.3 API Referenz...33 4.4.2 Inquiry API...36 4.4.2.1 API Referenz...36 4.4.2.2 Steuerung des Suchverhaltens...37 4.4.3 API-Rückmeldungen...38 4.4.3.1 Psitive Rückmeldungen...38 4.4.3.2 Fehlerrückmeldungen...40 4.5 UDDI Tplgie...42 4.5.1 Operatr Nde...42 4.5.2 Operatr Clud...43 4.5.3 Replikatin...43 4.6 UDDI-Sicherheit...44 5 Knzeptinelle Umsetzung...45 5.1 Sftware-technische Architektur...45 5.1.1 Registrierung vn Diensten...45 5.1.1.1 Allgemeine Anfrderungen und Ziele...45 5.1.1.2 Zu unterstützende Publishing API Funktinen...46 5.1.1.3 Authentisierung und Autrisierung auf Nachrichtenebene...46 5.1.1.4 Registratur-Methdik...48 5.1.1.5 Werkzeuggestützte Registratur...55 5.1.1.6 Exemplarische Registratur vn UDDI Entitäten...56 5.1.2 Deregistrierung vn Diensten...62 5.1.2.1 Allgemeine Anfrderungen und Ziele...62 5.1.2.2 Zu unterstützende Publishing API Funktinen...63 5.1.2.3 Authentisierung und Autrisierung auf Nachrichtenebene...63 5.1.2.4 Deregistratur-Methdik...63 5.1.2.5 Werkzeuggestützte Deregistrierung...64 5.1.3 Lkalisierung vn Diensten...64 5.1.3.1 Allgemeine Anfrderungen und Ziele...64 5.1.3.2 Zu unterstützende Inquiry API Funktinen...67 5.1.3.3 Lkalisierungsstrategie...67 5.1.3.4 Use Case: Registry Cache Priming...68 5.1.3.5 Use Case: Registry Cache Refresh...75 5.1.4 Laufzeitumgebung des Registraturdienstes...79 5.1.5 Persistenzschicht des Registraturdienstes...80 5.2 Physische Architektur...81 5.2.1 Verschlüsselung und Authentisierung auf Verbindungsebene...81 5.2.2 3-Tier Design...83 5.2.2.1 SDS Frntend Tier...86 5.2.2.2 SDS Middle Tier...91 5.2.2.3 SDS Backend Tier...94 5.2.2.4 Fazit...96 5.2.3 Vertikale Telematik Administratin Tier...97 5.2.4 Sicherheitsznen...98 5.3 Betriebliche Aspekte...99 5.3.1 Mnitring und Healthchecking...99 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 5 vn 138
5.3.2 Ausfallszenarien und Systemverfügbarkeit...103 5.3.3 Skalierung und Mengengerüste...105 5.3.4 Datensicherung und -wiederherstellung...107 6 Kriterien für die Prduktauswahl...108 Anhang A...112 A1 Abkürzungen und Akrnyme...112 A2 Glssar...114 A3 Abbildungsverzeichnis...115 A4 Tabellenverzeichnis...116 A5 Referenzierte Dkumente...117 A6 Kannische UDDIv2 tmdels...120 A6-1 UDDI v2 Types Categry System tmdel...120 A6-2 UDDI General v2 Keywrds Categry System tmdel...121 A6-3 UDDI Business Registry Pstal Address Structure tmdel (ptinal)...122 A7 Kannische SDS tmdels...124 A7-1 Telematik ServiceType tmdel...125 A7-2 WSDL Entity Type tmdel...126 A7-3 XML Namespace tmdel...127 A7-4 XML Lcal Name tmdel...128 A7-5 WSDL prttype Reference tmdel...129 A7-6 Prtcl Categrizatin tmdel...130 A7-7 Transprt Categrizatin tmdel...131 A7-8 SOAP Prtcl tmdel...131 A7-9 HTTP Prtcl tmdel...132 A7-10 WSDL Address tmdel...133 A7-11 WS-I Cnfrmance Claim tmdel (ptinal)...133 A8 Hinweise zur Lesbarkeit der XML Schema Diagramme...134 Anhang B...136 B1 Annahmen...136 B2 Klärungsbedarf...136 B3 Architekturentscheidungen Kapitel 5...136 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 6 vn 138
1 Zusammenfassung Mit Verabschiedung des Gesetzes zur Mdernisierung der gesetzlichen Krankenversicherung (GKV-Mdernisierungsgesetz GMG) wurde die Einführung der elektrnischen Gesundheitskarte (egk) für das deutsche Gesundheitswesen beschlssen. 291b des Fünften Szialgesetzbuches (SGB V), welches zum 28.06.2005 in Kraft getreten ist, frdert in der Knsequenz den Aufbau und Betrieb der für die Einführung und Anwendung der egk erfrderlichen Telematikinfrastruktur. Innerhalb dieser Infrastruktur ist ein zentraler Registrierungsdienst (sg. ServiceDirectryService (SDS)) bereitzustellen, welcher zur Lkalisierung vn Telematik Fachdiensten und anderen mittelbaren der unmittelbaren Diensten dient. Der SDS hält die technischen Beschreibungen vn Telematikdiensten persistent vr und ermöglicht unter Verwendung standardisierter Zugriffsmethden die eindeutige Identifizierung gleichartiger Dienstinstanzen und ihrer Kmmunikatinsadressen. Bei den zu registrierenden Diensten handelt es sich um akkreditierte Services, die statische und innerhalb der Telematikinfrastruktur bekannte Schnittstellen verwenden. Eine dynamische Beschreibung und Adressierung dieser Dienste ist smit nicht erfrderlich. Die sftware-technische Grundlage des Knzepts bildet der UDDIv2 Standard. SDS ist die Implementierung einer privaten, d. h. telematik-internen, Service Registry auf Basis vn UDDIv2. Der lgische Aufbau des Telematik-Registry-Service sieht ein eng an die Erfrdernisse der Telematikgesamtarchitektur angelehntes Datenmdell vr. Das gewählte Datendesign bietet darüber hinaus genügend Flexibilität für die Abbildung zusätzlicher Anfrderungen und stellt s in Summe leistungsfähige und einfach zu handhabende Mechanismen zur Dienstlkalisierung bereit. Die SDS-Architektur leistet auch die Umsetzung sicherheitsrelevanter Vrgaben der Telematik an die Authentisierung und granulare Autrisierung der Dienstnehmer swie hinsichtlich der Vertraulichkeit der übermittelten Daten. Physisch wird SDS als lastverteilte Multi-Tier-Architektur umgesetzt. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 7 vn 138
2 Einführung 2.1 Zielsetzung und Gliederung des Dkuments Dieses Dkument beschreibt das Design der Telematik-Registrierungsinfrastruktur und bildet smit die Grundlage für dessen spätere technische Realisierung. Flgende Gliederung liegt dem Dkument zugrunde: Kapitel 1, Zusammenfassung fasst die Kernaussagen dieses Dkumentes zusammen. Kapitel 2, Einführung beschreibt Zielsetzung, Gliederung, Zielgruppen, Geltungsbereich, Arbeitsgrundlagen, Bezugspunkte, Rahmenbedingungen und Knventinen der Spezifikatin swie die Abgrenzung zu anderen, thematisch verwandten der ergänzenden Dkumenten. Kapitel 3, Anfrderungen dkumentiert funktinale und nicht-funktinale Annahmen und Anfrderungen an den Registraturdienst. Kapitel 4, Dienstüberblick beschreibt Zweck, Grundlagen, Basisfunktinalität, Datenmdell, Benutzerschnittstellen und Betriebs- bzw. Sicherheitsaspekte des Registraturdienstes. Kapitel 5, Knzeptinelle Umsetzung beschreibt das sftware-technische Design des Registraturdienstes, seine Abbildung auf eine physikalische Server Tplgie swie betriebliche Aspekte. Kapitel 6, Kriterien für die Prduktauswahl stellt eine Auflistung vn generischen, herstellerunabhängigen Kriterien als Basis für die Auswahl einer auf UDDI basierenden Registraturlösung bereit. Anhang A beinhalten eine Liste vn verwendeten Abkürzungen und Akrnymen, ein Glssar, eine Zusammenstellung der verwendeten kannischen technischen Mdelle und Hinweise zum Lesen der im Text verwendeten grafischen XML Schema Diagrammen. Anhang B dkumentiert die referenzierte Sekundärliteratur swie Abbildungs- und Tabellenverzeichnisse. Anhang C enthält eine Aufstellung zu klärender Punkte und Fragestellungen, swie in kmprimierter Frm die Architekturentscheidungen aus Kapitel 5. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 8 vn 138
2.2 Zielgruppe Dieses Dkument richtet sich primär an IT-Architekten, die mit der technischen Realisierung der Telematik-Registrierungsinfrastruktur gemäß der hier dargelegten Spezifikatin betraut sind. Daneben beinhaltet dieses Papier aber auch Infrmatinen, die für SOA-Architekten, Web- Service-Entwickler, System- und Netzwerk-Administratren, IT-Supprt-Ingenieure, IT- Manager und technisch interessierte Benutzer vn Interesse sein können. Einen guten Überblick über die Datenstrukturen und die Basisfunktinalität des Registrierungsdienstes gibt Kapitel 4. Für Leser, die mit der technischen Umsetzung des Knzepts befasst sind, ist das detaillierte Studium vn Kapitel 5 unerlässlich. Lesern, die vrrangig an den knzeptinellen Ergebnissen und weniger an den Überlegungen, die zu diesen Ergebnissen führten, interessiert sind, wird das Studium des Anhangs C3 nahe gelegt. Dieser Abschnitt fasst die wesentlichen Ergebnisse dieses Papiers nchmals in kmprimierter Frm zusammen. Vertrautheit mit HTTP, XML und SOAP swie mit grundlegenden Knzepten vn Web Services, WSDL und service-rientierten Architekturen werden für das Verständnis dieses Textes vrausgesetzt. 2.3 Geltungsbereich Dieses Dkument und die darin getrffenen Festlegungen sind bindend für das IT- Persnal, welchem die technische Umsetzung dieses Knzepts bliegt. Daneben beeinflussen die in dieser Spezifikatin getrffenen Maßgaben auch die Entscheidungen der Architekten, denen das Design bzw. die Implementierung des Brker Service bliegt. 2.4 Arbeitsgrundlagen 2.4.1 Bezugspunkte Die Grundlage für die Spezifikatin des Registrierungsdienstes bilden die Anfrderungen und Festlegungen aus den flgenden Dkumenten der gematik: Gesamtarchitektur [gemgesarch] TelematikTransprt-Details [gemspecttd] Bedrhungs- und Risikanalyse [gembur] Schutzbedarfsfeststellung [gemschbedf] Netzwerkspezifikatin [gemnet] gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 9 vn 138
Netzwerksicherheit [gemnwsich] Namensdienst [gemnamd] System und Service Level Mnitring [gemsysslm] Diese wie alle weiteren in diesem Knzeptpapier referenzierten fachlichen und technischen Dkumente sind in Anhang B aufgelistet. 2.4.2 Rahmenbedingungen Das vrliegende technische Design beruht auf den einschlägigen RFCs und technischen Standards zum Thema Universal Descriptin, Discvery and Integratin (UDDI) und anderer assziierter Technlgien wie XML, SOAP, WSDL und Web Services. Es rientiert sich an den Knzepten, die integrative Architekturmdelle wie das Cmpsite Cmputing Mdel vrgeben und die vn service-rientierten Architekturen (SOA) umgesetzt werden. Maßgeblichen Anteil an der Bereitstellung der für UDDI grundlegenden Technlgien und technischen Knzepte hatten und haben die flgenden Organisatinen: Internet Engineering Task Frce (IETF) eine für alle Interessierten ffene internatinale Gemeinschaft vn Netzwerk-Designern und -Betreibern, Lieferanten vn Netzwerkprdukten und Frschern, die sich mit der Weiterentwicklung der Internet-Architektur und dem reibungslsem Betrieb der weltweiten Internet-Plattfrm beschäftigt Wrld Wide Web Cnsrtium (W3C) ein internatinales Knsrtium, das ffene, d. h. nicht-prprietäre, Web Standards (sg. W3C Recmmendatins) und Richtlinien für Web-Sprachen und -Prtklle entwickelt und veröffentlicht Organisatin fr the Advancement f Structured Infrmatin Standards (OASIS) ein zunächst als SGML Open gegründetes und später umbenanntes, nicht-prfitrientiertes, internatinales Knsrtium vn Herstellern und Benutzern aus dem IT-Sektr, welches die Entwicklung, Knvergenz und Einführung vn e-business-, Web Service-, Security- und XML-verwandten Standards vrantreibt. Web Services Interperability Organizatin (WS-I) eine ffene Organisatin der IT-Industrie, die es sich zur Aufgabe gemacht hat, Web Services Interperabilität über Plattfrm-, Betriebssystem- und Prgrammiersprachen-grenzen hinweg vranzubringen. Der dafür gewählte Ansatz stützt sich auf generische Prtklle zum kmpatiblen Nachrichtenaustausch. Die Organisatin unterstützt Kunden und Anwender bei der Entwicklung interperabler Web Services durch Richtlinien, Empfehlungen und die Bereitstellung vn Ressurcen. Die Ausführungen in diesem Dkument beziehen sich auf UDDIv2, einem im Juli 2002 verabschiedeten OASIS Standard. Diese Versin ist zum heutigen Zeitpunkt (Oktber 2006) im SOA- und Web Services Umfeld weitgehend etabliert und bildet die Grundlage für eine Vielzahl vn Implementierungen einer UDDI Registry. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 10 vn 138
2.5 Abgrenzung des Dkuments Die sich für Release 3 1 abzeichnenden, überarbeiteten SDS-Vrgaben der Gesamtarchitektur werden grundlegende Auswirkungen insbesndere auf die Registratur- Methdik und auf die Use Cases (Stichwrt: brkerseitiger Registry Cache) haben. Hatte [gemgesarch] bislang eine strikte und limitierende Mdellierung der Datenbjekte in SDS gefrdert, s ist für Release 3 ein neuer, ffenerer Ansatz zu erwarten, der die Ausprägung der Objekte im eigentlichen Sinne des UDDI-Standards und eine intensivere Nutzung vn UDDI-Kategrisierungssystemen erlaubt. Diese neue Offenheit ist grundsätzlich zu begrüßen, da sie zum einen den Anwendungsszenarien vn UDDIbasierten Registraturen besser gerecht wird und zum anderen flexiblere Verwendungsmöglichkeiten vn SDS innerhalb der Telematikinfrastruktur befördert. Die in diesem Dkument als Teil des sg. Release 2 der Telematik-Spezifikatinen getrffenen Architekturentscheidungen reflektieren einen Interimsstand. Die Festlegungen sind einerseits knfrm zu den aktuellen Versinen der Gesamtarchitektur ([gemgesarch]) und anderer assziierter Dkumente 2, andererseits werden die im Bereich der Dienstregistrierung erwarteten technischen Paradigmenwechsel (s..) zumindest in Teilen vrweggenmmen. Nicht Gegenstand dieses Dkuments sind knzeptinelle Überlegungen zu Netzwerkinfrastruktur, spezifischen Middleware-Kmpnenten (z. B. Verzeichnisdienste, PKI, etc.) der Diensten, die die Geschäftslgik der Telematik abbilden (Fachdienste) der rchestrieren (Brker Service). Existenz und Verfügbarkeit dieser physikalischen und lgischen Kmpnenten werden allerdings vrausgesetzt. Ebenfalls nicht Gegenstand der Betrachtungen sind betriebliche Belange (z. B. Betriebsführungsprzesse, Test- und Akkreditierungsprzesse für Telematikdienste, etc.). Diesbezüglich wird auf die Arbeitsergebnisse der anderen Arbeitsgruppen der gematik verwiesen. Dieses Dkument beinhaltet keine Empfehlungen hinsichtlich zu verwendender Hardware-bzw. Betriebssystemplattfrmen der spezifischer UDDI-Registraturlösungen. 2.6 Verwendung vn Schlüsselwrten Für die genauere Unterscheidung zwischen nrmativen und infrmativen Inhalten werden die flgenden, dem RFC 2119 (siehe [RFC2119]) angelehnten, in Grßbuchstaben geschriebenen deutschen Schlüsselwrte verwendet: MUSS abslutgültige und nrmative Festlegung DARF NICHT abslutgültiger und nrmativer Ausschluss SOLL Empfehlungen zu Festlegungen (Abweichungen sind in begründeten Fällen möglich) 1 Vraussichtlich im Smmer 2007. 2 Insbesndere [gemspecttd]. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 11 vn 138
SOLL NICHT Empfehlungen zu Ausschlüssen (Abweichungen sind in begründeten Fällen möglich) KANN fakultative Eigenschaften; haben keinen Nrmierungs- und keinen allgemeingültigen Empfehlungscharakter gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 12 vn 138
3 Anfrderungen Dieses Kapitel dkumentiert die funktinalen und nicht-funktinalen Anfrderungen an den Registrierungsdienst. In Anhang C3 werden die getrffenen SDS-Architekturentscheidungen den hier definierten Anfrderungen zugerdnet. 3.1 Funktinale Anfrderungen Die generellen Anfrderungen an eine Registrierungsinfrastruktur der Telematik bestehen darin, dienstrelevante Infrmatinen wie Service-Klassifizierungen, Service-Namen und assziierte Service-Adressen in Frm vn Datenbjekten bereitzustellen und diese mittels genrmter Prtklle abfragbar zu machen. Davn abgeleitet ergeben sich die in der nachflgenden Tabelle beschriebenen funktinalen Annahmen, welche zur leichteren Identifizierung mit eindeutigen Kennungen versehen sind. Tabelle 1: Funktinale Anfrderungen Kennung RD-FA-010 RD-FA-020 RD-FA-030 RD-FA-040 RD-FA-050 RD-FA-060 Beschreibung der Anfrderung(en) Allgemein Der Registrierungsdienst stellt einen auf UDDIv2 basierenden Mechanismus bereit, der das einfache und flexible Registrieren und Auffinden, aber auch Deregistrieren vn standardisierten Telematik-Services (mit bekannten Interfaces) erlaubt. Schnittstellen Der Registrierungsdienst ist über die genrmten Inquiry bzw. Publishing APIs des UDDIv2 Standards adressierbar. UDDI Betriebsart Zum Einsatz kmmt eine Multi-Tier-Architektur. Datenmdellierung Das zur Abbildung der Telematikdienstinfrmatinen genutzte UDDI-Datenmdell muss den Erfrdernissen der Telematikgesamtarchitektur genügen und ausreichende Flexibilität für künftige Anfrderungen bereitstellen. Sicherheit des Dienstes Der Registraturdienst muss einen effektiven Zugriffsschutz auf Verbindungs- und Nachrichtenebene gewährleisten, um Datenmanipulatin auszuschließen. Skalierbarkeit des Dienstes Der Registraturdienst ist s zu gestalten, dass er hrizntal und/der vertikal skaliert. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 13 vn 138
Kennung RD-FA-070 Beschreibung der Anfrderung(en) Verfügbarkeit des Dienstes Der Registraturdienst als Verzeichnisdienst ist gem. der gematik Schutzbedarfsfeststellung hchverfügbar auszulegen 3. Der Ausfall einzelner Kmpnenten des Registratur-Dienstes darf nicht zum grundsätzlichen Ausfall des gesamten Dienstes führen. 3.2 Nicht-funktinale Anfrderungen In der nachflgenden Tabelle sind die nicht-funktinalen Anfrderungen für den Registraturdienst beschrieben und zur leichteren Identifizierung mit eindeutigen Kennungen versehen. Tabelle 2: Nicht-funktinale Anfrderungen Kennung RD-NFA-010 RD-NFA-020 RD-NFA-030 Beschreibung der Anfrderung(en) Physikalische Sicherheit Alle Kmpnenten des Registraturdienstes sind durch geeignete rganisatrische und betriebliche Maßnahmen gegen unbefugten physikalischen Zugriff durch Dritte zu sichern. Netzwerksicherheit Der Registraturdienst ist durch geeignete Maßnahmen vr Netzwerkzugriffen außerhalb der HTTP(S)/SOAP-Prtkllspezifikatinen zu schützen. Insbesndere ist in diesem Zusammenhang auch die Vertraulichkeit der zu einem Dienstnehmer übermittelten Daten zu gewährleisten. Reprting Die Server-Systeme des Registraturdienstes unterliegen einem permanenten System-Mnitring, welches auf Basis vn Testnachrichten die SLAs überprüft und Indikatren bereitstellt, um Ausfälle und Fehlfunktinen im Hard- und Sftware-Umfeld möglichst sfrt erkennen zu können (RD-FA-070). 3 Siehe [gemschbedf], Anhang A3. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 14 vn 138
4 Dienstüberblick 4.1 Grundlagen 4.1.1 Terminlgie Im Rahmen dieses Dkuments werden eine Reihe vn technischen Termini aus dem Umfeld vn service-rientierten Architekturen (SOA) und Web-Services benutzt, die zunächst kurz erläutert werden sllen. Die Begriffserläuterungen sind mit Beispielen aus der Service-Infrastruktur der Telematik versehen, um s ihr Verständnis zu erleichtern. Im Wesentlichen werden zwei Begriffskategrien betrachtet 4 : Service-Rllen Service-Mdelle (Web-) Services zu denen auch der Registrierungsdienst zu rechnen ist können abhängig vn dem Kntext, in dem sie genutzt werden, unterschiedliche Rllen annehmen. Das bedeutet, dass ein Dienst innerhalb ein und desselben Geschäftsvrfalls seine Rlle mehrfach ändern kann. Flgende fundamentale Rllen sind zu unterscheiden: Service Prvider - eine (Server) Rlle, die auf die Bereitstellung eines Dienstes abhebt, z. B.: Registraturbetreiber: Service Prvider, genauer eine Service Prvider Entität, als die Organisatin, die den Telematik-Registrierungsdienst zur Verfügung stellt. Registrierungsdienst: ein Service Prvider Agent, als der eigentliche Dienst, der einem entsprechenden Message Exchange Pattern (MEP) zum Nachrichtenaustausch gehrcht 5. Service Requestr - eine (Client) Rlle, die als natürliches Gegenstück zum Service Prvider auf die Inanspruchnahme eines Dienstes abhebt, z. B.: Brker Betreiber: Service Requestr, genauer eine Service Requestr Entität, als die Organisatin, die als Brker-Betreiber den Telematik- Registrierungsdienst nutzt. BrkerS: ein Service Requestr Agent, als ein Dienst, der den Telematik- Registrierungsdienst nutzt, um Dienstbeschreibungen ausfindig zu machen. 4 Siehe dazu auch [SOA05]. 5 Für die Definitin vn MEP siehe Kap. 4.1.1.3. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 15 vn 138
Initialer Sender - eine Service Requestr Rlle, die die Übertragung einer Nachricht initiiert, z. B.: Primärsystem bzw. Knnektr der Leistungserbringer in Kmbinatin mit der egk eines Versicherten: ein initialer Sender, der über eine entsprechende Request-Nachricht einen Fachdienst anspricht. Ultimativer Empfänger - das Gegenstück zum initialen Sender; typischerweise ein Service Prvider (Agent) als letzte Kmpnente entlang des Weges, den eine Nachricht nimmt (sg. Message Path), z. B.: Verrdnungsdatendienst: der ultimative Empfänger einer VODD Request- Nachricht, die vm BrkerS weitergereicht wurde. Registrierungsdienst: der ultimative Empfänger einer UDDI Inquiry- Nachricht, die vm BrkerS - hier in seiner Funktin als initialer Sender - initiiert wurde. Mediatr (Intermediary) - ein der mehrere in einem Message Path zwischen initialem Sender und ultimativen Empfänger zwischengeschaltete Dienst- Agenten, die eingehende Nachrichten entweder unverändert an eine nachflgende Lkatin weiterleiten (sg. Passive Intermediary) der aber die Nachrichten zunächst bearbeiten, ihren Inhalt verändern und anschließend an eine Ziellkatin weiterschicken (sg. Active Intermediary). BrkerS: ein hybrider Mediatr, der je nach Kntext swhl als Passive als auch als Active Intermediary fungiert; er steht als zentrale Kmpnente zwischen den Knnektren und den Fachdiensten und übernimmt u. a. die Aufgabe des Request-Rutings. Mitglied einer Service Cmpsitin - ein Set vn Diensten, die im Verbund einen Vrfall abarbeiten; die einzelnen Services werden als Service Cmpsitin Members bezeichnet. Die Fähigkeit, Dienst-Arrangements zu bilden, ist ein zentraler Aspekt vn service-rientierten Architekturen und wird häufig durch verwandte Knzepte wie Dienst-Orchestrierung (WS-BPEL) und - Chregraphie (WS-CDL) beeinflusst. Bsp.: BrkerS, SDS, TrustedS, AuditS, Fachdienste, etc.: Mitglieder diverser Service Cmpsitins Service-Rllen sind hinsichtlich der Art vn Funktinalität, die vn einem Dienst dargebten werden, vllkmmen agnstisch. Sie beschreiben rein generische Zustände, die ein Dienst innerhalb eines (generischen) Kntexts annehmen kann. In der praktischen Anwendung vn Diensten hat sich ein Klassifizierungsschema für Services herausgebildet, welches sich an der jeweils zur Verfügung gestellten Applikatinslgik und der geschäftsbezgenen Rlle, die ein Dienst innerhalb der Gesamtlösung einnimmt, rientiert. Dieses Klassifizierungsschema, sg. Service Mdelle, kennt u. a. flgende wesentliche Ausprägungen: gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 16 vn 138
Business Service Mdel ein fundamentaler, autnmer SOA-Baustein, der eine eindeutige Geschäftslgik innerhalb whl-definierter funktinaler Grenzen kapselt und ftmals als Teil einer Service Cmpsitin zur Ausführung kmmt. Verrdnungsdatendienst (VODD): kapselt Funktinalitäten zu Verrdnungsdaten (Rezepte, etc.) der Versicherten im Rahmen einer entsprechenden Facharchitektur und wirkt als Teil einer vm BrkerS gesteuerten Service Cmpsitin mit. Versichertenstammdatenmanagement (VSDM): analg zu VODD für die Stammdaten der Versicherten. Utility Service Mdel jeder generische, nicht-applikatinsspezifische Dienst der Dienst-Agent, der aufgrund seines Designs seine Wiederverwendbarkeit befördert. AuditS: implementiert ein versichertenzentriertes Datenzugriffsauditlg (Auditlg), das es dem Versicherten (und nur ihm) erlaubt, Zugriffe zu seinen Daten fachdienstübergreifend zu verflgen swie retrspektiv Verletzungen vn Datenschutz und Datensicherheitsvrschriften festzustellen und nachzuweisen. : registriert Fachdienste und Utility Services und stellt die Registraturinfrmatinen für Abfragen bereit. Cntrller Service Mdel dedizierter Steuerungsdienst in einem Dienst- Arrangement (Service Cmpsitin), der das Zusammenspiel vn Service Cmpsitin Members zur Abarbeitung eines Geschäftsvrfalls krdiniert. BrkerS: hrizntale Dienste wie SDS und AuditS swie der VSDM Fachdienst werden vm BrkerS in einer Service Cmpsitin assembliert und gemäß der BrkerS-internen Applikatinslgik aufgerufen, um z. B. einen Geschäftsvrfall im Bereich der Versichertenstammdaten abzuarbeiten. Wie bei den Service-Rllen gilt auch hier, dass ein Dienst mehreren Service-Mdellen angehören kann. 4.1.2 Einrdnung des UDDI Registraturdienstes Es ist eine weit verbreitete, aber irrige Annahme, dass die Implementierung des UDDI- Prtklls (Universal Descriptin, Discvery and Integratin) einen Registraturdienst speziell für WSDL-Dkumente bereitstellt. Tatsächlich findet sich in der UDDI- Spezifikatin kein direkter Bezug zu WSDL (Web Services Descriptin Language, siehe [WSDL1.1]). Als einer der zentralen Bausteine vn service-rientierten Architekturen ist UDDI vielmehr ein generischer, vn OASIS genrmter Registrierungsstandard, der eine kmpatible Plattfrm zum Erfassen, Publizieren und vllautmatischen Auffinden vn Infrmatinen zu jeder Art vn Dienst, Legacy-Anwendung, Spezifikatin der Sftware-Bestand definiert. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 17 vn 138
S können neben Namensraum- und Schema-Definitinen, Element-Strukturen und XSLT Stylesheets auch UML-Mdelle und andere Kmpnenten wie zum Beispiel eben auch WSDL-Artefakte registriert werden. Das UDDI-Prjekt basiert auf einer Reihe vn grundlegenden IT-Standards, die vm W3C und der IETF entwickelt wurden. Dies sind im Einzelnen: das Dmain Name System (DNS, siehe [RFC1034] und [RFC1035]) die Extensible Markup Language (XML, siehe [XML103]) das Hypertext Transfer Prtkll (HTTP, siehe [RFC2616]) das Simple Object Access Prtcl (SOAP, siehe [SOAP1.1]) UDDI definiert ein relativ einfaches Datenhaltungsmdell und stellt Hilfsknstrukte zur Verfügung, die eine Kategrisierung der in einer Registratur gehaltenen Infrmatinen auf Basis vn Schlüssel-Wert-Paaren ermöglichen. Die UDDI-Technlgie bildet die Grundlage für Umsetzung des in [gemgesarch] gefrderten Telematik-Registraturdienstes, des sg. Service Directry Service (SDS). SDS ist die Implementierung eines Registry Web Services, basierend auf UDDIv2 6. Die Verwendung vn UDDIv2 ergibt sich aus der für die Telematikarchitektur aufgestellten Frderung nach Übereinstimmung mit dem WS-I Basic Prfile Versin 1.1 ([BasicPrfile1.1], [BasicPrfile1.1 Errata]) und dem WS-I Basic Security Prfile Versin 1.0 [Basic Security Prfile]. Im Service Directry Service werden hrizntale Dienste und Fachdienste der Telematik auf Basis ihrer jeweiligen WSDL-Definitinen und anderer, telematikspezifischer Datenquellen registriert. Dies beinhaltet insbesndere die Registrierung vn Dienstbetreiber- und Diensttyp-Infrmatinen swie die Speicherung der Kmmunikatinsadressen, unter denen diese Dienste angesprchen werden können. SDS ist netzwerktechnisch über das sg. Backend-VPN 7 direkt an den Brker Service (BrkerS) angebunden. Letzterer nutzt das vn der Registratur bereitgestellte UDDIv2 Inquiry API, um mittels entsprechender Suchfilter die Kmmunikatinsadresse einer spezifischen Dienstinstanz zu ermitteln. Das zentrale Implementierungsziel vn SDS ist es, einen Mechanismus bereitzustellen, der das einfache und flexible Registrieren und Auffinden vn standardisierten Services mit bekannten und statischen Interfaces erlaubt. Das flgende Architekturleitbild verdeutlicht die Einrdnung der SDS-Infrastruktur in die Telematikinfrastruktur. Die Darstellung leitet sich aus den in Kapitel 2.4.1 genannten Grundlagendkumenten ab: 6 Siehe [UDDI2API], [UDDI2CS], [UDDI2DS], [UDDI2OS], [UDDI2REP], [UDDI2RS], [UDDI2TMOD], [UDDI2WSID] und [UDDI2XS]. 7 Siehe [gemnet]. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 18 vn 138
Service Cnsumer Tier Cnsumer Adapter Tier Telematik Tier Back End Service Prvider Tier Leistungserbringer / Primärsystem Knnektr VPN / Zugangsnetz Web-Server (Web-Frntend) Brker-Applikatins-Server (Anwendungs-Gateway) Fachdienste SVS VSDM BrkerS TrustedS CAMS Registry Cache SCS VODD AMD Brker DB (Brker Strage) epa SDS AuditS ServiceMnitring Service (SLA) Fünf BrkerServices insgesamt: A) Für Leistungserbringer Ärzte (externer Betreiber) B) Für Leistungserbringer Zahnärzte (externer Betreiber) C) Für Leistungserbringer Krankenhäuser (externer Betreiber) D) Für Leistungserbringer Aptheken E) Für e-kisk und Versicherter@hme und als Back Up für die anderen (gematik als Betreiber) Maximal zwei AuditServices insgesamt (evtl. verschiedene, aber externe Betreiber) Ein ServiceDirectryService insgesamt (externer Betreiber) Fünf ServiceMnitringServices insgesamt (für jeden Brker einer, externer Betreiber) Abbildung 1: SDS-Instanz innerhalb der Telematikinfrastruktur Im Rahmen des Telematikdiensteverbundes fungiert SDS je nach Kntext als Service Prvider Agent, Ultimativer Empfänger, Service Cmpsitin Member. Darüber hinaus lässt sich der Registraturdienst dem Utility Service Mdel zurdnen. 4.1.3 Message Exchange Patterns SDS rientiert sich an einem Dienst-Aktivitätsmdell, das auf dem Austausch vn Nachrichten (Message Exchange) beruht. Dieser Nachrichtenaustausch flgt einem festgelegten Muster (Pattern). Message Exchange Patterns verkörpern generische und abstrakte Vrlagen, die einen Satz vn vrfrmulierten Sequenzen für den Austausch vn Nachrichten bereitstellen. MEPs werden in zwei Kategrien eingeteilt: primitive der einfache MEPs; z. B.: Request-Respnse (IN-OUT) ein einfaches, ppuläres Muster für den Nachrichtenaustausch, bei dem eine Quelle (Service Requestr) eine (Request-) Nachricht an ein Ziel (Service Prvider Agent) schickt, welches gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 19 vn 138
in der Flge eine (Respnse-)Nachricht an die Quelle zurücksendet. Dienste, die diesem Muster flgen, erfrdern typischerweise Hilfsmittel, mit denen Antwrtnachrichten den entsprechenden Anfragenachrichten zugerdnet werden können (Stichwrt: Krrelatin). Das Request-Respnse MEP findet im Fall des Registraturdienstes swhl für die Abfrage vn Service-Infrmatinen als auch für die Registratur vn Diensten Anwendung. Fire-and-Frget ein einfaches, asynchrnes Muster, basierend auf der unidirektinalen Übertragung vn Nachrichten vn einer Quelle an ein der mehrere Ziele (single-destinatin, multi-cast, bradcast). kmplexe MEPs; primitive MEPs können als Bausteine größerer, kmplexer Muster assembliert werden; ein Beispiel hierfür ist das Publish-and-Subscribe MEP. 4.2 Datenbasis In diesem Kapitel werden Datenquellen, die die Grundlagen für die in der Registratur abzuspeichernden Infrmatinen liefern, genauer betrachtet. 4.2.1 Datenbjekte der Telematik Das TelematikTransprt-XML-Schema 8, welches die Struktur einer TelematikCre- Nachricht definiert, sieht im Wesentlichen zwei Elementen vr, mit deren Hilfe die für die Bearbeitung erfrderlichen Telematikdienste identifiziert werden können: GTEL:Prvider beinhaltet die Betreiber-Kennung; meint den für einen Dienst verantwrtlichen Betreiber GTEL:Type beinhaltet die Diensttyp-Kennung; beschreibt die Art des Dienstes Hinsichtlich der für das GTEL:Prvider Element zu erwartenden Wertemenge gibt es zum heutigen Zeitpunkt nch keine Festlegungen. Die Wertedefinitin erflgt im Rahmen der Dienstevergabe. Die nachflgende Tabelle zeigt eine Liste vn Werten, die nach heutigem Kenntnisstand als Diensttyp auftreten können. Tabelle 3: GTEL:Type exemplarische Werte (nicht abschließend) Element-Name Datentyp Werte Beschreibung GTEL:Type String VSDM VODD etc. Versichertenstammdatenmanagement Verrdnungsdatendienst und andere (zukünftige) Servicekennungen 8 Siehe http://ws.gematik.de/schema/tel/transprt/latest/telematiktransprt.xsd; weitere Details auch in Kap. 5.1.3.1. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 20 vn 138
Die gelisteten Werte sind als Annahmen zu verstehen; entsprechende Vrgaben zu ihrer eindeutigen Ausprägung werden final in den entsprechenden Fachknzepten getrffen. Diensttyp und Betreiberkennungen bilden aktuell die vrrangige, perspektivisch gesehen jedch nicht die alleinige Grundlage für die Kategrisierung der Telematikdienste innerhalb der SDS-Registratur. Im weiteren Verlauf dieses Dkuments werden wir die Begriffe Diensttyp bzw. ServiceType verwenden, um Zusammenhänge im Bereich der Klassifizierung vn Telematikdiensttypen zu beschreiben. Zur Adressierung spezifischer Dienstbetreiber werden die Begriffe Prvider[-ID] und Betreiber[-{ID Kennung}] synnym verwendet. 4.2.2 WSDL-Definitinen Die Web Services Descriptin Language (WSDL) gilt in Verbindung mit dem Design und der Beschreibung vn Diensten als einer der fundamentalen SOA-Technlgiestandards. Knsequenterweise finden WSDL-Definitinen auch innerhalb der Telematik SOA ihre Anwendung bei der Ausgestaltung der hrizntalen Dienste 9 swie der Fachdienste (VODD, VSDM). Einzelne Teile dieser Definitinen können (perspektivisch) zusammen mit den in Kapitel 4.2.1 vrgestellten Datenbjekten die Infrmatinsgrundlage für die Struktur und Ausprägung des Datenbestandes innerhalb der Serviceregistratur bilden. Zum besseren Verständnis insbesndere der Ausführungen in Kapitel 5.1.1.4 werden Struktur und Inhalte vn WSDL-Dkumenten in diesem Kapitel kurz erläutert. WSDL-Dkumente beschreiben den Zugangspunkt zu einem Service Prvider Agent, den sg. (Service) Endpint. Darin enthalten sind die frmale Beschreibung der Endpunkt- Schnittstelle swie Implementierungsaspekte des jeweiligen Dienstes. Die dem Design vn WSDL zugrundeliegenden mdularen, wiederverwendbaren und in Bezug zueinander stehenden Artefakte lassen sich in zwei Kategrien subsumieren. 4.2.2.1 Abstrakte Beschreibung Dieser Teil einer Service-Definitin findet sich im sg. WSDL Service Interface Dkument 10 und etabliert die Schnittstellen-Charakteristika eines Dienstes, hne dabei aber Festlegungen hinsichtlich der darunter liegenden Kmmunikatinstechnlgien zu treffen. Durch diese Abstraktin ist sichergestellt, dass die Integrität der Dienstbeschreibung unabhängig vn eventuellen Änderungen der Technlgieplattfrm erhalten bleibt. Die abstrakte Beschreibung besteht im Wesentlichen aus den flgenden Kmpnenten: 9 Für Beispiele hrizntaler Dienste siehe Utility Service Mdel in Kap. 4.1.1.1. 10 Das WSDL Service Interface Dkument und das weiter unten erwähnte WSDL Service Implementatin Dkument können als separate Dateien existieren der innerhalb ein und derselben Datei. Im ersteren Fall werden die abstrakten Inhalte des WSDL Service Interface Dkuments dem Implementierungsdkument üblicherweise über einen Imprt-Mechanismus zur Verfügung gestellt. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 21 vn 138
types dieses ptinale Knstrukt erlaubt es, XML-Schema-Definitinen (XSD) direkt in die WSDL-Definitin einzubetten der auf externe Schemadefinitinen (imprt) zu verweisen. message für jede Nachricht, die ein Dienst senden der empfangen sll, wird ein entsprechendes message Knstrukt definiert und mit einem eindeutigen Namen versehen. prttype dieses Knstrukt ermöglicht einen generellen Blick auf das Service Interface, indem es die Nachrichten (messages), die ein Dienst verarbeiten kann, in abstrakten Funktinsgruppen, sg. Operatins, rdnet. Jede Operatin entspricht einer spezifische Aktin, die vn dem Dienst ausgeführt werden kann, inklusive vn Eingabe- und Ausgabeparametern, die als Nachrichten repräsentiert werden, und entsprechend der Reihenflge, in der sie angegeben werden und das Message Exchange Pattern der jeweiligen Operatin definieren. Wie bereits erwähnt, verwenden die Telematik-Web-Services vrrangig das Request-Respnse MEP auch der Registrierungsdienst macht hier keine Ausnahme. PrtType Elemente sind durch eine Kmbinatin ihres lkalen Namens und des Target Namespace ihres WSDL Service Interface Dkuments eindeutig identifizierbar. Ein und dieselbe WSDL prttype Instanz kann vn einem der mehreren Web Services implementiert werden. Vn den hier vrgestellten WSDL-Artefakten ist für den Aspekt der Dienstregistrierung insbesndere das prttype Knstrukt relevant. Ob und in welchem Umfang diese Kmpnente beim Registrieren der Telematikdienste in SDS zum Einsatz kmmt, zeigen die Ausführungen in Kapitel 5.1.1.4. 4.2.2.2 Knkrete Beschreibung Dieser Teil einer Service-Definitin findet sich im sg. WSDL Service Implementatin Dkument und beschreibt die Verknüpfung der abstrakten Service-Interface-Definitin mit einer realen, implementierten Technlgie. Dieses Dkument beinhaltet flglich Details zur Nachrichtenkdierung, zu physikalischen Transprtprtkllen und Adressinfrmatinen. Die knkrete Beschreibung besteht im Wesentlichen aus den flgenden Kmpnenten: binding spezifiziert einen Satz vn Nachrichtenkdierungs- und Transprt- Prtkllen, die für die Kmmunikatin mit einem Dienst, welcher einen bestimmten prttype implementiert, verwendet werden kann; eine der in diesem Zusammenhang am häufigsten auch innerhalb der Telematik- Service-Infrastruktur eingesetzte Technlgie ist SOAP (siehe [SOAP1.1]). Binding Elemente sind durch eine Kmbinatin ihres lkalen Namens und des Target Namespace ihres WSDL Service Implementatin Dkuments eindeutig identifizierbar. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 22 vn 138
Ein und dasselbe WSDL binding kann vn einem der mehreren Web Services implementiert werden. service gruppiert ein der mehrere verwandte, benannte Service Endpints (named prts) und stellt s die knkrete Implementierung eines Web Services dar. Das service Element ist durch eine Kmbinatin seines lkalen Namens und des Target Namespace seines WSDL Service Implementatin Dkuments eindeutig identifizierbar. WSDL Dkumenttypen WSDL Service Implementatin Dkument: fbarservice.wsdl WSDL Service Interface Dkument: fbar.wsdl definitins targetnamespace=thisnamespace xmlns:tns=thisnamespace Namensraum- Definitinen definitins targetnamespace=thisnamespace xmlns:tns=thisnamespace definitins targetnamespace=thisnamespace xmlns:tns=thisnamespace Datentyp- Definitinen Nachrichtentyp- Definitinen types message name=in message name=ut imprt types imprt lcatin=fbar.wsdl message name=in message name=ut Abstraktes Set vn Operatinen prttype name=fbarprttype peratin input message=tns:in utput message=tns:ut prttype name=fbarprttype peratin input message=tns:in utput message=tns:ut binding name=fbarbinding type=tns:fbarprttype [binding infrmatin] Knkretes Set vn Frmaten und Prtkllen für fbarprttype service name=fbarservice prt name=fbarprt binding=tns:fbarbinding [endpint infrmatin] Implementierung des fbarbinding Abbildung 2: WSDL Dkumenttypen prt jedes prt Element repräsentiert die Implementierung eines bestimmten prttypes unter Verwendung der Prtklle eines namentlich referenzierten bindings. In dem Element enthalten ist die physikalische Adresse, unter der auf einen Dienst zugegriffen werden kann. Prt Elemente sind durch eine Kmbinatin ihres lkalen Namen und des Target Namespace ihres WSDL Service Implementatin Dkuments eindeutig identifizierbar. Alle Artefakte der knkreten WSDL-Beschreibung sind für den Aspekt der Dienstregistrierung grundsätzlich relevant. Ob und in welchem Umfang diese gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 23 vn 138
Kmpnenten beim Registrieren der Telematikdienste in SDS zum Einsatz kmmen, zeigen die Ausführungen in Kapitel 5.1.1.4. 4.3 UDDI-Datenmdell Die in einer UDDI-Registratur gespeicherten Infrmatinen werden durch Instanzen der flgenden fünf, in [UDDI2DS] definierten Kerndatenstrukturtypen repräsentiert: businessentity businessservice bindingtemplate tmdel publisherassertin beinhaltet ein- der beidseitig bestätigte Infrmatinen zweier Parteien über ihre geschäftlichen Beziehungen; findet innerhalb der Telematikinfrastruktur keine Verwendung und wird deshalb nicht weiter betrachtet Die Unterteilung in typisierte Datenstrukturen unterstützt einerseits das einfache und schnelle Auffinden der in einer Registratur gespeicherten Daten und erlaubt andererseits ein unmittelbares Verständnis über die Art der enthaltenen Infrmatin. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 24 vn 138
Abbildung 3: Telematik-relevante UDDI-Kerndatenstrukturen Jede der ben abgebildeten Datenstrukturen ist in mehrere Felder untergliedert, die zur Beschreibung technischer der geschäftlicher Inhalte genutzt werden. Im Flgenden werden diese Strukturen anhand ihrer XSD-Diagramme genauer dkumentiert. Die beigestellten Erläuterungen knzentrieren sich auf die wesentlichen Anfrderungen aus [gemgesarch]. Entsprechend gekennzeichnet finden sich zudem Beschreibungen weiteren Elemente und Attribute, die bei der Dienstregistrierung im Bedarfsfall zusätzlich verwendet werden können. Eine vllständige Beschreibung des UDDIv2-Datenmdells ist in [UDDI2DS] und [UDDI2XS] enthalten. 4.3.1 businessentity Eine businessentity Struktur beinhaltet grundlegende Prfilinfrmatinen zu einem Dienstbetreiber (Service Prvider). gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 25 vn 138
Bei den Dienstbetreibern der Telematik kann es sich beispielsweise um Spitzenrganisatinen der Leistungserbringer auf Bundesebene, Organe der Kstenträger der die gematik selbst handeln. Tabelle 4: XML-Schema-Diagramm der Entität uddi:businessentity Pflichtfelder (MUSS) gem. [gemgesarch]: Name uddi:businessentity @businesskey uddi:name uddi:descriptin uddi:businessservices Beschreibung Die Struktur businessentity beschreibt einen Dienstbetreiber. Sie enthält Infrmatinen über den Betreiber und alle durch ihn angebtenen Dienste. Das Attribut businesskey bezeichnet den eindeutigen Schlüssel eines Dienstbetreibers innerhalb der UDDI-Registratur. Dieser Schlüssel (UUID) wird bei der Registrierung eines Betreibers autmatisch vergeben. Der eindeutige Name einer businessentity. Das ptinale Element descriptin enthält eine textuelle Beschreibung des Dienstbetreibers. Die Struktur businessservices enthält alle durch den Betreiber angebtenen gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 26 vn 138
Fakultative Felder (KANN): Name uddi:cntacts uddi:cntact (innerhalb der uddi:cntacts Struktur) uddi:persnname (innerhalb der uddi:cntact Struktur) (Fach-) Dienste in businessservice Strukturen 11. Beschreibung Cntainer-Strukturelement, welches Kntaktinfrmatinen des Dienstbetreibers zusammenfasst. Strukturelement für weiterführende Kntaktinfrmatinen zu einem Dienstbetreiber bzw. eines Ansprechpartners innerhalb des Dienstbetreibers. Name des Ansprechpartners uddi:phne (innerhalb der uddi:cntact Struktur) uddi:email (innerhalb der uddi:cntact Struktur) uddi:address (innerhalb der uddi:cntact Struktur) Telefnnummer des Ansprechpartners email-adresse des Ansprechpartners Pstanschriftsinfrmatinen, ggfs. unter Verwendung des Pstal Address Structure tmdels 12 4.3.2 businessservice Die Struktur businessservice repräsentiert die Instanz eines Dienstes, wbei allerdings die Details, wie auf den Dienst zugegriffen werden kann, in entsprechenden bindingtemplate-strukturen 13 abgelegt sind. Jeder (Telematik-) Dienstbetreiber stellt üblicherweise ein der mehrere (Fach-) Dienste als businessservice(s) zur Verfügung stellen. 11 Siehe Kap. 4.3.2. 12 Siehe Anhang A3-3 und Kap. 5.1.1.6. 13 Siehe Kap. 4.3.3. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 27 vn 138
Tabelle 5: XML-Schema-Diagramm der Entität uddi:businessservice Pflichtfelder (MUSS) gem. [gemgesarch]: Name uddi:businessservice @servicekey @businesskey uddi:name uddi:descriptin uddi:bindingtemplates Beschreibung Das Element businessservice repräsentiert die Instanz eines angebtenen Dienstes. Das zugehörige Attribut servicekey dkumentiert die eindeutige Kennung der Serviceinstanz innerhalb vn UDDI. Dieser Schlüssel (UUID) wird bei der Registrierung des Dienstes autmatisch vergeben. Das Attribut businesskey dkumentiert die Zurdnung der Serviceinstanz zu einer Entität uddi:businessentity. Der lkale Name des Services. Das ptinale Element descriptin enthält eine textuelle Beschreibung des angebtenen Dienstes. Die Struktur bindingtemplates ist ein Cntainer, der keine, eine der mehrere Strukturen bindingtemplate 14 beinhaltet. Fakultative Felder (KANN): Name uddi:categrybag uddi:keyedreference (innerhalb der uddi:categrybag Struktur) Beschreibung Liste vn Schlüssel-Wert-Paaren, mit denen der Instanz businessservice eine Reihe vn Kategrisierungsinfrmatinen zugerdnet werden. Einzelnes Schlüssel-Wert-Paar für die Zuweisung einer spezifischen Kategrie an die Instanz businessservice 15. 14 Siehe Kap. 4.3.3. 15 Siehe Anhänge A6 und A7 swie Kap. 5.1.1.4 und 5.1.1.6. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 28 vn 138
4.3.3 bindingtemplate Die Kmmunikatinsdetails einer Dienstinstanz hierbei insbesndere der Dienstzugangspunkt (accesspint) - werden in einem entsprechenden bindingtemplate gespeichert. Das Template referenziert in der Regel ein der mehrere tmdels. Tabelle 6: XML-Schema-Diagramm der Entität uddi:bindingtemplate (etc.) Pflichtfelder (MUSS) gem. [gemgesarch]: Name uddi:bindingtemplate @bindingkey Beschreibung Das bindingtemplate enthält die technischen Infrmatinen, die zum Ansprechen eines Dienstes ntwendig sind. Das Attribut bindingkey repräsentiert die eindeutige Kennung der Serviceinstanz innerhalb der UDDI Registratur. Dieser Schlüssel (UUID) wird bei der Registrierung des Dienstes autmatisch vergeben. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 29 vn 138
@servicekey Das Attribut servicekey dkumentiert die Zurdnung der Serviceinstanz zu einer Entität uddi:businessservice. uddi:descriptin Das Element descriptin ist ptinal und enthält wenn vrhanden eine Beschreibung des bindingtemplates. uddi:accesspint bzw. uddi:hstingredirectr uddi:tmdellinstancedetails uddi:tmdelinstanceinf @tmdelkey Fakultative Felder (KANN): Name uddi:descriptin (innerhalb einer uddi:tmdelinstanceinf Struktur) uddi:instancedetails (innerhalb einer uddi:tmdelinstanceinf Struktur) uddi:instanceparms (innerhalb einer uddi:instancedetails Struktur) Die Datenstruktur bindingtemplate enthält nrmalerweise ein Element accesspint, in dem die URL gespeichert ist, über die der Dienst angesprchen werden kann. Ist kein Element accesspint vrhanden, s muss zwingend ein Element hstingredirectr existieren, welches auf ein anderes bindingtemplate (mit entsprechenden accesspint-infrmatinen) verweist. Diese einfache Cntainerstruktur beinhaltet eine der mehrere Strukturen tmdelinstanceinf (s. u.), die zusammengenmmen einen technischen Fingerabdruck 16 darstellen. Die Struktur tmdelinstanceinf repräsentiert die spezifischen Details der Instanz bindingtemplate bezgen auf ein tmdel, indem es besagtes tmdel über dessen tmdelkey (s. u.) referenziert. Über das Attribut tmdelkey wird das tmdel 17 referenziert. Beschreibung In diesem Element wird die Rlle dkumentiert, welche die besagte tmdel-referenz in der Gesamtbeschreibung des Dienstes spielt. Diese Struktur beinhaltet dienstinstanzspezifische Infrmatinen entweder zum besseren Verständnis der Implementierungsdetails des referenzierten tmdels der zur Angabe weiterer Parameter. Dieses Element wird je nach Bedarf für die Angabe vn Kategrisierungsparametern genutzt. 4.3.4 tmdel Innerhalb des UDDI-Datenmdells stellt die tmdel-struktur ein auf Abstraktin basierendes Referenzsystem dar. Mit dieser Struktur lassen sich quasi beliebige Bezüge definieren allerdings haben sich zwei Knventinen für die Benutzung vn tmdels herausgebildet: Repräsentatin bzw. Referenzierung einer technischen Spezifikatin, um s die Kmpatibilität zu dieser Spezifikatin zum Ausdruck zu bringen mögliche Spezifikatinen können sein: Netzwerkprtklle, Frmate und Regeln für den strukturierten Datenaustausch, etc. Referenz eines abstrakten Namensraums, über den rganisatrische Identitäten der verschiedene Kategrisierungen (Taxnmien) möglich werden 16 Ein technischer Fingerabdruck ist ein Satz vn Referenzen auf spezifische und identifizierbare technische Spezifikatinen. Durch Referenzierung dieser Spezifikatinen wird Kmpatibilität zu eben diesen zum Ausdruck gebracht. 17 Siehe Kap. 4.3.4. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 30 vn 138