Sistemi Distribuiti - Riassunti

IDLCORBA

IDLCORBA è neutrale rispetto ai linguaggi. Utilizza un Interface Definition Language (IDL), un linguaggio simile a C/C++/Java che supporta la programmazione ad oggetti. I servizi diventano interfacce. IDL permette di costruire sistemi distribuiti indipendenti dal linguaggio di programmazione. Alla fine comunque ci deve essere un cast tra IDL e un certo linguaggio di implementazione (IDL Compilers).

Metadati sono dati su altri dati (ad esempio lo schema di un database). Nella programmazione ad oggetti, ad esempio, è possibile utilizzare la reflection. I metadati sono essenziali in sistemi eterogenei perché permettono di parlare del sistema e della struttura dei suoi componenti.

I metadati vengono utilizzati in diverse parti nell'architettura OMA:

• Dynamic Invocation Interface consente di agire sul meccanismo di chiamata di operazione stesso
• Interface Repository consente il rilevamento runtime di nuove interfacce IDL e la loro struttura
• Trader Service raccoglie i

servizi esportati da oggetti in una struttura a pagine gialle

Dynamic Invocation Interface (DII)

Interfaccia completa e flessibile par il remote invocation mechanism. E' basata sul concetto di pseudo-object che reifica l'istanza di una chiamata remota. DII permette di gestire sia la comunicazione sincrona (invoke()) che deferred (send())

Interface Repository

L'interface repository mantiene una descrizione di tutti gli IDL disponibili in un dominio CORBA. Attraverso questa interfaccia i programmi possono scoprire la struttura di tipi per cui non hanno uno stub

Dynamic Collaboration

Gli oggetti in CORBA possono adattarsi meglio che in linguaggi ordinari. Due oggetti A e B diversi che non sanno l'uno la struttura dell'altro possono iniziare una 'collaborazione' attraverso l'interface repository.

Software & System Architectures

software architectures: Organizzazione dei componenti

system architectures: Istanziazioni di un'archiettura software in cui i

Software Architectures

Astrazione a run-time degli elementi di un software durante una sua fase di operazione ... è definita dalla configurazione di elementi architetturali (componenti, connettori e dati) legati tra loro per raggiungere un insieme di proprietà architetturali

Elementi Architetturali

Un componente è un unità software con un interfaccia ben definita e uno stato interno che permette la trasformazione di dati. Replicabile nel suo ambiente.

Un connettore è un astrazione per gestire la comunicazione, cooperazione e il coordinamento tra i componenti.

Un dato è un elemento di informazione inviato o ricevuto da un componente attraverso un connettore.

Proprietà Architetturali e Constraints

La selezione e l'arrangiamento dei vari componenti, connettori e dati produce un insieme di proprietà architetturali. Spesso l'applicazione di principi dell'ingegneria del software

• Layered: I componenti in un layer 'chiamano' solo quelli ad un layer inferiore e vengono chiamati solo da componenti nel layer superiore. Il flusso request-response è sempre top-down/bottom-up.
• Object-based: I componenti sono oggetti connessi tra loro attraverso meccanismi di RPC. (L'architettura Client Server è di questo tipo). Insieme all'architettura layer rappresenta lo stile più utilizzato per i sistemi distribuiti moderni.
• Data-centered: La comunicazione avviene attraverso shared data space.
• Event-based: La comunicazione avviene attraverso eventi. I componenti possono essere sia produttori che consumatori di eventi.

repository (sia passiva/reactive che pro-attiva). I sistemi Web fanno largo uso di questo tipo di architettura.

Event-based

I processi comunicano attraverso un event bus in cui passano gli event (che possono portare dati). Esempio: Sistemi publish subscribe.

La caratteristica principale di questo tipo di sistemi è che i processi non hanno bisogno di referenziarsi (sono referentially uncoupled e space uncoupled).

Shared Data-space

Unisce Data-centric e Event-based. Una shared repository è sia uno spazio di dati che un event bus. Esempio: Blackboard systems (i processi inseriscono dati nella blackboard che aggrega knowledge, implementa policies e gestisce la coordinazione).

La caratteristica principale è che i processi non hanno bisogno di essere presenti contemporaneamente (uncoupled in time).

System Architecture

In un sistema distribuito la posizione dei componenti conta.

Tipi di architettura di sistema:

Centralized

Decentralized

Hybrid

Centralized

I Client mandano richieste ai Server.

Un Server è un processo che implementa un servizio.

Un Client è un processo che richiede un servizio.

La comunicazione può essere stateless: Ogni interazione avviene indipendentemente dalle altre. Ogni richiesta deve contenere tutte le informazioni necessarie. Non è necessario un canale di comunicazione (HTTP, IP, UDP). I server sono più semplici ma le richieste dei client occupano più banda.

La comunicazione statefull: L'interazione avviene su un canale precedentemente creato. (TCP, FDP). La comunicazione ha uno stato. I server sono più complessi ma le richieste dei client occupano meno banda. La comunicazione statefull è meno efficiente ma più affidabile.

In un'architettura Client-Server spesso si attua una suddivisione logica dei layer:

• User Interface Level
• Processing Level
• Data Level

Come mappare la suddivisione logica dei layer in pratica? Multi-tiered Architecture:

• two-tiered: Ogni layer può essere gestito o dal client o dal server

Lo scopo del WWW era essere un spazio di informazione comune; per questo erano neessarie 2 cose:

1. poter creare e salvare la propria informazione
2. poter referenziare informazioni di altri(senzza averle salvate in locale)

Il WWW era inteso come distributed hypermedia system.

Hypermedia indica la presenza di informazioni di controllo dell'applicazione incorporate all'interno dellapresentazione delle informazione.

Distributed perchè le informazione di presentazione e controllo possono essere salvate in posizioni diverse.

Proprietà richieste:

• Semplicità
• Estensibilità
• Latency

L'architettura del WWW deve essere pensata per trasferire 'dati pesanti' e deve quindiminimizzare l'interazione con la rete.

Scalabilità Gli elementi del sistema devono continuare a funzionare anche se soggetti ad un cariconon previsto, anche

se ricevono dati malicious e non bene formati in quanto devono comunicare con elementi fuori dal loro controllo.

Sicurezza Più confini organizzativi implicano misure di sicurezza di comunicazione. L'autenticazione però limita la scalabilità. Le operazioni di default non devono quindi richiedere autenticazione.

Indipendent Depolyment L'eterogeneità dei domini comporta una frammentazione delle implementazioni. Devono poter coesistere vecchie e nuove implementazioni (senza che le vecchie prevengano a quelle nuove di sfruttare le loro 'capacità'). Gli elementi architetturali devono essere pensati per poter accogliere nuove funzionalità.

Date queste proprietà e possibile definire uno stile architetturale per il Web (ovvero ReST) con queste caratteristiche

Client-Server Separazione de compiti tra interfaccia utente e dati. Vincoli: un componente server offre servizi e resta in attesa di richieste un cliente che ha bisogno di servizi

Proprietà: migliora la portabilità delle user interface tra più piattaforme

migliora la scalabilità semplificando la componente server

permette ai componenti di evolvere in maniera indipendente

Stateless

Vincoli: Ogni richiesta del Client deve contenere tutte le informazioni.

Proprietà: Migliora la visibilità (ogni richiesta svela tutta la sua natura)

Migliora l'affidabilità rendendo più semplice il recovery da partial failures

Migliora la scalabilità perché i server possono rilasciare subito le risorse

Migliora banalmente la semplicità di sviluppo server

Svantaggi: Riduce le performance

Cache

Vincoli: I Dati nella risposta devono essere marcati o meno come cachable in modo che un client possa sapere se riusarli in seguito

Proprietà: Migliora efficienza, scalabilità e performance percepite dall'utente. C'è meno latenza di interazione

Svantaggi: Riduce