WebServices in Perl

5/12/2018 WebServices in Perl - slidepdf.com

http://slidepdf.com/reader/full/webservices-in-perl 1/7

DEV DEVeloping Software Solutions — n. 127 — marzo 2005

WebServices in Perldi Fausto Zanasi

Per sviluppare Web Services secondo le specifiche SOAP/XML e pratica-mente necessario usare un toolkit. Il linguaggio Perl offre a questo scopoSOAP::Lite: uno strumento degno di nota per semplicita, potenza e completezza

Fausto Zanasi

E laureato in filosofia;autore di testi, docentee consulente, si occupa

di sviluppo software dal1977. Si occupa di OOP,DBMS, reti e ha svilup-pato progetti in Java,Delphi, Python, VisualC++ e Visual Basic.



pubblicato su

WWW.INFOMEDIA.IT

stampa digitale da

Lulu Enterprises Inc.

stores.lulu.com / infomedia

Infomedia

Infomedia e l’impresa editoriale che da quasi venti an-

ni ha raccolto la voce dei programmatori, dei sistemi-

sti, dei professionisti, degli studenti, dei ricercatori e dei

professori d’informatica italiani.

Sono piu di 800 gli autori che hanno realizzato per le te-

state Computer Programming, Dev, Login, Visual Basic

Journal e Java Journal, molte migliaia di articoli tecnici,

presentazioni di prodotti, tecnologie, protocolli, strumen-ti di lavoro, tecniche di sviluppo e semplici trucchi e stra-

tagemmi. Oltre 6 milioni di copie distribuite, trentamila

pagine stampate, fanno di questa impresa la piu grande ed

influente realta dell’editoria specializzata nel campo della

programmazione e della sistemistica.

In tutti questi anni le riviste Infomedia hanno vissuto del-

la passione di quanti vedono nella programmazione non

solo la propria professione ma un’attivita vitale e un vero

divertimento.

Nel 2009, Infomedia e cambiata radicalmente adottando

un nuovo modello aziendale ed editoriale e si e organiz-

zata attorno ad una idea di Impresa Sociale di Comunita,

partecipata da programmatori e sistemisti, separando le

attivita di gestione dell’informazione gestite da un board

comunitario professionale e quelle di produzione gesti-

te da una impresa strumentale. Questo assetto e in linea

con le migliori esperienze internazionali e rende Infome-

dia ancora di piu parte della Comunita nazionale degli

sviluppatori di software.

Infomedia e media-partner di manifestazioni ed eventi in

ambito informatico, collabora con molti dei pi u impor-tanti editori informatici italiani come partner editoriale e

fornitore di servizi di localizzazione in italiano di testi in

lingua inglese.

L’impaginazione automatica di questa rivista e realizzata al

100% con strumenti Open Source usando OpenOffice,

Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp,

Python e BASH

For copyright information about the contents of DEV, please see the section “Copyright” at the end of each ar-

ticle if exists, otherwise ask authors. Infomedia contents

is© 2005 Infomedia and released as Creative Commons

2.5 BY-NC-ND. Turing Club content is © 2005 Turing

Club released as Creative Commons 2.5 BY-ND.

Le informazioni di copyright sul contenuto di DEV so-

no riportate nella sezione “Copyright” alla fine di cia-

scun articolo o vanno richieste direttamente agli autori.

Il contenuto Infomedia e© 2005 Infomedia e rilasciato

con Licenza Creative Commons 2.5 BY-NC-ND. Il con-

tenuto Turing Club e © 2005 Turing Club e rilasciato

con Licenza Creative Commons 2.5 BY-ND. Si applicano

tutte le norme di tutela dei marchi e dei segni distintivi.

` E in ogni caso ammessa la riproduzione parziale o tota-

le dei testi e delle immagini per scopo didattico purch´ e

vengano integralmente citati gli autori e la completa

identificazione della testata.

Manoscritti e foto originali, anche se non pubblicati, non

si restituiscono.

Contenuto pubblicitario inferiore al 45%.

La biografia dell’autore riportata nell’articolo e sul

sito www.infomedia.it e di norma quella disponibi-

le nella stampa dell’articolo o aggiornata a cu-

ra dell’autore stesso. Per aggiornarla scrivere a

[email protected] o farlo in autonomia all’indirizzo

http: // mags.programmers.net / moduli / biografia

http://www.infomedia.it/

http://stores.lulu.com/infomedia




http://www.infomedia.it/



di Fausto Zanasi > [email protected]

54 DEV > n. 127 marzo 2005>>

programmazione Perl

Per sviluppare Web Services secondo

le specifiche SOAP/XML è pratica-

mente necessario usare un toolkit. Il

linguaggio Perl offre a questo scopo

SOAP::Lite: uno strumento degno di

nota per semplicità, potenza e com-

pletezza

La pigrizia, l’impazienza e la tracotanza sono,secondo Larry Wall, il creatore del linguaggioPerl, le tre grandi virtù del programmatore. Chiinizia ad occuparsi di WebServices le possiedetutte. Non desidera conoscere i dettagli (unaforma di pigrizia); è curioso di provare se que-

sta tecnologia mantiene quanto promette (impazienza) e, seè così , vuole fare quello che non è mai riuscito a fare primain modo soddisfacente con un server Web via HTML (traco-tanza).Il modulo Perl SOAP::Lite offre un’ottima risposta a questeesigenze. È semplice: nasconde (ma solo se lo si vuole) idettagli delle specifiche SOAP. È potente: bastano poche

righe di codice per scrivere client e server SOAP e provar-li subito. È completo: supporta tutte i più comuni protocol-li di trasposto (HTTP,FTP, POP, ecc..) e le estensioni WSDL,UDDI.

PerlIl principio fondamentale del linguaggio Perl è: ciò che èsemplice deve rimanere tale, ciò che è difficile deve esserepossibile. Spero di riuscire a dimostrare che, per sviluppare WebServices, è molto più facile usare SOAP::Lite che le cor-rispondenti soluzioni Java e .NET. Perl ha però un altromotto: c’è più di un modo di farlo. Si può rimanere scon-certati dalla varietà delle soluzioni espressive di Perl (inquanti modi si può ottenere lo stesso risultato) rispetto alla

semplicità di un altro linguaggio che offre un’unica forma,per quanto elegante. Ad uso degli audaci (i “virtuosi tracotanti”), che decidonoche vale la pena di provare questo “variopinto” linguaggioper godere dei vantaggi di SOAP::Lite, ho preparato laseguente tavola sinottica che riporta ciò che bisogna tenerpresente per (almeno) comprendere il codice Perl.

• La sintassi è, grosso modo, quella del C: il punto-e- virgola è usato come terminatore di istruzioni, ilblocco di istruzioni è racchiuso fra parentesi graffe,le istruzioni di assegnazione, if e while hanno lostesso senso.

• Perl è un linguaggio interpretato e senza tipi di dati:

non si usa la dichiarazione di tipo per le variabili; unlinguaggio di script dunque.• Una variabile è un nome di un’area di memoria. Il

carattere $ viene preposto alla variabile se questadenota un singolo valore, il carattere @ se denota

una array (vettore a indice numero), il simbolo % sedenota un insieme di coppie chiave/valore.

• L’istruzione package <nomePackage>; serve percreare uno spazio-di-nomi (come in Java): tutte le variabili e le funzioni usate di seguito a questa istru-zione gli apparterranno. La parola chiave my vieneusata per limitare la visibilità di una variabile all’in-terno di un ambito quale un file o un blocco. Unmodulo è un file che contiene un package e il cuinome coincide con quello del package (con esten-sione .pm).

• Un oggetto è un’area di memoria che “conosce” aquale classe appartiene. Una classe è un modulo chefornisce metodi per operare su oggetti. Un metodo èuna funzione il cui primo argomento è un riferimen-to ad un oggetto (o a una classe per i metodi stati-ci). La sintassi per applicare metodi ad oggetti èriferimentoOggetto->metodo(parametri) : la freccia alposto del più comune punto.

InstallazioneSupponiamo che Perl sia già installato correttamente. Se siha un’accesso a Internet ed è installato il moduloCPAN(.pm) si può scrivere dal prompt della shell di coman-di (DOS per WinX):

perl -MCPAN -e ‘install SOAP::Lite’

Questo comando effettua una connessione con il repository dei moduli Perl, il download del software, la configurazio-ne, attraverso la richiesta dei valori per i parametri , e l’in-stallazione. Altrimenti occorre procurarsi il package SOAP::Lite, peresempio presso il sito www.soaplite.com, e procedere comesi fa di solito per l’installazione di moduli Perl:

perl Makefile.PL

make

make test

make install

Su piattaforma Winx usare nmake invece di make.

Un primo esempio: un client per GoogleLa promessa di SOAP è l’interoperabilità: la possibiltà di richie-dere (e fornire) “servizi” fra client e server superando le diffe-renze di piattaforma e implementazione. Google, il più notomotore di ricerca per Internet, espone dei web services chepermettono di utilizzarlo, in modo alternativo ma equipollen-te a quello usuale via http/html. Le specifiche che li descrivo-no sono descritte in un file google.wsdl (contenuto in un filezip insieme ad altro materiale) reperibile pressohttp://www.google.com/apis/ . Inoltre è necessario possedere

una chiave di registrazione: un codice di tipo stringa che iden-tifica l’accreditamento presso google; la si può otterere semprepresso lo stesso sito. Dopo esserci procurati il file google.wsdle la chiave di registrazione, scriviamo un programma Perl chesia client SOAP verso i web-services di Google.

WebServices in Perl



use SOAP::Lite;

my $key = ‘************************’; # <<< scrivere

qui la chiave di registrazione

my $query = ‘Marilyn Monroe’;

my $google = SOAP::Lite->service(‘file:./GoogleSearch.wsdl’);

my $result = $google->doGoogleSearch($key, $query,

0, 10, ‘false’, ‘’, ‘false’, ‘’, ‘latin1’, ‘latin1’);

La prima istruzione prescrive di usare il modulo SOAP::Lite.Le due seguenti impostano i valori delle due variabili $key e $query rispettivamente alla chiave di registrazione e allastringa di ricerca. L’istruzione

my $google = SOAP::

Lite->service(‘file:./GoogleSearch.wsdl’);

istanzia la classe SOAP::Lite utilizzando il metodo service ilcui parametro è la URL che corrisponde al file wsdl: si ottie-ne un riferimento $google all’oggetto. L’istruzione successiva

my $result = $google->doGoogleSearch($key, $query,

0, 10, ‘false’, ‘’, ‘false’, ‘’, ‘latin1’, ‘latin1’);

applica il metodo doGoogleSearch all’oggetto per effettuare laricerca. La “firma” del metodo (numero, ordine e tipo dei para-metri) è definita sempre nel file google.wsdl in questo modo:

<message name=”doGoogleSearch”>

<part name=”key” type=”xsd:string”/>

<part name=”q” type=”xsd:string”/>

<part name=”start” type=”xsd:int”/>

<part name=”maxResults” type=”xsd:int”/>

<part name=”filter” type=”xsd:boolean”/>

<part name=”restrict” type=”xsd:string”/>

<part name=”safeSearch” type=”xsd:boolean”/>

<part name=”lr” type=”xsd:string”/>

<part name=”ie” type=”xsd:string”/>

<part name=”oe” type=”xsd:string”/>

</message>

L’esecuzione del metodo comporta la connessione con ilserver e lo scambio di messaggi SOAP, la richiesta e la rispo-sta. Quest’ultima viene ricevuta nell’originale formato SOAPdefinito, sempre nel file google.wsdl, in questo modo:

<message name=”doGoogleSearchResponse”>

<part name=”return” type=”typens:GoogleSearchResult”/>

</message>

. <xsd:complexType name=”GoogleSearchResult”>

<xsd:all>

<xsd:element name=”documentFiltering”

type=”xsd:boolean”/>

<xsd:element name=”searchComments”

type=”xsd:string”/>

<xsd:element name=”estimatedTotalResultsCount”

type=”xsd:int”/>

<xsd:element name=”estimateIsExact”


<xsd:elementname=”resultElements”type=”typens:

ResultElementArray”/>

<xsd:element name=”searchQuery”

type=”xsd:string”/>

<xsd:element name=”startIndex”


<xsd:element name=”endIndex”


<xsd:element name=”searchTips”type=”xsd:string”/>

<xsd:element name=”directoryCategories”

type=”typens:

DirectoryCategoryArray”/>

<xsd:element name=”searchTime”

type=”xsd:double”/>

</xsd:all>

</xsd:complexType>

L’oggetto $google (di tipo SOAP::Lite) compie, dietro lequinte, il lavoro di traslazione della risposta da questo for-mato a una struttura dati Perl referenziata da $result. Si trat-ta, in questo caso di un array associativo , hash in Perl: uninsieme di coppie chiave/valore. Per cui per stampare, peresempio, il valore di estimatedTotalResultsCount si scrive:

print $result->{‘estimatedTotalResultsCount’};

Val la pena di notare che la chiave resultElements ha un valore di un tipo -ResultElementArray - definito, sempre nelfile google.wsdl, in questo modo:

<xsd:complexType name=”ResultElementArray”>

<xsd:complexContent>

<xsd:restriction base=”soapenc:Array”>

<xsd:attribute ref=”soapenc:arrayType”

wsdl:arrayType=”typens:ResultElement[]”/>

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

…

<xsd:complexType name=”ResultElement”>

<xsd:all>

<xsd:element name=”summary” type=”xsd:string”/>

<xsd:element name=”URL” type=”xsd:string”/>

<xsd:element name=”snippet” type=”xsd:string”/>

<xsd:element name=”title” type=”xsd:string”/>

<xsd:element name=”cachedSize” type=”xsd:string”/>

<xsd:element name=”relatedInformationPresent”


<xsd:element name=”hostName” type=”xsd:string”/>

<xsd:element name=”directoryCategory”

type=”typens:DirectoryCategory”/><xsd:element name=”directoryTitle” type=”xsd:string”/>

</xsd:all>

</xsd:complexType>

SOAP::Lite traduce da questo formato in un array a indicenumerico di elementi, ognuno dei quali è un array associa-tivo. Quindi $result->{‘resultElements’} referenzia l’array deirisultati, che si può scorrere attraverso un ciclo for, e $result-

>{‘resultElements’}[$i] referenzia l’elemento i-esimo che è unarray associativo che corrisponde al tipo XSD ResultElement .Per esempio l’istruzione

for ($i = 0; $risultato =

$result->{‘resultElements’}[$i]; $i++) {print $risultato->{‘URL’};

}

stampa le URL dei risultati trovati.

DEV > n. 127 marzo 2005 55 <<

WebServices in Perl

programmazione Perl



Un altro breve esempio, a mo’ di conferma. Un web service,

il cui compito è restituire il codice fiscale inviando come para-

metri i dati anagrafici, è descrito, in formato wsdl, all’indiriz-

zo http://www.pinellus.com/cfc/Cod_fiscale.cfc?wsdl. L’esa-

me di questa risorsa, per esempio via browser, permette dideterminare il nome del metodo da chiamare (makecod) e i

parametri da passare (cognome, nome ecc…). Il programma

seguente permette di ottenere il risultato voluto:

use SOAP::Lite;

my $cfws = SOAP::Lite->service(‘http://www.

pinellus.com/cfc/Cod_fiscale.cfc?wsdl’);

my $cf = $cfws->makecod(‘cognome’,’nome’,’sesso’,

’provincia’,’comune’,’dataNascita’);

print $cf

Si noti che il descrittore del servizio non è un file wsdl che

abbiamo acquistito precedentemente, come nell’esempio

precedente di Google, ma una risorsa disponibile in rete

referenziabile tramite una URL. L’implementazione del ws,

sul lato server, è nascosta, e quindi irrilevante, per il nostro

client: basta che siano rispettate le regole di scambio mes-

saggi secondo il protocollo SOAP. Fin qui è fin troppo sem-

plice: cerchiamo di vedere cosa c’è sotto.

Un esempio completo: client e serverL’estrema semplicità degli esempi precedenti è dovuta dalla

presenza del file wsdl (Web Service Description Language)

che ha la funzione di descrivre compiutamente i servizi che

sono esposti da un server. Quando questo file manca, il client,

per poter costruire la richiesta, deve conoscere (almeno)

1) chi fornisce il servizio: la URL del server:chiamatoanche “endpoint” in wsdl o “proxy” nel caso di

SOAP::Lite.

2) quale servizio richiedere: l’individuazione, sul lato

server, avviene tramite un identificativo composto:

un namespace, chiamato “uri” in SOAP::Lite, e un

nome “proprio” della funzione richiesta all’interno di

questo namespace.

Per esempio per richiedere a un server, identificato dalla

URL http://localhost:1234, il servizio identificato dal name-

space Hello e dalla funzione sayHello si scrive il seguente

client SOAP::Lite:

use SOAP::Lite;$client = SOAP::Lite -> proxy(‘http://localhost:1234’);

$risposta = $client->uri(‘urn:Hello’) -> sayHello

(“richiesta del Client”);

print $risposta->result;

SOAP::Lite costruisce la seguente richiesta in formato

SOAP/XML

<?xml version=”1.0” encoding=”UTF-8”?>

<SOAP-ENV:Envelope

xmlns:xsi=”http://www.w3.org/1999/XMLSchema-instance”

xmlns:SOAP-ENC=”http://schemas.xmlsoap.org/soap/encoding/”

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”

xmlns:xsd=”http://www.w3.org/1999/XMLSchema”SOAP-ENV:encodingStyle=”http://

schemas.xmlsoap.org/soap/encoding/”>

<SOAP-ENV:Body>

<namesp1:sayHello xmlns:namesp1=”urn:Hello”>

<c-gensym3 xsi:type=”xsd:string”> richiesta

del Client </c-gensym3>

</namesp1:sayHello>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

che forse potrà impressionare chi non conosce le specifiche

SOAP/XML ma, grazie al nostro toolkit, tutto ciò resta oppor-

tunamente nascosto. Ciò che importa notare è il contenuto

dell’elemento SOAP-ENV:Body. Vi si trova la codifica del

richiamo della funzione: un elemento di nome sayHello il cui

namespace abbreviato è namesp1 che corrisponde, tramite

l’attributo xmlns:namesp1 a Hello . Il protocollo SOAP defini-

sce esclusivamente il formato delle richieste e delle risposte

dei servizi che il client e il server si scambiano, che sono cioè

specifici dell’applicazione.

Ma è indifferente, e non pone alcuna condizione, sul proto-

collo usato per trasportare questi messaggi che può essere

indifferentemente HTTP, FTP, SMTP/POP3 o altro. HTTP è

comunque quello più usato perchè opera già in modalità

richiesta/risposta, che è quella propria di SOAP. SOAP::Lite,

sul lato client , identifica il protocollo da usare a partire dalla

URL del parametrro proxy : nell’esempio precedente è http e

quindi viene istanziato un oggetto a partire dal modulo

SOAP::Transport::HTTP::Client che incapsula la precente

richiesta SOAP/XML in un prologo HTTP e gestisce l’invio al

server:

SOAP::Transport::HTTP::Client::send_receive:

POST http://CHAOS:9080

Accept: text/xml

Accept: multipart/*

Content-Length: 505

Content-Type: text/xml; charset=utf-8

SOAPAction: “urn:Hello#sayHello”

<segue richesta SOAP/XML>

Sul lato server la richiesta SOAP/XML viene presa in carico, in

ultima istanza, da quello che chiameremo nel seguito SOAP-

Server. Ma, simmetricamente a quanto accade sul lato client,

nemmeno il SOAP-Server si occupa di gestire il trasporto dei

messaggi. Quindi viene collegato, come estensione attivabile

alla bisogna, a un server che compie questa funzione: tipica-

mente il SOAP-Server opera come estensione CGI a un Web-

Server, per esempio Apache. SOAP::Lite permette però di

ottenere un SOAP Server che implementi anche il protocollo

di trasposto HTTP e agisca quindi come demone, ponendosiin ascolto delle richieste in arrivo su una determinata porta.

Occorre creare un oggetto istanza della classe

SOAP::Transport::HTTP:: Daemon

use SOAP::Transport::HTTP;

my $SoapServer = SOAP::Transport::HTTP::Daemon

->new (LocalPort => 1234);

Il SOAP-Server riceve, dunque, la richiesta di un servizio

identificato da un namespace (parametro uri del client) e

da un nome di funzione. A questo punto SOAP::Lite agisce

così: ricerca un modulo Perl (file con estensione pm) che

abbia un nome uguale al namespace. Per specificare dove il

SOAPServer deve cercare il modulo, occorre usare il meto-do dispatch_to che ha come argomento la directory dove si

trovano i moduli che implementano i servizi:

$SoapServer -> dispatch_to(‘/home/httpd/soap_modules/’);

WebServices in Perl

56 DEV > n. 127 marzo 2005>>

programmazione Perl



# per Win32 : $SoapServer

-> dispatch_to(‘C:\\miaDir\\moduliSoap’)

Inoltre, deve mettersi in attesa delle eventuali richeste dei

client. Questo si ottiene con il metodo handle

$SoapServer ->handle;

Il programma sul lato server è così completo. Supponiamoche in /home/httpd/soap_modules/ si trovi Hello.pm il cuicontenuto sia:

package Hello;

sub sayHello {

my($refOggetto, $parametroDalClient) = @_;

return “Risposta a: “ . $parametroDalClient;

}

1;

Secondo la “via” Perl all’Object Oriented questa è (anche)una classe con la definizione di un metodo sayHello . Il pro-gramma SOAP-Server, a seguito della richiesta, carica questaclasse, l’ istanzia ed esegue sull’oggetto ottenuto il metodosayHello passandogli il parametro che riceve dal client. Sinoti che è creata una nuova istanza per ogni richiesta del(dei) client e queste istanze sono reciprocamente indipen-denti.Il risultato viene ricodificato in un messaggio SOAP/XMLche viene rinviato al client.Di seguito viene mostrato questo messaggio insieme al suoprologo HTTP:

SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK

Date: Sat, 24 May 2003 16:28:53 GMT

Server: libwww-perl-daemon/1.26

Content-Length: 527

Content-Type: text/xml; charset=utf-8

Client-Date: Sat, 24 May 2003 16:28:53 GMT

Client-Peer: 127.0.0.1:9080

Client-Response-Num: 1

SOAPServer: SOAP::Lite/Perl/0.55

<?xml version=”1.0” encoding=”UTF-8”?>

<SOAP-ENV:Envelope

xmlns:xsi=”http://www.w3.org/1999/XMLSchema-instance”

xmlns:SOAP-ENC=”http://schemas.xmlsoap.org/soap/encoding/”xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”

xmlns:xsd=”http://www.w3.org/1999/XMLSchema”

SOAP-ENV:encodingStyle=”http://

schemas.xmlsoap.org/soap/encoding/”>

<SOAP-ENV:Body>

<namesp2:sayHelloResponse xmlns:namesp2=”urn:Hello”>

<s-gensym6 xsi:type=”xsd:string”>Risposta a:

richiesta del Client </s-gensym6>

</namesp2:sayHelloResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Il client che riceve la risposta in formato SOAP/XML la tra-

sforma in un oggetto Perl. L’esecuzione delle due istruzioni,del client SOAP::Lite esposto precedentemente

$risposta = $client->uri(‘urn:Hello’)

-> sayHello(“richiesta del Client”);

print $risposta->result;

producono :

Risposta a: richiesta del Client

Le due attività simmetriche, che permettono di passare dalmessaggio SOAP/XML all’oggetto Perl e dal richiamo di unmetodo a un messaggio SOAP/XML, sono chiamate serializza-zione e deserializzazione. Entrambe sono svolte da SOAP::Litein modo autonomo. Il programmatore si limita, sul lato client,a istanziarne un oggetto fornendo il necessario parametro proxy e a richedere a quest’ultimo i servizi. Sul lato server aistanziare un oggetto che riceve la richiesta, la deserializza e lariindirizza alla classe/metodo specificati. Come si è detto, c’èpiù di un modo per farlo (in Perl). Sul lato client, per esempiosi può operare in modalità autodispatch , aggiungendo questoparametro al richiamo del modulo:

use SOAP::Lite +autodispatch;

Quando questa modalità è abilitata, i metodi che non sonodisponibili localmente sono automaticamente inviati alSOAP-Server e là eseguiti. Il programma client dell’esempioprecedente diventa

use SOAP::Lite +autodispatch;

$client = SOAP::Lite -> proxy(‘http://localhost:9080’);

$HelloObj = $client->uri(‘urn:Hello’);

$risposta = $HelloObj->sayHello(“richiesta del Client”)

print $risposta->result();

L’oggetto $HelloObj costituisce un rappresentante locale del-

l’oggetto remoto, istanza della classe remota Hello . Il meto-do sayHello viene eseguito sul server. Sul lato server, spes-so si ricorre a un Web Server che gestisca lo scambio deimessaggio usando il protocollo di trasporto HTTP. In questocaso il SOAP-Server si pone come estensione in modalitàCGI. Occorre istanziare un oggetto della classeSOAP::Transport::HTTP::CGI:

use SOAP::Transport::HTTP;

my $SoapServer = SOAP::Transport::HTTP::CGI->new();

$SoapServer -> dispatch_to(‘/home/httpd/soap_modules/’);

$SoapServer -> handle;

Questo programma deve essere fruibile, in modalità cgi dal

WebServer: il modo varia in funzione di quale WebServer sista usando (Apache, IIS…).

DebugQuando si dichiara di usare il modulo SOAP::Lite è possibi-le attivare la modalità di debug in questo modo:

use SOAP::Lite +debug;

Questo ha l’effetto di produrre sul file STDERR (standarderror: usalmente lo screen) i messaggi che documentano glieventi che accadono durante l’esecuzione del programma(per quanto concerne l’attività di SOAP::Lite). Non tutti glieventi sono rilevanti sia per il client che per il server.

La Tabella 1 mostra l’elenco dei principali eventi / ruoli /significati. È possibile far seguire al paramtero +debug lalista degli eventi che si desidera riportare, per esempio

use SOAP::Lite +debug => (“transport”, “objects”);

DEV > n. 127 marzo 2005 57 <<

WebServices in Perl

programmazione Perl



I t a l i a n

F r e e

Un progetto che mi ha colpito particolar-mente è Php-Residence, un sistema perla gestione di hotel direttamente via WEB- realizzato da Marco De Santis. Come sipuò facilmente intuire, Php-Residence èstato sviluppato in PHP e rilasciato sottolicenza GPL. I sorgenti possono essereprelevati liberamente dal sito ufficiale; èpossibile visionare una demo per farsiun’idea della bontà del prodotto diretta-

mente dal sito. Per provare l’applicazioneanche sul proprio PC si deve configurareun ambiente di test; quindi sono neces-sarie le installazioni di un WEB SERVER eun DBMS come “contenitore” dati (comeMySql). Php-Residence può essere utiliz-zato sia sotto Windows (in questo casosarà necessario installare un “PHPEngine” come ad esempio Easyphp) cheLinux. L’autore ha avuto il grande meritodi essersi preoccupato anche della loca-lizzazione in modo da poter rivolgersi aduna maggiore utenza possibile; si posso-no scegliere tra ben quattro lingue: italia-no, inglese, spagnolo, tedesco. Durante ilprimo utilizzo si devono impostare alcuniparametri (come il collegamento al DB,

l’indirizzo dove risiede il WEB SERVERecc.) dopodiché si passano ad impostarele componenti tipiche di un hotel come letariffe o le regole per la gestione delleprenotazioni. Il sistema su cui si poggiaPhp-Residence permette di verificare

sulle varie postazioni, in tempo reale, sead esempio le camere sono disponibilioppure indirizzare i clienti verso altri hoteldella stessa catena. Le varie pagine dis-pongono di un buon numero di funzionali-tà soprattutto legate alle prenotazioni; èstato realizzato un completo sistema diregolazione per l’assegnazione automati-ca delle camere in base al numero dicomponenti per prenotazione (sul sito

ufficiale è presente una pagina cheapprofondisce il concetto). E’ possibileanche inserire e modificare in qualsiasimomento i dati dei clienti (come la tarif fae la camera associate); la formattazionedei dati contenuti nelle tabelle rende piùcomoda la consultazione permettendo diavere dei riepiloghi annuali. Si possonomemorizzare inoltre dei promemoria, veri-ficare i costi di gestione per quanto riguar-da le entrate/uscite della propria attivitàcon tanto di storico e bilancio. Abbiamoavuto modo di contattare Marco che hatenuto a dire: “Php-residence è stato ilmio primo progetto in assoluto, iniziai alavorarci nel 2000.Avendo l’esigenza di gestire alcune case

vacanza assieme a dei familiari sparsi invarie località, qualcosa di accessibile viaweb era l’ideale e così colsi l’occasione diun tutorial sul php pubblicato da una rivi-sta. Le sue funzionalità sono dunquerivolte più alla gestione che alle prenota-

zioni online, anche se ora è possibile con-trollare la disponibilità via internet. Lacaratteristica principale che lo contraddi-stingue, anche rispetto a prodotti com-merciali, è l’assegnazione automaticadegli appartamenti alle prenotazioni”. Almomento della scrittura dell’articolo Php-Residence è penalizzato dallo stile graficoutilizzato, che se pur semplice, non rendegiustizia ad un buon prodotto (secondo il

mio modesto parere). In particolare i pul-santi presenti nelle varie schermate sonosistemati in maniera a dir poco confusio-naria rendendo difficoltoso l’utilizzo adutenti meno esperti. Marco, tra l’altrosempre molto disponibile, non ha esitatoa comunicarci che sta prendendo in con-siderazione una profonda modifica dell’in-terfaccia per far ottenere a Php-Residence la giusta consacrazione. Perulteriori informazioni rimando al link delsito ufficiale.

http://www.digitaldruid.net/php-residence/

Ricordiamo che per le proposte si puòfare riferimento all’indirizzo dell’autore,includendo una descrizione del progetto eil relativo URL dove poter effettuare ildownload. Le segnalazioni ritenute di inte-resse saranno prese in considerazionedalla redazione.

PHP-RESIDENCEQuesto mese andiamo ad esaminare un sistema web per la gestione alberghiera

a cura di Gianluca Masina > [email protected]

Inoltre è possibile associare agli eventi delle funzioni invo-

cate al loro accadere, in modalità “callback”. Per esempio se

aggiungiamo al precedente programma SOAPServer :

use SOAP::Lite +debug => [result => \&conta_accessi];

my $numeroAccessi = 0;

sub conta_accessi {

$numeroAccessi++;

print “Accesso numero $numeroAccessi” .”\n”;

}

Otteniamo il log che riporta il numero d’ordine di ognirichiesta del web service.

Bibliografia e riferimenti[1] Randy j.Ray,Pavel Kulchenko, “Programming Web

Services with Perl”, O’Reilly 2001

[2] James Snell, Doug Tidwell & Pavel Kulchenko, “Pro-

gramming Web Services with SOAP”, O’Reilly 2001

[3] http://www.soaplite.com, il sito ufficiale si SOAP::Lite.

È laureato in filosofia; autore di testi, docente e consulente,si occupa di sviluppo software dal 1977. Si occupa di OOP,DBMS, reti e ha sviluppato progetti in Java, Delphi, Python,Visual C++ e Visual Basic.

WebServices in Perl

58 DEV > n. 127 marzo 2005>>

programmazione Perl

Evento Client o Server? Significato

transport Client L’uso degli oggetti HTTP::Request e HTTP::Response durante

il trasporto dei messaggi SOAPdispatch Server Mostra il nome completo della chiamata del WS : modulo/metodoresult Server Da il risultato della chiamata al metodo

parameters Server Mostra i parametri della chiamata al metodo

headers Server Restituisce gli header del messaggio ricevuto

objects Client e Server Istanziazione e distruzione degli oggettifault Client e Server Eccezione nell’esecuzione

TABELLA 1

Fausto Zanasi

WebServices in Perl

Documents

Transcript of WebServices in Perl