Sie sind auf Seite 1von 22

State of the SOAP

Martin Kutter Submitted for the proceedings of 10th German Perl Workshop, February 13-15, 2008

Inhaltsverzeichnis

1 Einfhrung
1.1 1.2 1.3 2.1 2.2 2.3 2.4 3.1 3.2

SOAP-Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Web Services Dream . . . . . . . . . . . . . . . . . . . . . . . . . . . The Web Services Cold Shower . . . . . . . . . . . . . . . . . . . . . . . . SOAP . . . . . . . . . SOAP::Lite . . . . . . SOAP::WSDL . . . . . XML::Compile::SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 5 5

2 Perl's SOAP Toolkits

. 6 . 7 . 10 . 12

3 Performance

Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

14

4 Welche Seife passt zu mir? 5 State of the SOAP 6 Bibliographie / Bibliography

16 18 18

Autor

Autor

Martin Kutter <martin.kutter@fen-net.de>,


Bio Martin Kutter

Martin Kutter ist Diplom-Psychologe und kmmert sich seit 2003 hauptberuich um die Schwierigkeiten und Probleme seiner Bit-Klienten. Perl schreibt Martin seit 2000. Er ist Autor von SOAP::WSDL und Test::Pod::Content und zur Zeit Maintainer von SOAP::Lite.

Abstract

Abstract

Web-Services mit XML-RPC und SOAP sind inzwischen allgegenwrtig - von Wikis wie TWiki ber Kollaborationsumgebungen wie Trac, bis hin zu amazon, Google und ebay: Nahezu jede Web-basierte Anwendung bietet inzwischen Web-Service Schnittstellen an. Im Vergleich mit anderen Sprachen schneidet Perl dabei nicht besonders gut ab: Keith Brown's SOAP wird seit 2000 nicht mehr gepegt, Pavel Kulchenko's SOAP::Lite setzt auf die inzwischen kaum noch verbreitete RPC-Variante und neuere Module wie SOAP::WSDL oder Mark Overmeer's XML::Compile::SOAP haben hohe Anforderungen an Perl-Version oder installierte Module und untersttzen (noch) nicht den gesamten Umfang der SOAPund WSDL-Spezikationen. Die folgenden Perl-Module werden in diesem Artikel vorgestellt und verglichen:

SOAP SOAP::Lite XML::Compile::SOAP SOAP::WSDL


SOAP und Web-Services sind ein Weg in die Zukunft - Perl darf diesen Weg nicht verpassen !

1 Einfhrung

1 Einfhrung

SOAP - frher das Simple Object Access Protocol, seit SOAP1.2 kein Akronym mehr, ist ein Protokoll fr den Nachrichtenaustausch zwischen Rechnersystemen. Der gngigste Einsatzzweck sind Web-Services (also SOAP ber HTTP/S), das gngigste Kommunikationsmuster Request/Response (mit XML-Remote Procedure Calls). Andere Kommunikationsbeziehungen wie z.B. Publish-Subscribe werden ber entsprechende Kommunikationsmuster unterstzt. SOAP-Nachrichten sind XML-Nachrichten, die dem SOAP XML Schema entsprechen. ber Erweiterungen im SOAP-Schema lassen sich SOAP-Nachrichten auch MIME oder DIME codieren. Fr die Denition von Web-Services gibt es eine standardisierte Sprache: WSDL, die Web Service Description Language. WSDL erlaubt die Verwendung verschiedener Protokolle fr einen Service ber sogenannte Bindings - die beiden gngigsten Bindings sind SOAP und HTTP.
1.1 SOAP-Nachrichten

SOAP-Nachrichten bestehen aus einem Envelope, einem (optionalen) Header und einem Body. SOAP-Header und -Body enthalten die eigentlichen Nutzdaten. Ein SOAP-Request fr den fr alle Code-Beispiele verwendeten Test-Web-Service sieht so aus:

<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <sayHello xmlns="urn:HelloWorld"> <name>Kutter</name> <givenName>Martin</givenName> </sayHello> </soap:Body> </soap:Envelope>
Dieser Request hat keinen SOAP-Header. Die Response ist unten dargestellt:

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <sayHelloResponse xmlns="urn:HelloWorld">

1.2 The Web Services Dream

<sayHelloResult>Hello Martin Kutter</sayHelloResult> </sayHelloResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>


SOAP-Client und -Server haben im Beispiel unterschiedliche Prexe fr die XMLNamespaces gewhlt. Das ist zulssig - die Namespace-URIs sind entscheidend, die Prexe sind bedeutungslos. Die SOAP-Nachrichten aus diesem Beispiel verwenden den document Nachrichten-Stil und die literal Codierung. Solche Nachrichten werden als document/literal bezeichnet. Alternativ gibt es noch den rpc Nachrichten-Stil und die encoded-Codierung. Nachrichten im document-Stil bertragen vorher denierte Nachrichten-Dokumente. rpcNachrichten enthalten einen Methoden-Namen als XML-Element und eine Liste positionaler Parameter fr diese Methode. Die Nachrichten oben knnten auch als rpc/literal deniert werden - neuere Web-Services whlen ihre Denitionen meist so, dass die Nachrichten auf verschiedene Arten erzeugt werden knnen. Die literal Codierung erlaubt keine ber die Denition der Dokumente hinausgehenden Encodings, whrend encoded die in der SOAP-Spezikation festgelegten Encodings, z.B. fr Listen untersttzt. Aktuelle Interoperability-Standards ( WS-I Basic Prole) fordern die Verwendung von document/literal oder rpc/literal, wobei document/literal die aktuell am weitesten verbreitete Variante ist. Die Kombination document/encoded wird praktisch nie verwendet. rpc/literal wird hug in Skriptsprachen (perl, php, python etc.) eingesetzt. Die Verwendung dieser Variante ist nach dem WS-I Basic Prole nicht mehr erlaubt. SOAP-Nachrichten knnen Attachments enthalten und MIME- oder DIME-codiert bertragen werden.
1.2 The Web Services Dream

ist der Name eines Kapitels in Programming Web Services with Perl von Randy Ray und Pavel Kulchenko. Beschrieben wird eine schne neue Welt, in der alle Systeme ber Web Services miteinander kommunizieren knnen, dank standardisierter Beschreibungen keine Kompatibilittsprobleme haben und sogar ber Web-Service Registries (das Protokoll dazu heist UDDI) die Adresse eines Service aus seinem Namen oder anderen Daten in Erfahrung bringen knnen.
1.3 The Web Services Cold Shower

ist der Name des nchsten Kapitels in Programming Web Services with Perl. Nach der Web-Service Euphorie folgte etwa ab 2002 die groe Ernchterung. Einige der Teile aus The Web Services Dream wie UDDI sind inzwischen wieder eingestampft, andere wie die Interoperabilitt sollen durch zustzliche Standards wie das WS-I Basic Prole

2 Perl's SOAP Toolkits

erreicht werden, mit denen die Mglichkeiten von SOAP und WSDL auf ein Minimum beschrnkt werden. Fr Perl war die Cold Shower besonders kalt: Es gab bis 2004 nur zwei SOAP-Toolkits, das eine davon - SOAP - wird seit 2000 nicht mehr gepegt, das andere - SOAP::Lite setzt mit der rpc/encoded Variante von XML-Nachrichten auf das falsche Pferd - der Rest der Welt verwendet document/literal. Perl's SOAP-Bibliotheken sind leider auch nicht fr besonders gute Benutzbarkeit bekannt. Die Frustration der Benutzer geht teilweise schon so weit, andere Sprachen zu verwenden:

Aus einem SOAP::Lite Bug-Report [1562278]: "Today I tried copying my requests into a python script - and had it up and running in less than 10 minutes."
Ich habe 2004 SOAP::WSDL verentlicht, das zunchst als Wrapper fr SOAP::Lite mit WSDL-Untersttzung fr document/literal-Nachrichten implementiert war und inzwischen zu einem eigenen SOAP Toolkit herangewachsen ist. Im letzten Jahr hat Mark Overmeer mit XML::Compile::SOAP und eine weiteres SOAP-Modul verentlicht, das die XML-Schema-Basis von SOAP und WSDL betont. Mit diesen Perl-Modulen gibt es inzwischen eine Reihe von Lsungsanstzen fr das gleiche Problem. Dieser Beitrag befat sich mit den Gemeinsamkeiten und Unterschieden der CPAN-Distributionen SOAP, SOAP-Lite, SOAP-WSDL und XML-Compile-SOAP. Fr alle SOAP-Toolkits (mit Ausnahme von SOAP) ist beispielhaft die Implementierung eines SOAP Client abgedruckt, der auf einen HelloWorld Web-Service zugreift. Der Service akzeptiert Name und Vorname als Parameter und antwortet freundlich mit

"Hello $Vorname $Name!"


Die zugehrigen Dateien (SOAP-Server, WSDL-Denition, Clients) sind Teil der SOAPWSDL Distribution (im Verzeichnis example).
2 Perl's SOAP Toolkits
2.1 SOAP

SOAP von Keith Brown (DevelopMentor) ist ein Toolkit fr das Schreiben von SOAP Clients und Servern. Das Modul wurde in Zusammenarbeit mit dem Java-Entwickler Don Box erstellt, um hnliche Toolkits fr beide Sprachen zu entwickeln. SOAP wird seit 2000 nicht mehr gepegt. Auf eine weitere Diskussion wird daher verzichtet. Programming Web Services with Perl enthlt eine bersicht ber die Funktionsweise von SOAP.

2.2 SOAP::Lite

2.2 SOAP::Lite

SOAP::Lite von Pavel Kulchenko wurde mit dem Anspruch entwickelt, ein vollstndiges Web-Service Toolkit fr Perl zu schreiben. SOAP::Lite ist unter allen Perl-Versionen ab 5.005 lauhig, und bietet eine fast vollstndige Untersttzung fr SOAP-Client und Server, UDDI-Clients und XMLRPC-Clients. SOAP::Lite untersttzt SOAP1.1 und SOAP1.2. rpc/encoded Web-Services werden sehr gut untersttzt, die Implementierung von rpc/literal oder document/literal Web-Services ist umstndlich. Mit dem Skript stubmaker.pl bietet SOAP::Lite eine rudimentre WSDLUntersttzung. SOAP::Lite untersttzt dabei keine verschachtelten complexTypeDenitionen im verwendeten XML Schema.

Funktionsumfang

Aufbau

SOAP::Lite ist ein Plugin-basiertes Toolkit - viele Komponenten sind austauschbar. Fast alle Perl-Klassen sind im Modul SOAP::Lite enthalten, so dass meist eine einzige Zeile gengt, um alle bentigten Klassen zu laden: use SOAP::Lite;
Eine SOAP-Nachricht durchluft bei SOAP::Lite-basierten Programmen mehrere Schichten. Der SOAP-Client nimmt die Daten vom Programm entgegen und bergibt sie an einen Serializer, der die Daten in XML umwandelt. Sofern ntig, wird die entstandene XML Nachricht vom SOAP::Packager in eine MIME/DIME-Nachricht umgewandelt, und von einem SOAP::Transport-Modul an den Server versendet. Die Antwort wird bei Bedarf vom SOAP::Packager zerlegt und von einem Deserializer in eine Perl-Datenstruktur zurckverwandelt. Serializer, Deserializer und Transportschicht sind austauschbar, wobei SOAP::Lite sehr hohe Anforderungen an Plugins stellt: So mssen z.B. TransportPlugins im Namespace SOAP::Transport liegen, den Namen des Protokolls als letzte Komponente im Namen haben (z.B. ::HTTP) und eine Client- und/oder Server-Klasse (z.B. SOAP::Transport::HTTP::Client und SOAP::Transport::HTTP::Server) implementieren. Dadurch ist es relativ schwer, SOAP::Lite mit Plugins zu erweitern. SOAP::Lite verwendet ein in Perl wenig verbreitetes Programmiermodell: Alle ObjektMethoden geben - als Setter aufgerufen - das Objekt zurck, so dass sich Methodenaufrufe verketten lassen.

my $soap = SOAP::Lite->new() ->proxy('http://www.example.org') ->autotype(0);

2 Perl's SOAP Toolkits

SOAP::Lite erzeugt SOAP-Nachrichten entweder aus einfachen Perl-Hashes oder aus SOAP::Data Objekten. Perl-Hashes knnen dabei nur fr einfache Datenstrukturen verwendet werden: Fr Baumstrukturen mssen SOAP::Data-Objekte verwendet werden. SOAP::Data-Objekte erlauben fast vollstndige Kontrolle ber das erzeugte XML. Die vom Serializer erwartete Struktur ist fr komplexe Datenstrukturen aber wenig intuitiv. Sofern die XML-Datentypen nicht explizit (ber das type-Attribut der SOAP::DataObjekte) angegeben sind, versucht SOAP::Lite den passenden XML-Datentyp zu erraten. SOAP::Lite verwendet dazu einen Satz an Regular Expressions, mit denen der gemeinte Datentyp erkannt wird. Dieses autotyping funktioniert fr rpc/encoded Schnittstellen in der Regel gut. Aus den SOAP-Nachrichten erzeugt SOAP::Lite ein Message-Objekt der Klasse SOAP::SOM. ber dieses lassen sich sowohl Fehler wie auch die einzelnen Nachrichtenelemente abrufen: die $som->fault->{ faultstring } if ( $som->fault() ); print $som->result, "\n";
Der Zugri auf tieferliegende Nachrichtenelemente ist per XPath mglich. Es knnen nur einfache Perl-Datenstrukturen (Skalare, Listen) abgerufen werden, fr komplexe Strukturen (Bume) mssen mehrere XPath-Ausdrcke eingesetzt werden. Obwohl SOAP::Lite Plugin-basiert designt wurde, gibt es kaum Erweiterungen. Ursache dafr ist vermutlich der komplexe Code, der als nahezu unwartbar gilt.

XML-Serialisierung / Deserialisierung

Erweiterbarkeit

Code-Generator Code-Beispiel

SOAP::Lite verwendet einen programmatischen Code-Generator, d.h. der erstellte Perl-Quellcode wird durch die Verkettung von Strings und Here-Dokumenten erstellt.
Das Code-Beispiel zeigt die Client-Implementierung fr den HelloWorldWeb-Service. Die aus anderen Quellen als der SOAP::Lite-Dokumentation bentigten Informationen sind in den Kommentaren beschrieben.

#!/usr/bin/perl use strict; use warnings; use SOAP::Lite;

2.2 SOAP::Lite

# I have to lookup the URL from the WSDL my $soap = SOAP::Lite->new( proxy => 'http://localhost:81/soap-wsdl-test/helloworld.pl', ); # I have to lookup the SOAPAction from the WSDL $soap->on_action( sub { 'urn:HelloWorld#sayHello' }); $soap->autotype(0); # I have to lookup the top level element's namespace from the WSDL $soap->default_ns('urn:HelloWorld'); # I have to encode all parameters as SOAP::Data objects # I have to know the order of parameters my $som = $soap->call( 'sayHello', SOAP::Data->name('name')->value( $ARGV[1] || q{"Your name"}), SOAP::Data->name('givenName')->value( $ARGV[0] || q{"Your given name"}), ); die $som->fault->{ faultstring } if ($som->fault()); print $som->result(), "\n";

Bewertung

SOAP::Lite's Strke ist seine gute Abwrts-Kompatibilitt - es luft auch noch unter perl-5.005. Fr die Implementierung von rpc/encoded SOAP-Clients und Server ist SOAP::Lite uneingeschrnkt zu empfehlen: Kein anderes Toolkit erlaubt es, Web-Services so einfach umzusetzen. Mit dem Fokus auf rpc/encoded-Nachrichten und der schlechten WSDL-Untersttzung bietet das Toolkit wenig Untersttzung fr die Implementierung aktueller document/literal Web-Services. Da keinerlei Dokumentations-Artefakte aus WSDLDenitionen erzeugt werden, mssen Entwickler Kenntnisse in XML, SOAP und WSDL haben, oder sich auf Beispiele verlassen knnen. SOAP::Lite bietet zur Zeit als einziges Perl-Toolkit die Mglichkeit, SOAP-Attachements zu verarbeiten. SOAP:Lite wird aktiv gepegt und ist relativ weit verbreitet - mit der Entscheidung fr SOAP::Lite in Projekten kann man wenig falsch machen, aber auch wenig gewinnen.

2 Perl's SOAP Toolkits

2.3 SOAP::WSDL

SOAP::WSDL, ursprnglich als Prprozessor fr SOAP::Lite entstanden, ist seit der Version 2 ein eigenstndiges SOAP Toolkit. Es benutzt SOAP::Lite's Transport-Module, sofern vorhanden. SOAP::WSDL untersttzt WSDL-basierte SOAPClients und -Server fr SOAP1.1 und WSDL 1.1. Die Untersttzung von SOAP1.2 ist geplant, fr SOAP-Server gibt es bisher nur eine CGI-basierte Implementierung. SOAP::WSDL untersttzt bisher nur den document/literal Nachrichten-Stil. Das Erstellen von SOAP-Schnittstellen ist auch ohne WSDL mglich, aber wenig komfortabel. Der Autor rt dazu, im Zweifelsfall eine Denition mit einem WSDL-Editor zu erstellen und die Schnittstellen daraus zu generieren. SOAP::WSDL untersttzt noch nicht den gesamten Umfang der WSDL- und XML-SchemaSpezikation. SOAP::WSDL kann SOAP-Client- und -Server-Klassen aus WSDL-Denitionen erzeugen. Es bietet auch einen on-the-y erzeugten Client - der Autor empelt aber, den Code-Generator zu verwenden. Beim Aufruf einer Methode eines generierten Client-Interfaces, bergibt der SOAPClient die Argumente an einen Serializer, der sie in eine XML-Nachricht umwandelt. Ein Transport-Objekt sorgt fr das Senden und Empfangen, und ein Deserializer erzeugt aus der SOAP-Nachricht ein Antwort-Objekt. SOAP::WSDL bringt eine eigene XML-Schema-Implementierung mit: SOAP::WSDL's CodeGenerator erzeugt Klassen fr alle in der WSDL-Denition verwendeten XML-SchemaDatentypen. Die erzeugten Klassen basieren auf Class::Std::Fast, einer performanteren Variante von Class::Std von Damian Conway. Die Umsetzung von XML-SchemaDatentypen in Klassen hnelt der von .NET: Jeder XML-Knoten wird als Objekt abgebildet. Die Kind-Knoten eines XML-Knoten sind als Eigenschaften der entsprechenden Klasse modelliert. Durch die Verwendung von Inside-Out-Objekten ist der Zugri nur ber Methoden mglich. Fr jede Eigenschaft wird eine get_FOO und eine set_FOOMethode erzeugt. Diese Daten-Klassen haben interessante Usability-Features: Die Konstruktoren aller komplexer Datentypen akzeptieren eine (komplexe) Hash-Referenz als Parameter in der Hashund Listen-Referenzen oder Objekte enthalten sein drfen. Ruft man eine nicht vorhandene Methode auf ein solches Objekt auf, so enthlt die Fehlermeldung eine Liste der vorhandenen Eigenschaften. Datums-, boolean und andere Werte werden automatisch in das entsprechende XML-Format konvertiert. Class::Std::Fast ist auch fr einige Besonderheiten im Laufzeitverhalten von SOAP::WSDL verantwortlich. Wie alle Inside-Out-Implementierungen verschiebt Class::Std::Fast einen Teil des Verwaltungs-Overhead in den Destruktor. Eine weitere Besonderheit von Class::Std::Fast ist ein Objekt-Cache (eine Variation des

Funktionsumfang

Aufbau

10

2.3 SOAP::WSDL

Flyweight-Pattern), um die Kosten fr das Erzeugen von Objekten beim mehrmaligen Erzeugen und Zerstren von Objekten der gleichen Klasse zu reduzieren.

SOAP::WSDL verwendet seit der Version 2 einen XML::Parser-basierten XML-Parser. SOAP::WSDL wandelt Objekte in XML-Nachrichten um und erzeugt aus diesen wieder Objekte. Die Klassendenitionen fr die Objekte werden aus der WSDL-Datei erzeugt. Der XML-Parser bentigt eine Struktur-Map (Typemap, eine Lookup-Tapelle fr die zu einem XPath-Ausdruck gehrenden Perl-Klassen) fr das Parsen von XML-Nachrichten Die aus XML-Schema-Datentypen generierten Klassen besitzen Methoden zur Umwandlung der Daten nach XML.

XML-Serialisierung / Deserialisierung

Erweiterbarkeit

SOAP::WSDL kann an vielen Punkten erweitert werden: SOAP Serializer und Deserializer, Transportschicht und sogar der Code-Generator lassen sich austauschen. Fr die Einbindung in Module, die alternative Darstellungsformen fr die SOAPNachrichten bentigen, gibt es Deserializer die Hash-Referenzen und SOAP::SOM-Objekte erzeugen.

Code-Generator

SOAP::WSDL verwendet einen template-basierten Code-Generator. SOAP Client- und Server-Klassen, wie auch die XML Schema basierten Datentypen werden mit Hilfe des Template Toolkit (Template) erzeugt. Die fr den XML-Parser bentigten Maps werden als Hash-Referenzen erzeugt, und per Data::Dumper in Perl-Quellcode umgewandelt.

Web-Service.

Code-Beispiel

Das Code-Beispiel zeigt die Client-Implementierung fr den HelloWorld

#!/usr/bin/perl use strict; use warnings; use lib 'lib'; # just needed because interface lies here # I have to generate the interface using wsdl2perl.pl before use MyInterfaces::HelloWorld::HelloWorldSoap; # I instantiate a interface class. my $soap = MyInterfaces::HelloWorld::HelloWorldSoap->new(); # I have to lookup the method and synopsis from the interface's pod my $result = $soap->sayHello({ name => $ARGV[1] || q{"Your name"},

11

2 Perl's SOAP Toolkits

givenName => $ARGV[0] || q{"Your given name"}, }); # SOAP::WSDL::SOAP::Typelib::Fault11 objects are false, but serialize to XML die $result if not $result; # I have to lookup the output parameter from the interface's POD - or try: # Will die on bad method names with a list of available methods print $result->get_sayHelloResult(), "\n";
Die Beschrnkung auf document/literal Web-Services und (bisher) SOAP 1.1 erlauben den Einsatz von SOAP::WSDL nur einen Teil von Web-Services - allerdings dem grten Teil der aktuellen Web-Services. Die generierten Dokumentations-Artefakte sind ein groes Plus fr Entwickler ohne Erfahrung mit WSDL / XML-Schema-Denitionen: Die bentigten Informationen knnen in einer fr Perl-Entwickler gelugen Form als Pod eingesehen werden. SOAP::WSDL ist performant und bentigt wenig Speicher. Die Inside-Out-Objekte auf der Basis von Class::Std::Fast sparen Speicherplatz, vor allem bei groen Datenstrukturen. SOAP::WSDL forciert mit seinen Class::Std::Fast-basierten Datentyp-Klassen ein bestimmtes Programmiermodell. Durch die alternativen Serializer / Deserializer lsst es sich aber auch in Projekte mit anderen Modellen einsetzen.
2.4 XML::Compile::SOAP

Bewertung

XML::Compile::SOAP untersttzt SOAP-Clients und Server fr SOAP 1.1 und SOAP 1.2, sowie WSDL 1.1 und 1.2 in den Varianten document/literal, rpc/literal und rpc/encoded. Der Schwerpunkt liegt auf document/literal, der Autor missbilligt die Verwendung von rpc/encoded-Nachrichten in der Dokumentation. XML::Compile::SOAP erstellt WSDL-basierte SOAP-Clients und -Server als Closures aus WSDL-Denitionen. Das Erstellen von SOAP-Schnittstellen ist auch ohne WSDL mglich, aber wenig komfortabel. XML::Compile::SOAP basiert auf der XML-Schema-Implementierung von XML::Compile. XML::Compile::SOAP erweitert XML::Compile um einen WSDL-Prozessor und einen SOAP Client und -Server.

Funktionsumfang

Aufbau

Serialisierung / Deserialisierung

XML::Compile::SOAP benutzt das DOM-API von XML::LibXML sowohl fr die Serialisierung wie auch die Deserialisierung von XMLNachrichten. Beim Deserialisieren wird ein DOM-Baum von einem Parser in Perl-HashStrukturen umgewandelt.

12

2.4 XML::Compile::SOAP

Beim Serialisieren werden Perl-Hash-Strukturen zunchst in einen DOM-Baum und dann in XML transformiert. XML::Compile::SOAP validiert die SOAP-Nachrichten - die Validierung geschieht im PerlTeil, nicht mit den Mglichkeiten der XML-Schema Validierung von XML::LibXML.

Erweiterbarkeit

Transportschicht.

XML::Compile::SOAP erlaubt zur Zeit lediglich den Austausch der

Der Code-Generator von XML::Compile::SOAP verfolgt einen sehr interessanten Ansatz. XML::Compile durchsteigt einen DOM-Baum und erzeugt dabei ein Closure-basiertes Parser-/Generator-Paar fr DOM Bume nach dem Prinzip rekursiv absteigender Parser. Das Ergebnis sind zwei Funktionen, die von XML::Compile::Dumper mit Hilfe von Data::Dump::Streamer in Perl Code umgewandelt werden knnen. Die so erzeugten Funktionen verwenden die Client- und Server- Funktionen der entsprechenden Protokoll-Module (z.B. XML::Compile::SOAP11::Client), um die SOAPMessages zu transportieren. Der Code-Generator ist damit eine interessante Sonderform programmatischer CodeGeneratoren: Statt Quellcode wird vom Generator eine Code-Referenz erzeugt, die von Data::Dumper::Streamer in Quellcode transformiert wird. Die Code-Referenz ist allein schon ausfhrbar, die weitere Transformation in Quellcode ist optional und wird vom Autor nicht mehr empfohlen.

Code-Generator

Code-Beispiel
#!/usr/bin/perl -w use strict; use warnings; use XML::Compile::WSDL11; use XML::Compile::Transport::SOAPHTTP; # I need access to the WSDL around - or use Data::Dumper::Streamer # for serializing the generated closures into (big) perl files my $wsdl = XML::Compile::WSDL11->new('wsdl/11_helloworld.wsdl'); # I compile a interface method for a single SOAP method from the WSDL # I have to lookup the method names from the WSDL my $call = $wsdl->compileClient('sayHello'); # I have to lookup the parameters from the WSDL - can be quite tricky my $result = $call->(

13

3 Performance

);

name => $ARGV[1] || q{"Your name"}, givenName => $ARGV[0] || q{"Your given name"},

# XML::Compile::SOAP's client just returns undef in case of failure die "Error calling soap method" if not defined $result; # I have to lookup the output parameters from the WSDL - or try Data::Dumper print $result->{ parameters }->{ sayHelloResult }, "\n"; XML::Compile::SOAP bietet als einziges Toolkit XML Schema Validierung. Da diese zur Zeit nicht abschaltbar ist, kann sie sowohl Fluch wie Segen sein: Was tun, wenn ein Client oder Server formal ungltige Daten sendet, aber nicht gendert werden kann? Die XML-Validierung ist im Perl-Teil implementiert - eine aus meiner Sicht nicht ganz nachvollziehbare Entscheidung: XML::LibXML und die darunterliegende libxml2 knnen XML Dokumente anhand von XML Schemata validieren, so dass sich der zustzliche Nutzen auf die Validierung des SOAP-Envelope beschrnkt. XML::Compile::SOAP besitzt die z.Zt. vollstndigste XML-Schema-Implementierung - es kann mit Hilfe von Callbacks auch mit any und anyAttribute-Denitionen umgehen. Der Closure-basierte Generator fr Server- und Client-Funktionen ist nicht fr alle PerlEntwickler verstndlich: Die Arbeit mit Closures ist weniger verbreitet als z.B. Objektorientierte Programmierung. Da keinerlei Dokumentations-Artefakte erzeugt werden, mssen Entwickler Kenntnisse in XML, SOAP und WSDL haben.
3 Performance

Bewertung

Performance kann fr Web-Service-Toolkits entscheidend sein - jedes Einsatzgebiet stellt bestimmte Performance-Anforderungen. Whrend fr Web-Services wie die geplante CPAN6 Paketverwaltung nur moderate Performance-Anforderungen gelten, legt der Einsatz von Web-Services z.B. als Backend fr Websites die Performance-Messlatte ungleich hher: Ein Benutzer wartet zwar auf perl -MCPAN6 - aber nicht auf einen Website-Aufruf im Browser. Die Performance-Eigenschaften knnen daher - je nach Einsatzzweck - ein k.o.-Kriterium fr ein SOAP-Toolkit, oder sogar fr den Einsatz von Perl als Implementierungssprache sein.
3.1 Benchmark

Fr das Benchmark wurde ein Test-Webservice deniert, und eine feste ResponseNachricht erzeugt. Im Test-Web-Service wird eine Liste an komplexen PersonenDatenstzen abgerufen, die Antwort ist ca. 10kB lang - eine fr Websites im Unternehmensumfeld bliche Operation mit einer kleinen Datenmenge.

14

3.2 Ergebnisse

Der Test-Web-Service wurde als CGI-basierter SOAP-Server mit SOAP::WSDL implementiert. Den eigentlichen Plan die Transportschicht aller Toolkits zu umgehen, konnte ich leider nicht umsetzen, da die dafr notwendigen Methoden in XML::Compile::Tester noch nicht oder nicht mehr verfgbar waren. Die Benchmark-Datei benchmark/person.pl wie auch der SOAP-Server example/cgi-bin/person.pl entstammen der SOAP-WSDL-Distribution in der Version 2.00_29. Im Benchmark ist mit SOAP::WSDL_XS eine noch nicht verentlichte Distribution mit aufgefhrt, die einen in XS implementierten XML Deserializer fr SOAP::WSDL bereitstellt. Das Benchmark besteht aus drei Durchlufen: Im ersten Durchlauf (Benchmark 0) wird die Ausgabe des Client-Aufruf in einer privaten Variable gespeichert und sofort wieder zerstrt. Im zweiten Durchlauf (Benchmark 1) werden alle Ergebnisse in einer Liste gespeichert und erst nach Ende des Benchmark zerstrt. Damit spielt die Zeit fr das Zerstren der Ergebnisse (Destruktor) keine Rolle fr die Ergebnisse. Der dritte Durchlauf (Benchmark 2) ist eine Wiederholung des zweiten.
3.2 Ergebnisse

Das Benchmark wurden auf einem Pentium Mobile 1.7 GHz (IBM Thinkpad T42 mit 1GB RAM) unter perl-5.8.8 auf Ubuntu 7.10 durchgefhrt. Der CGI-basierte SOAPServer lief unter apache2.2 mit mod_perl auf der gleichen Maschine.

Benchmark conducted with SOAP::Lite - 0.70_03 SOAP::WSDL - 2.00_27 SOAP::WSDL_XS - 0.00_1; XML::Compile - 0.64 Benchmark 0: Store result in private variable and destroy it Rate SOAP::Lite XML::Compile SOAP::WSDL SOAP::WSDL_XS SOAP::Lite 23.4/s --35% -55% -70% XML::Compile::SOAP 35.8/s 53% --32% -54% SOAP::WSDL 52.4/s 124% 46% --33% SOAP::WSDL_XS 78.1/s 234% 118% 49% -Benchmark 1: Push result on list Rate SOAP::Lite XML::Compile SOAP::WSDL SOAP::WSDL_XS SOAP::Lite 23.8/s --34% -68% -85% XML::Compile::SOAP 36.2/s 52% --51% -76% SOAP::WSDL 73.5/s 209% 103% --52%

15

4 Welche Seife passt zu mir?

SOAP::WSDL_XS

154/s

546%

325%

109%

--

Benchmark 2: Play it again, Sam Rate SOAP::Lite XML::Compile SOAP::WSDL SOAP::WSDL_XS SOAP::Lite 23.7/s --35% -71% -87% XML::Compile::SOAP 36.4/s 53% --56% -80% SOAP::WSDL 82.0/s 246% 125% --54% SOAP::WSDL_XS 179/s 654% 391% 118% -Die Ergebnisse zeigen zunchst deutlich den Eekt der Inside-Out-Objekte bei SOAP::WSDL und SOAP::WSDL_XS: Beide sind im Benchmark 1 und 2, in denen die Arbeit des Destruktors nicht bercksichtigt wird deutlich schneller. Benchmark 2 zeigt den Eekt des Objekt-Cache von Class::Std::Fast, der bei nochmaliger Durchfhrung ca. 10% Performance-Gewinn bringt. Insgesamt ist SOAP::Lite bei der Verarbeitung am langsamsten. SOAP::WSDL ist in allen Durchlufen schneller als SOAP::Lite oder XML::Compile::SOAP. Beim Einsatz von SOAP::WSDL in persistenten Umgebungen (z.B. mod_perl) lassen sich zustzliche Geschwindigkeitsvorteile erzielen, indem das Zerstren der Objekte auf einen Zeitpunkt nach dem Beantworten von Benutzeranfragen verschoben wird. Auch der Objekt-Cache von Class::Std::Fast bringt hier weitere Performance-Vorteile. Fr XML::Compile::SOAP sind in weiteren Versionen Performance-Steigerungen zu erwarten. Das Modul ist noch relativ jung und sicher noch nicht vollstndig optimiert. Das noch nicht verentlichte SOAP::WSDL:_XS zeigt, dass eine noch deutlich bessere Performance mglich ist - allerdings nicht mehr in Perl allein.
4 Welche Seife passt zu mir?

SOAP ist durch die fehlende Maintenance eine Risiko-Investition und nur Benutzern zu empfehlen, die im Zweifelsfall entsprechende Maintenance-Arbeiten selbst bernehmen knnen und wollen. SOAP::Lite punktet mit Abwrts-Kompatibilitt und Umfang: Es luft auch noch auf Perl 5.005, untersttzt SOAP-Clients und Server, SOAP Attachements mit MIME und DIME-Nachrichten und die meisten SOAP-Encodings. Abzge gibt es fr die rudimentre WSDL-Untersttzung, den Fokus auf rpc/encoded, das fr komplexere Web-Services komplizierte API und in der B-Note: SOAP::Lite ist alles andere als Lite, sondern mit >160kB Quellcode ein echtes Schwergewicht. Darunter leiden Verstndlichkeit und Wartbarkeit. Weitere Nachteile von SOAP::Lite sind der relativ hohe Speicherverbrauch und die schlechte Performance. SOAP::WSDL deckt mit dem Fokus auf WS-I kompatible Clients bisher nur eine Nische ab - die Nische, in der die meisten Anwendungen liegen. Ein CGI-basierter SOAP-Server ist seit kurzem in der SOAP-WSDL-Distribution enthalten. Vorteile von

16

SOAP::WSDL sind niedriger Speicherverbrauch und hohe Performance, besonders in persistenten Umgebungen. Es bietet ein einfaches API fr SOAP-Clients, verschiedene Erweiterungsmglichkeiten, und nutzt wo mglich (SOM-Deserialisierer, Transport) bestehende Perl-Module. SOAP::WSDL erzwingt mit seinen Class::Std::Fast-basierten InsideOut Daten-Objekten die Verwendung eines bestimmten Objekt-Modells und fordert durch die Namensgebung seiner Methoden einen bestimmten Programmierstil. Es deckt (noch) nicht das gesamte WS-I Basic Prole ab. SOAP::WSDL generiert als bisher einziges Modul Pod-Dokumentation aus den WSDL-Denitionen, so dass auch Nutzer ohne SOAP/WSDL/XML-Vorkenntnisse mit den generierten Artefakten arbeiten knnen. XML::Compile::SOAP kann sowohl SOAP-Clients wie auch SOAP-Server aus WSDLDernitionen erzeugen. Es wandelt Perl-Hash-Datenstrukturen in SOAP-Nachrichten um und vice versa. XML::Compile::WSDL punktet mit der vollstndigen Umsetzung der XML-Schema Denition, der Validierung von XML-Nachrichten und der fast vollstndigen SOAP- und WSDL-Untersttzung. SOAP-Client und -Server erzeugt XML::Compile::WSDL als Funktionsreferenzen (Closures) ohne DokumentationsArtefakte, so dass fr die Verwendung Kenntnisse in XML/SOAP/WSDL notwendig sind. Beim Einsatz in nicht-persistenten Umgebungen kostet das Erzeugen von SOAP-Client oder -Server aus den WSDL-Denitionen etwas Zeit. Insgesamt ist XML::Compile::SOAP etwas schneller als SOAP::Lite aber deutlich langsamer als SOAP::WSDL. Die Merkmale der einzelnen Toolkits sind in der Tabelle dargestellt: SOAP::Lite SOAP::WSDL XML::Compile::SOAP ----------------------------------------------------------------------------Status stable beta beta Verbreitung hoch niedrig niedrig Perl-Versionen perl 5.005 perl 5.8.0 perl 5.8.0 SOAP Client ja ja ja SOAP Server ja ja (nur CGI) ja Vollstndigkeit hoch/hoch/niedrig mittel/niedrig/ hoch/mittel/hoch (XML/SOAP/WSDL) mittel Attachments ja nein nein XML-Parser XML::Parser/eigener XML::Parser XML::LibXML XML-Validierung nein nein ja Code-Generator Programmatisch Templates Closures aus WSDL generiert Code (rudimentr) Code (Klassen)+POD Closures Input SOAP::Data Hash / Objekte Hash Output SOAP::SOM-Objekt Objekte Hash SOAP Message Style alle document/literal alle Abstraktion niedrig hoch mittel Erweiterbarkeit mittel hoch niedrig Performance niedrig hoch niedrig

17

6 Bibliographie / Bibliography

5 State of the SOAP

Die SOAP-Untersttzung fr Perl hat sich im letzten Jahr durch die beiden neuen Toolkits SOAP::WSDL (2.xx) und XML::Compile::SOAP wesentlich verbessert: Es gibt (wieder) SOAP-Toolkits fr Perl, die einfach zu handhaben sind und mit den gngigen SOAPClients und Servern zusammenarbeiten. Leider haben die beiden neuen SOAP-Toolkits auch zu einer Spezialisierung gefhrt: Es gibt nicht mehr das SOAP-Toolkit fr Perl, der Benutzer muss sich vielmehr zwischen einer der drei aktuell untersttzten Distributionen entscheiden. Whrend SOAP::WSDL in vielen Punkten versucht, SOAP::Lite's API nachzubilden ist XML::Compile::SOAP ein vllig neues Modul. Der Umstieg von einem SOAP-Toolkit auf das andere ist nur mit Einschrnkungen mglich: SOAP::WSDL und XML::Compile::SOAP erwarten leicht unterschiedliche Datenstrukturen. Die aktuelle Entwicklung von SOAP::Lite geht zur Vereinfachung der Code-Basis. Selten bentigte Komponenten sollen in eigene Distributionen ausgegliedert werden. Eine Integration der WSDL-basierten Toolkits als XML Serializer/Deserializer wre mglich vorausgesetzt, die erwarteten Datenstrukturen lassen sich auf einen gemeinsamen Nenner bringen.
6 Bibliographie / Bibliography

Damian Conway
Class::Std http://search.cpan.org/perldoc?Class::Std

Erich Gamma, Richard Helm, Ralph Johnson,


1994

and John Vlissides

Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley,

Pavel Kulchenko, Randy Ray, Byrne Reese, Martin Kutter

Martin Kutter

SOAP::Lite http://search.cpan.org/perldoc?SOAP::Lite SOAP::WSDL http://search.cpan.org/perldoc?SOAP::WSDL

Microsoft Corporation
Inside WSDL with .NET Attribution. Web Services Technical Article.
http://msdn2.microsoft.com/en-us/library/ms996434.aspx

Yves Orton
Data::Dump::Streamer http://search.cpan.org/perldoc?Data::Dump::Streamer

18

Marc Overmeer
XML::Compile http://search.cpan.org/perldoc?XML::Compile::SOAP

Marc Overmeer
XML::Compile::SOAP http://search.cpan.org/perldoc?XML::Compile::SOAP

Marc Overmeer
XML::Compile::Dumper http://search.cpan.org/perldoc?XML::Compile::Dumper

Randy Ray & Pavel Kulchenko


Programming Web Services with Perl. O'Reilly & Associates, Sebastopol, CA, 2003

Gurusamy Sarathy
Data::Dumper http://search.cpan.org/perldoc?XML::Compile::SOAP

Matt Sergeant, Christian Glahn, Petr Pajas


XML::LibXML http://search.cpan.org/perldoc?XML::LibXML

Andreas Specht & Martin Kutter


Class::Std::Fast http://search.cpan.org/perldoc?Class::Std::Fast

Larry Wall, Clark Cooper & Matt Sergeant


XML::Parser http://search.cpan.org/perldoc?XML::Parser

Web Services Interoperability Organization


WS-I Basic Prole http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html

W3C: Don Box, David Ehnebuske, et al.


Simple Object Access Protocol (SOAP) 1.1. W3C Note 08 May 2000.
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

W3C: Nilo Mitra, Yves Lafon


SOAP Version 1.2 Part0: Primer W3C Recommendation (Second Edition) 27 April
2007. http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

W3C: Martin Gudgin, Marc Hadley et al.


Recommendation (Second Edition) 27 http://www.w3.org/TR/2007/REC-soap12-part1-20070427/

SOAP

Version

1.2

Part1:

Messaging

Framework
April

W3C 2007.

19

6 Bibliographie / Bibliography

W3C: Martin Gudgin, Marc Hadley et al.


SOAP Version 1.2 Part2: Adjuncts W3C Recommendation (Second Edition) 27 April 2007. http://www.w3.org/TR/2007/REC-soap12-part2-20070427/

W3C: Erik Christensen, Francisco Curbera,


na

Greg Meredith, Sanjiva Weerawara-

Web Services Description Language (WSDL) 1.1. W3C Note 15 March 2001.
http://www.w3.org/TR/2001/NOTE-wsdl-20010315

W3C: David C. Fallside & Priscilla Walmsley


XML Schema Part 0: Primer Second Edition W3C Recommendation 28 October
2004. http://www.w3.org/TR/xmlschema-0/

W3C: Henry S. Thompson, David Beech, Murray


2004. http://www.w3.org/TR/xmlschema-1/

Maloney, Noah Mendelsohn

XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October

W3C: Paul V. Biron, Ashok Malhotra


XML Schema Part 2: Datatypes Second Edition W3C Recommendation 28 October
2004. http://www.w3.org/TR/xmlschema-2/

20

Index
Symbols M

.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A

MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 5
P

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . 7, 10, 12 Autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2


B

Parser, rekursiv absteigend . . . . . . . . . . 13 Performance . . . . . . . . . . . . . . . . . . . . . . . . . 14 Perl's SOAP Toolkits . . . . . . . . . . . . . . . . . 6 Pod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


R

Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Bewertung . . . . . . . . . . . . . . . . . . . . 9, 12, 14 Bibliographie / Bibliography . . . . . . . . . 18 Bio Martin Kutter . . . . . . . . . . . . . . . . . . . . 2


C

rpc/literal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
S

Class::Std . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Class::Std::Fast . . . . . . . . . . . . . . . . . . . . . . 10 Code-Beispiel . . . . . . . . . . . . . . . . . 8, 11, 13 Code-Generator . . . . . . . . . . . . . . . 8, 11, 13


D

Data::Dumper . . . . . . . . . . . . . . . . . . . . . . . 11 DIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 5 document/literal . . . . . . . . . . . . . . . . . . 5, 12 DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


E

Serialisierung / Deserialisierung . . . . . . 12 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 6 SOAP-Attachements . . . . . . . . . . . . . . . . . . 9 SOAP-Nachrichten. . . . . . . . . . . . . . . . . . . .4 SOAP::Data . . . . . . . . . . . . . . . . . . . . . . . . . . 8 SOAP::Lite. . . . . . . . . . . . . . . . . . . . . . . .710 SOAP::SOM . . . . . . . . . . . . . . . . . . . . . . 8, 11 SOAP::WSDL. . . . . . . . . . . . . . . . . . . .1012 State of the SOAP. . . . . . . . . . . . . . . . . . .18
T

Template Toolkit . . . . . . . . . . . . . . . . . . . . 11 The Web Services Cold Shower . . . . . . . 5 The Web Services Dream . . . . . . . . . . . . . 5
U

Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Erweiterbarkeit . . . . . . . . . . . . . . . . 8, 11, 13


F

UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
V

Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . 14
W

Funktionsumfang . . . . . . . . . . . . . . 7, 10, 12
H

HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I

Welche Seife passt zu mir? . . . . . . . . . . . 16 WS-I Basic Prole . . . . . . . . . . . . . . . . . . . . 5 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . 4, 7, 10


X

Inside-Out-Objekte . . . . . . . . . . . . . . . . . . 10

XML . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 10, 11

21

Index

XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 4 XML Schema Validierung . . . . . . . . . . . . 14 XML-Serialisierung / Deserialisierung 8, 11 XML::Compile::Dumper . . . . . . . . . . . . . 13 XML::Compile::SOAP . . . . . . . . . . . . . . . 12 XML::LibXML . . . . . . . . . . . . . . . . . . . . . . 12 XML::Parser . . . . . . . . . . . . . . . . . . . . . . . . 11 XML::Schema . . . . . . . . . . . . . . . . . . . . . . . 10

22