Orchestrierung von Geo Web Services

Größe: px
Ab Seite anzeigen:

Download "Orchestrierung von Geo Web Services"

Transkript

1 Fakultät Geoinformation Studiengang Kartographie Orchestrierung von Geo Web Services Diplomarbeit zur Erlangung des akademischen Grades Diplom-Ingenieurin für Kartographie (FH) Tag der Einreichung: 16. August 2009 Name: geboren am: Maria Kallbach 12. Februar Gutachter: Prof. Dr.-Ing. Frank Schwarzbach 2. Gutachter: Dipl.-Ing. (FH) André Müller

2 Danksagung An dieser Stelle möchte ich mich bei Allen bedanken, die mir während der Bearbeitung dieser Arbeit hilfreich und unterstützend zur Seite standen. Ganz besonders möchte ich meinen Dank Herrn Prof. Dr.-Ing. F. Schwarzbach aussprechen, der mich während meiner Diplomarbeit betreut und umfangreich unterstützt hat; genauso wie Herrn Dipl.-Ing. (FH) A. Müller, der als Zweitgutachter mir ebenfalls stets neue Anregungen und Tipps gab. Weiterhin bedanke ich mich bei den Laboringenieuren der Fakultät für die Hilfe bei der praktischen Umsetzung dieser Arbeit und für das Engagement und die Bereitschaft zur Lösung schwierigerer Hürden. Nicht zuletzt danke ich meiner Familie für den emotionalen Beistand ebenso meinen Freunden und Kommilitonen für die konstruktiven Hinweise und ihre Geduld.

3 Inhaltsverzeichnis 1 Einleitung 1 2 Überblick 2 3 Grundlagen Rechtliche Relevanz EU-Dienstleistungsrichtlinie INSPIRE GDI-DE und gdi.initiative.sachsen Technik SOAP WSDL BPEL REST Stand der SOAP-Unterstützung Standardisierungen Implementierungen Orchestrierungstools Intalio TIBCO Business Studio JDeveloper Apache Orchestration Direction Engine Weitere Orchestrierungstools Wahl des Orchestrierungstools Orchestrierung SOAP-Wrapping Typisierter Ansatz Generischer Ansatz Vorhandene Web Services OWS...51 i

4 4.2.2 Geo-Datenbanken ArcGIS-Services Eigene Web Services Katalog-Service und Datenverarbeitung WMS-Mantel Bildbearbeitung Koordinatentransformation Geo-Datenbanken GeoNames Oracle-DB Diensteketten Katalog-Service Datenverarbeitung WMS Bildbearbeitung Geo-Datenbank Bildbearbeitung Geo-Datenbank Koordinatentransformation Bildbearbeitung INSPIRE-Dienstekette Deployment der Diensteketten Zugriff auf Web Services Apache ODE Software-gestützt Browserbasierte Anwendungen Zusammenfassung 92 6 Literaturverzeichnis 94 7 Anlagen 99 ii

5 Abbildungsverzeichnis Abbildung 1: GDI-Hierarchie in Europa ([GDIDE2])...5 Abbildung 2: Sequenzdiagramm zur Orchestrierung ([GDISA1])...8 Abbildung 3: SOAP-Aufbau...9 Abbildung 4: SOAP als HTTP/GET im Browser...11 Abbildung 5: Aufbau SwA...13 Abbildung 6: Überblick über Prozesssprachen (vgl. [BECK])...16 Abbildung 7: REST als HTTP/GET bei geonames.org...19 Abbildung 8: REST als HTTP/GET bei ArcGIS-Services...21 Abbildung 9: UML-Klassendiagramm zu SOAP_1_1_FacadeFilter...28 Abbildung 10: Programmoberfläche von Intalio...31 Abbildung 11: TIBCO Programmoberfläche...33 Abbildung 12: Programmoberfläche von JDeveloper...35 Abbildung 13: BPEL-Engine von Apache ODE...37 Abbildung 14: BPEL-Designer in eclipse...43 Abbildung 15: Paket des BPEL-Designer von eclipse...43 Abbildung 16: Vorschlag einer Proxy Architektur von OGC [OGC3]...47 Abbildung 17: Einstiegsportal von GeoMIS.Sachsen...52 Abbildung 18: Suchergebnis bei GeoMIS.Sachsen...55 Abbildung 19: Relationales Schema MusterGIS Großschönau...56 Abbildung 20: Ergebnis nach der Datenbankabfrage...67 Abbildung 21: BPEL-Prozess als Design und mit Code-Ausschnitt...69 Abbildung 22: BPEL-Prozess mit Code-Ausschnitt...71 Abbildung 23: BPEL-Prozess und Beispiel-Code...73 Abbildung 24: Ergebnisbild der Dienstekette DK_OracleDB-WMS...74 Abbildung 25: BPEL-Prozess mit Beispiel-Code...75 Abbildung 26: Ergebnis der Dienstekette DK_Bebauungsplan für den Bereich Radebeul...76 Abbildung 27: Sequenzdiagramm eines INSPIRE-Requests...77 Abbildung 28: Ablauf der INSPIRE-Dienstekette...78 Abbildung 29: deploy.xml in eclipse...81 Abbildung 30: SOAP-Datei, erarbeitet in Notepad++ mit Syntaxhervorhebung...83 Abbildung 31: Pfad zur ODE...84 Abbildung 32: Kommando sendsoap in der Eingabeaufforderung...85 Abbildung 33: soapui mit SOAP-Request und -Response...86 Abbildung 34: SOAP-Gerüst in Altova XMLSpy...87 Abbildung 35: PHP-Seite für die Dienstekette WMS-Overlay...91 iii

6 Tabellenverzeichnis Tabelle 1: Die wichtigsten Unterschiede zwischen den SOAP Versionen 1.1 und 1.2 (vgl. [HALÖ])...12 Tabelle 2: Auswahl an Methoden von GeoNames.org...18 Tabelle 3: API für die Operation Export Map...20 Tabelle 4: Übersicht zu den Transformationsfunktionen...63 Tabelle 5: Übersicht der verwendeten Aktivitäten...68 Tabelle 6: Parameter von sendsoap.bat...84 iv

7 Listingverzeichnis Listing 1: Beispiel für einen SOAP-Request...10 Listing 2: Beispiel für einen SOAP-Response...10 Listing 3: Verkürzte Antwort im JSON-Format...22 Listing 4: Beispiel-Request für einen GetViewServiceMetadata...25 Listing 5: Beispiel-Response mit GetCapabilities eines WMS...26 Listing 6: SOAP-Anfrage für GetMap...26 Listing 7: SOAP-Antwort auf GetMap...27 Listing 8: Auszug aus einer bpmn-datei...32 Listing 9: Auszug aus einer xpdl-datei...34 Listing 10: Schematischer Aufbau eines SOAP-Requests nach OGC ([OGC1])...46 Listing 11: WMS-SOAP-Request nach [OGC3]...48 Listing 12: vereinfachter Java-Code des SOAP-wrappings...49 Listing 13: GetMap-Request als SOAP-wrapping...50 Listing 14: Proxy-Einstellungen im Java-Code...50 Listing 15: Vorschlag für einen GetFeature-Request im SOAP-wrapping...52 Listing 16: SOAP-Request an das GeoMIS.Sachsen...53 Listing 17: SOAP-Response vom GeoMIS.Sachsen...54 Listing 18: Ausschnitt aus dem SOAP-Response vom GeoMIS.Sachsen...55 Listing 19: Schematischer Aufbau einer SOAP-Nachricht an einen ArcGIS-Service...58 Listing 20: Ausschnitt aus dem Java-Code zu GeoNames...65 Listing 21: SOAP-Response von GeoNames...66 Listing 22: Beispiel einer deploy.xml...80 Listing 23: Ausschnitt aus der log-datei...82 Listing 24: grundsätzlicher PHP-Code mit SOAP...89 Listing 25: PHP-Code mit SOAP, am Beispiel der Dienstekette WMS-Overlay...89 Listing 26: PHP-Ausschnitt mit <img>-tag...90 v

8 Abkürzungsverzeichnis BKG Bundesamt für Kartographie und Geodäsie BPEL (BPEL4WS, WS-BPEL) Web Service Business Process Execution Language BPM Business Process Modeling BPMN Business Process Modeling Notation CAT Catalogue Services CSW Catalogue Service for the Web EPR Enpoint Reference GDI Geodateninfrastruktur GeoMIS Geographisches Metainformationssystem GML Geography Markup Language HTTP Hypertext Transfer Protocol INSPIRE Infrastructure for Spatial Information in the European Community JAR Java-Archive KVP Key Value Pairs MTOM Messaging Transmission Optimization Mechanism OASIS Organization for the Advancement of Structured Information Standards ODE Orchestration Direction Engine OGC Open Geospatial Consortium ORCHESTRA Open Architecture and Spatial Data Infrastructure for Risk Management OWS OGC Web Services PHP PHP: Hypertext Preprocessor REST Representational State Transfer RPC Remote Procedure Call SOA Serviceorientierte Architektur SOAP ursprünglich: Simple Object Access Protocol SwA SOAP with Attachment UDDI Universal Description, Discovery and Integration URI Uniform Resource Identifier vi

9 URL Uniform Resource Locator W3C World Wide Web Consortium WAR Web Archive WFS Web Feature Service WMS Web Map Service WSDL Web Service Description Language XML Extensible Markup Language XOP XML Optimized Packaging XPath XML Path Language XPDL XML Process Definition Language XSD XML Schema Definition vii

10 1 Einleitung 1 Einleitung Die Welt der Internettechnologie befindet sich gegenwärtig in einem Umschwung. Wurde vorher noch für jedes Problem eine Anwendung konstruiert, stehen jetzt die Web Services im Vordergrund, die vielseitig einsetzbar sind. Sie beschreiben den Austausch von Daten und Funktionalitäten zwischen verschiedenen Anwendungen. Um die Vorteile der Web Services zu nutzen, setzt sich die serviceorientierte Architektur (engl.: serviceoriented architecture, kurz: SOA) zunehmend durch. Die Idee der SOA ist mit dem publish-findbind-prinzip einfach zu erklären: ein Service-Anbieter veröffentlicht seinen Web Service in einem Service-Verzeichnis (publish); ein Nutzer sucht und findet diesen im Verzeichnis (find) und kann ihn somit nutzen und/oder in eigene Anwendungen einbinden (bind) (vgl. [HALÖ], [MELZ]). Da ein Web Service allein mitunter nicht alle gewünschten Funktionalitäten erfüllt, bedarf es einer Verknüpfung unterschiedlicher Dienste (Orchestrierung). Im Bereich der Geo Web Services sei folgendes Beispiel genannt: Für einen WFS (web feature service) sollen die Geometrien bestehender WFS vereint werden, da sie die gleiche Art von Geometrien (etwa Gebäude), aber mit verschiedenen Attribute führen (zum Einen Baujahr und zum Anderen Geschossigkeit). Nun kann dies zwar manuell geschehen, indem jeweils die Geometrien abgefragt und mittels einer Schematransformation transformiert, vereint und dem WFS zur Verfügung gestellt werden. Andererseits und viel effizienter kann dieser Prozess automatisch durch eine Orchestrierung realisiert werden. Die Dienstekette beinhaltet demzufolge mindestens drei Dienste: die beiden WFS und eine Transformation. Somit können die Daten aktuell ausgegeben werden und müssen nicht regelmäßig manuell auf den neuesten Stand gebracht werden. Der WFS-Request löst die Dienstekette direkt aus und der Nutzer erhält die Geometrien mit den Attributen (Gebäude mit Baujahr und Geschossigkeit). Im Rahmen der Diplomarbeit wird untersucht, in wie weit sich Geo Web Services orchestrieren lassen. Hierbei werden die Standards nicht außer Acht gelassen. Auf die SOAP-Unterstützung der Web Services wird besonderer Wert gelegt. Dazu werden mit einem geeigneten Orchestrierungstool vier Diensteketten implementiert. Diese Diplomarbeit versteht sich als Fortsetzung der bereits bestehenden Diplomarbeit von Claudia Jäger und Anne Weidenhagen von 2008 (siehe [DAJW]). 1

11 2 Überblick 2 Überblick Das folgende Kapitel 3 befasst sich mit den Grundlagen einer Orchestrierung. Dabei wird eingangs sowohl auf die Rechtliche Relevanz und auf die Technik eingegangen. Der letzte Abschnitt gibt eine Übersicht über die existierenden Orchestrierungstools, mit denen sich Diensteketten implementieren lassen. Das 4. Kapitel entspricht dem praktischen Teil der Diplomarbeit. An dieser Stelle sind sämtliche Ergebnisse dokumentiert: genutzte und eigens erstellte Web Services und umgesetzte Diensteketten. Weiterhin wird im Kapitel 4.6 beschrieben wie der Zugriff auf Web Services erfolgen kann. Abschließend gibt das Kapitel 5 eine Zusammenfassung der Diplomarbeit und einen Ausblick für die Zukunft. 2

12 3 Grundlagen 3 Grundlagen Um das Thema Orchestrierung rechtlich stützen zu können, befasst sich das erste Unterkapitel mit Richtlinien der EU, nationalen und regionalen Direktiven, die jeweils eine Geodateninfrastruktur (GDI) beschreiben. Einleitend dazu gibt die EU-Dienstleistungsrichtlinie einen Überblick über das angestrebte Ziel der EU. Damit eine erfolgreiche Orchestrierung entstehen kann, müssen verschiedene Standards berücksichtigt werden. Für die Web Services sind dies SOAP und WSDL. Für die Orchestrierung bedarf es darüber hinaus der Beschreibungssprache BPEL. Da diese Standards bereits in [DAJW] ausführlich beschrieben wurden, werden hier die Kernpunkte wiederholt und an einigen Stellen zusätzlich neue Versionen vorgestellt. Während der Bearbeitung trat auch der Begriff REST auf, worauf in diesem Kapitel kurz eingegangen wird. 3.1 Rechtliche Relevanz EU-Dienstleistungsrichtlinie Das Ziel der Dienstleistungsrichtlinie besteht darin, Fortschritte im Hinblick auf einen echten Binnenmarkt für Dienstleistungen zu erreichen, so dass im größten Sektor der europäischen Wirtschaft sowohl die Unternehmen als auch die Verbraucher den vollen Nutzen aus seinen Möglichkeiten ziehen können. ([DIENST1]) Grundgedanke der Richtlinie ist den Handel europaweit so zu öffnen, dass Dienstleistungen grenzüberschreitend genutzt werden können, um den gemeinschaftlichen Binnenmarkt zu unterstützen. Dabei beruft sich die EU-Dienstleistungsrichtlinie auf die sogenannte Lissabon-Strategie1. Erbringer und Empfänger von Dienstleistungen können somit besser von den Grundfreiheiten (Niederlassungsrecht, freier Dienstleistungsverkehr ohne Grenzen) profitieren. Ferner sollen Verwaltungsver- 1 Die Lissabon-Strategie (auch Lissabon-Agenda oder Lissabon-Prozess) ist ein EU-Programm mit dem Ziel bis 2010 Europa zum wettbewerbsfähigsten und dynamisch wissensgestützten Wirtschaftsraum der Welt zu machen. 3

13 3 Grundlagen fahren vereinfacht, Hindernisse abgebaut und Vertrauen zwischen den EU-Mitgliedsstaaten und zwischen den Dienstleistungspartnern verbessert werden. Um dies alles zu erreichen, sollen beispielsweise einheitliche Ansprechpartner, elektronische Verfahren und Verwaltungszusammenarbeit eingerichtet werden. Weiterhin werden die Rechte von Dienstleistungsempfängern gestärkt und eine Politik zur Wahrung der Qualität entwickelt. Die Richtlinie berührt eine Vielzahl von Dienstleistungen. Neben der herkömmlichen Situation, in der Dienstleistungen direkt erbracht werden, spricht die Richtlinie auch über Leistungen, die im Fernabsatz, beispielsweise über das Internet, erbracht werden können. ([DIENST2], Abs. 33) bzw. [...] zusätzliche Informationen müssen auf klare und eindeutige Art und Weise dargestellt werden und aus der Ferne sowie durch elektronische Mittel, wie z. B. im Internet oder per , leicht zugänglich sein. ([DIENST1], Kapitel 5.3.2). Demzufolge sind auch die Web Services betroffen. Für die Geo Web Services befinden sich genauere Direktiven in INSPIRE bzw. GDI-DE (siehe Kapitel bzw ). Seit 28. Dezember 2006 ist die EU-Dienstleistungsrichtlinie ([DIENST2]) mit der Bestätigung des EU-Rates in Kraft getreten. Drei Jahre haben nun die Mitgliedsstaaten Zeit diese Richtlinie umzusetzen. Darüber hinaus wird eine ständige Kontrolle die Qualität evaluieren. Aus der Richtlinie wird also ein dynamischer Prozess geschaffen INSPIRE Ziel dieser Richtlinie ist es, allgemeine Bestimmungen für die Schaffung der Geodateninfrastruktur in der Europäischen Gemeinschaft (nachstehend INSPIRE abgekürzt) für die Zwecke der gemeinschaftlichen Umweltpolitik sowie anderer politischer Maßnahmen oder sonstiger Tätigkeiten, die Auswirkungen auf die Umwelt haben können, zu erlassen. ([INSP5], Kapitel 1, Artikel 1, Absatz 1) Die Europäische Kommission initiierte ein Projekt das zum Ziel hat, eine europaweite Einheit in Sachen Geodaten (inklusive integrierten räumlichen Informationsdiensten) zu schaffen. Seit Mai 2007 ist die Richtlinie INSPIRE in Kraft und verordnet den Mitgliedsstaaten, interoperable Geobasis- und Geofachdaten anzubieten. Dies soll den Informationsaustausch über Grenzen hinweg und den öffentlichen Zugang zu den Daten in ganz Europa ermöglichen. 4

14 3 Grundlagen Im Sinne dieser Richtlinie bezeichnet der Ausdruck Geodateninfrastruktur Metadaten, Geodatensätze und Geodatendienste, Netzdienste und -technologien, Vereinbarungen über gemeinsame Nutzung, Zugang und Verwendung sowie Koordinierungs- und Überwachungsmechanismen, -prozesse und -verfahren, die im Einklang mit dieser Richtlinie geschaffen, angewandt oder zur Verfügung gestellt werden; ([INSP3], Kapitel 1, Artikel 3, Absatz 1) Geo Web Services definiert INSPIRE folgendermaßen: [Im Sinne dieser Richtlinie bezeichnet der Ausdruck] Geodatendienste mögliche dazugehörige Formen der Verarbeitung der in Geodatensätzen enthaltenen Geodaten oder der dazugehörigen Metadaten mit Hilfe einer Computeranwendung; ([INSP3], Kapitel 1, Artikel 3, Absatz 4) Abbildung 1 zeigt die Struktur von INSPIRE. Die europäische Richtlinie beschreibt allgemeine Regelungen, die für Europa gelten. Jeder Mitgliedsstaat hat selbst noch eine zusätzliche Geodateninfrastruktur (GDI), die detailliertere Informationen entsprechend für das Land gibt. Die unterste Stufe bilden die Länder und Kommunen des Landes. Abbildung 1: GDI-Hierarchie in Europa ([GDIDE2]) Folgende Schwerpunkte hat INSPIRE gesetzt, um dieses Ziel zu erreichen (vgl. [INSP2]): Daten sollen einmalig (nicht redundant) erhoben und dort gehalten werden, wo die Bearbeitung der Daten am effektivsten ist es soll möglich sein, Geodaten von verschiedenen Quellen aus Europa nahtlos zu kombinieren und mit weiteren Nutzern und/oder Applikationen nutzen zu können je nachdem wie detailliert die Informationen benötigt werden, sollen sie dem jeweiligen Nutzer bereitgestellt werden - unabhängig vom Level der Erfassung 5

15 3 Grundlagen Geodaten sollen in allen Bereichen einfach und verfügbar sein, um eine verantwortungsbewusste Regierungsführung (engl. good governance) zu fördern Geodaten sollen leicht auffindbar und durch Metadaten beschrieben sein, sowie deren Nutzungsund Erwerbsbedingungen dargestellt werden. Der Zeitplan sieht vor, dass zunächst die Metadaten in eine entsprechende Form gebracht werden müssen. D. h. es soll beschrieben sein, um was für Daten und Dienste es sich handelt, welche Ausdehnung sie haben, welcher Genauigkeit sie entsprechen, wer Ansprechpartner dafür ist und so weiter. In der INSPIRE-Richtlinie werden auch direkt Web Services angesprochen und dazu aufgerufen, im heutigen Zeitalter des Internets diese Möglichkeit zu nutzen und die Geodaten über Web Services verfügbar zu machen. INSPIRE nennt Diensteketten Dienste zum Abrufen von Geodatendiensten und erwartet somit eine Nutzung dieser Möglichkeit um die SOA zu fördern. Dienste zum Abrufen von Geodatendiensten (invoke): Dienste, über die von einem Geodatendienst erwartete Datenein- und Datenausgaben sowie eine Bearbeitungs- oder Dienstleistungskette zur Zusammenfassung mehrerer Dienste festgelegt werden können. Sie ermöglichen auch die Festlegung einer externen Webdienstschnittstelle für die Bearbeitungs- oder Dienstleistungskette. ([INSP4], Anhang Teil D, Absatz 3.5) Das dritte Kapitel der Direktive ( Interoperabilität von Geodatensätzen und -diensten ) beschäftigt sich direkt mit der Vereinbarkeit von Diensten, die europaweit nutzbar gemacht werden sollen. Die Richtlinie gilt nur für bereits bestehende, digitale Daten. Sie schreibt nicht vor wie weitere Daten erhoben werden sollen. 6

16 3 Grundlagen GDI-DE und gdi.initiative.sachsen Mit der Geodateninfrastruktur in Deutschland (GDI-DE) wird die übergreifende Vernetzung raumbezogener Daten (Geodaten) für die Unterstützung von effizienten Entscheidungsprozessen in Verwaltung, Wirtschaft und Politik gefördert. Neben der Betrachtung nationaler Entwicklungen ist es Aufgabe der GDI-DE, die Entwicklungen in Europa (INSPIRE) sowie weltweit (GSDI) einzubinden. ([GDIDE1]) Mit der GDI-DE soll ein Konzept geschaffen werden, das den partnerschaftlichen und offenen Aufbau einer Geodateninfrastruktur in Deutschland beschreiben soll. Dieser soll dann als Komponente zur europäischen GDI dienen. Es unterstützt den Grundgedanken einer modernen Verwaltung. Dieses Konzept wird als Architekturkonzept bezeichnet und befindet sich derzeit in der Version 1.0 vom August 2007 (siehe [GDIDE2]). An diesem Konzept arbeiten Personen der öffentlichen Verwaltung sowie Fachleute aus der Softwarebranche. Bisher liegen verschiedenste Geodaten verteilt und in unterschiedlichen Strukturen vor. Da der Bedarf an solchen Daten mehr und mehr wächst, soll mithilfe der GDI-DE der Zugang zu Geodaten für die öffentliche Verwaltung, die Wirtschaft und alle Bürger erleichtert werden. Weiterhin soll auch die Nutzung dieser Daten verbessert werden. Voraussetzung dafür ist, dass die Geodaten über Netzdienste zugänglich sind. Ziel der GDI-DE ist die Bereitstellung der digitalen Geoinformationen der öffentlichen Verwaltung und Wirtschaft. Dabei versteht sie sich als Teil des E-Government2. Neben den Vorgaben von INSPIRE werden zusätzliche Standardisierungsgremien wie OGC berücksichtigt. Die Architektur der GDI-DE beschreibt ein offenes Konzept zur Bereitstellung von Geodaten. Sie beschreibt Technologien, elementare Funktionen und Standards, wie sie für die Bereitstellung von Geodaten notwendig sind. Sie folgt dem im Auftrag formulierten Leitgedanken, grundsätzlich fachneutral auf allen Ebenen der Verwaltung angewendet werden zu können. ([GDIDE2], Kapitel 1.2). Die GDI-DE regelt die Handhabung mit Geodaten in der Bundesrepublik Deutschland im Allgemeinen. Für jedes Bundesland gibt es jeweils weitere Architekturkonzepte. Die Expertengruppe für Sachsen (gdi.initiative.sachsen) hat bisher an einem Entwurf des Architekturkonzeptes gearbeitet ([GDISA1]). Hier wird detaillierter beschrieben, wie der Umgang mit sächsischen Geodaten erfolgen soll. Dabei werden Einstiegsportale für den Nutzer direkt benannt und vorgestellt. Für Sachsen stellt 2 Als E-Government wird die Vereinfachung der Prozesse der amtlichen Institutionen durch den Einsatz von Informations- und Kommunikationstechniken (z. B. Internet) bezeichnet. 7

17 3 Grundlagen dies die Website dar. Hier befinden sich neben dem Architekturkonzept noch weitere Dokumente wie die Strategischen Leitlinien 3, die als Grundlage für das Konzept dienen. Im Zusammenhang mit Geodateninfrastrukturen wird besonders Wert auf die service-orientiere Architektur (SOA) gelegt. Eine GDI kann nur nach den Vorgaben der SOA aufgebaut werden. Die gdi.initiative.sachsen spricht dabei konkrete Orchestrierungen an: Unter Orchestrierung wird die Erstellung eines neuen, höherwertigen Dienstes durch eine intelligente Verkettung von vorhandenen Diensten verstanden. ([GDISA1], Kapitel 4.4.2). Abbildung 2: Sequenzdiagramm zur Orchestrierung ([GDISA1]) Abbildung 2 zeigt schematisch den Ablauf einer Orchestrierung. Die gdi.initiative.sachsen fordert praktisch eine Verkettung von Diensten. Es soll eine BPEL-Engine auf der GDI-Sachsen-Plattform installiert werden, um gezielt Orchestrierungen vornehmen zu können. 3 (letzter Zugriff: Juli 2009) 8

18 3 Grundlagen 3.2 Technik SOAP SOAP stand als Akronym für simple object access protocol. Da diese Definition aber seiner Funktionen nicht mehr gerecht wird bzw. inhaltlich falsch ist, steht das Wort SOAP seit der Version 1.2 für sich selbst. Das zuständige Standardisierungsgremium ist das W3C (World Wide Web Consortium). SOAP ist das Übertragungs-/Kommunikationsformat für Web Services. Es basiert auf XML-Technologien. Der SOAP-Aufbau wird einem herkömmlichen Brief nachempfunden (Abbildung 3): Envelope (Umschlag) Header (vergleichbar mit Betreff-Zeile) Body (eigentlicher Inhalt) Abbildung 3: SOAP-Aufbau Die SOAP-Nachricht selbst steckt nochmals mit ihren drei Teilen innerhalb des Transportprotokolls (hier: HTTP). HTTP nimmt es sozusagen mit auf dem Weg zum Empfänger. Der Aufbau soll nun am Beispiel des Dienstes IPtoCountry (zu finden unter: ecubicle.net/iptocountry.asmx) dargestellt werden: 9

19 3 Grundlagen Parameter: Connection-Endpoint: SOAP-Action: <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <SOAP-ENV:Body> <m:findcountryasxml xmlns:m="http://www.ecubicle.net/webservices/"> <m:v4ipaddress> </m:v4ipaddress> </m:findcountryasxml> </SOAP-ENV:Body> <SOAP-ENV:Envelope> Listing 1: Beispiel für einen SOAP-Request In Listing 1 ist die Struktur eines SOAP-Requests dargestellt. Der wichtige Teil (der Body) beinhaltet die benötigten Variablen für den Web Services, die der Nutzer auszufüllen hat. Bei diesem Beispiel handelt es sich um einen Dienst, der das Land zu einer IP-Adresse zurück liefert: <m:v4ipaddress> </m:v4ipaddress> V4IPAddress ist der Variablenname. m steht für den Namespace (xmlns:m=...). Es kann auch vorkommen, dass der Dienst keine Variablen erwartet, sondern lediglich aufgerufen werden muss (etwa beim Abrufen von Versionen). Dann enthält das Body-Element keine weiteren Elemente (<Body/>). <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" smlns:xsd="http://www.w3.org/2001/xmlschema"> <soap:body> <FindCountryAsXmlResponse xmlns="http://www.ecubicle.net/webservices/"> <FindCountryAsXmlResult> <IPCountryService xmlns=""> <Country>Germany</Country> </IPCountryService xmlns=""> </FindCountryAsXmlResult> </FindCountryAsXmlResponse> </soap:body> </soap:envelope> Listing 2: Beispiel für einen SOAP-Response 10

20 3 Grundlagen Listing 2 zeigt die dazugehörige Antwort. Im letzten Kind-Element der XML-Struktur ist das Ergebnis zu finden: <Country>Germany</Country> Auch hier befindet sich das Wesentliche im Body-Element. Da die SOAP-Nachrichten via HTTP verschickt werden, kann der Dienst auch direkt durch eine URL angesprochen werden. Für das eben genutzte Beispiel des Service IPtoCountry ist folglich die URL: Die Syntax einer solchen URL ist folglich: Die Variablen werden nach dem Connection-Endpoint (der Teil bis zum?) als Key-Value-Pairs angegeben. Die Antwort ist in diesem Fall ein verkürzter SOAP-Response. Sie enthält nur die KindElemente des Body-Elements (siehe Abbildung 4). Abbildung 4: SOAP als HTTP/GET im Browser Seit 2007 ist die Version 1.2 vorhanden ([SOAP]). Obwohl immer noch die vorhergehende Version (1.1) weit verbreitet ist, sollen hier die wichtigsten Unterschiede in Form einer Tabelle kurz vorgestellt werden: 11

21 3 Grundlagen Funktionalität Spezifikation Version Teil Version Teile Envelope-Standard-Namespace (gleichzeitig Versionserkennung) soap/envelope/ soap-envelope/ Encoding frei wählbar, Encoding der Spezifikation: soap/encoding/ frei wählbar, Encoding der Spezifikation: soap-encoding Intermediäre und NachrichtenWeiterleitung4 Actor5-Attribut Intermediär: SOAP-Knoten (Node-Element), die Rollen annehmen (Role-Element). Die Nachrichtenweiterleitung wird exakter reguliert. Fehlermanagement Ein Fehler enthält vier Elemente. Der faultcode gibt die Art des Fehlers an. Die Fehlerelemente wurden vollständig überarbeitet. Neue Fehlercodes sind hinzugekommen. Für den (optionalen) RPC-Teil der Spezifikation gibt es ebenfalls neue Fehlercodes. Elemente nach dem SOAP-Body erlaubt untersagt Binding Allgemeine Spezifikation zur Bindung an andere Protokolle. Beschreibung der Bindung an HTTP. Tabelle 1: Die wichtigsten Unterschiede zwischen den SOAP Versionen 1.1 und 1.2 (vgl. [HALÖ]) Mit SOAP können ausschließlich Textdateien übertragen werden, also Daten im ASCII-Format. Alle Teile einer SOAP-Nachricht müssen der XML-Syntax entsprechen. Binäre Daten (z. B. Bilder, formatierter Text, Video) können deshalb nicht eingebunden werden. Außerdem könnten größere Datenmengen den verfügbaren Speicherplatz überschreiten. Aus diesem Grund gibt es ein Verfahren, das es ermöglicht Daten außerhalb des Envelopes zu übermitteln. Neben der eigentlichen SOAP-Nachricht können ein oder mehrere Anhänge angefügt werden. Diese Vorgehensweise wird als SOAP with Attachments (SwA) bezeichnet. Im Anhang kann jeder beliebige Datentyp aufgenommen werden (siehe Abbildung 5). XML ist also wiederum auch möglich. In diesem Fall ist das Übermitteln von Bildern in SOAP von Interesse, da bspw. ein GetMap-Request an einen WMS ein Bild als Antwort zurück bekommt. In der Diplomarbeit [DAJW] wird ne- 4 5 Intermediäre leiten Nachrichten weiter und nutzen unter Umständen Teile daraus. Auf dem Weg zum Empfänger kann die Nachricht zusätzliche Stopps einlegen. Bisher kann der Pfad noch nicht beeinflusst werden. Das Attribut actor gibt den Empfänger des Header-Elements an. Wird es ausgelassen, so ist der Empfänger auch der endgültige Bestimmungsort der SOAP-Nachricht. 12

22 3 Grundlagen ben der Methode des Anhanges (by-reference) noch die Möglichkeit by-value beschrieben. Die Binärdaten werden dabei über eine Kodierung in ein Textformat umgewandelt und als Element direkt in die SOAP-Nachricht eingebettet. Das hat den Vorteil, dass die Nachricht als XML-Syntax bestehen bleibt. Derzeit ist es möglich mittels SOAP MTOM (message transmission optimization mechanism) eine W3C-Spezifikation ([MTOM]) die Vorteile beider Verfahren zu nutzen. Dabei werden kodierbare Elemente in den Body-Teil der SOAP-Nachricht eingefügt und nicht-kodierbare ausgelagert und die dazugehörige URI mitgeliefert. Abbildung 5: Aufbau SwA Da es sich schon in der Diplomarbeit [DAJW] problematisch gestaltelte einen Web Service zu erstellen, der mit Bilddaten und SOAP arbeiten kann und im Rahmen dieser Diplomarbeit eine Einarbeitung in das Thema aufwändig erscheint, wurde diese Möglichkeit nicht weiter betrachtet. 13

23 3 Grundlagen WSDL Die WSDL-Datei (web service description language) ist die Beschreibungsdatei eines Web Services. Sie enthält Informationen zu den Bestandteilen eines Dienstes, welche Daten ausgetauscht werden und den Aufbau des Web Services selbst. Zusätzlich verweist die WSDL auf den SOAP-Service. Somit können SOAP-Nachrichten automatisch aus WSDL-Dateien erstellt werden. Sie dient demzufolge als eine Art Schnittstellenbeschreibung. Auch hier ist das Standardisierungsgremium das W3C und die Technologie basiert auf XML. Die WSDL-Datei wird meist automatisch generiert sobald ein Web Service aufgesetzt wird. Es kann aber auch vorkommen, dass bereits bestehende Web Services keine WSDL-Datei zur Verfügung stellen. Dieses Problem kann umgangen werden, indem eine solche Datei manuell vom Entwickler verfasst wird (auch hierfür gibt es Tools wie bspw. Altova XMLSpy). Des Weiteren ist WSDL ein wesentlicher Bestandteil zur Umsetzung einer Orchestrierung. In ihr sind die sogenannten PortTypes definiert, die die automatisierte Erstellung von PartnerLinks unterstützen. Von daher ist die WSDL-Datei Grundvoraussetzung und unverzichtbar. Eine WSDL-Datei besteht aus folgenden Elementen: definitions (Wurzelelement, umfasst: Name des Service, Namespaces) types (Datentyp-Definitionen) message (Angaben über die Daten in einer (SOAP-)Nachricht, dieses Element kann mehrmals auftreten) porttype (Informationen über die angebotenen Methoden) binding (Protokoll und Nachrichtenformat) service (beinhaltet den Endpoint des Service) 14

24 3 Grundlagen BPEL BPEL (eigentlich WS-BPEL: web service business process execution language) ist die Sprache zur Beschreibung von Geschäftsprozessen. Für die Orchestrierung bedeutet dies, dass sie den Ablauf einer Dienstekette beschreibt (Variablenübergabe, Aufruf von Web Services und so weiter). Sie ist also die Sprache des Dirigenten. Das Standardisierungsgremium ist hier OASIS. Aktuell liegt die Version 2.0 vor. Die Prozesse werden selbst auch als Web Service veröffentlicht und können somit für weitere Orchestrierungen genutzt werden. BPEL basiert ebenfalls auf XML. Ein BPEL-Prozess besteht mindestens aus den Elementen partnerlinks, variables und sequence, zusammengefasst im Wurzelelement process. Die Struktur wird in fünf Abschnitte unterteilt (vgl. [HALÖ]): partner ( Teilnehmer, hier: Web Services) messages (Nachrichten, die untereinander ausgetauscht werden) data handling (Aktualisieren und Austauschen der beteiligten Variablen) activities (die einzelnen Schritte des Prozesses) scopes (Rahmen um zusammengehörige Aktivitäten) Der Abschnitt Activities kann folgende Elemente umfassen: invoke (Web Service aufrufen) receive (Nachricht von einem Web Service empfangen) reply (auf einen Web Service antworten) wait (eine bestimmte Zeit abwarten) throw (Fehlermeldungen zurückgeben) empty (keine Aktivität ausführen) Diese Elemente können selbst nochmals in strukturierte Aktivitäten eingebaut werden: sequence (festgelegte Reihenfolge) switch (bedingte Ausführung, zu Vergleichen mit if-anweisungen) while (Schleife) pick (Ausführung nach einem bestimmten Ereignis) flow (parallele Abarbeitung) scope (beeinflusst die Ausführung der Aktivitäten) 15

25 3 Grundlagen Diese strukturierten Aktivitäten können beliebig ineinander verschachtelt werden, um auch sehr komplexe Prozesse beschreiben zu können. BPEL ist stark von Web Service-Standards abhängig. Die WSDL-Dateien der beteiligten Web Services sind daher eine unumgängliche Grundvoraussetzung für BPEL und somit auch für die Orchestrierung. Ein Beispiel für ein BPEL-Dokument ist in der Anlage E zu finden. Eine weitere Sprache zur Beschreibung von Geschäftsprozessen bildet XPDL6. Seit 1993 wird sie von der Workflow Management Coalition (WfMC, entwickelt. Die aktuelle Version 2.1 besteht seit Oktober Im Gegensatz zu BPEL liegt der Fokus aber nicht auf Interaktion von Web Services, sondern vielmehr auf der Entwicklung eines Austauschformates für diverse Prozessprachen. Dabei unterstützt XPDL die grafische Business Process Modeling Notation (BPMN), indem BPMN-Konstrukte nach einer festegelegten Syntax beschrieben und abgelegt werden können. Folglich erlaubt XPDL, dass der Prozess mit einem Programm modelliert, mit einem anderen interpretiert und verändert und mit einem weiteren auf einer XPDL-konformen Engine ausgeführt werden kann. Deshalb ist XPDL keine ausführbare Programmiersprache wie BPEL, sondern eher ein Prozessbeschreibungsformat. Abbildung 6 ordnet die unterschiedlichen Konzepte ein. (vgl. [COLUMN2] und [BECK]) Abbildung 6: Überblick über Prozesssprachen (vgl. [BECK]) Somit ist für die Orchestrierung von Web Services BPEL vorteilhafter. 6 XML Process Definition Language 16

26 3 Grundlagen REST Ein Web Service kann neben HTTP und SOAP auch über REST (representational state transfer) angesprochen werden. REST ist dabei kein Nachrichtenprotokoll im eigentlichen Sinne sondern ein Architekturstil, der besagt, wie bestehende Web-Protokolle verwendet werden können. Im Jahr 2000 beschrieb Roy Fielding erstmals das REST-Prinzip in seiner Dissertation ([FIELD]). Darin wurde beschrieben, dass jede Ressource durch eine eigene URI erreichbar ist. Ein Web Service wird als RESTful bezeichnet, wenn die Konformität zum besagten Architekturstil gewährleistet ist. Die URI wird mittels HTTP/GET an den Server weitergegeben. Anders als bei SOAP gibt es keine Datentypen. Wie das Format der Server-Antwort auszusehen hat, ist in REST nicht festgelegt. Dies bleibt dem Web Service überlassen. Die Antwort kann mittels einer Stylesheet-Transformation beispielsweise in eine HTML-Seite gewandelt werden. Diese Methode der Abfrage von Web Services (bzw. von Ressourcen) ist sehr simpel. Es werden keine Programmierkenntnisse vorausgesetzt. Der REST-Request kann einfach durch einen Link auf der Website dargestellt werden. Der REST-Response kann direkt transformiert werden. (vgl. [HALÖ], [MELZ], [FIELD]) Im Prinzip ist die Orchestrierung von RESTful Web Services nicht möglich, weil sie nicht Standardkonform sind. Da aber Apache ODE (orchestration direction engine) die Unterstützung von REST demnächst vorsieht, werden an dieser Stelle Web Services, die über REST erreichbar sind, vorgestellt. GeoNames Die freie Geodatenbank GeoNames (http://www.geonames.org) beherbergt enorme Datensätze mit geographischen Bezug. Dieser Dienst ist frei und kann privat genutzt werden. Die Nutzer können sogar eigene Daten hochladen und somit zur allgemeinen Benutzung zur Verfügung stellen. GeoNames bietet verschiedene Methoden an, um an die Daten (Ressourcen) zu kommen. Die für eine Orchestrierung von Geo Web Services interessanten Methoden sind in Tabelle 2 zusammengefasst. 17

27 3 Grundlagen WebService cities Eingabeparameter Ausgabe north, south, east, west (Bounding Informationen zu Städten, die in der Bounding Box gefunden wurden: Box) name, lat, lng, geonameid, countrycode, countryname, fcl, fcode, fclname, fcodename, population, alternativenames, elevation, continentcode, admincode, adminname, timezone countrinfo country (Bsp.: DE, USA, CH) Informationen zum Land CountryCode, countryname, isonumeric, isoalpha3, fipscode, continent, capital, areainsqkm, population, currencycode, languages, geonameid, bboxwest, bboxnorth, bboxeast, bboxsouth search q (sucht in alle Attribute), name (sucht in Ortsbezeichnung), name_equals (exakte Ortsbezeichnung), weitere optionale Parameter Informationen zum gefundenen Datensatz (variiert) srtm3 lat, lng (Breite und Länge) eine Zahl, die die Höhe angibt (nur für das Festland; fallen die Koordinaten auf das Meer wird die Zahl ausgegeben; die Höhen beruhen auf das SRTM mit etwa 90 Meter Genauigkeit der NASA (http://www2.jpl.nasa.gov/srtm) Tabelle 2: Auswahl an Methoden von GeoNames.org Eine Auflistung aller verfügbaren Methoden ist unter ws-overview.html zu finden. Neben Abfragen zum GeoNames-Datenbestand gibt es sogar noch Methoden, die mit Wikipedia-Einträgen verknüpft sind. Abbildung 7 zeigt den Datenauszug, wenn nach dem Ländercode CA in der Methode countryinfo gesucht wird. Die URL ist nach folgendem Schema zusammengesetzt: [Methode]?variable1=xyz&... 18

28 3 Grundlagen Abbildung 7: REST als HTTP/GET bei geonames.org ArcGIS-Services ESRI bietet mit dem ArcGIS Server eine Möglichkeit Geodienste über ein Netzwerk bereitzustellen. Zu diesen Geodiensten zählen: Kartendienste, Globedienste (3D), Geoprozessingdienste (Analysen, WPS), Geodatendienste (ähnlich dem WFS), Geokodierungs- und Transformationsdienste. Die GIS Experten nutzen ArcGIS Desktop für die Erstellung von Karten, Modellen und Werkzeugen und stellen diese den Endanwendern mit ArcGIS Server bereit. ([ESRI2]) ArcGIS-Dienste nutzen als Standardprotokoll SOAP und REST. Da während der Diplomarbeit kein Dienst mittels ArcGIS Server erfolgreich aufgesetzt werden konnte, bietet ESRI einen Beispiel-Server an, um mit Musterdaten arbeiten zu können. Unter den Links stehen verschiedene Dienste zur Verfügung. Eine API für REST ist unter esri.com/help/9.3/arcgisserver/apis/rest zu finden. Für die Operation Export Map sieht die API folgendermaßen aus (bis auf bbox sind alle Parameter optional): 19

29 3 Grundlagen Parameter f Details Antwort-Format Werte: html, json, image, kmz Standard: html bbox Ausdehnung (Bounding Box) falls bboxsr nicht angegeben wird, bezieht sich das Referenzsystem auf die Karte Syntax: <xmin>, <ymin>, <xmax>, <ymax> Beispiel: bbox=-104,35.6,-94.32,41 size die Größe des Ausgabebildes Syntax: <width>, <height> Beispiel: size=600,500 Standard: size=400,400 dpi Auflösung des Bildes in dpi (dots per inch) Beispiel: dpi=200 Standard: dpi=96 imagesr räumliches Bezugssystem der Karte standardmäßig wird das Bild mit dem Bezugssystem der Karte ausgegeben bboxsr räumliches Bezugssystem der bbox standardmäßig bezieht sich die bbox auf das Bezugssystem der Karte format Ausgabeformat Werte: png, png8, png24, jpg, pdf, bmp, gif, svg, png32 layerdefs erlaubt das Filtern von Features innerhalb bestimmter Ebenen Syntax: layerid1:layerdef1;layerid2:layerdef2 (LayerID bezieht sich auf die vordefinierten Bezeichnungen) Beispiel: 0:POP2000> ;5:AREA> layers ausgewählte Ebenen es gibt 4 Varianten, um die Ebenen einzustellen: show: diese Ebenen werden exportiert hide: alle Ebenen außer diese werden exportiert include: zusätzlich zu den standardmäßig zu exportierenden Ebenen werden diese Ebenen ausgegeben exclude: abgesehen von diesen Ebenen werden die standardmäßigen Ebenen exportiert Syntax: [show hide include exclude]:layerid1,layerid2 (LayerID bezieht sich auf die vordefinierten Bezeichnungen) Beispiel: layers=show:2,4,7 transparent steuert die Transparenz im Bild true: Hintergrund wird transparent ausgegeben (nur von png und gif unterstützt) false (standardmäßig): Hintergrund wird weiß gesetzt Tabelle 3: API für die Operation Export Map 20

30 3 Grundlagen Abbildung 8 zeigt die Antwort zur Abfrage des Dienstes Weltbevölkerung mit den Parametern BoundingBox (hier: von 0 bis 20 östlicher Länge und 40 bis 60 nördlicher Breite) und Bildgröße (hier; 600x600px). Zusätzlich wurde noch das Ausgabeformat auf image (f=image) gesetzt, um nur das Bild zu bekommen (standardmäßig im png-format). Abbildung 8: REST als HTTP/GET bei ArcGIS-Services Die Daten (insbesondere Geometrien) können auch im sogenannten JSON7-Format ausgegeben werden. Die URI Highway_USA/MapServer/identify?geometryType=esriGeometryPoint&geometry=120%2C40&tolerance=10&mapExtent=-119%2C38%2C121%2C41&imageDisplay=400%2C300%2C96&f=json greift auf den Dienst ESRI_StateCityHighway_USA zu. identify bezeichnet die Methode des Dienstes. Danach folgen die einzelnen Variablen als Key-Value-Pairs. Der Dienst enthält die Geometrien der US-Staaten und der US-Highways. Hier bezieht sich die Abfrage auf Geometrien im Bereich von 119 bis 121 westlicher Länge und 38 bis 41 nördlicher Breite. Listing 3 zeigt die (verkürzte) Antwort darauf: 7 Bei JSON handelt es sich um ein Datenaustauschformat in Textform, das komplett unabhängig von Programmiersprachen ist, aber vielen Konventionen folgt. Es basiert auf einer Untermenge der JavaScript Programmiersprache. [JSON] 21

31 3 Grundlagen { "results":[ { [...] "value":"nevada", "displayfieldname":"state_name", "attributes":{ "OBJECTID":"22", "Shape":"Polygon", "AREA":" ", "STATE_NAME":"Nevada", [...] "POP1999":" ", [..] "WHITE":" ", "BLACK":"78771", [...] "HSEHLD_1_M":"64273", [...] }, "geometrytype":"esrigeometrypolygon", "geometry":{ "spatialreference":{ "wkid":4326 }, "rings":[ [ [ , ], [...] ] ] } }, { [...] "value":"california", "displayfieldname":"state_name", [...] ] } } ] Listing 3: Verkürzte Antwort im JSON-Format Hieraus ist ersichtlich, dass es sich um zwei Datensätze handelt. Beides sind Geometrien von Staaten ("layername":"states"). Weiterhin sind deren Attribute wie Fläche ("AREA":" "), Staat ("STATE_NAME":"Nevada"), Bevölkerungsanzahl von 1999 ("POP1999":" ") und 22

32 3 Grundlagen sogar weitere Angaben, beispielsweise die Anzahl der weißen und schwarzen Bevölkerung ("WHITE":" ", "BLACK":"78771") und die Anzahl der alleinstehenden Männer ("HSEHLD_1_M":"64273") angegeben. Nach dem Attribut geometrytype folgen die eigentlichen Koordinaten ("rings"). In diesem Beispiel handelt es sich jeweils um ein Polygon, dessen einzelne Stützpunkte im WGS84-Format (EPSG-Code 4326) angegeben sind. 23

33 3 Grundlagen 3.3 Stand der SOAP-Unterstützung Standardisierungen OGC Das Open Geospatial Consortium (OGC) befasst sich seit 2004 mit der Umsetzung von WSDL und SOAP für WMS. Das damalige Dokument OWS 2 Common Architecture: WSDL SOAP UDDI 1.0 ([OGC2]) geht bereits auf die Unterstützung der Standards WSDL, SOAP und UDDI für ihre OGC Web Services (OWS) ein. Der Ansatz konnte allerdings nicht den Anforderungen genügen, da das größte Problem darin bestand, dass in einem XML-Dokument keine binären Daten (wie Bilder) gespeichert werden können. Im Discussion Paper WMS Change Request: Support for WSDL & SOAP ([OGC1]) von 2005 wird versucht für den Web Map Service die Implementierung einer WSDL-Datei zu ermöglichen und SOAP als Austauschformat anzubieten. Die Möglichkeit SOAP zu unterstützen, wird im OpenGIS Wrapping OGC HTTP-Get and -POST Services with SOAP Discussion Paper ([OGC3]) behandelt. Die Idee ist, einen HTTP-Request abzufangen und in SOAP umzuwandeln. Genauso auch auf dem Rückweg (Response). Eine genaue Beschreibung über den Inhalt der Dokumente ist in [DAJW] Kapitel 6 nachzulesen. Für die WMS Version 1.4 ist die Umsetzung der jeweiligen Dokumente vorgesehen. Unter befinden sich die aktuellen Akti- vitäten der Standard Working Group für WMS 1.4. Da bisher keine SOAP-fähigen WMS vorhanden sind, wurde im Rahmen der Diplomarbeit ein eigener Web Service erstellt, der das sog. SOAP-Wrapping (siehe Kapitel 4.3.2) übernimmt. Die SOAP-Unterstützung bei den WFS (web feature service) ist so beschrieben, dass ein WFS Client mit einem WFS per SOAP kommuniziert (vgl. [OGC5], Kapitel 6.7). Der WFS direkt ist demnach nicht SOAP-fähig. Gleichermaßens sind die Catalogue Services (CAT) mittels SOAP beschrieben. Folglich ist es möglich Katalog Dienste über SOAP zu erreichen, wenn ein Client davor geschalten ist. 24

34 3 Grundlagen INSPIRE INSPIRE (Infrastructure for Spatial Information in the European Community) ist eine Initiative der europäischen Kommission, die zu einer europaweit einheitlichen Geodaten-Basis verhelfen soll. Dazu zählen vor allem raumbezogene Informationsdienste, also Geo Web Services (siehe Kapitel 3.1.2). Die Studie SOAP HTTP Binding Status ([INSP1]) zeigt den aktuellen Stand der SOAP-Unterstützung für Services, die für INSPIRE von Interesse sind, u. a. OWS. Dabei werden die derzeitigen und zukünftigen Spezifikationen von OGC und ORCHESTRA8 genauer betrachtet. Für die Darstellungsdienste (View Services) gibt es viele Faktoren, die dafür sprechen solche Standards in die Implementing Rules aufzunehmen. Vor allem fordert die INSPIRE Richtlinie einen standardisierten Ansatz. Darüber hinaus ist die Standardisierung im Bereich der Darstellungsdienste bereits soweit fortgeschritten, dass bereits OGC Standards übernommen wurden. Das Dokument SOAP Primer for INSPIRE Discovery and View Services ([INSP6]) demonstriert die Verwendung des vorgeschlagenen SOAP Frameworks ([INSP7]) für INSPIRE-konforme Kartendienste. Im Mittelpunkt steht dabei die Analyse von WSDL-Dateien: die einzelnen Elemente und ihre Eigenschaften werden ausführlich vorgestellt und mit Beispielen demonstriert; weiterhin betrachtet INSPIRE die dazugehörigen SOAP-Nachrichten. Auch hierfür gibt das Dokument Beispiele, die an dieser Stelle kurz vorgestellt werden. <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <soap:body> <getcapabilities </soap:body> </soap:envelope> xmlns="http://inspire.jrc.ec.europa.eu/view" service="wms" version="1.3.0"/> Listing 4: Beispiel-Request für einen GetViewServiceMetadata Listing 4 zeigt einen SOAP-Request, der die Metadaten (GetCapabilities) eines View-Services (speziell eines WMS) zurückgibt. Für diesen Request ist keine Variablenübergabe nötig, da die Antwort ohnehin immer dieselbe ist. Die Antwort darauf enthält die vollständigen Metadaten inklusive INSPIRE-Parametern zum jeweiligen Service. 8 Open Architecture and Spatial Data Infrastructure for Risk Management, Forschungsprojekt der EU zur Schaffung einer offenen Architektur und Infrastruktur für das Umweltrisikomanagement (http://www.eu-orchestra.org) 25

35 3 Grundlagen <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <soap:body> <wms:capabilities version="1.3.0" [...]/> </soap:body> </soap:envelope> Listing 5: Beispiel-Response mit GetCapabilities eines WMS Für einen GetMap-Request würde die SOAP-Anfrage wie folgt aussehen: <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <soap:body> <GetMap xmlns="http://inspire.jrc.ec.europa.eu/view" version="1.3.0" service="wms" xmlns:gml="http://www.opengis.net/gml" > <Layers>highways</Layers> <Styles>ROADS_RIVERS</Styles> <CRS>EPSG:4326</CRS> <bbox> minx= miny= maxx= maxy= </bbox> <Format>image/png</Format> <Transparent>true</Transparent> <BGcolor>0xFFFFFF</BGcolor> <Width>400</Width> <Height>200</Height> <Exceptions>application/vnd.ogc.se_xml</Exceptions> </GetMap> </soap:body> </soap:envelope> Listing 6: SOAP-Anfrage für GetMap Hieraus ist ersichtlich, dass die einzelnen Parameter eines GetMap-Requests von OGC als Variablen in die SOAP-Nachricht eingebunden werden. So wie es auch OGC vorsieht. Die Antwort darauf ist ein gewöhnlicher SOAP-Response. Da bekanntlich ein Bytestream (also ein Bild) vom WMS zurück kommt, wird dieser direkt auch in die SOAP-Nachricht geschrieben. 26

36 3 Grundlagen <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <soap:body> <GetMapResponse xmlns="http://inspire.jrc.ec.europa.eu/view"> /RTRfkgnflkgnf=fndslkfnkldsnfkldsnf43d5fwfsgs4ojojsfiodjs = </GetMapResponse> </soap:body> </soap:envelope> Listing 7: SOAP-Antwort auf GetMap Der Stream wird in INSPIRE mittels MTOM und XOP9 angegangen. Dabei werden wie in Kapitel beschrieben gewisse Teile kodiert in die Nachricht mit eingefügt und nicht kodierbare-teile ausgelagert und die jeweilige URI weitergegeben. Eine genaue Erläuterung über die Funktion von MTOM und XOP ist in [INSP6], Kapitel 4.10 ( MTOM and XOP use ) nachzulesen. Genau nach diesem Schema werden auch die weiteren Kartendienste und ihre Schnittstellen behandelt (z. B. GetFeatureInfo). Mit dem Dokument [INSP6] werden demnach Möglichkeiten dargestellt, wie INSPIRE-Dienste (speziell Kartendienste) mittels SOAP angesprochen werden können. Zu jedem SOAP-Beispiel werden außerdem die dazugehörigen WSDL-Dateien mit ihren benötigten Elementen veranschaulicht. Dies ist aber bisher noch Theorie und es gibt bis jetzt keine INSPIRE-konformen Kartendienste, die während der Diplomarbeit genutzt werden konnten. 9 XML-binary Optimized Packaging, eine W3C-Empfehlung um Binärdaten in XML einzubetten (http://www.w3.org/tr/xop10). 27

37 3 Grundlagen Implementierungen deegree deegree ist eine OGC-konforme WMS-Implementierung. Als freies Java-Framework ermöglicht es die Verwaltung und Darstellung geographischer Daten. Grundsätzlich bietet deegree für verschiedene Dienste eine SOAP-Unterstützung an. Diese bewegen sich jedoch im Rahmen dessen, was in den jeweiligen OGC-Spezifikationen vorgegeben ist. Wie schon in Kapitel erläutert, sind dies nur wenige. Insbesondere beim WMS existieren hierzu kaum praktische Dokumentationen bzgl. SOAP, d. h. eine WMS-Implementierung unter Verwendung von SOAP ist experimentell und daher in deegree auch wenig vorhanden. Lediglich bei GetMap-Anfragen kann eine rudimentäre SOAP-Unterstützung realisiert werden. Dafür bietet deegree die Java-Klasse org.deegree.enterprise.servlet.soap_1_1_facadeservletfilter als sog. Servlet10 Filter an. Abbildung 9 zeigt den Aufbau dieser Klasse. Die Methode handlesoaprequest verarbeitet einen eingehenden SOAP-Request, in der Version 1.1. Dabei wird das Wurzelelement envelope durchlaufen und der Inhalt des body-elementes zurückgegeben. Abbildung 9: UML-Klassendiagramm zu SOAP_1_1_FacadeFilter 10 Servlet ist eine Java-Klasse, deren Instanzen Anfragen von Clients entgegen nehmen und beantworten können ([JSERV]). 28

38 3 Grundlagen Seit Dezember 2008 befindet sich deegree in der Version 2.2. Die beschriebene Implementierung eines Servlet Filters ist erst für die nächste Version vorgesehen. Diese ist bereits als nightly build verfügbar. Das bedeutet, dass sie die neuesten Softwareänderungen enthält. Allerdings wird davon ausgegangen, dass eine nightly build-version nicht hinreichend getestet wurde. Demzufolge wird davon abgeraten eine solche Version einzusetzen. Sie ist ausschließlich für Entwickler zu empfehlen. Im Falle von deegree gibt es bisher nur die Programmierschnittstelle (API) und die dazugehörigen Dokumentationen für die neueste Version (siehe [DGRE1], [DGRE2]). Es sind weder eine WAR-Datei noch der Quellcode erhältlich. Da es sich hierbei also um eine teilweise experimentelle Implementierung handelt, existieren noch keine Dokumentationen bzw. Tutorials, die die Nutzung beschreiben. Es besteht aber die Möglichkeit, sich über eine Mailingliste von deegree mit anderen Softwareentwicklern auszutauschen (http://www.deegree.org/deegree/portal/media-type/html/user/anon/page/default/ js_pane/community%2cmailing-lists). Während der Diplomarbeit wurde kein WMS mittels deegree und der nightly build-version aufgesetzt. Ebenso verfügen weitere WMS-Implementierungen wie GeoServer und UMN MapServer nicht über eine SOAP-Schnittstelle und es bestehen keine Informationen über den aktuellen Stand der Entwicklung in dieser Hinsicht. 29

39 3 Grundlagen 3.4 Orchestrierungstools Der Markt an möglichen Orchestrierungstools ist im Zuge der SOA vergleichsweise groß geworden. Er reicht von frei verfügbar und quelloffen bis zu kostenintensiv und kommerziell. Es gibt sie zusammen in bestehenden Paketen, als stand-alone Werkzeuge und/oder als Tool zum Einbinden in bereits bestehende Systeme. In diesem Kapitel sollen die verschiedenen Möglichkeiten näher betrachtet und vorgestellt werden. Der letzte Abschnitt (3.4.6) begründet die eigene Entscheidung zum jeweiligen Orchestrierungstool Intalio Der Intalio Designer ist frei verfügbar, aber keine OpenSource-Software. Die aktuelle Version kann unter heruntergeladen werden. Zusätzlich ist eine (kostenlose) Registrierung bei intalio.com nötig. Die Installationsdatei kommt als JAR-Datei. Mit einem Doppel-Klick wird die Installation automatisch begonnen. Die Programmoberfläche ist an die Entwicklungsumgebung eclipse angelehnt, genauer gesagt: Intalio nutzt die eclipse-oberfläche für sich. Die Installationsdatei beinhaltet bereits eine vollständige eclipse-version. Die Seite gibt einen guten Einstieg zur Nutzung der Intalio-Produkte. Abbildung 10 zeigt die Programmoberfläche vom Intalio Designer. 30

40 3 Grundlagen Abbildung 10: Programmoberfläche von Intalio Um Prozesse zu erstellen, kann in Intalio neben BPEL auch die BPM ( business process modeling) genutzt werden. Sie ist gewissermaßen die graphische Variante von BPEL. Sie ist die visuelle Dokumentation des Prozesses mit grafischen Modellierungsnotationen (BPMN: business process modeling notation). Die Prozessteilnehmer werden in Pools eingeteilt. Diese können wiederum in Lanes geordnet werden, um die Aufgaben eines Teilnehmers zu kategorisieren. Genauso wie bei BPEL gibt es Activities, die interaktiv in die Oberfläche gezogen werden können. Intalio legt zwar für ein bpmprojekt drei XML-Dateien an (bpdm.canonicwsdl, modeler.bpmn, modeler.bpmn_diagram), die editierbar sind, aber die gleichzeitige Bearbeitung von drei Dateien aufwändig macht. Das folgende Listing 8 stellt einen Ausschnitt aus einer bpmn-datei dar. 31

41 3 Grundlagen <bpmn:bpmndiagram xmi:version="2.0" xmlns:xmi="http://www.omg.org/xmi" xmlns:bpmn="http://stp.eclipse.org/bpmn" xmlns:ecore="http://www.eclipse.org/emf/2002/ecore" xmi:id="_kzcgstevedyjmoclt3lipq" id="_kzcgsdevedyjmoclt3lipq"> <pools xmi:type="bpmn:pool" xmi:id="_kaltktevedyjmoclt3lipq" id="_kaltkdevedyjmoclt3lipq" name="client"> <eannotations xmi:type="ecore:eannotation" xmi:id="_lm-34devedyjmoclt3lipq" source="executablepool"> <details xmi:type="ecore:estringtostringmapentry" xmi:id="_lm34tevedyjmoclt3lipq" key="poolisexecutable" value="false"/> </eannotations> <vertices xmi:type="bpmn:activity" xmi:id="_kaltkzevedyjmoclt3lipq" id="_kaltkjevedyjmoclt3lipq" name="send" activitytype="task"> <outgoingmessages xmi:type="bpmn:messagingedge" href="#_powemtevedyjmoclt3lipq"/> <incomingmessages xmi:type="bpmn:messagingedge" href="#_uyr8tevedyjmoclt3lipq"/> </vertices> </pools> [...] </bpmn:bpmndiagram> Listing 8: Auszug aus einer bpmn-datei Damit die Prozesse ausgeführt werden können, braucht es zusätzlich den Intalio Server. Dieser kann ebenfalls unter heruntergeladen werden. Die Arbeit mit dem Intalio ist durch BPMN sehr vorteilhaft. Dennoch wurde es durch das zusätzliche Installieren des Servers zu mächtig und es kam während der Diplomarbeit zu keinem zufriedenstellenden Ergebnis. 32

42 3 Grundlagen TIBCO Business Studio TIBCO11 Business Studio ist eine Modellierungssoftware, die es dem Nutzer ermöglicht Geschäftsprozesse zu gestalten, anzuwenden und zu verwalten. Abbildung 11: TIBCO Programmoberfläche Sie ist ebenfalls kostenfrei verfügbar und eine proprietäre Software. Seit Dezember 2008 steht die Version (Windows und Linux) zur Verfügung. TIBCO baut ebenso auf eclipse auf (siehe Abbildung 11), was die Handhabung vereinfacht, und wie auch Intalio bedient es sich der BPMN. Als Beschreibung der Geschäftsprozesse wird hier aber XPDL genutzt. Diese kann dann bei Bedarf einfach in einem Editor bearbeitet werden. Eine XPDL-Datei kann mehrere Prozesse beinhalten. Innerhalb des Projektes übernimmt dann die BPMN die grafische Darstellung im Programm. Listing 9 zeigt einen Auszug aus einer XPDL-Datei. 11 The Information Bus Company 12 Download unter (letzter Zugriff: Juli 2009) Installationshandbuch: (letzter Zugriff: Juli 2009) Benutzerhandbuch mit Beispielen und Tutorials: (letzter Zugriff: Juli 2009) 33

43 3 Grundlagen <xpdl2:package xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" [...]> [...] <xpdl2:pools> <xpdl2:pool Id="_RAOCEfQ7EduxZJuosRfoMg" xpdext:displayname="tibco Office" Name="TIBCOOffice" BoundaryVisible="true" Process="_RAOCGvQ7EduxZJuosRfoMg"> <xpdl2:lanes> <xpdl2:lane Id="_RAOCEvQ7EduxZJuosRfoMg" xpdext:displayname="project Team" Name="ProjectTeam"> <xpdl2:nodegraphicsinfos> <xpdl2:nodegraphicsinfo Height="191.0"/> </xpdl2:nodegraphicsinfos> </xpdl2:lane> <xpdl2:lane Id="_RAOCE_Q7EduxZJuosRfoMg" xpdext:displayname="administration" Name="Administration"> <xpdl2:nodegraphicsinfos> <xpdl2:nodegraphicsinfo Height="277.0"/> </xpdl2:nodegraphicsinfos> </xpdl2:lane> </xpdl2:lanes> </xpdl2:pool> <xpdl2:pool> [...] </xpdl2:package> Listing 9: Auszug aus einer xpdl-datei TIBCO stellt die sogenannte tibcommunity13 bereit, die als Plattform dienen soll, um sich mit anderen Nutzern, Partnern und Experten austauschen zu können. Neben dem Business Studio bietet TIBCO den HTTP-Server Asset Central an. Mit diesem können dann die erstellten Prozesse veröffentlicht (deployed) werden. Allerdings ist es nur in der kostenpflichtigen Version (und nur für Windows) erhältlich. Dadurch konnte während der Diplomarbeit mit Hilfe von TIBCO kein Prozess erstellt und getestet werden

44 3 Grundlagen JDeveloper In der Diplomarbeit [DAJW] wurde der JDeveloper 10g der Firma Oracle zusammen mit der Oracle SOA-Suite verwendet. Seit Juli 2009 steht die Version (11g Release 1) zum kostenlosen Download14 für Windows, Linux und Macintosh bereit. Mittels JDeveloper können neben Geschäftsprozessen in BPEL auch Aufgaben in Java, JavaScript, XML, SQL und HTML gelöst werden. Dabei übernimmt das Programm den vollen Entstehungsprozess einer Software, vom Entwurf bis zur Veröffentlichung bzw. Bereitstellung. Die Handhabung in JDeveloper ist einfach und intuitiv gehalten. Per Drag and Drop können die einzelnen BPEL-Elemente (Activities, PartnerTypes, ) auf die Oberfläche gezogen werden. Des Weiteren kann zwischen der Design- und Quellansicht gewechselt werden. Abbildung 12 zeigt die Oberfläche im Designmodus. Abbildung 12: Programmoberfläche von JDeveloper 14 (letzter Zugriff: Juli 2009) 35

45 3 Grundlagen JDeveloper ist Teil des Oracle Produktes BPEL Process Manager (neueste Version 11g R1). Neben dem BPEL-Designer (hier JDeveloper) besteht dieser noch zusätzlich aus BPEL-Server (Bereitstellung von Prozessen), BPEL-Konsole (Zugriff auf Prozesse) und einer Datenbank (Speicherung der Zustände der Prozesse). Der BPEL Process Manager unterstützt die Standards BPEL4WS 1.1 und WS-BPEL 2.0. Um eine komplette Implementierung einer SOA zu realisieren, empfiehlt es sich, das gesamte Paket Oracle SOA-Suite zu nutzen. Weitere Informationen (u. A. Installationsanleitung und Tutorial zur Orchestrierung in JDeveloper) sind in [DAJW] zu finden. Ein großer Nachteil an diesem Produkt ist dessen Größe. JDeveloper und die Oracle SOA-Suite haben einen sehr hohen Speicherverbrauch. Des Weiteren ist es für kleine Anwendungen zu komplex. Aus diesem Grund wurde während der Diplomarbeit auf den Einsatz von JDeveloper verzichtet. 36

46 3 Grundlagen Apache Orchestration Direction Engine Seit 2006 gibt es auch von der Apache Software Foundation ein Orchestrierungstool: die Orchestration Direction Engine (kurz: ODE). Es verarbeitet wie alle gängigen Orchestrierungstools BPEL-Prozesse und kann somit Web Services ansprechen, Nachrichten senden und empfangen und Daten verarbeiten (manipulieren). Es berücksichtigt dabei die Standards WS-BPEL. 2.0 und BPEL4WS 1.1. Die ODE beinhaltet bereits eine BPEL-Engine. Zum Gestalten eines BPEL-Dokuments kann der BPEL-Designer in eclipse genutzt werden. (siehe Anhang) Abbildung 13 zeigt den ODE bzw. die implementierte BPEL-Engine unter Apache Tomcat. Abbildung 13: BPEL-Engine von Apache ODE Das Einstiegsportal für Apache ODE ist Das bisher einzige Forum auf diesem Gebiet ist unter zu finden. Ein großer Vorteil der ODE gegenüber den anderen Tools ist, dass es OpenSource ist. Somit ist der Quellcode für jeden offen erhältlich. Jeder hat das Recht ihn für sich zu ändern und diese Version weitergeben zu können. Es gibt keine Exklusivrechte für bestimmte Nutzergruppen an der Software. 37

47 3 Grundlagen Dennoch ist ein Nachteil anzumerken: Da ODE noch relativ jung und quelloffen ist, haben vor allem Anfänger Schwierigkeiten mit dem Umgang des Tools. Bereits bei der graphischen Bearbeitung (Design-Modus) des BPEL-Codes im BPEL-Designer von eclipse kann es anfangs zu Problemen kommen. Gelegentlich werden Änderungen im Design-Modus nicht im BPEL-Code übernommen. Programmierkenntnisse sind hier von Vorteil. Unter kann die aktuelle WAR15-Datei heruntergeladen und anschließend installieren und eingerichtet (hier: deployed) werden. Aktuell liegt die Version vor. Die Version 2.0 ist bereits in Bearbeitung und steht schon als beta-version zur Verfügung. ODE entspricht überwiegend der BPEL-Spezifikation. Darüber hinaus bietet es BPEL-Erweiterungen, die aus der Sicht von Apache als wichtig erachtet werden. Nachfolgend sollen die wesentlichen Punkte der BPEL-Spezifikation erläutert werden, die ODE (noch) nicht unterstützt (vgl. [ODE1]): <receive> Die <frompart> Syntax wird nicht unterstützt. Stattdessen kann das <variables>-attribut genutzt werden. Des Weiteren können nur die Variablen vom Typ message mit dem <variables>attribut referenziert werden, wohingegen die Spezifikation die Referenzierung auf eine Variable vom Typ element erlaubt, wenn die WSDL diese beinhaltet. Mehrfache Start-Aktivitäten (siehe Abschnitt 10.4 und 15.4 der Spezifikation) werden noch nicht unterstützt, abgesehen von dem Befehl initiate="join". ODE stellt nicht die Ordering Guarantees zur Verfügung und fordert nicht die Ordering Requirements ein (siehe Abschnitt 10.4 der Spezifikation). Demzufolge ist der folgende BPEL-Code <flow> <receive... createinstance="yes"/> <assign.../> </flow> gemäß der Spezifikation nicht erlaubt, aber bei ODE legitim. Die Spezifikation definiert zwei Standardfehler bpel:conflictingrequest und bpel:conflictingreceive um zwei ähnlichen Fehlerzustände zu behandeln. ODE unterscheidet nicht zwischen den beiden. 15 WAR steht kurz für web archive format. Sie beschreibt, wie eine Web-Anwendung in eine JAR- bzw. ZIP-Datei gepackt wird. [WAR] 38

48 3 Grundlagen Das Attribut validate falls vorhanden wird ignoriert. ODE unterstützt derzeit die Funktion der Überprüfung von Variablen nicht. <reply> Genau wie bei der <receive>-aktivität wird die <topart>-syntax nicht unterstützt und variable Attribute müssen auf Variablen vom Typ message verweisen. <invoke> Auch hier werden die <frompart>- und <topart>-syntax nicht unterstützt. Die inputvariable und outputvariable müssen auf Variablen vom Type message verweisen. Das Attribut <validate> wird ignoriert. <assign> Die BPEL-Spezifikation besagt, dass die <assign>-aktivität atomar ist. Bei ODE ist jedes <copy>-element atomar. Wie schon in den vorhergehenden Aktivitäten beschrieben, ignoriert ODE das Attribut <validate>. Folglich wird der Fehler bpel:invalidvariables nie von <assign> ausgelöst. Einzeilige Zuweisungen als Teil der Variablendeklaration werden noch nicht unterstützt. Aktuell nutzt ODE das Attribut expressionlaguage, um die Sprache zu bestimmen, die in den Zuweisungen genutzt wird (anstatt querylanguage). ODE stellt zusätzliche (nicht standardisierte) Erweiterungen zur Verfügungen, die entsprechend der Spezifikation nicht konform sind (vgl. [ODE2]). <pick> Die <pick>-aktivität hat die gleichen Einschränkungen wie <receive>. 39

49 3 Grundlagen <compensate> Diese Aktivität entspricht nicht der Spezifikation. In ODE hat sie den gleichen Effekt und die gleiche Syntax wie <compensatescope>. Außerdem wird das Attribut <scope> an Stelle von <target> mit dem selben Ergebnis genutzt. ODE setzt voraus, dass eines von den Attributen an- gegeben wird. <validate> Diese Aktivität ist noch nicht implementiert. ODE gibt an dieser Stelle einen Kompilierungsfehler aus. Nachfolgend werden nun die wichtigen BPEL-Erweiterungen von ODE vorgestellt (vgl. [ODE2]): Aktivitäten-Erweiterung und erweiterbare Zuweisungsfunktionen (extension activities and extensible assign operations) Apache ODE stellt ein Gerüst für ein plug-in zur Verfügung, womit sich benutzerdefinierte Aktivitäten und Variablenzuweisungen implementieren lassen. Solche plug-ins können bei ODE registriert und im Sinne der Spezifikation (<extensionactivity> und <extensionassign Operation>) genutzt werden. XPath-Erweiterungen ODE ergänzt die von BPEL bereits zur Verfügung gestellten XPath-Unterstützungen, indem zusätzlich XPath 2.0 unterstützt wird und eine Reihe von nützlichen Funktionen bereit gestellt werden, um gewisse Zuweisungen einfacher zu gestalten. Flexible Zuweisungen Erweitert die <assign>-aktivität, sodass Werte ignoriert oder fehlende Werte dem Attribut to-spec der copy-operation hinzugefügt werden. Diese Abkürzung erlaubt dem Nutzer einfach und intuitiv das zu beeinflussen, was normalerweise einen Fehler erzeugen würde. 40

50 3 Grundlagen RESTful BPEL Erweitert die Aktivität <invoke>, sodass RESTful Web Services eingebunden werden können. Diese Ergänzung nutzt BPEL-Variablen vom Typ xsd:uri und xsd:string an Stelle von PartnerLinks. Somit werden auch keine WSDL-Dateien benötigt. Diese Funktion ist allerdings noch nicht in ODE realisiert worden. Es ist vorerst ein Vorschlag, der noch Erfahrungen und Meinungen der Entwickler benötigt. weitere Erweiterungen sollen an dieser Stelle nur genannt werden: implicit correlations (eingeschlossene Wechselbeziehungen) Fehlerbehandlung der Aktivitäten externe Variablen Headers Handling iterable ForEach (wiederholbare ForEach-Anweisung) Zukünftig wird es mit der neuen Version 2.0 verlässlichere Kapazitäten, verbesserte Leistungsfähigkeit und eine endgültige Unterstützung für RESTful Web Services geben. Darüber hinaus bietet Apache stets eine nightly build-version an Weitere Orchestrierungstools Neben den genannten Tools gibt es noch eine Reihe weiterer verfügbarer Programme. Metastorm bietet unter dem Namen Metastorm Business Process Management ein Produkt an, mit dem auf einfachste Weise Geschäftsprozesse erstellt, implementiert, gesteuert, beobachtet und analysiert werden können. Dieses Tool ist Bestandteil anderer Produkte von Metastorm, um somit ein ganzes Paket mit dem Unternehmensarchitekturen realisiert werden können für den Kunden verfügbar zu machen. Demzufolge ist neben dem Process Designer noch eine Process Engine (zum Veröffentlichen der Prozesse), ein Dashboard (eine Art Monitor zur Verwaltung), ein Insight (um in Prozesse einwirken zu können) und vieles mehr erhältlich. Unter library/process_designer.asp kann eine Test-Version heruntergeladen werden. 41

51 3 Grundlagen Da dieses Tool zu umfangreich und nicht frei erhältlich ist, wurde bereits darauf verzichtet die Testversion auszuprobieren. Weiterhin verfügt Skelta über ein Produkt namens Skelta BPM.NET. Wie der Name besagt, basiert das Programm auf der Software-Plattform von Microsoft (.NET). Wie die meisten kommerziellen Produkte gibt es diese Software in mehreren Ausführungen: für Unternehmen, Geschäftsleute, Entwickler und so weiter. Dabei sind Grundelemente wie Designer und Konsole stets enthalten. Darüberhinaus kann Skelta noch mit einem Forms Designer dienen, mit dem vorab schon Ideen kreiert werden können. Als Standardsprache wird die BPMN genutzt. Unter kann eine DemoVersion angefordert werden. Da auch dieses Tool zu mächtig und kommerziell ist, wurde es während der Diplomarbeit nicht getestet. In der Diplomarbeit [DAJW] wurde die Software ActiveVOS getestet. Unter kann nach einer Registrierung eine 30-Tage Testversion heruntergeladen werden. ActiveVOS unterstützt die Standards WS-BPWL 2.0 und BPEL4WS 1.1. Wie die meisten BPEL-Designer stützt sich die Entwicklungsumgebung von ActiveVOS auf eclipse. Per Drag & Drop können die einzelnen Elemente in die Oberfläche gezogen werden. In dieser Umgebung ist es dann auch möglich das Debugging, Testläufe und ein Deployment vorzunehmen. Genauere Informationen zu ActiveVOS können der Diplomarbeit [DAJW] (Kapitel 8.3.1) entnommen werden. Da dieses Tool kostenpflichtig ist, wurde es hier nicht weiter betrachtet Wahl des Orchestrierungstools Um Orchestrierung von Web Services vorzunehmen, wurde sich während der Bearbeitung der Diplomarbeit für die Apache Orchestration Direction Engine (Version 1.3.2) entschieden. Sie bietet den großen Vorteil, dass sie OpenSource und damit auch kostenfrei verfügbar ist. Weiterhin wurde als Webserver der Apache Tomcat in der Version gewählt. Beides sind Produkte der Firma Apache Software Foundation und demzufolge konnten Kompatibilitätsprobleme von vornherein minimiert werden. 42

52 3 Grundlagen Abbildung 14: BPEL-Designer in eclipse Für das Erstellen von Diensteketten kam der BPEL-Designer in eclipse (Version Ganymede 3.4.2) zum Einsatz. Zwar steht dieser Designer seit Mai 2008 erst in der Version zur Verfügung, dennoch überzeugte er mit der einfachen Bedienung. Die einzelnen Elemente können per Drag & Drop in die Arbeitsfläche gezogen werden. Der BPEL-Code wird dann automatisch eingefügt. Es kann sowohl im Design-Modus als auch direkt im Quellcode gearbeitet werden. Abbildung 14 zeigt die Oberfläche (Design-Modus) in eclipse. Selbst die Bearbeitung der WSDL-Datei kann im Design-Modus erfolgen. Der BPEL-Designer gibt auch die Option eine deploy-datei gemäß der Apache ODE anzufertigen (siehe Abbildung 15). Abbildung 15: Paket des BPEL-Designer von eclipse 43

53 3 Grundlagen Weiterhin ist es möglich den Tomcat und ODE selbst in eclipse einzubinden, sodass die Prozesse direkt in der Entwicklungsumgebung erstellt, validiert, deployed, veröffentlicht und getestet werden können. Dies ist in den Anlagen A als Tutorial zu finden. Somit kann sämtliche Software für eine Orchestrierung kostenfrei und quelloffen erworben werden. 44

54 4 Orchestrierung 4 Orchestrierung Ziel einer Orchestrierung ist die Verkettung von Diensten, um somit einen komplett neuen, höherwertigen Dienst bereit zu stellen. Während der Bearbeitung der Diplomarbeit wurden vier Diensteketten praktisch umgesetzt. Dabei wurde besonders auf die Möglichkeiten von BPEL im Allgemeinen und dem Orchestrierungstool Apache ODE im engeren Sinne geachtet. Weiterhin wurde der Mehrwert der Diensteketten berücksichtigt. Dies konnte meist dadurch realisiert werden, indem sie mit gewissen Werten voreingestellt wurden, obwohl eine der großen Eigenschaften einer Orchestrierung die Wandelbarkeit ist, d. h. eine Dienstekette universell einsetzbar ist. Bevor die tatsächlichen Diensteketten vorgestellt werden, bedarf es einiger Voraussetzungen. In den nächsten Unterkapiteln werden die Web Services vorgestellt, die für die Umsetzung der Orchestrierung eingesetzt wurden. Vor allem das SOAP-Wrapping ist von besonderer Bedeutung, da es das Orchestrieren von OWS erst ermöglicht. 4.1 SOAP-Wrapping Wie schon im Kapitel erwähnt, agieren die Web Services untereinander standardmäßig mit dem Austauschformat SOAP. Für die Orchestrierung ist dies unabdingbar. Da aber die Geo Web Services (OGC Web Services), im speziellen die Web Map Services (WMS), dies noch nicht unterstützen (siehe [OGC1]), gibt es zwei Möglichkeiten diese trotzdem für eine Orchestrierung nutzbar also SOAP-fähig zu machen Typisierter Ansatz Bislang verfügen OWS nur über eine HTTP-Schnittstelle. Eine sorgfältigere Umsetzung der SOAPUnterstützung wäre, die Dienste gleich mittels SOAP als Übertragungsprotokoll zu installieren. Da SOAP über HTTP gesendet wird, ist demzufolge auch ein HTTP/GET bzw. POST möglich. In [OGC1] wird der Vorschlag einer direkten Umsetzung von SOAP auf WMS gemacht. Listing 10 stellt schematisch den Aufbau eines solchen SOAP-Requests dar. Im Element <GetMap> sind alle benötigten Parameter für einen GetMap-Request enthalten. 45

55 4 Orchestrierung Dabei wird zusätzlich in StyledLayerDescriptor, BoundingBox und Output unterteilt. In StyledLayerDescriptor sind die darzustellenden Ebenen angegeben (NamedLayer Name). Die BoundingBox gibt die Ausdehnung der Karte an in diesem Falle die linke untere und die rechte obere Ecke. Die Koordinaten dazu (coordinates) werden als GML übermittelt, wobei das Referenzsystem in der Elementdefinition (srsname="epsg:4326") zu finden ist. Informationen zum Ausgabebild sind unter Output deklariert (Format, Size,...). <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <GetMap xmlns:gml="http://www.opengis.net/gml" xmlns="http://www.opengis.net/ows" version="1.1.1" service="wms"> <sld:styledlayerdescriptor xmlns="http://www.opengis.net/sld" xmlns:sld="http://www.opengis.net/sld" version="1.0"> <NamedLayer> <Name>highways</Name> </NamedLayer> </sld:styledlayerdescriptor> <gml:boundingbox srsname="epsg:4326" xmlns="http://www.opengis.net/gml"> <coordinates> , , </coordinates> </gml:boundingbox> <Output> <Format>image/png</Format> <Transparent>true</Transparent> <BGcolor>0xFFFFFF</BGcolor> <Size> <Width>400</Width> <Height>200</Height> </Size> </Output> <Exceptions>application/vnd.ogc.se_xml</Exceptions> <Vendor></Vendor> </GetMap> </soap:body> </soap:envelope> Listing 10: Schematischer Aufbau eines SOAP-Requests nach OGC ([OGC1]) Für die Antwort speziell bei Bildern (also Binärdaten) schlägt [OGC1] vor, das <Body>-Element nicht weiter zu spezifizieren und die Daten als Anhang hinzuzufügen. Dabei soll die Technik SOAP with attachement genutzt werden (siehe Kapitel 3.2.1). 46

56 4 Orchestrierung Eine solche Umsetzung konnte während der Diplomarbeit nicht realisiert bzw. von bestehenden Diensten genutzt werden, da diese einerseits noch nicht standardisiert sind und andererseits WMSImplementierungen (wie deegree oder UMN) bisher keine SOAP-Unterstützung anbieten. Eine eigene Implementierung für SOAP-fähige WMS war im Rahmen dieser Diplomarbeit zu aufwändig Generischer Ansatz Dieses Verfahren belässt den Web Service mit dem Protokoll HTTP/GET bzw. HTTP/POST. Um diesen dennoch mittels SOAP ansprechen zu können, wird ein Vermittler geschaffen, der dies übernimmt. Auf diese Weise ist der Dienst zusätzlich mit SOAP erreichbar. Die Architektur sieht vor, dass der Vermittler den HTTP-Request abfängt und die Key-Value-Pairs (KVP) in einzelne Variablen aufteilt, die dann wiederum als geschlossene KVP an den Dienst gesendet werden. Dabei übernimmt SOAP die Validierung bzgl. der Datentypen und -strukturen und unterstützt das Ganze mit einer Fehlerbehandlung. Abbildung 16: Vorschlag einer Proxy Architektur von OGC [OGC3] Abbildung 16 veranschaulicht den Vorschlag vom OGC zwischen Client und Dienst jeweils einen Proxy16 zu schalten, der die Nachrichten als SOAP weiterleitet. Der Client-side Proxy empfängt einen Request als HTTP/GET bzw. HTTP/POST und transformiert diesen zu SOAP. Der Serverside Proxy erhält diesen SOAP-Request und stellt wieder den anfänglichen HTTP-Request her. Der Dienst selbst ist also auch über SOAP erreichbar. 16 Ein Proxy arbeitet als Vermittler, der auf der einen Seite Anfragen entgegennimmt, um dann über seine eigene Adresse eine Verbindung zur anderen Seite herzustellen. (Quelle: letzter Zugriff: Juli 2009) 47

57 4 Orchestrierung Ein HTTP/GET-Request wie FORMAT=image%2Fpng&TRANSPARENT=true&HEIGHT=200&WIDTH=200 &BBOX= , , , &SRS=EPSG%3A31492&STYLES=default würde als SOAP wie in Listing 11 dargestellt werden. <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <soap:body> <RequestProperty instance" xmlns:xsi="http://www.w3.org/2001/xmlschema- xmlns="http://www.ifgi.de/kvp2xml" xsi:schemalocation="http://www.ifgi.de/kvp2xml <property name="service">wms</property> <property name="version">1.1.1</property> <property name="request">getmap</property> <property name="layers">layer1,layer2</property> <property name="format">image/png</property> <property name="transparent">true</property> <property name="height">200</property> <property name="width">200</property> <property name="bbox"> , , , </property> <property name="srs">epsg:31492</property> <property name="styles">default</property> </RequestProperty> </soap:body> </soap:envelope> Listing 11: WMS-SOAP-Request nach [OGC3] Da es noch keine OWS mit einer solchen Architektur gibt, konnte für diese Diplomarbeit kein OGC-konformer WMS genutzt werden. Stattdessen wurde ein unabhängiger Web Service aufgesetzt, der als Mantel für jeden WMS dienen soll. Bereits in [DAJW] wurde ein solcher Dienst aufgesetzt, der indirekt den WMS aufruft. Im Unterschied zu diesem wurden jetzt die Parameter erweitert, sodass es den Anforderungen einer (zukünftigen) SOAP-Nachricht des OGC nahe kommt. Das bedeutet, dass die einzelnen Variablen (version, layers, styles, bbox,...) jetzt separat behandelt werden können. Vorher konnte nur die gesamte URL übergeben werden. Dies erschwerte das Behandeln von Fehlern und war nicht nutzerfreundlich. 48

58 4 Orchestrierung Mit diesem Web Service lässt sich jeder beliebige WMS aufrufen. Jedoch beinhaltet die Antwort nicht das Bild direkt, sondern eine URL, da die Technik von SOAP with Attachments (siehe Kapitel 3.2.1) hier nicht weiter in Betracht kam. Der Java-Code für das SOAP-Wrapping ist (vereinfacht) in Listing 12 dargestellt. public String GetMap (String endpoint, String version, String layers, String styles, int epsg, String bbox, int width, int height){ String reqparameters="request=getmap&format=image/png&transparent=true&bgcolor=0xffffff", link=null; int number = 0; File img_file=null; URL url; link=endpoint+"?"+reqparameters+"&version="+version+"&styles="+styles+ "&WIDTH="+width+"&HEIGHT="+height+"&BBOX="+bbox+"&LAYERS="+layers+" &SRS=EPSG:"+epsg; url=new URL(link); BufferedImage img=imageio.read(url); img.flush(); ImageIO.write(img,"png",img_file); return "http:// :8080/download/overlay/img"+number+".png"; } Listing 12: vereinfachter Java-Code des SOAP-wrappings Es werden die Variablen endpoint (URL-Pfad bis zum '?'), version, layers, styles, epsg, bbox, width und height übergeben. Die Parameter request, format, transparent und bgcolor bekommen einen festen Wert, da es sich in diesem Falle stets um einen GetMap-Request handelt. Listing 13 zeigt die SOAP-Nachricht. 49

59 4 Orchestrierung <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <SOAP-ENV:Body> <m:getmap xmlns:m="soap-wrapping"> <endpoint>string</endpoint> <version>string</version> <layers>string</layers> <styles>string</styles> <epsg>0</epsg> <bbox>string</bbox> <width>0</width> <height>0</height> <HTWProxy>true</HTWProxy> </m:getmap> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listing 13: GetMap-Request als SOAP-wrapping Für die Implementierung im lokalen Netz der HTW ist zusätzlich eine Proxy-Einstellung nötig, um auch externe WMS erreichen zu können. Von daher wird zusätzlich die bool'sche Variable HTWProxy übergeben. Sobald vom HTW-Lan aus ein externer WMS aufgerufen wird (HTWProxy=true), werden die Proxy-Einstellungen angepasst (siehe Listing 14). if (htwproxy){ System.setProperty("proxyPort", "3128"); System.setProperty("proxyHost", "www-cache.htw-dresden.de"); } Listing 14: Proxy-Einstellungen im Java-Code SOAP-Nachrichten werden mittels HTTP an den jeweiligen Empfänger gesendet. Dadurch kann der Dienst auch direkt über HTTP angesprochen werden. Für den 'Mantel-Dienst' sieht die URL wie folgt aus: &epsg=...&bbox=...&width=...&height=... 50

60 4 Orchestrierung Der vollständige Java-Code ist in der Anlage C zu finden. Die zum Dienst gehörige WSDL-Datei befindet sich auf der CD-ROM. Wie im Kapitel beschrieben, sieht deegree in der nächsten Version vor, eine SOAP-Unterstützung für aufgesetzte WMS zu gewährleisten. Auch dieser Ansatz entspricht im Wesentlichen der generischen Methode eines SOAP-wrappings. Sobald die SOAP-Standardisierung seitens des OGC gewährleistet wird und/oder WMS-Implementierungen mit SOAP erfolgen können, entfällt dieser 'Mantel-Dienst' und die OWS können direkt für eine Orchestrierung genutzt werden. 4.2 Vorhandene Web Services In diesem Kapitel werden bestehende Web Services vorgestellt, die für die Orchestrierungen zum Einsatz kamen. Eine tabellarische Zusammenfassung ist in der Anlage B zu finden OWS Als beispielhafter Vertreter für Geo Web Services wurden die Web Map Services (WMS) für die Umsetzung der Diensteketten genutzt. Wie im Kapitel 4.1 beschrieben, konnten die Dienste nicht direkt implementiert, sondern mussten indirekt aufgerufen werden. Mit dem 'SOAP-Wrapping' kann jeder beliebige WMS aufgerufen werden. Nach diesem Schema können auch die anderen OGC Web Services SOAP-fähig gemacht werden. Ein SOAP-Request für GetFeature eines Web Feature Service (WFS) könnte demnach wie in Listing 15 aufgebaut sein. 51

61 4 Orchestrierung <soap-env:envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <SOAP-ENV:Body> <m:getfeature xmlns:m="soap-wrapping"> <version></version> <service></service> <typename></typename> <filter></filter> <bbox></bbox> <maxfeature></maxfeature> </m:getfeature> <SOAP-ENV:Body> <SOAP-ENV:Envelope> Listing 15: Vorschlag für einen GetFeature-Request im SOAP-wrapping Ausschließlich die Catalog-Services (CSW) sind mittels SOAP zu erreichen (siehe [OGC4]). Für die Umsetzung einer Dienstekette kam der Katalog-Dienst GeoMIS.Sachsen17 zum Einsatz. Mit diesem Service ist es möglich, Metadaten von Geodiensten, Geodaten und Anwendungen zu veröffentlichen und somit bereitzustellen (vgl. [TERRA]). Demnach kann über eine Eingabemaske nach bestimmten Daten und/oder Diensten gesucht werden (siehe Abbildung 17). Abbildung 17: Einstiegsportal von GeoMIS.Sachsen 17 Einstiegsportal: (letzter Zugriff: Juli 2009) 52

62 4 Orchestrierung Ein möglicher SOAP-Request der dazu im Hintergrund versendet wird, ist in Listing 16 dargestellt. <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <SOAP-ENV:Body> <csw:getrecords maxrecords="60" resulttype="results" service="csw" startposition="1" version="2.0.2" xmlns:csw="http://www.opengis.net/cat/csw" outputschema="csw:profile"> <csw:query typenames= "csw:dataset csw:service csw:application csw:datasetcollection"> <csw:elementsetname typenames=""> full </csw:elementsetname> <csw:constraint version="1.0.0"> <ogc:filter xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc"> <ogc:propertyislike escape="\" singlechar="?" wildcard="*"> <ogc:propertyname> AnyText </ogc:propertyname> <ogc:literal>...</ogc:literal> </ogc:propertyislike> </ogc:filter> </csw:constraint> </csw:query> </csw:getrecords> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listing 16: SOAP-Request an das GeoMIS.Sachsen Was also über das Einstiegsportal unter Einsatz eines Clients bewerkstelligt wird, kann auch über SOAP erreicht werden. Wird etwa nach umwelt gesucht, muss in der SOAP-Nachricht das Element <ogc:literal> mit diesem Wert belegt werden. Als SOAP-Antwort bekommt der Nutzer sämtliche Metadatensätze zu den gefundenen Einträgen. In diesem Fall handelt es sich um einen Datensatz (Listing 17). 53

63 4 Orchestrierung <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <soapenv:header>[...]</soapenv:header> <soapenv:body> [...] <cswold:searchresultsnumberofrecordsmatched="1" numberofrecordsreturned="1"> <iso19115:md_metadata xmlns:iso19115= <iso19115:fileidentifier.../> <iso19115:language.../> <iso19115:characterset.../> <iso19115:hierarchylevel.../> <iso19115:contact.../> <iso19115:datastamp.../> <iso19115:metadatastandardname.../> <iso19115:metadatastandardversion.../> <iso19115:identificationinfo.../> <iso19115:referencesysteminfo.../> <iso19115:md_metadata.../> </cswold:searchresults> [...] </soapenv:body> <soapenv:envelope> Listing 17: SOAP-Response vom GeoMIS.Sachsen Die konkreten Metadaten zum gefundenen Datensatz sind im Element <iso19115:identification Info> zu finden. Dort gibt es weitere Kind-Elemente, die die einzelnen Informationen spezifizieren. Die anderen Elemente geben Auskunft über den gesamten Metadatensatz im Allgemeinen (z. B. Datum der Erstellung der Metadaten). Diesen SOAP-Response setzt das GeoMIS.Sachsen in eine nutzerfreundliche HTML-Seite (siehe Abbildung 18) um. 54

64 4 Orchestrierung Abbildung 18: Suchergebnis bei GeoMIS.Sachsen Die dort dargestellte Zusammenfassung sieht im SOAP-Response wie folgt aus: [...] <iso19115:identificationinfo> <iso19119:csw_serviceidentification xmlns:iso19119="http://schemas.opengis.net/iso19119"> [...] <smxml:abstract xmlns:smxml="http://metadata.dgiwg.org/smxml"> <smxml:characterstring> Dieser Dienst stellt Karten des Verwaltungsaltlas Sachsen zur Verfügung. Er liefert Verwaltungsübersichten und administrative Strukturen verschiedener Institutionen (Gerichte, Vermessung, Landesentwicklung, Forst, Kirche, Finanzverwaltung, Polizei, Landwirtschaft, Strassenbau, Umwelt) Wichtiger Hinweis: Punktuelle Darstellungen sind oft nur ortsgenau (z.b.vermessungsämter) und nicht koordinatengenau (z.b.behörden), sie werden daher ab einem bestimmten Maßstab ausgeblendet. </smxml:characterstring> </smxml:abstract> [...] </iso19119:csw_serviceidentification> <iso19115:identificationinfo> [...] Listing 18: Ausschnitt aus dem SOAP-Response vom GeoMIS.Sachsen 55

65 4 Orchestrierung Geo-Datenbanken Neben den Web Services besteht auch die Möglichkeit, Geo-Datenbanken für die Darstellung von raumbezogenen Daten, die über ihre Attribute selektierbar sind, für eine Dienstekette zu nutzen. Schon im Kapitel wurde die mögliche Implementierung der freien Geodatenbank GeoNames vorgestellt. An dieser Stelle wird die Verwendung der Oracle Datenbank der Fakultät Geoinformation mit den Musterdaten von Großschönau präsentiert. Abbildung 19: Relationales Schema MusterGIS Großschönau Abbildung 1918 stellt den Aufbau der Datenbank dar. Das Schema zeigt, dass Geometrien von Straßen, Gebäuden und Flurstücken vorhanden sind. Diese Geometrien sind mit Attributen wie Kennzahl und Größe (Flurstücke), Baujahr und Anzahl der Etagen (Gebäude) und Namen und Zustand (Straßen) versehen. Ferner sind sie mit weiteren Tabellen verknüpft, die beispielsweise Angaben zu den Eigentümern enthalten. Somit lassen sich die Geometrien gezielt abfragen. 18 Quelle: (letzter Zugriff: Juli 2009) 56

66 4 Orchestrierung Um die Geometrien auch bildlich darstellen zu können, muss das Format SDO_GEOMETRY der Datenbank in ein entsprechendes Grafikformat umgewandelt werden. Da dazu eine API für Java vorhanden ist, wurde sogleich ein Dienst aufgesetzt, der das SQL-Statement weiterleitet und das Ergebnis so transformiert, dass am Ende ein Bild (hier wieder als URL) übergeben werden kann. Auch dieser Web Service dient demzufolge als 'Mantel' für eine Geo-Datenbank. Der ausführliche JavaCode ist in der Anlage C zu finden. Für die Diplomarbeit wurde eine Möglichkeit der Datenbank-Anbindung entwickelt. Eine ausführliche Beschreibung des Dienstes ist im Kapitel nachzulesen. Darüber hinaus können auch die Attributwerte (wie Name des Eigentümers) weiterverarbeitet und somit Teil einer Dienstekette sein. Ähnlich wie bei dem eben beschriebenen Dienst können die Daten ausgelesen und in ein entsprechendes Format umgewandelt werden. Die Umsetzung eines solchen Dienstes wurde während der Bearbeitung nicht realisiert ArcGIS-Services Seit der Version 9.2 bietet ESRI neben seinen bisherigen Produkten auch den sogenannten ArcGIS Server an. Dadurch können Unternehmen ihren (GIS-)Kartenbestand über ein Netzwerk veröffentlichen. Daten, Karten, Modelle und Werkzeuge, die mittels ArcGIS Desktop bereitgestellt werden, sind nun für den Kunden mit Hilfe des ArcGIS Server verfügbar (vgl. Kapitel und [ESRI1]). Im Verlauf der Diplomarbeit konnte kein ArcGIS-Service aufgesetzt werden, da bereits die Installation zeitintensiv war und Probleme auftraten. Trotzdem ist es möglich, mit bereits vorhandenen ArcGIS-Services zu arbeiten. Wie bereits in Kapitel geschildert, bietet ESRI dazu eine Testumgebung an. Neben der Option des REST, können die Dienste auch über eine SOAP-Schnittstelle angesprochen werden. Unter World/MapServer?wsdl gibt es sogar eine WSDL-Datei für den in Abbildung 8 (Seite 21) gezeigten Dienst zur Bevölkerungsdichte. Allerdings konnte kein gültiger SOAP-Request erstellt werden, da die Parameterliste von der der REST-URI große Unterschiede aufwies und keine Dokumentation über die SOAPSchnittstelle vorhanden war. Abbildung 20 zeigt schematisch den Aufbau dieser SOAP-Nachricht. 57

67 4 Orchestrierung <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <SOAP-ENV:Body> <m:exportmapimage xmlns:m="http://www.esri.com/schemas/arcgis/9.3"> <MapDescription> <Name>String</Name> <MapArea><Extent/></MapArea> <LayerDescriptions>[...]</LayerDescriptions> <Rotation>[...]</Rotation> <SpatialReference>[...]</SpatialReference> <TransparentColor>[...]</TransparentColor> <SelectionColor>[...]</SelectionColor> <BackgroundSymbol>[...]</BackgroundSymbol> <CustomGraphics>[...]</CustomGraphics> <GeoTransformation>[...]</GeoTransformation> </MapDescription> <ImageDescription> <ImageType> <ImageFormat>esriImageNone</ImageFormat> <ImageReturnType> esriimagereturnurl </ImageReturnType> </ImageType> <ImageDisplay> <ImageHeight>0</ImageHeight> <ImageWidth>0</ImageWidth> <ImageDPI> E0</ImageDPI> <TransparentColor> <UseWindowsDithering> true </UseWindowsDithering> <AlphaValue>255</AlphaValue> </TransparentColor> </ImageDisplay> </ImageDescription> </m:exportmapimage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listing 19: Schematischer Aufbau einer SOAP-Nachricht an einen ArcGIS-Service Dadurch konnte der Einsatz von ArcGIS-Services hier nicht weiter berücksichtigt werden. 58

68 4 Orchestrierung 4.3 Eigene Web Services In diesem Abschnitt sollen die selbst erstellten Web Services vorgestellt werden, die anschließend Teil einer Dienstekette wurden. Eine Übersicht zu den Web Services ist in der Anlage B zu finden. Die Funktionen reichen von Datenverarbeitung über Datenbankabfragen bis hin zu Transformationen. Bei einigen Diensten wird zusätzlich die Variable HTWProxy verwendet. Sie dient dazu, den HTW-eigenen Proxy zu überwinden, um auch externe Funktionen im Internet erreichbar zu machen. Die jeweiligen Ein- und Ausgabeparameter werden stichpunktartig angegeben, genauso wie der konkrete Name des Dienstes. Der EPR19 ist bei jedem Dienst nach folgendem Schema aufgebaut: &parameter2= Katalog-Service und Datenverarbeitung Dienstname: Sammlung Dieser Dienst beinhaltet gleich vier Funktionen. Zwar kann jede Funktion als eigenständiger Web Service aufgesetzt werden, doch wird an diesem Dienst gezeigt, dass auch mehrere Funktionen in einem Web Service verfügbar gemacht werden können. Diese einzelnen Funktionen werden dann bei der Erstellung der SOAP-Nachricht mit SOAP-Action angesprochen. GetData Mit GetData wird das Metainformationssystem von Sachsen (GeoMIS.Sachsen) aufgerufen (siehe Kapitel 4.2.1). Dieses GeoMIS ist eine Art Suchmaschine nach Daten und/oder Diensten mit geographischem Raumbezug. Als Suchergebnis werden die jeweiligen Metadaten der Ressourcen ausgegeben. GetData speichert die gesamten Metadaten des Suchergebnisses in eine Datei, da die direkte Auflistung aller Metadaten bei GeoMIS.Sachsen ab einer gewissen Anzahl nicht möglich ist. Genau diese Einschränkung macht zwar den Dienst GeoData relativ langsam, aber trotzdem noch rentabler als wenn die Ergebnisse vom GeoMIS.Sachsen direkt und manuell in eine Datei gespeichert werden. Die Eingabe beschränkt sich lediglich auf suchwort. 19 Endpoint Reference: Adresse zum Web Service 59

69 4 Orchestrierung Eingabeparameter: <suchwort>string</suchwort> <HTWProxy>true</HTWProxy> Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> Als Antwort kommt der URL-Link zur erstellten XML-Datei. Diese beinhaltet allgemeine Informationen zu den gefunden Metadatensätzen. Im Unterschied zum GeoMIS.Sachsen, kann diese Datei alle (2034, Stand: Juli 2009) Metadatensätze beinhalten. Die Abfrage kann demnach bis zu vier Minuten dauern und es entsteht eine Datei mit einer Größe von etwa 48 MB. Dies erklärt sich dadurch, dass die einzelnen SOAP-Nachrichten nacheinander an das GeoMIS.Sachsen verschickt werden. Die erste Nachricht fragt nach den Datensätzen an der Stelle 0 bis 250, die zweite von 251 bis 500 und so weiter. Bei 2043 Datensätzen wären dies maximal neun Nachrichten. Es ist auch möglich, diese parallel (also gleichzeitig) zu versenden, da sie nicht abhängig voneinander sind. Der Versuch diese neun SOAP-Requests zeitgleich an das GeoMIS.Sachsen zu senden, erzielte zum Einen unterschiedliche Ergebnisse, da die Anfragen sessionabhängig verschickt werden und zum Anderen brachte es den dortigen Server mehrmals zum Absturz. Aus diesen Gründen blieb es beim sequentiellen Versenden der Nachrichten. GetRecById Ähnlich wie bei GetData wird das GeoMIS.Sachsen aufgerufen. GetRecById liefert nunmehr den kompletten Metadatensatz einer bestimmten ID. Die Eingabeparameter sind lediglich id und htwproxy. Zurück kommt wieder der URL-Link zur angelegten XML-Datei. Eingabeparameter: <ID>String</ID> <HTWProxy>true</HTWProxy> Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> 60

70 4 Orchestrierung Transformation Diese Funktion transformiert eine beliebige XML-formatierte Datei (z. B. Die Ergebnisdatei vom GeoMIS.Sachsen) mittels einer selbstdefinierten XSL-Datei. Die Eingabeparameter belaufen sich auf xml (URL zur XML-Datei), xsl (URL zur XSL-Datei), extension (Dateiendung der Zieltransformation) und dem htwproxy. Als Antwort erhält der Nutzer den Link zur transformierten Datei mit der eingegebenen Erweiterung (wurde keine extension angegeben, wird diese standardmäßig auf *.000 gesetzt). Als XSLT-Prozessor wurde der teilweise quelloffene Saxon20 verwendet. Eingabeparameter: <xml>string</xml> <xsl>string</xsl> <HTWProxy>true</HTWProxy> <extension>string</extension> Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> Zippen Zippen verpackt jede gewünschte Datei in ein komprimiertes ZIP-Archiv. Demzufolge beschränken sich die Eingabeparameter auf link (URL der zu zippenden Datei) und htwproxy. Auch hier kommt als Antwort die URL zur ZIP-Datei, welche somit heruntergeladen werden kann. Eingabeparameter: <link>string</link> <HTWProxy>true</HTWProxy> Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> 20 Java-Implementierung: (letzter Zugriff: Juli 2009) 61

71 4 Orchestrierung WMS-Mantel Dienstname: SOAP-Wrapping; Operation: GetMap Wie schon in Kapitel erläutert, besteht die Aufgabe dieses Web Services darin, einen WMS indirekt SOAP-fähig zu machen. Eingabeparameter: <endpoint>string<endpoint> <version>string<version> <layers>string<layers> <styles>string<styles> <epsg>int<epsg> <bbox>string<bbox> <width>int<width> <height>int<height> <HTWProxy>true<HTWProxy> Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> Bildbearbeitung Dienstname: Overlay; Operation: Overlay Overlay kann zwei Bilder mit gewünschter Transparenz übereinander legen. Dementsprechend sind die Eingabeparameter bild1 (URL zum untenliegenden Bild), bild2 (URL zum darüberliegenden Bild) und transparenz (Zahl zwischen 0.0 und 100.0; bedeutet opak). Als Antwort wird die URL zum neu erstellten Bild ausgegeben. Eingabeparameter: <bild1>string</bild1> <bild2>string</bild2> <transparenz>float</transparenz> Aussgabeparameter: <out>http://[server]/pfad/zur/datei</out> 62

72 4 Orchestrierung Koordinatentransformation Dienstname: CTS; Operationen: geo_nach_geopot, geopot_nach_gk, gk_nach_geopot, geopot_nach_wgs84 CTS ist ein Koordinatentransformationsdienst zur Umrechnung von geographischen Koordinaten im WGS84-System zu Koordinaten im Gauß-Krüger-System und zurück. Als Quelle für die inhaltliche Umsetzung des Dienstes diente die Website florkart/skripte/geotrans.htm. Sie beinhaltet Funktionen für Koordinatentransformationen in Gauß-Krüger, geographische Koordinaten mit Potsdam- und mit WGS84-Datum, sowie UTM. Zu jeder Transformation liegt ein Java-Script im Hintergrund, welche im Original von Helmut H. Heimeier stammen und für diese Arbeit angepasst wurden. Bei dem erstellten Koordinatentransformationsdienst geht die Berechnung über die geographischen Koordinaten mit dem in Deutschland gebräuchlichen Potsdam-Datum. Tabelle 4 gibt einen Überblick über die einzelnen Funktionen. Operation Beschreibung Eingabe Ausgabe geo_nach_geopot verschiebt das Kartenbezugssystem vom WGS84 Datum zum (in Deutschland gebräuchlichen) Potsdam-Datum lat, lon lat+lon geopot_nach_gk wandelt geographische Koordinaten in Gauß-Krüger-Koordinaten um; geographische Länge und Breite müssen im Potsdam Datum gegeben sein lat, lon rw+hw gk_nach_geopot wandelt Gauß-Krüger-Koordinaten in geographische Koordinaten um rw, hw lat+lon lat, lon lat+lon geopot_nach_wgs84 verschiebt das Kartenbezugssystem vom (in Deutschland gebräuchlichen) PotsdamDatum zum WGS84 Datum Tabelle 4: Übersicht zu den Transformationsfunktionen 63

73 4 Orchestrierung Die Ausgabeparameter beschränken sich jeweils auf eine Variable, da es nicht gelang einen Web Service aufzusetzen, der mehr als einen Parameter wieder zurückgeben kann. Die Syntax ist aber immer dieselbe: lat+lon bedeutet beispielsweise Die Zeichenkette ist demnach ein String. Für die Nutzung des Dienstes war es im weiteren Verlauf der Arbeit nicht hinderlich, da es in der Orchestrierung (also in BPEL) möglich ist, mittels XPath21 Variablenwerte zu zerlegen. Der Koordinatentransformationsdienst des BKG22 konnte nicht genutzt werden, da dieser zum Einen keine SOAP-Schnittstelle bereithält und zum Anderen durch einen Sicherheitsschlüssel (HTTPS) für eine Java-Programmierung schwer zugänglich gemacht wurde. Andere vergleichbare Dienste wurden nicht gefunden Geo-Datenbanken GeoNames Dienstname: GeoNames; Operation: GetCoord GeoNames stellt eine kostenfreie Datenbank im Internet zur Verfügung (http://www. geonames.org). Sie beinhaltet über 8 Millionen geographische Namen und 6,5 Millionen Attribute. Die Daten sind über Web Services bereitgestellt von GeoNames selbst erreichbar und können auch als Datensatz heruntergeladen werden. Wie schon in Kapitel ausgeführt, gibt es mehrere Möglichkeiten bzw. Web Services um die Daten zu erhalten. In dieser Diplomarbeit wurde der Dienst search eingesetzt. Die Eingabeparameter von seiten GeoNames wurden hier auf vier Parameter beschränkt. Eine Java-API ist unter zu finden. Listing 20 zeigt einen Ausschnitt vom erstellten Java-Code. 21 vom W3C entwickelte Abfragesprache (http://www.w3.org/tr/xpath20, (letzter Zugriff: Juli 2009)) 22 https://upd.geodatenzentrum.de/geodaten/gdz_rahmen.gdz_div?gdz_spr=deu&gdz_akt_zeile=3&gdz_anz_zeile=6&gdz_user_id=0 (letzter Zugriff: Juli 2009) 64

74 4 Orchestrierung ToponymSearchCriteria searchcriteria = new ToponymSearchCriteria(); searchcriteria.setname(name); searchcriteria.setq(q); if(countrycode!=null) searchcriteria.setcountrycode(countrycode); ToponymSearchResult searchresult = WebService.search(searchCriteria); for (Toponym toponym : searchresult.gettoponyms()) { if(isnamerequired){ if(toponym.getname().equalsignorecase(name)){ lat=toponym.getlatitude(); lon=toponym.getlongitude(); } } return "lat+lon"; Listing 20: Ausschnitt aus dem Java-Code zu GeoNames Eingabeparameter: <q>string</q> <name>string</name> <countrycode>string</countrycode> <isnamerequired>true</isnamerequired> <HTWProxy>true</HTWProxy> Ausgabeparameter: <out>lat+lon</out> Erläuterung zu den einzelnen Eingabeparametern: q: sucht in allen Attributen (Ortsname, Landesname, Kontinent, ) name: sucht nur in Ortsname countrycode: sucht unter diesem Land (Bsp.: DE Deutschland) isnamerequired: bool'sche Variable, true bedeutet, dass das Suchwort (q) im Ortsnamen enthal- ten sein soll Ausgegeben werden die Länge und Breite des gefundenen Datensatzes. Bei name=dresden, countrycode=de und isnamerequired=true kommt als Antwort: 65

75 4 Orchestrierung <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:body> <ns1:getcoordresponse xmlns:ns1="geonames"> <out> </out> </ns1:getcoordresponse> </soapenv:body> </soapenv:envelope> Listing 21: SOAP-Response von GeoNames Der Dienst gibt folglich die geographischen Koordinaten eines Ortes wieder Oracle-DB Dienstname: OracleDB; Operation: GetGeometry Um auch zu zeigen wie lokale Geo-Datenbanken angebunden werden können, wurde ein Web Service aufgesetzt, der die Geometrie einer Datenbank auslesen und verarbeiten kann. Dafür wurde die Oracle-Datenbank KS9 der Fakultät Geoinformation der HTW Dresden genutzt. Der Aufbau der dortigen Daten wurde bereits im Kapitel (Abbildung 19, Seite 56) dargestellt. Für die Diplomarbeit wurde sich darauf beschränkt, dass die Geometrie einer Tabelle abgefragt werden kann. Diese Geometrie wird in graphische Daten umgewandelt und dem Nutzer als Bild zurückgegeben. Eingabeparameter: <bbox>string</bbox> <sql>string</sql> <height>0</height> <width>0</width> Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> 66

76 4 Orchestrierung Die Eingabeparameter sind dabei: bbox (Begrenzungsrahmen der abzufragenden Geometrien), sql (das SQL-Statement), height und width (Größe des Ausgabebildes). Die Abfrage nach select geometrie from geb where nutz_ktg='w', also nach Wohngebäuden, in der BoundingBox = , , , ergibt Abbildung 20. Abbildung 20: Ergebnis nach der Datenbankabfrage 4.4 Diensteketten Im Laufe der Diplomarbeit wurden vier Diensteketten umgesetzt. Eine Übersicht dazu ist in der Anlage D zu finden. Eine Orchestrierung bedeutet stets, dass ein neuer Dienst aufgesetzt wird. Wie bei den eigenen Web Services werden in den folgenden Abschnitten die konkreten Dienstnamen aufgeführt. Die jeweiligen Ein- und Ausgabeparameter werden stichpunktartig angegeben. Der EPR ist in diesem Falle nach folgendem Schema aufgebaut: &parameter2=... Für das bessere Verständnis zeigt Tabelle 5 eine Übersicht der genutzten Aktivitäten unter BPEL, die in den folgenden Abbildungen vorkommen. 67

77 4 Orchestrierung Aktivitäten Bedeutung Variablenzuweisung Wird meist bevor und nachdem ein Web Service aufgerufen wird eingesetzt ermöglicht die parallele Abarbeitung von Aktivitäten ruft externe Web Services auf empfängt Informationen steht stets zu Beginn eines BPEL-Prozesses gibt Informationen zurück steht am Ende eines BPEL-Prozesses umschließt eine oder mehrere Aktivität(en), damit sie parallel geschalten werden können Tabelle 5: Übersicht der verwendeten Aktivitäten Katalog-Service Datenverarbeitung Dienstname: DK_GeoMIS-DV; Operation: process Diese Dienstekette benutzt ausschließlich den eigens erstellten Web Service Sammlung. Zwar ist dies folglich keine Kette im eigentlichen Sinne, aber wie im Kapitel schon erläutert, können die einzelnen Funktionen des Dienstes auch selbstständig aufgesetzt werden. Weiterhin wird mit der Dienstekette dargestellt wie mehrere Funktionen eines Web Services orchestriert werden können. Ziel ist es, einen Metadatensatz vom GeoMIS.Sachsen zu transformieren und in ein ZIP-Archiv zu packen, welche dann vom Server heruntergeladen werden können. Eine etwa 50MB große XMLDatei ist gepackt nur noch rund 1,2 MB groß. Zuerst wird die Funktion GetData aufgerufen, danach folgen parallel Zippen und Transformieren (siehe Abbildung 21). Die Eingabeparameter belaufen sich auf suchwort, xsl, extension und htwproxy. 68

78 4 Orchestrierung [...] <bpel:flow name="flow"> <bpel:sequence name="sequence"> <bpel:invoke name="zippen" partnerlink="sammlung_pl" operation="zippen" porttype="ns:sammlung" inputvariable="sammlung_plrequest1" outputvariable="sammlung_plresponse1"> </bpel:invoke> </bpel:sequence> <bpel:sequence name="sequence1"> <bpel:invoke name="trafo" partnerlink="sammlung_pl" operation="transformation" porttype="ns:sammlung" inputvariable="sammlung_plrequest2" outputvariable="sammlung_plresponse2"> </bpel:invoke> </bpel:sequence> </bpel:flow> [...] Abbildung 21: BPEL-Prozess als Design und mit Code-Ausschnitt Eingabeparameter: <m:suchwort>string</m:suchwort> <m:xsl>string</m:xsl> <m:extension>string</m:extension> <m:htwproxy>true</m:htwproxy> Die Variable suchwort entspricht dem Suchwort beim GeoMIS.Sachsen. Falls der Wert frei gelassen wird, werden sämtliche Einträge des GeoMIS.Sachsen zurückgegeben. Die XSL-Datei muss zentral auf einem Server liegen. Da es für den Web Service nicht möglich ist lokale Daten hochzuladen, muss der Wert dieser Variable also entsprechen. Falls die Variable extension (Erweiterung der Datei, die nach der Transformation entsteht) leer ist, wird als Standard- Erweiterung *.000 verwendet. Ausgabeparameter: <xml>http://[server]/pfad/zur/datei0</xml> <zip>http://[server]/pfad/zur/datei1</zip> <TraFo>http://[server]/pfad/zur/datei2</TraFo> 69

79 4 Orchestrierung Die Datei *.xml (Variable xml) enthält die Suchergebnisse vom GeoMIS.Sachsen. Die zip-datei (Variable zip) ist das entsprechende ZIP-Archiv. Unter der Variable TraFo ist die transformierte Datei zu finden. Diese Dienstekette soll vorerst die Theorie einer Orchestrierung veranschaulichen. Für das GeoMIS.Sachsen kann es von Bedeutung sein, dass damit Prozesse automatisiert werden können, wie etwa für die Erstellung einer Übersichtskarte der Blattschnitte für verfügbare Topographische Karten. Dabei kann der gesamte Metadatenbestand abgerufen, nach einschlägigen Wörtern gesucht, selektiert und anschließend in eine GML-Karte transformiert werden. Der Dienst Zippen würde hier wegfallen. Weiterhin können mit dieser Idee die Links der Portalseite aus dem Architekturkonzept der gdi.initiative.sachsen erstellt und aktuell gehalten werden. Die Portalseite soll als zentrale Einstiegsseite bereitgestellt werden, auf der der Nutzer komprimiert Informationen zu den sächsischen Geoportalen erhält und zu diesen per Link weitergeleitet wird. ([GDISA1], Kapitel 4.3.2) WMS Bildbearbeitung Dienstname: DK_WMS-Overlay; Operation: process Die Dienstekette verknüpft die Web Services SOAP-Wrapping und Overlay und verdeutlicht die Verkettung von Geo Web Services. Ziel ist es, einen Ausschnitt zwei überlagerter WMS zu erzeugen. Dafür werden nacheinander die WMSs aufgerufen. Anschließend werden die Bilder übereinander gelegt und der Link zum erstellten Bild zurückgegeben. Eingabeparameter: <m:endpoint1>string</m:endpoint1> <m:layers1>string</m:layers1> <m:styles1>string</m:styles1> <m:endpoint2>string</m:endpoint2> <m:layers2>string</m:layers2> <m:styles2>string</m:styles2> <m:version>string</m:version> <m:epsg>0</m:epsg> <m:bbox>string</m:bbox> <m:width>0</m:width> <m:height>0</m:height> <m:opacity>string</m:opacity> <m:htwproxy>true</m:htwproxy> 70

80 4 Orchestrierung Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> Abbildung 22 zeigt den dazugehörigen BPEL-Prozess und zeigt einen Ausschnitt aus der Datei selbst. [...] <bpel:invoke name="invoke_overlay" partnerlink="overlay_pl" operation="overlay" porttype="ns0:overlay" inputvariable="overlay_plrequest" outputvariable="overlay_plresponse"> </bpel:invoke> <bpel:assign validate="no" name="assign3"> <bpel:copy> <bpel:from> <bpel:literal xml:space="preserve"> <tns:dk_wms-overlay-processresponse xmlns:tns="dk_wms-overlay" xmlns:xsi="http://www.w3.org/2001/xmlschemainstance"> <tns:result></tns:result> </tns:dk_wms-overlay-processresponse> </bpel:literal> </bpel:from> <bpel:to variable="output" part="payload"> </bpel:to> </bpel:copy> [...] </bpel:assign> [...] Abbildung 22: BPEL-Prozess mit Code-Ausschnitt Nach der Eingabe und der Variablenübergabe werden die WMS nacheinander abgerufen. Es ist auch möglich die WMSs parallel aufzurufen, da sie nicht abhängig voneinander sind. Die Logik hinter dem SOAP-Wrapping ('Mantel-Dienst' für WMS) sieht allerdings vor, das entstandene Bild als Datei imgxx.png (XX entspricht einer laufender Nummer) in einem Ordner von Tomcat zu speichern. Würde der Service gleichzeitig in zwei Instanzen je einen WMS abrufen und die Datei 71

81 4 Orchestrierung speichern wollen, kommt es zu dem Konflikt, dass beide Bilder die selbe laufende Nummer bekämen und somit den selben Dateinamen tragen würden. Eine Datei würde verloren gehen, da sie nicht mit diesem Namen gespeichert werden kann. Nachdem zwei Bilder vorliegen, wird der Service Overlay aufgerufen. Ihm werden die Links der Bilder (Response-Variablen von SOAP-Wrapping ) und die Transparenz (vom Nutzer eingegebene Variable) übergeben. Schließlich wird das Ergebnis vom Dienst Overlay an dem Ausgabeparameter der gesamten Dienstekette übergeben: der Link zum Bild Geo-Datenbank Bildbearbeitung Dienstname: DK_OracleDB-WMS; Operation: process In dieser Dienstekette kommen die Web Services mit der Oracle-Datenbank und der Koordinatentransformation zum Tragen. Mittels einer SQL-Abfrage werden Geometriedaten aus der Oracle-Datenbank gelesen und als Bild gespeichert. Anschließend wird ein WMS aufgerufen, der als zusätzlicher Dienst Kartenmaterial unter die Geometriedaten der Datenbank legt. Folglich ist der letzte Dienst der Kette Overlay das Übereinanderlagern der beiden Bilder.. Die Eingabeparameter belaufen sich demnach auf die des GetMap-Requests eines WMS, des SQL-Statements und der Transparenz für die Überlagerung. Auch hier könnten die Web Services OracleDB und SOAP-Wrapping parallel aufgerufen werden, aber da sie wieder auf die gleichen Dateinamen schreiben würden, müssen sie nacheinander geschalten werden. Eingabeparameter: <m:endpoint>string</m:endpoint> <m:version>string</m:version> <m:layers>string</m:layers> <m:styles>string</m:styles> <m:epsg>0</m:epsg> <m:bbox>string</m:bbox> <m:height>0</m:height> <m:width>0</m:width> <m:sql>string</m:sql> <m:opacity> e0</m:opacity> <m:htwproxy>true</m:htwproxy> 72

82 4 Orchestrierung Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> [...] <bpel:receive name="receiveinput" partnerlink="client" porttype="tns:dk_oracledb-wms-process" operation="process" variable="input" createinstance="yes"/> <bpel:assign validate="no" name="assign"> <bpel:copy> <bpel:from> <bpel:literal xml:space="preserve"> <tns:getgeometry xmlns:tns="oracledb" xmlns:xsi="http://www.w3.org/2001/xmlschema -instance"> <bbox></bbox> <sql></sql> <height></height> <width></width> </tns:getgeometry> </bpel:literal> </bpel:from> <bpel:to variable="oracledb_plrequest" part="parameters"> </bpel:to> </bpel:copy> [...] </bpel:assign> [...] Abbildung 23: BPEL-Prozess und Beispiel-Code Mit dieser Dienstekette lassen sich bspw. bestimmte Gebäude farblich hervorheben. Als Grundlage kann eine Luftbildaufnahme gelegt werden. Abbildung 24 zeigt das Ergebnis, wenn nach baufälligen Gebäuden in Großschönau selektiert wird. Der SQL-Befehl ist dann folgendermaßen: select geometrie from geb where baul_zustand='4-baufällig' 73

83 4 Orchestrierung Abbildung 24: Ergebnisbild der Dienstekette DK_OracleDB-WMS Geo-Datenbank Koordinatentransformation Bildbearbeitung Dienstname: DK_Bebauungsplan; Operation: process Zusätzlich zur vorhergehenden Dienstekette, kommt an dieser Stelle der Koordinatentransformationsdienst hinzu. Außerdem ist der Dienst GeoNames Bestandteil dieser Kette. Als Besonderheit wird hier die Orchestrierung einer bereits bestehenden Dienstekette veranschaulicht, da diese selbst einen Web Service darstellen. Darüber hinaus werden schon im BPEL-Prozess Variablen mit Werten belegt, sodass sich die Eingabeparameter auf nur wenige beschränken. Als Ergebnis dieser Orchestrierung wird der Bebauungsplan einer gewünschten Stadt gezeigt. Der Nutzer braucht lediglich den Namen der Stadt eingeben. Der erste Dienst ( GeoNames ) sucht nach den passenden Koordinaten. Da es sich dabei ausschließlich um geographische Koordinaten im WGS84-System handelt, folgt eine zweifache Koordinatentransformation (von WGS84 nach Potsdam-Datum, von PotsdamDatum nach Gauß-Krüger). Nun liegen die Koordinaten (Mittelpunkt) der Stadt vor. Bevor der Dienst bzw. die Dienstekette WMS-Overlay aufgerufen wird, werden dessen Parameter mit festen Werten belegt. Für dieses Beispiel werden die freien WMS TOP.Sachsen und Bebauungsplan (vom GeoSN) genutzt. Die BoundingBox wird aus den Koordinaten von GeoNames errechnet. Direkt im BPEL-Code wird vom Mittelpunkt aus ein Umkreis von Meter errechnet. 74

84 4 Orchestrierung Eingabeparameter: <m:input>string</m:input> Ausgabeparameter: <out>http://[server]/pfad/zur/datei</out> [...] <bpel:copy> <bpel:from> <![CDATA[ concat( substring-before ($CTS_PLResponse1.parameters/rwhw,"+")-1500,",", substring-after ($CTS_PLResponse1.parameters/rwhw,"+")-1500,",", substring-before ($CTS_PLResponse1.parameters/rwhw,"+")+1500,",", substring-after ($CTS_PLResponse1.parameters/rwhw,"+")+1500,) ]]> </bpel:from> <bpel:to part="payload" variable="dk_wmsoverlay_plrequest"> <bpel:query querylanguage="urn:oasis:names:tc:wsbpel:2.0:sublan g:xpath1.0"> <![CDATA[ns1:bbox]]> </bpel:query> </bpel:to> [...] </copy> [...] Abbildung 25: BPEL-Prozess mit Beispiel-Code Der Ausschnitt des BPEL-Codes in Abbildung 25 zeigt den Xpath-Ausdruck (rot unterlegt) für die Errechnung der BoundingBox. Die Response-Variable der Koordinatentransformation wird dabei aufgesplittet und die Werte mit aufsummiert bzw. subtrahiert. 75

85 4 Orchestrierung Abbildung 26: Ergebnis der Dienstekette DK_Bebauungsplan für den Bereich Radebeul Abbildung 26 zeigt das Ergebnis für Radebeul. Die eingefärbten Flächen sind die Antwort vom WMS Bebauungsplan des Raumplanungsinformationssystems des Freistaates Sachsen (http://egov.rpl.sachsen.de/wms/com.esri.wms.esrimap/sn_bplan). 76

86 4 Orchestrierung INSPIRE-Dienstekette An dieser Stelle wird der Anwendungsfall 'Bedienung INSPIRE Request' der gdi.initiative.sachsen ([GDISA1], Kapitel 5.2.1, siehe Abbildung 27) vorgestellt und wie dieser in eine Orchestrierung umgesetzt werden kann. Hier wird von einem sogenannten Downloaddienst gesprochen, der durch einen INSPIRE-Request erreichbar ist. Dabei sind einfache WFS (web feature service) gemeint. Abbildung 27: Sequenzdiagramm eines INSPIRE-Requests Sie stellen die reinen Geometrien von Objekten zur Verfügung. Ihre Daten können aus Shapefiles oder Datenbanken bezogen werden. Bei einem GetFeature-Request an das WFS wird das Format GML (geography markup language) zur Ausgabe der Objekte genutzt. Für eine GDI hat der WFS folgende Bedeutungen: Datenquelle für ein GIS Datenquelle für einen WMS direkte Darstellungsmöglichkeit (über Darstellungsvorschrift) in einem Kartenclient bei INSPIRE: Downloaddienst Genauso wie bei den WMS können auch die WFS SOAP-fähig gemacht werden. Bisher ist die SOAP-Unterstützung für WFS seitens des OGC noch nicht ganz ausgereift (siehe Kapitel 3.3). Die Geometriedaten eines gleichen Objekts können in verschiedenen WFS unterschiedliche Attribute beinhalten. Beipsiel: WFS A bietet die Geometrien von Straßen mit der Breite der Fahrbahn als Attribut. WFS B enthält ebenfalls Straßengeometrien. Allerdings mit dem Attribut Fahrbahnbelag. 77

87 4 Orchestrierung Nun kann eine Dienstekette einen neuen WFS darstellen, der nach den Straßengeometrien von A und B fragt und diese vereint. Demzufolge stehen diesem neuen WFS diese Geometrien zur Verfügung. Abbildung 28: Ablauf der INSPIRE-Dienstekette Abbildung 28 verdeutlicht schematisch den Ablauf dieser Dienstekette. Parallel werden zunächst die beiden WFS nach ihren Geometrien (anhand Filter) abgefragt. Diese GML-Daten werden im Anschluss jeweils nach INSPIRE-Vorgaben mittels XSLT transformiert. Gegebenenfalls müssen an dieser Stelle noch Koordinatentransformationen stattfinden. Als Zwischenergebnis liegen nun zwei INSPIRE-GML-Daten vor. Um eine vollständige GML-Datei zu bekommen, wird letztlich nochmals transformiert bzw. die beiden Daten vereint. Als Endergebnis steht eine GML-Datei zur Verfügung. Diese kann direkt ausgegeben (bei SOAP-Anfragen dann als Inhalt des Body-Elements) oder als Datei abgespeichert werden. Somit kann ein neuer WFS aufgesetzt werden, der sich auf diese Datei bezieht. Damit dieser WFS einen INSPIRE-Request gerecht wird, muss dieser ebenfalls mit einem SOAP-Wrapping versehen werden. 78

88 4 Orchestrierung Bei dieser Herangehensweise werden die Daten für den WFS offline zur Verfügung gestellt. Das bedeutet, dass die Dienstekette manuell ausgelöst werden muss, damit ein aktueller Bestand vorliegen kann. Dieses Auslösen kann ein weiterer Dienst übernehmen, der in regelmäßigen Abständen einen Request an die Dienstekette verschickt. Eine Abfrage an das WFS bedient demnach nicht die Dienstekette, sondern fragt praktisch nur nach seinen Daten ab. Die Option die externen WFS-Daten direkt mit dem INSPIRE-Reqeust abzufragen, ist auch möglich. Dabei muss eine Schnittstelle geschaffen werden, die den Request entgegen nimmt. Anschließend wird dieser in einen gültigen GetFeature-Request umgewandelt und an die WFS weiterleitet. Die Antwort (die jeweiligen GML-Daten) werden als nächstes so transformiert, dass wieder ein INSPIRE-konformer Response ausgegeben werden kann. Es genügt also in der Dienstekette einen Dienst einzufügen, der den Request umwandelt. Auf diese Weise wird bei einem Request die Dienstekette direkt angesteuert und die Daten aktuell herausgegeben. 79

89 4 Orchestrierung 4.5 Deployment der Diensteketten Um Diensteketten auch nutzen zu können, müssen sie deployed werden. Dabei wird einfach eine deploy.xml angefertigt. Als sogenannter Deployment Descriptor funktioniert sie wie eine Konfigurationsdatei, die zur Laufzeit der BPEL-Engine befolgt wird. Im Falle des Apache ODE enthält sie Informationen zum BPEL-Prozess, genauer gesagt zu den einzelnen Rollen, die der Prozess beinhaltet. Listing 22 zeigt den Inhalt von deploy.xml der Dienstekette WMS-Bildbearbeitung (siehe Kapitel 4.4.2). <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:coat="coat" xmlns:coat_overlay="coat_overlay" xmlns:overlay="overlay"> <process name="coat_overlay:coat_overlay_process"> <active>true</active> <retired>false</retired> <process-events generate="all"/> <provide partnerlink="client"> <service name="coat_overlay:coat_overlay_service" port="coport"/> </provide> <invoke partnerlink="coatpl"> <service name="coat:coat" port="coatsoap"/> </invoke> <invoke partnerlink="overlaypl"> <service name="overlay:overlay" port="overlaysoap"/> </invoke> </process> </deploy> Listing 22: Beispiel einer deploy.xml Die ersten beiden Parameter (<active>, <retired>) geben Aufschluss darüber, ob der Prozess abrufbar ist. Wird <retired> auf true gesetzt, bedeutet dies, dass der Prozess außer Dienst ist. Unter <provide partnerlink> steht der interne Dienst, also der aus diesem Prozess entstandene Dienst. Die externen Dienste sind unter <invoke partnerlink> zu finden. Beide Male sind lediglich Referenznamen angegeben. Die genaue Schnittstelle ist dann im BPEL-Code direkt zu finden. 80

90 4 Orchestrierung Abbildung 29: deploy.xml in eclipse Der BPEL-Designer in eclipse vereinfacht die Erstellung einer solchen Datei, da mit Hilfe einer Eingabemaske die Dienste zugeordnet werden können. Abbildung 29 zeigt die deploy.xml der Dienstekette WMS-Overlay als Datei in eclipse. Sobald Apache ODE die deploy.xml abgearbeitet, den BPEL-Code und die WSDL-Datei(en) überprüft hat, wird eine deployed-datei erstellt. Diese Datei ist stets leer. Sie dient der ODE nur als Anhaltspunkt, dass die dazugehörigen Dokumente bereits überprüft wurden. Ob der Prozess valide ist, steht in der Log-Datei von Tomcat (siehe Listing 23). 81

91 4 Orchestrierung [...] DEBUG - GeronimoLog.debug(66) register: {DK_WMS-Overlay}DK_WMS-Overlay-Process [...] DEBUG - GeronimoLog.debug(66) Create AxisService: service={dk_wms-overlay}dk_wmsoverlay port=dk_wms-overlayport WSDL=DK_WMS-Overlay-ProcessArtifacts.wsdl BPEL=DK_WMS-Overlay-Process.bpel DEBUG - GeronimoLog.debug(66) Get import: import=soap-wrapping.wsdl parent=file:/c:/programme/apache/tomcat6/webapps/ode/web-inf/processes/dk_wmsoverlay/dk_wms-overlay-processartifacts.wsdl DEBUG - GeronimoLog.debug(66) Get import: import=overlay.wsdl parent=file:/c:/programme/apache/tomcat6/webapps/ode/web-inf/processes/dk_wmsoverlay/dk_wms-overlay-processartifacts.wsdl [...] DEBUG - GeronimoLog.debug(66) Created external service {SOAP-Wrapping}SOAPWrapping [...] INFO - GeronimoLog.info(79) Registered process {DK_WMS-Overlay}DK_WMS-OverlayProcess. INFO - GeronimoLog.info(79) Deployment of artifact DK_WMS-Overlay successful: [{DK_WMS-Overlay}DK_WMS-Overlay-Process] Listing 23: Ausschnitt aus der log-datei Hier wird auch nochmal deutlich wie die einzelnen WSDL-Dateien zugeordnet werden. 82

92 4 Orchestrierung 4.6 Zugriff auf Web Services Sobald ein Web Service aufgesetzt wurde, ist dieser über SOAP (bzw. HTTP) erreichbar. Das Grundgerüst ist demnach erstellt. Der Dienst braucht nichts Weiter, um laufen zu können. Nur die WSDL-Datei und ein Client werden für eine Anfrage benötigt. Dieses Kapitel soll einen Überblick darüber verschaffen, wie eine nutzerfreundliche Schnittstelle realisiert werden kann. Nicht jeder Nutzer kann mit SOAP-Nachrichten umgehen. Dafür werden sog. Clients entwickelt und eingesetzt. Sie stellen eine Anwendung dar, welche mit den Web Services kommuniziert. (vgl. [DAJW]) Apache ODE Leider gibt es bei Apache ODE keine BPEL-Konsole, die dynamisch Eingabefelder generiert und somit eine einfache Schnittstelle zum Testen bereitstellt. Stattdessen bietet ODE eine Batch-Datei (sendsoap.bat) an, mit der über eine Kommandozeile eine SOAP-Nachricht verschickt werden kann. Dafür muss vorerst eine soap-datei erstellt werden, die die SOAP-Nachricht enthält (siehe Abbildung 30). Dies kann in jedem beliebigen Texteditor geschehen. Abbildung 30: SOAP-Datei, erarbeitet in Notepad++ mit Syntaxhervorhebung 83

93 4 Orchestrierung Nun kann mit der Eingabeaufforderung (unter Windows: Start Zubehör Eingabeaufforderung) die Batch-Datei gestartet werden. Voraussetzung dafür ist, dass die Umgebungsvariable ODE_HOME auf den Ordner gesetzt ist, wo sich die Quelldaten (mit Unterordnern wie bin und lib) von ODE befinden siehe Abbildung 31). Für gewöhnlich sind diese in der Download-Datei neben der WARDatei enthalten. Abbildung 31: Pfad zur ODE Die Batchdatei kann nun mit folgenden Parametern aufgerufen werden: sendsoap [-o <outfile>] <url> <file> [-s <proxyserver>] [-p <proxyport>] [-u <user name>] [-w <password>] [-a <soapaction>] Die folgende Tabelle erläutert die einzelnen Parameter im Detail: Parameter Bedeutung -o <outfile> legt Datei an, worin die Ausgabe gespeichert wird (standardmäßig wird sie direkt in der Konsole ausgegeben) <url> Empfänger der SOAP-Nachricht <file> Datei, die die SOAP-Nachricht entählt -s <proxyserver> Proxy-Einstellungen, Server -p <proxyport> Proxy-Einstellungen, Port -u <username> Proxy-Einstellungen, Nutzername -w <password> Proxy-Einstellungen, Passwort -a <soapaction> SOAP-Action, um den Header einzubinden Tabelle 6: Parameter von sendsoap.bat 84

94 4 Orchestrierung Für einen einfachen SOAP-Test genügt der Aufruf sendsoap datei.soap. Am Beispiel der Orchestrierung WMS-Overlay sehen der Aufruf und die Antwort wie folgt aus: Abbildung 32: Kommando sendsoap in der Eingabeaufforderung Der SOAP-Response ist in dem Fall in den letzten Zeilen zu finden. Mit dieser Batchdatei kann jeder beliebige Web Service mittels SOAP aufgerufen werden. Der Dienst muss auch nicht lokal aufgesetzt sein. Allerdings ist diese Methode mehr als nutzerunfreundlich und nur für Testzwecke für den Entwickler gedacht Software-gestützt Es gibt bereits verschiedene Software, die SOAP-Nachrichten generieren, versenden und empfangen können. In der SOAP-Welt ist wohl soapui23 die bekannteste Software. Die Basisversion ist frei erhältlich; soapui pro enthält zusätzliche Features und ist kostenpflichtig. Neben dem Erstellen von SOAP-Nachrichten ist es weiterhin möglich Web Services einer bestimmten Last auszusetzen. Die eigentliche Funktion von soapui bezieht sich also auf den Test für SOAP auf Web Services. 23 Die aktuellste Version 3.0 kann unter (letzter Zugriff: Juli 2009) heruntergeladen werden. 85

95 4 Orchestrierung Abbildung 33: soapui mit SOAP-Request und -Response In Abbildung 33 ist zu erkennen, dass die jeweiligen SOAP-Nachrichten gegenüber dargestellt werden (links der Request, rechts der dazugehörige Response). Bevor eine Nachricht generiert werden kann, muss die WSDL-Datei importiert werden. Ganz links ist eine Übersicht der verfügbaren Bindings und Operationen zu finden, die soapui automatisch aus der WSDL generiert. Mit dem Button Submit request to specified endpoint URL wird die Nachricht an den Empfänger geschickt. soapui ist auch in der Lage Anhänge (Attachments) zu empfangen. Für einen simplen Test der SOAPSchnittstelle reicht diese Software demnach vollkommen aus. Des Weiteren bietet Altova XMLSpy24 die Möglichkeit mit SOAP umzugehen. XMLSpy ist im Prinzip ein Editor, mit dem sich XML-formatierte Dokumente erstellen lassen. In Bezug auf SOAP wird ähnlich wie bei soapui zuvor eine WSDL-Datei importiert bzw. referenziert. Darauffolgend werden die Bindings und Operationen ausgewählt. Danach erstellt XMLSpy sofort ein Gerüst für einen SOAP-Request. Die einzelnen SOAP-Parameter (Endpoint/Empfänger und SOAP-Action) können nachträglich unter SOAP SOAP Request-Parameter ändern geändert werden. Unter SOAP Request an Server senden verschickt XMLSpy die Nachricht. Die Antwort wird als neue Datei geöffnet. 24 Eine 30-Tage Testversion kann unter heruntergeladen werden. 86

96 4 Orchestrierung Abbildung 34: SOAP-Gerüst in Altova XMLSpy Neben diesen beiden Anwendungen gibt es noch zahlreiche weitere Möglichkeiten SOAP-Nachrichten zu versenden. In [DAJW] werden weitere SOAP-Clients vorgestellt. Zum Einen kann unter online eine SOAP-Nachricht verschickt werden; zum Anderen können auch Clients heruntergeladen werden. Diese Alternativen wurden während dieser Diplomarbeit nicht weiter betrachtet. 87

97 4 Orchestrierung Browserbasierte Anwendungen Die nutzerfreundlichste Schnittstelle für einen Web Service ist wohl die Anwendung in einem Internet-Browser. Da ohnehin der Nutzer schon mit dem Browser arbeitet, soll er nicht noch zusätzlich mit anderen (unbekannten) Anwendungen oder gar Software hantieren müssen. Verschiedene Scriptsprachen bieten bereits eine SOAP-Extension an. Für Python existieren Python SOAP als freie Bibliothek und ZSI (Zolera SOAP Infrastructure) mit SOAPpy, die beide als Toolkit eingesetzt werden können25. Bei Perl gibt es ebenfalls eine freie (open-source) Bilbiothek. SOAP::WSDL ermöglicht es in einfachen Schritten mittels der WSDL-Datei ein Interface zu schaffen26. In dieser Diplomarbeit wurde sich auf PHP27 konzentriert, da sie weit verbreitet und schnell zu erlernen ist. Die Syntax ist an die Programmiersprache C angelehnt. PHP wird vorrangig zur Erstellung von dynamischen Webseiten und/oder Webanwendungen verwendet. Die aktuellste Version 5.3 kann unter (letzter Zugriff: Juli 2009) heruntergeladen werden. Um eine eigens erstellte PHP-Seite über ein Netzwerk veröffentlichen zu können, braucht es einen Server (z. B. Apache HTTP-Server28). Das Tutorial Apache 2.2 für den Betrieb mit PHP konfigurieren in der Anlage A beschreibt wie PHP unter Apache geschalten werden kann und wie die SOAP-Extension in PHP konfiguriert wird. An dieser Stelle soll das PHP-Skript im Vordergrund stehen. Um eine SOAP-Nachricht verschicken zu können, muss dem PHP die WSDL-Datei bekanntgemacht werden. Daraus bezieht er dann den Empfänger der Nachricht. Die einzelnen Parameter müssen vom Entwickler selbst definiert werden. Damit sie beim Empfänger korrekt ankommen, müssen diese in einem Array festgelegt werden. Sobald die Parameter mit Werten belegt sind, kann der Web Service angesprochen werden. Es bedarf keiner manuellen Erstellung einer SOAP-Nachricht. PHP übernimmt dies. Listing 24 zeigt die grundsätzliche Vorgehensweise. 25 Python: (letzter Zugriff: Juli 2009) Python SOAP: (letzter Zugriff: Juli 2009) ZSI und SOAPpy: (letzter Zugriff: Juli 2009) 26 Perl: (letzter Zugriff: Juli 2009) SOAP::WSDL: (letzter Zugriff: Juli 2009) 27 PHP: Hypertext Preprocessor 28 (letzter Zugriff: Juli 2009) 88

98 4 Orchestrierung <?php function soaprequest() { global $r; $loc = 'http://[server]/[service]?wsdl'; $req = array( [Parameter] ); $client = new SoapClient($loc); $result = $client->[soap-action]($req); $r = $result->[outputvariable des Services]; }?> Listing 24: grundsätzlicher PHP-Code mit SOAP Wird bspw. der Dienst WMS-Overlay zugrunde gelegt, sieht der PHP-Code folgendermaßen aus: <?php function soaprequest() { global $r; $loc = 'http:// :8080/ode/processes/dk_wms-overlay?wsdl'; $req = array( 'endpoint1' => $_POST['endpoint1'], 'layers1' => $_POST['layers1'], 'styles1' => $_POST['styles1'], 'endpoint2' => $_POST['endpoint2'], 'layers2' => $_POST['layers2'], 'styles2' => $_POST['styles2'], 'version' => $_POST['version'], 'epsg' => $_POST['epsg'], 'bbox' => $_POST['bbox'], 'width' => $_POST['width'], 'height' => $_POST['height'], 'transparenz' => $_POST['transparenz'], 'HTWProxy' => $_POST['HTWProxy'] ); $client = new SoapClient($loc); $result = $client->process($req); $r = $result->result; }?> Listing 25: PHP-Code mit SOAP, am Beispiel der Dienstekette WMS-Overlay 89

99 4 Orchestrierung Die Zeilen 'endpoint1'=>$_post['endpoint1'][...] bedeuten, dass der Wert rechts neben dem => an die entsprechende Position des Arrays geschrieben wird. Es handelt sich dabei um ein soge- nanntes Assoziatives Array. Die Indizes tragen hier individuelle Bezeichnungen. Der syntaktische Aufbau der Zeile ist 'indexname'=>wert. $_POST referenziert dabei auf ein Eingabfeld im Layout: <input type="text" id="endpoint1" name="endpoint1" class="input"/> (zufällig sind hier die Namen gleich). Des weiteren wird ein SoapClient ($client=new SoapClient($loc);) instanziert. Dieser bezieht sich auf die oben definierte WSDL-Datei ($loc='http:// :8080/ ode/processes/dk_wms-overlay?wsdl';). Der Web Service wird mittels dem Befehl $client ->process($req) gestartet. process ist in diesem Fall die SOAP-Action des Dienstes. Der Rückga- bewert wird in das Array $result geschrieben. Um das konkrete Ergebnis zu bekommen, muss nun auf den Variablennamen referenziert werden: $result->result. Die gesamte Funktion soaprequest wird ausgelöst sobald auf einen Start-Button geklickt wird. Da das Ergebnis dieses Dienstes ein Link zum Bild ist, wird dieser String als Quelle für ein <img>-tag übergeben. <?php?> echo '<img src="'.$r.'" alt="" title="" />'; Listing 26: PHP-Ausschnitt mit <img>-tag Die Gestaltung der Webseite sollte stets nutzerfreundlich gehalten sein. Während der Diplomarbeit wurde für jede Dienstekette eine schlichte PHP-Seite erstellt. 90

100 4 Orchestrierung Abbildung 35: PHP-Seite für die Dienstekette WMS-Overlay Abbildung 35 zeigt beispielhaft eine solche Seite. Links ist ein Bild des BPEL-Prozesses (erstellt aus dem BPEL-Designer in eclipse) zu finden, welcher mit einem Mausklick vergrößert werden kann. Daneben befinden sich die Eingabefelder für den Dienst. Zusätzlich besteht die Option Voreinstellungen zu übernehmen. Sobald der Button Submit bestätigt wird, werden das PHP-Script ausgeführt und die SOAP-Nachricht an den Web Service (also der Dienstekette) gesendet. Das Resultat ist dann rechts neben den Eingabefeldern zu finden. In diesem Beispiel ist es jeweils das Bild. Bei der Dienstekette GeoMIS-DV werden die Links zu den Dateien aufgelistet. 91

Orchestrierung von Geo Web Services

Orchestrierung von Geo Web Services Fakultät Geoinformation Studiengang Kartographie Orchestrierung von Geo Web Services Diplomarbeit zur Erlangung des akademischen Grades Diplom-Ingenieurin für Kartographie (FH) Tag der Einreichung: 16.

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Makologa Touré Damian Gawenda

Makologa Touré Damian Gawenda Vortrag von Makologa Touré Damian Gawenda im ITT am 08. August 2006 07.08.06 Makologa Touré Damian Gawenda 1 Übersicht Was ist ein WMS? Web-Technologien Wie installiere ich einen Web-Map-Server? 07.08.06

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Generische WPS-Dienste und deren Umsetzung

Generische WPS-Dienste und deren Umsetzung Generische WPS-Dienste und deren Umsetzung Workshop Standardisierte Dienste im UIS am Marcus Briesen disy Informationssysteme GmbH Agenda Generische WPS Dienste? Kurzvorstellung WPS Der Weg zum Generischen

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Tutorial zu WS-BPEL Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Universität Hamburg Department Informatik Arbeitsbereich VSIS Gruppe 01: Johannes Kuhlmann,

Mehr

CITRA-ConfigCenter, Geodata-Warehouse, CITRA-ExportCenter & Geodatenshop Aufbau einer GDI mit CITRA Tools

CITRA-ConfigCenter, Geodata-Warehouse, CITRA-ExportCenter & Geodatenshop Aufbau einer GDI mit CITRA Tools CITRA-ConfigCenter, Geodata-Warehouse, CITRA-ExportCenter & Geodatenshop Aufbau einer GDI mit CITRA Tools CITRA Forum Sinzig 16.09.2009 Markus Lindner, CISS TDI GmbH CITRA-Forum Agenda Einführung GDI Fazit

Mehr

Architektur der Geodateninfrastruktur Deutschland

Architektur der Geodateninfrastruktur Deutschland Architektur der Geodateninfrastruktur Deutschland Version 2.0 Auszug Teil IV: Anhang Verzeichnis der referenzierten Standards Konzept zur fach- und ebenenübergreifenden Bereitstellung und Nutzung von Geodaten

Mehr

Datenbanken und Internet

Datenbanken und Internet Datenbanken und Internet XML-Schema oder DTD XML-Datei XML-Datei XML-Datei XML-Datei XML-Datei Validating XML Parser Application? Applikation / Anwendung Was ist das eigentlich? Wofür und für wen? Wie

Mehr

Projekt: Erstellung eines Durchführungskonzeptes mit Prototyp für ein landesweites Katastrophenschutzportal. - HW- und SW-Anforderungen des Prototypen

Projekt: Erstellung eines Durchführungskonzeptes mit Prototyp für ein landesweites Katastrophenschutzportal. - HW- und SW-Anforderungen des Prototypen - HW- und SW-Anforderungen des Prototypen Version: 0.3 Projektbezeichnung Projektleiter Verantwortlich KatS-Portal Dr.-Ing. Andreas Leifeld Patrick Hasenfuß Erstellt am 09/06/2011 Zuletzt geändert 10/06/2011

Mehr

Basiskarte Sachsen und Sachsenatlas webbasierte Geodienste des Freistaates Sachsen

Basiskarte Sachsen und Sachsenatlas webbasierte Geodienste des Freistaates Sachsen Basiskarte und atlas webbasierte Geodienste des Freistaates GEOforum Leipzig Vortragsreihe des Geo Leipzig e.v. 10.06.2008 Inhalt Basiskarte Webdienste auf Geobasisdaten Aktuelles atlas (Basiskomponente

Mehr

GeoXACML und SAML. Ubiquitous Protected Geographic Information. Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw.

GeoXACML und SAML. Ubiquitous Protected Geographic Information. Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw. GeoXACML und SAML Ubiquitous Protected Geographic Information Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw.de Was erwartet Sie in diesem Vortrag? Einleitung OpenGIS Web

Mehr

Business Process Execution Language for Web Services (BPEL4WS)

Business Process Execution Language for Web Services (BPEL4WS) Hauptseminar und Vorlesung Web Services WS 2003/04 Business Process Execution Language for Web Services (BPEL4WS) Patrick Sauter 2/17 Vortrag - Überblick Definition, Zielsetzung und Allgemeines einfacher

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

GDI-Initative. Initative von Intergraph. Dr. Uwe Jasnoch Programm Manager GDI

GDI-Initative. Initative von Intergraph. Dr. Uwe Jasnoch Programm Manager GDI GDI-Initative Initative von Intergraph Dr. Uwe Jasnoch Programm Manager GDI Warum engagiert sich Intergraph für GDI? Ende 2006 wurde eine Rahmenrichtlinie vom EU- Parlament verabschiedet Bis 2009 muss

Mehr

Web Services Composition (BPWS4J )

Web Services Composition (BPWS4J ) Web Services Composition (BPWS4J ) Hager Markus, Kober Christoph, Linde Kai, Ott Florian, Erdmann Dennis Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

Mehr

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 1 Verteilte Systeme Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 2 Verteilte Systeme 1. Innovative Beispiele aus der Praxis 2. Allgemeine Anforderungen und Techniken verteilter Systeme

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Entwicklung eines interoperablen, multimedialen Teaching-File-Service: Web-Service unterstützter Wissenstransfer in der Radiologie

Entwicklung eines interoperablen, multimedialen Teaching-File-Service: Web-Service unterstützter Wissenstransfer in der Radiologie Aus dem Universitätsklinikum Benjamin Franklin der Freien Universität Berlin Institut für Medizinische Informatik, Biometrie und Epidemiologie Geschäftsführender Direktor: Prof. Dr. Thomas Tolxdorff Entwicklung

Mehr

Geoproxy Freistaat Thüringen. Dokumentation zur Einbindung des Web Feature Service in GIS-Anwendungen. - ArcGIS von ESRI - Stand: 21.05.

Geoproxy Freistaat Thüringen. Dokumentation zur Einbindung des Web Feature Service in GIS-Anwendungen. - ArcGIS von ESRI - Stand: 21.05. Geoproxy Freistaat Thüringen Dokumentation zur Einbindung des Web Feature Service in GIS-Anwendungen - von ESRI - Stand: 21.05.2015 Dokumentenhistorie Version Datum Bemerkungen 1.0 21.05.2013 basierend

Mehr

Model-Driven Software Development

Model-Driven Software Development Model-Driven Software Development BPEL 2.0 Robert Siebert Das Forschungs- und Entwicklungsprojekt OrViA wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) gefördert, die innerhalb

Mehr

(Rechtsakte ohne Gesetzescharakter) VERORDNUNGEN

(Rechtsakte ohne Gesetzescharakter) VERORDNUNGEN 8.12.2010 Amtsblatt der Europäischen Union L 323/1 II (Rechtsakte ohne Gesetzescharakter) VERORDNUNGEN VERORDNUNG (EU) Nr. 1088/2010 DER KOMMISSION vom 23. November 2010 zur Änderung der Verordnung (EG)

Mehr

10. Seminar GIS & INTERNET, 11. Sept. 2007

10. Seminar GIS & INTERNET, 11. Sept. 2007 Service-orientierte Architektur (SOA) und Geodateninfrastruktur (GDI): dienstbare GIS-Komponenten Dr.-Ing. Jens Hartmann, Account Manager 10. Seminar GIS & INTERNET, 11. Sept. 2007 Agenda Motivation Service-orientierte

Mehr

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was

Mehr

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de XML-RPC, SOAP und Web Services Jörn Clausen joern@techfak.uni-bielefeld.de Übersicht Was ist RPC? Was hat XML mit RPC zu tun? Was sind XML-RPC und SOAP? Was sind Web Services? Wird das die Welt retten?

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

Vertiefte Grundlagen. Übung 2.7. TU Dresden - Institut für Bauinformatik

Vertiefte Grundlagen. Übung 2.7. TU Dresden - Institut für Bauinformatik Bauinformatik Vertiefte Grundlagen Geschäftsprozessmodellierung Übung 2.7 Begriffe Ein Geschäftsprozess beschreibt wiederkehrenden Ablauf. Dieser Ablauf beschreibt, welche Aktivitäten in welcher Folge

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

9. Business Process Execution Language

9. Business Process Execution Language 1 9. Business Process Execution Language Beobachtung: häufige Änderungen der Geschäftsprozesse dies erfordert leichte und schnelle Software-Anpassung Idee: Software in (Web-)Services gliedern ( SOA) diese

Mehr

Das MDI-DE Portal Neue Anforderungen und Ideen

Das MDI-DE Portal Neue Anforderungen und Ideen Das MDI-DE Portal Neue Anforderungen und Ideen MDI-DE Abschlussworkshop 26.04.2013, Hamburg Thomas Wojaczek, con terra Inhalte MDI-DE Portal Der Status Quo Neuerungen Phase III Neue Anforderungen und Ideen

Mehr

Architektur einer GDI: Service-oriented Architecture (SOA)

Architektur einer GDI: Service-oriented Architecture (SOA) Modul 6: Voraussetzungen einer GDI Vertiefende Dokumente I Stand: 24.01.2012 Architektur einer GDI: Service-oriented Architecture (SOA) Zu den Hauptargumenten für eine Geodateninfrastruktur zählen unter

Mehr

Konzepte und Anwendung von Workflowsystemen. Kapitel 8: Workflow Ausführungssprache BPEL

Konzepte und Anwendung von Workflowsystemen. Kapitel 8: Workflow Ausführungssprache BPEL Vorlesung Wintersemester 2011/12 Konzepte und Anwendung von Workflowsystemen Kapitel 8: Workflow Ausführungssprache BPEL Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen

Mehr

Oliver Olbrich Das ebxml Projekt Entstand 1999 in einer gemeinsamen Initiative von OASIS (Organisation for the Advancement of Structured Information Standards) und UN/CEAFACT (United Nations Center for

Mehr

ArcGIS for INSPIRE. Lars Schmitz. ESRI Deutschland GmbH, Kranzberg. Unterstützt von:

ArcGIS for INSPIRE. Lars Schmitz. ESRI Deutschland GmbH, Kranzberg. Unterstützt von: ArcGIS for INSPIRE Lars Schmitz ESRI Deutschland GmbH, Kranzberg Unterstützt von: Was ist ArcGIS for INSPIRE? + ArcGIS for INSPIRE bietet eine vollständige Lösung für INSPIRE auf Basis von ArcGIS + ArcGIS

Mehr

GeoServer in action Fortgeschrittene Möglichkeiten beim Einsatz des Geoservers

GeoServer in action Fortgeschrittene Möglichkeiten beim Einsatz des Geoservers GeoServer in action Fortgeschrittene Möglichkeiten beim Einsatz des Geoservers Nils Bühner buehner@terrestris.de terrestris GmbH & Co KG Über uns Nils Bühner buehner@terrestris.de github.com/buehner Informatiker

Mehr

Termin 4: Web Services Computing

Termin 4: Web Services Computing Arbeitsgruppe Übung Netzbasierte Informationssysteme Termin 4: Web Services Computing Prof. Dr. Adrian Paschke Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin

Mehr

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08 XML-RPC & SOAP & Fabio Caprera Systemprogrammierung SS 08 Inhalt XML-RPC Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile SOAP Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Entwicklung ISO/OGC-konformer Metadaten und Katalogdienste

Entwicklung ISO/OGC-konformer Metadaten und Katalogdienste 19. September 2006 Entwicklung ISO/OGC-konformer Metadaten und Katalogdienste Wilhelmstraße 56 D-53721 Siegburg http://www.supportgis.de Tel.:+49(0)2241-2594- 0 Fax.:+49(0)2241-2594-29 thiele@supportgis.de

Mehr

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler Web Services and Semantic Web - Introduction to Web Services von Andreas Weiler Definitionen Beispiele Technologien Vorteile Kritik Abschlussbeurteilung Fragen? Definition von IBM: Web services are a new

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

FuE-Bereich IuK-Systeme im Gesundheitswesen

FuE-Bereich IuK-Systeme im Gesundheitswesen FuE-Bereich IuK-Systeme im Gesundheitswesen IG XML und Web Services Dipl.-Inform. Axel Schwolow IG Kommunikation im Web Entwicklung früher ausschließlich Kommunikation über Browser heute zunehmend direkt

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

BPEL Business Process Execution Language

BPEL Business Process Execution Language BPEL Business Process Execution Language Dr. Martin Bartonitz Product Manager SAPERION AG Vorsitzender des Aufsichtsrates: Dieter Matheis Vorstand: Rudolf Gessinger (Vorstandsvorsitzender), Andreas Kunze

Mehr

Bedeutung der. Architektur von INSPIRE. Lars Bernard, TU Dresden Christian Elfers, con terra GmbH Markus Müller, AED-SICAD AG

Bedeutung der. Architektur von INSPIRE. Lars Bernard, TU Dresden Christian Elfers, con terra GmbH Markus Müller, AED-SICAD AG Bedeutung der INSPIRE Netzdienste t für die technische Architektur von INSPIRE Lars Bernard, TU Dresden Christian Elfers, con terra GmbH Markus Müller, AED-SICAD AG INSPIRE NS Architektur - Motivation

Mehr

Webservices REST vs. SOAP

Webservices REST vs. SOAP Webservices REST vs. SOAP Amine El Ayadi INF-M2 Anwendungen 1 (SS 2008) Department Informatik HAW Hamburg 17. Juni 2008 1/41 Agenda Einführung & Motivation Webservices SOAP Webservices REST Webservices

Mehr

SEQIS 10 things API Testing

SEQIS 10 things API Testing SEQIS 10 things API Testing SEQIS 10 things API Testing Herzlich Willkommen! Reinhard Salomon SEQIS Geschäftsleitung SEQIS 10 things Programm 2014 20.03.14 Business Analyse Einführung in den BABOK Guide

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Web Services. Dr. Wolfgang Süß

Web Services. Dr. Wolfgang Süß Service-orientierte Architektur (SOA) Architekturkonzept, da sich aus Diensten zusammensetzt. 3 Komponenten: Konnektoren: register Registrierung eines Dienstes bei einer Registry find Suchanfrage eines

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

PROC SOAP, PROC HTTP und der ganze REST Webservices und SAS

PROC SOAP, PROC HTTP und der ganze REST Webservices und SAS PROC SOAP, PROC HTTP und der ganze REST Webservices und SAS Schnittstellen Martin Haffner HMS Analytical Software GmbH Rohrbacher Str. 26 69115 Heidelberg Martin.Haffner@analyticalsoftware.de Andreas Mangold

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

Einbettung von Geoinformationen in E-Government-Prozesse

Einbettung von Geoinformationen in E-Government-Prozesse Einbettung von Geoinformationen in E-Government-Prozesse grit - graphische Informationstechnik Beratungsgesellschaft mbh Büro Berlin: Maxstr. 3a D-13347 Berlin +49-30-46606280 +49-30-46606282 Status und

Mehr

LEITPROJEKTE DER GDI-SÜDHESSEN

LEITPROJEKTE DER GDI-SÜDHESSEN INHALTSVERZEICHNIS 1 STAND APRIL 2012... 3 2 MONITORING... 4 3 TESTADRESSEN... 4 3.1 Bebauungspläne... 4 3.2 Radwege... 5 4 BEDIENBARKEIT DURCH DEN NUTZER (USABILITY)... 6 5 PROBLEMDOKUMENTATION... 6 5.1

Mehr

Daten. Karten. Lösungen. Regionalverband Ruhr Informationsveranstaltung INSPIRE

Daten. Karten. Lösungen. Regionalverband Ruhr Informationsveranstaltung INSPIRE Daten. Karten. Lösungen RegionalverbandRuhr InformationsveranstaltungINSPIRE OlafKnopp DieWhereGroup RegionalverbandRuhr InformationsveranstaltungINSPIRE OlafKnopp Referenzen Geoportal.de Geoportal Rheinland-Pfalz

Mehr

Modellierung von Geschäftsprozessen mit BPEL4WS

Modellierung von Geschäftsprozessen mit BPEL4WS Seminararbeit von Abstract Die Business Process Execution Language for Web Services (BPEL4WS) ermöglicht es, sowohl Geschäftsprozesse zu beschreiben, welche Web Services nutzen, als auch Geschäftsprozesse

Mehr

XMPP: Extensible Messaging and Presence Protocol

XMPP: Extensible Messaging and Presence Protocol XMPP: Extensible Messaging and Presence Protocol (aka Jabber) 5. Dezember 2005 Einleitung Was ist XMPP? Architektur Allgemeines Kommunikation via XMPP: Streams, Stanzas Beispielanwendung

Mehr

Geodateninfrastruktur Deutschland. Dr.-Ing. Martin Lenk Koordinierungsstelle GDI-DE Bundesamt für Kartographie und Geodäsie

Geodateninfrastruktur Deutschland. Dr.-Ing. Martin Lenk Koordinierungsstelle GDI-DE Bundesamt für Kartographie und Geodäsie Dr.-Ing. Martin Lenk Koordinierungsstelle GDI-DE Bundesamt für Kartographie und Geodäsie Agenda Geoportal: Schaufenster der GDI-DE Organisation und Auftrag Architektur der GDI-DE Geoportal.DE Zweck Funktionalität

Mehr

Geoportallösungen mit Mapbender

Geoportallösungen mit Mapbender Geoportallösungen mit Mapbender Inhalt Vorstellung Mapbender Beispiellösung Bielefeld Administration von WebGIS-Diensten über Mapbender GIS Architekturen mit Freier Software Ausblick Mapbender: Standard

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

GeoMedia 6.1.7: WMS. OGC WMS Daten in der GeoMedia Welt

GeoMedia 6.1.7: WMS. OGC WMS Daten in der GeoMedia Welt GeoMedia 6.1.7: WMS OGC WMS Daten in der GeoMedia Welt Tipps & Tricks September 2010 Inhaltsverzeichnis Inhaltsverzeichnis Einführung... 3 WMS Daten anhängen... 3 Ausgangslage... 3 WMS Verbindung erstellen...

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von Bachelorarbeit Thema: Modellierung interaktiver Web Service Workflows von Benjamin Koch Gliederung Beispiel Interaktive Workflows Komponenten o BPEL o Web Service o Web-Interface o Eclipse-Plugin Vorführung

Mehr

SOA, Webservices und SOAP für Schnelleinsteiger

SOA, Webservices und SOAP für Schnelleinsteiger SOA, Webservices und SOAP für Schnelleinsteiger (C)opyright 2005 by Jochen Vajda Inhalt Einführung I. Was ist SOA? II. Webservices, SOAP und WSDL SOAP mit PHP5 I. Benötigte Komponenten II. Client ohne

Mehr

INSPIRE-konforme Dienste publizieren und nutzen - Mit der ArcGIS Plattform für Organisationen

INSPIRE-konforme Dienste publizieren und nutzen - Mit der ArcGIS Plattform für Organisationen INSPIRE-konforme Dienste publizieren und nutzen - Mit der ArcGIS Plattform für Organisationen Stephan Künster, Ralf Hackmann Esri Deutschland GmbH con terra GmbH 3. September 2014, Essen 3 2014 Esri Deutschland

Mehr

Architektur von SOAP basierten Web Services

Architektur von SOAP basierten Web Services Architektur von SOAP basierten Web Services André Homeyer 28.11.2005 Worst-Case einer verteilten Anwendung TravelTime Client Benutzerinterface WackyWing Server Flüge suchen TravelTime Server Flüge suchen

Mehr

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus]

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] ESB Open Source ESB: Mule Flightreservation Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] Inhalt 1. Open Source ESB: Mule... 2 1.1. Überblick... 2 1.1.1. Das Beispiel Zeigt:... 2 1.2. Installationsanleitung...

Mehr

Integration von Web Feature Services (WFS) in ArcGIS

Integration von Web Feature Services (WFS) in ArcGIS Prof. Dipl.-Ing. Rainer Kettemann Labor für Geoinformatik Integration von Web Feature Services (WFS) in ArcGIS Fakultät Vermessung, Mathematik und Informatik Schellingstraße 24, 70174 Stuttgart www.geoinformatik.hft-stuttgart.de

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Arbeiten mit amtlichen und offenen Daten - NAS. Move Your Official Data Organized

Arbeiten mit amtlichen und offenen Daten - NAS. Move Your Official Data Organized Arbeiten mit amtlichen und offenen Daten - NAS Move Your Official Data Organized FME im Kontext von amtlichen Daten Überblick NAS Datenverarbeitung NAS Reader NAS schreiben Lösungsangebot: NAS2SHP-Template

Mehr

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems Diplomarbeit an der Private Fernfachhochschule Darmstadt Fachbereich Informatik Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

E-Government Web Services zur Integration von Bund und Wirtschaft - standardbasierte e-dec Services für elektronische Verzollungen

E-Government Web Services zur Integration von Bund und Wirtschaft - standardbasierte e-dec Services für elektronische Verzollungen E-Government Web Services zur Integration von Bund und Wirtschaft - standardbasierte e-dec Services für elektronische Verzollungen Dr. Stefan Hüsemann Berner Architekten Treffen Zentrum Paul Klee, Bern,

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 11: 19.12.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-,

Mehr

GDI-NW: Fortschritte bei Metadaten und Diensten bzgl. INSPIRE? Peter Kochmann Geschäftsstelle des IMA GDI.NRW 12.06.2013

GDI-NW: Fortschritte bei Metadaten und Diensten bzgl. INSPIRE? Peter Kochmann Geschäftsstelle des IMA GDI.NRW 12.06.2013 GDI-NW: Fortschritte bei Metadaten und Diensten bzgl. INSPIRE? Peter Kochmann Geschäftsstelle des IMA GDI.NRW 12.06.2013 Kommunale Nutzung des GEOkatalog Metadaten- Kennzahlen In der GDI-NW, d.h. im GEOkatalog

Mehr

ArcGIS Online. 2012 Esri Deutschland GmbH

ArcGIS Online. 2012 Esri Deutschland GmbH ArcGIS Online 1 2012 Esri Deutschland GmbH ArcGIS Online im ArcGIS System 2 2012 Esri Deutschland GmbH Ausprägungen von ArcGIS Online + ArcGIS Online (anonymer Zugriff) > Freigegebene Webkarten & Apps

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

GeForMTjs. GeForMT-Syntax. Testumgebung. Demonstration. Werkstatt 2012 - Multitouch-Gestenerkennung im Web

GeForMTjs. GeForMT-Syntax. Testumgebung. Demonstration. Werkstatt 2012 - Multitouch-Gestenerkennung im Web Werkstatt 2012 - Multitouch-Gestenerkennung im Web GeForMTjs Web-Framework zur Gestenerkennung auf Basis der Beschreibungssprache GeForMT GeForMT-Syntax Atomare Gesten Anzahl der Kontakte Punkt, Linie,

Mehr

InteProxy der sichere Proxy für OGC-Dienste

InteProxy der sichere Proxy für OGC-Dienste InteProxy der sichere Proxy für OGC-Dienste Deegree-Day 2008, 17. Juni 2008, Bonn Einführung: Was ist Absicherung? Aufbau einer sicheren GDI am Bsp. NDS Ausblick: Weitere Entwicklungsschritte (Demonstration)

Mehr

Anwendungsübergreifendes Geodatenmanagement mit novafactory

Anwendungsübergreifendes Geodatenmanagement mit novafactory Anwendungsübergreifendes Geodatenmanagement mit novafactory Jens Opitz, M.O.S.S. Computer Grafik Systeme GmbH InGeoForum, 18.05.2011 Agenda Geodaten und Geodateninfrastruktur Workflow einer GDI novafactory

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Web Services mit Java

Web Services mit Java Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich

Mehr

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0.

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0. GDI NRW Geodateninfrastruktur Nordrhein-Westfalen Testbed II Web Authentication & Authorization Service Februar Dezember 2002 Dokumentation Version 1.0 Teilnehmer AED Graphics con terra FhG ISST GIA GIUB

Mehr

Dokumentation: wi://googlemaps

Dokumentation: wi://googlemaps 1 Dokumentation: wi://googlemaps zur Einbindung von eigenen GoogleMaps Karten im TYPO3 Backend 2 Inhalt Einrichtung des Plugins... 3 Schritt 1: Frontend Plugin anlegen... 3 Schritt 2: Speicherort der Datensätze

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr