A.   NTS ENCODING GUIDE FÜR EDITOREN

INHALTSVERZEICHNIS

Abkürzungen

1.   Hintergrund, Aufbau und Zweck von NtS Encoding Guides

Der NtS-Standard wird fortlaufend verbessert. Die Freigabe des NtS Web Service bedeutete durch die Erleichterung des Austausches von NtS-Nachrichten zwischen Behörden einerseits und Behörden und NtS-Nutzern andererseits einen großen Schritt nach vorn.

Zur Erleichterung der harmonisierten Codierung von NtS-Nachrichten auf nationaler und internationaler Ebene wurden zwei Unterlagen erstellt, nämlich der NtS Encoding Guide für Editoren und der NtS Encoding Guide für Anwendungsentwickler. Diese Leitfäden gelten für die NtS XSD 4.0 und den NtS Web Service WSDL 2.0.4.0.

In Anbetracht der zunehmenden Nutzung des NtS Web Service sollen NtS-Nachrichten weiter harmonisiert werden, damit eine korrekte Anzeige der Inhalte auf Drittsystemen gewährleistet ist. Eine einheitliche Codierung von Nachrichten ist zudem eine Voraussetzung für die Berücksichtigung der Nachrichten in Reiseplanungsanwendungen.

Elemente, die nur Standardwerte oder vorgegebene Werte enthalten würden, werden weggelassen, sofern sie an Bedingungen geknüpft sind, denn sie führen nur zu allgemeinen Nachrichten ohne Mehrwert.

Der NtS Encoding Guide für Editoren wendet sich an den Personenkreis, der NtS-Nachrichten editiert (und herausgibt); der Leitfaden enthält eine Schritt-für-Schritt-Anleitung für die Erstellung der korrekten Nachrichtentypen sowie eine Erklärung der Codes. Im Leitfaden wird erläutert, wann die vier Typen der NtS-Nachrichten anzuwenden sind; außerdem enthält er Ausfüllanweisungen und Codes, die bei bestimmten Ereignissen zu verwenden sind. Der NtS Encoding Guide für Editoren ist Bestandteil der vorliegenden Anlage A.

Der NtS Encoding Guide für Anwendungsentwickler enthält Leitlinien für die Entwicklung und Implementierung von NtS-Anwendungen und erläutert deren Logik, Prozesse und automatische bzw. vorgegebene Werte. Der NtS Encoding Guide für Anwendungsentwickler ist Bestandteil der Anlage B zu dieser Verordnung.

2.   Auswahl des NtS-Nachrichtentyps

3.   Grundüberlegungen zu FTM, Schritte zur Herausgabe einer FTM

Genaue Angaben zu den zu verwendenden Codes sind Kapitel 4 zu entnehmen. Die ab Punkt 3.3 aufgeführten Überlegungen folgen nicht unbedingt der Eingabereihenfolge eines FTM-Editionstools.

4.   Erklärung der Codes für FTM

4.1.   Subject_code:

Festlegung der Verwendung von Betreff-Codes:

4.2.   Reason_code

Der Code für den Grund der Nachricht ist einzutragen, um den Schiffsführern ergänzende Informationen mitzuteilen.

Festlegung der Verwendung von Codes für den Grund der Nachricht:

4.3.   Limitation_code:

Definition der Codes für Einschränkungen:

4.4.   Limitation interval_code: Festlegung der Verwendung von interval codes:

4.5.   Indication_code:

Der Indication_code soll für Informationen über spezifische Werte im Hinblick auf bestimmte Einschränkungen (z. B. Geschwindigkeitsbegrenzungen, Mindestantriebsleistung, verfügbare Tiefe) verwendet werden. Zur Berechnung bestimmter Abmessungen ist ein Bezug auf ein externes (geografisches oder hydrologisches) Referenzsystem (z. B. Durchfahrtshöhe, verfügbare Tiefe, minimale Tiefe) erforderlich oder die Berechnung erfolgt in Relation zu bekannten Abmessungen von Bauwerken (z. B. verfügbare Länge, verfügbare Breite).

4.6.   Position_code (Objekte):

Nach Möglichkeit sollte sich der Position_code auf die Seite der Wasserstraße beziehen, auf der sich das Objekt relativ zur Fahrwasserachse (links/Mitte/rechts), relativ zu anderen allgemein bekannten Informationen (alt/neu) oder zur geografischen Richtung (Nord/Süd/Ost/West) befindet. Der Position_code für Objekte kann automatisch vorab aus den Referenzdaten des RIS Index eingetragen werden. Die linke/rechte Seite der Wasserstraße ist stromabwärts definiert.

4.7.   Position_code (Fahrwasser/Wasserstraße):

Ein Position_code für eine auf eine Wasserstraße bezogene FTM (oder Teil einer solchen FTM) ist nicht vorgesehen. Um anzugeben, auf welcher Seite des Fahrwassers/Kanals/Flusses/Sees ein Ereignis eintritt, wird die Einschränkung „besondere Vorsicht“ verbunden mit dem korrekten Position_code der Einschränkung verwendet.

4.8.   Position_code (Einschränkungen):

4.9.   Target_group_code (siehe Kapitel 3.5)

4.10.   Reporting_code

4.11.   Communication_code

es ist das folgende Format zu nutzen (Beispiele):

4.12.   Type_code:

Eine Wasserstraße ist entweder ein Kanal, ein See oder ein Fluss.

5.   Grundüberlegungen zu WRM

Wasserstandsmeldungen sind generell automatisch zu erstellen. Ist dies nicht möglich, muss die manuelle Erstellung von WRM möglichst eng an die für automatisch erstellte WRM festgelegten Prozesse angelehnt sein (siehe NtS Encoding Guide für Anwendungsentwickler).

6.   Grundüberlegungen zu ICEM, Schritte zur Herausgabe einer ICEM

Eismeldungen sind von örtlicher Beobachtung und Bewertung abhängig und werden gewöhnlich von entsprechend bevollmächtigtem Personal erstellt.

Eine ICEM ist herauszugeben, wenn Eis vorliegt. Eis verursacht nicht unbedingt Einschränkungen für die Schifffahrt, es können aber Informationen über die Schifffahrt nicht behindernde Eisverhältnisse bereitgestellt werden.

7.   Grundüberlegungen zu WERM

In Anbetracht der Fülle verfügbarer Webdienste und Apps für Wettervorhersagen und Unwetterwarnungen sollten WERM nur für Wetterinformationen von besonderer Wichtigkeit für die Schifffahrt verwendet werden, die von allgemeinen Wetterinformationsdiensten nicht erfasst werden.

Wettermeldungen sind generell automatisch zu erstellen. Ist dies nicht möglich, muss die manuelle Erstellung von WERM möglichst eng an die für automatisch erstellte WERM festgelegten Prozesse angelehnt sein (siehe NtS Encoding Guide für Anwendungsentwickler).

8.   Regeln für bestimmte Elemente

8.1.   Regeln für das Element „name“ in Bezug auf Objekte

Objektbezeichnungen (Namen) werden gewöhnlich vom NtS-Editionstool anhand von RIS Index-Referenzdaten vorab eingetragen. Namen sind in der Landessprache einzutragen, d. h., es können auch Umlaute oder kyrillische Buchstaben verwendet werden. (z. B. Baarlerbrücke, Volkeraksluis oder Mannswörth).

Keine Informationen über Merkmale des Objekts aufnehmen; der Objekttyp ist im Namen nicht zu wiederholen, sofern damit keine ergänzenden Informationen zum Objekttyp übermittelt werden.

Beispiel: Die Schleuse „Schleuse Freudenau“ ist nur als „Freudenau“ zu bezeichnen, der Objekttyp „Schleuse“ wird automatisch auf der Grundlage des type_code hinzugefügt.

Beispiel: Die Objektbezeichnung für die Eisenbahnbrücke in Krems (AT) lautet „Eisenbahnbrücke Krems“. Die Information „Eisenbahnbrücke“ wird in die Objektbezeichnung aufgenommen, weil sie ergänzende Informationen zum type_code „Brücke“ übermittelt.

Beispiel: Die Objektbezeichnung für eine Brücke in Linz (AT) lautet „Nibelungenbrücke“. Das Wort „Brücke“ bleibt in der Objektbezeichnung stehen, weil es Bestandteil der Brückenbezeichnung an sich ist.

Beispiel: Der Wasserstraßenpegel „Pegelstelle Wildungsmauer“ wird als „Wildungsmauer“ bezeichnet, weil die Information, dass es sich bei dem Objekt um eine Pegelstelle handelt, bereits im type_code codiert ist.

Bildet ein Wasserstraßenabschnitt die Grenze zwischen zwei Ländern mit unterschiedlichen Sprachen, kann die nationale Objektbezeichnung in beiden Sprachen bereitgestellt werden (z. B. „Staatsgrenze AT-SK/Statna hranica AT-SK“).

8.2.   Regeln für das Element „name“ in Bezug auf Wasserstraßen

Bezeichnungen von Wasserstraßen (Namen) werden gewöhnlich vom NtS-Editionstool anhand von RIS Index-Referenzdaten vorab eingetragen. Das Feld „name“ enthält die örtliche Bezeichnung des betreffenden Wasserstraßenabschnitts (z. B. „Rhein“). Je nach nationalen Verfahren kann die Möglichkeit bestehen, die Bezeichnung der Wasserstraße zu editieren und übliche örtliche Bezeichnungen oder Ergänzungen aufzunehmen (z. B. „Rhein am Deutschen Eck“).

8.3.   Regeln für die Elemente „value“ und „unit“ bei Einschränkungen

Wenn nicht anders angegeben, dürfen in NtS-Nachrichten nur cm, m3/s, h, km/h und kW, m/s (Wind), mm/h (Regen) und Grad Celsius als Maßeinheiten (units) benutzt werden.

B.   NtS ENCODING GUIDE FÜR ANWENDUNGSENTWICKLER

INHALTSVERZEICHNIS

1.   Hintergrund und Aufbau

Nachrichten für die Binnenschifffahrt (NtS) wurden auf der Grundlage der Verordnung (EG) Nr. 416/2007 der Kommission über die technischen Spezifikationen für Nachrichten für die Binnenschifffahrt gemäß Artikel 5 der Richtlinie 2005/44/EG des Europäischen Parlaments und des Rates über harmonisierte Binnenschifffahrtsinformationsdienste (RIS) auf den Binnenwasserstraßen der Gemeinschaft in verschiedenen europäischen Ländern eingerichtet. Der NtS-Standard wird fortlaufend weiterentwickelt; die Freigabe des NtS Web Service bedeutete durch die Erleichterung des Austausches von NtS-Nachrichten zwischen Behörden einerseits und Behörden und Nutzern dieser Nachrichten andererseits einen großen Schritt nach vorn; ein weiterer Fortschritt war die NtS XSD 4.0, mit der die Codierung von NtS-Nachrichten gestrafft wurde.

1.1.   Zweck des NtS Encoding Guide

Im NtS Encoding Guide wird erläutert, wann die vier Typen der NtS-Nachrichten anzuwenden sind; außerdem enthält er Codes, die bei bestimmten Ereignissen zu verwenden sind. Der Leitfaden gibt den NtS-Editoren Ausfüllanweisungen an die Hand und ermöglicht so eine auf nationaler und internationaler Ebene harmonisierte Codierung von NtS-Nachrichten.

In Anbetracht der zunehmenden Nutzung des NtS Web Service sollten die NtS-Nachrichten weiter harmonisiert werden, damit eine korrekte Anzeige der Inhalte auf Drittsystemen gewährleistet ist. Eine einheitliche Codierung von Nachrichten ist zudem eine Voraussetzung für die Berücksichtigung der Nachrichten in Reiseplanungsanwendungen. Die Version 1.0 des NtS Encoding Guide gilt für NtS XSD 4.0 und den NtS Web Service WSDL 2.0.4.0.

1.1.1.   NtS Encoding Guide für Editoren

Der NtS Encoding Guide für Editoren wendet sich an den Personenkreis, der NtS-Nachrichten editiert (und herausgibt); der Leitfaden enthält eine Schritt-für-Schritt-Anleitung für die Erstellung der korrekten Nachrichtentypen sowie eine Erklärung der Codes. Der NtS Encoding Guide für Editoren enthält auch für Anwendungsentwickler relevante Informationen.

1.1.2.   NtS Encoding Guide für Anwendungsentwickler

Der NtS Encoding Guide für Anwendungsentwickler enthält Leitlinien für die Implementierung von NtS-Anwendungen und erläutert deren Logik, Prozesse und automatische bzw. vorgegebene Werte.

2.   NtS-Nachrichten und Abschnitte

Eine Nachricht für die Binnenschifffahrt setzt sich wie folgt zusammen:

Abbildung 2

Bildliche Darstellung der Struktur der NtS-Nachricht: obligatorisches Element (1), obligatorisches Element, das einmal oder zweimal erscheinen kann (1…2), obligatorisches Element, das zweimal erscheinen muss (2), obligatorisches Element, das so oft erscheinen kann wie erforderlich (1-n), fakultatives Element, das so oft erscheinen kann wie erforderlich (0…n)

Der Identifikationsabschnitt ist obligatorisch und enthält allgemeine Angaben zum Urheber der Nachricht, dem Absender, dem Herausgabedatum, dem Land und der Ausgangssprache; er wird zusammen mit einem der vier verschiedenen Abschnittsarten der NtS-Nachricht übermittelt:

Darüber hinaus wird der ISRS (International Ship Reporting Standard) Location Code zur Definition des Objekts oder des Wassserstraßenabschnitts verwendet, auf das bzw. den sich die Nachricht bezieht.

Der ISRS Location Code ist in Nummer 4.3 des Anhangs dieser Verordnung definiert.

3.   Grundüberlegungen WRM

Wasserstandsinformationen sind sowohl für die Reiseplanung als auch für die Sicherheit von Bedeutung. Derzeit gibt es keinen gemeinsamen Standard als Referenz für Wasserstandsinformationen. Die Pegelwerte beziehen sich auf unterschiedliche Meeresniveaus oder spezielle Pegelnullpunkte. Für eine angemessene Bezugnahme ist mit dem Wert stets der jeweilige „reference_code“ bereitzustellen. WRM können zur Übermittlung folgender Informationen genutzt werden:

Erläuterungen zu Übersetzungen in der Kalkulationstabelle „reference code“ sind Kapitel 7.11 zu entnehmen.

Üblicherweise werden WRM automatisch auf der Grundlage von Informationen, die von Sensoren oder der Infrastruktur (z. B. Vorhersagen, Staustand) übermittelt werden, erstellt und herausgegeben. Für die Herausgabe von WRM kann es unterschiedliche Auslöser geben, beispielsweise werden sie in regelmäßigen Abständen oder beim Erreichen bestimmter Werte herausgegeben.

3.1.   Ausfüllen des Abschnitts nts_number in der WRM

In der NtS XSD 4.0 ist die NtS-Nummer in WRM optional. Wird sie übermittelt, muss die Nummer für jeden Nachrichtentyp einmalig sein (Organisation/Year/Number/Serial) und es obliegt der die WRM bereitstellenden Organisation, einmalige Nummern zu gewährleisten (aufeinanderfolgende Nummern sind nicht erforderlich).

3.2.   Ausfüllen der WRM einschließlich der Vorhersagen

In „date_start“ von „validity_period“ ist das heutige Datum (date_issue) einzutragen; in „date_end“ von „validity_period“ muss der Tag nach dem „date_issue“ eingetragen werden.

Um Veränderungen, beispielsweise beim Wasserstand, benutzerfreundlich zu übermitteln, kann die Differenz zu einer früheren Vergleichsmessung im Abschnitt „difference“ der WRM eingetragen werden. Neben der Veränderung beim Wert (z. B. - 5 [cm]) ist auch der Zeitunterschied zur Vergleichsmessung einzutragen.

Bei Vorhersagen ist „measure_date“ das Datum und die Uhrzeit, für das bzw. die die Vorhersage gilt.

Wasserstandsvorhersagen beinhalten immer einen Unsicherheitsfaktor. Gewöhnlich werden Modelle mit unterschiedlichen Parametern (z. B. Wettervorhersagen) berechnet, die zu unterschiedlichen Vorhersagewerten für den Wasserstand führen. Um die Übermittlung eines vorhergesagten Mindest- und Höchstwerts zu ermöglichen, beispielsweise die visuelle Darstellung eines Vertrauensintervalls für die Wasserstandsvorhersage, enthält der Abschnitt „measure“ der WRM zwei zusätzliche, optionale Datenfelder.

Die folgende Abbildung enthält eine Darstellung des Vertrauensintervalls für Wasserstandsvorhersagen.

Abbildung 3

Bildliche Darstellung des Vertrauensintervalls für die Wasserstandsvorhersage: wahrscheinlichster Wert (schwarz), obere Grenze des Vertrauensintervalls (violett), untere Grenze des Vertrauensintervalls (rot), gemessener Wasserstand (blau).

(Die x-Achse gibt die Zeit an, die y-Achse den Wasserstand (in cm))

In der NtS XSD stehen zwei Elemente zur Verfügung:

Neben den vorhergesagten Wasserständen kann das Vertrauensintervall auch zur Angabe der Unsicherheit der veröffentlichten Informationen über die minimale Tiefe und die Durchfahrtshöhe genutzt werden.

Die Werte value_min und value_max des Vertrauensintervalls ermöglichen, über die standardisierte NtS-WRM das Vertrausensintervall für WRM-Werte zu übermitteln, um es in grafischen Darstellungen zu verwenden. Die eigentlichen Rohdaten werden den IWT-Nutzern nicht angezeigt (z. B. im Codeformat).

Der measure_code „NOM“ darf nicht verwendet werden. Falls für einen bestimmten Typ von WRM keine Messung vorliegt, sind die entsprechenden Wertelemente freizulassen, wenn trotzdem eine Meldung gesendet werden soll.

4.   Prozesse für ICEM

Eismeldungen sind von örtlicher Beobachtung und Bewertung abhängig und werden gewöhnlich von Hand erstellt (bei einer automatischen Erstellung müssen die Regeln für die manuelle Erstellung befolgt werden, siehe den NtS Encoding Guide für Editoren).

Eine ICEM wird für einen bestimmten fairway_section, der durch die ISRS Location codes für seinen Anfang und sein Ende definiert wird, herausgegeben und enthält die Eisverhältnisse (ice_condition) an einem bestimmten Messdatum.

Die Gültigkeit der ICEM beginnt am Tag der Herausgabe (wird von der NtS-Anwendung automatisch eingesetzt). Um zu vermeiden, dass Nutzern ICEM angezeigt werden, die nicht mehr gültig sind, muss als date_end der Gültigkeit von der NtS-Anwendung automatisch der Tag nach der Herausgabe eingetragen werden (außer wenn durch nationale Prozesse sichergestellt wird, dass Meldungen ein Enddatum der Gültigkeit zugewiesen wird, sobald die in der Meldung enthaltene Information nicht mehr aktuell ist).

Im NtS Encoding Guide für Editoren wird beschrieben, unter welchen Umständen ein NtS-Editor eine neue ICEM erstellt oder eine ICEM aktualisiert. Es gelten die folgenden Prozesse:

4.1.   Neue ICEM

4.2.   Aktualisierung einer bestehenden ICEM

5.   Grundüberlegungen zu WERM

Üblicherweise werden WERM automatisch auf der Grundlage von Informationen, die von Sensoren oder der Infrastruktur übermittelt werden, erstellt und herausgegeben. In „date_start“ von „validity_period“ ist das heutige Datum (date_issue) einzutragen; in „date_end“ von „validity_period“ muss der Tag nach dem „date_issue“ eingetragen werden.

In WERM wird der Wasserstraßenabschnitt als eine Strecke zwischen zwei Punkten des Wasserstraßenabschnitts, also als Geltungsbereich der Wetterstation (Pegel), angegeben.

Datum und Uhrzeit der Messung/Vorhersage müssen übermittelt werden, auch wenn dies in WERM nicht obligatorisch ist.

Bei Vorhersagen ist unter dem „Messdatum“ (measure date) das Datum und die Uhrzeit zu verstehen, für das/die die Vorhersage gilt.

5.1.   Ausfüllen des Abschnitts nts_number in der WERM

In der NtS XSD 4.0 ist die NtS-Nummer in WERM optional. Wird sie übermittelt, muss die Nummer für jeden Nachrichtentyp einmalig sein (Organisation/Year/Number/Serial) und es obliegt der die WERM bereitstellenden Organisation, einmalige Nummern zu gewährleisten (aufeinanderfolgende Nummern sind nicht erforderlich).

5.2.   Ausfüllen des Abschnitts „weather_category_code“ in der WERM

Die Windgeschwindigkeit im „weather_category_code“ (Werte 0 bis 12) ist entsprechend der von der Weltorganisation für Meteorologie in ihrem Handbuch für Seewetterdienste (Manual on Marine Meteorological Services) WMO-Nr. 558 veröffentlichten Beaufort-Skala zu übermitteln.

Die Sichtverhältnisse im „weather_category_code“ (Werte 13 bis 22) sind entsprechend der Definition in der folgenden Tabelle anzugeben.

6.   Prozesse für FTM

Im NtS Encoding Guide für Editoren wird beschrieben, unter welchen Umständen ein NtS-Editor eine neue FTM erstellt oder eine bestehende FTM aktualisiert. Es gelten die folgenden Prozesse:

6.1.   Neue FTM

6.2.   Aktualisierung/Aufhebung einer bestehenden FTM

6.3.   FTM in Bezug auf Wasserstraßen und Objekte

Eine FTM in Bezug auf Wasserstraßen enthält Informationen über einen oder mehrere Wasserstraßenabschnitt(e). Ein Wasserstraßenabschnitt wird im Teil „fairway_section“ durch die ISRS Location Codes für seinen Anfang und sein Ende definiert.

Eine FTM in Bezug auf Objekte enthält Informationen über ein oder mehrere besondere(s) Objekt(e) an der Wasserstraße. Ein Objekt wird im Teil „object“ durch seinen ISRS Location Code definiert.

Eine FTM muss sich auf Folgendes beziehen:

6.4.   Automatische Rangfolge von Einschränkungscodes

Unterschiedliche Einschränkungen haben unterschiedliche Auswirkungen auf die Schifffahrt. Um die Anzeige der schwerwiegendsten Einschränkungen — etwa in einer FTM-Übersichtsliste — zu ermöglichen, sollte die folgende Rangfolge berücksichtigt werden, beginnend mit der schwerwiegendsten Einschränkung auf Rang 1:

6.5.   Handhabung des Einschränkungszeitraums

7.   Allgemeine Regeln für die Umsetzung

Es ist Folgendes zu berücksichtigen:

7.1.   Ausfüllen des Abschnitts „number_section“

Jede Nummer (Organisation/Year/Number/Serial) muss für jeden Nachrichtentyp einmalig vergeben sein. Das bedeutet, dass Nachrichten unterschiedlicher Typen die gleiche NtS-Nummer haben können.

Für Nutzer sind die Nachrichtennummern nur für FTM und ICEM relevant; bei allen anderen Nachrichtentypen kann die Anzeige der Nachrichtennummer je nach nationalen Anforderungen unterbleiben.

Den Nutzern ist die Nachrichtennummer im folgenden Format anzuzeigen: „Message Type/Country/Organisation/Year/Number/Serial“ (je nach verwendeten Filtern und sofern dabei keine Informationen verloren gehen, kann sie verkürzt werden).

7.2.   Ausfüllen der Elemente „from“, „originator“, „organisation“ und „source“

In das Element „from“ im Identifikationsabschnitt wird der Name des nationalen Systems, das die Nachricht bereitstellt, eingetragen (z. B. ELWIS, DoRIS, SLOVRIS, FLARIS).

Das Element „originator“ bezeichnet die Organisation, die Nachrichten in nationale Systeme eingibt.

Das Element „source“ bezeichnet die Behörde, für die die wasserstraßen- und verkehrsbezogenen Nachrichten herausgegeben werden.

Das Element „organisation“ im Abschnitt nts_number ist der Name der die nts_number zuweisenden Organisation (NtS-Anbieter).

7.3.   Weglassen von Elementen

Elemente, die nur Standardwerte oder vorgegebene Werte enthalten würden, werden weggelassen, sofern sie an Bedingungen geknüpft sind, denn sie führen nur zu allgemeinen Nachrichten ohne Mehrwert.

Dies betrifft die folgenden Elemente:

7.4.   Automatische Eintragung von date_issue

FTM und ICEM

Bei FTM und ICEM entspricht der Wert des Elements date_issue dem aktuellen Datum und der aktuellen Uhrzeit der Herausgabe. Bei aktualisierten Nachrichten entspricht date_issue dem Datum und der Uhrzeit der Herausgabe der Aktualisierung.

WRM und WERM

Bei WRM und WERM entspricht der Wert des Elements date_issue dem Datum und der Uhrzeit der Verarbeitungsaufforderung, denn innerhalb einer WRM oder WERM können mehrere Messungen mit unterschiedlichen Herausgabe-Zeitstempeln vorliegen.

7.5.   Handhabung von Angaben über Zeitzonen in NtS-Nachrichten

In NtS-XML-Nachrichten sind Datum und Uhrzeit immer als Ortszeit unter Einschluss von Angaben zur Zeitzone zu übermitteln.

Die einzigen Ausnahmen zu dieser Bestimmung sind „time_start“ und „time_end“ im Abschnitt „limitation_period“. Der Grund hierfür ist, dass im Abschnitt für die Einschränkung ein Intervall verwendet werden kann. Bestehen für das Start- und das Enddatum unterschiedliche Zeitregelungen (z. B. CEST und CET), führt dies zu einer Änderung der Zeitzonenangabe innerhalb dieses Intervalls. Diese Änderung kann nicht mit Hilfe eines einzigen Einschränkungszeitraums ausgedrückt werden. Anstatt für jede Zeitänderung andere Einschränkungszeiträume anzulegen, wird ein einziger Einschränkungszeitraum ohne Zeitzoneninformation verwendet, um den allgemeinen Aufwand in der Verarbeitung und Übertragung von Nachrichten zu verringern.

7.6.   Handhabung von Sekunden in NtS-Nachrichten

Als allgemeine Regel gilt, dass Sekunden in Feldern für (Datum/)Uhrzeit angegeben werden müssen, aber den NtS-Nutzern nicht angezeigt werden. Minuten genügen für NtS-Granularität.

7.7.   Format der Dezimalzahlen in NtS-Nachrichten

Dezimalzahlen in numerischen Feldern werden mit einem „.“ (Punkt) angegeben. Es wird kein Tausender-Trennzeichen benutzt.

Zur Gewährleistung einer nutzerfreundlichen Anzeige ist die Anzahl der für die Angabe von Werten verwendeten Dezimalstellen auf eine praktikable Anzahl zu begrenzen.

7.8.   In NtS-Nachrichten zu verwendende Maßeinheiten

In NtS-Nachrichten dürfen nur cm, m3/s, h, km/h und kW, m/s (Wind), mm/h (Regen) und Grad Celsius als Maßeinheiten benutzt werden; zwecks Nutzerfreundlichkeit können die Maßeinheiten in Anwendungen umgerechnet werden.

Unterscheiden sich die Eingabeeinheiten von den standardisierten Einheiten, müssen die eingegebenen Werte von der Anwendung entsprechend umgerechnet werden.

7.9.   Regeln für die Elemente „name“, „position_code“ und „type_code“

Das Element „name“ wird automatisch aus den Referenzdaten des RIS Index („national object name“) eingetragen (NtS-Editoren können die vorausgefüllten Namen ändern, wenn dies eine nationale Vorschrift ist). Benennungskonventionen für Objektbezeichnungen sind dem RIS Index Encoding Guide, Fassung 2.0 oder höher, zu entnehmen. Auch im NtS Encoding Guide für Editoren werden Beispiele für ordnungsgemäße Objektnamen aufgeführt.

Der Typcode (type_code) wird dem Objektnamen von der NtS-Anwendung vorangestellt.

Die Position von Objekten wird mittels des Positionscodes (position_code) codiert und dem Objekt von der NtS-Anwendung aus dem RIS Index hinzugefügt. Editoren können vorausgefüllte Typ- und Positionscodes ändern. Für geo_objects im fairway_section wird kein Objektpositionscode übermittelt.

Ein vollständiger Objektname besteht aus dem „position_code“, dem „typ_code“ und dem „name“.

Zur Arbeitserleichterung für NtS-Editoren können in NtS-Editionstools, die Editoren bei der Suche bzw. Auswahl der zutreffenden Objekte auf der Basis des RIS Index function_code oder dem NtS-type_code unterstützen, folgende Zuordnungen eingerichtet werden:

Tabelle 1

Entsprechung „RIS Index function_code“ — „NtS type_code“

7.10.   Regeln für das Element „fairway_name“

Zur Vermeidung der Anwendungslogik bzw. der Notwendigkeit korrekter Referenzdaten im Empfangssystem (der Software, mit der dem Nutzer die Nachricht angezeigt wird) muss das optionale Element „fairway_name“ immer in das „geo_object“ aufgenommen und von der NtS-Anwendung automatisch mit dem „waterway name“ aus dem RIS Index ausgefüllt werden. Editoren dürfen den Inhalt des Elements „fairway_name“ nicht ändern.

7.11.   Erläuterungen zu Übersetzungen in der Kalkulationstabelle „reference_code“

Für die Werte des reference_code in den NtS Reference Tables sind folgende Definitionen zu verwenden:

7.12.   Empfehlung für das Element „coordinate“

Obgleich das Element „Koordinate“ im Abschnitt Geo-Objekt optional ist, sind die geografischen Koordinaten in WGS84 im Format [d]d mm.mmm[m] N (latitude) und [d][d]d mm.mmm[m] E (longitude) anzugeben. Dies dient zur Herstellung eines geografischen Bezugs der NtS-Mitteilungen.

7.13.   Handhabung von Zielgruppen

Der Abschnitt Zielgruppe besteht aus dem Code für die Zielgruppe und dem Code für die Richtung. Wenn beide den Wert ALL haben, ist der gesamte Abschnitt auszulassen, sofern in der Nachricht keinen anderen, besonderen Zielgruppen enthalten sind. Wird nur einer der beiden Codes angegeben, muss der andere mit dem vorgegebenen Wert ALL ausgefüllt werden, weil beide Elemente obligatorisch sind.

Weitere Informationen zu Zielgruppen sind dem NtS Encoding Guide für Editoren zu entnehmen.

7.14.   Anzeige der zu einem bestimmten Zeitpunkt gültigen Nachrichten

Das Element „validity_period“ ist von den Anwendungen zur Auswahl derjenigen Nachrichten zu nutzen, die Nutzern über einen angeforderten Zeitraum angezeigt werden sollen.

Lautet der „subject_code“ INFSER (Informationsservice), wird der Gültigkeitszeitraum zur Angabe des Zeitraums verwendet, in dem die Nachricht des Informationsservice für die Nutzer angezeigt wird, nicht für den Zeitraum, in dem die übermittelte Information gültig ist (z. B. ein Monat).

7.15.   Optionale Funktionen zur Erhöhung der Nutzerfreundlichkeit des NtS-Editionstools

Je nach nationalen Anforderungen können NtS-Editoren die folgenden Funktionen angeboten werden:

8.   Struktur der NtS-XML-Nachrichten

Die Struktur der NtS-XML-Nachrichten sowie Inhalt und Zweck der Datenelemente werden in Anlage C „Definition des NtS-XML-Schemas (XSD)“ definiert und näher erläutert.

9.   NtS Web Service

9.1.   Zielsetzung

Die NtS-Expertengruppe hat festgestellt, dass die Technologie des web service ein angemessenes Mittel zur Übermittlung der Nachrichten für die Binnenschifffahrt ist.

Dieses Kapitel stellt die Spezifikation des web service für die Übermittlung von Nachrichten für die Binnenschifffahrt, kurz den NtS Web Service, dar. Besonderes Gewicht wurde auf die Verwendung bewährter internationaler Standards gelegt.

Ein Ziel der konzeptionellen Gestaltung bestand darin, zwischen Flexibilität und Robustheit des entstehenden web service ein ausgewogenes Verhältnis zu gewährleisten. Die in den Anfragen vorgesehenen Filterparameter entsprechen im Wesentlichen den im NtS-Standard festgelegten Kriterien (Wasserstraßenabschnitt mit optionalem Fluss-km, zeitliche Gültigkeit, Datum der Herausgabe der Nachricht). In Anbetracht der Anwendungsfälle des web service erscheint dies als hinreichend aussagekräftig, begrenzt aber zugleich die Komplexität der Umsetzung.

Hauptergebnis ist ein Vertrag über den web service, in dem die Anfragen und die Antworten festgelegt werden. Die Nutzer des web service können sich auf diesen Vertrag verlassen und die Provider müssen ihn einhalten. Dieser Vertrag wurde mittels des internationalen Standards WSDL festgelegt.

Jeder teilnehmende Mitgliedstaat richtet einen oder mehrere web services für die verschiedenen NtS-Nachrichtentypen (FTM, WRM, ICEM, WERM) ein und stellt sie über das Internet bereit (NtS Message Service).

Die technischen Einzelheiten für die Umsetzung des NtS Web Service, z. B. Auswahl geeigneter Datenpools, Anwendungen und Plattformen, fallen nicht unter diese Spezifikation und liegen in der Verantwortung jedes einzelnen teilnehmenden Mitgliedstaates.

Um eine sichere Kommunikation festlegen zu können, müssen verschiedene Sicherheitsaspekte und Schutzziele berücksichtigt werden. Abhängig von den jeweiligen Umständen müssen nicht alle Aspekte in die Überlegungen einbezogen werden. Die Rangfolge der verschiedenen Sicherheitsaspekte und der Grad ihrer Umsetzung kann unterschiedlich sein. Die Möglichkeiten der technischen Umsetzungen können zudem die Realisierbarkeit einer bestimmten Maßnahme begrenzen. Alle Informationen im NtS-Kontext sind öffentlich. Es besteht also keine Notwendigkeit, die NtS-Daten an sich im Hinblick auf den Datenschutz zu sichern. Aus diesem Grund muss jeder Provider selbst entscheiden, in welchem Grad dieser Aspekt in seinem Dienst umgesetzt wird.

9.2.   Grundprinzipien und grundlegende Sachzwänge

9.2.1.   Web-Standards

Der NtS Web Service muss das WS-I-Grundprofil 1.1 erfüllen. Dieses Profil „bietet eine Orientierungshilfe für die Kompatibilität einer Grundmenge an Spezifikationen für nicht geschützte web services wie SOAP, WSDL und UDDI“ (1). Die hier verwendeten, relevantesten Standards sind:

Die Antwortnachricht des NtS Web Service ist eine NtS-Nachricht, die in der Definition des XML-Schemas (XSD) in Anlage C zur vorliegenden Verordnung der Kommission festgelegt ist.

9.2.2.   Interaktionsmodell und Codierungsmethode für den NtS Web Service

Für den NtS Web Service wird die Codierungsmethode Document-Literal Wrapped genutzt, weil sie eine Validierung anhand eines XML-Schemas erlaubt und weil die in der WSDL-Spezifikation definierten Operationsbezeichnungen in den SOAP-Nachrichten unmittelbar als XML-Tag-Bezeichnungen verwendet werden.

9.3.   Allgemeine Spezifikationen und Empfehlungen

9.3.1.   Spezifikation: Angaben zur Version (Fassung)

Die Angaben zur Version des NtS Web Service bestehen aus zwei Abschnitten:

Der Abschnitt des web service an sich besteht aus zwei Teilen:

Die übergeordnete Version wird als positive Ganzzahl angegeben und bezeichnet die Hauptversion des web service.

Die untergeordnete Version wird als nicht negative Ganzzahl angegeben und bezeichnet die Nebenversion des web service innerhalb der Hauptversion.

Der Abschnitt des NtS-Schemas enthält die Version des NtS-Schemas gemäß Definition durch die NtS-Expertengruppe.

Die Version des hier spezifizierten NtS Web Service ist also 2.0.4.0, wobei 2.0 die Version des web service an sich bezeichnet und 4.0 die Version des genutzten NtS-Schemas.

Ausdrückliche Angaben zur Version sind in den Anfragen oder Antworten des NtS Web Service nicht erforderlich. Es wird erwartet, dass nur jeweils wenige Versionen der Dienste gleichzeitig online sein werden. Unterschiedliche Versionen werden mit unterschiedlichen URL versehen. Folglich wird jede Implementierung eines NtS Web Service eine bestimmte Version des NtS Web Service unterstützen

9.3.2.   Spezifikation: Struktur von Namensräumen

Die Namensräume (namespaces) im NtS Web Service basieren auf der Web-Domäne der RIS-Expertengruppen, http://www.ris.eu/.

Die Namensräume enthalten eine Komponente, die den entsprechenden Dienst sowie Informationen zur Version anzeigt. Der hier spezifizierte Dienst nutzt also den folgenden Namensraum:

NtS Message Service: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3.   Empfehlung: Nutzung von Namensräumen

Es wird empfohlen, zur Erzielung einer höheren Transparenz von XML-Dokumenten in dem am besten geeigneten Element der Schemata sowie den Dokumenten für den jeweiligen Fall Namensräume zu definieren und keine lokalen Namensraumdefinitionen in verschachtelten Elementen zu verwenden.

9.3.4.   Empfehlung: Verwendung von Vorsilben für Namensräume

Anfragen und Antworten im NtS Web Service nutzen XML-Elemente in qualifizierter Form, d. h. mit einer Vorsilbe für den Namensraum, und XML-Attribute in unqualifizierter Form, d. h. ohne Vorsilbe für den Namensraum.

Um eine bessere Lesbarkeit für Menschen zu erreichen, wird empfohlen, intuitive Namensraumvorsilben wie beispielsweise „nts“ zu verwenden.

9.3.5.   Spezifikation: Verwendung von ISRS Location Codes

Der ISRS Location Code wird in Kapitel 2 des NtS Encoding Guide für Anwendungsentwickler sowie im RIS Index Encoding Guide erläutert.

Bei einer Abfrage eines NtS Web Service kann der Kunde auf verschiedene Objekte, z. B. Wasserstraßenabschnitte, Pegel oder Schleusen, Bezug nehmen. Werden die entsprechenden Parameter, die ID-Elemente, verwendet, müssen sie ISRS Location Codes enthalten. Diese Parameter werden üblicherweise in ID-Elementen angegeben, wobei jeder ein oder zwei IDs enthält.

Bei der Verwendung dieser Parameter müssen die folgenden allgemeinen Konventionen eingehalten werden:

Zur Übermittlung von Wasserstraßenabschnitten (ID-Elementpaaare innerhalb von „fairway_section geo_object“) in NtS-Mitteilungen ist hinsichtlich der ISRS Location Codes Folgendes zu berücksichtigen:

Berührt eine Nachricht mehrere Wasserstraßenabschnitte, müssen alle Wasserstraßenabschnitte in getrennten „fairway_section“-XML-Elementen durch ihren Anfangs- und Endpunkt definiert werden.

Für einige Länder/Regionen ist es erforderlich, Filterfunktionen einzurichten. Lautet der ISRS Location Code (1-2) beispielsweise BE, verwenden Sie den ISRS Location Code (6-8) als ID zur Herstellung eines linearen Bezugs zum Wasserstraßen-Hektometer (ISRS Location Code 16-20). Beispiele für Wasserstraßenabschnitte (gültige ID-Elementpaare im „fairway_section“), die die oben definierten Ausnahmen enthalten:

Die folgende Abbildung zeigt für jede der allgemeinen Konventionen Gegenbeispiele für die Nutzung des ISRS Location Code (für Wasserstraßenabschnitte in der Slowakischen Republik (SK) gelten keine Ausnahmen von den allgemeinen Konventionen):

Ungültige Suchanfrage nach ISRS Location Codes

Allgemeine Bemerkung: Ein Abfragedienst für gültige ISRS Location Codes wird vom NtS Web Service nicht geboten. Die ISRS Location Codes werden im Europäischen Referenzdatenverwaltungssystem (European Reference Data Management System — ERDMS) bereitgestellt.

Die korrekte Verwendung der ISRS Location Codes in Suchanfragen und die Auslegung dieser Codes wird in den folgenden fünf Fallbeispielen gezeigt.

Fallbeispiel 1: Kein IDS-Element in der Anfrage

Das IDS-Element ist ein optionaler Teil der Anfrage, d. h. eine Suchanfrage ohne jegliche IDs-Elemente ist zulässig:

Gültige Suchanfrage ohne IDS-Parameter

Wird kein IDS-Element angegeben, sind alle Nachrichten als Antwort zu senden (selbstverständlich abhängig von anderen Filterkriterien wie validity_period oder dates_issue).

Fallbeispiel 2: Ein ID-Element in der Anfrage

Jedes IDS-Element kann ein oder zwei ID-Elemente enthalten. In der folgenden Abbildung wird ein Fall mit einem ID-Element gezeigt:

Gültige Suchanfrage mit einem ID-Parameter

Geht eine solche Suchanfrage ein, sendet der Server alle übereinstimmenden Nachrichten mit einem Anfangs-Hektometer ≤ „angegebener Wert“ (in diesem Beispiel 240,7) und einem End-Hektometer ≥ „dieser Wert“ als Antwort. In der folgenden Abbildung wird diese Auswahl von Nachrichten gezeigt: Die abgefragte Position liegt zwischen den Werten für die Start- und End-Hektometer der Nachrichten 1, 3 und 4, die als Antwort geschickt würden. Die Nachrichten 2, 5 und 6 überschneiden sich nicht mit der abgefragten Position, daher würden sie nicht geschickt werden.

Bezeichnet der angegebene ISRS Location Code ein einmaliges Objekt, z. B. einen Pegel oder eine Schleuse, sollte der web service die Nachrichten, in denen es um dieses Objekt geht, als Antwort schicken.

Übereinstimmende und nicht übereinstimmende Nachrichten für einen ID-Parameter

Fallbeispiel 3: Zwei ID-Elemente in der Anfrage

Jedes IDs-Element kann ein oder zwei ID-Elemente enthalten. In der folgenden Abbildung wird ein Fall mit zwei ID-Elementen gezeigt:

Gültige Suchanfrage mit zwei ID-Parametern

Alle abgefragten Hektometer-Werte werden auch dann als gültig behandelt, wenn der entsprechende Wasserstraßenabschnitt andere Anfangs- oder Endpunkte hat. Beginnt beispielsweise ein Wasserstraßenabschnitt an Hektometer 100,0 und endet er an Hektometer 300,0, wäre eine Anfrage, in der Hektometer 20,0 bis 400,0 abgefragt wird, gültig. Intern wird natürlich nur der „reale“ Umfang des Wasserstraßenabschnitts durchsucht.

Auf diese Weise wird die Suche nach sämtlichen Nachrichten über eine Wasserstraße ermöglicht, ohne dass der genaue Hektometer-Bereich bekannt ist (man würde dessen ISRS Location Code mit den Hektometerangaben „00000“ bzw. „99999“ einsenden).

Es werden alle passenden Nachrichten, die das angegebene Hektometer-Intervall schneiden, als Antwort gesendet. Diese Situation wird in dem folgenden Diagramm dargestellt:

Übereinstimmende und nicht übereinstimmende Nachrichten für zwei ID-Parameter

Die vorstehende Abbildung zeigt, wie „schneiden“ definiert ist. Während sich die Reichweite der Nachrichten 1 bis 4 mit dem Umfang des abgefragten Hektometer-Bereichs (teilweise oder vollständig) überschneidet, trifft dies für die Reichweite der Nachrichten 5 und 6 nicht zu; daher werden die Nachrichten 1 bis 4 als Antwort übermittelt, 5 und 6 jedoch nicht.

Die technische Voraussetzung dafür, dass sich eine Nachricht mit einem Intervall [A, B] schneidet, lautet: Der Anfangs-Hektometer der Nachricht ist ≤ B und ihr End-Hektometer ist ≥ A.

Kombination: Mehrere IDs-Elemente in Anfragen

Gültige Suchanfrage mit mehreren IDs-Elementen

Werden in einer Anfrage mehrere IDs-Elemente kombiniert, werden die entsprechenden Nachrichten zusammengeschlossen. Sämtliche IDs-Elemente werden einzeln behandelt und eine Nachricht wird wiedergegeben, wenn sie mindestens einem dieser Elemente entspricht. Daher würden in dem gezeigten Beispiel folgende Nachrichten wiedergegeben

9.4.   NtS-Nachrichtenservice (Spezifikation für die Umsetzung)

Dieses Kapitel enthält die Spezifikation für die Umsetzung des NtS-Nachrichtenservice, sie leitet sich aus den Überlegungen und Auswahlmöglichkeiten der vorhergehenden Kapitel ab.

Der NtS-Nachrichtenservice stellt in den NtS vier Nachrichtentypen bereit:

Mit der Umsetzung des NtS-Nachrichtenservice können alle Nachrichtentypen oder nur eine Auswahl daraus unterstützt werden. Die Bereitstellung mehrerer, einander ergänzender Dienste für einen bestimmten Nachrichtentyp durch einen teilnehmenden Mitgliedstaat ist zulässig.

9.4.1.   Anfrage

Zur Erzielung maximaler Robustheit des Dienstes bei möglichst geringer Komplexität wird für den NtS Web Service keine zusätzliche Sprache für Anfragen verwendet. Stattdessen werden die von WSDL bereitgestellten Konstrukte angewendet. Die Spezifikation der jeweiligen Operationen mit ihren Parametern erfolgt vollständig in der WSDL-Spezifikation. Im Fall des NtS-Nachrichtenservice wird eine einzige Operation definiert.

Die für den Betreff spezifischen Filterkriterien werden dem NtS-Standard entnommen, aber hinsichtlich der Multiplizität der Parameter erweitert.

Der Dienst gibt als Antwort nur Nachrichten wieder, die den angegebenen Kriterien entsprechen.

Seitenabrufmechanismus

Zur Steuerung der Datenmenge unterstützt die Anwendung einen Seitenabrufmechanismus Der Parameter für Seitenabrufe wird durch einen komplexen Parametertyp mit folgenden Elementen definiert:

Der komplexe Seitenabrufparameter ist optional; ist er jedoch vorhanden, müssen alle enthaltenen Elemente angegeben werden. Der Seitenabrufmechanismus funktioniert dann wie folgt:

Die Gesamtzahl der Nachrichten überschreitet den Wert des Parameters limit nicht, mit der Ausnahme, dass der Wert „0“„kein Limit“ bedeutet. In der Antwort werden so viele Nachrichten übersprungen, wie im Parameter offset definiert wurden. Zur Bereitstellung dieses Mechanismus muss der Dienst eine vorübergehend stabile (ansonsten aber beliebige) Sequenz der Nachrichten beobachten, z. B. zwischen zwei Aktualisierungen von Nachrichtendaten zum Basisdatensatz des web service. Das heißt, dass zwei aufeinanderfolgende, identische Abrufe die gleichen Nachrichten in der gleichen Reihenfolge ergeben müssen. Der Parameter totalcCount bestimmt, ob in der Antwort die Gesamtzahl der den betreff-spezifischen Kriterien entsprechenden Nachrichten übermittelt werden soll. Gewöhnlich sollte es ausreichen, diese Information mit der ersten Antwort anzufordern, sie aber in allen folgenden Antworten wegzulassen. Dies sollte zu einer besseren Leistung des web service führen.

Der Seitenabrufmechanismus bietet ein Mittel, Nachrichten „seitenweise“ nacheinander abzufragen. Damit der Seitenabrufmechanismus ordnungsgemäß funktionieren kann, müssen in jedem Abruf die gleichen betreff-spezifischen Parameter übermittelt werden.

9.4.2.   Antwort

Bei einer erfolgreichen Anfrage enthält die Antwort des NtS Web Service diejenigen NtS-Nachrichten, die den Anfrageparametern entsprechen. Die NtS-Nachrichten müssen mit dem NtS-Schema konform sein und können anhand dieses Schemas validiert werden. Da der Nachrichtentyp ein obligatorischer Parameter für Anfragen ist, kann jede Antwort nur NtS-Nachrichten enthalten, die dem angegebenen Nachrichtentyp entsprechen; also FTM, WRM, ICEM bzw. WERM.

Entdeckt der Webdienst bei der Verarbeitung der Anfrage Fehler, kann er als Antwort eine beliebige Anzahl an Fehlermeldungen senden, wobei er die im folgenden Unterkapitel aufgeführten Fehlercodes verwendet.

Eine Antwort eines NtS Web Service kann gleichzeitig NtS-Nachrichten und Fehlermeldungen enthalten.

Optionale Seitenabrufinformationen werden nur wiedergegeben, wenn die Anfrage Seitenabrufparameter enthielt. In einem solchen Fall sind der Versatz (Offset) und die Zahl der enthaltenen Nachrichten obligatorisch, während die Gesamtzahl (total count) nur vorhanden sein muss, wenn sie angefragt wurde.

Hinweis: Es wird davon ausgegangen, dass die Kommunikation zwischen dem web service und dem Nutzer technisch stabil eingerichtet ist, d. h., der Webdienst empfängt die Anfrage und der Nutzer die entsprechende Antwort. Technische Fehler wie der Ausfall der Internetverbindung oder die Unzugänglichkeit des web service aufgrund von Wartungsarbeiten oder Zusammenbruch werden hier nicht berücksichtigt. An dieser Stelle werden nur Fehlersituationen berücksichtigt, die aus dem Blickwinkel des Nutzers „hinter“ der Ebene des web service eintreten.

Fehlermeldungen

Die Fehlercodes für erwartete Fehlersituationen sowie die Erklärungen dazu sind der folgenden Tabelle zu entnehmen. Die Antworten enthalten nur den Fehlercode, dies ist das übliche Verfahren im XML-Schema der NtS.

Fehlercodes für den NtS-Nachrichtenservice

9.5.   Erstellung von Diensten und Kunden

Wird der Ansatz „der Vertrag zuerst“ konsequent beachtet, d. h., werden ein Vertrag oder mehrere Verträge mit vollständigen Beschreibungen der Schnittstellen in Form von WSDL-Dokumenten angegeben, kann die Umsetzung des Dienstes bzw. der Dienste sowie die Implementierung eines entsprechenden Kunden mittels geeigneter Software-Tools automatisch erfolgen. Im Idealfall müssen am erzeugten Quellcode keine manuellen Änderungen vorgenommen werden.

In den meisten Fällen sind jedoch mehrere Durchläufe erforderlich, bis die WSDL-Spezifikation die genauen Anforderungen eines solchen Tools erfüllt. Gewöhnlich stellt das Tool individuelle Anforderungen an die Verwendung des WSDL-Standards, damit es reibungslos funktionieren kann. Daraus folgt, dass Änderungen an der WSDL-Spezifikation erforderlich sein können, obgleich die WSDL-Spezifikation zunächst eine nach dem WSDL-Standard gültige Spezifikation war. Wird die WSDL-Spezifikation des web service nach der Generierung des Dienstes oder Kunden geändert, kann je nach den vorgenommenen Änderungen ein neuer Generierungsvorgang erforderlich sein.

Glossar

(1)  Die Beschreibung wurde (auf Englisch) aus der WS-I Website http://www.ws-i.org zitiert.

Anlage C