Problematik

Für die Orchestrierung ist es erforderlich, dass die integrierten Services die notwendigen Standards WSDL und SOAP unterstützen. Aufgrund der fehlenden Unterstützung dieser Standards von OGC Web Services, können diese bei der Orchestrieung nicht berücksichtigt werden.

Lösungsansätze des OGC

2005 hat das OGC den "WMS Change Request: Support for WSDL & SOAP" veröffentlicht, um diese Probleme anzugehen. Das Ziel dieses Reports ist es, eine standardisierte WSDL-Beschreibung für Web Map Services ab der Version 1.3.1 zu veröffentlichen. Das bedeutet, dass ab dieser Version eine WSDL-Datei als eine Art Anhang für den WMS mitgeliefert werden soll. Damit soll eine bessere Interoperabilität des WMS gewährleistet werden. Optional kann ein Link auf die WSDL in die GetCapabilities eingefügt werden. Damit wird es erleichtert, die WSDL aufzufinden.

Des Weiteren ist das OGC der Meinung, dass Web Services das SOAP-Protokoll unterstützen sollten. Dafür sind zwei Schritte notwendig. Der erste ist, dass eine Definition des SOAP-Bindings in die WSDL-Datei des Services eingefügt werden muss. Als zweites muss eine Unterstützung für den SOAP-Stil document/literal eingefügt werden.
Wahrscheinlich werden diese Forderungen in der WMS Version 1.3.1 nicht umgesetzt. Auf der Website des OGC lässt sich bei der Standards Working Group für WMS 1.4 finden, dass Vorschläge gemacht werden sollen, wie man SOAP und WSDL mit den jetzigen OGC Standards in Übereinstimmung bringen kann. Dabei bezieht sich die SWG auf das "SOAP OGC Discussion Paper" (07-158) und den "OWS 5 SOAP/WSDL Common Engineering Report" (08-009r1). Da beide Dokumente sehr ähnliche Inhalte haben, sollen hier nur die Gedanken des Discussion Papers erläutert werden.

Das OGC will zukünftig auch SOAP als Protokoll für die Interaktion von Web Services unterstützen, da mittlerweile SOAP ein wichtiges Kommunikationsprotokoll geworden ist. Dabei wird angestrebt, die HTTP-GET und -POST-Anfragen mittels SOAP zu "kapseln".
Bei der Verarbeitung solcher Anfragen geht das OGC davon aus, dass es einen clientseitigen Proxy und einen serverseitigen Proxy gibt. Der clientseitige Proxy erhält eine Anfrage von einem Nutzer mittels HTTP. Er transformiert diese in eine SOAP-Nachricht und sendet sie an den serverseitigen Proxy. Dieser wandelt die SOAP-Nachricht wieder in HTTP um und schickt die Anfrage an den eigentlichen Web Service. Mit der Antwort des Services wird genauso wie mit der Anfrage verfahren.
In diesem Discussion Paper werden zwei Konstellationen vorgestellt, einmal die Kapselung eines HTTP-GET zu SOAP und die eines HTTP-POST zu SOAP. Dabei sind die HTTP-Anfragen mittels KVP (KeyValuePair) verschlüsselt. Diese KVPs müssen in eine simple XML-Struktur entschlüsselt werden.
Wenn die Antwort des Services eine XML-Nachricht ist, kann diese ohne Veränderungen durch den SOAP-Service zurückgegeben werden. Binäre Daten dagegen müssen erst in eine valide SOAP-Antwort transformiert werden. Dies kann zum Beispiel mittels SOAP with Attachments passieren. Dafür muss die Antwort in ein base64Binary-Element gepackt werden.

Orchestrierung von OGC Web Services

Bei der Orchestrierung werden Web Services über ihre Beschreibung in Form der WSDL in den Prozess integriert. Aufgrund des Fehlens der Web Service Beschreibung in Form der WSDL können OGC Web Service nicht bei der Orchestrierung berücksichtigt werden.
Um dieses Hindernis zu umgehen, wurde im Rahmen der Diplomarbeit ein Service erstellt, der die OGC Services aufruft. Dieser Service verfügt über eine WSDL und kann somit bei der Orchestrierung einbezogen werden. Die Einbindung der OGC Web Services in den BPEL-Prozess erfolgt also indirekt.

Die Orchestrierung von OGC Web Services soll am Beispiel des WMSService demonstriert werden. Dafür wurden zuvor zwei Services erstellt. Dabei handelt es sich zum einen um den SelectService, der die WMS aufruft und deren Ergebnis empfängt und zum anderen um den ShowService, der die beiden Karten überlagert und das Ergebnis auf der Festplatte speichert. Dabei sollte die Überlagerung von Karten zweier WMS in einem BPEL-Prozess realisiert werden. Die Abbildung verdeutlicht den Ablauf des WMSService.

Die Erstellung des BPEL-Prozesses erfolgt analog zur zuvor vorgestellten Modellierung von Prozessen. Auch das Bereitstellen des WMSService auf dem BPEL-Server wird auf die gleiche Weise realisiert.
Der Aufruf des Dienstes erfolgt über dessen WSDL-Datei. Der Client generiert aus Informationen der WSDL eine SOAP-Nachricht, welche die Variablen für die Prozessanfrage enthält. Im Fall des WMSService wird vom Nutzer die Angabe von GetMap-Requests in Form einer URL, die alle erforderlichen Parameter mit entsprechenden Werten beinhaltet, für zwei WMS gefordert. Als Ergebnis wird die Pfadangabe, wo sich das Bild der überlagerten Karten befindet, angezeigt.