
Transcription
PFG 2015 / 4, 0313 – 0329Stuttgart, August 2015ReportEvaluierung und Monitoring von Dienstqualität (Qualityof Service) dargestellt am Beispiel der MarinenDateninfrastruktur Deutschland (MDI-DE)CHRISTIAN SEIP, RostockKeywords: spatial web services, INSPIRE, evaluation, monitoring, service qualityZusammenfassung: Service-orientierte Architekturen (SOA) sind heute weit verbreitet. Deutschlandentwickelte eine marinespezifische Service-orientierte Dateninfrastruktur (MDI-DE, Marine Dateninfrastruktur Deutschland) von 2010 bis 2013.Die Dienste in der MDI-DE tragen zur Erfüllungvon Berichtspflichten für verschiedene europäischeund nationale Regularien bei. Die Dienste derMDI-DE ebenso wie andere Dienste, die z. B. vonINSPIRE betroffen sind, müssen spezifische Anforderungen an Performanz, Verfügbarkeit undKonformität (Quality of Service, QoS) erfüllen.Obwohl SOA ein wichtiger Bereich in der Forschung ist, gibt es nur sehr wenige Publikationenund Studien über QoS, insbesondere hinsichtlichder INSPIRE-Anforderungen.Die Dienste der MDI-DE wurden mit verschiedenen Tools analysiert. Die Analyse erstreckte sichauf die Kontrolle der Qualität von Konformität undLeistung (Performanz). Aufgrund teils widersprüchlicher Ergebnisse und einiger Unzulänglichkeiten der unterschiedlichen Werkzeuge kann vereinfacht festgestellt werden, dass je mehr Werkzeuge verwandt werden, desto aussagekräftiger dasErgebnis ist. Die Servicequalitäten waren nichtkohärent, wenn sie mit verschiedenen Werkzeugengemessen wurden. Die Studie zeigt, dass für dasErreichen objektiver und nachvollziehbarer Messungen von QoS-Parametern als Teil von INSPIREnoch einige Herausforderungen bestehen.Summary: Evaluation and Monitoring of ServiceQuality illustrated by the Example of the GermanMarine Spatial Data Infrastructure (MDI-DE).Service oriented architectures (SOA) are widelyused nowadays. As the name implies such architectures rely on services. Germany developed a marine specific service oriented data infrastructure(MDI-DE, Marine Dateninfrastruktur Deutschland) from 2010 to 2013. The services in MDI-DEcan contribute to fulfilling reporting commitmentsfor various European and national legislation. Theservices of MDI-DE (just like other services affected, for instance, by INSPIRE) have to meet specific requirements regarding performance, availability and conformity (quality of service, QoS).Although SOA is an important field in scientificresearch there are only very few publications andstudies available on QoS, especially regardingINSPIRE requirements.The services of MDI-DE were analysed regardingtheir QoS using various existing tools. The paperdiscusses the tools' usefulness to reflect whether theservices performance or conformity need improvement. Due to partly contradicting results and thefailure of some tools concerning specific aspects, itcan at least be stated that the more tools are appliedthe more conclusive the outcome. Furthermore, theservice quality results were not coherent whenmeasured with different tools. The study indicatesthat achieving objective and comparable measurements of QoS parameters as part of the INSPIREimplementation will still be challenging.1Gange. Um hingegen Fachdaten aus dem Küsten- und Meeresbereich für Wissenschaft, Planung, Öffentlichkeit, Politik und Verwaltunggemäß den Anforderungen an eine integrierteeuropäische Meerespolitik bereitzustellen, istEinführungDer Aufbau von regional begrenzten Geodateninfrastrukturen (GDI) wie die des Bundes,der Länder oder der Landkreise ist im vollen 2015 E. Schweizerbart'sche Verlagsbuchhandlung, Stuttgart, GermanyDOI: /15/0272 4.25
314Photogrammetrie Fernerkundung Geoinformation 4/2015es notwendig, thematisch begrenzte GDI Regionen übergreifend aufzubauen. Das BMBFförderte von 2010 bis 2013 den Aufbau einersolchen marinen Dateninfrastruktur (MDI)mit dem Projekt MDI-DE. Das Ziel der MDIDE war es, sowohl vorhandene technischeLösungen wie das Nordsee-Ostsee-Küsteninformationssystem (NOKIS) und die Geodateninfrastruktur des Bundesamtes für Seeschifffahrt und Hydrographie (GDI-BSH) alsGrundstock zu integrieren, als auch Informationen aus allen Bereichen des Küsteningenieurwesens und Küstengewässerschutzes, des Meeresumweltschutzes, des marinenNaturschutzes, der Raumordnung und derKüstenforschung zusammenzuführen.Eine GDI wie die MDI-DE besteht aus einerVielzahl von verteilten Diensten und ist somitvon deren Verfügbarkeit, Leistung und Einhaltung von Normen und Standards abhängig.Die MDI-DE-Umgebung ist insofern ein gutes Testbeispiel zur Prüfung von Dienstqualitäten. Nicht verfügbare Dienste sind negativfür alle aufsetzenden Anwendungen in einerGDI, z. B. Portale, und hinderlich für die Nutzer. Aber auch wenn Dienste verfügbar sind,ist ihre Leistung für eine zufriedenstellendeNutzung sowie die Einhaltung von regulatorischen Anforderungen, z. B. INSPIRE, vonentscheidender Bedeutung. Darüber hinausmüssen Dienste-Anfragen und Dienste-Antworten abgestimmten Anforderungen genügen, um sicherzustellen, dass beispielsweiseein Dienst in das lokale GIS eines Anwendersintegriert werden kann. Daher ist Konformitätein weiterer wichtiger Faktor, der betrachtetwerden sollte und Grundlage für Interoperabilität ist. LUPP (2008) unterstreicht, dass Standardisierung von Diensten Interoperabilitätermögliche.Interoperabilität wiederum lässt sich unter anderem in die zwei Hauptbereiche organisatorische und technische Interoperabilitätunterteilen. Innerhalb der technischen Interoperabilität werden die beiden Merkmale semantische und syntaktische Interoperabilität unterschieden (RÜH 2014). Im Kontext derEU Direktive INSPIRE werden die Ebenender Interoperabilität weitergehend definiert.Das European Interoperability Framework(EIF) definiert vier Ebenen der Interoperabilität (JAKOBSSON 2012): rechtlich, organisato-risch, semantisch und technisch. In Bezug aufKonformität hinsichtlich INSPIRE gilt, dassKonformität mit INSPIRE auf der einen SeiteKonformität mit dessen Daten- bzw. Metadaten-Spezifikationen und auf der anderen Seitedie Übereinstimmung mit den Spezifikationenbezüglich der Servicequalität bedeutet.1.1 Quality of ServiceDie Evaluierung von Diensten lässt sich inzwei Kategorien einteilen: Performanz undVerfügbarkeit auf der einen Seite und Konformität auf der anderen Seite mit vielen Teilaspekten auf beiden Seiten. Diese Kategorienwerden für die fünf verschiedenen INSPIREDiensttypen Discovery, View, Download,Transformation und Invoke Spatial Data Services (INSPIRE 2007) konkretisiert.Dienstqualität (Quality of Service, QoS)wird durch PARASURAMAN et al. (1985) alsDiskrepanz zwischen den Erwartungen derKonsumenten und den tatsächlich für einenDienst festgelegten Spezifikationen definiert.Ist die Spezifikation nutzerorientiert, sollteder Dienst den Erwartungen des Nutzers entsprechen, also das, was er erwartet, sollte mitdem, was er wahrnimmt, übereinstimmen.Obwohl diese Definition aus dem Marketingbereich stammt, gilt sie auch für Web-Dienste(und wahrscheinlich viele andere Diensttypen). FRANKEN (1996) unterstreicht mit einemtechnischen Hintergrund dies durch seine Definition von Dienstqualität als vom Benutzerwahrgenommene Performanz. Dadurch stellter Performanz bzw. Leistung auf die gleicheEbene wie QoS und setzt diese beiden Begriffe praktisch gleich. INSPIRE (2007) setzt QoSzunächst auch mit Performanz gleich, indemnach Artikel 16 die Durchführungsbestimmungen unter anderem Mindestleistungskriterien für Dienste festlegen. Wie jedoch bereits erwähnt, ist im technischen Sinne diePerformanz nur ein Aspekt der Dienstqualität.Ein Nutzer erwartet zuerst, dass ein Dienstverfügbar ist und genutzt werden kann. EineAnalyse zur Auffindbarkeit von WMS überGoogle ergab eine Nichtauffindbarkeit von30% (MÜLLER & MANDERY 2010). Ein weiteres Qualitätsmerkmal eines Dienstes sowie einer GDI ist Performanz bzw. Leistung, weshalb dies auch eine INSPIRE-Anforderung
Christian Seip, Evaluierung und Monitoring von Dienstqualitätist. YANG & EVANS (2008) prägten den Begriff„Network GIS Performance“ (NGP), der sowohl die effiziente Nutzung von NetzwerkGIS-Ressourcen als auch die Geschwindigkeiteines Netzwerk-GIS umfasst. INSPIRE beschreibt Performanz als Geschwindigkeit, mitder eine Anfrage an einen Dienst abgeschlossen werden kann (INSPIRE CONSOLIDATIONTEAM 2007). YANG & EVANS (2008) sagen, dassein durchschnittlicher Benutzer ca. 8 Sekunden auf eine Web-Antwort zu warten bereit ist(8-Sekunden-Regel). Nach MÜLLER & MANDERY (2010) sind 86% der verfügbaren Dienstein der Lage, die Grafiken mit einer Auflösungvon 400 x 400 Pixeln in weniger als einer Sekunde zu liefern. Allerdings ist eine Performanz-Messung nur sinnvoll, wenn sie übereinen längeren Zeitraum durchgeführt wird(MÜLLER & MANDERY 2010).CIBULKA (2013) und das INSPIRE CONSOLIDATION TEAM (2007) erwähnen darüber hinausInteroperabilität als Attribut für Dienstqualität. Ein interoperabler Dienst kann mit denanderen Diensten zusammenarbeiten, die diegleichen Normen und Standards einhalten.Somit ist die Konformität der zweite Hauptbereich für die Dienstevaluierung.CIBULKA (2013) listet eine Vielzahl weitererAttribute auf, die Leistung beeinflussen: Zuverlässigkeit*: Fähigkeit eines Service,eine bestimmte Qualität einzuhalten. Skalierbarkeit: Fähigkeit eines Systems, dieRechenkapazität nach aktuellen Anforderungen zu erhöhen. Kapazität*: Obergrenze der Anzahl vongleichzeitigen Anfragen mit einer garantierten Performanz. Genauigkeit: Vom Dienst generierte Fehlerrate. Zugänglichkeit*: Fähigkeit eines Dienstes,der Anfrage eines Clients nachzukommen.Mit einem Stern sind Attribute gekennzeichnet, die als Mindestleistungskriterien für dieINSPIRE Network Services verwendet werden (INSPIRE CONSOLIDATION TEAM 2007).1.2 Messung von QoS-ParameternZur Messung von QoS-Parametern, speziellder relevanten Kriterien Performanz, Verfügbarkeit und Konformität, finden sich einige315Ansätze. CIBULKA (2013) entwickelte ein eigenes Werkzeug für seine Messungen.GIULIANI et al. (2013) verwendeten JMeterSkripte, die vom FOSS4GWMS (Grid-enabled Web Map Service) Benchmark im Jahr2009 stammten und ausgebaut und angepasstwurden (AIME & MCK ENNA 2009). Allerdingsspiegelt dies nur die Messungen von einemeinzigen Werkzeug (JMeter) wider, so dasses keinen Vergleich gibt, der die Genauigkeitder Ergebnisse überprüft. Das gleiche gilt fürHORÁK et al. (2009), die ausschließlich WAPT(Web Application Load, Stress and Performance Testing) von Softlogica LLC für ihreMessungen verwendeten. Im Zusammenhangmit INSPIRE weist DRERUP (2010) jedoch darauf hin, dass WAPT nicht nutzbar ist, umdie INSPIRE-Anforderungen zu erfüllen, daes nicht in der Lage sei, die Zeit zum Download einzeln zu messen. Es kann nur die Gesamtantwortzeit messen, die auch die Zeitbeinhaltet, die der Server braucht, um eineAnfrage zu bearbeiten. INSPIRE verlangt jedoch, dass jede Zeitspanne separat gemessenwird.Obwohl sich zahlreiche Arbeiten zu SOAfinden, stellen GIULIANI et al. (2013) in Bezugauf Servicequalität fest, dass trotz der Wichtigkeit wenig Forschung zu diesem Themaveröffentlicht worden sei.HECKEL & MARIANI (2005) schlugen vor,dass ein Suchdienst nur andere Dienste registriert bzw. aufnimmt, wenn diese einenKonformitäts-Test bestehen. Aber dieser Vorschlag bezieht sich nur auf Suchdienste undKonformität und somit nicht auf Verfügbarkeit und Performanz. BOZKURT et al. (2010)zeigen neun verschiedene Funktionstesttechniken und -ansätze, um Web-Dienste zu testen. Diese Techniken und Ansätze zielen jedoch generell auf Web-Dienste ab und nichtspeziell auf Dienste einer GDI.2Evaluierung und TestwerkzeugeBei der Evaluierung stellen Testwerkzeuge eine Anfrage an einen Dienst und messen dann entweder die Zeit bis zur Antwort(Performanz) oder überprüfen, ob die Antwort bestimmten Vorgaben entspricht (Konformität). Insbesondere bei der Leistung gibt
316Photogrammetrie Fernerkundung Geoinformation 4/2015es jedoch einiges zu beachten. Beispielsweise können zeitgleiche Anfragen anderer Nutzer die Antwortzeit beeinflussen. Aus diesemGrund beschäftigt sich zunächst Abschnitt 2.1mit solchen Überlegungen. Das dieser Studiezugrunde liegende Test-Setup wird zu Beginnvon Abschnitt 3 beschrieben.In Abschnitt 2.2 werden Werkzeuge vorgestellt, die Konformität und/oder Leistung undVerfügbarkeit überprüfen. Dabei wird hauptsächlich freie Software (Free and Open-Source-Software, FOSS) beschrieben. Eine Ausnahme bildet der serviceMonitor, der in dersdi.suite enthalten ist, die im MDI-DE-Projektverwendet wird. Nach FRØLUND & KOISTINEN(1998) erwartet der Benutzer vor allem einenDienst, der verfügbar ist und schnell Daten liefert. Abschnitt 2.2.2 stellt Testwerkzeuge zurÜberwachung der Leistung und Verfügbarkeit und Abschnitt 2.2.1 einen Überblick überWerkzeuge zur Überprüfung der Konformitätals Grundlage der Interoperabilität vor. Einesder Werkzeuge, die GDI-DE Testsuite, erlaubtden Test beider Eigenschaften und wird separat in Abschnitt 2.2.3 vorgestellt.2.1 Vorüberlegungen und möglicheMessproblemeGemäß Abschnitt 1.1 sind unter anderem Performanz und Verfügbarkeit Merkmale für dieDienstqualität. CIBULKA (2013) weist daraufhin, dass diese Eigenschaften von der Anzahlder Benutzer, der Art der Operation (GetMap,GetCapabilities, GetFeature etc.), dem Volumen der verarbeiteten Daten, und einer Reihe von anderen Parametern (Hardware, Software, Netzwerk, etc.) abhängig sind. Darausergeben sich einige Fragen an die Messungen:1) Wo wird gemessen?2) Welcher Anfragetyp wird verwendet, z. B.GetMap?3) Wie groß ist das Datenvolumen der Antwort?4) Unter welchen Umständen wird gemessen,z. B. Tageszeit?5) Welche Eigenschaften hat der Server, z. B.bezüglich Netzanbindung?6) Welche Eigenschaften hat der Rechner, vondem aus getestet wird, z. B. Hardware?Die INSPIRE-Anforderungen an Performanz und Verfügbarkeit wurden unter anderem im INSPIRE NETWORK SERVICES DRAFTINGTEAM (2013) definiert. Für eine 470 KB großeGrafik sollte die Reaktionszeit bis zur initialen Antwort auf eine GetMap-Anfrage an einen Darstellungsdienst maximal 5 Sekundenin einer normalen Situation betragen, d. h. einem Zeitraum außerhalb der Spitzenlast, alsoin 90% der Gesamtzeit. Damit legt INSPIREfür die Fragen 1) bis 3) konkrete Anforderungen fest.Hinsichtlich Frage 1) muss sich das Testwerkzeug für INSPIRE-Konformität auf demzu testenden Server installieren lassen. Abgesehen von MapMatters und serviceMonitor istdies bei allen vorgestellten Werkzeugen möglich.Für die Frage 2) legt INSPIRE eine GetMap-Anfrage fest. Zwei der verwendetenWerkzeuge, nämlich die GDI-DE Testsuiteund der serviceMonitor, bieten die Möglichkeit, eine Anfrage selbst zu formulieren. DerService Status Checker (SSC) bietet eine solche Möglichkeit nicht und erzeugt selbst einenicht veränderbare GetMap-Anfrage.Zum Datenvolumen (Frage 4) hat CIBULKA(2013) festgestellt, dass die Performanz auchvom Kartenmaßstab sowie von der Lage abhängt. Dies bedeutet, dass das Anfragen vonInformationen mit wenigen Daten, z. B. einigewenige Punkte statt vieler komplexer Polygone, zu geringeren Reaktionszeiten führt. Mitetwas Aufwand wäre es möglich, dieses Verhalten von räumlichen Webdiensten mit demserviceMonitor und mit der GDI-DE Testsuitezu untersuchen und somit die Aussage vonCIBULKA (2013) zu überprüfen. Beide Werkzeuge ermöglichen es, mehrere Tests auf einem Dienst mit unterschiedlichen Anfragenanzuwenden. So können verschiedene Maßstäbe und Raumausschnitte verwendet werden, um den Dienst zu testen. MapMattersund der SSC sind dazu nicht in der Lage, daAnfragen nicht vom Benutzer definiert werden können.Die Anzahl der Benutzer beeinflusst dieDienstqualität, da Nutzer Last auf einem Server erzeugen. Die Anzahl der Benutzer variiert mit der Tageszeit, wie DRERUP (2010)ausführt (Frage 4). Auch die Verfügbarkeitist zeitabhängig, zum Beispiel eingeschränkt
Christian Seip, Evaluierung und Monitoring von Dienstqualitätvon typischerweise nachts durchgeführtenWartungsarbeiten. Während der Zeitpunktder Messungen von keinem der Werkzeugespezifiziert werden kann, gibt es Werkzeuge,die messen und auch Last erzeugen können(2.2.2).Die Fragen 5 und 6 haben zwar sicherlichden größten Einfluss auf die Leistung, könnenaber beim Messen nicht beeinflusst werdenund müssen daher als gegebene Größen angesehen werden, die es zu dokumentieren gilt.2.2 TestwerkzeugeAbschnitt 2.2.1 gibt eine Übersicht zu Werkzeugen zur Überprüfung der Konformität. Abschnitt 2.2.2 stellt Testwerkzeuge zurÜberwachung der Leistung und Verfügbarkeitvor. Das Testwerkzeug, das beide Parametertesten kann, wird in Abschnitt 2.2.3 erläutert(GDI-DE Testsuite).2.2.1 Überprüfung der KonformitätDas Open Geospatial Consortium (OGC) bietet eine Testumgebung zur Kontrolle von Software auf Konformität mit OGC-Spezifikationen (Compliance and Interoperability TestingInitiative, CITE) (TEAMENGINE 2015).Während der Neogeo WMS INSPIRE-Tester(NEOGEO 2015) sich nur auf INSPIRE-Darstellungsdienste konzentriert, bietet der offizielle INSPIRE Geoportal Metadata Validator(EUROPEAN COMMISSION 2013) Tests für Metadaten, Suchdienste und Download-Dienste.2.2.2 Überwachung der Leistung undVerfügbarkeitMapMatters (MAPMATTERS 2015) ist ein vongeOps entwickeltes Portal, dessen Hauptaufgabe die Katalogisierung von Kartendiensten (WMS) ist. Es bietet dafür eine Textsuchesowie eine Suche nach deren geographischerAusdehnung. MapMatters verwendet sowohlRobots als auch Benutzereingaben, um dieDatenbank mit Kartendiensten zu füllen. Zusätzlich wird eine Monitoring-Komponentezur Aufzeichnung der Verfügbarkeit und derAntwortzeiten angeboten.317Der serviceMonitor von con terra überwacht verschiedene Dienstarten wie WMS,Web Feature Service (WFS), Web CoverageService (WCS) sowie ArcIMS und ArcGISund INSPIRE Network Services. Die Zeitintervalle sowie die Schwellenwerte in Bezugauf Verfügbarkeit und Performanz, die nichtunterschritten werden sollen, können konfiguriert werden. Wenn ein Dienst unter die vorgeschriebenen Qualitätsanforderungen fällt,kann ein Alarm per E-Mail oder SMS ausgelöst werden. Für INSPIRE-Netzwerkdienstesind die INSPIRE Quality-of-Service-Parameter bereits vorkonfiguriert. Außerdem können Daten über die Verfügbarkeit und Performanz der Dienste als Berichte mit Diagrammen oder Statistiken angezeigt und im MSExcel-Format exportiert werden.Die Ziele des SSC vom US-amerikanischenFederal Geographic Data Committee (FGDC)werden von ANTHONY & NEBERT (2012) wiefolgt zusammenfasst: Überwachung und Bewertung räumlicherWeb-Dienste, Benachrichtigung der Besitzer bei Problemen mit Diensten, Entdeckung von Performanz-Problemen, Ermittlung von Funktionsstörungen und Austausch von Testergebnissen.Listen mit Diensten können von Katalogenoder von einem registrierten Benutzer überAtom-Feeds bereitgestellt werden. Danachkönnen die Dienste dann in einem bestimmtenZeitintervall geprüft (zweimal pro Tag) unddie Ergebnisse in einer Datenbank archiviertwerden. Die Ergebnisse sind über einen WebDienst, über eine API mit GET-Anfragen, dieAusgaben im JSON-Format erzeugt, und überHTML-Service-Berichte verfügbar.Das INSPIRE CONSOLIDATION TEAM (2007)definiert Kapazität als die Grenze der Anzahlvon gleichzeitigen Anfragen, die mit garantierter Leistung zur Verfügung gestellt werden können. Das bedeutet, dass es eine starke Korrelation zwischen der Performanz undder Menge an gleichzeitigen Benutzern, alsoAnfragen, gibt. BARANSKI et al. (2011) zeigten,dass ihr Server-Aufbau höchstens fünf gleichzeitige Anfragen erlaubte, um der INSPIREAnforderung einer Reaktionszeit von wenigerals fünf Sekunden zu entsprechen (3.1). Lei-
318Photogrammetrie Fernerkundung Geoinformation 4/2015der ist keines der bisher dargestellten Werkzeuge in der Lage, eine bestimmte Anzahl vongleichzeitigen Anfragen zu simulieren.Die Website SoftwareQATest.com von R ICKHOWER beschäftigt sich mit Qualitätssicherung und Tests. Sie listet 66 Werkzeuge in derKategorie Load and Performance Test Tool,von denen Proxy Sniffer, WAPT (Web Application Load Stress und Leistungstests), ApacheJMeter und ApacheBench Beispiele sind, diebereits auf räumliche Web-Dienste angewandtwurden. Auch wenn es eine Vielzahl solcherLast-Tools für spezielle Anforderungen wiedas in BARANSKI et al. (2011) vorgestellte Hybrid Cloud-Konzept gibt, sind weitere Anpassungen oder neue Implementierungen für denEinsatz in GDI erforderlich.2.2.3 Die GDI-DE TestsuiteDie GDI-DE ist die nationale Geodateninfrastruktur Deutschlands. Eine ihrer Komponenten ist die GDI-DE Testsuite (TESTSUITE 2015),die von der Koordinierungsstelle GDI-DEbeim Bundesamt für Kartographie und Geodäsie (BKG) in Abstimmung mit dem Lenkungsausschuss GDI-DE zwischen Ende desJahres 2010 und Mitte 2011 entwickelt wurde.Die Testsuite kann als Online-Web-Anwendung oder über eine API genutzt werden oderlokal installiert und verwendet werden. HO-GREBE (2012) fasst die Ziele der GDI-DE Testsuite wie folgt zusammen: Unterstützung der Interoperabilität innerhalb der GDI-DE (gemeinsames Werkzeug). Unterstützung des Umsetzungsprozessesder GDI-DE und INSPIRE (gemeinsamesVerständnis der einschlägigen Normen undSpezifikationen). Unterstützung des INSPIRE Monitoring(Konformitätsindikatoren)3Evaluierung der MDI-DEDiensteDieser Abschnitt analysiert die im MDI-DEPortal verfügbaren Dienste hinsichtlich ihrerPerformanz (3.2) und Konformität (3.1). Allein Abschnitt 2 vorgestellten Werkzeuge wurden mit Ausnahme von MapMatters (keineDienstleistungsstatistiken) benutzt. Die meisten Werkzeuge wurden von ihren Herstellerngehostet. Eine Ausnahme bildete der serviceMonitor der sdi.suite, der auf einem Serverbeim BSH gehostet wurde. Damit musste beiden anderen Servern gegen die INSPIRE-Anforderung verstoßen werden, auf dem Serverselbst zu messen. Jedoch war dies nicht möglich, da ein Zugriff auf die Server nicht möglich war. Allerdings entsprechen diese TestsAbb. 1: Für Überwachung und Testen genutzte MDI-DE-Infrastrukturknoten.
Christian Seip, Evaluierung und Monitoring von Dienstqualitätdamit eher der Nutzersicht: Es interessiert weniger, wie schnell ein Dienst auf dem Serverreagiert, sondern eher wie schnell eine Antwort beim Nutzer eintrifft.Last-Tools wurden nicht verwandt. Zum einen ist nicht bekannt, wie viele Benutzer den/die Dienst/e gerade während eines Testlaufsbenutzen. Bei der Erzeugung gleichzeitigerAnfragen kann daher nicht bestimmt werden, wie groß die Gesamtsumme aller gleichzeitigen Anfragen ist. Zum anderen bedeutetkünstlich erzeugte Last und erhöhte Bandbreite ggf. höhere Kosten für die beteiligtenInstitutionen. Der Testaufbau (Abb. 1) beinhaltet acht Institutionen und deren Infrastrukturknoten mit neun Serverinstanzen unddrei verschiedenen Arten von Karten-ServerSoftware. Insgesamt bieten sie 27 Dienste mit882 Layern, von einem bis zu 397 Layern proDienst. Von den 27 Diensten sind 23 WMSund vier WFS. Die verwendeten WMS-Versionen waren annähernd gleich verteilt: elfmit der Version 1.3.0 und zwölf mit Version1.1.1. Von den WFS nutzen drei die Version2.0.0 und einer die Version 1.0.0.Die GetMap-Anfragen wurden von derGDI-DE Testsuite generiert. Diese wurdenauch für den serviceMonitor genutzt, so dassbeide die gleichen Anfragen nutzen und somit vergleichbar sind. Zusätzlich wurden GetCapabilities-Anfragen verwandt, um in der319Lage zu sein, die Anfragetypen zu vergleichen. Leider bietet SSC eine solche Möglichkeit nicht, denn es erzeugt, wie oben erwähnt,selbst eine GetMap-Anfrage, die nicht verändert werden kann.Über weitere die Messung beeinflussendeCharakteristika, z. B. Netzanbindungen unddie unterschiedlichen Latenzen und Hardwareder Server, ist nichts bekannt.3.1 Konformität mit INSPIRE undOGCDetaillierte Fehleranalysen für jeden Dienstund jedes Werkzeug sind aufgrund des Umfanges der Dienste nicht möglich. Daher werden in diesem Abschnitt nur Zusammenfassungen für die Konformität mit den Spezifikationen des OGC (3.1.1) und von INSPIRE(3.1.2) vorgestellt.3.1.1OGCDie OGC TEAM Engine produzierte mehrere falsch-negative Ergebnisse, die die Anzahlder tatsächlichen Fehler beeinflussten. Dienste bestanden die Tests auf vorgeschriebeneAusgaben bei Exceptions nicht, obwohl einemanuelle Analyse ergab, dass die Ausgabenden Anforderungen entsprachen.Tab. 1: Vergleich der Fehlermeldungen: OGC TEAM Engine und GDI-DE Testsuite.NoErrorTEAM EngineTestsuite01Wrong format when exception is raised -02GetFeatureInfo request to non-queryable services -03GetMap request with TRANSPARENT TRUE and „empty”bounding box -04Use of exponential notation values for the bounding box -05LegendGraphic is not exactly pixels20 x 20100 x 51206Invalid response when requesting a layer with a certain CRS- 07Invalid response when requesting a layer with the LAYERSparameter set to a specific layer- 08No service exception when requesting a layer with the CRSparameter set to an invalid CRS- 09MIME type of the response matches the format image/png whenthe FORMAT parameter is set to image/png- 10
Photogrammetrie Fernerkundung Geoinformation 4/2015320Für beide Testwerkzeuge (OGC TEAM Engine und die GDI-DE Testsuite) müssen dieErgebnisse relativiert werden, weil die Anzahl der Tests, die ein Dienst zu durchlaufenhat, stark variiert (55 bis 625 Tests pro Dienst;i.d.R. abhängig von der Anzahl der angebotenen Layer). Die Anzahl der fehlgeschlagenen Tests, also die Anzahl der Fehlermeldungen, dass etwas nicht konform zur Spezifikation ist, ist eine zentrale Aussage über einen Dienst, hilft in diesem Fall aber nicht dieDienste zu vergleichen. Denn diese Anzahlwird wesentlich durch die Anzahl der Layereines Dienstes beeinflusst. In Verbindung mitkleineren Fehlern wie „die Legendengrafikmisst nicht genau 20 20 Pixel“ (größere Legendengrafiken waren eine Anforderung imMDI-DE-Projekt) führt dies bei vielen Layernzu einer großen Anzahl von Fehlermeldungen. Somit ist die Aussagekraft der Ergebnisse recht klein und eine Prüfung des Einzelfallsfür jeden Dienst erforderlich. Interessanterweise haben die Ergebnisse der OGC TEAMEngine und der GDI-DE Testsuite nur einenFehler gemeinsam, wie Tab. 1 zeigt. Dies bedeutet, dass beide Werkzeuge benötigt werden, um alle Fehler zu finden.3.1.2INSPIRETab. 2 zeigt, dass der Neogeo WMS INSPIRETester die wenigsten Fehler der drei INSPIREKonformitätstest-Tools fand. Der INSPIREGeoportal Metadata Validator findet fast soviele Fehler wie die GDI-DE Testsuite. DieGDI-DE Testsuite erkennt aber nicht nur mehrFehler, sondern beschreibt die Fehler auch detaillierter. Da leider nicht alle Dienste mit derGDI-DE Testsuite getestet werden können,kann nicht auf den INSPIRE Geoportal Metadata Validator verzichtet werden.Tab. 2: Vergleich der INSPIRE-Fehlermeldungen (N Neogeo WMS INSPIRE tester, I INSPIREGeoportal Metadata Validator, G GDI-DE Testsuite).NoErrorNIG01Unexpected value for AccessConstraints 02BoundingBox missing for some CRS - 03MetadataUrl not found in ExtendedCapabilities 04Fees element mandatory but not found -05DefaultLanguage, ResponseLanguage, . 06One or more layers failed the INSPIRE validation- 07Metadata element „Layers” is missing, empty or incomplete but it is required- 08Metadata element „Responsible Organisation” is missing, .- -09Metadata element „Temporal Reference” is missing, .- 10Metadata element „Resource Type” is missing, .- 11Metadata element „Metadata Point Of Contact” missing, .- 12Metadata element „Metadata Date” is missing, .- 13Metadata element „Metadata Language” is missing, .- 14Metadata element „Spatial Data Service Type” is missing, .- 15Metadata element „Mandatory Keyword” is missing, .- 16Metadata element „Resource Abstract” is missing, .- 17Not every layer supports EPSG:4326 and EPSG::4258-- 18Not every layer has an AuthorityURL and a correctly formatted identifier-- 19Service title for identification not specified-- 20A conformity statement with a result of conformance evaluation is not given--
Christian Seip, Evaluierung und Monitoring von Dienstqualität3.2 Performanz und VerfügbarkeitDie INSPIRE Anforderungen wurden zusammen mit weiteren zu beachtenden Aspektenbereits in Abschnitt 2 erläutert. Darauf aufbauend wurden die MDI-DE Dienste zunächstmit dem Service Status Checker (SSC, 3.2.1)getestet. Hierbei war es nur möglich, die 23WMS Dienste zu testen, da für WFS Dienste321nur Fehlermeldungen zurückgeliefert wurden.Jedoch gab es für drei der Dienste generellkeine Ergebnisse und für weitere drei keineErgebnisse für die Reaktionszeit. Anschließend folgt in Abschnitt 3.2.2 die Auswertung der Ergebnisse des serviceMonitors, dersowohl alle 23 WMS als auch alle vier WFSDienste untersuchen konnte. Mit der GDI-DETestsuite (3.2.3) können nur WMS Dienste ge-Abb. 2: Resultate für score (Punktzahl) (Service Status Checker).Abb. 3: Resultate für speed (Performanz, Reaktionszeit) (Service Status Checker).
322Photogrammetrie Fernerkundung Geoinformation 4/2015testet werden, wobei einer der 24 Dienste ausnicht nachvollziehbaren Gründen nicht getestet werden konnte.3.2.1 FGDC Service Status Checker(SSC)Der SSC gibt eine Punktzahl (score) und diePerformanz in Form der Reaktionszeit (speed)aus. Die Methode der Berechnung der Punktzahl (score) ist unklar, weil eine Anfrage beimFGDC unbeantwortet blieb. Abb. 2 und 3 zeigen die Ergebnisse jeweils für score und speedim Zeitraum Mitte August bis Anfang September 2013. Die Zeitspanne ist so kurz, weil dieAPI des FGDC SSC maximal 1.000 Datensätze zurückliefern kann. Abb. 2 zeigt, dass dieErgebnisse der Bewertungen in zwei Grup-Abb. 4: Resultate für speed (Performanz, Reaktionszeit) (sdi.suite serviceMonitor).Abb. 5: Resultate für Verfügbarkeit (sdi.suite serviceMonitor).
Christian Seip, Evaluierung und Monitoring von Dienstqualität323pen geteilt sind. Die eine Gruppe (elf Dienste)erreicht Werte über 95%, während die andere Gruppe (neun Dienste, mit Ausnahme der„NA“ (nicht verfügbaren) Dienste) Werte unter 50% erreichte. Abb. 3 zeigt auch, dass alleDienste die Anforderungen von INSPIRE erh
mance Testing) von Softlogica LLC fürihre Messungen verwendeten. Im Zusammenhang mit INSPIRE weistDRERUP (2010) jedoch da-rauf hin, dass WAPT nicht nutzbar ist, um die INSPIRE-Anforderungen zu erfüllen, da esnichtinderLagesei,dieZeitzumDown-load einzeln zu messen. Es kann nur die Ge-samtantwortzeit messen, die auch die Zeit