x Attività di business che supportano l’acquisto e la vendita: le organizzazioni in generale

Tecnologie per il Commercio Elettronico recuperano e utilizzano informazioni per identificare e valutare clienti, fornitori, impiegati e
I PARTE :
Anche se elettronico, alla base c’è il commercio, inteso come “scambio (negoziato) di beni o servizi
di valore tra due partecipanti: Compratore e Venditore
Iniziato dalla preistoria, probabilmente come specializzazione di attività (coltivare, fare frecce,
cacciare, ecc) e realizzato come“baratto”.
Poi è arrivato il denaro, ma il meccanismo di base è rimasto lo stesso: un membro della società crea
(fabbrica) qualcosa che è di interesse (cioè ha un valore ) per un altro membro della società.
Il commercio (o “fare affari”) è quindi uno scambio (negoziato) di oggetti (o servizi) di valore tra
almeno due partecipanti, e include tutte le attività che ciascun partecipante compie per completare
la transazione.
Avendo stabilito che per avere “commercio” ci deve essere chi compra e chi vende, la stessa
transazione comporta azioni e punti di vista diversi da parte del compratore e del venditore:
x Il Compratore deve: identificare il bisogno, cercare il prodotto che possa soddisfare il
bisogno specifico, selezionare il fornitore, negoziare l’acquisto (include logistica delle
consegne, ispezione, testing e accettazione), effettuare il pagamento, usufruire dei servizi
post vendita (assistenza, manutenzione, garanzia).
x Il Venditore deve: condurre ricerche di mercato per identificare i bisogni dei clienti, creare
prodotti e/o servizi che possano soddisfare tali bisogni, occuparsi della vendita e provvedere
alla consegna del bene, ricevere il pagamento dal cliente, provvedere all’assistenza post-
vendita, alla manutenzione e fornire i servizi connessi alla garanzia.
Gli accordi sulla consegna e sul metodo di pagamento sono detti negoziato.
Quando il compratore è un’azienda, le prime quattro attività sono in genere raggruppate in un
dipartimento dedicato all’acquisizione di beni e servizi, che si chiama “ufficio acquisti”, o
“procurement”, o “supply management”, etc. Esempio delle Pubbliche Amministarzioni con il
“Capitolato di Appalto”. Per il venditore, il punto di vista è simmetrico. Notare che nella vita reale
spesso la parte più difficile e imprevedibile è proprio il primo passo (requirements e specifiche di
prodotto). Esempio IBM con i primi text editor che troppo complicati e non furono mai messi in
commercio. Spesso il venditore può vendere “a credito”, ad es.due aziende con ordine aperto e
fattura a fine mese.
business partners.
x Consumer to Consumer (C2C): Grazie alla diffusione delle tecnologie, chiunque può
facilmente vendere e comprare da chiunque altro. (Spesso è assimilata alla categoria B2C).
x Business to Government (B2G): Le organizzazioni vendono beni o servizi allo Stato o ad
enti Statali.
Da sempre, i “commercianti” hanno utilizzato l’evoluzione della tecnologia per migliorare (costi,
qualità, ecc) i processi di business e sono sempre stati attenti alle evoluzioni della tecnologia che
potessero essere utili. Nel mondo reale, spesso il processo avviene all’inverso: la spinta
all’evoluzione della tecnologia viene da motivi economici (business) o politici (guerre).. Ad
esempio le navi (prima a vela e poi a vapore) e i trasporti in genere, la stampa, la radio, la
televisione, ecc., ed infine i calcolatori e internet.
Spesso il predominio sui mezzi tecnologici ha fatto la potenza di una nazione (vedi Pisa, Venezia,
Inghilterra, USA oggi).
I calcolatori hanno migliorato enormemente i processi di business (contabilità, magazzino, paghe e
personale, ecc). La miniera d’oro della IBM negli anni ’60. Con l’arrivo delle comunicazioni tra
calcolatori si è sviluppata la trasmissione (ovviamente elettronica) di dati di business, anche con la
definizione di standard di comunicazione come EDI (Electronic Data Interchange) e EFT
(Electronic Funds Transfer), che ovviamente ha avuto un “boom” con l’avvento di Internet. Ad
esempio la IBM definisce il commercio elettronico come “la trasformazione dei processi di business
attraverso l’uso delle tecnologie di Internet”.
A fronte della metà degli anni 90, con il boom di Internet, sono stati fatti ingenti investimenti nel
commercio elettronico. A metà degli anni 2000 tale tendenza ha subito una battuta di arresto dovuta
al fallimento di molti di questi investimenti, e ad una maggior difficoltà a trovare finanziamenti per
questo settore. Si è dunque iniziato a valutare il rischio anche nel commercio elettronico ottenendo
conseguentemente un riassestamento del mercato. Dunque si è soliti dividere in una prima ondata
caratterizzata dall’entusiasmo e dal pressappochismo e in una seconda ondata caratterizzata da una
visione più accurata, sana e obiettiva del commercio elettronico, che è andata comunque a
confermare la validità di internet come valore aggiunto per il commercio e a sviluppare settori come
il B2C che prima di internet non aveva avuto mai modo di esprimersi pienamente.
Prima Ondata Seconda Ondata

Da secoli (dal 1300 a Firenze) nel commercio si tiene traccia delle “Transazioni”.
È chiaro che una transazione (scambio di valori) è in genere costituita da tante azioni e anche da
altre transazioni. Ad esempio la spedizione è una transazione composta da:
o contattare un trasportatore e (se necessario) negoziare accordi
o ispezionare le merci da spedire
o imballare le merci
o creare e stampare la bolla di spedizione
o caricare le merci
o pagare il trasportatore

L’insieme delle azioni e transazioni logicamente correlate che vengono eseguite in sequenza per
ottenere un certo scopo vengono genericamente indicate come “business processes”.

Possiamo classificare i vari tipi di commercio come segue:

x Business to Consumer (B2C): l’azienda vende prodotti o servizi al singolo consumatore.
x Business to Business (B2B): l’azienda vende prodotti o servizi ad un’altra azienda.

1 2
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico

Il commercio elettronico ha quindi due aspetti: quello del commercio (processi di business) e
quello elettronico (nell’accezione moderna, le tecnologie di Internet).
Essendo il commercio l’obbiettivo primario, l’utilizzo di Internet deve essere una soluzione di
business, e non l’uso “gratuito” di una tecnologia. In questa ottica, per capire come l’ e-commerce
(ecomm) possa essere utile, consideriamo allora vari aspetti di business che secondo la visione
degli economisti possono organizzarsi in una organizzazione aperta (ovvero il mercato), sia in una
organizzazione gerarchica (ovvero l’azienda).
Nella definizione degli economisti, il mercato è un modo di allocare risorse scarse (mercato è qui
inteso in senso astratto, e non necessariamente come luogo fisico).
Il commerciamte di maglie compra dai “tessitori” e vende ai negozi di maglie. Ci sono quindi due
“mercati”. Molti anni fa in campagna le donne arrotondavano le entrate con macchine da maglieria.
Al mercato si fanno le transazioni che hanno valore per tutti e due i partner, in base al “costo” che
ogni partner ha nello scambio. Ad es. per il commerciante di maglie, al mercato dei tessitori, i costi
sono:
x identificare i tessitori
x visitarli
x consegna delle maglie
x ispezione all’arrivo
Per il tessitore sono
x acquisto lana e strumenti
x rischio di invenduto (fattori di colori, moda, ecc.)
Ragionamenti simili si possono fare per mercati differenti da quello delle maglie.
Secondo una teoria degli economisti, se i costi di una transazione diventano troppo alti, qualcuno in
affari forma una “organizzazione piramidale”, da lui controllata, per eliminare il costo (spesso
variabile) di transazioni in un mercato aperto, si parla quindi di Integrazione Verticale. Con
l’organizzazione si introducono ovviamente i costi di gestione e controllo (mangement and
supervision), ma l’attuale struttura industriale, soprattutto per i beni di consumo, ha scelto questa
strada. Questo non è vero per certe commodities (beni solitamente non “customizzabili”), come il
grano, lo zucchero, il petrolio, ecc. Cosa c’entra tutto questo con Internet ?
Il web ha portato la possibilità di un modello “nuovo”, cioè a rete (Network). Le varie business unit
possono creare e disfare “alleanze strategiche”, che formano una sorta di “azienda virtuale”, a
seconda delle esigenze di mercato e del momento. Questi reti dipendono in larga misura dalla
condivisione di dati e informazioni, resa possibile dal web. I rapporti di stima e fiducia creati da
queste reti in genere durano nel tempo e permettono una maggiore flessibilità nell’organizzare “il
business”, che si può configurare e riconfigurare nel corso del tempo.
In questa ottica si capisce perché negli ultimi anni sono aumentati gli spin-off e l’outsourcing.
Gli economisti hanno trovato la legge del “ritorno decrescente”, cioè man mano che aumenta l’uso
di qualcosa, il ritorno (la soddisfazione) diminuisce (esempio stupido del quinto hamburger). Le reti
sono un interessante eccezione a questa regola e queste aziende virtuali beneficiano del cosiddetto
effetto rete. Esempio, migliore, del fax.
Qualunque sia l’organizzazione, è comunque sempre necessario identificare i “business processes”,
e a questo può servire la nozione di “value chain” (catena del valore).
Per la “creazione” di un prodotto o servizio finito sono necessari molti processi di business, i quali
devono cooperare tra loro per la realizzazione del prodotto. Una certa combinazione di prodotto,
distribuzione e clientela identifica una “business unit”. Per capire dove è meglio utilizzare ecomm è
spesso utile organizzare le attività di una business unit in “catene di valore” che, per molte attività
di produzione si possono facilmente identificare. In una business unit, in genere si distingue tra
attività primarie e attività di supporto.
Questa è una visione un pò più “scientifica” del venditore di auto.
Una azienda (corporation) è un isieme di una o più business unit. Ad es. IBM ha la BU dei PC, dei
server, dei mainframe, dei servizi di consulenza, di manutenzione (sorta di outsourcing interno).
3 4
V. Casarosa – Tecnologie per il Commercio Elettronico
Un insieme di aziende che operano nello stesso settore di beni e servizi costituiscono una
“Industry”. Ovvero, una industry è l’insieme delle business unit che producono prodotti/servizi
simili.
Sempre nella linea di ottimizzare la business unit e per allargare gli orizzonti (vedi modello
network) è spesso utile considerare anche la “Industry value chain”, cioè tutte le business units
coinvolte nella creazione del prodotto (bene o servizio), dalla nascita alla morte.
Nell’esempio, la segheria potrebbe entrare anche nel business
del taglio tronchi, oppure il dettagliante potrebbe entrare nel
business dei trasporti (acquisti e consegne). In ogni fase è
coinvolta una Bussines Unit, bisogna valutare l’opportunità di
migliorare l’efficienza di una business unit esaminando i
processi lungo la catena di valore del prodotto.
Vedremo meglio tra poco che questa nozione è importante per
determinare la “supply chain”, cioè tutte le business unit che
stanno a monte di una certa business unit, e che gli forniscono
beni e servizi.
Visto un pò meglio come i fattori economici possano
determinare l’organizzazione di un business, e possano
consgliare l’uso di tecnologie Internet, andiamo a vedere come
queste possono influenzare le strategie di business, che sono
essenzialmente la vendita e il marketing di un prodotto (bene
o servizio).
Cerchiamo quindi di capire come il commercio via Web possa
influenzare gli aspetti principali del processo di vendita e di
marketing.
Il primo aspetto è ovviamente quello di vedere come un sito
Web possa generare fatturato (revenue).
Dobbiamo però notare che non tutte le iniziative di ecomm hanno come obbiettivo di vendere via
web, ma possono essere fatte per azioni di marketing o di immagine (brand).
Ci sono poi gli aspetti di impatto sui canali esistenti (che possono usufruire positivamente della
vendita via web oppure entrarvi in conflitto) e sul contatto con i clienti.
Molto importante è l’usabilità, ovvero la facilità da parte dell’utente a reperire le informazioni di cui
necessita.
Notare infine che non tutto il vendibile si presta a essere venduto via Web.
Alla vendita via Web si prestano bene le commodities che non importa “toccare con mano” (libri,
dischi, piccola elettronica) oppure gli “intangibili” (software, viaggi, assicurazioni, azioni di borsa).
Alcuni esempi di come dal nulla si possa creare un impero economico sono tipici degli USA:
leggenda metropolitana di Amazon e Jeff Bezos (analista di borsa nel 1994), Steve Jobs e Wozniak,
“inventori” del PC oppure Bill Gates, inventore di Microsoft.
V. Casarosa – Tecnologie per il Commercio Elettronico
Qualunque cosa si venda, consideriamo diversi “revenue model”, cioè la combinazione di strategie
e tecniche usate da una azienda per generare fatturato via Web:
x La vendita per catalogo esiste da molti anni (fine 800 Sears, Montgomery Ward, aree rurali
USA), Postal Market in Italia.
L’uso del Web significa complementare (o sostituire) il catalogo stampato con informazioni
rese disponibili sul sito Web (vantaggi di costi e soprattutto di tempestività). Ci sono molti
esempi di questo modello, in varie tipologie di prodotti.
In generale, gli ordini possono essere fatti via Internet oppure in modo tradizionale (telefono,
fax, posta).
o Calcolatori e apparati elettronici (Dell- custom PC, Gateway; Sun, IBM, Best Buy, Circuit
City, etc)
o Libri, CD e video (molta concorrenza, tutte le maggiori case editrici, Amazon resta il
primo per i libri, CDNow per i CD)
o Abbigliamento (Gap, L.L. Bean, ecc.)
o Fiori, regali, oggettistica (Interflora, Godiva, ecc.)
o Generi di lusso (Versace, Evian, Tiffany, ecc). Uso pesante di grafica e animazione per
selezionare la clientela.
x Vendita delle informazioni contenute nel sito, in generale, abbonamenti, oppure “pay per
view/download”.
o Informazioni legali e mediche
o Copie digitali di giornali e riviste
o Informazioni di borsa
o Pubblicazioni scientifiche, come l’ACM Digital Library.
Diatriba in corso tra ricercatori e publisher (ACM, IEEE, Elsevier, Springer e Verlag, ecc.)
su IPR (Organismo che tutela la proprietà Intellettuale nel campo delle Ricerche
scientifiche) vs libera diffusione via rete.
x Vendita di spazi pubblicitari.
Segue il modello televisivo e dei giornali di annunci economici (distribuiti gratis). Dopo un
entusiasmo iniziale, ha avuto un lungo periodo di declino, per due problemi principali. Primo,
non è mai chiaro in base a quali parametri tariffare (numero visitatori, numero di click, tempo
speso sulla pagina, ecc.). Secondo, pochi siti hanno (avevano) un numero di visitatori
sufficienti. Inoltre, per un sito, sarebbe interessante raccogliere informazioni demografiche
(indirizzo, sesso, età, professione, ecc.) dei visitatori, per poter vendere spazi mirati a certi
segmenti, ma sempre meno visitatori lasciano informazioni (privacy, spamming, ecc.).
La pubblicità via web sta tornando in auge, e ne parleremo quando parleremo di Marketing.
R Portali, cioè punto di ingresso sul Web, spesso con search engine (Yahoo, Google)
R Quotidiani e giornali (rischio di diminuire le vendite delle copie di carta)
R Annunci economici, per categoria (offerte di lavoro, auto usate, ecc).
x Modelli misti (pubblicità e abbonamenti). Usato soprattutto da giornali on-line. Il visitatore paga
un abbonamento (fee) e accetta un certo livello di pubblicità (esattamente come nei giornali di
carta). Ci sono molti esempi di transizione da advertising a misto (ad es. Enciclopedia
Britannica).
x Servizi a pagamento.
Compenso proporzionale al numero delle transazioni oppure all’importo delle transazioni,
oppure erogati per abbonamento. Vari servizi si prestano molto bene a vendite via web. In quasi
tutti i casi il vantaggio sta nella diminuzione dei tempi e dei costi delle transazioni, dato che si
riduce il numero di “intermediari”.
R Agenzie di viaggi. (computers in uso da anni per prenotazioni aerei; trasporti e alberghi, i
quali pagano il servizio; ultimamente soprattutto il cliente lo paga ~ 35€)
R Biglietti per spettacoli (teatro, partite, concerti, mostre, cinema)
5 6
V. Casarosa – Tecnologie per il Commercio Elettronico
R Servizi di assicurazione e di borsa
R Servizi di banca on line (conto Arancio, Fineco)
R Vendita di automobili (tramite il concessionario più vicino, che paga il servizio, ma ha il
cliente e risparmia il venditore)
R Compra vendita di immobili (catalogo on line)
R Giochi elettronici (abbonamento)
R Film (abbonamento o pay per view; precursori i film porno (vedi Canale 5 in Francia nel
1984); problema della larghezza di banda al crescere degli utenti)
R Servizi professionali (medici, legali, commercialista) siamo ormai borderline
Dopo l’aspetto di revenue, si può considerare come conciliare la vendita via web con altri canali.
Per molte compagnie grandi la vendita via Web può provocare conflitti con (cannibalizzazione dei)
i canali di vendita tradizionali (distributori, negozianti). A meno che la compagnia decida di andare
al 100% via Web, è necessario trovare una cooperazione tra canali esistenti e la vendita via web
(bonus ai negozianti). Ad es. Levìs, dopo aver fatto due conti, ora fornisce solo informazioni sui
prodotti, e la lista di rivenditori. Un altro esempio è Eddie Bauer (abbigliamento casual) che
vendeva da catologo e da negozianti: con la vendita diretta via web aveva introdotto anche il fatto
che chi comprava via web poteva riportare l’acquisto al negozio più vicino, creando un malcontento
generale (costi maggiori per i negozianti, meno vendite per la business unit del catalogo). Con
opportuni incentivi è riuscita ad avere il supporto per le vendite via web da tutti, conciliando i tre
canali di vendita,
Altro aspetto da considerare è la relazione con i (potenziali) clienti. Nel mondo tradizionale
abbiamo i due estremi di comunicazione:
x Contatto personale, relazione uno a uno, molta interazione (venditore e cliente, stretta di
mano)
x Mass media, relazione uno a molti, nessuna interazione (anonima, TV, radio giornali)
Nella comunicazione mass media il compratore è passivo, e il venditore attivo.
Nel contatto personale, molto più costoso per il venditore, entrano in gioco anche fattori “personali”
e rapporti di stima e amicizia. Non necessariamente l’oggetto da vendere deve essere costoso, vedi
ad es. un libro o un CD.
La vendita via Web fornisce una flessibilità molto maggiore, e si posiziona nel mezzo. Si possono
avere interazioni con e tra più di un cliente, si possono stabilire relazioni molti a uno (da clienti a
azienda), uno a uno (scambio di mail con una persona di supporto), molti a molti (bollettini e liste di
discussione). Non è ancora chiaro come si confronta con gli altri due modi di comunicazione in
termini di costi e benefici, ma forse (purtroppo) finirà col soppiantare il contatto personale.
L’altro aspetto molto importante da considerare (una volta deciso di cominciare a “vendere” via
Web) sono gli aspetti di usabilità del sito. Ovviamente, come in un negozio, la cosa più importante
è di cercare di soddisfare il visitatore, sia per vendere che per invogliarlo a ritornare.
Purtroppo un’azienda interagisce con molte categorie di interlocutori (compratori, fornitori, il
proprio personale, persone in cerca di lavoro, ecc) e quindi i visitatori del sito possono avere molte
ragioni differenti:
R Avere informazioni su prodotti e servizi
R Acquistare
R Avere informazioni su garanzie e assistenza post vendita
R Avere informazioni generali sull’azienda
R Avere informazioni finanziarie sull’azienda (fatturato ecc.)
R Avere informazioni sull’organizzazione e sul management
R Avere informazioni sulle possibilità di lavoro in azienda
R Contattare persone o dipartimenti all’interno dell’azienda
Non è’ certamente facile fare un sito che soddisfi tutti, considerato anche che i visitatori hanno
livelli di esperienza e di aspettative molto differenti. Le cose stanno cambiando, ma un aspetto
V. Casarosa – Tecnologie per il Commercio Elettronico
tuttora poco curato è l’interattività di un sito web (messaggi ignorati o tempi di risposta lunghi,
disconnessione tra il Call Center e il sito web, ecc).
Altri fattori tecnologici da considerare sono:
x Livelli del browser (troppe immagini)
x Larghezza di banda della connessione (troppa animazione)
x Utilizzo da parte di disabili (vedi criteri e bollino del W3C)
Ci sono compagnie che vendono il servizio di valutare e testare un sito web, dal punto di vista
dell’usabilità (nuove opportunità create del web). Come sempre, è comunque impossibile fornire
una ricetta garantita che vada bene per tutti. Anche qui valgono le considerazioni già dette, che
spesso i fattori di successo sono imprevedibili.
Abbiamo finora visto alcuni degli aspetti principali per vendere via Web. Vediamo ora alcuni degli
aspetti principali per fare del marketing via Web.
L’obbiettivo della “vendita” è generare fatturato (revenue). L’obbiettivo del “marketing”è stabilire
una presenza sul mercato (visilità, brand, trust, ecc).
Una strategia di marketing è l’insieme delle azioni che un’azienda fa per promuovere i propri
prodotti, cioè far sapere che esistono, e che sono i migliori del mondo.
Nelle classi di marketing si insegnava che componenti essenziali del marketing sono le “quattro P”:
x Prodotto. La qualità è importante, ma anche il “brand”, cioè la percezione del prodotto che ha il
pubblico
x Prezzo. La teoria moderna è che un’azienda dovrebbe pensare più in termini di “valore” per il
cliente piuttosto che in termini di prezzo. Vedi le aste.
x Posto. Per il commercio tradizionale significa l’ubicazione del negozio, la presenza capillare,
ecc. Per il Web, capacità di consegna ovunque, oppure consegna via rete (musica, informazioni,
prenotazioni, ecc.)
x Promozione. Diffondere la conoscenza del prodotto. È l’aspetto più visibile e più importante del
marketing.
La “promozione” (descrizione) dei prodotti sul sito web può essere organizzata seguendo le
categorie dei prodotti (cucine, salotti, camere da letto, ecc), come in un grande magazzino. Questo
riflette il punto di vista del “produttore”, ma non è detto che vada sempre bene per il “compratore”.
In certi casi può essere più utile organizzare il sito per categorie di clienti (vestiti bambini,
abbigliamento giovani, taglie forti, ecc.). Questo permette di offrire con maggiore evidenza prodotti
e servizi che sono specifici per quella categoria di utenti. Ad esempio, per una università
(americana) pagine per studenti iscritti, per studenti in cerca di una università, per professori, per
potenziali donatori, ecc,
Questo approccio sta diventando sempre più comune nel B2B, in quanto per una azienda che vende
ad un’altra azienda diventa sempre più critico offrire beni e servizi “personalizzati” per il
compratore.
Una strategia di marketing viene generalmente indirizzata a un certo “segmento di mercato”, cioè a
una popolazione omogenea per un certo insieme di parametri. La segmentazione più diffusa è quella
demografica (età, sesso, istruzione, indirizzo, ecc.). Con il web diventa possibile indirizzarsi a
segmenti di mercato sempre più piccoli. Organizzando il sito web per categorie di clienti, è
possibile creare degli spazi virtuali per ciascuna categoria (vedi ad esempio il sito Dell). In certi casi
la segmentazione può arriavare addirittura a una persona sola.
La pubblicità (specie per radio e televisione) ha raggiunto livelli molto sofisticati, ad esempio
variando I contenuti a seconda delle fascie del giorno e dei contenuti dei programmi televisivi
(prodotti per bambini al mattino, insieme ai cartoni animati, ecc.)
Ci sono siti web che memorizzano e cercano di capire il comportamento del visitatore e di ricavarne
le sue preferenze, in modo da offire una esperienza “personalizzata”. Ad esempio (banale):
x Il curioso, che non ha le idee chiare, deve essere invogliato a restare sul sito (vendo materiale da
campeggio, e metto sul sito descrizioni e foto di campeggi).
x Il compratore indeciso, a cui devono essere fornite informazioni dettagliate sui prodotti, tabelle
di confronto con prodotti simili, ecc.
7 8
V. Casarosa – Tecnologie per il Commercio Elettronico
x Il compratore deciso, al quale si deve rendere l’acquisto il più semplice possibile (1-click buy)
Con il web sta diventando possibile una segmentazione “a livello individuale”. Con il web è infatti
possibile acquisire (e mantenere) informazioni dettagliate sullle abitudini di acquisto di un cliente.
Queste possibilità (portate dal web) prendono il nome di CRM, e permettono di cambiare le
interazioni tra venditore e compratore rispetto al mondo tradizionale, introducendo nuove possibilità
di creare valore nella “value chain”.
Differente approccio a vari aspetti di marketing tra CRM (Customer Relationship Management) e
modo tradizionale
Esempio di CDNow, che offre:
o storia degli ordini
o suggerimenti
o informazioni su artisti di interesse
o wish list
o regali fatti
o regali che si vorrebbero ricevere
o
Tutto quello detto sopra avviene solo su richiesta del cliente. Quando il cliente arriva sul sito, la
pagina che vede è personalizzata sul suo profilo.
CRM già tentato in passato, ma con SW rozzi, e quindi con effetti controproducenti (Amazon e
guida del Messico). È infatti facile esagerare nel tracciare e mantenere informazioni, introducendo
quindi problemi di privacy (esempio delle Digital Libraries o del Mobile computing).
Uno dei pilastri del marketing è la pubblicità. Il web ha portato la pubblicità con i banner, spazi
della pagina (generalmente animati) su cui si può cliccare per andare sul sito pubblicizzato. Una
misura della loro efficacia è data dal click-through, cioè la percentuale di visitatori che cliccano il
banner. Passata da 2% a 0.3.0.5%., perchè i visitatori sono sempre più seccati dai banner. Sistemi
alternativi (pop-up windows, pop behind windows, interstizial ad, ad moving on the page) sono
sempre più malvisti dai visitatori. Alcuni Internet browser danno la possibilità di bloccare le pop-up
windows.
Per piazzare un banner, una azienda ha vari metodi:
o Rete di scambio (io mostro il tuo e tu mostri il mio). Costo zero, ma chi piazza un banner
deve accettare di riceverne due, cioè quello dello scambio, più un altro venduto dal gestore
dello scambio, che così fa il suo profitto. Molto spesso nella rete di scambio ci sono anche
concorrenti diretti, e quindi il sistema funziona poco.
o Fai da te, cioè ricercare siti che sono di interesse per i miei prodotti (ma non concorrenti) e
pagare il sito che accetti il mio banner.
o Rivolgersi ad agenzie di pubblicità come per i giornali e la televisione. Le grandi agenzie
pubblicitarie offrono spazi su siti molto frequentati, e quindi molto costosi.
La maggiore difficoltà della pubblicità via Web resta quella di misurare l’impatto e di stabilire delle
tariffe. Una tabella indicativa, vecchia di qualche anno, è la seguente:
V. Casarosa – Tecnologie per il Commercio Elettronico
In questo ultimo periodo (uno o due anni) la pubblicità web ha ripreso fortissimo. Alla base due Il DNS, nato come servizio di utilità, viene spesso considerato come una directory. Sono nate molte
fattori: l’aumento di “internauti” e la diffusione della larga banda (Alice) che permette di navigare controversie, in cui il WIPO (World Intelectual Property Organization) ha generalmente preso le
molto più facilmente. Ma il grosso colpo lo ha dato Google con l’invenzione del “riferimento a parti del marchio.
pagamento”. Lo vediamo in un momento, quando parliamo dei motori di ricerca. Circa 40 milioni di nomi world wide. In USA circa 30 milioni. L’Italia ha da poco annunciato il
Un’altra possibiltà portata dal Web è di fare pubblicità con e-mail. Poco costosa, audience milione di nomi. ed è quarta in Europa. In testa alla classifica c'è la Germania, saldamente al
immensa: le ultime stime danno 50 milioni di host in EU, 350 milioni world-wide. Liste di milioni comando con più di 8,2 milioni di registrazioni di domini ".de". Seguono l'inglese ".uk" (circa 4
di indirizzi email disponibili a poco prezzo (200 EUR). milioni di indirizzi) e, al terzo posto, l'Olanda, con 1,3 milioni di suffissi ".nl" registrati, poi Spagna
Anche questa possibilità sta rapidamente degenerando a causa dello spam. Possibilità di opt-in o di poi Svezia. I nomi appetibili sono ormai tutti presi, e c’è un grosso mercato di vendita e affitto di
opt- out. In alcuni paesi perseguita per legge. Prodotti publicizzati sempre più scadenti. Usi di filtri nomi a dominio(Business.com 7.5 M$, Altavista 3.3 M$, Wine.com 3 M$, Autos.com 2,2 M$,
di mail. WallStreet.com 1 M$). Molti si comprano i nomi misspelled, in buona o mala fede (vedi Vigilio):
Un’altro fenomeno, sempre più rilevante, che è emerso con il web è quello dei motori di ricerca. Cybersquatting. Attualmente poco chiara per la legislazione anche la distinzione tra nomi e marchi
Programmi sempre più sofisticati (spider, crawler, robot) visitano “tutti” i siti Web (contatto (nuovo Codice della Proprietà industriale ha equiparato il nome a dominio al marchio).
sistematico con indirizzi IP e porta 80) cercando pagine che il motore giudica di interesse
(essenzialmente basato su parole chiave definite dal motore). Per le pagine interessanti si annotano Le considerazioni svolte finora si applicano principalmente al B2C.
l’URL e il contenuto della pagina viene indicizzato e messo in un data base del motore. Quando il Si è evitato finora di parlare di queste distinzioni, perchè il confine diventa sempre più sfumato.
navigatore fa una query, si estraggono dal DB quei siti che il motore giudica rilevanti, e vengono Alcuni fanno distinguo più sottili come C2C (vedi le aste) e B2G (le amministrazioni pubbliche
presentati (si suppone) in ordine di rilevanza, secondo criteri definiti dal motore. Per dare un’idea, stanno diventando uno dei più grossi attori di “business” on line).
Google oggi indicizza circa 8 miliardi di pagine e riceve circa 300 milioni di richieste al giorno. È comunque indubbio che nel contesto B2B vi sono aspetti che non si trovano nel B2C. Vediamo
Si stima che oggi un USA ci siano circa 150 milioni di internauti attivi, e che ogni mese i tre siti top gli aspetti principali dell’ecomm nel contesto B2B
(Google, Yahoo, MSN) ricevano circa 90 milioni di visitatori l’uno. Prendiamo ad esempio l’attività degli acquisti. Un’azienda, in generale, acquista materie prime,
È chiara l’importanza per la visibilità di un sito web di essere più in cima possibile alla lista della componenti, o servizi, mette il suo valore aggiunto a queste cose e vende (si spera con profitto) il
ripsosta di un motore. Pochi utenti vanno oltre la prima pagina. Esistono compagnie che offrono il “prodotto “finito” a qualcun altro. Tutto questo per dire che l’attività di purchasing, o procurement,
servizio di migliorare il posizionamento (uso di parole chiave all’interno delle pagine e uso di o “reparto acquisti” è una delle attività fondamentali di una azienda., che si presenta con molte più
metadati), ma è una lotta a “guardie e ladri”, dato che i motori di ricerca si difendono dalle furbate e attività rispetto all’acquisto di un privato.
in sostanza vogliono decidere loro chi va in testa, in base al reale contenuto e non in base ai
metadati.
Gli introiti da pubblicità sono infatti diventati una grossa voce nel bilancio dei motori di ricerca
(Google) o dei portali (Yahoo e MSN). Il metodo più semplice è di vendere spazi banner nalla home
page, e poi anche nelle pagine del risultato, dove i banner possono essere mirati in base alle query.
All’inzio alcuni motori “vendevano” il posizionamento semplicemente in base alle parole chiave
della ricerca, ma questo era poco soddisfacente per gli inserzionisti, in quanto non si riusciva a
misurare l’efficacia. Google ha capitalizzato su una idea nuova.
L’inserzionista paga perchè un link al suo sito appaia in prima posizione quando l’internauta scrive
certe parole chiave. Il pagamento avviene a posteriori, in base al numero di visite ricevute. La cifra
da pagare per ogni visita dipende dal costo delle parole chiave, che vengono vendute all’asta (da un
cent a 10 euro). Il costo dipende dal numero di “parole disponibili” per indicare l’attività
dell’inserzionista (poche parole, costo elevato), e dal valore dell’acquisto potenziale che potrebbe
fare il cliccatore. Come costo, i servizi finanziari sono in testa. Anche turismo e beni culturali vanno
forte, ma nel primo le parole sono tante (e quindi costo minore), e nel secondo i prodotti “in
vendita” sono molto a buon mercato (e quindi minor valore per l’inserzionista).
Un’altra possibilità offerta da Google, che già scandisce il contenuto di un sito, è di proporre ai siti
di interesse di accettare banner appropriati per il sito (in questo caso Google fa da mediatore).
Google e il sito che accetta il banner si dividono poi quanto paga l’inserzionista, sempre in base alle
visite ricevute.
Dopo il crollo delle “dot com”, diventate “dot gone”(.andate) (12000 aziende tra il 1998 e il 2001,
con più di 100 miliardi di venture capital), il mercato comincia a credere di nuovo nella
“NetEconomy”
o Google capitalizzata a 60 milioni di dollari Gli acquisti di una azienda avvengono tramite la “supply chain”, e sono uno degli aspetti più
o Yahoo a 44 milioni importanti del business. La Supply Chain è la parte di una Industry Value Chain che si trova a
o Amazon a 14 milioni monte di una Business Unit.
Il pericolo viene da Microsoft (capitalizzata a circa 600 Milioni $), cha sta mettendo un motore di Le specifiche del prodotto da acquistare (capitolato) sono spesso molto dettagliate (sia nella PA che
ricerca dentro Windows, e che quindi cerca di fare con Google e Yahoo come ha fatto con nell’industria), dato che servono come base per gare di appalto. Spesso ci vuole uno staff esperto
Netscape. per valutare le risposte a RFQ (Request For Quotation).
Quasi tutte le aziende fanno distinzione tra materiali diretti e materiali indiretti (parti di ricambio,
L’ultimo aspetto è quello del nome a dominio, che può diventare una specie di logo dell’azienda. attrezzature da ufficio, materiali di consumo, ecc.). Per i materiali diretti i due modelli di acquisto
9 10
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
sono “contract purchasing”, cioè un contratto aperto, in cui si specificano di solito prezzi e quantità
minime, oppure “spot purchasing” per procurarsi materiali in emergenza.
Molto spesso le attività di acquisto dei materiali indiretti sono in un reparto acquisti diverso da
quello di acquisto dei materiali diretti (inclusi ad es. computer e viaggi). Alcune compagnie si
specializzano nella fornitura di questi materiali indiretti, indicati spesso come “MRO supplies”
(Maintenance, Repair and Operating). Ad esempio, uno dei più grandi al mondo (W.W. Grainger)
offre oltre 220.000 articoli dal suo sito web. Qualche analista ha stimato che un acquisto via web
costi fino a 10 volte meno di un acquisto per telefono.
Un altro aspetto delle aziende sono le attività logistiche, cioè la capacità di avere le cose giuste,
nella quantità giusta, nel posto giusto, al tempo giusto. Ci sono due aspetti. Da un lato il flusso
interno di movimenti delle materie prime ordinate (dall’arrivo alla fabbrica, poi al magazzino, poi
alla produzione e poi al magazzino di nuovo per la spedizione). Dall’altro la spedizione di merci
agli acquirenti, spesso fatta con compagnie esterne (outsourcing tipo DHL). Il primo aspetto viene
gestito dai sistemi aziendali, che ovviamente devono essere connessi anche alle attività di acquisto e
vendita per gestire correttamente il magazzino. Per il secondo aspetto. oltre ai sistemi interni della
compagnia di trasporto, bisogna interagire con i clienti per dare notizie sullo stato della spedizione.
Ad esempio, una grossa compagnia americana (J.B. Hunt, con oltre 70.000 camion e containers) ha
aperto un sito web per i clienti, in modo che possano seguire la spedizione da soli. Ha stimato che
con questo sito risparmia più di 600.000 dollari l’anno (tra spese di personale e spedizioni perse).
Ovviamente oltre al sito web ci deve essere una struttura per acquisire i dati in tempo reale (o
quasi). Esempi di DHL e FedEx, con siti web p
er il cliente. Qualcuno ha installato i GPS sui camion (la risoluzione dei GPS sembra sia scesa a
qualche centimetro.
Ci son infine le attività di supporto (al processo di produzione), che sono sostanzialmente:
x Amministrazione e contabilità (bilancio, pianificazione, cash flow, ecc)
x Gestione del personale (assunzioni, addestramento, valutazione, ecc)
x Ricerca e sviluppo (dipende molto dalla grandezza dell’azienda)
Anche in queste attività ci sono spazi per ecomm. Ad esempio, una compagnia sparsa su tutti gli
Stati Uniti cresceva di 100 nuovi assunti al mese, con la necessità di dare a tutti un seminario di
mezza giornata sugli schemi e i benefici di pensione e assistenza medica (con scelte da fare da parte
della persona). Ha comprato i servizi di una azienda (Online Benefits)specializzata nel duplicare
questo tipo di seminari su un sito web, con tutte le opportune misure di sicurezza, adattato alle
esigenze dell’azienda compratrice.
Notare che se si tiene conto del turnover, 100 assunzioni al mese non è poi una gran cosa. Ad
esempio IBM Italia anni ’80 aveva 15.000 dipendenti, e con un turnover (fisiologico) del 3 o 4
percento, si hanno 500-700 assunzioni l’anno. Si può concludere che Internet sta favorendo il
Modello a Network (invece che il modello di concorrenza), che spesso diventa “out-sourcing”.
Per quasi tutte le attività viste, lo scambio di informazioni per via elettronica è ormai in uso da
molti anni (prima di Internet), con il nome generico di EDI (Electronic Data Interchange). Le
aziende hanno rapidamente capito che si poteva risparmiare da un lato la stampa e la spedizione di
documenti cartacei, e dall’altro l’immissione dei dati ricevuti su carta nei propri sistemi informativi.
Abbiamo già visto che un semplice acquisto comporta molte azioni. Vediamo ora lo scambio di
informazioni necessario.
11
V. Casarosa – Tecnologie per il Commercio Elettronico
Poichè molte delle informazioni scambiate sono sostanzialmente le stesse per ogni azienda, a partire
dalla fine degli anni ’70 l’ANSI (American National Standard Institute), tramite il comitato ASC
X12 (Accredited Standards Committee) ha sviluppato una serie di specifiche sul formato dei dati
che vengono scambiati in varie centinaia di transazioni tra aziende. Ad esempio, inviando un
messaggio EDI con codice 850, significa che è un ordine di acquisto, e il programma ricevente può
passare direttamente i dati ricevuti (opportunamente interpretati in base al codice 850) ai rispettivi
programmi aziendali. Lo standard X12 era (ed è) uno standard essenzialmente americano. Verso la
fine degli anni ’80 sforzo congiunto con Europa per definire uno standard “mondiale” chiamato
EDIFACT (EDI For Administration, Commerce and Transport).
Con riferimento alla figura di sopra, basta pensare che c’è un calcolatore che “parla” EDI al posto
della mail room.
Grosse aziende connesse direttamente tra loro per EDI. Piccole aziende connesse tramite VAN
(valore aggiunto di log e altri servizi). L’arrivo di Internet ha spostato il traffico EDI dalle VAN
(soluzione alternativa a una linea dedicata con ciascuno dei prori partner) a Internet, con l’utilizzo
dei browser e delle forms, ma ancora con necessità di SW EDI. Con l’arrivo in rete di aziende molto
piccole (non attrezzate per EDI) si sono creati servizi (a pagamento) per convertire dati da HTML a
EDI e viceversa.
Nel 1997 le VAN coprivano il 95% del traffico EDI; si stima che nel 2007 sarà meno del 5%.
La migrazione da EDI a Internet è molto meno vera per transazioni finanziarie (soprattutto tra
banche), essenzialmente per motivi di affidabilità (interessi persi a cuasa di ritardi della rete) e
sicurezza.
Un aspetto sempre più importante per migliorare l’efficienza di business attraverso tecnologie
Internet è la gestione della “Supply Chain”. I concetti alla base di questa evoluzione sono:
- “mercato” con modello a rete
- rapporti di fiducia tra fornitore e acquirente
- condivisione delle informazioni.
SCM (Supply Chain Management) aiuta un azienda a pianificare e coordinare le operazioni di tutti i
partner di una Supply Chain. La supply chain di un certo prodotto è l’insieme di tutte le aziende e le
operazioni che forniscono parti o servizi per ottenere il prodotto finito. Vedi FIAT, e tutti queli che
forniscono i pezzi per fare una macchina. Mentre prima era un rapporto uno a uno tra fornitore
acquirente, con il Web siamo passati a una visione globale di Network di aziende. Ci sono vari casi
molto positivi, portati a esempio.
12
V. Casarosa – Tecnologie per il Commercio Elettronico
- Dell, che è riuscita a mantenere livelli di inventario minimi, pur fabbricando PC “su misura”,
dividendo con i propri fornitori le informazioni sugli ordini e sull’andamento delle vendite.
- Boeing, in cui un aeroplano ha circa 1 milione di parti, e tutti sono costruiti su misura. Nel 1997,
errori nella pianificazione della produzione costrinsero Boeing a arrestare la produzione per diverse
settimane, con un costo di circa 1500 miliardi (di dollari). Riorganizzando completamente la supply
chain, è riuscita a diminuire i tempi di consegna di un aereo da 36 mesi a 10 12 mesi.
- Harley Davidson, che è riuscita a restare competitiva con i giapponesi (dopo una crisi negli anni
’80, dovuta a un peggioramento della qualità) essenzialmente riorganizzando la supply chain e
passando da 4000 fornitori a circa 350. Massiccio uso di EDI (con portale web per i piccoli) e uso di
bar code e (adesso) RFID per migilorare la logistica.
RFID (Radio Frequency Identification Devices) in uso da tempo (vedi Telepass). Quelli di ultima
generazione non hanno bisogno di batterie, ma prendono energia dal segnale in arrivo per inviare la
risposta.

Un ultimo aspetto del B2B è la creazione di “mercati elettronici” (electronic marketplace). L’idea
era di creare dei siti Web come punti di contatto, di scambio di informazioni e di commercio per
aziende dello stesso segmento di industria, più o meno come già esistevano essenzialmente tramite
carta stampata. Quello che sembrava il modello più promettente era l’”independent exchange”, cioè
un sito non controllato da nessuna azienda (del settore di industria), chiamato anche “portale
verticale”. A metà del 2000 c’erano più di 2200 siti di questo tipo, in una gran varietà di tipi di
industria (ad esempio, circa 200 siti nell’industria dei metalli). Nel 2002 ne erano rimasti in
operazione meno di 100. Le ragioni principali sono la fine del venture capital (.com e .gone) e la
reazione dei maggiori attori in ogni settore di industria.
Il concetto di “negozio privato” su un sito web (vedi Dell) significa che di solito c’è un accordo
commerciale per cui il compratore si impegna (su un numero ridotto di articoli) a comprarne un
minimo garantito in cambio di (forti) sconti.
Aste e Comunità Virtuali vanno menzionate solo per dire che sono molto diffuse, ma sono la zona
grigia a cavallo tra B2B, B2C e C2C. Concorrenza di Amazon a e-Bay (market leader) tramite
garanzia di rimborso (vedi anche escrow) e accordi con Sotheby’s. Si tralasciano completamente
anche gli aspetti fiscali e legali delle vendite nazionali e internazionali.
Diamo alcuni cenni su HW e SW per i siti web di ecomm, dal punto di vista dell’amministratore.
L’HW di un server Web è un PC più affidabile, robusto e performante di un normale PC, e quindi
anche abbastanza più costoso. Un buon PC (Processore 2,5 GHz, RAM 1024 MB, HD 350 GB)
oggi va intorno a 600-1000 EUR, mentre i web server possono andare da 5000 a 500.000 EUR
(IBM, Sun, HP). L’avvento di Linux sta cambiando le cose. I server sono in genere montati su rack,
hanno dischi multipli (velocità e affidabilità).
A seconda del carico da supportare, il server può essere su un solo PC, oppure può essere distribuito
su tanti PC (server farms, anche con qualche centinaio di PC). Se l’HW è molto potente, su un PC si
possono avere più siti web (server virtuali), che hanno tutti lo stesso indirizzo IP, che corrisponde a
tanti nomi a dominio diversi. Nel caso di server farms si possono avere due strategie: pochi server
molto potenti (meno affidabilità, minor costo di manutenzione) oppure tanti server piccoli (minor
costo, più affidabilità, più difficile il load balancing). La seconda soluzione sembra la tendenza
attuale, esempio di eBay, che dopo problemi e un giorno di fermo completo, con qualche milione di
dollari di perdite, è andare su “molti piccoli”.
13
V. Casarosa – Tecnologie per il Commercio Elettronico
Server Farm: configurazione server complesso.
Dato che installare e mantenere un buon Web server è costoso e richiede skill, molti ISP (che danno
la connettività a Internet) offrono servizi di Web Hosting. Ovviamente il servizio è molto
interessante per piccole aziende, che non hanno le competenze informatiche per allestire e gestire
un sito Web. Interessante anche per aziende lontane dai maggiori backbone di Internet, se il sito
prevede un gran volume di traffico.
x Solo room space (il vantaggio sta nella vicinanza dei router)
x Server shared (virtual server)
x Server dedicato
SW per web servers:
x Apache (a patchy server, Linux, Windows, BSD-UNIX,SCO-UNIX, HP-UNIX, Solaris, ecc. )
x Microsoft Internet Information Server (IIS).
Utilities per web servers:
x Ping (Packet Internet Groper, dà il tempo e il numero di hops)
x Trace Route (più sofisticato di ping, dà indirizzo IP e tempo per raggiungere ogni router)
x e-Mail (già visto lo spam, ci sono anche i virus, che arrivano principalmente da buchi nel SysOp
e middleware, oppure dalla posta)
x Telnet e FTP
x Indexing (contenuto del sito) e Search (sito o intera rete)
x Log (data e ora, chi, quanto tempo, pagine visitate, downloads, ecc. Può crescere molto
rapidamente. Programmi di “data analysis” per analizzare il log)
x Link checkers (link non validi, intra sito e extra sito, file orfani)
x Content Management Systems (forniscono template per siti web, in cui in teoria l’utente deve
solo mettere il contenuto, vedi ad es. Mambo).
x Performance evaluation (throughput, response time. Ci sono siti che offrono benchmarking per
siti web, confronti, test su misura)
x Bilanciamento del carico (tramite switch più o meno intelligenti, costo fino a 50.000 $)
x Remote server administration (importante la sicurezza)
14
V. Casarosa – Tecnologie per il Commercio Elettronico

La sofisticazione (e il costo ) di un sito di ecomm può variare moltissimo. I due fattori principali da
considerare sono una stima del traffico sul sito e delle vendite, e quanto una azienda vuole spendere.
Un’altra decisione importante è se installare tutto in casa, oppure servirsi di un ISP, a vari livelli di
servizio. Il fattore determinante qui è il costo delle persone con skill “ecomm”.
Qualunque sia la soluzione, un SW di ecomm deve comunque avere tre funzioni di base:
x Il display del catalogo. Spesso organizzato in reparti come un negozio fisico. Il vantaggio del
catalogo elettronico sta nel fatto che uno stesso articolo può stare in posti diversi (scarpe da
tennis sotto scarpe e anche sotto sport). Il catalogo può essere statico (semplici pagine HTML)
oppure dinamico (collegato al DB aziendale). La forniture di un template di catalogo può far
parte dei servizi offerti da un ISP.
x Il carrello elettronico Dopo i primi inizi con form secondo il modello degli ordini via posta
(scomodi), tutti i siti utilizzano il carrello elettronico. Con un solo clic si mette un articolo nel
carrello, con un solo clic si leva, con un solo clic si va alla cassa. Molte compagnie vendono SW
di carrello elettronico, con vari livelli di sofisticazione. Per ovviare alla natura stateless di
HTTP, si usano cookies, oppure ID appesi alla URL del browser, oppure registrazione al sito
con login e password, che offre maggiore sicurezza (ma è anche un buon metodo per
discriminare i curiosi e acquisire informazioni demografiche).
x La transazione finanziaria. A parte il metodo di pagamento effettivo, di cui parleremo in
seguito, la chiusura del conto può essere la parte più complicata dell’acquisto,a causa delle
promozioni speciali (paghi uno prendi due, 40% di sconto fino alla fine del mese, acquisti anche
il ritorno e paghi il 50%, acquisti business class e la moglie vola gratis, ecc).
Dopo alcune storie dell’orrore, quasi tutti i siti di e-comm fanno il redirect della transazione con
carta di credito su una banca, e nessuno memorizza più queste informazioni nel carrello o sul
sito del merchant.
Per un semplice negozio elettronico queste tre funzioni possono bastare. Per aziende più grandi c’è
ovviamente la necessità di integrare il sito Web con il resto delle applicazioni informatiche
dell’azienda e con i partner di business. Non facile, dato il mescolone di programmi. spesso assai
vecchi.
Si sta diffondendo sempre più una categoria di ISP che offrono pacchetti completi di hosting più
SW per ecomm (chiamati CSP, Commerce Service Provider), e che si rivolgono a clienti piccolo-
medi, con una vasta categoria di prezzi. Uno dei più grandi (ValueWeb) ospita circa 150.000 siti in
130 paesi.
Nella fascia bassa (perfino 20$ il mese) ci sono CSP che offrono template molto semplici, da
riempire con il catalogo del negozio, per cui si può mettere su un sito in 2 ore. Spesso non offrono
neppure il carrello e la gestione finanziaria (se uno vende pochi articoli al giorno può andare bene).
In genere gli ordini vengono raccolti dall’host e poi inviati via email al merchant, che deve gestirli.
Talvolta viene dato anche spazio gratis in cambio di banner nella home page del negozio (fee di
advertising intascata dall’host).
A un livello più alto ci sono i CSP tipo Mall (Centro Commerciale), che ospitano tanti negozi
differenti e li raggruppano per categorie, come in un centro commerciale. Vedi Yahoo.
Speso si perde il connotato di “negozio elettronico”, e si ha la vista di un enorme catalogo, che
include anche servizi di comparazione.
Tre funzioni necessarie per siti ecomm di livello sofisticato (aziende) sono Integrazione con EIS,
CRM e SCM.
L’integrazione con EIS (Enterprise Information System) può essere molto costosa, ma è necessaria
per tutte quelle aziende che hanno già un sistenma informativo (cioè tutte).
CRM (Customer Relationship Management) cerca di capire le necessità di un cliente, e poi
customizza i beni o servizi ai suoi bisogni. Per automatizzare (in una certa misura) questa funzione,
è necessario un software abbastanza sofisticato che cerca di raccogliere dati da tutte le transazioni
fatte da un certo cliente (Marketing, Comportamento, Vendite, Assistenza), e cerca poi di trarne
conclusioni. Esistono pacchetti di software CRM con costi da 200mila a 500mila dollari.
SCM (Supply Chain Management) aiuta un azienda a pianificare e coordinare le operazioni di tutti i
partner di una Supply Chain. La supply chain di un certo prodotto è l’insieme di tutte le aziende e le
operazioni che forniscono parti o servizi per ottenere il prodotto finito. Vedi FIAT, e tutti queli che
15
V. Casarosa – Tecnologie per il Commercio Elettronico
forniscono i pezzi per fare una macchina. Mentre prima era un rapporto uno a uno tra fornitore
acquirente, con il Web siamo passati a una visione globale di Network di aziende. Ci sono due casi
molto positivi,portati a esempio. Dell, che è riuscita a mantenere livelli di inventario minimi, pur
fabbricando PC “su misura”, dividendo con i propri fornitori le informazioni sugli ordini e
sull’andamento delle vendite. Boeing, in cui un aeroplano ha circa 1 milione di parti, e tutti sono
costruiti su misura. Nel 1997, errori nella pianificazione della produzione costrinsero Boeing a
arrestare la produzione per diverse settimane, con un costo di circa 1500 miliardi (di dollari).
Riorganizzando completamente la supply chain, è riuscita a diminuire i tempi di consegna di un
aereo da 36 mesi a 10 12 mesi. Il costo di un pacchetto SCM varia molta a seconda di quanti partner
e locazioni ci sono nel supply chain, e si va da 1milione a 10milioni di dollari.
Costi per un sito Web piccolo:
Per siti web di tipo small (e pochi articoli da vendere) i costi annuali possono essere i seguenti:
Nome a dominio 100
Spese iniziali 200
Affitto mensile 1200
Macchina fotog. digitale 400
Software 100
Design iniziale 500
Spese iniz carta di credito 200
Commissione carta credito 3%
Totale 2700 + 3% vendite
Costi per un sito Web grande:
A titolo di confronto, vediamo le spese per self hostingdi un sito piccolo:
Hardware 5000-10000
Connessione a Internet 8000-12000
locali 5000
Personale 15000-50000
Per siti di aziende grandi o molto grandi i costi raggiungo rapidamente i milioni di dollari come
start up, e poi circa il 50% per costi operativi. La maggior parte di questi costi sono per integrare il
sito con i sistemi informativi dell’azienda. A questo livello abbiamo come fornitori principali IBM
(WebSphere), Microsoft (Commerce Server), Oracle (E-business suite).
Iniziamo a vedere le “tecnologie”. Sostanzialmente ecomm è una “Web Application” distribuita, e
quindi le “tecnologie di base” sono di fatto quelle delle applicazioni distribuite, cioè applicazioni in
cui vari pezzetti di SW girano su macchine diverse, comunicando tra loro per svolgere i compiti
dell’applicazione. Una definizione migliore (più astratta) può essere quella che un “sistema
distribuito” è un insieme di calcolatori indipendenti, che appaiono all’utente come un unico
sistema coerente.
Notare che se i processori su cui vengono eseguiti i vari pezzetti dell’applicazione sono nella stessa
macchina fisica, di solito si parla di calcolo parallelo o programmazione concorrente, e non di
applicazioni distribuite (la differenza sostanziale sta nel fatto che in caso ci può essere memoria
condivisa, nell’altro no).
Quando si parla di distribuito, l’aspetto (problema) principale da considerare è il problema della
interoperabilità (piattaforme HW e SW diverse, diversi fornitori di SW) che, (in teoria) si risolve
con la definizione di protocolli accettati da tutti. Il punto critico dove realizzare l’interoperabilità è a
livello della comunicazione, cioè lo scambio dei messaggi.
Evoluzione delle reti negli anni ’75-85 (OSI versus IBM-SNA e poi TCP), evoluzione del
distribuito negli anni 85-95 (DCE, oggetti, Java, RMI).
16
V. Casarosa – Tecnologie per il Commercio Elettronico
In genere l’interoperabilità viene ottenuta tramite Middleware, come in Figura. Sotto comunica con
ciascun sistema operativo, sopra presenta una vista omogenea a tutti i pezzetti dell’applicazione
(calcolatore virtuale).
L’altro aspetto importante del distribuito è il modello di distribuzione, cioè con quale criterio si
divide l’applicazione in vari pezzetti, e quale è il ruolo (le funzioni) svolte da ciascun pezzetto. I
due modelli che vanno per la maggiore sono il client-server e il peer-to-peer. Nel primo, si
distinguono due ruoli: (i) il client, che quando ha bisogno di qualche funzione non disponibile
localmente chiama (invia un messaggio a) e (ii) il server, che sta in attesa di chiamate (messaggi in
arrivo) per eseguire le sue funzioni, ed invia (se necessario) un messaggio di risposta al client. Non
è previsto che un cliente parli ad un altro client.
Nel peer-to-peer tutti i pezzetti sono in attesa di messaggi e possono mandare risposte (messaggi)
anche a chi non è il mittente del messaggio ricevuto. Il P2P è entrato nella visione di massa con
Napster, sistema P2P nato per condividere file, e poi ustao per lo scambio di musica MP3, finchè
non l’hanno chiuso. Non era un vero P2P, perchè aveva comunques dei server con il directory.
In ogni caso, il modello client/server (storicamente il primo, quando sono arrivate le LAN) è
concettualmente il più semplice e di fatto il più diffuso.
In una applicazione si possono distinguere (grosso modo) tre aspetti: interfaccia utente (view o
presentation), elaborazione (business logic), dati .
Un altro modo di vedere la suddivisione di funzioni è il modello MVC (Model, View, Control),
dove il model è la logica di business più i dati, il view è l’interfaccia utente e il control controlla il
passaggio delle informazioni tra i due. In una architettura client/server queste tre “funzionalità” si
possono dividere in vari livelli. Il più semplice è a due livelli (two tier).
La Figura mostra come col modello client server si possano avere diversi modi di distribuire, a
due livelli. Si passa del “thin client” al “thick client”.
17
V. Casarosa – Tecnologie per il Commercio Elettronico
Ovviamente poi il lato server può essere distribuito a sua volta, arrivando a una architettura a più
livelli (la terminologia è quella di Sun Java, ma i concetti sono del tutto generali). Si mette in
evidenza la possibilità di avere in client generico (browser) che richiede quindi un server generico
(web server) che intefacci con la business logic, oppure si può avere un client specifico che
interagisce direttamente con la business logic.
La chiamata a “sub-routine” o a “funzione” è nata con la programmazione, anche a livello
linguaggio macchina, per consentire flessibilità al ciclo fetch, update-instruction-counter, execute.
Le applicazioni distribuite hanno cominciato a svilupparsi con l’arrivo delle LAN.
L’idea geniale, che ha fatto da capostipite, è relativamente recente (1984) dove per la prima volta si
parla di Remote Procedure call (RPC). Come tutte le idee geniali, è estremamente semplice (perchè
non ci abbiamo pensato prima ?). Si tratta di estendere il noto e collaudato concetto di chiamata a
procedura in modo che la procedura chiamata sia (venga) eseguita su un altro calcolatore, diverso
da quello dove viene eseguito il chiamante.
Uno degli aspetti principali delle applicazioni distribuite è quello della comunicazione tra i vari
pezzetti del SW, cioè come si scambiano tra loro le informazioni (messaggi) i vari pezzetti.
Ovviamente ogni pezzetto può fare ricorso a delle procedure del Sistema Operativo come send e
receive, ma questo va un pò contro l’idea di cercare di nascondere il più possibile l’aspetto di
“distribuzione”. RPC (se bene implementato) va evidentemente in questa direzione, cecando di far
credere al chiamante che la procedura remota è locale, e viceversa.
Dietro l’apparente semplicità, ci sono due grossi problemi da risolvere, rispetto al caso della
chiamata “normale”, soprattutto se vogliamo dare sia al chiamante (il client) che al chiamato (il
server) l’illusione che la chiamata sia locale. Il primo è come passare i parametri (in e out), dato che
le due procedure possono girare su piattaforme completamente diverse. Il secondo è cosa fare se la
RPC non va a buon fine, il che può avvenire per tanti motivi (ad es. una delle due macchine va in
abend, oppure se la rete va giù, ecc.). Si può supporre che il sistema operativo e il middleware si
prendano cura di questi due aspetti, per quanto possibile.
Per i parametri, “è ovvio” che si possono passare solo per valore, dato che le due procedure girano
in due spazi di indirizzo diversi. In effetti si possono passare anche i pointer (indirizzi), ma quello
che avviene è che si passano (per valore) i dati puntati nel calcolatore A, si copiano in qualche parte
della memoria di B e si passa alla procedura remota un puntatore a questi dati, nello spazio di
indirizzi di B. Se le due piattaforme sono diverse, ci sono anche problemi di rappresentazione
interna. Vedi il classico problema di “little endian” e “big endian” (dai Viaggi di Gulliver, rissa su
quale parte si deve rompere un uovo).
18
V. Casarosa – Tecnologie per il Commercio Elettronico
 affidabile. Tutto questo non avviene per magia, ma come in Fig. Gli stub si preoccupano
essenzialmente di converitre i dati in ingresso e uscita in un “byte stream” di formato “neutro”
(rispetto alle possibili piattaforme HW e SW), chiamato Network Data Representation (NDR). Il
runtime si occupa essenzialmente del binding, dei time-out, possibili re-try in base alla semantica di
esecuzione. Il trasporto è quello che passa il convento.

(a) Original message on system A (little endian)

(b) Received message on system B (big endian)
(c) Message after being inverted (number is OK, string is not)
(The little numbers in boxes indicate the address of each byte)

La soluzione “naive” di invertire i byte al ricevente mette a posto le cose per i numeri, ma non per
le stringhe. Si vede quindi che occorre inviare al ricevente anche informazioni sul “tipo” dei dati, in
modo che possano essere memorizzati nel modo giusto. Vediamo tra poco come il middleware si
prenda cura di questo aspetto.

Per le RPC che non vanno a buon fine, possiamo categorizzare i motivi nel modo seguente:
1. Il server non si trova o non risponde Alla base di un RPC trasparente c’è la possibiltà di definre le funzioni offerte dal server (cioè dalla
2. Il messaggio dal client al server viene “perso nella rete” procedura remota) in termini indipendenti dalla sua implemetazione, cioè tramite la definizione di
3. Il server va in crash dopo aver ricevuto il messaggio, ma prima di eseguire la richiesta una “interfaccia” che, oltre al nome della funzione, definisce i parametri in e out.
4. Il server va in crash dopo aver ricevuto il messaggio, ma dopo aver eseguito la richiesta Il supporto fornito da DCE, oltre quello runtime, è quello di creare gli stub (client e server) a partire
5. Il messaggio di risposta dal server al client viene “perso nella rete” da una descrizione “formale” dell’interfaccia supportata dal server, cioè la firma della procedura
6. Il client va in crash dopo aver inviato il messaggio remota, cioè il nome della procedura e i parametri (in C è il prototipo di funzione). Questa
Il problema è: cosa deve fare dal lato client il SysOp+Middleware, a seconda del motivo di interfaccia è descritta in Interface Definition Language (IDL), e viene “compilata”, dando in uscita
fallimento ? il sorgente degli stub (in un linguaggio supportato dalla piattaforma su cui dovranno girare, insieme
Il caso 1 è “banale”, la RPC non comincia neppure e il SysOp comunica al client di provare più al client o al server).
tardi (solleva un eccezione).
I casi 2, 3, 4 e 5 presentano la difficoltà, dal lato client, di essere difficilmente distinguibili uno
dall’altro. Ogni volta che il client fa una chiamata, viene fatto partire un timer. Quando il timer va
in time-out, cosa deve fare il SysOp (possibilmente insieme al client) ? Ci sono sostanzialmente due
possibilità, che definiscono quella che viene chiamata la “semantica di esecuzione”.
(i) Continuare a fare retry finchè non si riceve una risposta; questa è la semantica “almeno una
volta” (ma potrebbe darsi anche molte di più). (ii) Non ripetere la chiamata e sollevare
un’eccezione; questa è la semantica “al massimo una volta” (ma possibilmente anche zero volte).
La semantica ideale è ovviamente “esattamente” una volta, ma anche complicando lo scambio di
messaggi con ack , il problema non si risolve completamente. La scelta della strategia dal lato client
dipende da cosa deve fare il server quando è chiamato. Se la procedura remota è “idempotente”,
cioè il risultato non cambia qualunque sia il numero di volte che viene eseguita - ad esempio
sqrt(16) – allora va bene at least once. Se devo trasferire soldi da un conto bancario, va bene at most
once.
Il problema della semantica di esecuzione si pone anche nel caso 6, in quanto di solito il client,
quando riparte, non sa se la sua chiamata era poi andata buon fine.
Diciamo due parole sul più “antico” e diffuso middleware di supporto a RPC, e cioè il Distributed UUID di 16 byte
Computing Environment (DCE), sviluppato da Open Group, formerly Open Software Foundation 8 byte data e ora, in UTC (il numero di intervalli da 100 nanosecondi a partire dalla mezzanotte del
(OSF) a partire dalla fine degli anni ’80. 15 Ottobre 1582, inizio calendario Giuliano)
DCE, originariamente per Unix, è stato portao su varie piattaforme (incluso PC), e i suoi principi 2 byte clock sequnce (sorta di serial number degli UUID generati sullo stesso nodo)
sono alla base delle evoluzioni successive verso gli oggetti distribuiti (di cui vedremo qualcosa). 6 byte il nodo (generalmente il MAC address della scheda LAN)
Oltre il supporto a RPC, DCE include anche il supporto per un file system distribuito, un servizio di
directory, un servizio di sicurezza, e un servizio “di orologio”.
Alla chiamata del client, DCE si preoccupa di localizzare il server, stabilire una connessione con la
procedura remota (binding), convertire i dati in transito nelle due direzioni, e fornire un trasporto

19 20
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
L’ultimo punto da menzionare è come avviene il binding (in DCE).
Quando il server parte, chiede al SysOp una porta, e poi la comunica al demon locale, che la
memorizza in una tabella che contiene (server, endpoint, protocollo/i). Poi si registra al directory
(detto Global Location Broker in terminologia DCE), che sta in ascolto su una porta “well known”,
e quindi si può trovare con un broadcast. Il server fornisce al directory l’indirizzo della macchina su
cui gira e il nome del servizio. Notare che anche il DCE local demon sta in ascolto su una porta well
known, e quindi il client, avuto l’indirizzo del server , può chiedere al demon l’endpoint, e infine
può chiamare il servizio.
Le disgrazie del DCE (implementato su molte piattaforme) è stato l’arrivo della programmazione
a oggetti (fine anni ’80, primi ’90). Un oggetto incapsula dei dati (lo stato dell’oggetto) che
possono venire cambiati solo attraverso metodi “interni” dell’oggetto, che sono disponibili
all’esterno solo attraverso una “interfaccia” (l’implementazione dei metodi è anch’essa loro
incapsulata).
Il meccanismo RPC è ancora valido, con il vantaggio che la “chiamata” a oggetti remoti può
diventare ancora più trasparente. Il meccanismo di base è esattamente lo stesso.
Questa separazione tra l’interfaccia e l’oggetto stesso che implementa l’interfaccia è molto utile,
perchè così l’interfaccia può stare su una macchina e l’oggetto su un’altra.
Il client fa il binding con il proxy, il quale fornisce una copia locale al client dell’interfaccia. La
richiesta arriva al server e viene passata allo skeleton, il quale quale chiama la copia locale al server
dell’interfaccia. Proxy e skeleton fanno sostanzialmente marshalling e unmarshalling.
Notare che in generale lo stato dell’oggetto (i dati) risiedono su una sola macchina (il server). È
possibile però avere anche oggetti con lo stato distribuito.
Una grossa differenza tra RPC e sistemi distribuiti a oggetti è che in questo caso di solito il sistema
supporta riferimenti a oggetti “system-wide”, e quindi i riferimenti a oggetti possono essere passati
da un processo all’altro, magari come parametri di una invocazione a metodo remoto.
Nel binding viene materializzato un proxy, il quale deve “sapere” tutto quello che serve per parlare
col server. Mettere nel riferimento (proxy) l’indirizzo del server, l’endpoint e l’oggetto come
informazione hardcoded può essere troppo rigido (il server non si può muovere). Si può usare una
tecnica simile a quella del DCE. Si può semplificare mettendo addirittura soltanto un pointer
21
V. Casarosa – Tecnologie per il Commercio Elettronico
(implementation handle, ad esempio un URI) a una implementazione del proxy che può essere
scaricata dinamicamente al momento del binding. Un’altra differenza in RMI è il passaggio di
oggetti locali o oggetti remoti come parametri di una Remote Method Invocation (RMI). Poichè
tutti i parametri dei metodi sono oggetti, in tutto il sistema potrebbero essere usati solo riferimenti
a oggetti remoti, e quindi passare come parametri il loro riferimento. Per motivi di efficienza,
conviene spesso avere anche oggetti locali. In questo caso, quando si deve passare il riferimento a
un oggetto come parametro di una chiamata, è necessario fare una distinzione (si perde un pò di
trasparenza). In una chiamata gli oggetti locali vengono passati per valore (viene cioè inviata una
copia dell’oggetto locale) e gli oggetti remoti vengono passati per riferimento.
Nel DCE, malgrado gli sforzi, il supporto di chiamata a oggetti distribuiti è rimasto limitato dalla
natura intrinsica di RPC, e quindi in sostanza è una RPC a un metodo di un oggetto gestito dal
server. In Java, essendo gli oggetti integrati nel linguaggio, il supporto è molto più trasparente e,
come detto prima, se tutti gli oggetti fossero remoti, sarebbe completamente trasparente.
In più Java ha il vantaggio che il proxy è serializzabile, e quindi può essere passato come parametro
ad un altro processo, come implementazione del riferimento a un oggetto remoto. In effetti si usa
passare un “implementation handle”, cioe indicare la “client class” che può instanziare il proxy, e
indicare dove si trova questa classe. Notare che il tutto funziona perchè alla fine il proxy, su
qualunque macchina si trovi, viene eseguito nella JVM, che è uguale per tutti.
II PARTE :
Mentre il WWW è utilizzato per l’accesso ai dati e ai documenti, i Web Service sono utilizzati per
accedere tramite il protocollo http ai programmi, e sono sviluppati con una tecnologia simile a
quella del P2P.
Secondo la definizione data dal W3C un Web Service (servizio web) è un sistema software
progettato per supportare l'interoperabilità tra diversi elaboratori su di una medesima rete;
caratteristica fondamentale di un Web Service è quella di offrire un'interfaccia software (descritta in
un formato automaticamente elaborabile quale, ad esempio, il WSDL) utilizzando la quale altri
sistemi possono interagire con il Web Service stesso attivando le operazioni descritte
nell'interfaccia tramite appositi "messaggi" inclusi in una "busta" SOAP: tali messaggi sono,
solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. L'XML,
acronimo di eXtensible Markup Language, ovvero «Linguaggio di marcatura estensibile» è un
metalinguaggio creato e gestito dal World Wide Web Consortium (W3C), Rispetto all'HTML,
l'XML ha uno scopo ben diverso: mentre il primo è un linguaggio per la realizzazione della struttura
di template di pagine Web, il secondo è un linguaggio utile allo scambio dei dati, quindi di back-
office e non di front-office, o di esposizione che dir si voglia. Per scambio dei dati si intende la
conservazione in una struttura XML di dati presi, presumibilmente, da un database o da altre fonti,
oppure memorizzati direttamente all'interno di una struttura XML.
XML-RPC è un protocollo utilizzato in informatica che permette di eseguire delle chiamate a
procedure remote (RPC) attraverso la rete Internet. Nonostante la sua semplicità permette di
trasmettere strutture dati complesse, chiederne l'esecuzione ed avere indietro il risultato. Proprio
grazie all'utilizzo di standard basati su XML, tramite un'architettura basata sui Web Service
(chiamata, con terminologia inglese, Service oriented Architecture - SOA) applicazioni software
scritte in diversi linguaggi di programmazione e implementate su diverse piattaforme hardware
possono quindi essere utilizzate, tramite le interfacce che queste "espongono" pubblicamente e
mediante l'utilizzo delle funzioni che sono in grado di effettuare (i "servizi" che mettono a
disposizione) per lo scambio di informazioni e l'effettuazione di operazioni complesse (quali, ad
esempio, la realizzazione di processi di business che coinvolgono più aree di una medesima
azienda) sia su reti aziendali come anche su Internet: la possibilità dell'interoperabilità fra diversi
software (ad esempio, tra Java e Python) e diverse piattaforme hardware (come Windows e Linux) è
resa possibile dall'uso di standard "aperti" (per un concetto assimiliabile cfr. la voce "open source").
Il consorzio OASIS (Organization for the Advancement of Structured Information Standards) ed il
World Wide Web Consortium sono i principali responsabili dell'architettura e della
22
V. Casarosa – Tecnologie per il Commercio Elettronico
standardizzazione dei Web Service; per migliorare l'interoperabilità tra le diverse implementazioni XML name space identifier for SOAP serialization
dei Web Service l'organizzazione WS-I sta inoltre sviluppando una serie di "profili" per meglio XML name space identifier for SOAP envelope
definire gli standard coinvolti.
SOAP (Simple Object Access Protocol), fu definito inizialmente da IBM, Microsoft e altri e poi
sviluppato dalla W3C dal 1999. L’attuale proposta è la versione 1.2.
SOAP definisce:
x Il formato del messaggio per comunicazioni “one-way”, descrivendo come un messaggio
può essere racchiuso in un documento XML (Message Structure).
x La descrizione di come un messaggio SOAP (o il documento XML cherappresenta il
messaggio SOAP) viene trasportato attraverso il protocollo HTTP (per interazioni basate su
Web) oppure SMTP (per interazioni basate su e-mail) (Message Exchange)
x Un insieme di regole che devono essere rispettate quando si elabora un messaggio SOAP e
una semplice classificazione delle entità richieste durante tale fase. Inoltre viene descritto
quali parti del messaggio dovrebbero essere lette e da chi, e come reagire nel caso in cui il
contenuto non è comprensibile (Processing Model)
x Un insieme di convenzioni su come effettuare una chiamata RPC in un messaggio SOAP e
la relativa risposta, e come implementare uno stile di interazione RPC, ovvero: la chiamata
Esempio Soap: Body e Header
RPC del clientviene tradotta in un messaggio SOAP, inoltrata, tradotta in una chiamata RPC
sul server; la risposta del server sarà contenuta in un messaggio SOAP, spedito al client, e La codifica di una RPC con SOAP segue alcune regole convenzionali riguardanti:
passata ad esso come ritorno di una chiamata RPC (Protocol Binding) L’indicazione della risorsa (oggetto) tramite indirizzo(endpoint) alla quale è indirizzata la chiamata.
La trasmissione dei parametri del metodo e del valore di ritorno dello stesso.
L’indicazione dell’oggetto a cui è indirizzata la chiamata avviene in maniera dipendente dal
protocollo usato per trasportare il messaggio. In HTTP sarà la URI richiesta al server a specificare
l’oggetto dal quale si vuole invocare un determinato metodo. Convenzionalmente l’header
SOAPAction conterrà la URI completa dell’oggetto seguita dal nome del metodo.

La chiamata al metodo viene codificata come una struttura XML nel Body del payload SOAP, in
cui:
x L’elemento radice della struttura ha lo stesso nome del metodo da chiamare.
SOAP si basa sullo scambio di messaggi. x I parametri sono codificati come elementi figli della radice, dichiarati con lo stesso nome e tipo
I messaggi sono visti come degli involucri, in cui l’applicazione del corrispondente parametro formale del metodo ed elencati nello stesso ordine in cui
racchiude i dati che devono essere spediti. Un messaggio si compone compaiono nella signature del metodo.
di due parti:
x Per l’eventuale tipo ritornato dalla chiamatasi crea un elemento a parte che figurerà solo nel
- header: che può essere suddiviso in più blocks messaggio di risposta.
- body: che può essere suddiviso in più blocks L’esito della chiamata, se positivo, viene codificato come una struttura XML dove:
SOAP non dice cosa fare con header e body, ma indica solamente che
x L’elemento radice ha convenzionalmente il nome del metodo seguito da “Reponse”.
lo header è opzionale e che il body è obbligatorio. L’utilizzo dello
x Il primo elemento della struttura rappresenta il valore ritornato dal metodo, il suo nome non ha
header e del body è implicito. Il body serve a livello di dato
importanza ma il tipo deve coincidere con quello ritornato dal metodo.
dell’applicazione; lo header, invece, viene utilizzato a livello di
infrastruttura del dato. x A seguire vengono inseriti come compaiono nella signature tutti i valori dei parametri di tipo
out e in/out del metodo.
Lo stile di codifica può avvenire tramite la serializzazione, opzionalmente si può utilizzare soap-
enconding, oppure dipendere dall’applicazione (in questo caso si parla di accordi “out of band”).
Può essere usato in ciascun header block e in ciascun figlio (e discendenti) di “body”, quindi in uno
stesso messaggio possiamo avere codifiche diverse per elementi diversi.
L’unico elemento ammesso nel body è fault.
Nella versione 1.2, l’elemento fault viene specificato in più dettaglio. Esso richiede due sotto-
elementi obbligatori:
x Code: contenente un valore (il codice per il fault) e possibilmente un sottocodice (per
informazioni specifiche per applicazione)
23 24
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
x Reason: spiegazione del motivo che ha causato l’errore L’elaborazione di un nodo SOAP avviene nei seguenti passi:
z identificare tutti i suoi ruoli (SOAP non specifica come)
e può contenere pochi ulteriori elementi: z identificare tutti i blocchi a lui destinati;
x detail: dettaglia l’errore. z assicurarsi di “capire” tutti i blocchi con MustUnderstand=TRUE; altrimenti generare un
x node: l’identificazione del nodo che ha prodotto il fault (se assente, per default viene inteso chi fault (e non fare alcuna elaborazione)
contiene il messaggio in quel momento) z elaborare tutti i blocchi con MustUnderstand=TRUE
x role: il ruolo del nodo che ha generato il fault z a discrezione, elaborare tutti (o parte) degli altri blocchi (a lui destinati oppure no)
z cancellare tutti i blocchi a lui destinati
Gli errori relativi ad un obbligatorio mustUnderstand header vengono riportati usando un fault
element e includendo uno speciale header indicando quali degli headers originali non è stato Le funzionalità aggiuntive (da SOAP chiamate “features”) necessarie all’applicazione, come ad
“understood” esempio: log del messaggio, messaggio criptato, canale criptato, correlazione tra request e response,
ecc., possono venire fornite in due modi:
SOAP specifica in dettaglio come i messaggi devono essere elaborati (in particolare le entires dello z Negli “header block”, come combinazione di sintassi (tag XML nel blocco) e semantica
header). (elaborazione in un nodo); questa combinazione viene chiamata “SOAP Module”
Un messaggio SOAP può attraversare vari nodi SOAP (il protocollo non specifica come) essi z Nel protocollo di trasporto sottostante, tramite la definizione di un “SOAP binding”
possono essere SOAP Sender, SOAP Receiver, SOAP Intermediary.
Ogni nodo SOAP lungo il percorso verifica il ruolo associato ad ogni parte del messaggio. Come Nel trasferimento end-to-end ogni salto può avere un binding diverso. Il SOAP binding è la
meccanismo di estensione per passare informazioni “di controllo” ad un certo ruolo vengono specifica di come un messaggio passa da un nodo all’altro usando un protocollo di trasporto. Il
utilizzati gli header blocks. binding materializza il messaggio “astratto” SOAP (Infoset) e ne fornisce una rappresentazione
I tre ruoli standard sono: none, next, o ultimateReceiver. Le applicazioni definiscono i propri ruoli e serializzata. Il binding (in generale) può supportare features necessarie all’applicazione (ad esempio
li usano nel messaggio. Il ruolo determina chi è responsabile per ogni parte del messaggio. Se un canale criptato, correlazione tra request e response, ecc.). Il binding (in generale) deve specificare i
block non ha un ruolo, per default viene impostato a ultimateReceiver. Se viene impostato un Message Exchange Patterns (MEP) supportati (che sono anche loro features): one-way, request-
mustUnderstandflag, un nodo che risponde al ruolo definito deve elaborare quella parte di reponse, reponse.
messaggio, altrimenti deve generare un “fault” e non inoltrare il messaggio. SOAP 1.2 include un Riguardo il binding di SOAP con HTTP (Web Method Feature), SOAP può usare i metodi GET o
attributo relay. Se presente, il nodo che non elabora quella parte del messaggio ma deve inoltrarlo POST. Con il metodo GET, la richiesta non è un messaggio SOAP, ma solo la risposta lo è; con
(cioè, non può rimuovere quella parte). L’uso dell’attributo relay insieme al ruolo next, è molto utile POST sia la richiesta che la risposta sono messaggi SOAP. SOAP usa gli stessi codici di errore e di
per garantire persistenza dell’informazione lungo il percorso del messaggio (tipo una sessione). stato del protocollo HTTP. Le specifiche SOAP suggeriscono anche un binding a SMTP che correla
request-response (In-reply-to, Header block).
Role absent "none" "next" "ultimateReceiver"
Tra SOAP 1.1 e SOAP 1.2 vi sono delle differenze tra i nomi:
Node
initial sender not applicable not applicable not applicable not applicable SOAP 1.1 SOAP 1.2
intermediary no no yes no Client Sender
ultimate receiver yes no yes yes Server Receiver
FaultCode Code
Node intermediary ultimate receiver FaultString Reason
Actor Role
mustUnderstand
"true" must process must process Data l’importanza di XML, abbondano le API Java:
"false" may process may process
absent may process may process z JAXP -- Java API for XML Processing – elaborazione e trasformazione di documenti XML
(SAX, DOM, XSLT)
z JAXB -- Java Architecture for XML Binding – validazione e trasformazione di schemi e
documenti XML in classi e oggetti Java
z SAAJ -- SOAP with Attachments API for Java – preparazione (e spedizione) di messagi
SOAP anche con attachments
z JAX-RPC -- Java API for XML-based RPC – preparazione e spedizione di messaggi SOAP
con il meccanismo RPC
z JAXR -- Java API for XML Registries – interrogazioni e interazioni con “business
registries”
z JAXM -- Java API for XML Messaging – preparazione e spedizione di messaggi (anche
XML e SOAP)
z WSDL4J (JWSDL) – Web Services Description Language for Java
z UDDI4J – Universal Description, Discovery and Integration for Java

25 26
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
Andiamo ad analizzare le più importanti.
SAAJ (SOAP with Attachments API for Java) è un’API della Java Community Process per SOAP
con attachments, ovvero permette di inviare, opzionalmente, messaggi SOAP con allegati. È
caratterizzato da una gestione semplice delle connessioni, tramite request/reponse sincrona. Viene
utilizzata una codifica Base64 che permette di codificare anche dati non binari, e XML-binary
Optmizing Packaging per la descrizione dell’allegato.
JAX-RPC incarnazione moderna di DCE, RMI, ecc. Rispetto agli agli antenati, ha aggiunto un
livello in più di astrazione, dovuto a WSDL (cioè XML) e SOAP (cioè XML) garantendo
l’interoperabilità. JAX-RPC sta per Java API for XML-based RPC. JAX-RPC è la tecnologia Java
per costruire sia Web services che i rispettivi client che usano remote procedure calls (RPC) ed
XML. In JAX-RPC una RPC si basa sul protocollo SOAP. Le chiamate e le risposte RPC vengono
trasmesse come messaggi SOAP over HTTP.
Parte server: si specificano le procedure remote definendo i metodi di una interfaccia scritta in
linguaggio Java. Inoltre vengono realizzate le classi che implementano questi metodi.
Parte client: viene utilizzato un proxy (la classe stub del client) su cui si invocano i metodi del
servizio.
In JAX-RPC non viene fatto il parser dei messaggi SOAP. È il sistema a runtimed i JAX-RPC che
converte le chiamate e le risposte delle API in messaggi SOAP. Quindi viene utilizzato solo il
linguaggio Java e vengono nascosti i messaggi SOAP. Dato l’utilizzo di SOAP e HTTP, il client (o
il server) possono anche non essere in Java. Basta che supportino HTTP e capiscano SOAP. In
ambiente Java, con JAX-RPC posso scrivere il client (o il server) “come se” non fossero remoti. Lo
schema di funzionamento è quello già noto:
27
V. Casarosa – Tecnologie per il Commercio Elettronico
Per assicurare l’interoperabilità è necessario avere un documento WSDL, quindi JAX-RPC
definisce un mapping tra i types di XML e i types di Java (SOAP encoding e XML schema):
– Mapping of XML data types to the Java types (abbastanza ovvio per I tipi semplici).
– Mapping of abstract definitions of port type, operations and messages to Java
interfaces and classes
– Java representation of a wsdl:port address specification
– Java representation of a wsdl:service definition
Questi mappings sono definiti da JAX-RPC anche nell’altro verso, per generare un documento
WSDL a partire da un Web Service implementato e “deployed”.
Definisce inoltre un meccanismo di “estensibilità” per definire il mapping di tipi non previsti dalle
specifiche, per mezzo di “custom serializers e deserializers” che si possono pluggare in JAX-RPC.
Dal lato client si può invocare un Web Service (service endpoint) in tre modi
1. Stub statico, generato da wscompile:
- Configurato staticamente
- Configurato a runtime
2. Stub dinamico, generato da JAX-RPC a runtime
3. Dynamic Invocation Interface (creazione di un oggetto “call”, definizione delle sue proprietà e
suo utilizzo per invocare il servizio remoto.
I modi di interazione sono: Synchronous request/response, one-way, non-blocking RPC.
Quanto più è dinamico, tanto più dobbiamo mettere codice nel client.
Gli Handlers sono quei metodi che elaborano gli headers di un messaggio SOAP.
Sono metodi che si possono aggiungere sia sul lato client che sul lato server
Si registrano a JAX-RPC e possono essere ordinati in sequenza (handler chain)
Dal lato client:
La richiesta SOAP in partenza viene passata alla catena di handler prima di essere spedita.
La risposta SOAP in arrivo viene passata alla catena di handler prima di essere data al client
(applicazione).
Dal lato server:
La richiesta SOAP in arrivo viene passata alla catena di handler prima di essere data al Web
Service.
La risposta SOAP in partenza viene passata alla catena di handler prima di essere spedita.
Permettono la realizzazione pratica dei “SOAP Nodes” e dei ruoli.
Passiamo a WSDL (Web Service Description Language). Le ragioni che hanno portato a definirlo
possono essere identificate nella necessità di avere una descrizione per i Web Service “machine-
processable” , per rappresentare i termini di un “contratto” tra il cliente e il fornitore (motivazione
maggiore), avere una descrizione più precisa rispetto aquella in linguaggio naturale, per permettere
la Dynamic Discovery (possibilità di scoprire dinamicamente servizi web) e infine
l’interoperabilità.
Esistono tool per la generazione automatica di documenti WSDL, a partire da un servizio esistente,
e Stub (proxy) e skeleton (template) per l’accesso remoto al servizio (se necessario) a partire dal
documento WSDL. Dentro WSDL manca (per ora) la semantica, si utilizza il cosiddetto Business
Level Agreement.
Creato originariamente da IBM, Microsoft e Ariba, attualmente si è arrivati alla versione 2.0.
WSDL ha un ruolo e lo scopo simile a quello di un linguaggio IDL (Interface DescriptionLanguage)
In WSDL sono dei documenti XML che descrivono le interfacce dei Web Service. Differentemente
agli IDL, WSDL oltre a specificare le operazioni offerte dai servizi, deve anche definire il
meccanismo per accedere al servizio. Una specifica WSDL è caratterizzata da una parte abstract
(concettualmente analoga ai convenzionali IDL) e da una parte concrete (dove vengono definiti il
protocollo di binding ed altre informazioni). La parte abstract è composta di definizioni di port type,
ovvero ognuna di essa è un’insieme di operation slegate tra loro logicamente. Ogni operation
definisce un semplice scambio di messages. Un message rappresenta il dato che deve essere
scambiato in una singola trasmissione.
28
V. Casarosa – Tecnologie per il Commercio Elettronico
 Import/Include
Definizioni
astratte
Types

Interfaces Operations

Bindings Operations

Definizioni
concrete
Services Endpoints

Elementi in WSDL 1.2 Elementi in WSDL 2.0

WSDL utilizza lo stesso sistema dei tipi utilizzato in XML Schema, differentemente dai
convenzionali IDL in cui il sistema dei tipi è imposto dalla piattaforma sottostante (CORBA, J2EE,
ecc.) Qualora necessario, al suo interno può essere definito un differente sistema dei tipi. La
definizione dei tipi è il primo passo nella definizione di una interfaccia WSDL. Il secondo passo è la
definizione dei messaggi: un message in WSDL è un “typed document” diviso in parts. Ogni part è
caratterizzata da un nome e da un tipo definito nello XML Schema, es. per invocare una procedura
(RPC) che prende come parametri un intero ed un floating point, viene definito un messaggio che
ha due parti: una conterrà l’intero e l’altra conterrà il floating point. In questo caso sia l’intero che il
FP sono tipi base dello XML Schema per tanto non è necessario nessun altra definizione.
WSDL 2.0
Il terzo passo della definizione di un WSDL è la definizione delle operazioni (chiamate:
transmission primitives o interactions). Nella versione1.0 ci sono quattro operazioni base o MEPs
(Message Exchange Patterns): one-way, request-response, solicit-response, notification. One-way e
notification richiedono un singolo messaggio. In one-way il client invoca un servizio inviando un
messaggio; in notification, invece, è il servizio che invia il messaggio. Request-response e solicit-
response richiedono lo scambio di due messaggi. Il primo inizia al di fuori del servizio (il servizio
viene invocato con seguito di una risposta); il secondo è iniziato dal servizio (il servizio fa una
richiesta ed aspetta una risposta di ritorno). Le interazioni sincrone vengono realizzate usando le
operazioni di tipo request-response oppure solicit-response, mentre quelle asincrone vengono
realizzate attraverso le operazioni one-way e notification.

In WSDL 2.0 i MEPs sono stati aumentati:

z In-Only. This pattern consists of exactly one message received by a service from some
other node. No fault may be generated.
z Robust In-Only. This pattern can be considered as a variation of In-Only. It also consists of
exactly one message received by a service, but in this case faults can be triggered by the
message received.
z In-Out. This pattern consists of exactly two messages: a message received by a service from
some other node, followed by a message sent to the other node. The second message may be
replaced by a fault.
z In-Optional-Out. This pattern consists of one or two messages: a message received by a
service from some other node, optionally followed by a message sent to the other node from
the service. Each message may trigger a fault in response.
z Out-Only. This pattern consists of exactly one message sent to some other node from a
service. No fault maybe generated.
z Robust Out-Only. This pattern can be considered as a variation of Out-only. It also consists
of exactly one message sent to some other node from a service, but in this case faults can be
WSDL 1.0 triggered by the message.
z Out-in. This pattern consists of exactly two messages: a message sent to some other node
from a service, followed by a message received by the service from the other node. The
second message may be replaced by a fault.

29 30
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
 z Out-Optional-In. This pattern consists of one or two messages: a message sent to some
other node from a service, optionally followed by a message received by the service from Vediamo infine come fatto un Web Service Stack (nello schema manca ancora tutta la parte relativa
the other node. Each message may trigger a fault in response. alla semantica):

Vediamo in dettaglio il meccanismo import e include di WSDL 2.0:

Mechanism
wsdl:import
wsdl:include
wsdl:types/ xs:import
wsdl:types/
xs:schema/xs:import
wsdl:types/
xs:schema/xs:include
La struttura di un documento WSDL è la seguente:
<wsdl:description
targetNamespace="xs:anyURI" >
<documentation />*
[ <import /> | <include /> ]*
<types />?
[ <interface /> | <binding /> | <service /> ]*
</wsdl:description>
Web Services Stack
Object Meaning
Declare that WSDL 2.0 components
WSDL 2.0
refer to WSDL 2.0 components from a
Namespace BPEL/
DIFFERENT targetNamespace.
Merge Interface, Binding and Service
components from another WSDL 2.0
WSDL 2.0 Document
document that has the SAME
targetNamespace.
Declare that XML Schema
XML Schema components refer to XML Schema
Namespace components from a DIFFERENT
targetNamespace.
Declare that XML Schema
XML Schema components refer to XML Schema
2005-2006 V. Casarosa - Tecnologie per il Commercio Elettronico Parte b4 - 1
Namespace components from a DIFFERENT
targetNamespace.
Merge XML Schema components UDDI: Universal Discovery, Description ed Integration (UDDI) è una specifica per la realizzazione
XML Schema from another XML Schema document di registri distribuiti, basati sul web, di web service; i registri UDDI vengono usati per la ricerca e la
Document that has the SAME or NO promozione di servizi web. È sostanzialmente un servizio di naming come il DNS (che però opera a
targetNamespace. livello più basso) o LDAP. L'interrogazione dei registri può essere effettuata da browser o con il
SOAP. Le informazioni gestite da UDDI sono di tre tipi:
- pagine bianche: contengono informazioni anagrafiche delle aziende.
- pagine gialle: contengono le liste dei WS divisi per categoria.
- pagine verdi: contengono informazioni tecniche sui WS come l'URL dove risiedono e gli
eventuali file WSDL.
? = zero oppure una occorrenza
* = zero oppure più occorrenze
+ = una oppure più occorrenze

An optional documentation comes first, if present.

Then comes zero or more elements from among the following, in any order:
include
import
extensions
An optional types follows
Zero or more elements from among the following, in any order:
interface: descrive una sequenza di messagi che un service può inviare o ricevere, raggruppandoli
in operations. Un operation è una sequenza di messaggi di input e output, e un’interfaccia è un set di
operation. Una Interfaccia può estendere una o più interfacce.
binding: descrive un formato concreto per il messaggio e il protocollo di trasmissione che verrà
usato per definire un endpoint. Definisce i dettagli implementativi necessari ad accedere al service.
service: Descrive un set di endpoint dove verra fornito il servizio.
extensions. Un UDDI registry (gestito da un’operatore) contiene le descrizioni dei business e dei servizi
supportati. Descrizione del Data Model presa da OASIS UDDIV2 Data structure Specs e qualcosa
31 32
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
da V3 che ha portato più flessibilità nei tipi di registro (la notazione cambia nelle diverse versioni). L'UDDI è uno degli standard alla base del funzionamento dei Web Service: è stato progettato per
Ha avuto una rapida evoluzione, tre versioni differenti in poco tempo, è basato su XML (WDSL e essere interrogato da messaggi in SOAP e per fornire il collegamento ai documenti WSDL che
SOAP), è costituito da un Registry e un Data Model, sono state sviluppate API appropriate tra cui descrivono i vincoli protocollari ed i formati dei messaggi necessari per l'interazione con i Web
JAXR (in Java). Ecco i tipi di registro: Service elencati nella propria directory.

III PARTE :

Nell'ambito dell'informatica, con la locuzione inglese di Service-Oriented Architecture (SOA)

viene indicata un'architettura software atta a supportare l'uso di servizi (Web services) per
soddisfare le richieste degli utenti così da consentire l'utilizzo delle singole applicazioni come
componenti del processo di business.
Nell'ambito di un'architettura SOA è quindi
possibile modificare, in maniera relativamente più
semplice, le modalità di interazione tra i servizi, la
combinazione nella quale i servizi vengono
utilizzati nel processo, così come risulta più
agevole aggiungere nuovi servizi e modificare i
processi per rispondere alle specifiche esigenze di
business: il processo di business non è più
vincolato da una specifica piattaforma o da
La V2 ha specificato meglio il concetto (e le regole) di replication e ha introdotto il concetto di un'applicazione ma può essere considerato come
“subscribe”, con il meccanismo di notification quando ci sono nuove registrazioni. Ecco le funzioni un componente di un processo più ampio e quindi
di una UDDI registry: riutilizzato o modificato. L'architettura orientata ai servizi si presenta particolarmente adatta per le
aziende che presentano una discreta complessità di processi e applicazioni, dal momento che
agevola l'interazione tra le diverse realtà aziendali permettendo, al contempo, alle attività di
business di sviluppare processi efficienti, sia internamente che esternamente ed aumentarne la
flessibilità e l'adattabilità.
Benché molte aziende offrano prodotti che possono formare la base di una SOA va sottolineato che
la SOA non è un prodotto. Un'architettura orientata ai servizi non è legata ad una specifica
tecnologia. Può essere realizzata usando una vasta gamma di tecnologie, comprese REST, RPC,
DCOM, CORBA o i Web services. SOA può essere implementata anche non usando nessuno di
questi protocolli e, per esempio, basarsi sul file system, trasferendo i dati in base alle specifiche
dell'interfaccia tra i processi, conformemente al concetto di SOA. La chiave è l'indipendenza dei
servizi, definiti da un'interfaccia specifica, che possono essere chiamati per eseguire i propri compiti
in un modo standard, senza che il servizio abbia conoscenza dell'applicazione chiamante e senza
Di seguito viene schematizzato un UDDI Data Model: che l'applicazione abbia conoscenza, o necessiti di averne, del servizio che effettivamente eseguirà
l'operazione. SOA può anche essere vista come uno stile dell'architettura dei sistemi informatici che
permetta la creazione delle applicazioni sviluppate, combinando servizi debolmente accoppiati e
interoperabilità degli stessi. Questi servizi interoperano secondo una definizione formale, detta
protocollo o contratto, come per i WSDL indipendente dalla piattaforma sottostante e dalle
tecnologie di sviluppo (come Java, .NET, ecc). I servizi, per esempio, scritti in Java usando la
piattaforma Java EE e quelli in C# con .NET possono essere utilizzati dall'applicazione sovrastante.
Le applicazioni in esecuzione su una piattaforma possono anche utilizzare servizi in esecuzione su
altre, come con i Web services, facilitando quindi la riusabilità. SOA può supportare l'integrazione e
la consolidazione di attività all'interno di complessi sistemi aziendali, ma non specifica o fornice la
metodologia o il framework per documentare capacità e potenzialità dei servizi.
I linguaggi di altro livello come BPEL e le specifiche come WS-CDL e WS-Coordination
estendono il concetto di servizio, fornendo un metodo per definire e supportare la coordinazione dei
servizi di rifinitura con quelli maggiori, che, di conseguenza, possono essere inclusi in flussi di
controllo e processi aziendali implementati con applicazioni composte o portali.
SOA è designato per il collegamento a richiesta di risorse computazionali (principalmente
applicazioni e dati), per ottenere un dato risultato per gli utenti, che possono essere utenti finali o
altri servizi. L'OASIS (Organization for the Advancement of Structured Information Standards)
definisce SOA così:
33 34
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
Un paradigma per l'organizzazione e l'utilizzazione delle risorse distribuite che possono essere Un Business Process è un flusso operativo, realizzato come una serie di passi o attività, finalizzato a
sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, completare una transazione di business. In BPEL (Business Process Execution Language) un
interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e Business Process è un service stateful (mantiene le informazioni sullo stato) con cui eseguire i passi
aspettative misurabili. per raggiungere l’obiettivo del business.
Anche se esistono molteplici definizioni di SOA, solo il gruppo Organization for the Advancement Il business process è una sequenza di interazioni tra un Web Service (quello che orchestra) e altri
of Structured Information Standards ha prodotto una definizione formale applicabile profondamente Web Service (i partner services). Il business process (descritto con BPEL) è di fatto un Web
sia alla tecnologia che ai domini aziendali. Service, con tanto di WSDL. La descrizione delle interazioni è fatta tramite un documento XML
La validità di un'architettura orientata ai servizi (SOA) è conseguenza degli elementi e degli che, in un certo senso, rappresenta il “programma” da eseguire per ottenere lo scopo del business
standard su cui si fonda. In particolare vanno considerati i seguenti aspetti: process. Esistono “BPEL engines” in grado di “eseguire” un processo descritto in BPEL. BPEL può
x Standard aperti: per poter operare in ambienti multipiattaforma è necessario, o essere utilizzato anche per descrivere un “abstract process”, cioè una descrizione delle interazioni
quantomeno consigliabile, utilizzare esclusivamente standard aperti quali XML, WSDL e fatta a livello più astratto e non eseguibile.
WSS (Web Services Security). Gli elementi (anche attività) di BPEL sono di seguito riportati:
x Modularità: bisogna trovare il giusto equilibrio tra i servizi erogati da ogni singolo
componente, creando un insieme bilanciato di piccoli servizi riutilizzabili per le funzioni z <process> Root Element
comuni e servizi più grandi per processi specifici. z <partnerLink> Describes service collaborators, including role
x Contratti di servizio: WSDL (Web Services Description Language) è la specifica standard and target operation (WSDL port type)
per la creazione di contratti di Web Services, un contratto definito avrà come conseguenza z <variable> Data used in the process
servizi più flessibili. z <receive> Block and wait for partner message
x ESB (Enterprise Service Bus): La dorsale di pubblicazione dei servizi ed abilitazione delle z <reply> Reply back to the partner
applicazioni per accedervi. Inoltre include caratteristiche quali adattatori per i sistemi z <invoke> Invoke a partner Web Service, either as a
legacy, capacità di orchestrazione dei servizi, autorizzazione e autenticazione lato sicurezza, request/reply (synch), or one-way (asynch)
trasformazione dei dati, supporto per regole di business e capacità di monitorare i service- z <assign> Copy data between variables
level agreement. z <throw> Generate a fault
Sono diversi gli standard proposti, spesso in concorrenza tra loro (anche se non ufficialmente): z <wait> Suspend operation for a given time period
x W3C: SOAP, WSDL, WS Coreography Description Language (WS-CDL) z <empty> Do nothing (a no-op)
x OASIS: UDDI, WSBPEL, WS-Security z <sequence> Execute series of activities in order
Molto attivi sulla security. Hanno ereditato iniziative di ebXML z <flow> Execute series of activities concurrently
x ebXML: Framework for B2B, Collaborative Protocol Profile (CPP) e Collaborative z <switch> Case statement
Protocol Agreement (CPA) z <while> Looping construct, repeat while true
ebXML è il più sospetto. Le sue specifiche sembrano in concorrenza con SOAP, WSDL, z <pick> Block and wait for a message or alarm
UDDI. Ha un altro registro, con altre interfaccie. z <eventHandlers> Receive message or alarm––unblocked
Il CPP (Collaboration Protocol Profile) è un documento XML che contiene le stesse (process still executing)
informazioni di WSDL. Ci sono molti (troppi) articoli che si affannano a dimostrare che non z <scope> Define a scope (bounds) for variables, fault
sono in concorrenza. handlers, compensation and correlation
x WS-I (Consorzio di aziende): Interoperability Basic Profiles z <faultHandlers> Designate exception handling for specific
x IBM, Microsoft, SAP, Oracle, BEA, etc (varie estensioni) conditions (catch and catchall)
z <compensate> On a fault, execute compensating logic to
Vediamo una lista delle specifiche e estensioni che sono proposte, progettate, implementate da “undo” previously completed activities
IBM, MS, BEA. L’idea è sempre quella di definire le specifiche basandosi su XML e XSD, e poi z <correlations> Associate messages with specific process instances
eventualmente estendere SOAP, WSDL, UDDI. z <terminate> Immediately end and destroy the process
z WS-Addressing (presente come estensione anche in SOAP)
z WS-Policy Facciamo un esempio, in cui definiamo il “Business process” di un Web Service che accetta un
z WS-Metadata Exchange Purchase Order.
z WS-Security (presente come estensione anche in SOAP)
z WS-Trust Dopo averlo ricevuto, inizia tre interazioni in parallelo:
z WS-Secure Conversation
z WS-Federation - calcolare il prezzo
z WS-Reliable Messaging (presente come estensione anche in SOAP) - decidere lo shipping (trasporto)
z WS-Coordination - schedulare la produzione
z WS-BPEL (BPEL rappresenta l’unione di due sforzi separati di IBM.)
z WS-CDL Le freccie solide rappresentano le dipendenze:
z SAML
z CPP - per il prezzo totale bisogna avere il prezzo dello shipping
z CPA - per finalizzare la produzione bisogna avere la data di shipping

35 36
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
 L’elemento Partner Link definisce le interazioni con gli altri services, e i ruoli che i due servizi che
interagiscono hanno. Se un servizio viene solo invocato, il partner link ha un solo ruolo. Il primo
rappresenta la connessione con il client che utilizza il servizio PO. Il secondo rappresenta la
connessione con il servizio invoicing, dove il primo ruolo è quello dell’invoicing, che offre il
servizio al PO, il secondo ruolo è quello del PO (invoice requester) che verrà chiamato dall’invoice
Callback. In modo analogo si hanno due ruoli per lo shipping. Lo scheduling viene solo chiamato
dal PO e ha un solo ruolo. Notare che per ogni ruolo viene definito il PortType, cioè le operazioni
che quel ruolo deve supportare.
Nel documento XML che descrive il business process in BPEL, verrano definiti i link del processo,
che fanno riferimento ai LinkType definiti nel WSDL .
La sequenza esterna suppone che la chiamata dal client del PO sia del tipo request/response. Invoke
è invece del tipo “message” e non aspetta risposta.

WS addressing fornisce un meccanismo di trasporto neutrale per indirizzare web-services e messagi

in accordo con le raccomandazioni del W3C.
Endpoint Reference
– Abstract Properties
– XML Representation
z Message Addressing Properties
– Abstract Properties
– XML Representation
Vogliamo definire il business process del servizio “Purchase Order”, il quale interagisce con altri z SOAP Binding
tre servizi: – Addressing properties in header blocks
- invoice
- shipping End to end: ingl., da estremità a estremità. Caratteristica del protocollo quale il TCP per la
- production scheduling rilevazione degli errori e del controllo di flusso. Si distingue dalla rilevazione effettuata nella
Le operazioni dei servizi coinvolti sono le seguenti (tra parentesi c’è il chiamante dell’operazione): modalità hop-by-hop (tratta per tratta) nel livello Collegamento dati (Data link) o nel Livello di rete.
z Purchase Order services Il controllo TCP viene effettuato solo dalle due entità TCP poste negli host ai capi della
– sendPurchaseOrder (PO client) connessione. Ad esempio nella trasmissione dati tra due processi client-server, l'entità TCP di un
– sendInvoice (Invoice Service Callback) host (Client) comunica direttamente con l'entità TCP dell'altro host (Server) senza alcun'altra entità
– sendSchedule (Shipping Service Callback) TCP intermediaria del Livello Trasporto.
z Invoice services Il Point-to-Point Protocol, o PPP, è un protocollo di rete di Livello datalink, comunemente usato
– initiatePriceCalculation (PO service) nello stabilire connessioni dirette tra due nodi. PPP compone spesso il livello datalink (il livello di
– sendShippingPrice (PO service) collegamento dati) del modello OSI nelle connessioni su circuiti punto-punto sincronizzati e non
z Shipping services sincronizzati, soprattutto in ambito WAN. PPP era stato progettato per lavorare assieme ad altri
– requestShipping (PO service) protocolli di livello superiore, come l'IP, IPX, e AppleTalk.
z Scheduling services Il protocollo di trasporto (ad es. https) può garantire sicurezza punto-a-punto, è necessaria sicurezza
– requestProductionScheduling (PO service) end-to-end.
– sendShippingSchedule (PO service) Si devono utilizzare il più possibile tecnologie e standard esistenti:
Nel listing distribuito si vede come il WSDL di “Purchase Order” (solo parte astratta) viene esteso – XML-signature
aggiungendo i “partner link types” che rappresentano le interazioni (e le dipendenze) tra Purchase – XML-encryption
Order e gli altri servizi. – SOAP Headers
La protezione dei dati deve essere garantita in memoria (resa più difficile se il computer è collegato
<plnk:partnerLinkType name="purchasingLT"> (riga 94) in rete) e in transito (ancora peggio). Internet è intrinsicamente “non sicura” (sniffers, routers)
<plnk:role name="purchaseService"> I principali aspetti della sicurezza sono: Segretezza, Integrità, Autenticità. Il controllo di accesso ai
<plnk:portType name="pos:purchaseOrderPT"/> dati (scopo ultimo della sicurezza) e tutti gli altri aspetti della sicurezza derivano da queste tre
</plnk:role> proprietà.
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT"> (riga 99)
La crittografia è nota da secoli e originariamente si basava sulla cifratura dell’alfabeto (o
<plnk:role name="invoiceService"> sostituendo numeri con lettere, o facendo corrispondere ad ogni lettera un’altra lettera o simbolo).
<plnk:portType name="pos:computePricePT"/> Con l’avvento dei calcolatori ha avuto una grande evoluzione. Normalmente l’algoritmo di
</plnk:role> criptazione è pubblico, ovvero noto a tutti, la sicurezza viene invece garantita dalla segretezza della
<plnk:role name="invoiceRequester"> chiave. I principali algoritmi si dividono in quelli a chiave privata o simmetrici (una sola chiave per
<plnk:portType name="pos:invoiceCallbackPT"/>
</plnk:role>
cifratura e decifratura) e quelli a chiave pubblica o assimetrici (ci sono due chiavi una simmetrica e
</plnk:partnerLinkType> una pubblica, una verrà usata per cifrare e l’altra per decifrare).

37 38
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
Un esempio di algoritmo a chiave privata è riportato in figura. Il punto fondamentale è che la chiave rielaborati da un’altra permutazione. La procedura continuerà poi negli altri cicli, seguendo lo
essendo unica è la stessa per tutti e due. Spesso il problema che si pone è proprio quello di schema generale esposto in precedenza, in totale sono 16 cicli.
scambiare la chiave in maniera sicura (è un cane che si morde la coda). L'algoritmo elabora blocchi di dati di 64 bits utilizzando un insieme ben preciso di operazioni:
Paolo Mario Nel primo ciclo, i dati in ingresso vengono sottoposti ad una permutazione iniziale, suddivisi in due
semiblocchi, scambiati di posto ed elaborati singolarmente. In particolare, sul semiblocco destro
vengono applicati più procedimenti di somma binaria (OR esclusivo) utilizzando fra l'altro anche la
messaggio messaggio chiave risultante dal corrispettivo ciclo di elaborazione sulla chiave.
chiave segreta R viene espanso a 48 bit, or esclusivo con la sottochiave, ridotto a 32 bit con selction box, e infine
in chiaro in chiaro
permutato.
Al termine del primo ciclo i due semiblocchi ottenuti vengono sottoposti a quattordici cicli generici.
Ogni ciclo generico è simile al primo ciclo tranne che per la mancanza della permutazione iniziale.
algoritmo di cifratura algoritmo di decifratura Al termine del quattordicesimo ciclo generico, i due semiblocchi risultanti entrano nell'ultimo ciclo.
Anche in questo caso, le operazioni effettuate sono simili a quelle viste in precedenza, solo che al
termine i dati ottenuti vengono sottoposti ad una permutazione finale.
Per la decifratura, si applica lo stesso procedimento, applicando le sottochiavi in ordine inverso.

messaggio cifrato messaggio Electronic Code Book (ECB): Il modo più semplice è di trasformare un blocco per volta. Ogni
chiave segreta
cifrato blocco di 64 bit sarà quindi criptato indipendentemente dagli altri. Come dice il nome, in teoria,
fissata la chiave, posso costruire un dizionario. Si presta a analisi di frequenza.
Gli algoritmi sono veloci e implementati anche via hardware, si è passati dai stream cipher (un
carattere alla volta) ai block cipher (un blocco di caratteri alla volta, cifratura blocchi di 64 bit).
Una chiave da 64-192bit è dunque da considerarsi piccola, ovvero non garantisce un’adeguata
sicurezza. La forza (robustezza: strength) sta sia nell’algoritmo, sia nell’impedire attacchi di forza
bruta, cioè provare tutte le combinazioni della chiave: non feasibility (è solo una questione di
tempo). DES, algoritmo più noto e usato (IBM e NSA anni 70) ha resistito 20 anni. L’evoluzione
della potenza di calcolo lo ha reso non sicuro. Nel 98 violata chiave DES 56 bit in 22 ore. (premio
del NIST). Oggi si è passati a implementazioni più sicure dell’algoritmo note come AES e 3DES (
DES-EEE: K1, K2, K3 - DES-EDE: k1=K3, oppure k1=K2=K3 ). Altri algoritmi a chiave privata
sono: IDEA, RC5, SkipJack. I due principali svantaggi sono che il numero di chiavi cresce come n2
e sul modo di scambiarsi le chiavi.
A titolo di esempio, vediamo il DES(Data Encryption Standard):

Cipher Block Chaining (CBC): Per rendere la codifica più robusta, si concatenano i blocchi uno
con l’altro. In questo caso è necessario(oltre alla chiave k) accordarsi anche sul valore di C0.
È necessario un “blocco” iniziale (seed) , il blocco cifrato diventa il seed del blocco successivo.
Per decifrare, bisogna ricordare che se C=A XOR B, allora A=C XOR B.

Li, Ri 32 bit
Ki 48 bit (derivati dalla chiave da 56 bit con permutazioni e shift)
F espansione di Ri a 48 bit, poi XOR, selection box, permutazione

La chiave iniziale è costituita da 64 bits generati solitamente in modo casuale ma aventi una
particolarità: l'ottavo bit di ogni riga non è altro che un controllo di disparità effettuato sui bits
costituenti la riga e non verrà utilizzato nelle successive operazioni di elaborazione sulla chiave.
I 64 bits della chiave iniziale vengono sottoposti alla permutazione iniziale attraverso la quale
vengono eliminati gli otto bits di controllo riducavando la chiave a 56 bits. I 56 bits ottenuti
vengono suddivisi in due parti da 28 bits per poi essere spostati singolarmente a sinistra. Il valore
dello spostamento è variabile ed è legato a un ciclo predefinito. I due semiblocchi vengono quindi

39 40
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
Output Feedback Mode (OFM): si fa il feedback dell’uscita dalla codifica e poi si fa l’OR con Mi.
Cipher Feedback Mode (CFM), è dove si fa il feedback dell’uscita dell’OR.
Passiamo ora ad analizzare gli algoritmi a chiave pubblica. Mentre la chiave privata è segreta per
definizione, la chiave pubblica si presuppone che sia conoscibile da tutti. Allora ogni “principal”
avrà due chiavi: Privata e Pubblica. Ogni chiave potrà essere utilizzata per cifrare o per decifrare, la
chiave usata per cifrare non potrà essere usata per decifrare e viceversa. La conoscenza della chiave
pubblica non dà alcuna indicazione su quella privata. Vediamo un’esempio ( tutti conoscono la
chiave pubblica di Mario, l’unico che conosce la chiave privata di Mario, per definizione, Mario
stesso):
Paolo Mario
41
V. Casarosa – Tecnologie per il Commercio Elettronico
Solo Paolo può avere cifrato il messaggio con la sua chiave privata, garantendo così al messaggio
stesso autenticità e integrità (in quanto il messaggio può essere decifrato solo con la chiave
pubblica di Paolo associata univocamente alla sua chiave privata):
Paolo Mario
AUTENTICATO
Applicando le due cifrature in cascata si ottiene anche la segretezza oltre all’integrità e
l’autenticità:
Paolo Mario
Passiamo ora ad analizzare l’algoritmo a chiave assimmetrica più noto: RSA
Il nome dell’algoritmo deriva dalla prima lettera dei cognomi di coloro che lo inventarono
nell’Aprile del 1977: Ronald L. Rivest, Adi Shamir e Leonard M. Adleman. I campi di impiego
dell'algoritmo sono diversi e variano passando dall'uso all'interno di programmi fino ad arrivare a
costituire l'elemento portante di vere e proprie tecnologie di rete. Fra le varie applicazioni possiamo
sicuramente ricordare: PGP; Secure Socket Layer (SSL); Secure Electronic Transactions (SET);
In linea di principio, l'analisi dell'algoritmo potrebbe essere facilmente suddivisa in due parti: la
generazione della coppia di chiavi e l'utilizzo delle stesse.
La prima parte, la generazione della coppia di chiavi, viene solitamente effettuata in questo modo:
vengono scelti due numeri primi p, q molto grandi di 512 bit (dell’ordine di 10 alla 155, più degli
atomi dell’universo); viene calcolato n=mod(pq), e la funzione di Eulero (n) = (p - 1)(q - 1)
dopo di che i due primi p, q vengono eliminati; si sceglie un intero e minore di (n) e primo con
esso; utilizzando la versione estesa dell'algoritmo di Euclide viene calcolato l'intero d così da avere
e * d = 1 mod (n); vengono resi pubblici i valori e,n che costituiscono la chiave pubblica e
mantenuto segreto d che, utilizzato con n rappresenta la chiave privata.
Cifratura: C = M elevato e mod n
Decifratura: M = C elevato d mod n
La determinazione di d è facile conoscendo p e q. La forza dell’algoritmo sta appunto nella
difficoltà di fattorizzare n, che è noto a tutti.
42
V. Casarosa – Tecnologie per il Commercio Elettronico
Pro e contro chiavi Pubbliche:
KDC
Ognuno si genera da solo la coppia di chiavi (le smart card possono generare la coppia di chiavi)
– Pubblicizza la chiave pubblica
– Custodicsce con cura la chiave privata (floppy, smart card)
AS TGS KDC=key distribution center
Nessuna necessità di scambiare informazioni con i propri corrispondenti.
Algoritmo di cifratura lento (circa 100 volte più lento rispetto a DES). AS = authentication service
Necessità di associare con certezza una chiave pubblica al corrispondente proprietario allora si 1 2 TGS= ticket granting service
ricorre a una Certification Authority (trusted third party) per il rilascio di “Certificati Digitali”, che 3
possono formare una Pubblik Key Infrastructure (PKI).
Client Server
– Documento di identità elettronico, firmato dalla CA
– Standard X509v3 (Standard più diffuso) 4
La chiave privata non esce mai dalle mani del “pricipal”. La sicurezza del caveau rientra nelle
normali misure di sicurezza di una banca. Commento sulla sicurezza: di solito bisogna badare di più 1) client, server, nonce.
all’interno che all’esterno. Il client chiede all’Autentication Service un “ticket” per accedere al server “server”. Le
La PKI è una struttura ad albero che autorizza altre CA figlie a rilasciare certificati. Si ritorna al informazioni (client, server e nonce) sono tutte in chiaro. Il nonce serve a evitare il replay.
solito concetto della catena d fiducia. Se mi fido del CA padre, e la chiave pubblica di CA1 (che
magari non conosco) viene certificata su un certificato firmato da CA, da allora in poi posso 2) {Kc-s, n} Kc, {Tc-s} Ks - Tc-s = c, s, n, Kc-s, expir. date.
accettare tutti i certificati firmati da CA1, ecc. AS ha un data base di chiavi (segrete) e recupera le chiavi del client e del server. Genera random
L’applicazione di una cifratura assimetrica prende il nome di firma elettronica, in quanto al pari di una chiave di sessione da usare col server e la manda criptata con la chiave del client. Manda anche
una firma (e anche più) garantisce autenticità e integrità. Poiché la cifratura di tutto il messaggio e il ticket per il server, criptato con la chiave del server.
in genere molto lunga si usa cifrare il cosiddetto Digest (riassunto) del messaggio, generato tramite
una funzione Hash, ovvero Digest = Hash(m). La codifica del digest può essere fatta con la chiave 3) {Ac} Kc-s, {Tc-s} Ks
privata, oppure con un qualsiasi “segreto” condiviso con il destinatario. Il destinatario verifica la Il client manda al server un “authenticator” (che include anche un time stamp), criptato con la
firma generando ex-novo il digest e confrontandolo con la firma decifrata. chiave di sessione, e il ticket. Notare che il client può recuperare la chiave di sessione solo se
La funzione Hash genera una stringa di lunghezza prefissata, facile da calcolare, tale che: dato conosce Kc (generalmente derivata da una password)
H(m), impossibile trovare m (non reversibile); dato m, “impossibile” trovare m’ per cui H(m) =
H(m’); impossibile trovare m e m’ per cui H(m) = H(m’); cambiando anche un solo bit di m, 4) {As} Kc-s
cambia H(m). Gli algoritmi di hash sono in sostanza una cifratura, in cui il risultato della cifratura Il server recupera Kc-s dal ticket, verificare l’autenticator e, se richiesto, manda al client il suo
di un blocco viene poi “combinato” con il blocco successivo (funzione di compressione). authenticator, criptato con la chiave di sessione. Notare che il server può recuperare la chiave di
Message Authentication Code (MAC): Se il valore iniziale è “un segreto” che solo io conosco, sessione solo se conosce Ks
allora il digest (MAC) vale anche come autenticazione. Altrimenti se voglio firmare con chiave
privata, si può metter il valore iniziale a tutti zeri o tutti uni.
KDC
blocco blocco
valore n bit n bit
iniziale digest AS TGS
k bit Funzione di k bit Funzione di MAC
3 4
compressione compressione 1 2
5
Funzione di compressione con due input (k bit e n bit, k< n) e un output di k bit Client Server
Operazioni di XOR, permutazioni e shift su blocchi di n bit, usando i k bit come “chiave” 6
MD5 (molto veloce, blocco di 512 bit, digest di 128 bit)
SHA-1 (più sicuro, blocco di 512 bit, digest di 160 bit) Per evitare di usare continuamente Kc, si utilizza TGS
1 e 2 sono come prima, dove il server prescelto è il TGS
Kerberos: è un protocollo di rete per l'autenticazione tramite crittografia che permette a diversi Dopo il 2, il client decodifica e memorizza la chiave di sessione con il TGS, memorizza il TGT
terminali di comunicare su una rete informatica insicura provando la propria identità e cifrando i (Ticket-Granting Ticket), e poi può “buttare via” Kc (la chiave segreta)
dati. Kerberos previene l'intercettazione e i replay attack, e assicura l'integrità dei dati. I suoi Al 3 il client chiede al TGS un ticket per il server “server”, fornendo il TGT
progettisti mirarono soprattutto ad un modello client-server, e fornisce una mutua autenticazione — Al 4 il client riceve la chiave di sessione con il server, e il ticket per accedere al server
sia l'utente che il fornitore del servizio possono verificare l'identità dell'altro. Il 5 e 6 sono come il 3 e 4 di prima
Kerberos si basa sulla crittografia simmetrica e richiede una terza parte affidabile, nello specifico
sarà il KDC Key Distribution Center. Tornando ai Web Services, abbiamo già detto che SLL o https non garantisocno la sicurezza end-
to-end. WSS si propone di definire specifiche per avere sicurezza (nei messaggi SOAP) inventando
il meno possibile, ovvero garantire l’autentificazione e la segretezza sfruttando le tecnologie
standard ed esistenti (XML signature, XML Encryption, SOAP Headers).

43 44
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
Tutti i concetti affrontati sino ad ora, riguardo la firma elettronica, li ritroviamo all'interno di XML parametri necessari per ottenere una chiave di sessione simmetrica a partire da chiavi pubbliche e
Signature, la tecnologia che permette di "firmare" documenti XML o parti di essi, garantendone private vedi esempio algoritmo di seguito.
l'autenticità e l'integrità. Per creare la firma digitale di un documento XML viene utilizzato il suo
digest. Abbiamo detto che la funzione utilizzata per calcolarne il valore è molto sensibile alle
variazioni del documento e quindi al fine di garantire il corretto funzionamento del meccanismo
della firma digitale, il digest deve essere generato utilizzando la forma canonica del documento
XML. L’elemento che viene di fatto firmato (digest + encryption) è sempre “signed info” (il quale
contiene in chiaro i digest di tutti i pezzetti che si vogliono firmare). La validazione consiste di due
passi:
1) Validare il digest di ogni “reference” contenuta in “signed info”
2) Validare la firma su “signed info”
Notare che “key info” è opzionale (ci potrebbero già essere accordi out-of-band tra il signer e il
destinatario) ed è fuori “signed info”. Se si vuole proteggere, basta mettere una “reference” a “key
info” dentro “signed info”. Notare infine che “signature” può avere tre forme
Detached: le info da firmare stanno fuori di “signature”;
Enveloping: le info da firmare stanno dentro “signature” (ma fuori di “signed info”) ;
Enveloped: “signature” sta dentro le info da firmare (in questo caso l’elemento “signature” viene
rimosso dall’elemento da firmare prima di calcolare il digest, e quindi la firma).

In XML il problema della sicurezza è affrontato dalla specifica di XML Encryption, una
tecnologia in grado di proteggere un documento XML o parti di esso. XML Encryption permette di
cifrare gli elementi di un documento XML utilizzando i più diffusi algoritmi di crittografia, sia a
chiave simmetrica che a chiave pubblica. In sistema a chiave simmetrica il dato viene codificato
utilizzando la stessa chiave sia per la codifica sia per la decodifica e questo impone che entrambe
l'applicazioni che scambiano i dati conoscano la chiave per poterli decodificare correttamente. In un
algoritmo a chiave pubblica sono presenti due chiavi tra loro correlate: una pubblica (che può
essere tranquillamente divulgata) ed una privata (che deve essere tenuta segreta). In questo sistema
ogni codifica fatta con una chiave può essere decodificata solamente con l'altra chiave; quindi per
proteggere i dati da inviare ad una determinata persona è sufficiente utilizzare la chiave pubblica ad
essa associata. In questo modo ho la sicurezza che solo quella determinata persona potrà
decodificare i dati visto che è l'unica a conoscenza della chiave privata.
È possibile criptare: un intero documento XML, un singolo elemento di un documento XML, solo i
contenuti di un elemento XML, dati non XML (es. un’immagine jpeg), i dati già criptati (super-
encryption). Il W3C ha definito anche specifiche di Encryption, con le quali si può criptare “tutto”.
Le specifiche dicono che è tutto opzionale, eccetto (ovviamente) il “CipherData”. Si può infatti
supporre che tutte le altre informazioni siano note out-of-band. Encryption method è ovvio;
“EncryptedData” viene messo al posto dei dati criptati. RetrievalMethod punta a dove si trovano le
informazioni per recuperare la chiave. AgreementMethod serve a specificare l’algoritmo e i
L'algoritmo Diffie-Hellman risale al 1976 ed è quindi uno dei più antichi algoritmi a chiave
pubblica; gli autori furono anche i primi a proporre l'idea dei cifrari a chiave pubblica.
L'algoritmo è particolarmente adatto alla generazione di una chiave segreta tra due corrispondenti
che comunicano attraverso un canale non sicuro (pubblico). La sua sicurezza si basa sulla
complessità computazionale del calcolo del logaritmo discreto.
Supponiamo di avere i soliti Aldo e Bruno che vogliono scambiarsi una chiave segreta in modo
sicuro. Aldo genera e comunica pubblicamente un numero primo N molto elevato (p.es. 1024 bit,
circa 300 cifre decimali) e un generatore g (che esiste sicuramente essendo N primo); si potrebbero
anche usare due numeri N e g pubblicati da un qualche ente.
A questo punto:
1. Aldo genera un numero casuale a < N e calcola A = ga mod N. Il numero A viene
comunicato pubblicamente a Bruno.
2. In modo del tutto analogo Bruno genera due numeri b e B = gb mod N e invia B ad Aldo.
3. Aldo calcola il numero k = Ba mod N.
4. Bruno calcola k = Ab mod N.
Inutile aggiungere che le due chiavi k sono uguali! Infatti entrambe valgono gab mod N.
A questo punto Aldo e Bruno possono usare la chiave per comunicare con un cifrario simmetrico
p.es. il DES.
Se viene criptato un intero file, il documento xml consiste solo dell’elemento “EncryptedData”.
L’attributo “MimeType” dice di che documento si tratta. Il metdo di criptazione è a chiavi
simmetriche, cioè AES a 128 bit, cob Cipher Block Chaining. Le informazioni sulla chiave si
limitano a dare il “nome” della chiave (cioè dicono chi sono io mittente), in quanto essendo una
chiave simmetrica si suppone che questo basti a individuare il “segreto condiviso”.
Se viene criptato un intero elemento (semplice o complesso che sia), nel nostro caso tutto il body
del messaggio SOAP, si avrà:

45 46
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
 - request/response protocol: definisce come si richiedono e ricevono le assertion. SAML supporta
messaggi SOAP su HTTP in questo momento, ma in futuro saranno supportati altri meccanismi di
trasporto;
- bindings: fornisce i dettagli esatti su come le richieste SAML devono essere mappate nei
protocolli di trasporto, come SOAP su HTTP;
- profili: sono le istruzioni su come inserire o trasportare le assertion SAML tra sistemi di
comunicazione diversi;

Abbiamo poi i due partecipanti:

– Asserting party (SAML Authority): il sistema, o il dominio amministrativo, che easserisce
informazioni su un soggetto.
– Relying party: sistema, o il dominio amministrativo, che si affida alle informazioni
acquisite sul soggetto tramite l’ asserting party.

Se viene invece criptato il contenuto di un elemento a differenza del caso precedente, il nome
dell’elemento sarà in chiaro. Se non si vuole far vedere di quale elemento si tratta, (ad es. metodo di
pagamento carta credito o bank transfer) si deve quindi usare la cifratura dell’elemento.
La struttura di “EncryptedKey” è sostanzialmente come “EncryptedData” (le specificiche
definiscono un solo abstract type), solo che il dato criptato deve essere una chiave ad esempio la
chiave simmetrica dell’algoritmo AES128 . È utile quando si vuole fornire una chiave di sessione
con la quale sono stati criptati i dati veri e propri..
Il processo di decriptazione non presenta novità:
1. Estrae e decifra il contenuto dell’elemento CypherValue.
2. Legge l’algoritmo utilizzato dal valore dell’attributo dell’elemento EncryptionMethod.
3. Legge il tipo del dato dal valore dell’attributo dell’elemento EncryptedData.
4. Ottiene informazioni sulla chiave dall’elemento KeyInfo.
5. Usa le informazioni acquisite nei passi precedenti per costruire il testo in chiaro.

Vediamo ora come si può mettere tutto insieme (autenticazione, firma e criptazione) usando
l’elemeto Security (definito da WSS) ovvero l’Header Block Security. La parte principale è quella
di definire un “security token”, che può essere binario (come sopra) o human readable (come
username e password).Il resto è riconducibile a quanto visto sopra. Viene definito anche un
elemento Reference per puntare al security token. Per fornire l’autenticazione viene utilizzato il
certificato X509, che viene anche usato per firmare il contenuto del Body.
Il Security Assertion Markup Language (SAML) è un insieme di specifiche per lo scambio di
informazioni, basate su XML, riguardanti autenticazione e sicurezza (' assertion') degli utenti
(Raccomandazione OASIS).
Lo standard SAML definisce un framework per scambiare in sicurezza informazioni (assertion)
online tra business partner. SAML è stato ideato per funzionare sui meccanismi di trasporto più
comuni, come HTTP, SMTP, FTP e alcuni framework XML, tipo SOAP ed eb-XML. Fornisce un
metodo standard per definire l'autenticazione dell'utente, le autorizzazioni e gli attributi all'interno
di un documento XML. Le componenti principali sono:
SAML in un messaggio SOAP Risposta SAML
Il Single sign-on (SSO, traducibile come autenticazione unica o identificazione unica) è un sistema
specializzato che permette ad un utente di autenticarsi una sola volta e di accedere a tutte le risorse
informatiche alle quali è abilitato.
Gli obiettivi sono multipli:
x semplificare la gestione delle password: maggiore è il numero della password da gestire,
maggiore è la possibilità che saranno utilizzate password simili le une alle altre e facili da
memorizzare, abbassando così il livello di sicurezza;
x semplificare la gestione degli accessi ai vari servizi;
x semplificare la definizione e la gestione delle politiche di sicurezza.
Vediamo ora alcuni esempi nelle pagina successiva:

- assertion: ce ne sono di tre tipi diversi, ma sono sempre dichiarazioni di fatti riguardanti l'utente,
sia esso una persona fisica o un computer. Le assertion di autenticazione richiedono che un utente
provi la propria identità. Gli attributi (attribute assertion) contengono i dettagli specifici dell'utente,
come la nazionalità o il tipo di carta di credito. I permessi (authorization decision assertion)
identificano invece quali operazioni un utente può compiere (per esempio autorizzazioni all'acquisto
di un bene);

47 48
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
 Source site first (artifact - pull)
Source site first (POST form – push)
Destination site first
49
V. Casarosa – Tecnologie per il Commercio Elettronico
Nel B2B spesso le parti hanno già relazioni di affari e non c’è bisogno di fare pagamenti via
Internet. Ci sono Tre modelli (evoluzione temporale) di Pagamento Elettronico:
Nel primo il Trusted Third Party agisce come “proxy” della carta di credito. Ad es. First Virtual ha
creato il “Virtual PIN”, che è quello che gira in rete non criptato. Il client dà il VP al merchant, che
lo manda a First Virtual, che manda una email al client chiedendo conferma. Quando il client
risponde, il First Virtual da l’OK al merchant. Non è più utilizzato nel business (ad oggi è sicuro
mandare in giro anche il numero di carta di credito)
Il secondo è quello classico, il più diffuso oggi:
Il modello classico coinvolge tanti attori e tante transazioni
1. Il Consumer invia i dati della carta di credito al merchant.
2. Il merchant invia i dati alla sua banca.
3. La banca del merchant chiede di validare i dati alla banca del consumer.
4. La banca del consumer manda la validazione dei dati alla banca del merchant.
5. La banca del merchant invia conferma al merchant
6. Il merchant conferma l’aqcuisto al consumer
7. Il merchant chiede alla sua banca di accreditare la somma.
8. la banca del merchant chiede l’accredito della somma alla banca del consumer.
9. La banca del consumer effettua il pagamento sul conto del merchant.
10. La banca del merchant conferma l’avvenuto pagamento al merchant.
Tutte le transazioni in rete devono essere sicure (autenticare i due attori e criptare i messaggi).
SET (Secure Electronic Transactions) è il primo e più diffuso, spinto da VISA e Mastercard.
Notare comunque che la sicurezza in rete è “il male minore”. I tanti casi di compromissione delle
CC sono avvenuti quasi tutti sui siti dei merchant,
Il terzo è il più innovativo, ma non è ancora decollato
z Rilevante essenzialmente per B2C
z Trusted Third Party
– Ha le informazioni riservate (conto bancario, carta di credito, ecc.) di “tutti”
(compratori e venditori)
– Le informazioni scambiate contengono solo i dati della transazione
– Criptazione non necessaria
– Transazioni finanziarie fatte da TTP
– Utilizzo del First Virtual
z Electronic Fund Transfer
– Trasposizione on line del sistema classico a carta di credito
– Le informazioni devono essere criptate
– SET, CyberCash (VeriSign)
z Digital Cash (Electronic Money)
– Ciò che viene trasferito è “il denaro” stesso
– si utilizza il Digital Cash
Qualcuno ha detto che il denaro elettronico “è una splendida idea il cui momento non è ancora
giunto”. Interesse dei Governi. (ad es. se creiamo e-cash in aggiunta a quello vero, devono entrarci
anche le Banche Centrali).
I pro del digital cash sono due
z Centinaia di anni per passare dal baratto all’oro, poi alla carta moneta, poi agli assegni
z Denaro elettronico creato (in genere) a fronte di denaro reale
z Alternativa alle carte di credito (costo di gestione più basso)
z Micropagamenti
– Giornali e riviste
– Musei
– Servizi on line
50
V. Casarosa – Tecnologie per il Commercio Elettronico
Digital cash Bob firma x (valore mascherato) e non ha modo di sapere il valore di m.
Notare che tutta la faccenda dell’anonimo è dovuta alla perdita di privacy data da Internet. Dato il modo in cui ho trovato r, e il modo con cui ho mascherato m, basta che poi io divida la firma
In teoria il denaro vero non è anonimo (numero di serie) ma in pratica è impossibile fare un adit t del valore mascherato per avere la firma di m.
trail (vedi a suo tempo i sequestri). Ecco le differenze tra una transazione online e offline:
Identified Anonymous z m = Alicès message to be signed by Bob
On-line -Requires bank -Requires bank z (n,e) = Bob's public key
z (n,d) = Bob’s private key.
-Known cash -Unknown cash z gcd(r, n) = 1 (r random generated by Alice)
withdrawer withdrawer z x = (re m) mod n sent to Bob (m is blinded)
z t = xd mod n to Alice (x signed by Bob)
-Audit trail created -No audit trail created z xdº (re m)d º r md mod n,
Off-line -No bank required -No bank required z s = r--1 t mod n (true signature of m)
-Known cash -Unknown cash E-cash anonimo con numero di serie
withdrawer withdrawer Vediamo di utilizzare la blind segnature. Utilizziamo radice e potenza come surrogati più chiari da
-Audit trail created -No audit trail created spiegare e capire rispetto alla matematica vera di RSA.
Un “banconota” è data da x (numero di serie) e dalla firma di un hash di x da parte della banca.
Vediamo (per curiosità) alcuni aspetti tecnici, intorno alla “blind signature” Si usa l’hash per evitare che io (furbo) mi generi “denaro falso”. Infatti se spaccio come e-cash (y3,
y), questo viene preso per buono dato che in questo caso la “firma” è y, e la verifica della firma
E-cash anonimo (elevamento al cubo) dà proprio il numero di serie.
Vediamo (a piccoli passi) come si possa utilizzare la blind signature per avere e-cash anonimo Alice maschera l’hash di x e lo fa firmare alla banca.
Primo caso semplice (anche troppo) Alice ricostruisce la sua “banconota” elettronica e la spende.
Abbiamo l’anonimità, ma non possiamo evitare il double spending (spendere di nuovo lo stesso La banca può controllare il double spending, ma non sa che il compratore è Alice.
denaro). Bob deve essere on line.
z Utilizziamo radice cubica e elevamento al cubo come “surrogati” più chiari di criptazione
z e-cash è una sequenza di bit con chiave privata (1/3) e decriptazione con chiave pubblica (3)
z Alice apre un conto in banca z e-cash = (x, f(x)1/3)
z La banca dà ad Alice un “certificato” firmato (dalla banca) del valore di x Euro z f(x) usato per evitare e-cash falso = (y3, y)
z Alice dà il certificato a Bob (esegue un acquisto) z Alice genera un valore x random (numero di serie), calcola f(x) e lo maschera con un
z Bob verifica la firma del certificato numero r random
z Bob dà l’acquisto ad Alice z Alice manda alla banca r3*f(x)
z e-cash anonimo (tutti i certificati sono uguali) z Alice riceve dalla banca r*f(x)1/3 (messaggio firmato)
z Problema di double-spending z Alice ottiene e-cash firmato (x, f(x)1/3) dividendo per r
z e-cash anonimo e con numero di serie (la banca non ha mai visto
E-cash con numero di serie (non anonimo) x e f(x))
Aggiungiamo un numero di serie. Se Bob è on line non è possibile double spendine. Alice non è più z Alice spende e-cash da Bob
anonima (per la banca) perchè sa quali numeri di serie ha avuto z Bob verifica la firma e chiama la banca (per evitare double spending)
z Problema che Bob deve essere on line con la banca
z Alice apre un conto in banca
z La banca dà ad Alice un “certificato” firmato del valore di x Euro, contenente anche un Double spending – Passo 1
numero di serie E-cash anonimo spendibile off-line
z Alice dà il certificato a Bob (esegue un acquisto) Vedremo tra poco come fa Alice ad avere l’e-cash firmato, supponiamo per ora che ce l’abbia e lo
z Bob verifica la firma del certificato spenda, seguendo un rituale complicato:
z Bob chiama la banca e verifica che quel numero di serie non sia già stato speso (la banca
registra i numeri di serie spesi) z e-cash = prodotto di k/2 numeri
z Bob dà l’acquisto ad Alice z ogni numero = f(xi,yi)1/3, con i che va da 1 a k/2
z Problema di anonimità z xi = g(ai, ci), ai e ci random
z Problema che Bob deve essere on line con la banca z yi = g(ai XOR <info>, di), di random
z f e g funzioni hash
Blind Signature z <info> contiene informazioni che identificano Alice
Il problema si pone quando voglio far “firmare” una banconota elettronica dalla banca, ma voglio z Notare che facendo XOR di ai e (ai XOR <info>) si ottiene <info>
anche che la banca non possa collegare la banconota a me che sto chiedendo di firmarla. z Alice spende e-cash da Bob
Il trucco sta nel far firmare un valore di m “mascherato” in modo tale che io possa poi operare sulla z Bob genera random k/2 bi, con b = 0 oppure b = 1
firma del valore mascherato per ottenere la firma di m. z se bi = 1, Alice fornisce ai, ci, yi
z se bi = 0, Alice fornisce (ai XOR <info>), di, xi
51 52
V. Casarosa – Tecnologie per il Commercio Elettronico V. Casarosa – Tecnologie per il Commercio Elettronico
 z Bob può calcolare f(xi, yi) e verificare la firma della banca
z In nessun caso Bob può conoscere <info>
z Prima o poi Bob manda il tutto (e-cash e risposte di Alice) alla banca

Double spending – Passo 2

Se Alice spende un’altra volta lo stesso e-cash, ci sono buone probabilità che per qualche i (i che va
da 1 a k/2) il bit random generato da Charlie sia diverso da quello generato da Bob, e quindi Alice
fornisce la risposta “complementare”.
Quando la banca fa lo XOR, salta fuori <info> e Alice viene pizzicata.
La domanda (spontanea) è: se la banca deve firmare senza sapere cosa firma, come fa a sapere che
le info sono quelle giuste ?

z Alice (disonesta) spende e-cash da Charlie

z Charlie esegue la stessa procedura di Bob
z Charlie ottiene una serie (random) di ai e (ai XOR <info>)
z Prima o poi Charlie manda il tutto alla banca
z La banca si accorge che ha già ricevuto questo e-cash da Bob
z La banca fa lo XOR delle risposte date da Alice a Bob e a Charlie
z La banca ottiene (probabilisticamente) <info> e quindi l’identità di Alice

Blind signature di e-cash

Anche qui si fa ricorso alle probabilità. Se Alice tenta di barare su un numero consistente di f(xi,
yi), ci sono buone probabilità che la banca la pizzichi subito, perchè qualcuna delle f con
informazioni fasulle finisce tra quelle non firmate, e quindi info viene visto (la banca riceve r, e può
“smascherare” info)

z La banca non deve conoscere <info> a meno di double spending

z Prima di firmare, la banca deve essere “sicura” che e-cash contiene le <info> giuste (cioè di
Alice)
z Alice genera k valori f(xi, yi), con i che va da 1 a k
z Alice manda alla banca k valori f(xi, yi)*ri3, con i che va da 1 a k
z La banca sceglie random k/2 valori e li restituisce ad Alice firmati
z Alice genera il suo e-cash
z Alice manda alla banca i k/2 valori di ri associati alle f(xi, yi) che non sono state firmate
z La banca verifica che dentro le f(xi, yi) ci siano le <info> giuste

Ant è un software per l'automazione del processo di build. È simile a make ma scritto in Java ed è
principalmente orientato allo sviluppo Java. Ant è un progetto Apache, open source, ed è rilasciato
sotto licenza Apache. Esso si basa su script in formato XML.
Ogni build file definisce un project composto da target in cui sono elencati i task, le istruzioni da
eseguire. Nel progetto possono essere definite delle properties, coppie nome e valore
immodificabili nel resto del progetto. I target possono avere delle dipendenze da altri target.
La principale caratteristica di ant è la portabilità; per esempio comandi strettamente dipendenti dalla
piattaforma come rm –rf classes sono semplicemente eseguiti indipendentemente dalla
piattaforma dal comando <delete dir="classes"/> del target clean.
Una discrepanza comune tra le varie piattaforme è il modo in cui il path delle directory è
specificato. UNIX usa un forward slash (/) per delimitare i componenti di un path, a differenza di
Microsoft Windows che usa un backslash (\). La sintassi ant lascia libero l'autore del codice di usare
una convenzione qualsiasi, back/forward slash per le directory, punto e virgola o due punti (; o :)
per i separatori dei path (classpath). Ant converte tutto nella forma più appropriata alla piattaforma
corrente. Ant viene eseguito da riga di comando e la sintassi del comando è sempre a disposizione
eseguendo il comando: ant –help.
Tipicamente viene usato nel modo seguente:
ant –buildfile <build_file>.xml D <proprieta1>=<valore1>–D<proprieta2>=<valore2>
<target1> <target2>
53
V. Casarosa – Tecnologie per il Commercio Elettronico