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 » 18.Modelli di middleware: RDA, DOM, CM


Il modello RDA

Con il termine di middleware di accesso remoto ai dati (Remote Data Access o RDA) si intendono quelle piattaforme – spesso anche denominate database middleware – che offrono servizi per lo sviluppo di applicazioni di accesso a basi di dati remote, basate sul paradigma cliente-servente.

I database middleware forniscono servizi di accesso ad archivi o a sistemi DBMS di tipo relazionale, gerarchico, reticolare o a oggetti, con vari livelli di trasparenza per mascherare la distribuzione dei dati sui nodi di rete e le eterogeneità tra i sistemi

Viene adoperato il linguaggio standard SQL (Structured Query Language) per l’interrogazione e la manipolazione logica di dati remoti.

Le interfacce di programmazione offerte sono di tipo proprietario, oppure basate su standard de facto, quale ad esempio la specifica Open DataBase Connectivity (ODBC).

Il modello RDA

Il funzionamento nel caso di applicazioni a due livelli può essere così schematizzato:

  • l’applicazione cliente prepara un’interrogazione SQL che deve essere eseguita sul gestore remoto dei dati, e la trasmette al middleware;
  • il middleware sul nodo cliente impacchetta la richiesta in un messaggio, che inoltra al sistema servente;
  • il middleware sul nodo servente riceve il messaggio, estrae l’istruzione SQL e la invia al DBMS o al gestore dei dati
  • il DBMS esegue il comando ed invia la risposta al middleware;
  • il middleware sul nodo servente si occupa di inoltrare i dati all’omologo componente sul nodo cliente, eventualmente suddividendoli in più messaggi;
  • l’applicazione cliente preleva i dati dal middleware locale.

Il modello RDA

Architettura a due livelli

Architettura a due livelli


Il modello RDA

Vantaggi dello strato database middleware

Un’interrogazione SQL produce in generale una quantità di dati variabile: la dimensione della risposta non è perciò nota a priori (a differenza di una RPC).

L’applicazione cliente non accede direttamente al DBMS ma preleva i record risultanti dall’istruzione SQL direttamente dall’interfaccia RDA locale.

Il DBMS viene quindi sollevato dall’onere di gestione delle sessioni applicative.

La trasmissione dei dati su rete avviene in maniera ottimizzata a cura dei due componenti middleware.

Se i comandi SQL sono generati dinamicamente (dynamic SQL), il middleware locale al cliente svolge anche controlli sintattici, evitando di richiedere al DBMS remoto l’esecuzione di istruzioni incorrette.

Il modello a oggetti distribuiti

Viene riguardato come la seconda generazione di sistemi software distribuiti

Viene riguardato come la seconda generazione di sistemi software distribuiti


Il modello a oggetti distribuiti

Il modello a oggetti distribuiti è un’estensione in ambiente distribuito delle tecniche di programmazione ad oggetti.

Schematizzando:

DO = OOP + C/S

Distributed objects = object-oriented programming + client-server

L’utilizzo di una piattaforma Distributed Object Middleware (DOM) permette di invocare un metodo su di un oggetto remoto come fosse locale.

Esempi di tecnologie DOM:

  • Java RMI
  • OMG CORBA

Il modello a oggetti distribuiti

I componenti di un’applicazione distribuita sono oggetti che risiedono su macchine diverse e comunicano mediante invocazione di metodi.


Il modello a oggetti distribuiti

Il meccanismo di invocazione di un metodo su di un oggetto remoto è analogo a quello delle RPCs.

Il programmatore applicativo viene sollevato dall’onere di gestione della complessità dovuta alla distribuzione dei componenti su piattaforme eterogenee, sviluppando software ad oggetti in maniera (il più possibile) simile al caso sequenziale.

Sono disponibili strumenti di sviluppo simili al caso RPC:

  • IDL e relativi compilatori;
  • stub.

Object Request Brokers (ORBs)

Le piattaforme Distributed Object Middleware si presentano spesso sotto forma di Object Request Brokers.

Un ORB è una sorta di bus software per la comunicazione tra oggetti su rete. Esempi di ORB:

  • OMG CORBA
  • Microsoft COM+

Object Request Brokers (ORBs)

Il ciclo di sviluppo è analogo al caso RPC.

  • Specifica IDL
  • Compilazione IDL (generaz. stub)
  • Stesura client
  • Stesura server

Java/RMI

Un middleware a oggetti non basato su ORB

  • Specifico per la piattaforma Java.
  • Ambiente di elaborazione distribuita omogeneo (macchine virtuali Java).

I processi serventi creano oggetti e ne registrano il nome in un catalogo (RMI registry).

I clienti ottengono riferimenti agli oggetti remoti – eventualmente tramite ricerca nel catalogo – e ne invocano i metodi.


Java/RMI

RMI fornisce i meccanismi per

  • scambiare oggetti come parametri o valori di ritorno;
  • trasferire su richiesta il codice di un oggetto;
  • serializzare e trasferire lo stato di un oggetto.

Il trasferimento del codice utilizza un web server.

Tali meccanismi consentono di realizzare sistemi con codice mobile.


Il modello a componenti

Terza generazione di sistemi software distribuiti

Terza generazione di sistemi software distribuiti


Il modello a componenti

Componente

  • Modulo software (eseguibile) dotato di interfacce.
  • Le sue dipendenze da altri moduli sono esplicite nelle interfacce.
  • Può essere rilasciato ed eseguito autonomamente.
  • È componibile con altri moduli per costruire unità più complesse.

Component Based Software Engineering (CBSE)

  • Estende la nozione di riuso rispetto all’orientamento agli oggetti (OO).
  • Riuso non solo di classi e procedure, ma di intere applicazioni.

Il modello a componenti può essere considerato una evoluzione del modello a oggetti

  • Modello OO: dipendenze tra oggetti non esplicite nelle interfacce; la logica delle interazioni tra oggetti è nascosta al loro interno.

Piattaforme middleware a componenti

Offrono ai componenti meccanismi predefiniti di

  • gestione del ciclo di vita (esecuzione, attivazione, disattivazione);
  • sicurezza;
  • persistenza;

Lo sviluppatore ha il compito di dichiarare le strategie con cui associare i servizi standard a un componente.

Ciò avviene in fase di programmazione o, più tipicamente, di distribuzione del componente (deployment).

Basate sul concetto di contenitore (container).

Ambiente di esecuzione di componenti, in grado di gestirne il ciclo di vita, eseguirli, offrire i servizi standard necessari.

Un middleware a componenti: J2EE

Sun Java 2 Enterprise Edition (J2EE).

Architettura a tre livelli.


Un middleware a componenti: J2EE

Quattro tipi di componenti:

  1. Clienti generici
  2. Clienti web
  3. Serventi web
  4. Enterprise Java Beans (EJB)

I componenti EJB sono ospitati in contenitori, che ne gestiscono il ciclo di vita.


Microsoft COM/DCOM

COM

  • Interazione cliente-servente tra processi locali, basata sul modello RPC

DCOM

  • Estensione di COM in ambiente distribuito

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