Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 16.Introduzione alle tecnologie middleware


Sistemi distribuiti

Una definizione di sistema distribuito

“Il mio programma gira su un sistema distribuito quando non funziona per colpa di una macchina di cui non ho mai sentito parlare”

L. Lamport

Heterogeneous distributed computing

I sistemi distribuiti sono in generale eterogenei.

L’eterogeneità dei computer e delle tecnologie – hardware e software – è da considerarsi la norma, non l’eccezione, anche all’interno di una stessa grande azienda o organizzazione, pubblica o privata.

Il paradigma di elaborazione più generale prevede componenti interoperanti in ambiente distribuito ed eterogeneo (heterogeneous distributed computing).

Eterogeneità

In ambiente distribuito vari fattori aumentano la complessità dello sviluppo di software di qualità:

  • le applicazioni sono distribuite su una rete di calcolatori, di caratteristiche differenti (mainframes, servers, workstations, personal computers) e dotati di hardware e di sistemi operativi diversi e spesso incompatibili;
  • occorre adoperare linguaggi di programmazione diversi:
    • linguaggi visuali come Visual Basic o Visual C++ per lo sviluppo rapido della parte di presentazione di un’applicazione (la cosiddetta presentation logic);
    • linguaggi tradizionali come COBOL, C, C++ per lo sviluppo delle funzionalità di un’applicazione (business logic);
    • SQL per l’accesso ai dati;
    • Java per applicazioni multimediali e sul Web.

Eterogeneità

I dati sono distribuiti su più nodi di elaborazione, memorizzati in archivi o con sistemi di gestione di basi di dati (DBMS) diversi, e in generale condivisi da applicazioni locali e remote.
Nello sviluppo di software su rete – anche in ambiente omogeneo – occorre fronteggiare problematiche quali

  • sicurezza;
  • guasti;
  • contesa e condivisione delle risorse;

che si presentano ben più complessi che per i sistemi centralizzati; l’eterogeneità aggiunge ulteriore complessità a questi stessi problemi.

Enterprise Application Integration

Sistemi complessi funzionanti raramente vengono sviluppati integralmente ex novo; tipicamente essi evolvono a partire da sistemi esistenti già funzionanti.

L’integrazione di sistemi informativi sviluppati in momenti, con linguaggi e con tecniche diversi, ed operanti su piattaforme eterogenee, è un problema centrale delle tecnologie software.

Si richiede sempre più di:

  • utilizzare applicazioni di terze parti (sistemi COTS, Commercial Off-The-Shelf);
  • riutilizzare applicazioni esistenti (sistemi ereditati o legacy).

Enterprise Application Integration

L’integrazione di applicazioni, siano esse sistemi di nuovo sviluppo, sistemi ereditati o sistemi COTS, è da considerarsi lo scenario tipico di sviluppo software su larga scala.


Enterprise Application Integration

L’integrazione di applicazioni (EAI) è un processo sovente più complesso dello sviluppo ex novo.

\begin{tabular}{lp{0.5\columnwidth}}\toprule \textbf{SVILUPPO DI APPLICAZIONI}& \textbf{INTEGRAZIONE DI APPLICAZIONI}\\Nuove applicazioni&Riuso di applicazioni esistenti, spesso non documentate, e uso di componenti Cots \\ Possibilita' di scelta di tecnologie e prodotti& Vincoli su sistemi operativi, protocolli, linguaggi, ambienti di sviluppo ecc.; tecnologie dei sistemi esistenti spesso non interoperanti \\ Richiede competenze di analisi, progettazione, programmazione&Richiede competenze di architetture software, reingenerizzazione, riuso, capacita' di buona progettazione delle interfacce, adattamento di compnenti, predisposizione all'evoluzione \\ Puo' essere svolto da giovani sviluppatori& Richiede familiarita' con i sistemi esistenti; svolto da specialisti con anni di esperienza\\ \bottomrule \end{tabular}

Enterprise Application Integration

In questa prospettiva dello sviluppo software, la programmazione (intesa come codifica di moduli software in un linguaggio di programmazione) è, ancor meno che in passato, una fase critica del ciclo di vita del software, in termini sia di risorse sia di competenze tecnologiche richieste.

Assume maggiore importanza la capacità di adattare componenti esistenti e non originariamente pensati per interoperare, mediante l’attenta progettazione delle interfacce.

Molte tecnologie middleware sono nate con il preciso obiettivo di fornire una risposta al problema dell’EAI.

Il middlewareDefinizione, proprietà, modelli, tassonomia

Con il termine middleware si intende uno strato software interposto tra il sistema operativo e le applicazioni, in grado di fornire le astrazioni ed i servizi utili per lo sviluppo di applicazioni distribuite.


Il middleware – Definizione, proprietà, modelli, tassonomia

Lo strato middleware offre ai programmatori di applicazioni distribuite librerie di funzioni, o middleware API (Application Programming Interface), in grado di mascherare i problemi dovuti all’eterogeneità dei sistemi su rete.

Le piattaforme middleware vengono anche definite software di connettività tra applicazioni, o anche “glue technologies” (tecnologie collante), evidenziando la loro caratteristica di tecnologie di integrazione di applicazioni.

Proprietà del livello middleware

Il livello middleware può mascherare le eterogeneità mediante meccanismi di:

trasparenza del sistema operativo:

  • operando al di sopra del sistema operativo, i servizi forniti dalle API middleware possono essere definiti in maniera indipendente da esso, consentendo la portabilità delle applicazioni tra diverse piattaforme;

trasparenza del linguaggio di programmazione:

  • la comunicazione tra componenti sviluppati il linguaggi diversi pone problemi connessi alle differenze tra i tipi di dato supportati ed alla diversità tra i meccanismi di scambio parametri nell’invocazione di sottoprogrammi;
  • il livello middleware può consentire l’interoperabilità, definendo un sistema di tipi intermedio e regole non ambigue di corrispondenza con i tipi dei linguaggi più diffusi.

Proprietà del livello middleware

Il livello middleware può mascherare le eterogeneità mediante meccanismi di:

trasparenza della locazione:

  • le risorse (dati e servizi) dovrebbero essere accessibili a livello logico, senza conoscerne la effettiva locazione fisica. E’ lo strato middleware che deve farsi carico della localizzazione su rete del processo partner in una comunicazione, e del trasporto dei dati (location transparency);

trasparenza della migrazione:

  • dati e servizi possono venir rilocati durante il loro ciclo di vita. Se un componente migra, il middleware può consentire l’accesso a componenti mobili sulla rete, in maniera trasparente ai moduli clienti (migration transparency).

Proprietà del livello middleware

Il livello middleware può mascherare le eterogeneità mediante meccanismi di:

trasparenza ai guasti:

  • una elaborazione distribuita può fallire anche solo in maniera parziale per guasti che si verificano nei singoli nodi o nel sottosistema di comunicazione;
  • occorrono tecniche complesse per poter gestire uno stato globale consistente della computazione. Lo strato middleware può offrire al programmatore meccanismi ad alto livello per mascherare i guasti (failure transparency);

trasparenza della replicazione:

  • la replicazione di componenti è una delle tecniche più comuni per realizzare politiche di tolleranza ai guasti, ma può essere utilizzata anche per migliorare le prestazioni, attraverso un miglior bilanciamento del carico di elaborazione;
  • l’esistenza di più copie di un componente dovrebbe però essere trasparente ai suoi clienti (replication transparency).

Proprietà del livello middleware

Il livello middleware può mascherare le eterogeneità mediante meccanismi di:

trasparenza delle implementazioni commerciali:

  • alcune tecnologie middleware, tra cui CORBA, si presentano in realtà come specifiche di riferimento promosse da organizzazioni di produttori, spesso poi recepite dagli enti di standardizzazione;
  • le varie implementazioni commerciali sono quindi realizzate in maniera conforme allo standard, eventualmente differenziandosi tra loro per aspetti secondari o per servizi aggiuntivi fuori standard;
  • in questo modo è resa possibile l’interoperabilità tra applicazioni basate su realizzazioni commerciali diverse dello stesso tipo di middleware.

Modelli di tecnologie middleware

Nell’ultimo decennio sono state realizzate numerose tipologie di piattaforme middleware, sia in forma prototipale in ambito di ricerca, sia in forma commerciale.

Principali modelli di programmazione:

  • Chiamata di procedura remota (Remote Procedure Call, RPC)
  • Scambio messaggi (Message-Oriented Middleware, MOM)
  • Transazionale (Transaction Processing, TP)
  • Spazio delle tuple (Tuple Space, TS)
  • Accesso remoto ai dati (Remore Data Access, RDA)
  • Oggetti distribuiti (Distributed Object Middleware, DOM)
  • Componenti (Component Model, CM)

Una tassonomia dei sistemi middleware

Esempi delle varie tecnologie

  • RDA: ODBC, Oracle DB Integrators
  • TP: X/Open DTP
  • RPC: SunRPC, OSF DCE RPC
  • MOM: IBM MQSeries
  • TS: Linda, JavaSpaces, Jini
  • DOM: Sun Java/RMI, OMG CORBA, Microsoft DCOM
  • CM: OMG CCM, Sun Enterprise Java Beans

I materiali di supporto della lezione

AA. VV., Java Server Programming – J2EE Edition, Wrox Press, 2000.

Bernstein P.A., Middleware: A Model for Distributed Services, Communications of the ACM, Vol. 39, N. 2, 1996.

Birrell A.D., Nelson B.J., Implementing Remote Procedure Calls, ACM Transactions on Computer Systems, Vol. 2, N. 1, 1984.

Gelernter D., Generative Communication in Linda, ACM Transactions on Programming Languages and Systems, Vol. 7, N. 1, 1985.

Carriero N., Gelernter D., How to Write Parallel Programs: A Guide to the Perplexed, ACM Computing Surveys, 1989.

Coulouris G., Dollimore J., Kindberg T., Distributed Systems: Concepts and Design, Addison-Wesley, 1998.

Edwards W.K., Joy B., Core Jini – 2nd ed., Prentice Hall, 2001.

Lehman T.J. et al., Hitting the distributed computing sweet spot with TSpaces, Computer Networks, Vol. 35, 2001.

Monson-Haefel R., Enterprise Java Beans, O’Reilly, 2000.

Mullender S., Distributed Systems, Addison-Wesley, 1993.

Natis Y., Pezzini M., Shulte R., Middleware Deployment Trends: Survey of Real-World Enterprise Applications, Gartner Strategic Report, 1999.

Sing Li, Professional Jini, Wrox Press, 2000.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93