Architettura distribuita

Nell'architettura distribuita, i componenti sono presentati su piattaforme diverse e diversi componenti possono cooperare tra loro su una rete di comunicazione al fine di raggiungere un obiettivo o un obiettivo specifico.

• In questa architettura, l'elaborazione delle informazioni non è limitata a una singola macchina, ma è distribuita su diversi computer indipendenti.

• Un sistema distribuito può essere dimostrato dall'architettura client-server che costituisce la base per architetture multi-tier; le alternative sono l'architettura del broker come CORBA e l'architettura orientata ai servizi (SOA).

• Esistono diversi framework tecnologici per supportare architetture distribuite, inclusi .NET, J2EE, CORBA, servizi Web .NET, servizi Web AXIS Java e servizi Globus Grid.

• Il middleware è un'infrastruttura che supporta adeguatamente lo sviluppo e l'esecuzione di applicazioni distribuite. Fornisce un buffer tra le applicazioni e la rete.

• Si trova al centro del sistema e gestisce o supporta i diversi componenti di un sistema distribuito. Esempi sono monitor di elaborazione delle transazioni, convertitori di dati e controller di comunicazione, ecc.

Middleware come infrastruttura per sistema distribuito

La base di un'architettura distribuita è la sua trasparenza, affidabilità e disponibilità.

La tabella seguente elenca le diverse forme di trasparenza in un sistema distribuito:

Sr.No.	Trasparenza e descrizione
1	Access Nasconde il modo in cui si accede alle risorse e le differenze nella piattaforma dati.
2	Location Nasconde dove si trovano le risorse.
3	Technology Nasconde all'utente diverse tecnologie come il linguaggio di programmazione e il sistema operativo.
4	Migration / Relocation Nascondi le risorse che possono essere spostate in un'altra posizione che sono in uso.
5	Replication Nascondi le risorse che possono essere copiate in più posizioni.
6	Concurrency Nascondi le risorse che possono essere condivise con altri utenti.
7	Failure Nasconde gli errori e il ripristino delle risorse dall'utente.
8	Persistence Nasconde se una risorsa (software) è in memoria o su disco.

Vantaggi

• Resource sharing - Condivisione di risorse hardware e software.

• Openness - Flessibilità nell'utilizzo di hardware e software di diversi fornitori.

• Concurrency - Elaborazione simultanea per migliorare le prestazioni.

• Scalability - Maggiore produttività con l'aggiunta di nuove risorse.

• Fault tolerance - La capacità di continuare a funzionare dopo che si è verificato un guasto.

Svantaggi

• Complexity - Sono più complessi dei sistemi centralizzati.

• Security - Più suscettibile agli attacchi esterni.

• Manageability - Maggiore impegno richiesto per la gestione del sistema.

• Unpredictability - Risposte imprevedibili a seconda dell'organizzazione del sistema e del carico di rete.

Sistema centralizzato vs sistema distribuito

Criteri	Sistema centralizzato	Sistema distribuito
Economia	Basso	Alto
Disponibilità	Basso	Alto
Complessità	Basso	Alto
Consistenza	Semplice	Alto
Scalabilità	Povero	Buona
Tecnologia	Omogeneo	Eterogeneo
Sicurezza	Alto	Basso

Architettura client-server

L'architettura client-server è l'architettura di sistema distribuito più comune che scompone il sistema in due principali sottosistemi o processi logici:

• Client - Questo è il primo processo che invia una richiesta al secondo processo, ovvero il server.

• Server - Questo è il secondo processo che riceve la richiesta, la esegue e invia una risposta al client.

In questa architettura, l'applicazione è modellata come un insieme di servizi forniti dai server e un insieme di client che utilizzano questi servizi. I server non devono conoscere i client, ma i client devono conoscere l'identità dei server e la mappatura dei processori ai processi non è necessariamente 1: 1

L'architettura client-server può essere classificata in due modelli basati sulla funzionalità del client:

Modello thin client

Nel modello thin-client, tutta l'elaborazione dell'applicazione e la gestione dei dati è effettuata dal server. Il cliente è semplicemente responsabile dell'esecuzione del software di presentazione.

• Utilizzato quando i sistemi legacy vengono migrati su architetture client server in cui il sistema legacy funge da server a sé stante con un'interfaccia grafica implementata su un client

• Uno dei principali svantaggi è che pone un carico di elaborazione pesante sia sul server che sulla rete.

Modello Thick / Fat-client

Nel modello thick client, il server è responsabile solo della gestione dei dati. Il software sul client implementa la logica dell'applicazione e le interazioni con l'utente del sistema.

• Più appropriato per i nuovi sistemi C / S in cui le capacità del sistema client sono note in anticipo

• Più complesso di un modello thin client soprattutto per la gestione. Le nuove versioni dell'applicazione devono essere installate su tutti i client.

Vantaggi

• Separazione delle responsabilità come la presentazione dell'interfaccia utente e l'elaborazione della logica di business.

• Riusabilità dei componenti del server e potenziale di concorrenza

• Semplifica la progettazione e lo sviluppo di applicazioni distribuite

• Semplifica la migrazione o l'integrazione delle applicazioni esistenti in un ambiente distribuito.

• Inoltre, fa un uso efficace delle risorse quando un numero elevato di client accede a un server ad alte prestazioni.

Svantaggi

• Mancanza di infrastrutture eterogenee per far fronte ai cambiamenti dei requisiti.

• Complicazioni di sicurezza.

• Disponibilità e affidabilità del server limitate.

• Testabilità e scalabilità limitate.

• Clienti grassi con presentazione e logica aziendale insieme.

Architettura multilivello (architettura a più livelli)

L'architettura multilivello è un'architettura client-server in cui le funzioni come la presentazione, l'elaborazione dell'applicazione e la gestione dei dati sono fisicamente separate. Separando un'applicazione in livelli, gli sviluppatori hanno la possibilità di modificare o aggiungere un livello specifico, invece di rielaborare l'intera applicazione. Fornisce un modello con cui gli sviluppatori possono creare applicazioni flessibili e riutilizzabili.

L'utilizzo più generale dell'architettura multi-livello è l'architettura a tre livelli. Un'architettura a tre livelli è in genere composta da un livello di presentazione, un livello di applicazione e un livello di archiviazione dati e può essere eseguita su un processore separato.

Livello di presentazione

Il livello di presentazione è il livello più alto dell'applicazione a cui gli utenti possono accedere direttamente come la pagina Web o la GUI del sistema operativo (interfaccia utente grafica). La funzione principale di questo livello è tradurre le attività ei risultati in qualcosa che l'utente possa capire. Comunica con altri livelli in modo da posizionare i risultati nel livello browser / client e in tutti gli altri livelli nella rete.

Livello applicazione (logica aziendale, livello logico o livello intermedio)

Il livello applicazione coordina l'applicazione, elabora i comandi, prende decisioni logiche, valuta ed esegue calcoli. Controlla la funzionalità di un'applicazione eseguendo un'elaborazione dettagliata. Inoltre, sposta ed elabora i dati tra i due livelli circostanti.

Livello dati

In questo livello, le informazioni vengono archiviate e recuperate dal database o dal file system. Le informazioni vengono quindi restituite per l'elaborazione e quindi nuovamente all'utente. Include i meccanismi di persistenza dei dati (server di database, condivisioni di file, ecc.) E fornisce API (Application Programming Interface) al livello dell'applicazione che fornisce metodi di gestione dei dati memorizzati.

Advantages

• Prestazioni migliori rispetto a un approccio thin client ed è più semplice da gestire rispetto a un approccio thick client.

• Migliora la riusabilità e la scalabilità: con l'aumentare delle richieste, è possibile aggiungere server aggiuntivi.

• Fornisce supporto multi-threading e riduce anche il traffico di rete.

• Fornisce manutenibilità e flessibilità

Disadvantages

• Testabilità insoddisfacente a causa della mancanza di strumenti di test.

• Affidabilità e disponibilità del server più critiche.

Broker Architectural Style

Broker Architectural Style è un'architettura middleware utilizzata nell'elaborazione distribuita per coordinare e abilitare la comunicazione tra server e client registrati. In questo caso, la comunicazione degli oggetti avviene tramite un sistema middleware chiamato broker di richieste di oggetti (bus software).

• Il client e il server non interagiscono direttamente tra loro. Il client e il server hanno una connessione diretta al suo proxy che comunica con il mediatore-broker.

• Un server fornisce servizi registrando e pubblicando le proprie interfacce con il broker ei client possono richiedere i servizi dal broker in modo statico o dinamico mediante ricerca.

• CORBA (Common Object Request Broker Architecture) è un buon esempio di implementazione dell'architettura broker.

Componenti dello stile architettonico del broker

I componenti dello stile architettonico del broker sono discussi attraverso le seguenti voci:

Broker

Il broker è responsabile del coordinamento della comunicazione, come l'inoltro e l'invio dei risultati e delle eccezioni. Può essere un servizio orientato alle chiamate, un documento o un broker orientato ai messaggi a cui i client inviano un messaggio.

• È responsabile dell'intermediazione delle richieste di servizio, dell'individuazione di un server appropriato, della trasmissione delle richieste e dell'invio delle risposte ai client.

• Conserva le informazioni di registrazione dei server, comprese le loro funzionalità e servizi, nonché le informazioni sulla posizione.

• Fornisce API per le richieste dei client, i server per rispondere, la registrazione o l'annullamento della registrazione dei componenti del server, il trasferimento dei messaggi e l'individuazione dei server.

Stub

Gli stub vengono generati al momento della compilazione statica e quindi distribuiti sul lato client che viene utilizzato come proxy per il client. Il proxy lato client funge da mediatore tra il cliente e il broker e fornisce ulteriore trasparenza tra questi e il cliente; un oggetto remoto appare come uno locale.

Il proxy nasconde l'IPC (comunicazione tra processi) a livello di protocollo ed esegue il marshalling dei valori dei parametri e l'annullamento del marshalling dei risultati dal server.

Skeleton

Lo scheletro viene generato dalla compilazione dell'interfaccia del servizio e quindi distribuito sul lato server, che viene utilizzato come proxy per il server. Il proxy lato server incapsula funzioni di rete specifiche del sistema di basso livello e fornisce API di alto livello per mediare tra il server e il broker.

Riceve le richieste, decomprime le richieste, annulla il marshalling degli argomenti del metodo, chiama il servizio appropriato e esegue anche il marshalling del risultato prima di rimandarlo al client.

Bridge

Un bridge può connettere due reti differenti in base a protocolli di comunicazione differenti. Media diversi broker tra cui DCOM, .NET Remote e Java CORBA broker.

I bridge sono un componente opzionale, che nasconde i dettagli di implementazione quando due broker interagiscono e accettano richieste e parametri in un formato e li traducono in un altro formato.

Broker implementation in CORBA

CORBA è uno standard internazionale per un Object Request Broker, un middleware per gestire le comunicazioni tra oggetti distribuiti definiti da OMG (Object Management Group).

Architettura orientata ai servizi (SOA)

Un servizio è un componente della funzionalità aziendale che è ben definito, autonomo, indipendente, pubblicato e disponibile per essere utilizzato tramite un'interfaccia di programmazione standard. Le connessioni tra i servizi sono condotte da protocolli orientati ai messaggi comuni e universali come il protocollo del servizio Web SOAP, che può fornire richieste e risposte tra i servizi liberamente.

L'architettura orientata ai servizi è una progettazione client / server che supporta un approccio IT orientato al business in cui un'applicazione è costituita da servizi software e consumatori di servizi software (noti anche come clienti o richiedenti di servizi).

Caratteristiche di SOA

Un'architettura orientata ai servizi fornisce le seguenti funzionalità:

• Distributed Deployment - Esporre i dati aziendali e la logica aziendale come unità di funzionalità vaghe, accoppiate, rilevabili, strutturate, basate su standard, a grana grossa e senza stato chiamate servizi.

• Composability - Assemblare nuovi processi dai servizi esistenti che sono esposti a una granularità desiderata attraverso interfacce di reclamo ben definite, pubblicate e standard.

• Interoperability - Condivisione di funzionalità e riutilizzo di servizi condivisi su una rete indipendentemente dai protocolli sottostanti o dalla tecnologia di implementazione.

• Reusability - Scegli un fornitore di servizi e accedi alle risorse esistenti esposte come servizi.

Operazione SOA

La figura seguente illustra come funziona SOA:

Advantages

• Il libero accoppiamento di orientamento al servizio offre alle aziende una grande flessibilità per utilizzare tutti i servizi disponibili indipendentemente dalle limitazioni della piattaforma e della tecnologia.

• Ogni componente del servizio è indipendente dagli altri servizi a causa della funzionalità del servizio senza stato.

• L'implementazione di un servizio non influirà sull'applicazione del servizio fintanto che l'interfaccia esposta non viene modificata.

• Un client o qualsiasi servizio può accedere ad altri servizi indipendentemente dalla piattaforma, dalla tecnologia, dai fornitori o dalle implementazioni del linguaggio.

• Riusabilità di beni e servizi poiché i clienti di un servizio devono solo conoscere le sue interfacce pubbliche, la composizione del servizio.

• Lo sviluppo di applicazioni aziendali basato su SOA è molto più efficiente in termini di tempo e costi.

• Migliora la scalabilità e fornisce una connessione standard tra i sistemi.

• Utilizzo efficiente ed efficace dei "servizi aziendali".

• L'integrazione diventa molto più semplice e migliora l'interoperabilità intrinseca.

• Complessità astratta per gli sviluppatori e stimola i processi aziendali più vicini agli utenti finali.