1 / 32

Geodaten prozessieren mit WPS (Web Processing Service)

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

mrinal
Télécharger la présentation

Geodaten prozessieren mit WPS (Web Processing Service)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Matthias Lendholt 6. Januar 2010 Geodaten prozessieren mit WPS (Web Processing Service)

  2. Geodatenprozessierung

  3. Geodatenprozessierung Warum auslagern? • Performanzgewinn • Hoher Ressourcenbedarf • Parallelisierbarkeit • Wiederverwendbarkeit • Komplexitätsreduktion • Übersichtlichere Architektur • Stärkere Kohäsion • Höhere Kapselung • Losere Kopplung

  4. Remote • Corba (†) • RPC • Web Services: SOAP • REST (direct HTTP) • Sprachspezifisch, z.B. Java RMI • WPS

  5. 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)

  6. WPS - Operationen • GetCapabilities Liste verfügbarer Prozesse • Describe Process Liste Eingabe- und Rückgabeparameter • Execute Operation

  7. Anwendungsfall 1: Eigenen Prozess auslagern Anwendungsfall 2: Fremden WPS integrieren

  8. AAIS (I) Projekt DEWS: Affected Area Identification Service (AAIS) + 

  9. AAIS (II) DEWS AWI-Simulation GUI Resource-Service AAIS

  10. AAIS (III) DEWS AWI-Simulation GUI Resource-Service AAIS

  11. AAIS (IV) DEWS AWI-Simulation GUI Resource-Service WPS Execute Process AAIS

  12. AAIS (V) DEWS AWI-Simulation GUI Resource-Service AAIS

  13. AAIS (VI) DEWS AWI-Simulation GUI Resource-Service + AAIS

  14. AAIS (VII) DEWS AWI-Simulation GUI Resource-Service AAIS

  15. 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>

  16. 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>

  17. 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

  18. 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

  19. 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

  20. Fazit Anwendungsfall AAIS (II) Warum auslagern? • Performanzgewinn • Hoher Ressourcenbedarf • Parallelisierbarkeit • Wiederverwendbarkeit • Komplexitätsreduktion • Übersichtlichere Architektur • Stärkere Kohäsion • Höhere Kapselung • Losere Kopplung   ? ?     

  21. Anwendungsfall 1: Eigenen Prozess auslagern Anwendungsfall 2: Fremden WPS integrieren

  22. AWI-Simulation (I) DEWS Sensordaten AWI-Simulation als WPS GUI Resource-Service AAIS

  23. <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

  24. AWI-Simulation (III) Sensordaten AWI-Simulation als WPS GUI

  25. 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">

  26. <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">

  27. 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

  28. AWI-Simulation Sensordaten AWI-Simulation als WPS GUI Nicht sinnvoll realisierbar

  29. 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)

  30. Fazit Anwendungsfall AWI-Simulation Warum auslagern? • Performanzgewinn • Hoher Ressourcenbedarf • Parallelisierbarkeit • Wiederverwendbarkeit • Komplexitätsreduktion • Übersichtlichere Architektur • Stärkere Kohäsion • Höhere Kapselung • Losere Kopplung         

  31. WPS Fazit „Wann lohnt sich ein WPS?“  Einzelfallentscheidung

  32. 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

More Related