State of the Soap

State of the SOAP

Martin Kutter

Submitted for the proceedings of 10th German Perl Workshop,

February 13-15, 2008

Inhaltsverzeichnis

1 Einführung 41.1 SOAP-Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 The Web Services Dream . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 The Web Services Cold Shower . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Perl's SOAP Toolkits 62.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 SOAP::Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 SOAP::WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 XML::Compile::SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Performance 143.1 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Welche Seife passt zu mir? 16

5 State of the SOAP 18

6 Bibliographie / Bibliography 18

1

Autor

Autor

Martin Kutter <[email protected]>,

Bio Martin Kutter

Martin Kutter ist Diplom-Psychologe und kümmert sich seit 2003 hauptberu�ich um dieSchwierigkeiten 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.

2

Abstract

Abstract

Web-Services mit XML-RPC und SOAP sind inzwischen allgegenwärtig - von Wikis wieTWiki ü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: KeithBrown's SOAP wird seit 2000 nicht mehr gep�egt, Pavel Kulchenko's SOAP::Lite setzt aufdie inzwischen kaum noch verbreitete RPC-Variante und neuere Module wie SOAP::WSDLoder Mark Overmeer's XML::Compile::SOAP haben hohe Anforderungen an Perl-Versionoder installierte Module und unterstützen (noch) nicht den gesamten Umfang der SOAP-und WSDL-Spezi�kationen.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 ver-passen !

3

1 Einführung

1 Einführung

SOAP - früher das Simple Object Access Protocol, seit SOAP1.2 kein Akronym mehr, istein Protokoll für den Nachrichtenaustausch zwischen Rechnersystemen. Der gängigsteEinsatzzweck sind Web-Services (also SOAP über HTTP/S), das gängigste Kommunika-tionsmuster Request/Response (mit XML-Remote Procedure Calls). Andere Kommuni-kationsbeziehungen wie z.B. Publish-Subscribe werden über entsprechende Kommunika-tionsmuster untersützt.SOAP-Nachrichten sind XML-Nachrichten, die dem SOAP XML Schema entsprechen.Über Erweiterungen im SOAP-Schema lassen sich SOAP-Nachrichten auch MIME oderDIME codieren.Für die De�nition von Web-Services gibt es eine standardisierte Sprache: WSDL, die WebService Description Language. WSDL erlaubt die Verwendung verschiedener Protokollefür einen Service über sogenannte Bindings - die beiden gängigsten Bindings sind SOAPund HTTP.

1.1 SOAP-Nachrichten

SOAP-Nachrichten bestehen aus einem Envelope, einem (optionalen) Header und einemBody. SOAP-Header und -Body enthalten die eigentlichen Nutzdaten. Ein SOAP-Requestfür den für 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">

4

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 Pre�xe für die XML-Namespaces gewählt. Das ist zulässig - die Namespace-URIs sind entscheidend, die Pre�xesind bedeutungslos.Die SOAP-Nachrichten aus diesem Beispiel verwenden den document Nachrichten-Stilund 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 de�nierte Nachrichten-Dokumente. rpc-Nachrichten enthalten einen Methoden-Namen als XML-Element und eine Liste positio-naler Parameter für diese Methode. Die Nachrichten oben könnten auch als rpc/literalde�niert werden - neuere Web-Services wählen ihre De�nitionen meist so, dass die Nach-richten auf verschiedene Arten erzeugt werden können.Die literal Codierung erlaubt keine über die De�nition der Dokumente hinausgehendenEncodings, während encoded die in der SOAP-Spezi�kation festgelegten Encodings, z.B.für Listen unterstützt.Aktuelle Interoperability-Standards ( WS-I Basic Pro�le) fordern die Verwendung von do-cument/literal oder rpc/literal, wobei document/literal die aktuell am weitesten verbreiteteVariante ist. Die Kombination document/encoded wird praktisch nie verwendet. rpc/literalwird häu�g in Skriptsprachen (perl, php, python etc.) eingesetzt. Die Verwendung dieserVariante ist nach dem WS-I Basic Pro�le nicht mehr erlaubt.SOAP-Nachrichten können Attachments enthalten und MIME- oder DIME-codiert übertra-gen werden.

1.2 The Web Services Dream

ist der Name eines Kapitels in Programming Web Services with Perl von Randy Ray undPavel Kulchenko. Beschrieben wird eine schöne neue Welt, in der alle Systeme über WebServices miteinander kommunizieren können, dank standardisierter Beschreibungen keineKompatibilitätsprobleme haben und sogar über Web-Service Registries (das Protokolldazu heist UDDI) die Adresse eines Service aus seinem Namen oder anderen Daten inErfahrung bringen können.

1.3 The Web Services Cold Shower

ist der Name des nächsten Kapitels in Programming Web Services with Perl.Nach der Web-Service Euphorie folgte etwa ab 2002 die groÿe Ernüchterung. Einige derTeile aus The Web Services Dream wie UDDI sind inzwischen wieder eingestampft, anderewie die Interoperabilität sollen durch zusätzliche Standards wie das WS-I Basic Pro�le

5

2 Perl's SOAP Toolkits

erreicht werden, mit denen die Möglichkeiten von SOAP und WSDL auf ein Minimumbeschränkt werden.Für Perl war die Cold Shower besonders kalt: Es gab bis 2004 nur zwei SOAP-Toolkits,das eine davon - SOAP - wird seit 2000 nicht mehr gep�egt, das andere - SOAP::Litesetzt mit der rpc/encoded Variante von XML-Nachrichten auf das falsche Pferd - der Restder Welt verwendet document/literal.Perl's SOAP-Bibliotheken sind leider auch nicht für besonders gute Benutzbarkeit be-kannt. Die Frustration der Benutzer geht teilweise schon so weit, andere Sprachen zuverwenden:

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 verö�entlicht, das zunächst als Wrapper für SOAP::Lite

mit WSDL-Unterstützung für document/literal-Nachrichten implementiert war und in-zwischen zu einem eigenen SOAP Toolkit herangewachsen ist. Im letzten Jahr hat MarkOvermeer mit XML::Compile::SOAP und eine weiteres SOAP-Modul verö�entlicht, dasdie XML-Schema-Basis von SOAP und WSDL betont.Mit diesen Perl-Modulen gibt es inzwischen eine Reihe von Lösungsansätzen für dasgleiche Problem. Dieser Beitrag befaÿt sich mit den Gemeinsamkeiten und Unterschiedender CPAN-Distributionen SOAP, SOAP-Lite, SOAP-WSDL und XML-Compile-SOAP.Für alle SOAP-Toolkits (mit Ausnahme von SOAP) ist beispielhaft die Implementierungeines SOAP Client abgedruckt, der auf einen HelloWorld Web-Service zugreift. Der Ser-vice akzeptiert Name und Vorname als Parameter und antwortet freundlich mit

"Hello $Vorname $Name!"

Die zugehörigen Dateien (SOAP-Server, WSDL-De�nition, Clients) sind Teil der SOAP-WSDL Distribution (im Verzeichnis example).


2.1 SOAP

SOAP von Keith Brown (DevelopMentor) ist ein Toolkit für das Schreiben von SOAPClients und Servern. Das Modul wurde in Zusammenarbeit mit dem Java-EntwicklerDon Box erstellt, um ähnliche Toolkits für beide Sprachen zu entwickeln.SOAP wird seit 2000 nicht mehr gep�egt. Auf eine weitere Diskussion wird daher verzich-tet. Programming Web Services with Perl enthält eine Übersicht über die Funktionsweisevon SOAP.

6

2.2 SOAP::Lite

2.2 SOAP::Lite

Funktionsumfang SOAP::Lite von Pavel Kulchenko wurde mit dem Anspruch entwi-ckelt, ein vollständiges Web-Service Toolkit für Perl zu schreiben. SOAP::Lite ist unterallen Perl-Versionen ab 5.005 lau�ähig, und bietet eine fast vollständige Unterstützungfür SOAP-Client und Server, UDDI-Clients und XMLRPC-Clients.SOAP::Lite unterstützt SOAP1.1 und SOAP1.2.rpc/encoded Web-Services werden sehr gut unterstützt, die Implementierung vonrpc/literal oder document/literal Web-Services ist umständlich.Mit dem Skript stubmaker.pl bietet SOAP::Lite eine rudimentäre WSDL-Unterstützung. SOAP::Lite unterstützt dabei keine verschachtelten complexType-De�nitionen im verwendeten XML Schema.

Aufbau SOAP::Lite ist ein Plugin-basiertes Toolkit - viele Komponenten sind aus-tauschbar.Fast alle Perl-Klassen sind im Modul SOAP::Lite enthalten, so dass meist eine einzigeZeile genügt, um alle benötigten Klassen zu laden:

use SOAP::Lite;

Eine SOAP-Nachricht durchläuft bei SOAP::Lite-basierten Programmen mehrere Schich-ten. Der SOAP-Client nimmt die Daten vom Programm entgegen und übergibt sie aneinen Serializer, der die Daten in XML umwandelt. Sofern nötig, wird die entstandeneXML Nachricht vom SOAP::Packager in eine MIME/DIME-Nachricht umgewandelt, undvon einem SOAP::Transport-Modul an den Server versendet. Die Antwort wird bei Be-darf vom SOAP::Packager zerlegt und von einem Deserializer in eine Perl-Datenstrukturzurückverwandelt. Serializer, Deserializer und Transportschicht sind austauschbar, wo-bei SOAP::Lite sehr hohe Anforderungen an Plugins stellt: So müssen z.B. Transport-Plugins im Namespace SOAP::Transport liegen, den Namen des Protokolls als letzteKomponente im Namen haben (z.B. ::HTTP) und eine Client- und/oder Server-Klasse(z.B. SOAP::Transport::HTTP::Client und SOAP::Transport::HTTP::Server) imple-mentieren. Dadurch ist es relativ schwer, SOAP::Lite mit Plugins zu erweitern.SOAP::Lite verwendet ein in Perl wenig verbreitetes Programmiermodell: Alle Objekt-Methoden geben - als Setter aufgerufen - das Objekt zurück, so dass sich Methodenaufrufeverketten lassen.

my $soap = SOAP::Lite->new()

->proxy('http://www.example.org')

->autotype(0);

7


XML-Serialisierung / Deserialisierung SOAP::Lite erzeugt SOAP-Nachrichten ent-weder aus einfachen Perl-Hashes oder aus SOAP::Data Objekten. Perl-Hashes könnendabei nur für einfache Datenstrukturen verwendet werden: Für Baumstrukturen müssenSOAP::Data-Objekte verwendet werden.SOAP::Data-Objekte erlauben fast vollständige Kontrolle über das erzeugte XML. Dievom Serializer erwartete Struktur ist für komplexe Datenstrukturen aber wenig intuitiv.Sofern die XML-Datentypen nicht explizit (über das type-Attribut der SOAP::Data-Objekte) angegeben sind, versucht SOAP::Lite den passenden XML-Datentyp zu erraten.SOAP::Lite verwendet dazu einen Satz an Regular Expressions, mit denen der gemeinteDatentyp erkannt wird. Dieses autotyping funktioniert für rpc/encoded Schnittstellen inder Regel gut.Aus den SOAP-Nachrichten erzeugt SOAP::Lite ein Message-Objekt der KlasseSOAP::SOM. Über dieses lassen sich sowohl Fehler wie auch die einzelnen Nachrichten-elemente abrufen:

die $som->fault->{ faultstring } if ( $som->fault() );

print $som->result, "\n";

Der Zugri� auf tieferliegende Nachrichtenelemente ist per XPath möglich. Es können nureinfache Perl-Datenstrukturen (Skalare, Listen) abgerufen werden, für komplexe Struk-turen (Bäume) müssen mehrere XPath-Ausdrücke eingesetzt werden.

Erweiterbarkeit Obwohl SOAP::Lite Plugin-basiert designt wurde, gibt es kaum Er-weiterungen. Ursache dafür ist vermutlich der komplexe Code, der als nahezu unwartbargilt.

Code-Generator SOAP::Lite verwendet einen programmatischen Code-Generator, d.h.der erstellte Perl-Quellcode wird durch die Verkettung von Strings und Here-Dokumentenerstellt.

Code-Beispiel Das Code-Beispiel zeigt die Client-Implementierung für den HelloWorld-Web-Service.Die aus anderen Quellen als der SOAP::Lite-Dokumentation benötigten Informationensind in den Kommentaren beschrieben.

#!/usr/bin/perl

use strict;

use warnings;

use SOAP::Lite;

8

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 Stärke ist seine gute Abwärts-Kompatibilität - es läuft auchnoch unter perl-5.005.Für die Implementierung von rpc/encoded SOAP-Clients und Server ist SOAP::Lite un-eingeschränkt zu empfehlen: Kein anderes Toolkit erlaubt es, Web-Services so einfachumzusetzen.Mit dem Fokus auf rpc/encoded-Nachrichten und der schlechten WSDL-Unterstützungbietet das Toolkit wenig Unterstützung für die Implementierung aktueller do-cument/literal Web-Services. Da keinerlei Dokumentations-Artefakte aus WSDL-De�nitionen erzeugt werden, müssen Entwickler Kenntnisse in XML, SOAP und WSDLhaben, oder sich auf Beispiele verlassen können.SOAP::Lite bietet zur Zeit als einziges Perl-Toolkit die Möglichkeit, SOAP-Attachementszu verarbeiten.SOAP:Lite wird aktiv gep�egt und ist relativ weit verbreitet - mit der Entscheidung fürSOAP::Lite in Projekten kann man wenig falsch machen, aber auch wenig gewinnen.

9


2.3 SOAP::WSDL

Funktionsumfang SOAP::WSDL, ursprünglich als Präprozessor für SOAP::Lite entstan-den, ist seit der Version 2 ein eigenständiges SOAP Toolkit. Es benutzt SOAP::Lite'sTransport-Module, sofern vorhanden. SOAP::WSDL unterstützt WSDL-basierte SOAP-Clients und -Server für SOAP1.1 und WSDL 1.1. Die Unterstützung von SOAP1.2ist geplant, für SOAP-Server gibt es bisher nur eine CGI-basierte Implementierung.SOAP::WSDL unterstützt bisher nur den document/literal Nachrichten-Stil.Das Erstellen von SOAP-Schnittstellen ist auch ohne WSDL möglich, aber wenig kom-fortabel. Der Autor rät dazu, im Zweifelsfall eine De�nition mit einem WSDL-Editor zuerstellen und die Schnittstellen daraus zu generieren.SOAP::WSDL unterstützt noch nicht den gesamten Umfang der WSDL- und XML-Schema-Spezi�kation.

Aufbau SOAP::WSDL kann SOAP-Client- und -Server-Klassen aus WSDL-De�nitionenerzeugen. Es bietet auch einen on-the-�y erzeugten Client - der Autor emp�elt aber, denCode-Generator zu verwenden.Beim Aufruf einer Methode eines generierten Client-Interfaces, übergibt der SOAP-Client die Argumente an einen Serializer, der sie in eine XML-Nachricht umwandelt.Ein Transport-Objekt sorgt für das Senden und Empfangen, und ein Deserializer erzeugtaus der SOAP-Nachricht ein Antwort-Objekt.SOAP::WSDL bringt eine eigene XML-Schema-Implementierung mit: SOAP::WSDL's Code-Generator erzeugt Klassen für alle in der WSDL-De�nition verwendeten XML-Schema-Datentypen. Die erzeugten Klassen basieren auf Class::Std::Fast, einer performante-ren Variante von Class::Std von Damian Conway. Die Umsetzung von XML-Schema-Datentypen in Klassen ähnelt der von .NET: Jeder XML-Knoten wird als Objekt abge-bildet. Die Kind-Knoten eines XML-Knoten sind als Eigenschaften der entsprechendenKlasse modelliert. Durch die Verwendung von Inside-Out-Objekten ist der Zugri� nurüber Methoden möglich. Für jede Eigenschaft wird eine get_FOO und eine set_FOO-Methode erzeugt.Diese Daten-Klassen haben interessante Usability-Features: Die Konstruktoren aller kom-plexer Datentypen akzeptieren eine (komplexe) Hash-Referenz als Parameter in der Hash-und Listen-Referenzen oder Objekte enthalten sein dürfen. Ruft man eine nicht vorhan-dene Methode auf ein solches Objekt auf, so enthält die Fehlermeldung eine Liste dervorhandenen Eigenschaften. Datums-, boolean und andere Werte werden automatisch indas entsprechende XML-Format konvertiert.Class::Std::Fast ist auch für einige Besonderheiten im Laufzeitverhalten vonSOAP::WSDL verantwortlich. Wie alle Inside-Out-Implementierungen verschiebtClass::Std::Fast einen Teil des Verwaltungs-Overhead in den Destruktor. Eineweitere Besonderheit von Class::Std::Fast ist ein Objekt-Cache (eine Variation des

10

2.3 SOAP::WSDL

Flyweight-Pattern), um die Kosten für das Erzeugen von Objekten beim mehrmaligenErzeugen und Zerstören von Objekten der gleichen Klasse zu reduzieren.

XML-Serialisierung / Deserialisierung SOAP::WSDL verwendet seit der Version 2 einenXML::Parser-basierten XML-Parser. SOAP::WSDL wandelt Objekte in XML-Nachrichtenum und erzeugt aus diesen wieder Objekte. Die Klassende�nitionen für die Objektewerden aus der WSDL-Datei erzeugt.Der XML-Parser benötigt eine Struktur-Map (Typemap, eine Lookup-Tapelle für die zueinem XPath-Ausdruck gehörenden Perl-Klassen) für das Parsen von XML-NachrichtenDie aus XML-Schema-Datentypen generierten Klassen besitzen Methoden zur Umwand-lung der Daten nach XML.

Erweiterbarkeit SOAP::WSDL kann an vielen Punkten erweitert werden: SOAP Serializerund Deserializer, Transportschicht und sogar der Code-Generator lassen sich austauschen.Für die Einbindung in Module, die alternative Darstellungsformen für die SOAP-Nachrichten benötigen, gibt es Deserializer die Hash-Referenzen und SOAP::SOM-Objekteerzeugen.

Code-Generator SOAP::WSDL verwendet einen template-basierten Code-Generator.SOAP Client- und Server-Klassen, wie auch die XML Schema basierten Datentypenwerden mit Hilfe des Template Toolkit (Template) erzeugt.Die für den XML-Parser benötigten Maps werden als Hash-Referenzen erzeugt, und perData::Dumper in Perl-Quellcode umgewandelt.

Code-Beispiel Das Code-Beispiel zeigt die Client-Implementierung für den HelloWorldWeb-Service.

#!/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


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";

Bewertung Die Beschränkung auf document/literal Web-Services und (bisher) SOAP1.1 erlauben den Einsatz von SOAP::WSDL nur einen Teil von Web-Services - allerdingsdem gröÿten Teil der aktuellen Web-Services.Die generierten Dokumentations-Artefakte sind ein groÿes Plus für Entwickler ohne Er-fahrung mit WSDL / XML-Schema-De�nitionen: Die benötigten Informationen könnenin einer für Perl-Entwickler geläu�gen Form als Pod eingesehen werden.SOAP::WSDL ist performant und benötigt wenig Speicher. Die Inside-Out-Objekte auf derBasis von Class::Std::Fast sparen Speicherplatz, vor allem bei groÿen Datenstruktu-ren. SOAP::WSDL forciert mit seinen Class::Std::Fast-basierten Datentyp-Klassen einbestimmtes Programmiermodell. Durch die alternativen Serializer / Deserializer lässt essich aber auch in Projekte mit anderen Modellen einsetzen.

2.4 XML::Compile::SOAP

Funktionsumfang XML::Compile::SOAP unterstützt SOAP-Clients und Server fürSOAP 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 miss-billigt die Verwendung von rpc/encoded-Nachrichten in der Dokumentation.XML::Compile::SOAP erstellt WSDL-basierte SOAP-Clients und -Server als Closures ausWSDL-De�nitionen. Das Erstellen von SOAP-Schnittstellen ist auch ohne WSDL mög-lich, aber wenig komfortabel.

Aufbau XML::Compile::SOAP basiert auf der XML-Schema-Implementierung vonXML::Compile. XML::Compile::SOAP erweitert XML::Compile um einenWSDL-Prozessorund einen SOAP Client und -Server.

Serialisierung / Deserialisierung XML::Compile::SOAP benutzt das DOM-API vonXML::LibXML sowohl für die Serialisierung wie auch die Deserialisierung von XML-Nachrichten. Beim Deserialisieren wird ein DOM-Baum von einem Parser in Perl-Hash-Strukturen umgewandelt.

12

2.4 XML::Compile::SOAP

Beim Serialisieren werden Perl-Hash-Strukturen zunächst in einen DOM-Baum und dannin XML transformiert.XML::Compile::SOAP validiert die SOAP-Nachrichten - die Validierung geschieht im Perl-Teil, nicht mit den Möglichkeiten der XML-Schema Validierung von XML::LibXML.

Erweiterbarkeit XML::Compile::SOAP erlaubt zur Zeit lediglich den Austausch derTransportschicht.

Code-Generator Der Code-Generator von XML::Compile::SOAP verfolgt einen sehr in-teressanten Ansatz. XML::Compile durchsteigt einen DOM-Baum und erzeugt dabei einClosure-basiertes Parser-/Generator-Paar für DOM Bäume nach dem Prinzip rekursivabsteigender Parser.Das Ergebnis sind zwei Funktionen, die von XML::Compile::Dumper mit Hilfe vonData::Dump::Streamer in Perl Code umgewandelt werden können.Die so erzeugten Funktionen verwenden die Client- und Server- Funktionen der ent-sprechenden Protokoll-Module (z.B. XML::Compile::SOAP11::Client), um die SOAP-Messages zu transportieren.Der Code-Generator ist damit eine interessante Sonderform programmatischer Code-Generatoren: Statt Quellcode wird vom Generator eine Code-Referenz erzeugt, die vonData::Dumper::Streamer in Quellcode transformiert wird.Die Code-Referenz ist allein schon ausführbar, die weitere Transformation in Quellcodeist optional und wird vom Autor nicht mehr empfohlen.

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";

Bewertung 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 ungültige Daten sendet, aber nicht geändert werdenkann? Die XML-Validierung ist im Perl-Teil implementiert - eine aus meiner Sicht nichtganz nachvollziehbare Entscheidung: XML::LibXML und die darunterliegende libxml2können XML Dokumente anhand von XML Schemata validieren, so dass sich der zusätz-liche Nutzen auf die Validierung des SOAP-Envelope beschränkt.XML::Compile::SOAP besitzt die z.Zt. vollständigste XML-Schema-Implementierung - eskann mit Hilfe von Callbacks auch mit any und anyAttribute-De�nitionen umgehen.Der Closure-basierte Generator für Server- und Client-Funktionen ist nicht für alle Perl-Entwickler verständlich: Die Arbeit mit Closures ist weniger verbreitet als z.B. Objek-torientierte Programmierung. Da keinerlei Dokumentations-Artefakte erzeugt werden,müssen Entwickler Kenntnisse in XML, SOAP und WSDL haben.

3 Performance

Performance kann für Web-Service-Toolkits entscheidend sein - jedes Einsatzgebiet stelltbestimmte Performance-Anforderungen. Während für Web-Services wie die geplanteCPAN6 Paketverwaltung nur moderate Performance-Anforderungen gelten, legt der Ein-satz von Web-Services z.B. als Backend für Websites die Performance-Messlatte ungleichhöher: Ein Benutzer wartet zwar auf perl -MCPAN6 - aber nicht auf einen Website-Aufrufim Browser. Die Performance-Eigenschaften können daher - je nach Einsatzzweck - eink.o.-Kriterium für ein SOAP-Toolkit, oder sogar für den Einsatz von Perl als Implemen-tierungssprache sein.

3.1 Benchmark

Für das Benchmark wurde ein Test-Webservice de�niert, und eine feste Response-Nachricht erzeugt. Im Test-Web-Service wird eine Liste an komplexen Personen-Datensätzen abgerufen, die Antwort ist ca. 10kB lang - eine für Websites im Unter-nehmensumfeld übliche Operation mit einer kleinen Datenmenge.

14

3.2 Ergebnisse

Der Test-Web-Service wurde als CGI-basierter SOAP-Server mit SOAP::WSDL implemen-tiert. Den eigentlichen Plan die Transportschicht aller Toolkits zu umgehen, konnte ichleider nicht umsetzen, da die dafür notwendigen Methoden in XML::Compile::Tester

noch nicht oder nicht mehr verfügbar waren.Die Benchmark-Datei benchmark/person.pl wie auch der SOAP-Serverexample/cgi-bin/person.pl entstammen der SOAP-WSDL-Distribution in derVersion 2.00_29.Im Benchmark ist mit SOAP::WSDL_XS eine noch nicht verö�entlichte Distribution mitaufgeführt, die einen in XS implementierten XML Deserializer für SOAP::WSDL bereit-stellt.Das Benchmark besteht aus drei Durchläufen: Im ersten Durchlauf (Benchmark 0) wirddie Ausgabe des Client-Aufruf in einer privaten Variable gespeichert und sofort wiederzerstört.Im zweiten Durchlauf (Benchmark 1) werden alle Ergebnisse in einer Liste gespeichertund erst nach Ende des Benchmark zerstört. Damit spielt die Zeit für das Zerstören derErgebnisse (Destruktor) keine Rolle für 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 mit1GB RAM) unter perl-5.8.8 auf Ubuntu 7.10 durchgeführt. Der CGI-basierte SOAP-Server 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


SOAP::Lite 23.8/s -- -34% -68% -85%


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


SOAP::Lite 23.7/s -- -35% -71% -87%


SOAP::WSDL 82.0/s 246% 125% -- -54%

SOAP::WSDL_XS 179/s 654% 391% 118% --

Die Ergebnisse zeigen zunächst deutlich den E�ekt der Inside-Out-Objekte beiSOAP::WSDL und SOAP::WSDL_XS: Beide sind im Benchmark 1 und 2, in denen die Arbeitdes Destruktors nicht berücksichtigt wird deutlich schneller.Benchmark 2 zeigt den E�ekt des Objekt-Cache von Class::Std::Fast, der bei noch-maliger Durchführung ca. 10% Performance-Gewinn bringt.Insgesamt ist SOAP::Lite bei der Verarbeitung am langsamsten. SOAP::WSDL ist in allenDurchläufen schneller als SOAP::Lite oder XML::Compile::SOAP.Beim Einsatz von SOAP::WSDL in persistenten Umgebungen (z.B. mod_perl) lassen sichzusätzliche Geschwindigkeitsvorteile erzielen, indem das Zerstören der Objekte auf einenZeitpunkt nach dem Beantworten von Benutzeranfragen verschoben wird. Auch derObjekt-Cache von Class::Std::Fast bringt hier weitere Performance-Vorteile.Für XML::Compile::SOAP sind in weiteren Versionen Performance-Steigerungen zu er-warten. Das Modul ist noch relativ jung und sicher noch nicht vollständig optimiert.Das noch nicht verö�entlichte SOAP::WSDL:_XS zeigt, dass eine noch deutlich besserePerformance möglich 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 zuempfehlen, die im Zweifelsfall entsprechende Maintenance-Arbeiten selbst übernehmenkönnen und wollen.SOAP::Lite punktet mit Abwärts-Kompatibilität und Umfang: Es läuft auch noch aufPerl 5.005, unterstützt SOAP-Clients und Server, SOAP Attachements mit MIME undDIME-Nachrichten und die meisten SOAP-Encodings. Abzüge gibt es für die rudimentä-re WSDL-Unterstützung, den Fokus auf rpc/encoded, das für komplexere Web-Serviceskomplizierte API und in der B-Note: SOAP::Lite ist alles andere als Lite, sondern mit>160kB Quellcode ein echtes Schwergewicht. Darunter leiden Verständlichkeit und Wart-barkeit. Weitere Nachteile von SOAP::Lite sind der relativ hohe Speicherverbrauch unddie schlechte Performance.SOAP::WSDL deckt mit dem Fokus auf WS-I kompatible Clients bisher nur eine Ni-sche ab - die Nische, in der die meisten Anwendungen liegen. Ein CGI-basierterSOAP-Server ist seit kurzem in der SOAP-WSDL-Distribution enthalten. Vorteile von

16

SOAP::WSDL sind niedriger Speicherverbrauch und hohe Performance, besonders in persis-tenten Umgebungen. Es bietet ein einfaches API für SOAP-Clients, verschiedene Erwei-terungsmöglichkeiten, und nutzt wo möglich (SOM-Deserialisierer, Transport) bestehen-de Perl-Module. SOAP::WSDL erzwingt mit seinen Class::Std::Fast-basierten Inside-Out Daten-Objekten die Verwendung eines bestimmten Objekt-Modells und fordertdurch die Namensgebung seiner Methoden einen bestimmten Programmierstil. Es deckt(noch) nicht das gesamte WS-I Basic Pro�le ab. SOAP::WSDL generiert als bisher einzi-ges Modul Pod-Dokumentation aus den WSDL-De�nitionen, so dass auch Nutzer ohneSOAP/WSDL/XML-Vorkenntnisse mit den generierten Artefakten arbeiten können.XML::Compile::SOAP kann sowohl SOAP-Clients wie auch SOAP-Server aus WSDL-Der�nitionen erzeugen. Es wandelt Perl-Hash-Datenstrukturen in SOAP-Nachrichtenum und vice versa. XML::Compile::WSDL punktet mit der vollständigen Umset-zung der XML-Schema De�nition, der Validierung von XML-Nachrichten und derfast vollständigen SOAP- und WSDL-Unterstützung. SOAP-Client und -Server er-zeugt XML::Compile::WSDL als Funktionsreferenzen (Closures) ohne Dokumentations-Artefakte, so dass für die Verwendung Kenntnisse in XML/SOAP/WSDL notwendig sind.Beim Einsatz in nicht-persistenten Umgebungen kostet das Erzeugen von SOAP-Clientoder -Server aus den WSDL-De�nitionen etwas Zeit. Insgesamt ist XML::Compile::SOAPetwas 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

Vollständigkeit 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 (rudimentär) 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-Unterstützung für Perl hat sich im letzten Jahr durch die beiden neuen Tool-kits SOAP::WSDL (2.xx) und XML::Compile::SOAP wesentlich verbessert: Es gibt (wieder)SOAP-Toolkits für Perl, die einfach zu handhaben sind und mit den gängigen SOAP-Clients und Servern zusammenarbeiten.Leider haben die beiden neuen SOAP-Toolkits auch zu einer Spezialisierung geführt: Esgibt nicht mehr das SOAP-Toolkit für Perl, der Benutzer muss sich vielmehr zwischeneiner der drei aktuell unterstützten Distributionen entscheiden. Während SOAP::WSDL

in vielen Punkten versucht, SOAP::Lite's API nachzubilden ist XML::Compile::SOAP

ein völlig neues Modul. Der Umstieg von einem SOAP-Toolkit auf das andere ist nurmit Einschränkungen möglich: SOAP::WSDL und XML::Compile::SOAP erwarten leichtunterschiedliche Datenstrukturen.Die aktuelle Entwicklung von SOAP::Lite geht zur Vereinfachung der Code-Basis. Sel-ten benötigte Komponenten sollen in eigene Distributionen ausgegliedert werden. EineIntegration der WSDL-basierten Toolkits als XML Serializer/Deserializer wäre möglich -vorausgesetzt, die erwarteten Datenstrukturen lassen sich auf einen gemeinsamen Nennerbringen.


Damian Conway

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

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

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

Pavel Kulchenko, Randy Ray, Byrne Reese, Martin Kutter

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

Martin Kutter

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 Pro�le 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 April2007. http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

W3C: Martin Gudgin, Marc Hadley et al.

SOAP Version 1.2 Part1: Messaging Framework W3CRecommendation (Second Edition) 27 April 2007.http://www.w3.org/TR/2007/REC-soap12-part1-20070427/

19


W3C: Martin Gudgin, Marc Hadley et al.

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

W3C: Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawara-

na

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 October2004. http://www.w3.org/TR/xmlschema-0/

W3C: Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn

XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October2004. http://www.w3.org/TR/xmlschema-1/

W3C: Paul V. Biron, Ashok Malhotra

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

20

Index

Symbols

.NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

A

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

B

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

C

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

D

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

E

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Erweiterbarkeit . . . . . . . . . . . . . . . . 8, 11, 13

F

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

H

HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I

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

M

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

P

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

R

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

S

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

T

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

U

UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

V

Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . 14

W

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

X

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

21

Index

XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 4XML Schema Validierung. . . . . . . . . . . .14XML-Serialisierung / Deserialisierung 8,

11XML::Compile::Dumper . . . . . . . . . . . . . 13XML::Compile::SOAP . . . . . . . . . . . . . . . 12XML::LibXML . . . . . . . . . . . . . . . . . . . . . . 12XML::Parser . . . . . . . . . . . . . . . . . . . . . . . . 11XML::Schema . . . . . . . . . . . . . . . . . . . . . . . 10

22

State of the Soap

Documents

Transcript of State of the Soap