320 likes | 414 Views
Matthias Lendholt 6. Januar 2010. Geodaten prozessieren mit WPS (Web Processing Service). Geodatenprozessierung. Geodatenprozessierung. Warum auslagern? Performanzgewinn Hoher Ressourcenbedarf Parallelisierbarkeit Wiederverwendbarkeit Komplexitätsreduktion Übersichtlichere Architektur
E N D
Matthias Lendholt 6. Januar 2010 Geodaten prozessieren mit WPS (Web Processing Service)
Geodatenprozessierung Warum auslagern? • Performanzgewinn • Hoher Ressourcenbedarf • Parallelisierbarkeit • Wiederverwendbarkeit • Komplexitätsreduktion • Übersichtlichere Architektur • Stärkere Kohäsion • Höhere Kapselung • Losere Kopplung
Remote • Corba (†) • RPC • Web Services: SOAP • REST (direct HTTP) • Sprachspezifisch, z.B. Java RMI • WPS
WPS • OGC Standard • Spezifiziert für HTTP • SOAP optional • GeoDaten (XML) direkt in Prozessaufruf Typsicherheit! (jenseits von int und String) • Synchroner Aufruf • Rückgabewerte • Entweder direkt in Antwort • Oder als separater Download (URL)
WPS - Operationen • GetCapabilities Liste verfügbarer Prozesse • Describe Process Liste Eingabe- und Rückgabeparameter • Execute Operation
Anwendungsfall 1: Eigenen Prozess auslagern Anwendungsfall 2: Fremden WPS integrieren
AAIS (I) Projekt DEWS: Affected Area Identification Service (AAIS) +
AAIS (II) DEWS AWI-Simulation GUI Resource-Service AAIS
AAIS (III) DEWS AWI-Simulation GUI Resource-Service AAIS
AAIS (IV) DEWS AWI-Simulation GUI Resource-Service WPS Execute Process AAIS
AAIS (V) DEWS AWI-Simulation GUI Resource-Service AAIS
AAIS (VI) DEWS AWI-Simulation GUI Resource-Service + AAIS
AAIS (VII) DEWS AWI-Simulation GUI Resource-Service AAIS
AAIS – wps:Execute(I) <?xml version="1.0" encoding="utf-8"?> <wps:Execute service="WPS" version="1.0.0" xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:xlink="http://www.w3.org/1999/xlink"> <ows:Identifier> AffectedAreaIdentificationProcess</ows:Identifier> <wps:DataInputs> <wps:Input> <ows:Identifier>ISOCountryCode</ows:Identifier> <wps:Data> <wps:LiteralData>TH</wps:LiteralData> </wps:Data> </wps:Input> <wps:Input> <ows:Identifier>SimulationResultURL</ows:Identifier> <wps:Data> <wps:LiteralData> http://dews-services/resources/docs/foo.zip</wps:LiteralData> </wps:Data> </wps:Input>
AAIS – wps:Execute(II) <wps:Input> <ows:Identifier>EtaAttribute</ows:Identifier> <wps:Data> <wps:LiteralData>arrivaltim</wps:LiteralData> </wps:Data> </wps:Input> <wps:Input> <ows:Identifier>SshAttribute</ows:Identifier> <wps:Data> <wps:LiteralData>ssh_max</wps:LiteralData> </wps:Data> </wps:Input> <wps:Input> <ows:Identifier>MinSsh</ows:Identifier> <wps:Data> <wps:LiteralData>0.5</wps:LiteralData> </wps:Data> </wps:Input> </wps:DataInputs> </wps:Execute>
AAIS – wps:ExecuteResponse <wps:ExecuteResponse … > <wps:Process wps:processVersion="1.0.0"> <ows:Identifier> AffectedAreaIdentificationProcess</ows:Identifier> </wps:Process> <wps:ProcessOutputs> <wps:Output> <ows:Identifier> NumberOfIdentifiedAffectedAreas</ows:Identifier> <wps:Data> <wps:LiteralData>61</wps:LiteralData> </wps:Data> </wps:Output> <wps:Output> <ows:Identifier>FeatureCollection</ows:Identifier> <wps:Data> <wps:ComplexData>UEsDBBQAC1ycDsAAA … =</wps:ComplexData> </wps:Data> </wps:Output> </wps:ProcessOutputs> </wps:ExecuteResponse> ~500.000 Bytes Base64 encodiertes und zuvor geziptes Shapefile
Diskussion Anwendungsfall AAIS + Service ausgelagert + Separation of Concerns + Präzisere Architektur (Nutzung von Standards) + Wiederverwendbarkeit + Erhöhte Flexibilität + Server Performance > Client Performance NONSENSE - Zweifelhaft: · Prozessor-Geschwindigkeit? · Parallelisierung? · RAM? - Up- und Downloadzeiten
Fazit Anwendungsfall AAIS (I) • Sinnvolle Auslagerung / bessere Architektur • Client unabhängig von GeoDaten • Keine volle Nutzung der WPS Fähigkeiten (Shapefiles statt GML) • Kein Performancegewinn • Zu hoher Anteil von Up- und Download • Nur geringer Gewinn bei Prozessierungszeit • Alternative wäre leichter zu realisieren • Kein Deegree WPS Server • z.B. Java RMI oder XML RPC
Fazit Anwendungsfall AAIS (II) Warum auslagern? • Performanzgewinn • Hoher Ressourcenbedarf • Parallelisierbarkeit • Wiederverwendbarkeit • Komplexitätsreduktion • Übersichtlichere Architektur • Stärkere Kohäsion • Höhere Kapselung • Losere Kopplung ? ?
Anwendungsfall 1: Eigenen Prozess auslagern Anwendungsfall 2: Fremden WPS integrieren
AWI-Simulation (I) DEWS Sensordaten AWI-Simulation als WPS GUI Resource-Service AAIS
<ows:Identifier>observations</ows:Identifier> <Data> <ComplexData> <om:ObservationCollection gml:id="oc_1234"> <om:member> <om:Observation gml:id="obs_seismic_1234567"> <om:samplingTime> <gml:TimeInstant> <gml:timePosition> 2007-12-12T01:12:00+02</gml:timePosition> </gml:TimeInstant> </om:samplingTime> <om:procedure xlink:href="urn:GFZ:GITEWS:def:procedure:Seiscomp3" /> <om:observedProperty> <swe:CompositePhenomenon gml:id="comp_123" dimension="1"> <gml:csName>DLR</gml:csName> <swe:base xlink:href="urn:DLR:GITEWS:def:phenomenon:SeismicComposite" /> <swe:component xlink:href="urn:GFZ:GITEWS:def:quantity:depth:BelowEpicenter" /> <swe:component xlink:href="urn:DLR:GITEWS:def:phenomenon:universalMagnitude" /> <swe:component xlink:href="urn:DLR:GITEWS:def:phenomenon:originLocation" /> </swe:CompositePhenomenon> </om:observedProperty> <om:featureOfInterest> <gml:FeatureCollection gml:id="foi_earthquake"> <gml:location> <gml:Point> <gml:pos srsName="urn:ogc:crs:epsg:4328">104.095 -6.2522</gml:pos> </gml:Point> </gml:location> </gml:FeatureCollection> </om:featureOfInterest> <om:resultDefinition> <swe:DataBlockDefinition> <swe:components name=""> <ns:SimpleDataRecord xmlns:ns="http://www.opengis.net/swe/0.0"> <ns:field name=""> <ns:Time definition="urn:ogc:data:time:iso8601" /> </ns:field> <ns:field name=""> <ns:Quantity definition="urn:GFZ:GITEWS:def:quantity:depth:BelowEpicenter"> <ns:uom xlink:href="m" /> </ns:Quantity> </ns:field> <ns:field name=""> <ns:Quantity definition="urn:DLR:GITEWS:def:phenomenon:universalMagnitude" /> </ns:field> <ns:field name=""> <ns:Text definition="urn:DLR:GITEWS:def:phenomenon:originLocation" /> </ns:field> </ns:SimpleDataRecord> </swe:components> <swe:encoding> <swe:TextBlock decimalSeparator="." blockSeparator="@@" tokenSeparator="," /> </swe:encoding> </swe:DataBlockDefinition> </om:resultDefinition> <om:result>2007-12-12T01:12:00+02,109.12,8,104.095 -6.25229@@</om:result> </om:Observation> </om:member> <om:member> <om:Observation gml:id="obs_buoy_003_1234567"> <om:samplingTime> <gml:TimeInstant> <gml:timePosition> 2007-12-12T01:20:00+02</gml:timePosition> </gml:TimeInstant> </om:samplingTime> AWI-Simulation (I) Sensordaten AWI-Simulation als WPS GUI
AWI-Simulation (III) Sensordaten AWI-Simulation als WPS GUI
Komplexitätsfalle <Execute xmlns="http://www.opengis.net/wps/1.0.0" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:smf="http://www.awi.de/tsunami/smf/1.0" xmlns:om="http://www.opengis.net/om/0.0" xmlns:gml="http://www.opengis.net/gml" xmlns:swe="http://www.opengis.net/swe/0.0" service="WPS" version="1.0.0">
<om:featureOfInterest> <gml:FeatureCollection gml:id="foi_earthquake"> <gml:location> <gml:Point> <gml:pos srsName="urn:ogc:crs:epsg:4328">104.095 -6.2522</gml:pos> </gml:Point> </gml:location> </gml:FeatureCollection> </om:featureOfInterest> <om:resultDefinition> <swe:DataBlockDefinition> <swe:components name=""> <ns:SimpleDataRecord xmlns:ns="http://www.opengis.net/swe/0.0"> <ns:field name=""> <ns:Time definition="urn:ogc:data:time:iso8601" /> </ns:field> <ns:field name=""> <ns:Quantity definition="urn:GFZ:GITEWS:def:quantity:depth:BelowEpicenter">
Java Code XML • XML-Schema Java Bibliothek (z.B. XMLBeans) Nicht möglich • Generische Objektbäume (Map-List-Schachtelung) Nicht typsicher und nicht praktikabel • Templates mit String Ersetzung Wie bitte? ExecuteProcess-XML kann nicht sinnvoll erzeugt werden
AWI-Simulation Sensordaten AWI-Simulation als WPS GUI Nicht sinnvoll realisierbar
WPS • GeoDaten (XML) direkt in Prozessaufruf Typsicherheit! (jenseits von int und String) Generik = Beliebigkeit (XML Schema zu mächtig für Java) Warum auslagern? • Komplexitätsreduktion • Komplexität wird weitergereicht (schlechtes Schnittstellendesign)
Fazit Anwendungsfall AWI-Simulation Warum auslagern? • Performanzgewinn • Hoher Ressourcenbedarf • Parallelisierbarkeit • Wiederverwendbarkeit • Komplexitätsreduktion • Übersichtlichere Architektur • Stärkere Kohäsion • Höhere Kapselung • Losere Kopplung
WPS Fazit „Wann lohnt sich ein WPS?“ Einzelfallentscheidung
WPS Fazit • Performanzgewinn bei • Hoher Parallelisierung • Hohem Arbeitsspeicher-Bedarf • Abwägung gegenüber Transferzeiten • Typsicherheit nur bei • Nutzung von GML (statt Shapefiles) • in Java erzeugbarem XML (Schema Bibliothek) • Verbesserung der Architektur • Übersichtlichkeit, Verständlichkeit • Funktionale Trennung • Flexibilität und Wiederverwendbarkeit