Fachhochschule Würzburg-Schweinfurt

Transkript

1 Fachhochschule WürzburgSchweinfurt Schwerpunkt ecommerce Hauptseminar ecommerce (WS 05/06) Thema : SOAP Felix Haberlach ( ) und Andreas Sieber ( )

2 Inhaltsverzeichnis: 1. EINLEITUNG RPC Remote Procedure Call Serialisierung WAS IST SOAP? AUFBAU EINER SOAPNACHRICHT Kriterien für eine SOAP Nachricht Die einzelnen Nachrichtenbestandteile Der Envelope Der Header Der Body Das Binding an ein Protokoll SOAPFaults Beispiel einer SOAPRequest Nachricht MÖGLICHKEITEN ZUR KOMMUNIKATION Asynchrone Kommunikation Request / Response SOAPRPC KODIERUNG IN SOAP VORTEILE, NUTZEN UND SCHWÄCHEN VON SOAP Vorteile Interoperabilität und weltweit geachtet Weitere Vorteile des SOAPProtokolls Nachteile Fehlende Sicherheitsmechanismen Weitere Nachteile Streitfall Firewallfriendly FAZIT UND AUSBLICK LITERATURVERZEICHNIS

3 1. Einleitung Beinahe jedes Unternehmen ist mit dem Internet verbunden. So tauschen sich Mitarbeiter per aus oder beziehen ihre Informationen aus Internetseiten anderer Unternehmen oder Organisationen. Durch diese Tatsachen werden Unternehmen automatisch zu Anbietern von Informationen und Services, indem sie im Gegenzug Anfragen per beantworten, selbst Inhalte auf Webseiten anbieten oder Anwendungen, wie z.b. OnlineShops, zur Verfügung stellen. Die vorhandenen Systeme haben dabei meist proprietäre Schnittstellen, die sich nicht für die Interaktion mit anderen Systemen eignen. Dabei ist die Integration von Daten heute das wichtigste Thema der Informationstechnologie. Wenn man dann noch Integration über Unternehmensgrenzen hinweg anstrebt, kommt man heute an Web Services nicht vorbei. Die Zielsetzung dieser Technologie war es, eine beliebige Zahl von Applikationen bzw. deren Komponenten miteinander kommunizieren zu lassen. Festzuhalten ist, dass hier die Interaktion der Maschinen untereinander und nicht die der Menschen im Vordergrund steht. Dabei sollte es keine Rolle spielen, auf welcher Plattform bzw. in welcher Sprache die Applikationen betrieben bzw. entwickelt werden. Ein Standard, der im Zusammenhang mit Web Services verwendet wird, ist SOAP. Was genau SOAP ist, wie er funktioniert und zu bewerten ist, wird in dieser Seminararbeit behandelt. Da SOAP auf Serialisierung und u.u. auf RPC zurückgreift, werden auch diese Begriffe kurz zu Beginn dieser Seminararbeit erläutert. 1.1 RPC Remote Procedure Call In der Vorlesung Datenkommunikation im Unternehmen des Studiengangs Wirtschaftsinformatik, wurde diese Thematik bereits erschöpfend behandelt. Trotzdem hier noch einmal eine kurze Erklärung, um den Einstieg in das Hauptthema zu erleichtern. Hinter der Bezeichnung Remote Procedure Call (RPC) verbirgt sich die Verteilung einer Anwendung durch Auslagern von Unterprogrammen, die isoliert von der übrigen Anwendung auf einem anderen Rechner ablaufen. Das zu Grunde liegende Konzept hierfür ist relativ einfach: ein Programm auf einem Rechner kann eine Funktion eines Programms auf einem anderen Rechner nutzen und dabei eventuell auch Parameter übergeben, ohne sich um Netzwerkdetails kümmern zu müssen. Allerdings bestehen Einschränkungen bezüglich der Umgebung, wie z.b. dem verwendeten Betriebssystem oder Übertragungsprotokoll. Diese müssen aufeinander abgestimmt sein, um eine Kommunikation zu ermöglichen. Ein RPCAufruf arbeitet in den meisten Fällen synchron. Das lokale Programm sendet die Anforderung an das Programm des andern Rechners und pausiert seine Arbeit bis zum Eintreffen der Antwort. Mit Hilfe einzelner Threads kann dieses Problem jedoch umgangen und somit eine asynchrone Realisierung eines entfernten Funktionsaufruf ermöglicht werden. 1.2 Serialisierung Mit Serialisierung wird der Vorgang einer Konvertierung eines Objekts in eine andere Form beschrieben. Im konkreten Fall der SOAPSerialisierung bedeutet dies, dass die Parameter und Rückgabewerte von zu versendenden Methoden in einen XMLStream, die Anfrage (Request) und Antwort (Response) in SOAP kodiert werden. Der Empfänger führt dann eine Deserialisierung durch, um die empfangenen Daten weiterverarbeiten zu können. Da XML ein offener Standard ist, kann der XMLStream plattformunabhängig von beliebigen Anwendungen verarbeitet werden. 2. Was ist SOAP? SOAP ist ein plattformunabhängiges, vom W3C spezifiertes Protokoll zur Übermittlung von XML Nachrichten zwischen verteilten Systemen, mit dem es möglich ist, Methoden, Services, Komponenten auf entfernten Systemen aufzurufen. Dabei übernimmt SOAP bei der Kommunikation zwischen einem Web ServiceNutzer und dem Anbieter die Verpackung, Strukturierung und Kapselung der auszutauschenden Informationen. Anders als bereits vorher existierende Protokolle (CORBA, DCOM, etc.), ist SOAP völlig frei von Restriktionen bezüglich Hardware, Betriebssystem, Sprache, Implementierung oder 2

4 Softwarehersteller. Übertragen werden die Informationen über gewöhnliche Netzprotokolle wie HTTP, SMTP oder FTP. Für die Datenübertragung kann also jedes beliebige Protokoll verwendet werden, allerdings gelten bei der Nutzung bestimmter Protokolle eventuell Einschränkungen. So ist über SMTP lediglich eine asynchrone Kommunikation möglich. Die SOAPSpezifikation enthält standardmäßig eine so genannte Bindung an HTTP. Beim Einsatz mit anderen Transportprotokollen muss dann eine entsprechende Bindung spezifiziert werden. Die ursprüngliche Bezeichnung für SOAP lautete Simple Object Access Protocol, welche aber später wieder zurückgezogen wurde, da sie den vollständigen Sinn von SOAP nicht traf. So hat SOAP beispielsweise wenig mit Object Access zu tun. 1 Heute steht SOAP daher einfach nur noch für SOAP. Dies hat den nicht zu unterschätzenden Vorteil, dass man sich im Bereich der IT schon eine Abkürzung weniger merken muss. 3. Aufbau einer SOAPNachricht Bevor darauf eingegangen wird, wie der Ablauf einer SOAPKommunikation aussehen kann, wollen wir einen Blick in das Herzstück der Kommunikation werfen: die SOAPMessage. 3.1 Kriterien für eine SOAP Nachricht Damit ein XMLDokument zu einer SOAPNachricht wird, müssen einige Kriterien erfüllt sein: Die enthaltenen, zu übertragenden XMLDaten (z.b. Aufrufanfrage einer Methode eines bestimmten Webservices) müssen von SOAPBodyElementen umrahmt werden Die BodyElemente werden wiederum von einem SOAPEnvelopeElement (zu dt. Umschlag) umschlossen Das Dokument bzw. der Inhalt muss konform mit den entsprechend definierten Namespace Vorgaben sein Das Dokument muss Informationen zur Serialisierung der Daten beinhalten Ein Protokoll für die Übertragung (z.b. HTTP) muss definiert sein 3.2 Die einzelnen Nachrichtenbestandteile Im Folgenden soll kurz auf die einzelnen möglichen Bestandteile einer SOAPNachricht eingegangen und ein kurzes Beispiel für eine SOAPMessage gezeigt werden Der Envelope Im Zusammenhang mit dem Verschicken von SOAP Nachrichten treten immer wieder Vergleiche zu dem Versenden eines Briefes auf. Einen großen Anteil an diesem Vergleich hat der Envelope. Er umschließt die eigentliche XMLNachricht, wie ein Briefumschlag und legt Namespaces z.b. für XMLSchema fest, die bei der SOAPKommunikation verwendet werden. Diese Namesräume definieren z.b., wie die SOAPNachrichten auszusehen haben. Es ist außerdem auch immer ein Verweis auf das SOAPXMLSchema, welches die zu benutzende SOAPVersion benennt, anzugeben. Abb.1: Aufbau einer SOAPNachricht 2 1 [WSP03] 2 [MSWS] 3

5 3.2.2 Der Header Ein Header ist nicht zwingend Notwendig, um eine SOAPMessage zu versenden. Trotzdem kann es nützlich sein, einen Header in die Nachricht einzubauen, wenn man z.b. spezielle Zusätze wie Routing, Verschlüsselungs oder Transaktionsinformationen dem Kommunikationspartner mitteilen will 3. Wichtig dabei ist, dass sowohl Sender als auch Empfänger der Nachricht von der Bedeutung der gesendeten Elemente das gleiche Verständnis haben. Es gibt bereits Ansätze (z.b. via ebxml), welche fest definierte Headerelemente benutzen und so keine Missverständnisse zuwischen Sender und Adressat aufkommen lassen. 4 Mit dem sogenannten mustunderstandattribut können zudem Informationen gekennzeichnet werden, die vom Empfänger der Nachricht verstanden werden müssen. Sollte der Empfänger Elemente, welche mit mustunderstand versehen wurden, nicht interpretieren können, ist die gesamte Nachricht für ihn nicht verwertbar. Es wird eine Fehlermeldung via SOAP zurückgesendet Der Body Im Body der Nachricht sind die Daten und Informationen enthalten, die es eigentlich zu Übertragen gilt z.b. eine Aufforderung, dass der Webservice XY die Funktion geld_her aufrufen soll. Es wird schnell klar, dass alle Elemente im Body vom Adressaten verstanden werden müssen, da sonst keine Kommunikation möglich ist. Deshalb wird beim Body, wie auch beim Envelope, mit Namespaces gearbeitet. Sie helfen die Webservices und deren Funktionen genau zu identifizieren. So wird z.b. vermieden, dass eine gleichnamige Funktion eines anderen Webservices aufgerufen wird. Innerhalb des Bodys können die enthaltenen Elemente und Werte eine beliebige, jedoch weiterhin XML konforme Struktur aufweisen Das Binding an ein Protokoll Um eine SOAP Nachricht zu verschicken, muss man ein Protokoll wählen um die Übertragung umsetzten zu können. Da SOAP protokollunabhängig definiert und umgesetzt wurde, kann ein beliebiges Protokoll für diesen Zweck ausgewählt werden. Im Normalfall wird jedoch HTTP oder SMTP verwendet. Das Binding definiert das Protokoll, mit dem die Nachricht verschickt werden kann SOAPFaults In SOAP ist ein spezielles Fehlerelement definiert, welches zum Einsatz kommt, wenn z.b. ein Problem bei der Verarbeitung einer SOAPAnfrage aufgetreten ist. Das Element wird in die Antwortnachricht an den Requestor geschrieben. Diese Fehlernachrichten, die nur das SOAP Faultelement im Body besitzen, beinhalten Informationen über die Art des Fehlers und wo dieser aufgetreten ist. 3.3 Beispiel einer SOAPRequest Nachricht Nun soll ein kurzes Beispiel das Kapitel abrunden. Hierbei handelt es sich um einen SOAP Aufruf, der einen Webservice bittet, die Funktion ausgeben auszuführen. Außerdem wird der Namensparameter Rainer Zufall im Request hinterlegt. Anschließend sollen die wichtigsten Zeilen der Nachricht erklärt werden. 1 POST /BeispielServer HTTP/1.1 2 Host: BeispielHOST 3 ContentType: text/xml; charset="utf8" 4 ContentLength: <?xml version = 1.0 encoding= utf8?> 7 <SOAPENV:Envelope 8 xmlns:soapenv = " 3 JWS S.35 4 [EBXL] 4

6 9 SOAPENV:encodingStyle = " 10 <SOAPENV:Header> 11 <SOAPENV:Header> 12 <SOAPENV:Body> 13 <p:ausgeben xmlns:p=" "> 14 <Name>Rainer Zufall</Name> 15 </p:ausgeben > 16 </SOAPENV:Body> 17</SOAPENV:Envelope> Abb.2: Beispiel einer SOAPNachricht Zeile 15: Hier ist ein HTTPHeader dargestellt. Dieser hat mit der eigentlichen SOAPNachricht nichts zu tun. Er wird jedoch automatisch bei einem SOAPRequest über HTTP erstellt und gibt allgemeine Informationen (z.b. in Zeile 4 die Länge der Nachricht) preis. Zeile 69: Mit dem obligatorischen XMLHeader in Zeile 6 beginnt nun die eigentliche SOAPMessage. Die weiteren Zeilen bis einschließlich Zeile 9 bilden den Anfangstag des Envelope. In dem oben gezeigten Beispiel wird das SOAPSchema, welches die Version von SOAP vorgibt, eingebunden. In Zeile 8 wird die Einbindung über einen Namespace dargestellt. In Zeile 9 wird ein encodingstyle Element per Namespace definiert. Das encodingstyle Element wird benutzt, um die Richtlinien für die Serialisierung zuzuordnen. Zeile 1011: Hier ist der SOAPHeader zu finden. In unserem Beispiel ist er leer. Es könnte in diesem Fall auch vollständig auf die Tags verzichtet werden. Zeile 1216: Nun kommen wir zum Body. Hier ist die eigentliche Nachricht angegeben, die verschickt werden soll. Nämlich, dass eine Methode ausgeben aufzurufen ist. Als Namespace, wo diese Funktion zu finden ist, wurde definiert. Außerdem soll der Parameter Name den Wert Rainer Zufall bekommen. 4. Möglichkeiten zur Kommunikation Anfänglich wurde SOAP entwickelt, um RPCs nicht nur unternehmensintern, sondern auch über die Unternehmensgrenzen hinaus zu ermöglichen. Da diese Methode alleine für heutige Bedürfnisse aber zu unflexibel war, liegt das Interesse nun auch auf dem Senden von SOAP Nachrichten in nur eine Richtung. Um aber entsprechende RequestResponse Modelle imitieren zu können, wird häufig eine Kombination von EinwegNachrichten gewählt. Für die Kommunikation mit SOAP gibt es daher mehrer Möglichkeiten. 4.1 Asynchrone Kommunikation Die asynchrone Kommunikation über SOAP basiert häufig auf der Verwendung des SMTP Protokolls. Bei dieser Art der Kommunikation, wird dem Empfänger eine SOAP Nachricht gesendet, welche die entsprechenden Informationen beinhaltet. Es ist prinzipiell auch möglich eine Nachricht parallel an mehrere Empfänger zu versenden. Im Gegensatz zur synchronen Kommunikation bei RPCs, wird hier keine sofortige Beantwortung erwartet. Der offensichtliche Vorteil hierbei ist also, dass es völlig belanglos ist, ob der Empfänger zum jeweiligen Zeitpunkt direkt erreichbar ist oder nicht. Besonders beim Anstoß von Workflows, bei denen keine sofortige Antwort erwartet wird, z.b. einer Bestellung, wird diese Möglichkeit genutzt. 5

7 Der Preis für die gewonnene Flexibilität ist allerdings, dass der Sender nicht erfährt, ob die Nachricht erfolgreich übermittelt werden konnte. 4.2 Request / Response Als Erweiterung des asynchronen Modells kann diese Möglichkeit betrachtet werden. Dieses Muster beschreibt die Interaktion, in der vom Empfänger auf eine SOAPAnfrage (Request) eine SOAP Nachricht als Antwort (Response) gesendet wird. Hier wird also ganz konkret eine Antwort erwartet. Wird von einer fehlerlosen Interaktion ausgegangen, besteht diese Kommunikationsmöglichkeit daher aus zwei SOAPNachrichten. Tritt allerdings ein Fehler beim Verarbeiten der Nachricht auf, muss von der Anwendung mit einem HTTP 500 Fehler geantwortet werden. Des Weiteren muss die Antwort eine SOAPNachricht mit einem SOAP FaultElement sein. Die Antwort erfolgt nach erfolgreicher Bearbeitung des Requests und bezieht sich immer auf die vorher gesendete Anfrage. Mögliche Fehler während der Verarbeitung oder der Übertragung können je nach Fall von keinem, einem oder beiden Partnern behandelt werden. Als Beispiel für diese Art der Kommunikation über SOAP wäre beispielhaft der elektronische Austausch von Dokumenten zu nennen. 4.3 SOAPRPC Wie der Name bereits verrät, handelt es sich bei dieser Möglichkeit der Kommunikation um eine Mischung eines traditionellen RPCs mit SOAP. Um die Funktionalität von RPC mit der Flexibilität von XML und zusätzlicher Interoperabilität zu kombinieren, wurde in der SOAPSpezifikation ein einheitliches Format für den Aufruf und die Antwort eines RPC definiert. Da SOAP auf existierenden Standards wie HTTP und XML aufbaut, funktioniert SOAPRPC auch in Umgebungen, in denen herkömmliche RPCMechanismen scheitern. Sowohl die Kodierung der Anfrage als auch die der Antwort erfolgen in SOAP. Um die mitgeschickten Parameter bzw. deren Datentypen zu kodieren, wird ein XMLSchema eingesetzt. Da die SOAPSpezifikation vom W3C standardisiert ist, StandardInternetprotokolle verwendet und XML für die Serialisierung von Nachrichten benutzt, können mit SOAPRPC die grundlegendsten Probleme des ursprünglichen RPC behoben werden. Abb. 3: vereinfachte Darstellung einer Kommunikation über SOAPRPC 5. Kodierung in SOAP Die Art der Kodierung legt fest, wie die gesendeten Daten im Web Service übertragen werden. Es gibt zwei verschiedene Ansätze für die Kodierungsart: rpc/encoded: Hier erfolgt die Kodierung des Aufrufs per RPC. Das bedeutet, die Nachrichten werden, wie bereits beschrieben, in SOAP, die Datentypen in XML Schemata kodiert. document/literal: Diese Art ist eine Erfindung von Microsoft und verwendet keine Kodierung, wie das bei der RPCKodierung passiert. Stattdessen werden die Daten einfach serialisiert, also als reine XMLDatei, übertragen. Obwohl rpc/encoded gewisse Vorzüge, wie beispielsweise die Einfachheit, vorzuweisen hat, wurden viele Web Service Implementierungen mit document/literal erweitert. Dies liegt vor allem daran, dass man mit rpc/encoded nur Methodenaufrufe und deren Antworten, jedoch keine einfachen Nachrichten versandt werden können. 6

8 6. Vorteile, Nutzen und Schwächen von SOAP Da nun schon ein Blick auf den Aufbau und die inneren Abläufe der SOAPKommunikationen und Nachrichten geworfen wurde, soll jetzt ein betriebswirtschaftlicher Blick auf SOAP geworfen und Vor und Nachteile des Protokolls herausgearbeitet werden. Dabei soll jeweils der wichtigste Vor und Nachteil besonders betrachtet werden. 6.1 Vorteile Interoperabilität und weltweit geachtet SOAP bildet einen akzeptierten W3CStandard, der eine breite Unterstützung durch die Industrie erfährt. Kein Wunder, denn die Größen der Softwarebrache wie SUN, Microsoft oder HP unterstützen und fördern SOAP sowie dessen Weiterentwicklung und Verbesserung. 5 Gerade, dass sowohl SUN als auch Microsoft im selben Boot sitzen hat weitreichende Folgen. So ist es mit Hilfe von SOAP möglich die beiden Welten Java und MS.Net via Webservice zu verbinden, ohne, dass Absprachen zwischen den Kommunikationspartnern bestehen. SOAP ist für diesen Zweck sowohl plattform als auch programmiersprachenunabhängig definiert und umgesetzt worden. Dies ist ein entscheidender Vorteil gegenüber anderen Protokollen wie z.b. DCOM oder RMI. DCOM ist fest mit Windows verzahnt, RMI wiederum nur mit JAVA. Jedoch ist anzumerken, dass die Interoperabilität von Java und.net via SOAP und Webservices noch nicht 100%ig funktioniert. 6 Vor allem bei der Verwendung von selbst definierten Datentypen kann es auf Grund der offenen SOAPStruktur zu Problemen kommen. Um die Interoperabilität weiter auszubauen wurde die Web Service Interoperability Organisation, kurz WSI, ins Leben gerufen. Die WSI versucht durch Empfehlungen und Vorschläge, wie SOAP und auch andere Bestandteile der Webservicewelt zu benutzen sind, die Verbindung zwischen verschiedenen Plattformen und Programmiersprachen zu erleichtern. 7 Gerade in der Interoperabilität, die derzeit nur mit SOAP sinnvoll zu bewerkstelligen ist, liegt ein großes Potential der Webservices. So können Firmen nicht nur intern über Webservices kommunizieren, auch zu anderen Konzernen oder Partnern und deren Anwendungen ist so eine Verbindung möglich. Eine echte Integration, oder eine feste Bindung zwischen den Anwendungen muss hierfür nicht mehr bestehen und dies ungeachtet der Plattform oder Programmiersprache. Die Vorstellung Alles mit Allem verbinden zu können passt natürlich nur zu gut in die heutige Unternehmenswelt, wo strategische Partnerschaften und Firmenfusionen auf der Tagesordnung stehen Weitere Vorteile des SOAPProtokolls Der XMLText der SOAPNachricht kann auch von Menschen gelesen werden. Wegen der XMLAbstammung von SOAP ist eine Interpretation der Nachricht möglich. Dies bietet im Gegensatz zu anderen Protokollen wie z.b. CORBA oder DCOM, welche binäre Nachrichten senden, die Möglichkeit die gesendeten und empfangenen Nachrichten mitzulesen. Es besteht Offenheit und freie Wahlmöglichkeit bezüglich des Übertragungsprotokolls. Neben den üblichen und gängigen Protokollen können also auch Exoten wie Beispielsweise MQ benutzt werden. Auch viele große Softwarehersteller sind auf den Zug aufgesprungen und statten ihre Anwendungen und Produkte mit SOAPInterfaces aus. So hat SAP in seine mysap Softwarelösungen SOAPSchnittstellen eingearbeitet, was so z.b. eine Verbindung mit WebsphereApplikationen via SOAP möglich macht. 8 SOAP kann nicht nur für die Kommunikation zwischen Anwendungen und Computern in Netzwerken oder im Internet sorgen, sondern auch als Schnittstelle für die Mobile Kommunikation benutzt werden. Für nahezu alle gängigen Betriebssysteme der Mobile Geräte sind SOAPImplementierungen möglich und auch schon vorhanden. Jedoch ist kritisch 5 [W3CM] 6 [SYW04] 7 [KFW04] 8 Computerwoche

9 anzumerken, dass eine SOAPKommunikation bei vor allem schwachen und langsamen Mobiles z. Zt. noch nicht sinnvoll umgesetzt werden kann. SOAP ist nicht geschlossen, sondern ein offener erweiterbarer Standard. Es können Erweiterungen für Funktionalitäten, die SOAP von Hause aus nicht unterstützt, integriert werden. Die Erweiterungen sind unabhängig voneinander definiert. SOAP bietet, wie bereites in dieser Ausarbeitung dargestellt, mehrer Kommunikationsmöglichkeiten (SOAPRPC, Asynchron, Request/Response) an. Dies ist ein Vorteil gegenüber anderen Kommunikationsmechanismen wie beispielsweise XMLRPC, wo nur Prozeduren aufgerufen werden können. 6.2 Nachteile Fehlende Sicherheitsmechanismen Im SOAP Protokoll sind einige wichtige Funktionalitäten nicht vorhanden. Zum Beispiel sind Sicherheitsmechanismen wie Verschlüsselung der Daten oder Authentifizierung in SOAP nicht berücksichtigt worden. Die Nichtberücksichtigung ist jedoch absichtlich geschehen, da man das Protokoll einfach und schlank halten wollte. Mit Hilfe von Erweiterungen sind diese fehlenden Bestandteile einzubinden und so die Funktionalität von SOAP auch erweiterbar. Jedoch kann dies zur Folge haben, dass zuvor eine Absprache zwischen den beiden Kommunikationspartnern stattzufinden hat, z.b. welche Art von Verschlüsselung benutzt werden soll. Diese Vorabsprachen sind jedoch gerade in der B2BKommunikation zwischen Applikationen schwer ohne menschlichen Eingriff umzusetzen. Es gibt z.b. aber auch die Möglichkeit, Sicherheitsfragen durch das Verwenden von sichereren Transportprotokollen wie HTTPS zu lösen. Einen weiteren und sehr umfassenden Lösungsansatz bietet WSS (Web Service Security). Diese Spezifikation wurde von der OASIS im Jahr 2004 als Standard bestätigt. WSS bietet für die wichtigsten Sicherheitsprobleme der Kommunikation über SOAP passende Lösungen. So werden beispielsweise Signierung und Verschlüsselungen angeboten. Eine ähnliche Funktionalität bietet auch die Erweiterung SOAPDSIG (Digital Signature), allerdings beschränkt sich diese auf die Authentifizierung von Nachrichten. Solche Sicherheitsmechanismen machen immer dann Sinn wenn vertrauliche Daten ausgetauscht werden, denn die SOAPNachrichten werden im Klartext übertragen und sind so, wenn sie abgefangen werden, leicht zu lesen und zu interpretieren Weitere Nachteile Auch andere Funktionalitäten wie Benennung von Routing oder Kontextinformationen für Transaktionen sind nicht im SOAPProtokoll verankert und müssen, sollten diese benötigt werden, über Erweiterungen eingebunden werden. Durch die XMLStruktur werden die Dateien extrem groß und überladen, was sich nicht zuletzt auf die Performance auswirkt. Der so generierte Overhead bewirkt neben der längern Übertragungsdauer auch eine größere Zeitspanne beim Interpretieren und Auswerten der Messages. Dies ist auch der Hauptgrund warum die Mobilekommunikation zu Webservices via SOAP noch in den Kinderschuhen steckt. Die vorhandenen Geräte bieten auf Grund der Technik noch nicht die nötige Power. In Umgebungen wo eine schnelle Kommunikation gefordert ist, sollte deshalb besser, wenn möglich, auf performantere Protokolle wie CORBA zurückgegriffen werden. 6.3 Streitfall Firewallfriendly Ein Punkt der oft als Vorteil 9 verkauft wird, stellt ebenso einen Nachteil dar. Man liest immer wieder von der Kompatibilität zwischen SOAP und Firewalls. Dies ist letztlich auf den offenen Port 80 zurückzuführen, der von SOAP genutzt werden kann, wenn z.b. HTTP als Protokoll eingesetzt wird. Im Gegensatz zu anderen Protokollen wie CORBA dessen IIOP von den meisten Firewalls nicht 9 [XM02] 8

10 durchgelassen wird, ist mit SOAP eine Kommunikation unter diesem Gesichtspunkt sicher leichter zu bewerkstelligen. Von einer echten Kompatibilität zu Firewalls zu sprechen ist hier, aus unserer Sicht jedoch falsch. Es wird eher versucht die Firewall über die Inhalte, die versendet werden, zu täuschen und Nachrichten ungefiltert weiterzuleiten. Unter dem, für viele Firmen, extrem wichtigen Security Aspekt ist eine solche Vorgehensweise jedoch zu hinterfragen. In Zukunft könnte sich die Eigenschaft Firewallfriendly jedoch in Luft auflösen, denn die Industrie hat bereits als Antwort die ersten Firewalls entworfen, die eingehende SOAPNachrichten prüfen und validieren können Fazit und Ausblick SOAP bietet an sich nichts grundlegend Neues wenn es darum geht, Anwendungen oder Systeme miteinander zu verbinden. Es werden vorhandene Technologien wie XML oder Transportprotokolle ( z.b. HTTP) aufgegriffen, die SOAP für seine Kommunikation nutzt. Hauptziel von den Machern und Förderern von SOAP war es, einen Standard für den B2B Bereich zu schaffen. Man wollte verhindern, dass angebotene Services immer mit Restriktionen an die Systemsbeschaffenheit der Nutzer verbunden waren. Im Web hat man keinen Einfluss darauf, welche Infrastruktur und technischen Gegebenheiten sich bei den jeweiligen Kommunikationspartnern vorfinden. Deshalb versucht man mit Hilfe von SOAP diese Lücke zu schließen. SOAP ist keinesfalls als Allzweckwaffe zu sehen. Es fehlen wichtige Funktionalitäten (wie Verschlüsselung), die im Webserviceumfeld gefordert werden, um komplexe Anwendungen zu verwirklichen. Diese fehlenden Aspekte können jedoch, dank der nicht geschlossenen Struktur von SOAP, über Erweiterungen eingebunden werden. Die Zukunft von SOAP ist stark mit der von Webservices verbunden. Es gibt derzeit de facto neben SOAP keine andere Möglichkeit einen B2BWebservice im Internet anzubieten, der frei von Interoperabilitätsproblemen ist. Die Chancen stehen nicht schlecht, dass dies für die nächste Zeit so bleiben wird. Schließlich ziehen die großen der Softwarebranche bezüglich des SOAP Protokolls an einem Strang. Man muss sich jedoch klar machen, dass eine 100%ige Interoperabilität auch SOAP nicht garantieren kann. In Folge der Offenheit von SOAP und der damit verbundenen individuellen Implementierungen von Unternehmen und Servicebereitstellern, wird es weiterhin zu verschiedenen Problemen in der Interoperabilität kommen. Das heißt aber nicht, dass diese Probleme ausschließlich auf SOAP zurückzuführen sind. Da SOAP auf XML und ein Transportprotkoll zurückgreift, können sich Fehler dieser beiden Komponenten auf die SOAPKommunikation auswirken. Auch sind in der Spezifikation von SOAP Mehrdeutigkeiten vorhanden, so dass manche Dinge verschieden interpretiert werden können. Diese Probleme gilt es für die Zukunft zu minimieren, um die Verwendung von SOAP und somit die Verbreitung und Verwendung der Webservices im Allgemeinen, weiter zu optimieren. 10 [WSF03] 9

11 8. Literaturverzeichnis Bücher: [WPS02] Shnell, James, Tidwell, Doug und Kulchenko, Pavel WebserviceProgrammierung mit SOAP. Köln. O Reilly. [WSP03] Hauser, Tobias und Wenz, Christian Web Services mit PHP. Bonn. Galileo Press. [WPG05] Lubkowitz, Mark Webseiten programmieren und gestallten. Bonn. Galileo Press. [WSJ03] Langer, Thorsten Web Services mit Java. München. Markt und Technik Zeitschriften und Magazine: [IW04] Wenz, Christian Nie mehr ohne Seite. Internet World. 8. S.6870 [XM02] Göbbels, Volker Gründlich Eingeseift: SOAP Webservices mit PHP. XMLMagazin. 1. S.6570 [CTWS] Schäpers, Arne und Huttary, Rudolf Offene Verbindlichkeiten: Web Services mit.net. C T. 10. S Skripte [DAU04] JunkerSchilling, Klaus Datenkommunikation in Unternehmen. S. 710 Internetquellen: [WSS04] Bayer, Thomas: Die WS* Spezfikationen, (letzter Zugriff: ) [SWS03] Manhart, Klaus: Sicherheit bei Webservices, (letzter Zugriff: ) [USWS04] Buda, Lidiya, Grünbauer, Johannis und Jürjens Jan: (Un)Sicherheit bremst Webservices, (letzter Zugriff: ) [DS04 ] Ullenboom, Christian: Java ist auch eine Insel (OpenBook), Kapitel 18.16: DailySOAP, (letzter Zugriff: ) [BTB05] Koch, Daniel: From Babylon Back to Babylon, (letzter Zugriff: ) [FL02] Großwendt, Volkmar: Fährtenleser, (letzter Zugriff: ) [KIV03] Franke, Susanne und Shmith, Randy Franklin: Sicherheit beim Einsatz von Webservices: Kontrollposten im Vorfeld, p,archiv,ng,,thes,.html (letzter Zugriff: ) [WSF03] Buret, Carol: Erste SOAP Firewall auf dem Markt,

12 [SYW04] Schwichtenberg, Holger: Brückenschlag zwischen den Systemwelten, bj,cz,np,archiv, ng,,thes,.html [KFW04] Franke, Susanne: Klebstoff für Webdienste, p,archiv,ng,,thes,.html [W3C] (letzter Zugriff: ) [DLWS] (letzter Zugriff: ) [SISO] (letzter Zugriff: ) [WSST] (letzter Zugriff: ) [SWS] (letzter Zugriff: ) [MISO] _soap_eai.html (letzter Zugriff: ) [WSRS] _soap.html (letzter Zugriff: ) [MSWS] /wsmsgspecindex.asp (letzter Zugriff: ) [W3CM] [EBXL] 11