Introduzione
2
amministrazione, sia al fatto che ogni Peer fornisce, ad altri membri della comunità,
l’accesso a risorse presenti sul proprio computer.
Alla luce dell’importanza che sta assumendo il P2P Computing, si è deciso di
sviluppare un software conforme a questa architettura, in grado di permettere la
distribuzione di software OpenSource. Inoltre questo stesso software deve essere a sua
volta distribuito con licenza OpenSource.
Affinchè un software si possa dire OpenSource (OS) a tutti gli effetti non è
sufficiente che chi lo sviluppa metta a disposizione il codice sorgente, ma, secondo la
definizione stessa di OS [34], la licenza di rilascio del sorgente deve contenere
clausole esplicitamente rivolte a garantire l'integrità del codice distribuito, la libera
redistribuzione dello stesso, l'assenza di ogni forma di discriminazione verso singoli o
gruppi e anche riguardo ogni possibile utilizzo del software stesso. Per favorire la
diffusione di questa tipologia di software esistono sia un'organizzazione, l'Open
Source Iniziative [49], sia varie licenze adottate da diversi produttori (ad esempio
Netscape [50]) pronte per l'uso.
I vantaggi di una simile modalità di sviluppo sono legati ai seguenti fattori:
• la grande stabilità di ciò che si produce e distribuisce è dovuta al fatto che, di
norma, un gran numero di sviluppatori e di beta-tester sparsi in tutto il mondo
riescono a eliminare i bug e ad assicurare uno sviluppo omogeneo assai meglio di
pochi sviluppatori concentrati all'interno della stessa software house;
• gli sviluppatori OS, potendo riutilizzare e adattare ai propri scopi i sorgenti
sviluppati da altri, hanno molte più risorse da dedicare alle caratteristiche
specifiche e innovative del proprio progetto.
Inoltre sviluppare un software OS non vuol dire distribuirlo esclusivamente in
forma gratuita, nulla vieta, infatti, di commercializzare il proprio prodotto fornendo,
con esso, servizi a valore aggiunto quali manuali o servizi di supporto all’installazione
e all’utilizzo: è questa la via, ad esempio, seguita dalle software house RedHat [51] e
Mandrake [52] per le rispettive distribuzioni del sistema operativo Linux.
Introduzione
3
Il tool sviluppato in questo lavoro di tesi deve, inoltre, fornire adeguati strumenti di
ricerca tra i software OpenSource disponibili all’interno della propria comunità
virtuale: è necessario, pertanto, organizzare tali software secondo modelli precisi e
rigorosi. Sono stati quindi individuati i seguenti tre distinti criteri di classificazione:
• secondo un modello commerciale che descriva la tipologia d’uso del software
distribuito (es. utility di sistema, gioco, editor);
• secondo un modello architetturale che descriva l’architettura computazionale
del software distribuito (es. 2-Tier, 3-Tier);
• secondo un sottinsieme delle componenti che costituiscono un business model.
Il lavoro di tesi svolto si articola nei seguenti capitoli:
• Capitolo 1. I Modelli Architetturali: analizza i tre diversi modelli di
catalogazione del software e, per ogni modello, viene formulata una propria
proposta;
• Capitolo 2. Architetture Peer-to-Peer: analizza le architetture Peer-to-Peer
esistenti su cui basare il successivo sviluppo del tool;
• Capitolo 3. Politella: Progetto Architetturale: analizza le scelte architetturali
fatte per sviluppare il tool;
• Capitolo 4. Politella: Manuale Utente: analizza il funzionamento del tool;
• Appendice A. Diagrammi delle Classi: riporta i diagrammi UML delle classi
implementate per sviluppare il tool;
• Appendice B. Scenari di Interazione: riporta i diagrammi UML degli scenari di
interazioni tra le classi che compongono il tool sviluppato.
I Modelli Architetturali
4
1. I Modelli Architetturali
1.1. Introduzione
Chiunque voglia distribuire del software, sia esso un negozio, un sito specializzato
o un più semplice sito amatoriale, deve organizzare il materiale a propria disposizione
secondo alcuni precisi criteri. Ciò è necessario non solo per facilitare il lavoro di
gestione e organizzazione di tutti i programmi da parte di chi si occupa di tale
distribuzione, ma, anche, per facilitare e accelerare le ricerche di chi fosse interessato
ad un particolare software.
In questo lavoro di tesi, il cui obiettivo è l’implementazione di un tool in grado di
permettere la distribuzione on-line di programmi per calcolatore, si è deciso di
classificare il software seguendo tre criteri distinti:
• secondo un business model;
• secondo un modello architetturale;
• secondo un modello commerciale.
Nei paragrafi successivi, quindi si analizzano alcuni business model esistenti
(paragrafo 1.2) per poi definirne uno proprio, si analizzano i modelli architetturali
esistenti presentando per ognuno di questi degli esempi esplicativi (paragrafo 1.3), ed
infine, facendo riferimento ad alcuni siti Web specializzati nella distribuzione di
software, si analizzano i modelli commerciali esistenti (paragrafo 1.4).
I Modelli Architetturali
5
1.2. Business Model
Nel riferimento bibliografico [11] un business model è descritto nel seguente
modo:
“A business model shows the essentials (the strategic intent) of the way of doing
business in terms of stakeholders creating and exchanging objects of value with
each other”.
L’obiettivo principale di un business model, quindi, è quello di spiegare, anche
attraverso una rappresentazione grafica “who is offering what to whom and expects
what in return” ([11]), concentrando la propria attenzione sul concetto del valore
creato e scambiato tra i vari componenti del business model, senza però preoccuparsi
di come questi “objects of value” sono realmente creati.
Paul Timmers nel Cap. 3 di [1] e in [9] fornisce quest’altra definizione di business
model, simile alla precedente:
“Definition of a business model:
• An architecture for the product, service and information flows, including a
description of the various business actors and their roles; and
• A description of the potential benefits for the various business actors; and
• A description of the sources of revenues”.
I ricercatori dell’“Amsterdam Center of e-Business Research” Jaap Gordijn, Hans
Akkermans e Hans van Vliet, autori degli articoli [10] e [11], affermano che ogni
business model deve chiarire i seguenti punti:
• Who are the value adding business actors involved;
• What are the offerings of which actors to which other actors;
• What are the elements of offerings;
• What value-creating or adding activities are producing and consuming these
offerings;
• Which value-creating or adding activities are performed by which actors.
I Modelli Architetturali
6
Analizzando business model differenti si possono notare alcune caratteristiche
fondamentali comuni a tutti: ogni business model, infatti, deve essere composto da
uno o più business role e da almeno una business relationship tra questi business role.
Per business role s’intende ogni entità indipendente che prende parte al business
model e che può essere rappresentata da una singola persona, da una azienda, da un
componente software più o meno complesso, ecc..
Per business relationship, invece, s’intende la relazione d’interazione che intercorre
tra due business role differenti, oppure tra un business role e se stesso: può essere
costituita, ad esempio, dalla stipula di un contratto tra i due business role o dalla
fornitura di un particolare servizio.
Nel successivo paragrafo 1.2.1, si noterà che queste componenti fondamentali
possono assumere nomi differenti secondo il business model analizzato: ad esempio il
business role può essere indicato anche con il termine actor, oppure la business
relationship con value activity.
1.2.1. Alcuni esempi di Business Model
Di seguito si presentano in modo sintetico gli aspetti fondamentali di alcuni
business model che, singolarmente, sono stati utili per il successivo sviluppo di una
propria proposta di business model.
1.2.1.1. TINA Business Model
L’architettura TINA ([12] e [13]), il cui business model è riportato in Figura 1.1, è
stata definita e sviluppata dal Telecommunications Information Networking
Architecture (TINA) Consortium ([53]), un consorzio internazionale costituito da
numerosi operatori delle telecomunicazioni (tra cui Telecom Italia [54]) il cui fine è
realizzare un’architettura di tipo open adattabile ad ogni genere di sistema di
telecomunicazioni.
I Modelli Architetturali
7
Figura 1.1: TINA Business Model
All’interno di questo business model vengono definiti i seguenti business role (per
una trattazione completa si faccia riferimento a [13]):
• Consumer: chi ricopre questo ruolo utilizza semplicemente i servizi che gli
sono messi a disposizione. All’interno di un generico sistema di
telecomunicazioni, che ricalchi le specifiche TINA, chi ricopre questo ruolo può
essere sia una singola persona, sia una grossa azienda. Inoltre il numero di chi lo
ricopre può essere anche di alcuni ordini di grandezza superiore al numero di chi
ricopre tutti gli altri business role.
• Retailer: si occupa di fornire al Consumer i servizi che, di volta in volta, gli
vengono richiesti. Il ruolo di Consumer può essere svolto sia da piccole che da
grandi aziende. Ogni entità, che svolge il ruolo di Consumer, può utilizzare una o
più differenti entità Retailer contemporaneamente e per periodi di tempo lunghi o
brevi. Ogni Retailer può sviluppare propri servizi in modo completamente
indipendente da tutti coloro che in quel sistema TINA svolgono questo stesso
ruolo.
• Broker: il compito di chi svolge questo ruolo è permettere, ai vari business
role, l’individuazione all’interno del sistema sia dei servizi disponibili, sia di chi
ricopre gli altri business role. Il servizio fornito dal Broker è comparabile a quello
fornito dai motori di ricerca all’interno della rete Internet.
• Third party service provider: chi ricopre questo ruolo è in grado di fornire
servizi ai Retailer oppure ad altri Third party service provider. La differenza
principale tra il business role Retailer e Third party service provider è che
quest’ultimo non può avere alcuna relazione diretta con il Consumer, ma ciò non
impedisce che chi svolge questo ruolo possa, contemporaneamente, assumere
I Modelli Architetturali
8
anche quello di Retailer. Inoltre le business relationship esistenti tra Third party
service provider e Retailer e tra Retailer e Consumer dovrebbero essere differenti.
• Connectivity provider: chi ricopre questo ruolo garantisce il corretto
trasporto dei servizi all’interno di un sistema di telecomunicazioni aderente
all’architettura TINA. Il Connectivity Provider fornisce, ai Retailer e ai Third
party service provider, un’interfaccia attraverso cui ricevere le richieste di
connessione dei propri “acquirenti” di servizi (rispettivamente Consumer e
Retailer o Third party service provider).
Ogni entità che prende parte a questo business model e che, come si è visto, può
essere indistintamente una singola persona oppure un’azienda, piccola o grande, può
contemporaneamente ricoprire più ruoli.
Affinché i differenti business role appena descritti possano interagire tra loro, sono
definite le seguenti business relationship (per una trattazione completa si faccia
riferimento a [13]):
• Generic access inter business administrative domain interactions: è
un’interazione di tipo generico che permette una serie di operazioni comuni a
tutte le altre business relationship. Questo tipo di interazione deve essere la prima
ad aver luogo; le seguenti sono alcune delle interazioni che permette:
− istanziare il dialogo tra business administrative domain.
− identificare reciprocamente i business administrative domain coinvolti
nell’interazione.
− individuare ed avviare servizi.
• Retailer business relationship (Ret): è la business relationship definita tra chi
ricopre il ruolo di Consumer e di Retailer. Tra le interazioni che permette si
possono citare ad esempio:
− tutte le interazioni definite dalla Business Relationship Generic access
inter business administrative domain interactions.
− la scoperta e l’avvio di servizi di management e amministrativi.
• Broker business relationship (Bkr): permette l’accesso alle informazioni,
gestite dal Broker, relative a tutti gli altri business role del sistema (ad esempio il
Consumer usa questa business relationship per scoprire i Retailer disponibili,
oppure il Retailer per individuare a sua volta i Consumer oppure dei Third party
service provider). Tra le interazioni che permette si possono citare ad esempio:
I Modelli Architetturali
9
− tutte le interazioni definite dalla Business Relationship Generic access
inter business administrative domain interactions.
− la (de)registrazione dei servizi offerti e delle loro caratteristiche.
− la gestione delle informazioni in possesso del Broker.
• Third party business relationship (3Pty): permette al Retailer (o al Third
party service provider) di mettere a disposizione del Consumer servizi che non
possiede direttamente, ma che può acquisire dai Third party service provider. Tra
le interazioni che permette si possono citare ad esempio:
− tutte le interazioni definite dalla Business Relationship Generic access
inter business administrative domain interactions.
− tutte le interazioni definite dalla Business Relationship Ret.
• Retailer-to-Retailer business relationship (RtR): permette di estendere le
interazioni definite in 3Pty e Ret tra due Retailer.
• Connectivity service business relationship (ConS): permette al Connectivity
Provider di fornire un servizio di trasporto dei servizi (punto-punto o punto-
multipunto) ai business role che lo richiedono, solitamente Retailer e Third party
service provider. Tra le interazioni che permette si possono citare ad esempio:
− tutte le interazioni definite dalla Business Relationship Generic access
inter business administrative domain interactions.
− la gestione del servizio di connessione.
• Terminal connection business relationship (TCon): permette la gestione
delle connessioni tra Connectivity Provider e i business role Consumer, Retailer e
Third party service provider. Tra le interazioni che permette si possono citare ad
esempio:
− tutte le interazioni definite dalla Business Relationship Generic access
inter business administrative domain interactions.
− la parziale gestione delle impostazioni di una connessione.
• Layer network federation business relationship (LNFed): è un’interazione
di federazione tra Connectivity Provider differenti. Tra le interazioni che permette
si possono citare ad esempio:
− tutte le interazioni definite dalla Business Relationship Generic access
inter business administrative domain interactions.
− la gestione delle connessioni tra Connectivity Provider.
Come si vede nella Figura 1.2, estratta da [26], singoli business role o più business
role insieme possono costituire dei business administrative domain; questi
interagiscono gli uni con gli altri attraverso dei reference point, che sono le
I Modelli Architetturali
10
implementazioni delle business relationship. Poiché tra due business administrative
domain distinti vi deve essere un solo reference point, al suo interno, eventualmente,
devono confluire tutte le funzionalità descritte dalle differenti business relationship
esistenti tra i business role appartenti a business administrative domain: ad esempio,
nella Figura 1.2, all’interno del reference point A confluiscono le funzionalità sia
della business relationship a (tra business role 1 e business role 2), sia della business
relationship b (tra business role 1 e business role 3).
Figura 1.2: Business Administrative Domain e Reference Point
1.2.1.2. Value Added Web Business Model
Il documento [14] descrive il Value Added Web Business Model, adatto per
l’implementazione di servizi web e basato in parte sul TINA Business Model descritto
nel paragrafo precedente.
L’utilizzo di questo business model, schematizzato in Figura 1.4, permette di
fornire i normali servizi web in modo trasparente per l’utente finale, ma fornendo
anche una certa Quality of Service.
Il VAW Business Model è il risultato dell’applicazione del TINA Business Model
al business model per il WWW riportato in Figura 1.3.
I Modelli Architetturali
11
Figura 1.3: WWW Business Model
In questo business model, ogni End-user possiede una business relationship con un
Internet Service Provider (ISP) per ottenere l’accesso alla rete Internet e ai servizi su
di essa disponibili, come ad esempio il WWW.
La business relationship tra l’ISP e il Content Provider permette a quest’ultimo di
ottenere l’accesso alla rete Internet e di fornire agli End-user i propri servizi web.
Tra ISP, inoltre, esistono altre business relationship grazie alle quali si forma la
rete Internet stessa.
Con questo business model, però, non è possibile fornire garanzie di Quality of
Service (QoS) agli End-user, perché l’ISP non possiede alcun meccanismo per
realizzare connessioni di tipo End-to-End tra un Content Provider e un End-user.
Ogni End-user può, autonomamente, istanziare delle connessioni dirette con ogni
Content Provider di proprio interesse o, in alternativa, questa connessione può passare
attraverso un intermediatore: il business role Portal/Community.
Un Portal può essere utilizzato dagli End-user come punto di partenza per
raggiungere i Content Provider più vicini ai propri interessi. Spesso un Portal è anche
in grado di mettere in contatto più End-user con interessi simili, creando così una
Community.
Combinando assieme le caratteristiche del WWW Business Model con quelle del
TINA Business Model (in una versione semplificata che non prevede la presenza del
I Modelli Architetturali
12
business role Broker) si può ottenere il VAW Business Model schematizzato, come
già detto, in Figura 1.4.
Figura 1.4: VAW Business Model
L’elemento essenziale di questo business model è la presenza di un Retailer, un
business role intermedio tra End-User, Content Provider e Connectivity Provider.
Il Connectivity Provider fornisce l’accesso alla rete Internet e la reciproca
interconnessione a tutti gli altri business role presenti in questo modello.
Il Provider non solo fornisce i tradizionali contenuti web, ma anche altri servizi
web a valore aggiunto (Value Added Web), quali garanzie di Quality of Service o
servizi a particolari condizioni di connessione (ad esempio un filmato di tipo MPEG
viene fornito ad un End-user solamente se l’ampiezza di banda della connessione a
disposizione di quest’ultimo è sufficiente).
Il Retailer, unico business role ad avere una relazione diretta con tutti gli altri
business role del modello, si occupa di far sottoscrivere agli End-user e gestire i
contratti di accesso ai servizi forniti dal Content Provider. Il Retailer, inoltre, è
responsabile di comunicare al Connectivity Provider i requisiti di QoS richiesti da un
End-user per l’accesso ai servizi.
I Modelli Architetturali
13
1.2.1.3. UMTS Business Model
Presso il sito web dell’European Institute for Research and Strategic Studies in
Telecommunications (EURESCOM) ([61]), un centro di ricerca specifico per le
telecomunicazioni (costituito nel 1991 da venti operatori delle telecomunicazioni
europei, tra i quali anche la Telecom Italia), è possibile reperire gli articoli [15] e [16]
al cui interno è descritto l’UMTS Business Model schematizzato in Figura 1.5.
User
Network
Operator
Subscriber
Service
Provider
Value Added
Service Provider
Subscription-Subscriber
Profile Management
Billing
Delegation of
Service Usage
User Service Profile
Management
Delegation
of Service
Provision
Accounting
Usage
Payment
Payment
Billing
Billing
Payment
Usage
Payment
Payment
Figura 1.5: UMTS Business Model
In questo modello sono definiti i seguenti business role:
• Subscriber: questo business role identifica una persona fisica o un'altra entità
che possiede, con un Service Provider, una relazione contrattuale per la fornitura
di servizi ad uno o più business role User. Il Subscriber si occupa anche di pagare
al Service Provider, con cui ha stipulato un contratto, i servizi di cui usufruisce.
• User: questo ruolo identifica una persona, o un’altra entità, autorizzata da un
Subscriber ad utilizzare i servizi per cui quest’ultimo ha sottoscritto un contratto
con il Service Provider.
• Service Provider: questo business role si occupa di fornire un servizio o un
gruppo di servizi agli User che li hanno richiesti attraverso la sottoscrizione di un
contratto tra il Service Provider e il Subscriber. La fornitura dei servizi è possibile
grazie all’interazione tra il Service Provider e il Network Operator.
Questo ruolo, inoltre, si occupa di mantenere e gestire le informazioni relative ai
Subscriber.
I Modelli Architetturali
14
• Network Operator: mediante questo ruolo ogni User può accedere ai servizi
del Service Provider per cui il proprio Subscriber ha sottoscritto un contratto. In
questo ruolo si possono individuare due componenti distinte:
− Core Network Operator: si occupa di supportare i servizi messi a
disposizione dal Service Provider.
− Access Network Operator: fornisce agli User l’accesso al Core Network
Operator.
Dal punto di vista dell’accesso ai servizi, tale suddivisione dei compiti è
esclusivamente interna a questo business role ed è, quindi, completamente
trasparente allo User.
• Value Added Service Provider: questo business role fornisce altri servizi,
diversi, però, da quelli disponibili presso il Service Provider. L’accesso a questi
servizi è possibile previa sottoscrizione di un altro contratto. Tale contratto può
essere stipulato direttamente dallo User o dal Subscriber attraverso il proprio
Service Provider.
I business role appena descritti interagiscono tra loro grazie alle seguenti business
relationship:
• Subscription: è una relazione di tipo commerciale tra i business role Service
Provider e Subscriber. Permette di definire i servizi sottoscritti da ogni Subscriber
e le rispettive tariffe d’utilizzo.
• Delegation of Service Usage: il Subscriber delega uno o più User ad utilizzare
i servizi per cui ha sottoscritto un contratto con il Service Provider.
• Delegation of Service Provision: permette al Service Provider di far accedere
ai propri servizi lo User utilizzando l’infrastruttura di rete gestita dal Network
Operator.
• Subscriber Profile Management e User Service Profile Management:
queste due business relationship permettono, rispettivamente, al Subscriber e allo
User di modificare le informazioni gestite dal Service Provider.
• Usage: questa relazione coinvolge User, Network Operator e Value Added
Service Provider, Network Operator. Questa business relationship permette allo
User di accedere ai servizi messi a disposizione dal Service Provider e dal Value
Added Service Provider.
• Accounting: permette al Network Operator di informare il Service Provider
che un particolare User ha utilizzato quel particolare servizio sottoscritto.
• Billing: alla sottoscrizione di un contratto per l’accesso ad alcuni servizi, da
parte di un Subscriber, fa seguito la notifica del costo per l’utilizzo di tali servizi.
I Modelli Architetturali
15
• Payment: sottoscritto un contratto per dei servizi e notificato il costo per il
loro utilizzo, il Subscriber o lo User, devono pagare la corrispondente quota al
rispettivo fornitore dei servizi, il Service Provider o il Value Added Service
Provider.
Questa business relationship intercorre anche tra Network Operator e Service
Provider o Value Added Service Provider. In questo caso rappresenta la
controparte per la possibilità, fornita dal Network Operator ai provider, di far
accedere gli User ai propri servizi sfruttando l’infrastruttura di rete gestita dal
Network Operator.
1.2.1.4. CIP Business Model
All’interno dell’articolo [19], gli autori Mehdi Jazayeri e Ivana Podnar presentano
un business model per quello che ritengono un mercato emergente: il mercato
dell’Information Commerce (i-commerce).
Gli autori di questo documento definiscono l’i-commerce come un caso particolare
dell’e-commerce, focalizzato sulla compra-vendita d’informazioni di tipo elettronico:
tra le possibili “merci” di questo mercato si possono citare i libri in formato
elettronico, le immagini, i brani musicali, il software o, ancora, tutti quei beni
definibili interamente con dei bit e senza una consistenza materiale.
Il business model descritto, detto CIP Business Model (Costumer-Intermediary-
Provider Business Model), deve il suo nome ai tre business role che lo compongono:
il Costumer, l’Intermediary e il Provider.
Il CIP Business Model, schematizzato in Figura 1.8, è sviluppato attraverso due
fasi intermedie rappresentate, rispettivamente, in Figura 1.6 e Figura 1.7, e
caratterizzate da un progressivo sviluppo del business model stesso.
Il primo passo che gli autori hanno fatto per sviluppare questo modello, è stato
quello di identificare gli actor (o business role) che intervengono in una qualunque
attività di i-commerce. Nel caso più semplice (si veda Figura 1.6) si sono individuati
un Customer, alla ricerca di un certo prodotto, e un Provider, che ne offre alcuni.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
