Einführung der Gesundheitskarte. Lokalisierungsdienst Stufe 2. Version: Stand:
|
|
- Kora Fleischer
- vor 8 Jahren
- Abrufe
Transkript
1 Einführung der Gesundheitskarte Spezifikatin Infrastrukturkmpnenten: Versin: Stand: Status: freigegeben gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 1 vn 138
2 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 ). 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 ( ): Einführung der Gesundheitskarte Spezifikatin Infrastrukturkmpnenten:, Versin Dkumenthistrie Versin Stand Kapitel Grund der Änderung, Hinweise Bearbeitung Rudimentäre Knzeptstruktur gematik, AG Verfeinerung Dkumentenstruktur, Spez. UDDIund Telematik-Datenstrukturen Grundlagen-Infs und Anhänge zu kannischen tmdels hinzugefügt, Einführungskapitel ergänzt Datenmdellabbildungen, Grundlagen, phys. Design, Datenmapping , 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
3 Versin Stand Kapitel Grund der Änderung, Hinweise Bearbeitung , 2, 3, 4, 5, 6, A2 Registraturbeispiel WSDL-UDDI Mapping Registratur-Methdik, UDDI APIs, Lkalisierungsstrategie Zusammenfassung, Einleitung, UDDI APIs, Publisher Accunts, Lkalisierungsstrategie, Prduktauswahlkriterien, Glssar , C1, C3 Physische Architektur, (Frntend, Middle und Backend Tier), Healthchecking und Skalierung, Annahmen, Architekturentscheidungen , 5, C3, UDDI Server Tplgie, Skalierung, Architekturentscheidungen Middle Tier Netzwerk Design ergänzt, Prduktauswahlkriterien ergänzt Kmmentare der gematik-internen QS eingearbeitet gematik, AG8 gematik, AG8 gematik, AG8 gematik, AG8 gematik, AG freigegeben zur Vrkmmentierung gematik Freigegeben gematik Alle Anpassungen auf Basis [gemgesarch] v0.3.0; neues Kap (Deregistrierung); Behandlung vn Indirect Bindings verdeutlicht; Stilistische Überarbeitung gematik, AG Freigegeben gematik gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 3 vn 138
4 Inhaltsverzeichnis Dkumentinfrmatinen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Gliederung des Dkuments Zielgruppe Geltungsbereich Arbeitsgrundlagen Bezugspunkte Rahmenbedingungen Abgrenzung des Dkuments Verwendung vn Schlüsselwrten Anfrderungen Funktinale Anfrderungen Nicht-funktinale Anfrderungen Dienstüberblick Grundlagen Terminlgie Einrdnung des UDDI Registraturdienstes Message Exchange Patterns Datenbasis Datenbjekte der Telematik WSDL-Definitinen Abstrakte Beschreibung Knkrete Beschreibung UDDI-Datenmdell businessentity businessservice bindingtemplate tmdel UDDI-Benutzerschnittstellen Publishing API Authentisierung...32 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 4 vn 138
5 Autrisierung API Referenz Inquiry API API Referenz Steuerung des Suchverhaltens API-Rückmeldungen Psitive Rückmeldungen Fehlerrückmeldungen UDDI Tplgie Operatr Nde Operatr Clud Replikatin UDDI-Sicherheit Knzeptinelle Umsetzung Sftware-technische Architektur Registrierung vn Diensten Allgemeine Anfrderungen und Ziele Zu unterstützende Publishing API Funktinen Authentisierung und Autrisierung auf Nachrichtenebene Registratur-Methdik Werkzeuggestützte Registratur Exemplarische Registratur vn UDDI Entitäten Deregistrierung vn Diensten Allgemeine Anfrderungen und Ziele Zu unterstützende Publishing API Funktinen Authentisierung und Autrisierung auf Nachrichtenebene Deregistratur-Methdik Werkzeuggestützte Deregistrierung Lkalisierung vn Diensten Allgemeine Anfrderungen und Ziele Zu unterstützende Inquiry API Funktinen Lkalisierungsstrategie Use Case: Registry Cache Priming Use Case: Registry Cache Refresh Laufzeitumgebung des Registraturdienstes Persistenzschicht des Registraturdienstes Physische Architektur Verschlüsselung und Authentisierung auf Verbindungsebene Tier Design SDS Frntend Tier SDS Middle Tier SDS Backend Tier Fazit Vertikale Telematik Administratin Tier Sicherheitsznen Betriebliche Aspekte Mnitring und Healthchecking...99 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 5 vn 138
6 5.3.2 Ausfallszenarien und Systemverfügbarkeit Skalierung und Mengengerüste Datensicherung und -wiederherstellung Kriterien für die Prduktauswahl Anhang A A1 Abkürzungen und Akrnyme A2 Glssar A3 Abbildungsverzeichnis A4 Tabellenverzeichnis A5 Referenzierte Dkumente A6 Kannische UDDIv2 tmdels A6-1 UDDI v2 Types Categry System tmdel A6-2 UDDI General v2 Keywrds Categry System tmdel A6-3 UDDI Business Registry Pstal Address Structure tmdel (ptinal) A7 Kannische SDS tmdels A7-1 Telematik ServiceType tmdel A7-2 WSDL Entity Type tmdel A7-3 XML Namespace tmdel A7-4 XML Lcal Name tmdel A7-5 WSDL prttype Reference tmdel A7-6 Prtcl Categrizatin tmdel A7-7 Transprt Categrizatin tmdel A7-8 SOAP Prtcl tmdel A7-9 HTTP Prtcl tmdel A7-10 WSDL Address tmdel A7-11 WS-I Cnfrmance Claim tmdel (ptinal) A8 Hinweise zur Lesbarkeit der XML Schema Diagramme Anhang B B1 Annahmen B2 Klärungsbedarf B3 Architekturentscheidungen Kapitel gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 6 vn 138
7 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 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
8 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
9 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 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
10 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 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
11 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 Insbesndere [gemspecttd]. gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 11 vn 138
12 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
13 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
14 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
15 4 Dienstüberblick 4.1 Grundlagen 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 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 15 vn 138
16 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
17 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 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
18 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 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
19 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 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
20 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 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 weitere Details auch in Kap gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 20 vn 138
21 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 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 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 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 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 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
22 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 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
23 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
24 Kmpnenten beim Registrieren der Telematikdienste in SDS zum Einsatz kmmen, zeigen die Ausführungen in Kapitel 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
25 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 businessentity Eine businessentity Struktur beinhaltet grundlegende Prfilinfrmatinen zu einem Dienstbetreiber (Service Prvider). gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 25 vn 138
26 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: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
27 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: (innerhalb der uddi:cntact Struktur) uddi:address (innerhalb der uddi:cntact Struktur) Telefnnummer des Ansprechpartners -adresse des Ansprechpartners Pstanschriftsinfrmatinen, ggfs. unter Verwendung des Pstal Address Structure tmdels 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 Siehe Anhang A3-3 und Kap Siehe Kap gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 27 vn 138
28 Tabelle 5: XML-Schema-Diagramm der Entität uddi:businessservice Pflichtfelder (MUSS) gem. [gemgesarch]: 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 Siehe Kap Siehe Anhänge A6 und A7 swie Kap und gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 28 vn 138
29 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 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
30 @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 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 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 gematik_inf_spezifikatin_registrierungsdienst_v1_1_0.dc Seite 30 vn 138
The Cable Guy: Dynamische DNS-Aktualisierung in Windows 2000
The Cable Guy: Dynamische DNS-Aktualisierung in Windws 2000 (Engl. Originaltitel: The Cable Guy: DNS Dynamic Update in Windws 2000) DNS (Dmain Name System) unterstützt einen Mechanismus zum Auflösen vn
MehrAbgestimmte Kennwortrichtlinien
Abgestimmte Kennwrtrichtlinien Maik Görlich In Active Directry Dmänen unter Windws 2000 Server und Windws Server 2003 knnte jeweils nur eine einheitliche Kennwrtrichtlinie und eine Kntsperrungsrichtlinie
MehrNewsletter e-rechnung an die öffentliche Verwaltung
Vn: E-Rechnung an den Bund Gesendet: Miwch, 05. Nvember 201414:43 Betreff: ERB-Newsleer: Deutsch Newsletter e-rechnung an die öffentliche Verwaltung Sehr geehrte Abnnentin, sehr geehrter
MehrNewsletter e-rechnung an die öffentliche Verwaltung
Vn: E-Rechnung an den Bund Gesendet: Dnnerstag, 16. Oktber 201413:16 Betreff: ERB-Newsle)er: Deutsch Newsletter e-rechnung an die öffentliche Verwaltung Sehr geehrte Abnnentin, sehr
MehrImplementierung von Manufacturing Execution Systemen (MES) Zusammenfassung
Implementierung vn Manufacturing Executin Systemen (MES) Zusammenfassung Das Management der Fertigungs- und Mntageprzesse mit allen unmittelbar prduktinsbeeinflussenden Przessen wird zunehmend zu einer
MehrKurzbeschreibung. Unterstützte Beschaffungsarten. Highlights. Abgrenzung zu anderen Lösungen
Kurzbeschreibung WECO E-Prcure ermöglicht es, direkt aus Lieferantenkatalgen im Internet der aus firmeneigenen Katalgen Beschaffungsvrgänge im SAP ERP-System zu generieren. Die Datenübername erflgt über
Mehretutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche
etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:
MehrJava und XML 2. Java und XML
Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003
Mehr1. Handbuch Systemübersicht
Infrmatinssystem für Öffentliche Verträge www.bandi-altadige.it Sistema infrmativ cntratti pubblici 1. Handbuch Systemübersicht Vers. 2013-08 DE AUTONOME PROVINZ BOZEN - SÜDTIROL PROVINCIA AUTONOMA DI
Mehr1 Allgemeines. 2 Vergabeportal Vergabemarktplatz Rheinland
Infrmatinen zur Angebtsabgabe beim Erftverband Infrmatinen zur Angebtsabgabe beim Erftverband 1 Allgemeines Der Erftverband ist als Körperschaft des öffentlichen Rechts im Zuge vn Beschaffungen vn Liefer-
MehrService Level Agreement (SLA) für OS4X Suite der c-works GmbH
Seite 1 vn 6 Service Level Agreement (SLA) für OS4X Suite der Datum des Inkrafttretens: 19-10-2011 Dkument-Eigentümer: Versin Versin Datum Beschreibung Autr 1.0 10.10.2011 Service Level Agreement H. Latzk
MehrWiederholung: Beginn
B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben
MehrHilfedatei der Oden$-Börse Stand Juni 2014
Hilfedatei der Oden$-Börse Stand Juni 2014 Inhalt 1. Einleitung... 2 2. Die Anmeldung... 2 2.1 Die Erstregistrierung... 3 2.2 Die Mitgliedsnummer anfordern... 4 3. Die Funktionen für Nutzer... 5 3.1 Arbeiten
MehrOrientierungshilfen für SAP PI (Visualisierungen)
EINSATZFELDER FÜR DIE KONFIGURATIONS-SZENARIEN INTERNE KOMMUNIKATION UND PARTNER-KOMMUNIKATION UND DIE SERVICE-TYPEN BUSINESS-SYSTEM, BUSINESS-SERVICE UND INTEGRATIONSPROZESS Betriebswirtschaftliche Anwendungen
MehrCATIA Richtlinien. Es wird zuerst ein quadratischer Tank (geschlossene Form) konstruiert, dieser wird zu:
CATIA Richtlinien Inhalt: 1. Benennung vn Bauteile 2. Benennung vn Baugruppen 3. Strukturierung vn CATIA-Dateien 4. Uplad auf Agra Um die Benennung und die Struktur in CATIA zu vereinheitlichen bitten
MehrInstallationsanleitung. zum Anschluss an Telefonanlagen (Mehrplatzversion)
zum Anschluss an Telefnanlagen () CPTel () besteht aus zwei unterschiedlichen Prgrammen: CPTel Server und CPTel Client. Installatinsvarianten: eigenständiger CPTel-Server CPTel-Server und CPTel-Client
MehrA585 Mailserver. IKT-Standard. Ausgabedatum: 2015-02-04. Version: 2.03. Ersetzt: 2.02. Genehmigt durch: Informatiksteuerungsorgan Bund, am 2005-12-05
Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB A585 Mailserver Klassifizierung: Typ: Nicht klassifiziert IKT-Standard Ausgabedatum: 2015-02-04 Version: 2.03 Status: Genehmigt
MehrWorkflow, Business Process Management, 4.Teil
Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung
Mehrrmdata GeoProject Release Notes Version 2.4 Organisation und Verwaltung von rmdata Projekten Copyright rmdata GmbH, 2015 Alle Rechte vorbehalten
Release Ntes rmdata GePrject Versin 2.4 Organisatin und Verwaltung vn rmdata Prjekten Cpyright rmdata GmbH, 2015 Alle Rechte vrbehalten rmdata Vermessung Österreich rmdata Vermessung Deutschland Industriestraße
MehrVorbereitung der Abiturzeugnisse mit CUBE-SVS
Vrbereitung der Abiturzeugnisse mit CUBE-SVS Zur Schreibweise: Menüpunkt im Hauptmenü (waagerecht) Menüpunkt im Untermenü (klappt senkrecht herunter) Bearbeitungsvrgang / ntwendige Einstellungen Die ntwendigen
MehrEin weiteres an gleicher Stelle auffindbares Formular in Open Office Vorlage deckt den gesamten Bereich der Rechtshilfe ab.
BUNDESMINISTERIUM FÜR JUSTIZ Erlass vm 28. Nvember 2011 über die Einführung eines elektrnischen Wrkflws betreffend Berichte der Staatsanwaltschaften/Oberstaatsanwaltschaften und Einzelerlässe der Oberstaatsanwaltschaften/des
MehrGEZIELT MEHR SICHERHEIT MIT 4I ACCESS SERVER & 4I CONNECT CLIENT
Seite 1/7 GEZIELT MEHR SICHERHEIT MIT 4I ACCESS SERVER & 4I CONNECT CLIENT ZENTRAL LOKALE MANAGEMENT-PLATTFORM FÜR EINE W ELTWEIT SICHERE INDUSTRIELLE KOMMUNIKATION. Seite 2/7 Auf den folgenden Seiten
MehrEine Information des Ingenieurbüro Körner zur Baustellenverordnung
Eine Infrmatin des Ingenieurbür Körner zur Baustellenverrdnung Ihr Ansprechpartner: Dipl.-Ing. Frank Körner Wasserbank 6 58456 Witten Ruf- Nr. (02302) 42 98 235 Fax- Nr. (02302) 42 98 24 e-mail: kerner@ibkerner.de
MehrKurzübersicht. Grundeinstellungen. 1) Im Rakuten Shop
Kurzübersicht Die Anbindung an Rakuten ermöglicht es Ihnen Bestellungen aus Ihrem Rakuten Shp zu imprtieren und hieraus Lieferscheine und Rechnungen zu erstellen. Prdukte lassen sich aus dem Rakuten Shp
MehrWDB Brandenburg: Online-Erfassung und -Pflege Schritt für Schritt
Für die Nutzung der Online-Erfassung und Pflege benötigen Sie Ihre Institutinsnummer und ein Passwrt. Sie sind nch nicht als Nutzer für die Online-Erfassung registriert? Betätigen Sie den Buttn Neu registrieren.
MehrTactonWorks EPDM Integration. Lino EPDM pro. Whitepaper. unter Nutzung des TactonWorks Add-in EPDM von Tacton Systems AB
Lin EPDM pr Whitepaper unter Nutzung des TactnWrks Add-in EPDM vn Tactn Systems AB Ausgabedatum: 04.09.2013 - Dkumentversin: 1.1 Autr: Clemens Ambrsius / Rüdiger Dehn Cpyright Lin GmbH 2013 Alle Rechte
MehrVorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz
Anwendungshandbuch Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz Version: 1.0 Herausgabedatum: 31.07.2015 Ausgabedatum: 01.11.2015 Autor: DB Energie http://www.dbenergie.de Seite: 1 1.
MehrUMSETZUNGSHILFE Exta Einladung zur Durchführung eines betrieblichen Eingliederungsmanagement nach 84 Abs. 2 SGB IX
UMSETZUNGSHILFE Exta Einladung zur Durchführung eines betrieblichen Eingliederungsmanagement nach 84 Abs. 2 SGB IX Mai 2015 & Thmas Hchgeschurtz 1. Anschreiben an Mitarbeiter zur Verfahrenseinleitung Einladung
MehrVerteilte Systeme: Übung 4
Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist
MehrWhite Paper. Fabasoft Folio Zugriffsdefinitionen. 2013 Winter Release
White Paper Fabasoft Folio Zugriffsdefinitionen 2013 Winter Release Copyright Fabasoft R&D GmbH, A-4020 Linz, 2012. Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder
MehrThemen. Web Services und SOA. Stefan Szalowski Daten- und Online-Kommunikation Web Services
Themen Web Services und SOA Wer kennt den Begriff Web Services? Was verstehen Sie unter Web Services? Die Idee von Web Services Ausgangspunkt ist eine (evtl. schon bestehende) Software Anwendung oder Anwendungskomponente
MehrIPM- Prozessmanagement. Manuelle Anträge
Manuelle Anträge Allgemeines In jedem der nachflgend dargestellten Przesse, in denen manuelle Aktinen enthalten sind (z.b. Genehmigung des Leiters zu einem Rllen-Antrag), können zu diesen Aktinen über
MehrContainerformat Spezifikation
Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...
MehrKOMPETENZTRAINING 2016/17
Kursnummer: 2016KA010 Titel der Veranstaltung: KOMPETENZTRAINING 2016/17 Sprachbildung Frühe Sprachförderung Kmpetenztraining Sensibilisierung für Mehrsprachigkeit und interkulturelle Situatinen als Grundlage
MehrLabel-Guide Stand: 10 2014
Label-Guide Stand: 10 2014 Der ClimatePartner Label-Guide 2 Über ClimatePartner ClimatePartner ist ein führender Business Slutin Prvider für Klimaschutz und unterstützt Unternehmen aller Branchen dabei,
MehrMigration von statischen HTML Seiten
Migration von statischen HTML Seiten Was ist Typo3 Typo3 ist ein Content Mangement System zur Generierung von Internetauftritten. Dieses System trennt Inhalt, Struktur und Layout von Dokumenten und stellt
MehrSo greifen Sie über WebDAV auf Dateien auf dem Extranet der Pfimi Kirche Waldau zu
S greifen Sie über WebDAV auf Dateien auf dem Extranet der Pfimi Kirche Waldau zu Überblick WebDAV ist eine Erweiterung vn HTTP, mit der Benutzer auf Remte-Servern gespeicherte Dateien bearbeiten und verwalten
MehrHilfe Bearbeitung von Rahmenleistungsverzeichnissen
Hilfe Bearbeitung von Rahmenleistungsverzeichnissen Allgemeine Hinweise Inhaltsverzeichnis 1 Allgemeine Hinweise... 3 1.1 Grundlagen...3 1.2 Erstellen und Bearbeiten eines Rahmen-Leistungsverzeichnisses...
MehrDas Handbuch zu Simond. Peter H. Grasch
Peter H. Grasch 2 Inhaltsverzeichnis 1 Einführung 6 2 Simond verwenden 7 2.1 Benutzereinrichtung.................................... 7 2.2 Netzwerkeinrichtung.................................... 9 2.3
MehrWebalizer HOWTO. Stand: 18.06.2012
Webalizer HOWTO Stand: 18.06.2012 Copyright 2003 by manitu. Alle Rechte vorbehalten. Alle verwendeten Bezeichnungen dienen lediglich der Kennzeichnung und können z.t. eingetragene Warenzeichen sein, ohne
MehrZustandsgebundene Webservices
Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite
MehrHandbuch für Gründer. Daniela Richter, Marco Habschick. Stand: 21.02.2013. Verbundpartner:
Daniela Richter, Marco Habschick Stand: 21.02.2013 Verbundpartner: Inhaltsverzeichnis 1. Allgemeines...3 2. Zugang zur Gründungswerkstatt...4 3. Login...5 4. Meine Werkstatt...6 5. Businessplan...7 5.1.
MehrÜbersicht Die Übersicht zeigt die Zusammenfassung der wichtigsten Daten.
Webalizer Statistik Bedeutung der Begriffe Übersicht Die Übersicht zeigt die Zusammenfassung der wichtigsten Daten. Anfragen Gesamtheit aller Anfragen an Ihren Account. Jede Anfrage auf eine Grafik, eine
MehrFlashfragen in ILIAS Test & Assessment. Helmut Schottmüller
Flashfragen in ILIAS Test & Assessment Helmut Schottmüller Flashfragen in ILIAS Test & Assessment Helmut Schottmüller Veröffentlicht Januar 2009 Copyright 2009 Helmut Schottmüller Inhaltsverzeichnis 1.
MehrWeb Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen
9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.
MehrWhitepaper. Produkt: combit Relationship Manager 7. combit Relationship Manager email-rückläufer Script. combit GmbH Untere Laube 30 78462 Konstanz
combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager 7 combit Relationship Manager email-rückläufer Script Inhalt Einleitung 3 Notwendige Anpassungen 3 crm Solution
MehrAGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b
AGROPLUS Buchhaltung Daten-Server und Sicherheitskopie Version vom 21.10.2013b 3a) Der Daten-Server Modus und der Tresor Der Daten-Server ist eine Betriebsart welche dem Nutzer eine grosse Flexibilität
MehrInformationen zu den regionalen Startseiten
Informationen zu den regionalen Startseiten Inhaltsverzeichnis Informationen zu den regionalen Startseiten 1 1. Grundlegende Regeln 2 1.1. Was wird angezeigt? 2 1.2. Generelle Anzeigeregeln 2 2. Anpassbare
MehrDaniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers
Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des
MehrFunktionsübersicht. Modul: redcms_keycontract
Funktionsübersicht Modul: redcms_keycontract 10. Mai 2006 redcms KeyContract (für Intranet und Internet) - Features! Strukturierte Ablage von Dateien: Anlegen beliebig vieler Rubriken und Unterrubriken
MehrImplementierung von Web Services: Teil I: Einleitung / SOAP
Implementierung von Web Services: Teil I: Einleitung / SOAP Prof. Dr. Kanne - FSS 2007 Carl-Christian Kanne, February 25, 2007 Web Services - p. 1/12 Web Services: Allgemein XML Datenaustauschformat plattformunabhängig
MehrNorm 225 Service Definition mit WSDL
1 Norm 225 Service Definition mit WSDL 2 3 Release und Version Release 1, Version 2.0, vom 19. Juni 2007 4 5 Status Offizielle Norm 6 7 Editor Dr. Torsten Schmale, inubit AG 8 9 10 11 12 13 14 15 16 17
Mehr1 Einleitung. 1.1 Motivation und Zielsetzung der Untersuchung
1 Einleitung 1.1 Motivation und Zielsetzung der Untersuchung Obgleich Tourenplanungsprobleme zu den am häufigsten untersuchten Problemstellungen des Operations Research zählen, konzentriert sich der Großteil
MehrNutzung dieser Internetseite
Nutzung dieser Internetseite Wenn Sie unseren Internetauftritt besuchen, dann erheben wir nur statistische Daten über unsere Besucher. In einer statistischen Zusammenfassung erfahren wir lediglich, welcher
MehrDefacto brauchen alle Handels- u. Gewerbebetriebe ab 1.1.2016 eine Registrierkassemit bestimmten technischen Voraussetzungen!
Defact brauchen alle Handels- u. Gewerbebetriebe ab 1.1.2016 eine Registrierkassemit bestimmten technischen Vraussetzungen! Seit 1.1.2013 gilt bereits uneingeschränkt die Kassenrichtlinie KRL2012 des österreichischen
MehrKESB-Kennzahlen Kanton Zürich. Bericht 2015. Verabschiedet am 21. April 2016
KPV KESB-Präsidienvereinigung Kantn Zürich c/ KESB Bezirk Pfäffikn ZH Schmittestrasse 10 Pstfach 68 8308 Illnau Tel 052 355 27 77 Fax 052 355 27 89 Web: www.kesb-zh.ch KESB-Kennzahlen Kantn Zürich Bericht
MehrSoftwareentwicklungspraktikum Sommersemester 2007. Grobentwurf
Softwareentwicklungspraktikum Sommersemester 2007 Grobentwurf Auftraggeber Technische Universität Braunschweig
MehrAllgemeines zu Datenbanken
Allgemeines zu Datenbanken Was ist eine Datenbank? Datensatz Zusammenfassung von Datenelementen mit fester Struktur Z.B.: Kunde Alois Müller, Hegenheimerstr. 28, Basel Datenbank Sammlung von strukturierten,
MehrErlä uterungen zu Meldungen IP Losses Art. 101 CRR
Erlä uterungen zu Meldungen IP Lsses Art. 101 CRR Rechtlicher Hintergrund Die Verlustdaten, welche in Art. 101 CRR gemeldet werden, werden vn der FMA herangezgen, um zu beurteilen, b die (begünstigten)
MehrVVA Webservice Online Lieferbarkeits-Abfrage
Version 1.0 Dateiname VVA_OLA_Schnittstellenbeschreibung_2012.docx Erstellt am 30.05.2010 Seitenanzahl 5 arvato media GmbH Historie der Dokumentversionen Version Datum Autor Änderungsgrund / Bemerkungen
MehrFact Sheet 2 Personalkosten
Fact Sheet 2 Persnalksten V e G ü2 7 G ü Zusammenfassung: Für den Anspruch auf Erstattung vn Persnalksten, das Erstattungsantragsverfahren swie für die zur Erstattung vrzulegenden Nachweise gelten ausführliche
MehrContainerformat Spezifikation
Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...
Mehrhttp://train-the-trainer.fh-joanneum.at IINFO Storyboard
IINFO Storyboard Allgemeine Bemerkungen und Richtlinien zur Handhabung. Das Storyboard besteht aus einem Web, d.h. einer vernetzten Struktur von HTML-Seiten welche später von den Programmieren direkt als
Mehr2.5.2 Primärschlüssel
Relationale Datenbanken 0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110
MehrWSDL. Web Services Description Language. André Vorbach. André Vorbach
André Vorbach WSDL Web Services Description Language André Vorbach Übersicht Was ist WSDL? Dokumentenstruktur Elemente Definitions Types Messages porttype Binding Service SOAP-Bindings Beispiel Was ist
MehrWEBSEITEN ENTWICKELN MIT ASP.NET
jamal BAYDAOUI WEBSEITEN ENTWICKELN MIT ASP.NET EINE EINFÜHRUNG MIT UMFANGREICHEM BEISPIELPROJEKT ALLE CODES IN VISUAL BASIC UND C# 3.2 Installation 11 Bild 3.2 Der Webplattform-Installer Bild 3.3 IDE-Startbildschirm
MehrWindows 7 / Vista startet nicht nach Installation von Windows XP
Windws 7 / Vista startet nicht nach Installatin vn Windws XP - Um weiterhin Sicherheitsupdates fur Windws zu erhalten, mussen Sie Windws Vista mit Service Pack 2 (SP2) ausfuhren. Weitere Infrmatinen finden
MehrAufgabenheft. Fakultät für Wirtschaftswissenschaft. Modul 32701 - Business/IT-Alignment. 26.09.2014, 09:00 11:00 Uhr. Univ.-Prof. Dr. U.
Fakultät für Wirtschaftswissenschaft Aufgabenheft : Termin: Prüfer: Modul 32701 - Business/IT-Alignment 26.09.2014, 09:00 11:00 Uhr Univ.-Prof. Dr. U. Baumöl Aufbau und Bewertung der Aufgabe 1 2 3 4 Summe
MehrSelbstbewertungsbogen
Selbstbewertungsbgen für Krankenpflegedienste in der ambulanten Versrgung schwerkranker Kinder und Jugendlicher Vrliegender Bgen dient der Selbsteinschätzung der Spezialisierung und Erfahrung in der Versrgung
Mehr10.3.1.8 Übung - Konfigurieren einer Windows 7-Firewall
5.0 10.3.1.8 Übung - Konfigurieren einer Windows 7-Firewall Drucken Sie diese Übung aus und führen Sie sie durch. In dieser Übung werden Sie erfahren, wie man die Windows 7-Firewall konfiguriert und einige
MehrFuxMedia Programm im Netzwerk einrichten am Beispiel von Windows 7
FuxMedia Programm im Netzwerk einrichten am Beispiel von Windows 7 Die Installation der FuxMedia Software erfolgt erst NACH Einrichtung des Netzlaufwerks! Menüleiste einblenden, falls nicht vorhanden Die
MehrStadt Rödental. Paralleles Markterkundungsverfahren und Auswahlverfahren nach Nr. 6.4.1 der bayerischen Breitbandrichtlinie
Stadt Rödental Paralleles Markterkundungsverfahren und Auswahlverfahren nach Nr. 6.4.1 der bayerischen Breitbandrichtlinie 1. Zieldefinitin a) Die Stadt Rödental führt ein Markterkundungsverfahren nach
MehrBewerbung für die Auszeichnung RheumaPreis Fragebogen. Bitte füllen Sie diesen Fragebogen aus und senden Sie ihn an die folgende Adresse:
Bewerbung für die Auszeichnung RheumaPreis Fragebgen Bitte füllen Sie diesen Fragebgen aus und senden Sie ihn an die flgende Adresse: Organisatinsbür RheumaPreis Pstfach 17 03 61 60077 Frankfurt/Main Angaben
MehrCC Modul Leadpark. 1. Setup 1.1 Providerdaten 1.2 Einstellungen 1.3 Qualifizierungsstati 1.4 Reklamationsstati 1.5 Design 1.
CC Modul Leadpark 1. Setup 1.1 Providerdaten 1.2 Einstellungen 1.3 Qualifizierungsstati 1.4 Reklamationsstati 1.5 Design 1.6 Dateien 2. Mein Account 2.1 Shortcutmenü 2.2 Passwort 2.3 E-Mail 2.4 Daten 3.
MehrÜbungen zu Softwaretechnik
Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 11 Dr. H. Ehler, S. Wagner 23. Januar 2004 Übungen zu Softwaretechnik Aufgabe 16 Qualitätseigenschaften Broker-Pattern Beurteilen Sie das in Aufgabe 15 benutzte
MehrDigital Director Kompatibiltätsliste für Kameras
Digital Directr Kmpatibiltätsliste für Kameras (eine Dwnlad-Versin steht zur Verfügung unter www.manfrtt.cm) Kapitel.1 Liste der kmpatiblen Kameras Kapitel.2 Besnderheiten für jedes Mdell Kapitel.1 Liste
MehrDrucken aus der Anwendung
Drucken aus der Anwendung Drucken aus der Anwendung Nicht jeder Großformatdruck benötigt die volle Funktionsvielfalt von PosterJet - häufig sind es Standarddrucke wie Flussdiagramme und Organigramme die
MehrProjektmanagement in der Spieleentwicklung
Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren
MehrHinweis 1629598 - SAP-Kernel 720 ersetzt ältere Kernel-Versionen
Kernel-Versinen Hinweissprache: Deutsch Versin: 8 Gültigkeit: gültig seit 16.03.2012 Zusammenfassung Symptm Das Wartungsende der SAP-Kernel-Versinen 700, 701, 710 und 711 ist der 31. August 2012. Diese
MehrWie Sie mit Mastern arbeiten
Wie Sie mit Mastern arbeiten Was ist ein Master? Einer der großen Vorteile von EDV besteht darin, dass Ihnen der Rechner Arbeit abnimmt. Diesen Vorteil sollten sie nutzen, wo immer es geht. In PowerPoint
MehrUse Cases. Use Cases
Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben
MehrDokumentenverwaltung im Internet
Dokumentenverwaltung im Internet WS 09/10 mit: Thema: Workflow und Rollenverteilung im Backend Gruppe: DVI 10 Patrick Plaum und Kay Hofmann Inhalt 1. Benutzer und Benutzergruppen erstellen...2 1.1. Benutzergruppen...2
MehrAnleitung zu htp Mail Business htp WebMail Teamfunktionen
Sehr geehrter Kunde, sehr geehrte Kundin, mit dem E-Mail Produkt htp Mail Business stehen Ihnen eine Vielzahl von Funktionen für eine professionelle Kommunikation innerhalb und außerhalb Ihres Unternehmens
MehrIII.2.3) Technische und berufliche Leistungsfähigkeit
1. Anfrderungen an das Unternehmen 1.1 Sicherheitsanfrderungen Gegenstand des vrliegenden Auftrags sind Lieferungen und Leistungen, die entweder ganz der teilweise der Geheimhaltung nach dem Sicherheitsüberprüfungsgesetz
MehrDie Installation eines MS SQL Server 2000 mit SP3a wird in diesem Artikel nicht beschrieben und vorausgesetzt.
Seite 1 von 5 ISA Server 2004 Microsoft SQL Server Veröffentlichung - Von Marc Grote -------------------------------------------------------------------------------- Die Informationen in diesem Artikel
MehrKlausur Advanced Programming Techniques
Advanced Prgramming Techniques Autr: Prf. Dr. Bernhard Humm, FB Infrmatik, Hchschule Darmstadt Datum: 8. Juli 2008 Klausur Advanced Prgramming Techniques 1 Spielregeln zur Klausur Allgemeines Die Bearbeitungszeit
MehrBenutzerhandbuch für die Verwendung des viavac HL7 Forcast Webservices (VAC-CDSS)
Benutzerhandbuch für die Verwendung des viavac HL7 Forcast Webservices (VAC-CDSS) Inhaltsverzeichnis Zweck des Dokuments... 2 Verwendung des Dokuments... 2 Referenzierte Dokumente... 2 Übersicht...3 Allgemeine
MehrI n f o r m a t i o n s s i c h e r h e i t i n G e m e i n d e n B e v ö l k e r u n g s z a h l < 6 000
Leitfaden I n f o r m a t i o n s s i c h e r h e i t i n G e m e i n d e n B e v ö l k e r u n g s z a h l < 6 000 Inhalt 1 Einleitung... 2 2 Übersicht Dokumente... 2 3 Umsetzung der Anforderungen an
MehrWindows. Workshop Internet-Explorer: Arbeiten mit Favoriten, Teil 1
Workshop Internet-Explorer: Arbeiten mit Favoriten, Teil 1 Wenn der Name nicht gerade www.buch.de oder www.bmw.de heißt, sind Internetadressen oft schwer zu merken Deshalb ist es sinnvoll, die Adressen
Mehrinviu routes Installation und Erstellung einer ENAiKOON id
inviu routes Installation und Erstellung einer ENAiKOON id Inhaltsverzeichnis inviu routes... 1 Installation und Erstellung einer ENAiKOON id... 1 1 Installation... 1 2 Start der App... 1 3 inviu routes
MehrDer Kundenmanager. Der Kundenmanager der Firma AED-SICAD ist ein Bestandteil des Web Order System (WOS) und unterscheidet zwischen folgenden Kunden:
Der Kundenmanager Der Kundenmanager der Firma AED-SICAD ist ein Bestandteil des Web Order System (WOS) und unterscheidet zwischen folgenden Kunden: Geschäftskunden Bei Geschäftskunden handelt es sich um
MehrMassenversand Dorfstrasse 143 CH - 8802 Kilchberg Telefon 01 / 716 10 00 Telefax 01 / 716 10 05 info@hp-engineering.com www.hp-engineering.
Massenversand Massenversand Seite 1 Massenversand Seite 2 Inhaltsverzeichnis 1. WICHTIGE INFORMATIONEN ZUR BEDIENUNG VON CUMULUS 4 2. STAMMDATEN FÜR DEN MASSENVERSAND 4 2.1 ALLGEMEINE STAMMDATEN 4 2.2
Mehr4. BEZIEHUNGEN ZWISCHEN TABELLEN
4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe
MehrSind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar?
Sind Prozessmanagement-Systeme auch eingebettete Systeme einsetzbar? 12. Symposium Maritime Elektrotechnik, Elektronik und Informationstechnik, 8.-12. Oktober 2007 Rostock, Deutschland Rostock, Deutschland
MehrHandbuch. NAFI Online-Spezial. Kunden- / Datenverwaltung. 1. Auflage. (Stand: 24.09.2014)
Handbuch NAFI Online-Spezial 1. Auflage (Stand: 24.09.2014) Copyright 2016 by NAFI GmbH Unerlaubte Vervielfältigungen sind untersagt! Inhaltsangabe Einleitung... 3 Kundenauswahl... 3 Kunde hinzufügen...
MehrAuf der linken Seite wählen Sie nun den Punkt Personen bearbeiten.
Personenverzeichnis Ab dem Wintersemester 2009/2010 wird das Personenverzeichnis für jeden Mitarbeiter / jede Mitarbeiterin mit einer Kennung zur Nutzung zentraler Dienste über das LSF-Portal druckbar
MehrNeuer Downloadbereich
Neuer Downloadbereich Seite 2 Inhaltsverzeichnis 1. REGISTRIERUNG... 3 2. MEIN KONTO... 5 3. PASSWORT VERGESSEN / ÄNDERN... 6 4. E-MAIL-ADRESSE ÄNDERN... 8 5. MEINE DOWNLOADS... 9 6. AUSLOGGEN... 11 Seite
MehrDie Telematik-Infrastruktur (TI)
Die Telematik-Infrastruktur (TI) Bedeutung, Hintergründe und Ziele Juli 2015 Düsseldorf IT-Beratung der KV Nordrhein Inhalt Bedeutung Telematik und TI? Hintergrund der TI Was sind die Ziele der TI? TI
Mehrwindata SEPA-API Basic / Pro Dokumentation
windata SEPA-API Basic / Pr Dkumentatin Versin v1.8.0.0 11.11.2014 windata GmbH & C. KG windata GmbH & C.KG Gegenbaurstraße 4 88239 Wangen im Allgäu windata SEPA-API Basic / Pr - Dkumentatin Inhaltsverzeichnis
MehrLeitfaden zu VR-Profi cash
Single Euro Payment Area (SEPA)-Umstellung Leitfaden zu VR-Profi cash Wichtiger Hinweis Bitte beachten Sie, dass die btacs GmbH alle Leitfäden nach bestem Wissen und Gewissen erstellt hat, und diese der
Mehr