Nell'ambito delle applicazioni informatiche si è soliti distinguere tra:
architetture locali: tutti i componenti sono sulla stessa macchina;
architetture distribuite: le applicazioni e i componenti possono risiedere su nodi diversi messi in comunicazione da una rete.
I vantaggi della seconda alternativa consistono principalmente nella possibilità di uso concorrente dei programmi, nella centralizzazione dei dati, nella distribuzione del carico elaborativo, il tutto al prezzo di una maggiore complessità specialmente riguardo alla comunicazione fra i vari compenenti.
Le applicazioni distribuite si possono classificare in base al «grado» di distribuzione:
Applicazioni client-server: sono presenti solo due livelli e le operazioni sono svolte quasi interamente sul servente. Come esempio possiamo citare i classici siti Web statici o dinamici; gli strumenti per la realizzazione di tale tipo di applicazioni sono i socket di rete, la cui programmazione è possibile in vari linguaggi, tra cui c, c++, Java.
Qui non viene approfondito tale argomento; per chi fosse interessato è possibile consultare la mia dispensa «Programmazione dei socket di rete in GNU/Linux» reperibile presso il sito <http://www.linuxdidattica.org>, oppure l'ottimo lavoro di Simone Piccardi «Guida alla programmazione in Linux» presso <http://gapil.truelite.it>.
Applicazioni multi-livello: si ha un numero maggiore di livelli, allo scopo, soprattutto, di alleggerire il carico elaborativo dei serventi.
Quelle che vengono suddivise infatti sono le funzionalità del lato servente, lasciando sostanzialmente invariate le caratteristiche della parte cliente che ha il compito di ospitare l'interfaccia dell'applicazione.
Un esempio di tale tipo di architettura è quello del modello three-tier già citato nel paragrafo 7.1; ricordiamo brevemente la sua struttura in tre strati o livelli:
front-end o presentation tier o interfaccia;
middle tier o logica applicativa;
back-end o data tier o gestione dati persistenti.
Questa nomenclatura è tipica delle applicazioni Web; più in generale si può fare riferimento ad una suddivisione in tre livelli, applicabile a qualsiasi applicazione software, che è la seguente:
PL (Presentation Layer): è la parte di visualizzazione dei dati (moduli, «controlli» di input, ecc.) necessari per l'interfaccia utente;
BLL (Business Logic Layer): è la parte principale dell'applicazione, che definisce le varie entità e le loro relazioni indipendentemente dalle modalità di presentazione all'utente e di salvataggio negli archivi;
DAL (Data Access Layer): contiene tutto il necessario alla gestione dei dati persistenti (sostanzialmente sistemi di gestione di basi di dati).
Il numero di livelli può essere anche maggiore di tre, allo scopo di suddividere ulteriormente i compiti dei vari strati; in questo caso si parla di applicazioni multi-tier o n-tier.
Applicazioni completamente distribuite: in questo ogni livello non risiede più su un singolo nodo di rete ma è distribuito geograficamente; siamo in presenza di una architettura «ad oggetti», con oggetti clienti che invocano servizi offerti da oggetti serventi e con una distribuzione del carico elaborativo che diviene la massima possibile.
Uno scenario di questo tipo viene talvolta denominato «Web a oggetti» e contribuisce alla diffusione della «componentistica software», termine con il quale si indica una tecnologia tendente a portare nel campo della produzione del software alcune metodologie di tipo industriale classico, migliorando o superando i metodi artigianali preesistenti.
Con essa lo sviluppo delle applicazioni si scompone in due attività distinte:
creazione di componenti («semilavorati» software);
costruzione di applicazioni integrando i componenti già pronti.
Il problema principale, nelle architetture completamente distribuite, è quello della definizione di regole per l'interazione fra i vari componenti; a tale proposito sono state proposte soluzioni eterogenee, che hanno portato alla nascita di tecnologie diverse per la rappresentazione degli oggetti coinvolti nelle applicazioni, e che dipendono da protocolli di comunicazione differenziati.
Le tecnologie più importanti sono:
CORBA (Common Object Request Broker Architecture): è uno standard aperto e multi-piattaforma sviluppato da OMG per permettere la comunicazione fra componenti indipendentemente dalla loro collocazione sui nodi di una rete e dal linguaggio di programmazione utilizzato.
OMG (Object Management Group è un consorzio creato nel 1989 da varie aziende tra cui Microsoft, HP, NCR, SUN, allo scopo di creare sistemi di gestione di architetture distribuite.
RMI (Remote Method Invocation): è una tecnologia che consente a processi Java distribuiti di comunicare attraverso una rete; è specifica appunto del mondo Java.
DCOM (Distributed Component Object Model): è una tecnologia informatica introdotta nel 1996 da Microsoft come contraltare di CORBA ed è basato l'estensione in rete della precedente tecnologia COM.
Occore notare come RMI, nelle versioni più recenti, sia completamente compatibile con CORBA e questo riduce praticamente a due le alternative in ambito di architetture completamente distribuite.
La comunicazione tra gli oggetti avviene solitamente in reti TCP/IP e può usare protocolli come l'HTTP oppure protocolli definiti appositamente come, per CORBA, l'IIOP (Internet InterOrb Protocol).
L'indipendenza dal linguaggio di programmazione pone la questione di come descrivere gli oggetti CORBA o DCOM in modo che i programmi possano fare riferimento ad essi qualunque sia il linguaggio in cui sono scritti; a questo scopo è stato definito un apposito linguaggio per la definizione di interfacce, l'IDL (Interface Definition Language) per CORBA e l'MIDL (Microsoft IDL) per DCOM.
La creazione di soluzioni software basate su queste tecnologie richiede risorse considerevoli (un broker CORBA ha costi molto elevati) e pone spesso problemi di funzionamento in Internet: con DCOM infatti ci sono difficoltà di dialogo con oggetti posti all'esterno di una rete locale e entrambe le tecnologie richiedono di configurare appositamente eventuali firewall presenti nella rete.
A questo aggiungiamo che la stessa Microsoft considera deprecata DCOM a vantaggio del suo nuovo ambiente integrato di sviluppo .NET.
Non deve quindi stupire che siano state cercate ulteriori soluzioni per la programmazione distribuita che fossero davvero universali e meno complicate delle precedenti.
Una prima proposta è stata XML-RPC (XML-Remote Procedure Call) che consiste nell'uso dei servizi RPC appoggiandosi a XML come formato per la codifica delle richieste di esecuzione remota; RPC è nato per l'invocazione di subroutine residenti su computer remoti nel modello client-server e non è particolarmente adatto ad applicazioni orientate agli oggetti.
Il passo avanti decisivo è stato allora quello di proporre la distribuzione in rete, non più dei componenti software, ma dei servizi che essi forniscono; questo ha portato alla definizione e all'uso dei Web Services (Servizi Web) ai quali è dedicato il prossimo capitolo.