1

WP8 Component ModelM. Aldinucci, M. Coppola, M. Danelutto, M. Vanneschi, C. Zoccolo

Gennaio 2004

1 Introduzione..................................................................................................................................................................... 2

2 Modello a componenti: primi requisiti e scelte fondamentali ................................................................................... 2

2.1 Primi requisiti del modello ..................................................................................................................................... 3

2.2 Una prima soluzione: composizione su un solo livello ......................................................................................... 4

2.3 Definizione di Componente..................................................................................................................................... 4

2.4 Framework .............................................................................................................................................................. 5

2.5 Web & Grid Services 5

2.5.1 HTTP + SOAP = Web Services ........................................................................................................................ 5

2.5.2 Web Services + Grid = Grid Services ............................................................................................................... 6

3 Grid & applicazioni: visione logica............................................................................................................................... 6

3.1 Middleware.............................................................................................................................................................. 6

3.2 Applicazioni............................................................................................................................................................. 8

4 Alta performance ed aderenza agli standard .............................................................................................................. 8

5 Progettazione a componenti: l’esperienza ASSIST .................................................................................................. 10

5.1 ASSIST overview ................................................................................................................................................... 11

5.1.1 Linguaggio........................................................................................................................................................ 11

5.1.2 Compilazione ................................................................................................................................................... 11

5.2 Lo schema del nodo task-code.............................................................................................................................. 12

5.2.1 Il funzionamento del nodo task-code .............................................................................................................. 12

5.2.2 Nodo task-code: classi oggetti e loro relazioni di uso .................................................................................... 14

5.2.3 Fase di run ........................................................................................................................................................ 14

6 Programming Model: un possibile scenario .............................................................................................................. 17

6.1 Application Manager ............................................................................................................................................ 18

6.2 Definizione dei Componenti ................................................................................................................................. 21

6.2.1 Interfacce di comunicazione ............................................................................................................................ 21

6.2.2 Interfacce di configurazione ............................................................................................................................ 22

6.3 Componenti Standard e Componenti Specializzati.............................................................................................. 23

6.3.1 Integrazione fra Standard di Componenti ....................................................................................................... 23

6.3.2 Componenti Storage......................................................................................................................................... 24

6.3.3 Riconfigurazione di Componenti .................................................................................................................... 25

6.4 Strategia ................................................................................................................................................................ 27

6.5 ASSIST come formalismo per specificare le strategie di configurazione e riconfigurazione in applicazioniGrid-aware ........................................................................................................................................................................... 27

6.6 Fault-tolerance...................................................................................................................................................... 30

6.7 Sicurezza................................................................................................................................................................ 31

2

7 Bibliografia .................................................................................................................................................................... 31

1 IntroduzioneQuesto documento vuole riassumere i risultati del primo anno di lavoro nel progetto FIRB GRID.itconseguiti all’interno del WP8. In particolare, questo documento costituisce una raccolta di linee guidada utilizzare nella progettazione e nello sviluppo dell’ambiente di programmazione a componenti adalte prestazioni per griglia che costituisce uno degli obiettivi del progetto. Le considerazioni riportatenel documento sono per lo più frutto dell’interazione dei gruppi di lavoro WP8 afferenti alDipartimento di Informatica dell’Università di Pisa e dell’ISTI/CNR, sempre di Pisa, ma il documentoaccoglie e rappresenta anche considerazioni derivate dalle discussioni con gli altri gruppi di ricerca chepartecipano attivamente alle attività del WP8 all’interno del progetto.

Come già accennato, il documento non presenta una scelta univoca riguardo ad un modello a componenti,Piuttosto, discute una serie di scelte e propone linee guida che possono essere utilizzate per laprogettazione e per la realizzazione dell’ambiente a componenti ad alte prestazioni per griglia obiettivodel WP8.

In particolare, questo documento è costruito in parti sinergiche ma distinte:

• una prima parte (sezione 2), raccoglie e descrive una serie di requisiti e funzionalità per unmodello di programmazione ad alte prestazioni che produca codice per Grid e che sia basato sutecnologia a componenti, allo scopo, fra l’altro, di evidenziare quelle caratteristiche che nonsono esclusivamente legate al modello a componenti in sé ma che hanno pesante influenza sullecaratteristiche ad alte prestazioni del modello di programmazione;

• una seconda parte (sezioni 3, 4 e 5) discute come un modello a componenti possa essereutilizzato per la (ri)progettazione di un supporto per ambienti di programmazione ad alteprestazioni (ASSIST) allo scopo di evidenziare le problematiche da risolvere e le caratteristicheda includere nel modello a componenti per supportare modelli di programmazione ad alteprestazioni;

• una terza parte del documento (sezione 6) discute in prospettiva le linee guida per larealizzazione di un modello a componenti ad alte prestazioni per griglia. Le considerazioni quiriportate derivano ovviamente dai punti discussi nelle altre parti del documento. Qui ci sonodiverse opzioni che sono state lasciate come opzioni aperte, cioè come opzioni che possonorisolversi con più di una scelta. Questo accade in tutti i casi in cui solo un’adeguatasperimentazione può dirimere eventuali scelte che dal punto di vista squisitamente teorico sipresentano come equivalenti;

Il documento fa riferimento al deliverable “Analysis of Component-Oriented Frameworks” di D.Puppin, T. Fagni, N. Tonellotto, M. Serranò (ISTI–CNR) e S. Campa (Dip. Informatica, Universitàdi Pisa) che raccoglie le esperienze derivate nel confronto di strumenti e modelli a componentiesistenti, studio sempre condotto nel primo anno di attività del progetto. A questa attività hacollaborato anche il gruppo del CNR di Roma.

2 Modello a componenti: primi requisiti e scelte fondamentaliL’ambiente di sviluppo è fondato su un modello a componenti che permette la progettazione diapplicazioni ad alta performance per griglie computazionali (Grid). Le applicazioni risultano formate daun insieme di componenti e di interazioni fra componenti (coordinamento). La logica dell’applicazione èrealizzata mediante entrambi gli aspetti. Discutiamo gli aspetti generali dell’ambiente di sviluppo, quindidefiniamo con maggiore precisione il concetto di componente e di coordinamento.

3

2.1 Primi requisiti del modelloIl modello a componenti deve fornire una serie di caratteristiche essenziali. Alcune di queste sonofunzionali allo sviluppo efficiente di applicazioni, altre sono specifiche delle Grid:

• Modularità. Deve essere possibile uno sviluppo modulare delle applicazioni, ovvero lo sviluppo diuna parte di applicazione deve poter essere abbastanza indipendente dalle altre.

• Riuso. L’ambiente e il modello devono permettere il riuso di codice da parte del programmatore diapplicazioni nelle varie forme:

o codice sequenziale sorgente o oggetto;

o codice parallelo sviluppato mediante l’ambiente stesso oppure altri ambienti/librerie per laprogrammazione parallela. È ragionevole pensare che riuso sia di codice sorgente cheoggetto parallelo sia limitato ad un insieme predeterminato di ambienti.

• Portabilità. Delle applicazioni e/o di componenti, quindi implicitamente anche del supporto run-time dell'ambiente.

• Alta performance e parallelismo. La semantica del parallelismo deve essere chiaramente e formalmentedeterminata al fine di abilitare ottimizzazioni statiche o dinamiche del codice parallelo.

• Grid-awareness

o supporto alla dinamicità ed adattività;

o eterogeneità;

o fault-tolerance

o Quality of Service;

o interfaccia appropriata verso i protocolli standard o standard di fatto Grid (resourcelocation, sicurezza).

L’ambiente di sviluppo deve rendere possibile distribuire sia componenti in formato binario, cioè codiceeseguibile più opportune interfacce che permettano di associarlo al run-time dell'applicazione, siacomponenti in formato sorgente, per i quali il processo di istanziazione prevede la produzione dell'eseguibileper l'architettura target tramite gli opportuni strumenti di compilazione. Si mantiene così l'apertura neiconfronti del mercato di componenti commerciali e il basso overhead di istanziazione di componentiprecompilate, senza rinunciare alla maggiore flessibilità ed efficienza che può portare la ricompilazionejust-in-time di moduli funzionali complessi e parametrici.

I modelli a componenti più diffusi si concentrano su componenti di complessità limitata (paragonabilead una classe di un linguaggio ad oggetti) e con interfacce semplici, tendenzialmente visti come“implementazioni riutilizzabili”.

Chiamiamo le componenti di complessità e dimensione limitate “technical components”, incontrapposizione alle “business components”, che realizzano funzioni più complesse (o parti diarchitettura software) orientate ad uno specifico campo applicativo. L'approccio a componenti sembraavere avuto pienamente successo nella costruzione di interfacce utente e interfacce verso servizisoftware, essenzialmente cioè nella creazione di un mercato di technical components ed in un insiemedi container standardizzati (ad esempio i browser WWW, o gli application server per EJB). Laproduzione di applicazioni per semplice composizione di componenti off-the-shelf è invece limitatadalla relativa assenza di un mercato di business components [1].

Per gli obiettivi prefissati, un modello a componenti per Grid dovrebbe permettere un approccio menoriduttivo, che vada oltre la composizione piatta di technical components e renda disponibili mattonisoftware di maggiore complessità e flessibilità.

4

2.2 Una prima soluzione: composizione su un solo livelloIl meccanismo di composizione, idealmente, dovrebbe permettere di costruire componenti a partire dacomponenti più semplici. Data la forte eterogeneità dei componenti che dovranno essere gestiti(programmi sequenziali e paralleli, componenti di altri framework, interfacce verso servizi), come primoapproccio è stato però scelto di non sviluppare un modello completamente generale basato su componenti containergenerici liberamente annidabili. Si semplifica la struttura delle applicazioni imponendo che vi sia un solo livellodi composizione dei componenti, eliminando le componenti “contenitori” ma mantenendo intatta lageneralità della interazione tra le singole componenti (grafo arbitrario, nondeterminismo/concorrenza,tipologie di interfacce ...).

Prediligendo l'aspetto di HPC e Grid-awareness si da quindi precedenza all'integrazione di componentia grana relativamente grossa, che sono connessi tra loro in un grafo generico ma non sono contenutil'uno nell'altro, ed alla gestione della dinamicità ed adattività. Il passo successivo di generalizzazione (grafodi componenti interno ad una componente) rimane per ora oggetto di discussione.

L'obiettivo è definire un modello di componente generico e di alto livello, che dia la possibilità discrivere applicazioni distribuite adattive. Vogliamo poter utilizzare più linguaggi sequenziali e paralleliesistenti per l'implementazione dei singoli componenti, quindi per quanto possibile la definizione delcomponente non deve vincolare l'implementazione del componente o il suo run-time.

2.3 Definizione di ComponenteL'obiettivo è definire un modello di componente generico e di alto livello, che dia la possibilità discrivere applicazioni distribuite adattive. Visto il numero e la diversità di definizioni ed implementazionidisponibili in letteratura [1], la definizione di componente è un punto abbastanza critico. In particolareè necessario non vincolare eccessivamente una futura implementazione di componente e del run-timeall’aderenza ad un modello/standard fissato, in quanto gli standard esistenti non sono stati progettatiper ambienti ad alta performance e Grid. Si assume una definizione piuttosto generale, ma largamenteaccettata (Szyperski [2]):

“A component is an unit of composition with contractually specified interfaces and explicit context dependencies only. Acomponent can be deployed independently and is subject to composition by third parties.”

Lo stesso ed altri autori in lavori successivi raffinano in modi diversi il concetto, ma già da questadefinizione è possibile mettere in luce alcuni aspetti importanti di un modello a componenti:

• Un componente è l’unità atomica di composizione. Non si può assumere di poter raffinare ilcomponente in sottoparti allo stesso livello di programmazione (o dagli stessi programmatori1).

• Un componente ha interfacce chiare e definite. Queste permettono l’accesso alle funzionalità e nedefiniscono esplicitamente il contesto di uso. Cioè fornisce e richiede interfacce. Le interfacce sonodistinte secondo questo criterio in provided e required/used.

• La composizione è orizzontale. In generale non c’è una gerarchia verticale di inclusione oannidamento. Relazioni fra componenti quali quella di ereditarietà o implemented_by non sonoauspicabili.

Altre proprietà dei componentiAltre proprietà auspicabili dei componenti sono le seguenti:

• Polimorfismo delle interfacce (secondo quanto emerso dal Task4 e Task2-CCM).

1 Nella letteratura dei componenti a volte si distingue fra classi di programmatori piuttosto che fra livelli o macchine astratte.

5

• Le interfacce possono essere distinte secondo il loro uso tipico. Ad esempio in CCM si distinguealmeno fra interfacce di tipo RPC (facets/receptacles) e di tipo evento (event sink/source),entrambe in forma used e provided.

• Late linking, late binding. Deve essere possibile progettare e compilare una applicazione senza avereimmediata disponibilità di alcuni dei componenti della applicazione.

• Esistenza in sola forma binaria. È un requisito normalmente richiesto per ragioni commerciali,anche se ha alcune ricadute scientifiche, per esempio il fatto che un componente non è in generaleraffinabile/espandibile mediante ereditarietà.

• Unica identità, possibilità di avere versioni diverse, nessuno stato persistente. Non è possibiledistinguere istanze diverse di un componente. Alla base del requisito l’idea che un componentepossa essere rimpiazzato da un altro equivalente in modo abbastanza indolore nella progettazione diuna applicazione (il discorso non necessariamente si estende alla esecuzione di un’applicazione).

2.4 FrameworkIn un framework la parte della struttura di implementazione che è indipendente dall’applicazione vieneseparata dal codice specifico del programma, in modo da non essere mai direttamente modificata dalprogrammatore. Le interfacce dei componenti ed il coordinamento dei componenti stessi fanno partedelle funzioni proprie del framework.

Mantenere separati il codice di supporto e quello applicativo permette al programmatore di concentrarsisull’applicazione, e riduce la probabilità che i suoi errori “contaminino” codice che non è specificodell’applicazione. È importante sottolineare la differenza esistente tra framework e libreria: usando unalibreria, il programmatore codifica la struttura dell’applicazione, impiegando all’occorrenza funzioni diutilità generiche fornite dalla libreria. Al contrario, un framework mette a disposizione una strutturagenerica ed essenzialmente indipendente dall’applicazione, all’interno della quale sono inseriti moduli dicodice specifico dell’applicazione [3].

2.5 Web & Grid Services

2.5.1 HTTP + SOAP = Web ServicesCome descritto nelle parti di rassegna, un Web Service fornisce una porta accessibile mediante iprotocolli classici del Web finalizzata a fornire servizi ad applicazioni piuttosto che contenuti navigabilimediante un browser. Questi servizi sono accessibili attraverso Internet e sono generalmenteimplementati sopra il protocollo standard HTTP. Generalmente i Web Services accettano richieste eforniscono risposte codificate mediante messaggi SOAP (Simple Object Access Protocol), cioè messaggiASCII etichettati secondo uno schema XML (XSD). Lo schema XML ha alcune etichette fissate (tag),che devono comparire in un ordine fissato. Altre etichette possono essere definite in accordo ad alcunevarianti standard (ad esempio per la codifica dei tipi di dato). Il messaggio SOAP viene in genereimplementato sopra il protocollo HTTP, anche se alcune eccezioni esistono: in linea di principio unqualsiasi protocollo di trasmissione è possibile a patto che le parti siano d’accordo sul protocollo (adesempio l’interazione mediante remoting in piattaforme .NET). I Web Services possono esserepubblicati in indici gerarchici con ricerca per contenuto, di tipo pagine gialle (UDDI – UniversalDescription, Discovery and Integration). Il contenuto è in generale la descrizione via WSDL (Web ServiceDescription Language) dei servizi offerti.

6

Figura 1: Ciclo di vita di un Web Service

I Web Services rappresentano un’implementazione indipendente dalla piattaforma della chiamata diprocedura remota. Per questo costituiscono un mezzo adeguato per l’integrazione di applicazioni oparti di applicazione implementate mediante tecnologie diverse, o che girano su piattaformehardware/software diverse e non compatibili in modo nativo. Rimane al momento poco studiatol’aspetto performance, almeno nel caso che i messaggi SOAP siano implementati sopra HTTP (vedi ancheTask2). Si noti che in linea di principio altre, più efficienti implementazioni sono possibili (ad esempiodirettamente sopra TCP, come per il remoting di .NET). Alcuni framework di sviluppo quali Java2(EJB) e .NET agevolano molto lo sviluppo di applicazioni che forniscono o richiedono Web Servicesmediante l’offerta di classi finalizzate alla costruzione, codifica e decodifica di messaggi SOAP, iltrattamento delle condizioni di fault, ecc.

2.5.2 Web Services + Grid = Grid Services

La specifica OGSA (Open Grid Services Architecture) rappresenta il tentativo portare la tecnologiaWeb Services su piattaforma Grid. Globus Toolkit 3.0 è una implementazione OGSA. Le peculiarità deiGrid Services rispetto ai Web Services riguardano una maggiore espressività e standardizzazione deglischemi WSDL verso gli aspetti tipici delle Grid, in particolare: creazione e distruzione dinamica di GridServices, naming, gestione e descrizione delle condizioni di fault. Data la forte diffusione delmiddleware Globus Toolkit nell’ambiente di ricerca, potrebbe essere opportuno consideraredirettamente varianti Grid Services piuttosto che Web Services.

3 Grid & applicazioni: visione logica

3.1 MiddlewareAl livello più basso una Grid è un insieme di risorse di calcolo e memorizzazione interconnesse. Siassume che le applicazioni Grid siano definite sopra un certo numero di livelli di virtualizzazione comemostrato in Figura 2.

7

Figura 2: Corrispondenza fra lo schema a livelli proposto in [4] e i livelli tradizionali di unsistema

Ai fini della progettazione di un ambiente di sviluppo per le applicazioni è conveniente porsi ai livellialti di questa architettura software. In questo modo si può assumere di avere a disposizione tutti iservizi tipici di middleware, per esempio quelli di Globus toolkit (scelto per conformità ad uno standarddi fatto), e di poter risolvere alcuni dei problemi dell’ambiente per Grid proprio invocando i servizi delmiddleware, ad esempio:

• Autenticazione, single-sign-on, sicurezza delle comunicazioni.

• Ricerca e prenotazione delle risorse.

• Protocolli di trasmissione sicura, staging dei file.

In particolare al livello più alto dell’architettura si può immaginare un’applicazione su Grid comelogicamente composta da un insieme di processi comunicanti con struttura piatta. Una stessa Grid potràospitare più applicazioni contemporaneamente, la stessa risorsa di una Grid potrà ospitare più processidella stessa o di diverse applicazioni.

È importante rilevare come le primitive di middleware (almeno per il middleware Globus Toolkitbasato su Web Serivices) siano neutrali rispetto al modello di programmazione, la cui definizione èquindi completamente ortogonale rispetto ai livelli sottostanti [5].

Ovviamente questo non vuol dire che non sia possibile definire dei sottoinsiemi di risorse aventicaratteristiche specifiche, ad esempio risorse di calcolo di una certa potenza, disponibilità, o collegate dareti con una data banda o latenza. Si vuole però sottolineare che queste informazioni (anche se di bassolivello) possono essere formate e sintetizzate ad un livello più alto nella gerarchia di macchine virtuali,eventualmente in funzione di specifiche richieste dell’applicazione o del programmatore.

8

3.2 ApplicazioniA livello dell’applicazione si possono individuare una serie di entità sequenziali o parallele interconnessemediante canali aventi le caratteristiche fornite dal middleware. Il concetto di applicazione è importanteperché è l’entità minima su cui sono definiti una serie di servizi, fra i quali:

• Servizi per il loading e run dell’applicazione.

• Servizi per la gestione a run-rime dell’applicazione. Questi riguardano le politiche e le azioni chegarantiscono dinamicità, adattività, sicurezza e fault-tolerance.

In particolare si individua una entità logica detta Application Manager con il compito di gestire il ciclodi vita di una applicazione [6]. I servizi sopra descritti sono di pertinenza dell’Application Manager. Iservizi di gestione dovrebbero essere finalizzati a realizzare la strategia della gestione mediante azioni diconfigurazione e riconfigurazione dei componenti di una applicazione.

La gestione delle riconfigurazioni necessita delle informazioni/azioni che implementano la soluzione adun problema di gestione, limitatamente ad un fissato paradigma computazionale. Ad esempio sapendoche una parte della applicazione si comporta come un farm (o è un farm), una tattica di performancepuò essere quella di adeguare il throughput del farm ad un dato valore (non necessariamente ilmassimo) in modo da garantire una buona efficienza complessiva della applicazione. Le azioni diconfigurazione e riconfigurazione da intraprendere riguardano tipicamente la variazione del grado diparallelismo e/o ridondanza; le informazioni di configurazione riguardano il tempo medio di servizio, ilnumero medio di processori occupati, il carico dei sistemi coinvolti, ecc. Le informazioni e le azioni diconfigurazione sono compito tipico del framework. Il programmatore delle applicazioni deve poter assumere diavere a disposizione in modo primitivo le interfacce per esporre le azioni e le informazioni tipiche diun dato componente, che dipendono dal paradigma computazionale implementato dal componente. Ilprogrammatore può eventualmente sceglierle in un insieme pre-determinato, mascherarle, sottoporle avincoli, ma non definirle da zero. Questo può essere eventualmente compito di un programmatore cheagisce a più basso livello (al livello del framework). Rimane da valutare il rischio di una certa perdita diflessibilità dovuta alla mancanza di ereditarietà, quindi alla possibilità da parte del programmatore delleapplicazioni di modificare il comportamento delle interfacce di configurazione.

La strategia riguarda la politica di lungo termine che una applicazione persegue. L’idea è quella di averelogicamente una sola strategia, quindi un solo gestore per ogni applicazione. Come vedremo più avantiquesto gestore, che è logicamente unico, può essere anche distribuito. La strategia è application-specific, mentre le azioni di configurazione non lo sono, e sono legate ai paradigmi utilizzati percostruire l’applicazione. La strategia deve essere programmabile o configurabile dal programmatoredell’applicazione. Troviamo un esempio semplice ma significativo in XCAT [7]. Una applicazioneXCAT è controllata da una “applicazione di controllo”, generalmente un programma interpretato in unlinguaggio di scripting, in cui possono essere utilizzati alcuni servizi del framework, fra i quali:CreationService, ConnectionService, NamingService. Lo script di fatto descrive una strategia medianteun algoritmo e può creare, connettere e cercare componenti in risposta a specifici eventi che si sianoverificati. Nel caso di XCAT nessuna indicazione ulteriore viene fornita su come utilizzare questi servizi(non si distinguono i paradigmi computazionali dei componenti).

4 Alta performance ed aderenza agli standardUn punto fondamentale nel disegno di un ambiente di programmazione a componenti per il Gridriguarda la possibilità di costruire applicazioni ad alta/altissima performance. Questo aspetto vastudiato in modo comparato con l’adozione di eventuali standard per i componenti e per il Grid.Questo è particolarmente vero per la tecnologia a componenti. Il Grid al livello fabric è un sistemadistribuito. In linea di principio è possibile rendere efficiente sia la totalità delle applicazioni sia lasingola applicazione. Distinguiamo due approcci al problema.

9

Il primo approccio è quello di Condor [8], una Grid è considerato come un sistema operativo che devemassimizzare l’efficienza delle risorse. Le operazioni tipiche sono lo scheduling batch di job.L’efficienza delle comunicazioni (come banda e latenza) può rappresentare un fattore non dominante,in genere è possibile rendere i job arbitrariamente a grana grossa combinandoli in pacchetti. Approccisimili riguardano tutti quei casi in cui è necessario distribuire un lavoro per problemi di spazio(memoria, disco, etc). Un esempio analogo si trova nell’ambiente Xgrid della Apple. [9]

Il secondo approccio è più complesso, e può includere anche il primo. Si vuole rendere efficientel’esecuzione di una singola applicazione, mantenendo tutti i vincoli di unreliability e unsteadiness dellerisorse di calcolo e di comunicazione. Consideriamo per prima la performance. Come sappiamodall’esperienza maturata in programmazione parallela uno dei rischi è quello di raggiungere un rapportocalcolo/comunicazioni che rende non conveniente la parallelizzazione di un certo lavoro. In generale,come dimostrato da lavori diversi [10, 11], tanto meno le comunicazioni sono efficienti, quanto piùsono necessarie strategie di distribuzione, orchestrazione e scheduling dei dati e del calcolo efficaci, cheriescano a sfruttare la località. In molti casi questo è possibile solo mediante una scrittura moltoaccurata del codice, che si traduce in un approccio artigianale alla progettazione delle applicazioni:avere comunicazioni non efficienti e stabili porta ad uno svantaggio difficilmente colmabile che anzi ingenere viene ulteriormente peggiorato dall’esigenza di avere:

• Interfacce generali;

• protocolli di comunicazione indipendenti dalla piattaforma standard (XML, SOAP, …).

Le soluzioni possibili sono trade-off fra l’esigenza di utilizzare protocolli standard e risorse accessibilisolo mediante interfacce esplicite, e la necessità di avere primitive efficienti. Le vie percorribili sonodue, e non si escludono tra loro:

1. Aumentare l’efficienza delle interfacce, cioè del supporto delle sincronizzazioni/comunicazioni. Ingenerale gli standard (ad esempio CCA) definiscono i tipi delle interfacce, ma non forzano la loroimplementazione. Per esempio in CCM è possibile lavorare al livello di stub/skeleton (end-pointsdegli RPC, quindi delle comunicazioni) per rendere efficiente il passaggio dei dati. Si può pensare direalizzare in diversi modi i collegamenti fra interfacce e poi scegliere dinamicamente il metodo piùconveniente per ogni coppia di partner (late binding). Possono essere inclusi in questa visioneanche i collegamenti multipli fra componenti parallele. Questo tipo di soluzione porta ad un bassainteroperabilità ed è onerosa dal punto di vista della realizzazione perché deve supportare piùrealizzazioni su diverse architetture. Un esempio è l’implementazione di remoting nella piattaforma.NET, dove i messaggi SOAP vengono codificati in modo efficiente e implementati sopra unprotocollo di più basso livello rispetto allo standard HTTP. Altro esempio (anche se di naturadiversa) è Lithium+RemoteRMI [12], dove RMI viene modificato per passare riferimenti invece divalori in modo da ridurre la dimensione dei dati che transita sulla rete di interconnessione. In molticasi queste soluzioni necessitano di rendere stateful il protocollo di comunicazione (questo avvienenei casi citati).

2. Sfruttare la naturale gerarchia di una Grid. Eventuali insiemi coerenti di componenti per necessità dibanda, potenza di elaborazione, latenza di comunicazione vengono mappati in insiemi coerenti dirisorse Grid che hanno i necessari requisiti. All’interno di insiemi coerenti di risorse e/o dicomponenti si utilizzano implementazioni specializzate ed ottimizzate (eventualmente nonstandard).

Due esempi di utilizzo di entrambe le soluzioni sono i seguenti:

• CORBA+MPI dove insiemi di computazioni MPI si mettono insieme con meccanismi CORBA. Lecomunicazioni in insiemi coerenti di programmi MPI si realizzano in modo nativo, quelle frainsiemi programmando stub/skeleton per effettuare multicast/broadcast direttamente fra processiMPI. Al livello di programmazione la gerarchia si specifica specificando array distribuiti e processiSPMD parametrici su questi [13, 14].

10

• ASSIST a vari livelli.

o Computazioni interne ad un parmod possono utilizzare meccanismi di comunicazioneprimitivi dell’ambiente (ad esempio via memoria condivisa), la realizzazione di questimeccanismi è ottimizzata in funzione della specifica piattaforma (sistema operativo,architettura).

o Computazioni fra parmod fra componenti ASSIST possono beneficiare di implementazionidi interfacce di comunicazioni ottimizzate.

o Il caricamento di componenti ASSIST su nodi di una Grid di natura diversa comporta laselezione automatica delle primitive più efficienti per la specifica configurazione (adesempio si utilizza XDR in caso di piattaforme eterogenee e comunicazioni native in caso dipiattaforme omogenee).

o Il mapping degli insiemi di componenti che comunicano via Web Services dovrebbe esserefatto (nel prossimo futuro) tenendo conto delle naturali relazioni di gerarchia e coerenzadelle risorse target.

Particolarmente critiche sono le interfacce di tipo Web service. Infatti in genere si suppone che questeutilizzino formati di dati XML/SOAP altamente inefficienti in spazio. Ipotizzando un programmingmodel gerarchico interfacce Web server potrebbero essere esposte verso link non critici dal punto divista della latenza/banda o comunque cercando di mantenere il rapporto calcolo/comunicazioni alto ininsiemi che espongono interfacce inefficienti.

5 Progettazione a componenti: l’esperienza ASSISTSi propone una rilettura a componenti del supporto run-time di ASSIST [15] finalizzata all’individuazionedelle peculiarità desiderabili dei componenti nel caso di applicazioni high-performance. Nella sezione sidescrive ed analizza il compilatore ASSIST (nella versione 1.2 quando non diversamente specificato [16,17, 18]) e il suo supporto run-time in termini di candidati componenti funzionali a partire da un“generico” modello di componenti. In particolare si forniscono:

• schema globale del supporto;

• schema funzionale del singolo nodo;

• disegno delle relazioni di dipendenza fra oggetti nell’attuale framework.

Strategicamente, la riprogettazione è un lavoro speculativo finalizzato a capire i pro/contro dellaprogettazione di un sistema complesso basato su componenti. Il case study di sistema complesso èASSIST e il suo run-time support.

ASSIST nella versione 1.2 è stato progettato con una metodologia Object Oriented. Come detto unframework di componenti può essere considerato come un framework OO in cui alcune entità (classi)hanno ulteriori caratteristiche, come la dipendenza da un contesto esplicito. Assunto questo, l’idea baseper la riprogettazione di ASSIST consiste nel descrivere il framework OO del disegno attuale e neltracciare un piano di migrazione verso un framework componenti+oggetti. Il piano di migrazionerichiede di caratterizzare le entità nel progetto attuale e capire quali di queste possono esseretrasformate in componenti.

La riprogettazione mantiene inalterate le funzionalità di ASSIST 1.2 e del suo supporto run-time. Loschema di framework a componenti, anche se non progettato per una diretta implementazione su Grid,non deve contenere elementi che ne impediscano la migrazione verso il Grid. Deve inoltre mantenerela caratteristica di ambiente per applicazioni high-performance, di interoperabilità con altri strumenti elinguaggi standard di sviluppo.

11

5.1 ASSIST overviewUn programma ASSIST viene tradotto in un insieme di codici eseguibili in più fasi. Descriviamobrevemente le entità presenti in ASSIST al livello di linguaggio (parmod), quindi come vengonocompilate.

5.1.1 LinguaggioUn programma ASSIST [15] è costituito da un grafo di moduli paralleli (parmod) e sequenziali (seqmod).Gli archi del grafo rappresentano stream di dati. Oltre che mediante gli stream, più parmod possonointeragire accedendo a oggetti esterni, cioè entità esterne ai parmod che possono includere uno statopersistente: queste possono essere sia oggetti che semplici zone di memoria. ASSIST fornisce unmeccanismo primitivo per l’accesso agli oggetti esterni (shared). Inoltre il programmatore può utilizzaremeccanismi non primitivi di accesso agli oggetti esterni (librerie DSM, server CORBA o altro). In talcaso l’accesso, la sincronizzazione, la consistenza degli oggetti esterni è a carico del programmatore eavviene attraverso meccanismi non primitivi del linguaggio ASSIST immersi nel codice utente. Attivitàin parmod differenti possono essere concorrenti/parallele fra loro. Il paradigma più evidente diparallelismo fra parmod è il pipeline (esteso a DAG o grafi).

Un parmod può esprimere attività concorrenti/parallele anche al suo interno. In questo caso ilparallelismo esprimibile è sostanzialmente di due tipi:

• Farm-like, corrispondente alla topologia none. Nel caso siano dichiarate variabili di stato del parmodqueste sono “replicate” su ogni Virtual Processor (VP). Le copie non vengono mai riconciliate(sincronizzate) quindi costituiscono una “memoria persistente” del VP. Ad esempio è possibilecontare il numero di task che fluiscono attraverso un VP, dato che la sua copia di una variabile distato rimane persistente. I VP possono anche condividere variabili shared, che saranno allocate insingola copia in modo trasparente e direttamente accedute dal codice sequenziale.

• Data-Parallel-like, corrispondente alla topologia array. Le variabili di stato sono distribuite nelle entitàdel supporto che implementano i gruppi di VP (VPM) secondo una semplice strategia “a strisce”(non configurabile). Per queste variabili vale la “owner-computes rule”: la topologia descrive qualiVP possiedono quali indici dell’array. Le variabili di stato sono riconciliate con una sincronizzazioneglobale al parmod alla fine di ogni ciclo del loop. Le variabili shared si comportano come nel casoprecedente.

• Mixed Data-Parallel & Farm, i due tipi di parallelismo possono essere scelti nondeterministicamentein base ai dati e allo stato della computazione. Le modalità di funzionamento sono ereditate dai duemodelli precedenti.

In definitiva ASSIST nella versione 1.2 può essere descritto come un ambiente che esprime ilparallelismo secondo due livelli gerarchici:

• fra diversi parmod;

• all’interno di un parmod.

Il primo descrive un grafo data-flow. Il secondo può esprimere sia computazioni basate su domain-decomposition di tipo Data-Parallel, sia con replicazione funzionale di tipo farm. La computazioneviene descritta mediante un insieme di proc che incapsulano il codice utente sequenziale e che sonoorganizzate secondo una forma di parallelismo descritta dal tipo di parmod (a sua volta descritta dalleentità a livello di linguaggio, quali guardie, topologia, ecc.).

5.1.2 CompilazioneLa compilazione di un programma ASSIST consiste essenzialmente in tre fasi:

12

1. Applicazione ASSIST grafo di task-code. Task-code è un linguaggio intermedio in cui è possibiledescrivere una rete (grafo) di nodi task-code che globalmente costituiscono il run-time support diASSIST. Esistono due tipi fondamentali di nodi task-code: sequenziale e parallelo-SPMD.Quest’ultimo è in grado di esprimere parallelismo di tipo multithreaded e può essere organizzato ingruppi omogenei di repliche di uno stesso nodo secondo il paradigma SPMD. Il parmod contopologia one viene tradotto in una rete di due nodi sequenziali (Figura 3 a). Il parmod paralleloviene tradotto in una composizione notevole di nodi task-code (template) in funzione del tipo diparmod. I parmod con topologia none e array vengono tradotti in una rete con tre o più nodi, dicui due sono nodi sequenziali e uno o più sono nodi paralleli (Figura 3 b). In Figura 3 i processi disupporto sono indicati con il colore grigio.

Figura 3: Schema a processi. a) parmod one b) parmod none e array.

2. Configurazione dei nodi. I nodi task-code vengono inizialmente descritti in linguaggio task-code.Ogni nodo task-code viene successivamente tradotto in un insieme di classi e oggetti che descriveun processo del supporto run-time. Ognuno di questi processi gestisce un processing element. Lagenerazione delle classi di un nodo task-code avviene arricchendo e configurando un unico schemacomune a tutti i nodi task-code (sia di tipo sequenziale che parallelo). Questo schema rappresentaun punto fondamentale nel percorso di riprogettazione perché può essere messo in relazione con ilconcetto di componente.

3. Rete di nodi task-code rete di processi. La rete di processi vera e propria si ottiene compilando larete di nodi task-code (ognuno dei quali è descritto da un framework di classi C++).

Alla fine della fase 2 della traduzione possiamo descrivere un’applicazione ASSIST con un disegno adue livelli. Un primo livello relativo alle relazioni fra parmod e seqmod descrivibile come un grafo.Ogni parmod è a sua volta tradotto in una grafo (diretto aciciclo) di nodi task-code. I due livellivengono quindi appiattiti in un solo livello producendo un grafo di nodi task-code. Ognuno di questinodi viene generato da uno schema comune che descriviamo nel prossima sezione.

5.2 Lo schema del nodo task-codeCome detto tutti i nodi task-code sono specializzazioni di un unico schema. Descriviamol’implementazione dello schema di nodo task-code in due passi, partendo dalla descrizione più astrattafino alla più concreta:

1. Il funzionamento del generico nodo task-code.

2. L’implementazione del generico nodo task-code come framework di classi.

5.2.1 Il funzionamento del nodo task-codeDescriviamo il funzionamento dello schema di nodo task in Figura 4, dove i box bianchi possonoessere messi in relazione con sottosistemi (implementati da oggetti in unica copia o classi) del nodo

13

task-code. I box a strisce diagonali (elab) rappresentano oggetti che vengono definiti durante la fase dicompilazione (quindi non sono sempre uguali, ma a loro volta sono definiti configurando uno schemacomune di più basso livello, che non descriviamo). Tipicamente questi sottosistemi includono codiceutente. Le altre forme sono di ausilio alla definizione del comportamento dello schema e in generalepossono essere messe in relazione con meccanismi di più basso livello. Lo schema è in realtà unprogramma parzialmente definito (con alcuni buchi) che viene completato nella fase 2 di compilazione(riempire i buchi con codice).

Figura 4: Funzionamento di un nodo task-code

In breve il funzionamento del nodo task-code è il seguente.

In presenza di un token su uno stream di input le guardie (incluse nei blocchi elab) vengono valutate insequenza. La prima guardia che risulta verificata porta alla esecuzione del codice associato. Questocodice può essere codice utente (nel caso di nodo parallelo) oppure codice di supporto (nel caso di ISMil codice che implementa una distribution). In ogni caso eventuali guardie contemporaneamente verevengono valutate (e il loro codice eseguito) in sequenza.

Nel caso parallelo, il codice associato ad una elab è cablato al suo interno come un array di riferimenti atask. I task dell’array sono eseguiti in sequenza, una barrier viene sempre eseguita fra l’esecuzione di duetask. Ogni task può a sua volta essere composto a una lista di proc che possono essere eseguiteconcorrentemente (multithreaded). In Figura 4, [f1 | f 2] rappresentano un task, mentre f1 e f2 sonoproc. Un task può essere composto da più proc se e solo se queste appartengono a differenti VP set nelparmod origine.

Al momento dell’esecuzione di un task la scatola elab di competenza raccoglie i sui parametri di input(attraverso altri sottosistemi non descritti, che tipicamente possono accedere alla rete, ad esempioSMUSystem), quindi spedisce riferimento al codice e dati ad un Processor Engine che implementa un pooldi esecutori con scheduler che esegue task. L’esecuzione di proc diverse può procedere su threadconcorrenti/paralleli. Dentro il Processor Engine anche un singolo task può essere eseguitoconcorrentemente (solo nel caso che questo task in realtà corrisponda all’esecuzione di un set di VP,cioè nel caso che il task rappresenti un VPM di un parmod array).

14

Una volta completato il task il modulo elab riceve un ack (task done), e si procede a sincronizzare i noditask-code interessati all’esecuzione: tipicamente i nodi paralleli che condividono lo stato nel caso diparmod array (mediante una barrier); oppure delle control variables nel caso di nodi ISM/OSM. Eventualivariabili di out presenti in costrutti ASSIST_out vengono spedite verso output controller durantel’esecuzione. A questo punto le variabili di out vengono spedite al modulo output controller, che fungeda serializzatore di output.

5.2.2 Nodo task-code: classi oggetti e loro relazioni di usoFacciamo un passo ulteriore verso l’architettura concreta del nodo task code. Questo è in realtà unaclasse (process template) che viene “scritta” dal modulo builder del compilatore. Questa classe ha duemetodi: init e run.

Il metodo init si provvede ad inizializzare il nodo task-code e in particolare ha il compito di configurareadeguatamente le sezioni dell'architettura del nodo che sono sensibili alla configurazione dinamica delsistema, che nel nostro caso e' soltanto la variabilità del numero dei nodi generici paralleli (VPM)presenti nella rete dei processi. Il dinamismo del supporto si limita quindi solo alla fase di caricamentoed inizializzazione, non e' possibile al momento ri-configurare durante la fase di run un qualsiasi nodogenerico.

Ad esempio in questa fase si decidono i rank dei nodi nella architettura complessiva, si aprono i canalidi comunicazione e inizializza i sottosistemi.

Il metodo run descrive il comportamento a regime del nodo task-code. I due metodi vengono chiamatiin sequenza. La terminazione del metodo run corrisponde alla terminazione dell’applicazione.

5.2.3 Fase di runDopo essere stato inizializzato il nodo generico entra in una fase di run. In questa fase sono coinvoltesia entità addette al controllo del sistema che all'esecuzione parallela/concorrente di procedure ofunzioni. Queste entità sono suddivisibili in sottosistemi con singole istanze (eventualmente attivi, cioèmultithreaded) o con istanze multiple tra cui e' possibile identificare due ulteriori: quelli instanziatistaticamente e quelli il cui numero di istanze e' variabile con la configurazione del sistema. Durante lafase di run il nodo generico essenzialmente esegue il seguente ciclo:

while( run not terminated ) {

wait for a stream notification; // non-deterministic way

if (guards condition enable elaboration) {

for each i from (elaboration instruction list) {

get all data values (parameter) needed by i;

parallel/concurrent execute task(i, values);

wait for all task done;

commit state changes and output to stream;

}

};

}

Il ciclo si ripete fino a quando esistono stream attivi ed esiste almeno una guardia abilitata.

Riportiamo lo schema di relazione fra classi e oggetti durante la fase run e successivamente ladescrizione dettagliata dei sottosistemi (Figura 5):

15

Figura 5: Relazioni fra classi e oggetti durante la fase di run di un nodo generico

16

Input-Controller ComponentÈ un componente a singola istanza che gestisce e controlla le attivazioni di elaborazioni; in funzione deivalori notificati da altri componenti addetti al trasporto dei dati (Stream Component) e al risultato delleespressioni delle guardie decide di attivare una elaborazione. Contiene al suo interno una tabella dielaborazioni attivabili da espressioni. La valutazione delle espressioni necessita della notifica dellapresenza di dati oltre che dei valori delle variabili di controllo. Non e' un componente attivo ed utilizza iservizi di Condition-Var Component e delle varie istanze di Elaboration Component.

Stream ComponentSono i componenti che gestiscono la corretta acquisizione o il corretto invio di messaggi e dati tra nodiin accordo a varie politiche e protocolli. Ogni Stream Component ha la possibilità di essere configuratocome consumer o producer, i consumer notificano la presenza del dato al componente a loro collegato(Input Controller) mentre i producer non hanno tale funzionalità. Esistono diversi tipi di StreamComponent:

• Point2Point collega due nodi generici producer e consumer.

• Scatter collega un producer con n consumer e suddivide il dato fornendone una parte ad ogniconsumer.

• Broadcast collega un producer con n consumer fornisce l'intero dato a tutti i consumer.

• Queue collega un producer ad n consumer e realizza una coda distribuita con operatori get e put.

• All collega n producer ad un consumer ed attende un dato da ogni singolo producer, fornendo ildato aggregato

• Any collega n producer ad un consumer ed attende un dato da uno qualsiasi dei producer senzaeffettuare alcuna aggregazione. Al momento è possibile che esistano più istanze dello stesso StreamComponent ma sono comunque istanze statiche.

Condition-Var ComponentÈ il componente che racchiude al suo interno la gestione dei valori di tutte le variabili di controllo. IlCondition-Var Component gestisce la coerenza dei valori poiché le variabili potrebbero essere lette omodificate da diversi nodi generici. Per consentire la condivisione dei valori con funzionalità di lock eunlock il componente fa uso di un proprio canale raw per le comunicazioni.

Elaboration ComponentIl componente racchiude e gestisce il flusso computazionale collegato ad una elaborazione. Ha al suointerno una lista di azioni o istruzioni che devono essere eseguite anche in modalitàconcorrente/parallela (chiamata di procedura, synch, cicli for e while, assist_out).Prima di eseguire ognisingola azione si preoccupa di disporre di tutti i dati necessari al calcolo dell'azione, che possono essere:valori provenienti da stream forniti da Input-Controller Component o valori di stato che può richiede allecomponenti SMUSystem delegate alla gestione degli attributi distribuiti. Una volta preparato un task(coppia azione + valori) ne richiede l'esecuzione al Processor-Engine Component il quale le elaborerà inparallelo (se il nodo e' caricato su una macchina SMP) o concorrentemente (se su singoloprocessore).Elaboration Component non attende la fine dell'esecuzione del task ma continuerà a forniretask al Processor-Engine Component fino ad esaurire le potenziali azioni parallele. Una volta prodotti i taskda elaborare Elaboration Component si mette in attesa del completamento delle azioni. ElaborationComponent non è un componente attivo. Nonostante che il nodo generico possa aver instanziato piùElaboration Components, ogni istanza ha una lista distinta di azioni da eseguire. Quindi, pur mantenendouna comune funzionalità e interfaccia gli Elaboration Components eseguono procedure parallele diverse.

17

Processor-Engine ComponentE' il componente che si occupa dell'esecuzione parallela (in presenza di sistema SMP) o concorrente ditask. Il componente è attivo, ovvero ha dei flussi computazionali indipendenti (threads), ma può essereconfigurato anche come componente passivo (singolo thread). Il componente mantiene in una coda itask da elaborare ed utilizza un numero prefissato di thread attivi (scelti da thread pool) per schedularele computazioni. Il numero di threads nel thread pool può cambiare dinamicamente per rifletterevariazioni del carico computazionale richiesto.

SMU-System ComponentÈ il gestore ottimizzato dello stato distribuito tra nodi generici. Un nodo generico può avere diversiattributi distribuiti di dimensioni e tipo distinti. Lo stato distribuito gestito dagli SMU-System Componentsadotta la “owner-computes rule” e consente la scrittura soltanto al possessore del dato, mentre la letturaè sempre ammessa. Ogni componente SMU-System collabora con gli altri presenti negli altri nodigenerici che compongono l’applicazione. Lo SMU-System colleziona tutte le richieste provenienti daicomponenti di un nodo, localizza il possessore delle varie richieste e prepara il messaggio da inviare aivari collaboratori combinando e compattando richieste e dati in un unico messaggio. Non è necessarioche le operazioni tra SMU-System siano sincronizzate ma è possibile richiedere operazioni in modoasincrono, per tale motivo il componente è attivo. Data la estrema variabilità e strutturazione delmessaggio, lo SMU-System utilizza un canale particolare SMUChan che implementa un protocollobasato su ACT (Asyncronous Completion Token) oltre che ricevere e spedire su buffer multipli evariabili. Le operazioni esportate dallo SMUSystem sono: fetch, commit e syncronize. Le prime due nonrichiedono sincronizzazione mentre la terza la richiede. La fetch legge tutti i dati richiesti compresiquelli non detenuti dal nodo, mentre il commit scrive i nuovi valori sulla partizione di stato di proprietàdel nodo. La syncronize necessita della collaborazione di tutte le SMUSystem; è un'operazione simile allafetch ma è atomica (funzionalmente simile alla sequenza barriera;fetch;barriera).

Shared-Variable ComponentConsente l'accesso libero in lettura e scrittura a variabili condivise. Non implementa nessun tipo di locko unlock al dato. L'attuale implementazione si basa sulle Reference della libreria DVSA. Le operazioni chepossono essere richieste a questo sistema sono get e put.

Output-Controller ComponentE' il componente addetto alla gestione dell'output sugli stream. L'emissione di un messaggio da inviaresu uno stream puo essere richiesta sia da un task che sta eseguendo una procedura utente sia da unaElaboration. Questo sottositema controlla e serializza le richieste da inviare sullo stream.

6 Programming Model: un possibile scenarioPer quanto detto l’ambiente ASSIST può essere fatto evolvere abbastanza rapidamente verso unambiente a componenti (ASSIST 2). Inoltre l’ambiente ASSIST rappresenta un buon punto di partenzaper la progettazione di un ambiente a componenti high-performance per Grid anche perché permettedi riutilizzare numerose esperienze fatte in altri progetti, fra le quali:

1. il supporto ad applicazioni parallele ad alte prestazioni (scheduling, mapping, efficienza dellecomunicazioni);

2. l’interoperabilità con ambienti quali CORBA e CCM (attualmente in fase di sviluppo);

3. il supporto run-time per applicazioni su architetture eterogenee.

In questa sezione presentiamo in dettaglio una possibile caratterizzazione funzionale dei componentiutile a costruire un ambiente per Grid. Nella sezione 6.5 questi concetti verranno integrati ad ASSISTper formare una proposta di ambiente di sviluppo a component per Grid.

18

Il modello di programmazione a componenti opera sopra allo strato di middleware di griglia, quindidispone di tutti i servizi di Globus. Le applicazioni si appoggiano su un framework per laprogrammazione a componenti ad alte prestazioni, che incorpora i servizi del middleware. Unaapplicazione può essere così descritta:

• In ogni istante è un insieme di componenti e di relazioni fra componenti. I due insiemi sonorappresentabili con un grafo, la cui forma può evolvere durante la vita dell’applicazione. Lastruttura iniziale dell’applicazione (grafo) è specificata.

• I componenti possono utilizzare i servizi del framework. Tutti componenti dell’applicazionedevono includere un insieme minimo di funzionalità di configurazione. A differenza del CCM leinterfacce di configurazione sono usate dinamicamente, quindi non vengono disattivate all’avviodell’applicazione.

• Inoltre, nell’insieme dei componenti di una applicazione possono essere distinti alcuni sottoinsiemi,non necessariamente disgiunti, con ruoli coerenti. Fra questi sono significativi:

o Computational units (parallel/sequential). Componenti internamente paralleli o sequenziali cheimplementano la logica della applicazione. Il codice dei componenti paralleli dovrebbeessere parametrico nel grado di parallelismo ed altri parametri fondamentali.

o Storage. I componenti finalizzati alla memorizzazione di dati.

o Strategy (Application Manager). Definiscono la strategia di gestione dell’applicazione.

Un’applicazione può dialogare in modalità client-server con altre applicazioni sia come client sia comeserver. I partner di comunicazione non sono considerati parte integrante dell’applicazione e possonoessere anche componenti sviluppati utilizzando altri framework. L’applicazione si può comportarecome client o come server rispetto ai partner. Il dialogo dell’applicazione con i partner sarà delegato aisuoi componenti secondo modalità da descrivere al livello dell’applicazione. Ad esempio si pensi adun’applicazione di tipo farm di web server, in generale sarà l’applicazione a decidere a quali componentismistare le sessioni di richieste.

Riassumendo, un’applicazione è composta da un insieme di componenti tra loro interconnessi e porteverso servizi esterni all’applicazione. I componenti sono organizzati in un grafo dalla configurazioneiniziale del grafo specificata, ma la cui struttura può evolversi dinamicamente. I componentidell’applicazione devono avere un insieme minimo di interfacce comuni per poter controllare lariconfigurazione, ed esiste un’entità Application Manager che fa leva su queste interfacce comuni pergestire l’applicazione.

6.1 Application ManagerCome detto ogni componente del framework in esame include almeno un insieme minimo di interfaccededicate alla configurazione. Queste sono inserire automaticamente dal compilatore a partire dal “tipo”di componente (vedi Figura 1 e rassegna sugli ambienti a componenti).

19

Figura 6: Sviluppo di componenti: a) CCM b) Java beans

Componenti che esplicitano paradigmi di parallelismo diversi (ad esempio stream parallel rispetto a dataparallel, regolare o irregolare) possono esporre insiemi diversi di interfacce di configurazione. L’insiemedelle interfacce di un componente è esplorabile mediante un'interfaccia (obbligatoria) di introspezione.Come detto l’Application Manager è logicamente un'unica entità che si occupa di lanciare, configurare egestire un'applicazione. Proprio per le caratteristiche del Grid è opportuno considerare unarealizzazione distribuita dell’Application Manager. Una applicazione è un grafo. Al momento dellaunching l’Application Manager si occupa di recuperare le risorse, creare i componenti, effettuare icollegamenti fra i componenti, quindi di “ascoltare” l’applicazione ed eventualmente riconfigurarla.L’operazione di riconfigurazione può consistere nell’interazione con un componente, come nelcambiamento della forma del grafo. Dunque al momento del launch l’Application Manager non puòche essere uno (un flusso di controllo).

Effettuato il launch uno spettro di soluzioni può essere considerato, da quella completamentecentralizzata a quella completamente distribuita:

1. Centralizzata. L’application manager è un componente che dovrà mantenere contatti con tutti glialtri componenti.

2. Completamente distribuita. Ogni componente ha il suo application manager, che coopera con tuttio alcuni degli altri application manager.

3. Mista. Ad ogni Application Manager è assegnata una partizione del grafo. Gli Application Managercomunicano fra di loro, eventualmente in modo gerarchico. Ricade in questa classe anche il caso distrategie 2-tier in cui alcune funzionalità dell’Application Manager vengono implementate in mododistribuito ed altre in modo centralizzato.

Nelle soluzioni 2 e 3 è necessario stabilire una partizione opportuna del grafo e realizzare una strategiacome un algoritmo distribuito. Supponendo di aver progettato l’applicazione come un grafo lineare, ipossibili scenari sono descritti in Figura 7.

20

Figura 7: Application Manager nelle versioni centralizzata, distribuita e mista

21

La struttura gerarchica è particolarmente interessante. Permette una realizzazione:

• Distribuita, con possibilità di recovery da errori nel caso di fault di risorse, autonomia di decisionein caso di indisponibilità temporanea di link.

• Sottografi densi o ad alta variabilità possono essere sottoposti a controllo centalizzato generalmentepiù efficiente per i problemi a grana fine (il problema è la gestione, non l’algoritmo).

• Permette di sfruttare la naturale gerarchia di risorse del Grid.

6.2 Definizione dei ComponentiL'obiettivo è definire un modello di componente generico e di alto livello, che offra la possibilità discrivere applicazioni distribuite adattive. Vogliamo poter utilizzare più linguaggi sequenziali e paralleliesistenti per l'implementazione dei singoli componenti, quindi per quanto possibile la definizione delcomponente non deve vincolare l'implementazione del componente o il suo run-time.

Il codice “ospite” del componente può variare notevolmente, per grana di calcolo, complessità direalizzazione e tipo di run-time necessario, ma soprattutto deve poter essere sia programma parallelocompleto sia un componente di un framework differente. Il modello del componente ed il suosupporto a tempo di esecuzione sono guidati dalla necessità di sfruttare le funzionalità di componentipiù sofisticati e mantenere compatibilità ed efficienza di interfacciamento nei casi più semplici.

Figura 8: Schema astratto di un componente

In Figura 8 è rappresentato schematicamente modello di componente. Nella prossima sezione (6.2.1)presentiamo in dettaglio le interfacce RPC, eventi e stream. La sezione 6.2.2 è dedicato alla descrizionedelle interfacce di configurazione.

In generale per componenti provenienti da altri framework possiamo comunque definire appropriatiwrapper che adattino le funzionalità che hanno implementazione diversa, o che forniscano funzionalitàminimali per le operazioni non supportate (vedi sezione 6.3.1).

6.2.1 Interfacce di comunicazioneNella costruzione di un componente il tipo di un metodo di una interfaccia dipende anche dallamodalità di interazione associata. La maggior parte dei modelli a componenti orientati al client-serverprevede come classe di interfacce principale la classe uses-provides con semantica di chiamata remota

22

di procedura (RPC). La semantica RPC però non è in generale adeguata al calcolo ad alta performanceed alla comunicazione tra sistemi internamente o esplicitamente paralleli.

Introduciamo nel modello di componenti più classi di interfacce: RPC, stream ed eventi. Esse sidistinguono per le caratteristiche dell'interazione, e quindi per la struttura che conferiscono alprogramma e la possibilità di ottimizzare in maniera differente i vari aspetti dell'interazione. In generale,l’interfaccia di un componente potrà contenere più metodi appartenenti a classi diverse.

• interfacce RPC hanno la consueta semantica della chiamata di metodo/procedura remota.Essenzialmente il componente che usa (use) la funzionalità cede il flusso di controllo al componenteche la mette a disposizione (provide); la specifica dell'interfaccia definisce sia il tipo delle richieste che deirisultati restituiti, e la composizione delle componenti segue il flusso di controllo dell'applicazione.

• interfacce stream permettono la comunicazione di un flusso di (pacchetti di) dati in modo continuo eunidirezionale tra due componenti; la semantica dell'interazione tra i due componenti èfondamentalmente data-flow, con comunicazione unidirezionale e non necessariamentesincronizzata. La semantica più semplice permette di sviluppare modelli di performance più accurati(p.es. reti di code), e di misurarne i parametri (banda, latenza, tempi di servizio) a tempo diesecuzione. In molti casi ciò consente una migliore ottimizzazione statica e/o dinamica(sovrapposizione calcolo/comunicazioni, esecuzione in parallelo). La presenza di interfacce streampermette di strutturare l'applicazione in modo da sfruttare meglio la banda di comunicazione inpresenza di latenze di comunicazione elevate, nonché di applicare alla rete di code associataottimizzazioni in parte già note dalla programmazione parallela e distribuita.

• Eventi. In diversi modelli di componenti sequenziali esiste la possibilità di generare in modoasincrono eventi, che possono essere inviati automaticamente ad un insieme di moduli registrati. Lanecessità propria del Grid Computing di gestire a tempo di esecuzione un elevato livello didinamicità (variazioni di carico e risorse, fallimenti) può sfruttare gli eventi come metodo generaledi notifica tra componenti dell'applicazione e con i componenti dello Application Manager. Il livelloastratto di specifica di ciascun componente dichiara gli eventi che può emettere (oltre ad un insiemedi eventi standard comunque previsti dal supporto del componente), quelli che intende ricevere(eventualmente sostituendosi all'azione standard prevista dal supporto) e quale parte della suaimplementazione è delegata a riceverli.

Attributi delle interfacceLe interfacce possono avere attributi non legati al tipo del dato comunicato o al tipo di interazione; taliattributi possono essere legati all'interfaccia del componente o al connettore usato (vedi sezionesuccessiva). In particolare per le interfacce stream e per le RPC ha senso distinguere gli attributi:

sincronia: il trasferimento dati può essere sincrono e/o asincrono; notiamo che le porte RPC sidistinguono comunque dagli stream completamente sincroni per il fatto che il supporto puòassociare richiesta e risposta.

dependability, sicurezza: informazioni necessarie a generare il codice di supporto.

6.2.2 Interfacce di configurazioneUn certo insieme di interfacce di configurazione, oltre a quelle liberamente definite dal programmatore, sonorichieste al componente dal supporto del modello; queste sono ulteriormente classificabili come:

• interfacce di introspezione, finalizzate a fornire informazioni all’Application Manager;

• interfacce attive, che permettono la riconfigurazione del componente.

Le funzioni di misurazione delle prestazioni, QoS e dependability sono integrate in tutte le interfaccedel componente e fanno parte del supporto del componente stesso. I contratti relativi, i modelli diperformance e i requisiti sono analogamente associati a tutte le interfacce; la compilazione delcomponente provvede ad inserire le informazioni necessarie nel supporto del componente, nelle sue

23

proprietà visibili nel component repository e quindi ai componenti che vi si interfacciano / al controllodell'applicazione che lo usa.

Interfacce Attive. Sono le interfacce di controllo associate al componente; esse hanno la possibilità diregolare i parametri dell'implementazione del componente e/o del suo supporto. Sono un insiemeprestabilito fissato dal modello, che ogni componente può implementare o no; il compito richiestoall'interfaccia attiva può perciò essere realizzato in modo automatico (codice generato dalcompilatore a partire dalla specifica di interfaccia del componente), o anche da politiche specificatenell'implementazione dello stesso componente (codice utente collegato al supporto delcomponente). Come già anticipato, per i componenti che lo supportano le interfacce diconfigurazione possono anche provocare un cambiamento di struttura interna dell'elaborazione.

Interfaccia di Introspezione. Come in altri ambienti a componenti, deve essere possibile interrogare uncomponente a run-time riguardo le funzionalità fornite. Fanno parte delle informazioni disponibiliper la introspezione anche la disponibilità o meno di parametri di performance, Quality of Service edependability, e l'esistenza di metodi adatti a modificare e controllare questi parametri o le politicherelative nell'implementazione del componente: in altre parole la descrizione dei parametriosservabili e delle interfacce attive rese disponibili dal particolare componente.

Esempio: un componente internamente parallelo misura la sua performance su di un particolare metodofornito (supporto delle interfacce); la performance viene richiesta al componente (interfaccia diconfigurazione), e dall'esterno (siamo in un caso semplice) viene determinato un aumento del grado diparallelismo interno al componente. L'interfaccia di configurazione del componente può essere ingrado o meno di gestire il cambiamento (l'informazione è disponibile tramite introspezione); ilcambiamento può essere realizzato semplicemente dal supporto (p.es. parallelismo in un farm senzastato) o richiedere del codice specializzato nell'implementazione del componente (per esempio unaridistribuzione ottimale di dati in una struttura dati dinamica).

6.3 Componenti Standard e Componenti Specializzati

6.3.1 Integrazione fra Standard di ComponentiI componenti di ogni tipo devono essere generabili dal compilatore dell’ambiente di programmazionein oggetto (diciamo A). Vogliamo che questi componenti siano aderenti a un qualche standard, peresempio CCA/Beans (diciamo B), quindi integrabili con componenti sviluppati e compilatiseparatamente dall’ambiente A. Sono possibili diverse soluzioni:

1. Inclusione. Si includono nel framework di A tutte le primitive, le interfacce e i tipi forniti da B. Icomponenti nativi-B non saranno sotto il controllo dell’application manager di A, a meno cheanche B abbia un application manager; in tal caso si può procedere ad un analogo wrapping allivello di application manager. Ad esempio se A è il futuro ASSIST e B è il CCA/XCAT si puòincludere l’applicazione di controllo dentro un componente e integrare i servizi di B con quelli di A.

2. Adaptor. Si realizza un adaptor fra A e B, l’interfaccia esposta dall’adaptor è conforme a B, quellainterna conforme ad A. L’application manager di A potrà controllare direttamente solo icomponenti conformi ad A e gli adaptor AB, che dovranno mappare gli eventi interessanti di A inB e viceversa. (Vedi Figura 9)

3. Si rinuncia all’integrazione totale. L’integrazione fra A e B avviene tramite Web o Grid Services(Vedi Figura 9). Questa soluzione è in linea di principio indipendente dal tipo di piattaforma.Inoltre, dato che l’ambiente è progettato sopra i servizi di middleware, il progettista dell’ambientepuò in teoria contare su set di classi/funzionalità a supporto dei Grid Services. Queste includonotutti i meccanismi di costruzione di messaggi SOAP, come il naming e il lookup dei Services. Èimportante notare che i Web e Grid Services permettono l’integrazione di sistemi diversi perhardware e sistema operativo mediante la definizione di uno standard “esterno” per lo scambio deimessaggi, ma l’implementazione ed il supporto dei meccanismi (protocollo, costruzione, ispezione,

24

encoding dei messaggi) non è necessariamente portabile. In generale il progettista dell’ambientedovrà scegliere uno dei diversi standard per i messaggi e fornirne una implementazione in tutte lepiattaforme che vuole supportare. L’adozione di strumenti di sviluppo avanzati quali beans Java,.NET o GlobusToolkit agevola l’implementazione dei protocolli, perché gli strumenti includonoparte del supporto necessario per costruire i services. È abbastanza chiaro però che ogni strumentoha i sui lati negativi:

a. i beans di Java sono limitati al mondo Java, ne vanno valutati attentamente il grado diinteroperabilità con altri linguaggi di sviluppo e l’efficienza di un supporto in Java. Javapotrebbe essere efficacemente utilizzato insieme ad una delle soluzioni precedenti per costruireadaptor.

b. .NET è principalmente finalizzato alla piattaforma Windows. Esistono implementazioni “open”non Windows (Solo/Rotor per Linux). Non è chiaro però quanto attivamente questeimplementazioni siano supportate.

c. Globus Toolkit fornisce servizi più orientati ai Grid Services che ai Web Services (almeno nellaversione GT3). Non è chiaro per quali piattaforme esista e quale sia il livello di interoperabilitàcon i linguaggi di sviluppo sequenziali standard (Java, C, C++).

Le soluzioni 2 e 3 sono sicuramente più facili da percorrere almeno per la realizzazione di un prototipo,inoltre permettono di mantenere un core di sviluppo stabile non esposto alle variazioni di specificadegli altri standard, e di permettere l’integrazione dell’ambiente a con vari altri ambienti B1, B2 … Nonè chiaro a priori quale sarebbe la differenza di performance fra le varie soluzioni. Le soluzioni 2 e 3vanno molto verso l’approccio gerarchico. Le computazioni critiche per grana o efficienza possonoessere mantenute dentro un ambiente uniforme A.

Figura 9: Integrazione ASSIST con altri ambienti: a) Adaptor b) Web Services

6.3.2 Componenti StorageSi assume che i componenti abbiano uno stato interno. In generale questo stato interno sarà compostoda tutte le classi di memoria necessarie all’algoritmo incluso nel componente (stack, heap, buffers, ecc.).Il layout in memoria dello stato interno è evidentemente dipendente da molti fattori, fra cui l’algoritmo,il linguaggio utilizzato per la programmazione dell’algoritmo e del supporto al componente, il tipo dipiattaforma (hardware e sistema operativo), eccetera. Risulta quindi irrealistico predisporre metodi

25

generali per la serializzazione ed il trasporto attraverso diverse piattaforme dello stato interno di uncomponente (ad esempio nel caso di riconfigurazione o remapping). In questa ottica può essere utiledistinguere un componente specializzato: il componente storage. Il componente storage non implementanessun algoritmo, provvede solo alla memorizzazione di dati. Un componente storage è formalmenteun componente come tutti gli altri e quindi ha tutti i tipi di interfaccia descritti in sezione 6.2, fra le sueinterfacce saranno presenti quelle necessarie per l’accesso ai dati memorizzati. I componenti storagepotranno essere (come gli altri componenti) sequenziali o paralleli con la chiara interpretazione di avereuno storage centralizzato o distribuito. Conseguentemente le interfacce di accesso potranno essereaccedute in modo concorrente con molteplicità eventualmente maggiore di uno. Più componentistorage potranno essere direttamente collegati (a catena, albero, crossbar, ecc.) per realizzare unostorage esplicitamente distribuito, in cui il mapping e la consistenza dei dai dati può essereesplicitamente gestita al livello di Application Manager.

I dati interni ad un componente storage potranno essere memorizzati in un formato indipendente dallapiattaforma e dal linguaggio abilitando la riconfigurazione (spostamento ad esempio) dei componentistorage. I dati contenuti sono indirizzabili mediante chiavi corrispondenti ad oggetti. Il componente èresponsabile dell’allocazione e della gestione delle partizioni o delle copie in accordo a modelli diconsistenza specificabili fra un insieme predefinito.

È importante sottolineare che per come sono definiti i componenti storage sono solo un ulterioreparadigma computazionale (come farm, pipeline, eccetera), infatti essi descrivono una classe dialgoritmi: i gestori di memoria. Questo paradigma insiste sulla separazione della gestione dei dati e delcontrollo come concetti ortogonali [11]. Differenti combinazioni ed implementazioni di componentiparalleli e storage permettono la realizzazione adattiva di soluzioni a dati/controllo mescolati vs separati(processori dedicati vs separati). Questo concetto può essere visto come una particolare istanza delconcetto di “oggetto esterno” ASSIST.

6.3.3 Riconfigurazione di ComponentiUn punto critico riguarda lo stato interno. Si distinguono due categorie di operazioni diriconfigurazione: interne ed esterne.

Le operazioni di riconfigurazione esterne hanno impatto sul ciclo di vita del componente e sonoorchestrate dall’Application Manager. Non si può assumere che questa categoria di operazioni preservilo stato interno del componente.

Le operazioni di riconfigurazione interne non hanno impatto sul ciclo di vita del componente ed hannouna implementazione interna al componente (supporto alle interfacce di configurazione). Si assume chequesta categoria di operazioni preservi lo stato interno del componente.

Come in ASSIST si prevede una distinzione fra componenti sequenziali e paralleli. Sui componentisequenziali sono possibili solo operazioni di configurazione esterna. Nel componente sequenziale lostato interno sarà composto dalle variabili locali dell’implementazione del componente che nonvogliamo né esplicitare nel modello a componenti né rendere portabili, salvabili, eccetera. Icomponenti paralleli ammettono operazioni di riconfigurazione interna e/o esterna.

Supponiamo che i componenti sequenziali e paralleli possano essere connessi a componenti storage e aun Application Manager secondo una delle modalità discusse. Possiamo individuare le operazioni diconfigurazione esterna più elementari, necessarie alla gestione del ciclo di vita del componente:

• Create. Un componente viene creato, il suo stato interno iniziale specificato a tempo dicompilazione. I componenti che possono essere creati dipendono dal sito ove si vuole crearli (icomponenti installati) e sono a conoscenza dell’Application Manager mediante un servizio dimiddleware.

• Destroy. Un componente viene distrutto. Eventuali componenti storage connessi esclusivamente alcomponente distrutto sono sottoposti a garbage collecting.

26

• Move. Un componente viene mosso da una locazione ad un'altra. Lo stato interno viene perduto,mentre eventuali componenti (inclusi gli storage) connessi rimangono connessi. L’operazione èatomica.

• Copy. Un componente viene replicato. Lo stato interno viene perduto. Un eventuale storageesclusivo del componente viene replicato insieme al componente oppure si possono utilizzaremeccanismi di votazione fra copie calde collegate.

• Connect e disconnect. Da utilizzare in conseguenza di azioni di tipo Create e Destroy. Si puòimmaginare due operazioni analoghe che però mantengono lo stato interno.

Le operazioni di riconfigurazione sono ricevute da un componente in modo asincrono ma sonoeffettuate in specifici istanti: il loro trattamento può essere ritardato fino al verificarsi di determinatecondizioni di consistenza. In particolare si devono considerare le conseguenze dovute ad un eventualecheckpointing dello stato esterno in un componente storage. Le azioni di move sono chiaramentefinalizzate ad esigenze di re-mapping dell’applicazione per motivi di performance, di affidabilità, didisponibilità di risorse, eccetera. Le azioni di tipo copy sono finalizzate a creare copie di uncomponente per esigenze di affidabilità. Questa operazione è problematica perché può introdurre inmodo surrettizio parallelismo non voluto e perché rimane da capire cosa fare di eventuali interfaccedata-flow in input e output. La realizzazione di una copia calda (ma anche fredda) comporterebbe lavariazione dei canali di input in broadcast e di output in combing (voting per le copie calde). In ognicaso si ha un impatto non banale sui componenti direttamente connessi e ci sarebbe la necessità diconfinare la riconfigurazione ad una zona limitata del grafo (non è chiaro cosa fare per esempio se ilcomponente ridondante offre un web service). Inoltre il nondeterminismo introduce il problema diconsistenza delle scelte fra copie calde di componenti.

Alcune operazioni di riconfigurazione interna possono essere le seguenti:

• Degree. Si cambia il grado di parallelismo del componente. Tutte le operazioni di cambio diparallelismo in computazioni farm con/senza stato o Data-Parallel si possono effettuare mediantereplicazione di codice parametrico e memoria condivisa (vedi anche Figura 10).

• Algorithm. Si cambia il codice eseguito dal componente.

È possibile immaginare anche operazioni di più alto livello che delegano al componente stesso partedell’intelligenza e che chiedono al componente di rispettare un certo contratto di performance e/o diutilizzo delle risorse. Ad esempio:

• Improve_XXX_by_factor, dove XXX può essere tempo di servizio, latenza, …

• Release_resources_YYY, dove YYY può essere memoria, processori, spazio disco, banda dicomunicazione, …

Le interfacce di configurazione dovrebbero includere un sottoinsieme finalizzato a fornire informazioniall’Application Manager (interfacce di introspezione, vedi sezione 6.2.2). Queste informazioniriguardano lo stato del sistema, il tipo di componente, la performance del componente oppure laperformance dei collegamenti fra componenti.

27

Figura 10: Riconfigurazione di un componente Data-Parallel

6.4 StrategiaLa strategia è la politica implementata dall’Application Manager per ottimizzare le prestazionidell’applicazione rispetto a dei criteri assegnati. La strategia può disporre delle informazioni estraibili daicomponenti mediante le interfacce di introspezione e può operare sulle interfacce attive deicomponenti. Il tipo di strategia utilizzabile è sicuramente legato al tipo di Application Manager che sisceglie di implementare. In particolare un Application Manager distribuito richiede unaimplementazione distribuita della strategia, quindi un modello di performancecomposizionale/componibile. La definizione di una buona strategia per applicazioni su Grid èattualmente un problema di ricerca aperto. Una proposta attualmente allo studio è quella delle reti dicode applicate al grafo di componenti.

6.5 ASSIST come formalismo per specificare le strategie diconfigurazione e riconfigurazione in applicazioni Grid-aware

Utilizzando tutti i concetti e le tecniche finora discusse nella sezione, discutiamo ora come ASSIST [15,16 17, 18] possa essere utilizzato come formalismo per specificare le strategie di configurazione ericonfigurazione di applicazioni Grid ad alte prestazioni, con particolare riguardo agli aspetti delladinamicità, adattività e qualità del servizio.

Tipiche situazioni di interesse possono essere quelle in cui si vuole variare l’allocazione delle risorse peruna applicazione per:

• mantenere un certo livello di performance e affidabilità in seguito a variazioni dinamiche nel caricodi elaborazione di parti dell’applicazione e/o in seguito a ragioni legate alla disponibilità delle risorseattualmente allocate e/o in seguito a variazioni nella composizione dei partecipanti ad unaorganizzazione virtuale;

• far fronte a situazioni che richiedono un incremento della qualità del servizio (performance, bandadi risposta, affidabilità) come in seguito all’insorgere di emergenze.

Supponiamo di avere un modello di programmazione, come delineato nella parte precedente di questasezione, in cui le applicazioni a componenti siano sviluppate mediante Web Services (ma quanto

28

diremo vale per qualunque modello a componenti: CCM, CCA, ecc), e che i componenti incapsulinoprogrammi paralleli espressi in ASSIST: tali programmi potranno essere non solo singoli moduli paralleli osequenziali, ma anche grafi ASSIST di moduli paralleli o sequenziali.

In questo contesto, ASSIST non viene usato semplicemente per esprimere il fatto che una certacomponente è parallela, ma anche e soprattutto per specificare la strategia da seguire per la configurazione (tempodi creazione) e la riconfigurazione a tempo di esecuzione in seguito ad eventi o situazioni come quelli sopraesemplificati.

Esempio. Consideriamo la seguente computazione a componenti:

Figura 11: Visione astratta e concreta di un’applicazione

• La componente C1 è una interfaccia verso una gerarchia di memoria di Grid, che genera duestream di oggetti (dati elementari e strutturati) a partire da data set disponibili su Grid evirtualizzati come presenti sul nodo che esegue C1; uno stream viene inviato alla componente C2(con una certa probabilità p), l’altro alla componente C3 (con probabilità 1-p). C1 può essere unacomponente già esistente, oppure essere espresso da un programma ASSIST con oggetti esterni(ad esempio, usando la facility di ASSIST-CORBA);

• C2 è una componente che incapsula un programma ASSIST. Attraverso un formalismo adatto (dadeterminare nell’arco del primo anno di progetto), viene specificato che C2 by default è un modulosequenziale che esegue una certa funzione F eseguita su un singolo nodo della Grid, mentre inseguito a necessità o opportunità di riconfigurazione (on reconfiguring) viene trasformato in un farm(parmod con topologia none e distribuzione on demand) i cui worker eseguono la stessa F definitanella sezione by default. Il numero effettivo di worker, e la loro allocazione su Grid (su processori di

29

uno stesso cluster o, in generale, su processori di nodi diversi della Grid), sarà determinatodinamicamente a tempo di esecuzione in seguito alle necessità/opportunità di riconfigurazione;

• C3 è una componente che incapsula un programma ASSIST che, secondo l’approccio indicato perC2, by default è un programma data parallel operante su elementi dello stream di tipo array secondouna certa funzione G (parmod con topologia array, distribuzione opportuna, ed eventuale stencilespresso a programma); viene specificato, inoltre, che by default tale programma è eseguito su unsingolo nodo parallelo (cluster) della Grid. On reconfiguring, il programma può aumentare il grado diparallelismo (numero di processori reali su cui allocare i Processori Virtuali VP di ASSIST)utilizzando risorse appartenenti allo stesso nodo o, in generale, a nodi diversi della Grid;

• C4 è una componente che incapsula un programma ASSIST espresso by default da un modulosequenziale, che esegue una funzione H, e on reconfiguring da un parmod capace di operare sui datidi ingresso con modalità data-parallel o con modalità farm o secondo un opportuno mix dei due, aseconda del valore dello stato della computazione e dei dati stessi;

• C5 è una componente che incapsula un programma ASSIST, con determinate caratteristiche (adesempio, un grafo di parmod e moduli sequenziali, con eventuali oggetti esterni) che riceve valori sustream in modo nondeterministico da C2 o da C4. Viene specificato che C5 può essere eseguitosolo su un determinato nodo della Grid, senza riconfigurazione.

In questo esempio, osserviamo che tutta la computazione potrebbe essere espressa come grafoASSIST, mentre l’approccio di incapsulare le componenti come Web Services ha l’obiettivo (almeno nelbreve-medio termine) di garantire maggiore interoperabilità e aderenza agli standard.

Ricordiamo anche che la specifica del “contratto di performance” (espresso informalmente dalle frasi bydefault e on restructuring) deve essere oggetto di un opportuno formalismo.

Disponendo di un supporto dinamico per ASSIST (cosa che non è presente in ASSIST, ma sarà presentenelle successive versioni), la strategia di riconfigurazione, conseguente all’applicazione del contratto diperformance, porterà in generale ad avere Processori Virtuali di uno stesso modulo ASSIST(nell’esempio per le componenti C2, C3, C4) allocati su nodi distinti. Al riguardo, valgono tutte leconsiderazioni fatte nella precedente parte della sezione circa i problemi da affrontare.

La realizzazione della strategia di riconfigurazione necessita di:

• strumenti di monitoring e misura,

• modello di performance utilizzato sia a tempo di creazione che a tempo di esecuzione,

• resource discovery,

• strategie di scheduling locale (ai singoli nodi) e globale (alle risorse di Grid disponibili),

• strumenti di allocazione di dati e di codici (checkpointing, partizionamento, ecc),

oltre che di un nuovo supporto di ASSIST che, basato sull’introduzione di dinamicità nella gestione eallocazione dei Processori Virtuali, permetta una efficiente riallocazione e ridistribuzione del carico.

Nell’esempio, supponiamo che, in seguito a misurazioni effettuate mediante informazioni dimonitoring, il modello di performance determini che la componente C2 è diventata un collo dibottiglia. L’applicazione della strategia di riconfigurazione porterà a trasformare dinamicamente lastruttura di C2, che passerà da una configurazione sequenziale (o farm con un certo numero n1 di nodiworker) ad una configurazione farm (o farm con un numero di nodi worker n2 > n1). I nuovi workersaranno allocati su nodi diversi in base all’applicazione delle strategie di resource discovery, scheduling eallocazione. Cosa analoga vale per C3 e C4, e, in generale, per più di una componente alla volta.

Tutto questo processo è logicamente centralizzato nelle funzionalità dell’Application Manager che,come detto nelle sezioni precedenti, potrà eventualmente essere implementato in modo decentralizzatoattraverso la cooperazione delle Interfacce Attive.

30

Notiamo che il modello di ASSIST possiede caratteristiche interessanti, e sotto certi aspetti uniche, perrealizzare applicazioni adattive ad alte prestazioni; in particolare, per quanto riguarda l’impatto che lemodalità di parallelizzazione hanno sulla definizione adattiva di componenti:

a. una componente puramente funzionale, o con stato read-only, per default è espressa da un farm, oda una combinazione di pipeline e farm: Il farm può avere un singolo worker come caso di default,ma il numero di worker può variare dinamicamente a seconda delle necessità durante la vitadell’applicazione;

b. una componente con stato può essere espressa come una struttura Data-Parallel e/o con oggettiesterni condivisi. Ancora, il caso di default può essere quello della computazione sequenziale,mentre modifiche dinamiche alla struttura della computazione dovrebbero essere possibili a run-time secondo necessità o convenienza;

c. possono essere previste anche situazioni in cui una stessa componente viene dinamicamenteconfigurata talvolta come stream-parallel, talvolta come data-parallel, o come combinazioni dei due;

d. in tutti i casi, è utile avere a disposizione un meccanismo flessibile di distribuzione dei dati e digestione dello stato, incluso il caso degli oggetti esterni, così come la possibilità di gestione delnondeterminismo;

Inoltre, come ricordato all’inizio della sezione, ASSIST

e. è dotato di supporto per sistemi distribuiti eterogenei,

f. è interoperabile con ambienti quali CORBA e, nel prossimo futuro, CCM.

La proposta ora descritta, da sviluppare adeguatamente nel corso del secondo anno di progetto, intenderappresentare il ponte tra Grid computing e programmazione parallela strutturata, affrontando un problema difondo delle applicazioni Grid-aware che, attualmente, in letteratura è affrontato in modo poco chiaro:non è pensabile di parlare di adattività, gestione della dinamicità, modifica a run-time dell’allocazionedelle risorse ad una applicazione, ecc, senza pensare ad un numero limitato di modalità con caratteristiche eproprietà note, cioè a forme computazionali che siano parametrizzabili sia come implementazione che comevalutazione. Se, in seguito al manifestarsi di certi eventi a tempo di esecuzione, viene riscontrata lanecessità o la convenienza di modificare la qualità del servizio, deve essere noto come ristrutturarel’applicazione secondo soluzioni per le quali sia noto un modello dei costi. Questo non può chesignificare variare il grado di parallelismo (situazione prevista in letteratura in casi molto limitati), o leforme di parallelismo, o le politiche di scelta nondeterministica, o la politica di tolleranza ai guasti, ecc,in accordo a paradigmi computazionali che, ad un certo livello, possano essere espressi dal progettistadell’applicazione. Si ritiene che, in questa ottica, ASSIST possa svolgere un ruolo molto importante:non solo per la parallelizzazione di parti di applicazioni, ma soprattutto per la caratterizzazione Grid-aware delle applicazioni stesse.

6.6 Fault-toleranceIl modello a componenti deve utilizzare tecniche di fault-tolerance in modo da essere in grado dirispondere ad eventi che possono considerarsi normali se non tipici per un ambiente di griglia, quali adesempio la scomparsa di un nodo di elaborazione dall’insieme dei nodi raggiungibili dall’applicationmanager. Le tecniche da utilizzare sono per lo più tecniche note (monitoring, checkpointing, ecc.) evanno semplicemente contestualizzate sulle necessità dell’ambiente di programmazione a componentiad alte prestazioni. In altre parole, non si ritiene necessario, al momento, prevedere attività specificheper lo sviluppo di tecniche di fault-tolerance ad-hoc per i componenti.

31

6.7 SicurezzaDal punto di vista della sicurezza la soluzione ideale sarebbe quella di appoggiarsi completamente allefunzionalità del middleware sottostante, anche se alcune caratteristiche che riteniamo interessanti nonsono al momento supportate da Globus. In particolare appare importante:

• considerare strategie di sicurezza dinamiche. Un codice non deve necessariamente avere gli stessipermessi per tutta la vita. Nel caso un codice sia spostato da una macchina ad un’altra puòdinamicamente acquisire o perdere alcuni permessi (es. scrivere su un disco). Potremmo studiaremeglio il problema a partire dal supporto HotSpot per Java, in cui la politica di sicurezza vienevalutata al livello delle classi al momento del binding, cioè al momento della chiamata e non delcaricamento;

• il raffinamento delle politiche di autenticazione e autorizzazione dei componenti rispetto alleorganizzazioni virtuali, in modo da superare il concetto di autorità centrale di certificazione epermettere alle singole organizzazioni virtuali di mantenere il controllo sulle proprie risorse.

7 Bibliografia

[1] Gerd Beneken, Ulrike Hammerschall, Manfred Broy, Marìa Victoria Cengarle, Jan Jürjens, BernhardRumpe, and Maurce Schoenmakers. Componentware - State of the Art 2003. Background paper forthe Understanding Components Workshop, Venice, 7-9 October 2003.

[2] C. Szyperski and C. Pfister. WCOP'96 Workshop Report, ECOOP 96 Workshop Reader, 1996.

[3] S. MacDonald, J. Anvik, S. Bromling, J. Schaeffer, D. Szafron and K. Tan. From patterns toframeworks to parallel programs. Parallel Computing, 2002.

[4] I. Foster and C. Kesselman and S. Tuecke. The Anatomy of the Grid: Enabling Scalable VirtualOrganization. The International Journal of High Performance Computing Applications, 2001.

[5] Foster and C. Kesselman and J. Nick and S. Tuecke. The Physiology of the Grid: An Open GridServices Architecture for Distributed Systems Integration, 2002.

http://www.globus.org/research/papers/ogsa.pdf

[6] K. Kennedy, M. Mazina, J. Mellor-Crummey, K. Cooper, L. Torczon, F. Barman, A. Chien, H. Dail,O. Sievert, D. Angulo, I. Foster, D. Gannon, L. Johnsson, C. Kesselman, R. Aydt, D. Reed, J.Dongarra, S. Vadhiyar and R. Wolski. Toward a Framework for Preparing and Executing AdaptiveGrid Programs. Proc. of NSF Next Generation Systems Program Workshop (IPDPS 2002), 2002.

[7] Indiana University, Extreme Lab. XCAT home page. http://www.extreme.indiana.edu/xcat/

[8] D. Thain, T. Tannenbaum and M. Livny. Condor and the Grid. Fran Berman and Geoffrey Fox andTony Hey editors, Grid Computing: Making the Global Infrastructure a Reality, 2002.

32

[9] Apple Advanced Computation Group. The Xgrid home page. http://www.apple.com/acg/xgrid/

[10] H E. Bal. Ibis: A Java-based grid programming environment. In Proc. of Euro-Par2003 (invitedtalk), LNCS n. 2790, 2003.

[11] M. Aldinucci. Dynamic shared data in structured parallel programming frameworks. PhD. thesis,Università degli studi di Pisa, 2003

[12] M. Aldinucci and M. Danelutto and P. Teti. An advanced environment supporting structuredparallel programming in Java. Future Generation Computer Systems 19(5), 2003.

[13] A. Denis, C. Pérez, T. Priol, and A. Ribes. Padico: A component-based software infrastructure forgrid computing. Technical Report RR-4974, INRIA - Rennes, 2003.

[14] T. Priol. Programming the Grid with Distributed Objects. Proc. of Workshop on PerformanceAnalysis and Distributed Computing (PACD 2002), 2002

[15] M. Vanneschi. he programming model of ASSIST, an environment for parallel and distributedportable applications. Parallel Computing 28(12), 2002.

[16] M. Aldinucci, S. Campa, P. Ciullo, M. Coppola, S. Magini, P. Pesciullesi, L. Potiti, R. Ravazzolo, M.Torquati, M. Vanneschi and C. Zoccolo. The Implementation of ASSIST, an Environment for Paralleland Distributed Programming. In Proc. of Euro-Par2003, LNCS n. 2790, 2003.

[17] M. Aldinucci, S. Campa and P. Ciullo, M. Coppola, M. Danelutto, P. Pesciullesi, R. Ravazzolo, M.Torquati, M. Vanneschi and C. Zoccolo. ASSIST demo: a high level, high performance, portable,structured parallel programming environment at work. . In Proc. of Euro-Par2003, LNCS n. 2790,2003.

[18] M. Aldinucci, S. Campa, P. Ciullo, M. Coppola, M. Danelutto, P. Pesciullesi, R. Ravazzolo, M.Torquati, M. Vanneschi and C. Zoccolo. A framework for experimenting with structured parallelprogramming environment design. In Proc. of Intl. Conference ParCo2003: Parallel Computing, 2003