Sistemi Distribuiti RPC E CORBA

Massimo AnconaMassimo Ancona

Sistemi Distribuiti RPC E CORBA

Sistemi Distribuiti RPC E CORBA

SD 1:SD 1:

April 25, 2004

2

SD

COMUNICAZIONI CLIENT-SERVER COMUNICAZIONI CLIENT-SERVER

Il protocollo RPC. Si presenta in tre forme:

• request protocol (R) - isi usa quando non e’ richiesto un valore di ritorno (tipo void).

• Request-reply protocol (RR) - si richiede un risultato di ritorno, la risposta del server funge anche da ack.

• request-reply-acknowledge reply (RRA) protocol - basato su tre messaggi: request reply ack. Quest’ultimo contiene il reqestId del reply message da validare

SD 2:SD 2:

April 25, 2004

3

SD

MECCANISMO RPC MECCANISMO RPC

SD 3:SD 3:

Remote Procedure Call (RPC)

e' un meccanismo (protocollo) che permette ad un programma in esecuzione su un host di eseguire codice (una procedura) su un altro host. Se il codice e' sviluppato con metodologia object-oriented, allora una RPC viene anche detta RMI (remote method invocation).

RPC e' un ottimo metodo per implementare il modello client-server. Una chiamata RPC viene iniziata dal chiamante (il client) che invia un messaggio ad un sistema remoto (il server) che esegue una determinata procedura con gli argomenti forniti nel messaggio. Al termine dell'esecuzione, viene inviato un messaggio "risultato" al chiamante.

April 25, 2004

4

SD


SD 4:SD 4:

Allo scopo di permettere a un’ampia gamma di client di accedere ai server si sono proposti sistemi e meccanismi RPC standard, basati su un Interface Description Language (IDL) che supporta diverse piattaforme quali: DCOM (e ActiveX) di Microsoft e gli standard OSF DCE e CORBA.

Recentemente e' stato usato anche XML come linguaggio IDL e HTTP come protocollo di trasporto. I vantaggi di questo metodo, noto come "web services" sono: semplicita' e standardizzazione. XML e' un file di testo universalmente noto mentre HTTP e' disponibile in tutti gli OS. Esempi di questo standard RPC sono XML-RPC e SOAP da esso derivato.

April 25, 2004

5

SD

OSF/DCE Distributed Computing Environment

OSF/DCE Distributed Computing Environment

Un insieme di tool software e servizi che semplificano la programmazione distribuita• DCE RPC: cuore del sistema facilita lo sviluppo

delle applicazioni per l’alto livello di astrazione. • DCE Directory Service nmeccanismo reliable

per associare nomi alle applicazioni.• DCE Security Service• DCE Distributed time service• DCE Threads• DCE Distributed File Service

SD 5:SD 5:

April 25, 2004

6

SD


SD 6:SD 6:

April 25, 2004

7

SD

GROUP COMMUNICATION GROUP COMMUNICATION

Si basa sul concetto di Multicast - un messaggio inviato da un processo ai processi membri di un gruppo. Utile per:• Fault tolerance basata su servizi replicati:

un gruppo di server che eseguono lo stesso servizio.

• Localizzazione di oggetti in servizi distribuiti

• Servizi piu’ efficienti

• Aggiornamenti multipli

• Importante nei sistemi wirelessSD 7:SD 7:

April 25, 2004

8

SD


Atomicità

Tutti i membri di un gruppo devono ricevere tutti i request message a loro inviati.• Atomic Multicast: invio di un messaggio che è

ricevuto da tutti i membri del gruppo o da nessuno.

Reliability• Reliable Multicast: metodo di trasmissione che

cerca di raggiungere tutti i membri del gruppo senza garanzia di successo.

SD 8:SD 8:

April 25, 2004

9

SD


Ordering

Riguarda l’ordine di ricevimento dei messaggi da parte dei membri di un gruppo. Nei multicast atomico e reliable si usano code FIFO di ordinamento dei messaggi.

• Multicast totalmente ordinato: una serie di messaggi inviati a un gruppo e che devono raggiungere i membri del gruppo tutti nello stesso ordine. SD 9:SD 9:

CORBACORBACCommon ommon OObject bject BBroker roker

AArchitecturerchitecture

CORBACORBACCommon ommon OObject bject BBroker roker


SD 10:SD 10:

CCommon OObject RRequest BBroker AArchitecture (CORBA)


Cos’è CORBA• La specifica di un’architettura Object-

Oriented per applicazioni distribuite

A cosa serve• ad accedere a informazioni distribuite in

ambito di applicazioni desktop

• a trasformare programmi e sistemi esistenti in risorse di rete

SD 11:SD 11:



CORBA si basa su distributed object computing.

CORBA rende possibile il riuso di software tramite elaborazioni ad oggetti distribuite

I due ingredienti essenziali di CORBA sono quindi• integrazione di un objct-model con

distributed computing• l’uso di un broker - intermediario che smista

messaggi tra client e serverSD 12:SD 12:



Il broker ha la capacità di • scegliere i server più adatti a soddisfare una

richiesta• separare l’interfaccia (vista dal cliente)

dall’implementazione del server

I principali meccanismi per elaborazioni distribuite in uso sono• Remote Procedure Call (RPC)• API specifiche di comunicazione per

applicazioni in reteSD 13:SD 13:

CORBA (struttura di un’applic.)CORBA (struttura di un’applic.) CORBA (struttura di un’applic.)CORBA (struttura di un’applic.)

SD 14:SD 14:

CORBA: tipi di invokation (call) CORBA: tipi di invokation (call) CORBA: tipi di invokation (call) CORBA: tipi di invokation (call)

SD 14:SD 14:

Synchronous communication•L’applicazione trasferisce il controllo all’ ORB e si pone in attesa fino alla terminazione della stessa

Deferred Synchronous Communication•L’applicazione non aspetta un risultato ma deve controllare che si sia completata prima di emettere una nuova richiesta

One-way communication•L’applicazione invia la richiesta e continua il proprio lavoro senza controllarne il completamento

CORBA: stili di invokation (call) CORBA: stili di invokation (call) CORBA: stili di invokation (call) CORBA: stili di invokation (call)

SD 14:SD 14:

Stub-stile invokation•La call viene costruita al momento della compilazione. Essa e’ ottenuta tramite linking dei client stubs nell’applicazione client.•Il codice del client chiama una procedura stub generata dalla definizione dell’interfaccia in IDL. Questo metodo supporta le chiamate sincrone e one-way ma non le deferred asincrone

Dynamic invokation•L’applicazione deve costruire dinamicamente la call. Ha enorme liberta’ e puo’ usare ogni tipo di invokation.

CORBA (architettura) CORBA (architettura) CORBA (architettura) CORBA (architettura)

SD 15:SD 15:

CORBA (architettura) CORBA (architettura) CORBA (architettura) CORBA (architettura)

SD 15:SD 15:

OGGETTI CORBAOGGETTI CORBA OGGETTI CORBAOGGETTI CORBA

Un oggetto Corba ha un’interfaccia scritta in IDL e ha differenti rappresentazioni sul client e sul server. Un server implementa un oggetto in un

linguaggio di programmazione concreto, es. C++ o Java, come istanza di un’ implementation class: l’implementazione e’ detta un servant.

Un client intenzionato ad usare un oggetto implementato da un server crea un oggetto che delega tutte le operation call al servant tramite l’ ORB. Questo oggetto e’ detto proxy.

SD 16:SD 16:


• Quando un client chiama un metodo sul local proxy object, l’ORB impacchetta i parametri e li invia al server che spacchetta i parametri e invoca il metodo sul servant. I parametri di ritorno e il risultato seguono il cammino a ritroso.

• Un servant e’ connesso all’ORB in modo da permettergli di invocare il metodo del servant. La connessione e’ gestita dal POA (Portable Object Adapter).

SD 17:SD 17:


SD 18:SD 18:

CORBA: Linguaggio IDL - EsempioCORBA: Linguaggio IDL - Esempio CORBA: Linguaggio IDL - EsempioCORBA: Linguaggio IDL - Esempio

// Personnel application: IDL source

module CORP{

typedef long BadgNum;

typedef long DeptNum;

enum DismissalCode {DISMISS_FIRED, DISMISS_QUIT};

…

interface Employee{

void promote(in char new_job_class);

void dismiss(in DismissalCode reason,in string description);

}; // end of interface Employee

…

}; /* end module CORP */SD 19:SD 19:

IDL: ereditarietà singolaIDL: ereditarietà singola IDL: ereditarietà singolaIDL: ereditarietà singola

module CORP{

struct Personal Data{

…

struct EmpData{

...

interface Employee{

attribute EmpData personal_data;

readonly attribute Department department_job;

void promote(in char new_job_class);

void dismiss(in DismissalCode reason,in string description);

void transfer(in Department new_dept_obj);

}; // end of interface Employee

SD 19:SD 19:

IDL: ereditarietà singola cont.IDL: ereditarietà singola cont. IDL: ereditarietà singola cont.IDL: ereditarietà singola cont.

interface Manager: Employee{

void approve_transfer(in Employee employee_obj,

in Department current_department,

in Department new_department);

}; // end of interface Manager

…

}; // end module CORP

SD 19:SD 19:

IDL: Ereditarieta’ MultiplaIDL: Ereditarieta’ Multipla IDL: Ereditarieta’ MultiplaIDL: Ereditarieta’ Multipla

Ci riferiamo all’esempio precedente

module CORP{

…

interface Employee

{

attribute EmpData personal_data;

readonly attribute Department department_obj;

…

void promote (…);

void dismiss(…);

void transfer(…);

};//End interf. Employee

SD 19:SD 19:

IDL: Ereditarieta’ MultiplaIDL: Ereditarieta’ Multipla cont. cont.IDL: Ereditarieta’ MultiplaIDL: Ereditarieta’ Multipla cont. cont.

interface Manager: Employee{

void approve_transfer (in Employee employee_obj,

in Department current_department,

in Department newdepartment);

}; // end interf. Manager

interface Personnel: Employee{

Employee hire(in Employee _data, in Department department_obj,

in Department new_department);

};//end interf. Personel

interface PersonelManager: Personnel, Manager{

void arbitrate(); …

};// end interf. PersonalManager

SD 19:SD 19:

CORBA (2)CORBA (2)CCommon ommon OObject bject BBroker roker


CORBA (2)CORBA (2)CCommon ommon OObject bject BBroker roker


SD 10:SD 10:

CORBA: Communication(Invocation) CORBA: Communication(Invocation) StilesStiles

CORBA: Communication(Invocation) CORBA: Communication(Invocation) StilesStiles

Sono di tre tipi:

Syncronous communication L’applicazione trasferisce il controllo all’ORB e si blocca.

Conveniente quando le richieste sono eseguite in un ordine predefinito e sono di breve durata. E’ l’unico modo ammesso con il meccanismo stub style

Deferred synchronous communicationL’applicazione non si blocca in attesa di risposta, tuttavia deve attendere il completamento della richiesta in corso con tecniche di polling prima di emetterne una nuova.

One-way communication L’applicazione non si blocca e non deve controllare l’esito della

richiesta che non restituisce risultato. E’ possibile comunque ottenere eccezioni nel caso di fallimento in esecuzione.

SD 19:SD 19:

CORBA CORBA Invocation TypesInvocation Types CORBA CORBA Invocation TypesInvocation Types

Sono di due tipi:

Stub Style Invocation (SSI) Piu’ facile da usare e piu’ efficiente, ma

suporta solo le comunicazioni sincrona e one way.

Dynamic Invocation (DI)

Si costruisce la call completamente a run time e suporta tutti i meccanismi di comunicazione.

SD 19:SD 19:

CORBA Stub Stile InvokationCORBA Stub Stile Invokation CORBA Stub Stile InvokationCORBA Stub Stile Invokation

La Stub Style Invokation (SSI)

I client stub forniscono informazioni implementation-specific che facilitano lo sviluppo di un’applicazione client. Lo stub mappa operazioni definite in IDL su un insieme di definizioni di dati e prototipi di routine in un linguaggio di programmazione specifico (esempio C++) invocate dall’applicazione client.

Si esegue una SSI tramite dei client stub creati a partire dal codice IDL: le call agli stub sono molto simili a call di routine.

I file header e le definizioni prodotte compilando IDL vengono a loro volta compilati (dal compiler C++) all’interno della applicazione e inseriti nello stub (una parte nascosta del codice cliente).

SD 19:SD 19:

CORBA Stub Stile InvocationCORBA Stub Stile Invocation CORBA Stub Stile InvocationCORBA Stub Stile Invocation

Caratteristiche della Stub Style Invocation (SSI) Supporta invocazione sincrona e a una via, non la

sincrona differita (deferred synchronous)

si basa su meccanismi di call simili a chiamata di procedura

Si esegue una SSI tramite dei client stub creati a partire dal codice IDL: le call agli stub sono molto simili a call di routine.

I file header e le definizioni prodotte compilando IDL vengono a loro volta compilati dal comilatore specifico (es. C, C++, Java..)

SD 19:SD 19:

Uso di Stub Style InvocationUso di Stub Style Invocation Uso di Stub Style InvocationUso di Stub Style Invocation

Presentata per passi successivi

1) Si generano uno o piu’ client stub dalla definizione dell’interfaccia usata dalla applicazione client

Generalmente lo stub e’ un file sorgente (o oggetto) che viene integrato nel codice cliente tramite compilazione e linking (o solo linking)

Ci si connette allo stub a scatola chiusa astraendo dalle sue funzionalita’ e lasciando che svolga la sua funzione.

SD 22:SD 22:

Stub Style InvocationStub Style Invocation 1 1Stub Style InvocationStub Style Invocation 1 1

Una porzione di codice IDL viene usato per esemplificare:

/* codice IDL */

module CORP

{….

Interface Personnel

{ Employee hire

(in EmpData employee_data, in Department department_obj,

out BadgeNum new_employee_id)

context(sec_level):

};

SD 22:SD 22:

Stub Style Invocation 2Stub Style Invocation 2Stub Style Invocation 2Stub Style Invocation 2

Il codice IDL viene compilato da un comando del tipo:

> idl_compile CORP.idl -c Personnel_client

2) Si connette il client stub all’applicazione. I files generati al passo 1) vengono compilati e linked alla applicazione. In questo esempio viene generato sorgente C. Il prototipo dello stub e’ inserito nel file:

Personnel_client.h.

SD 26:SD 26:

Stub Style Invocation 3Stub Style Invocation 3 Stub Style Invocation 3Stub Style Invocation 3

/* codice C Personnel_client.h */

CORBA_Object CORP_Personnel_hire

{

CORP_Personnel Object,

CORBA_Environment * ev,

CORBA_Context * ctx_obj,

CORP_EmpData * employee_data,

CORBA_Object department_obj,

CORP_BadgeNum * new_employee_id

};

SD 22:SD 22:


3) Si ottengono i riferimenti agli oggetti coinvolti nella richiesta. Qui si devono ottenere riferimenti a istanze specifiche degli oggetti Personnel, Context, Departement

4) Si emettono call al client stub dall’ interno del codice applicativo usando gli argomenti appropriati come specificato nel codice IDL.

L’esempio seguente mostra la call in linguaggio C al client stub dal programma client prodotto dal codice IDL al punto 2).

SD 22:SD 22:


/* C */

new_emp_obj = CORP_Personnel_hire

(

personnel_obj

&Ev,

ctx_obj,

new_emp_data,

dept_obj,

new_emp_badge

);

SD 22:SD 22:


Alla variabile new_emp_obj viene assegnata una object reference alla nuova istanza dell’oggetto employee creato tramite l’operazione CORP_Personnel_hire.

Il generatore di stub crea nomi univoci nel client stub in base alle specifiche CORBA:

modulename_interfacename_operationname

Nel nostro caso lo stub CORP_Personnel_hire denomina l’ operazione hire dell’ oggetto Personel definito nel modulo CORP.

SD 22:SD 22:


personnel_obj: riferimento all’oggetto istanza di Personnel su cui e’ definita l’operazione hire.

indirizzo dell’ argomento environment usato per memorizzare eccezioni.

reference al context object associato alla richiesta, tramite la variabile cxt_obj che corrisponde alla variabile context(sec_level) nel nostro codice IDL

new_emp_data contiene i dati dell’oggetto corrente di tipo employee

SD 22:SD 22:


new_emp_data contiene i dati dell’oggetto corrente di tipo Employee

dept_obj: riferimento all’istanza di Department in cui l’impiegato e’ “hired”. Corrisponde alla variabile new_employee_id di IDL.

indirizzo cui inviare il nuovo badge number dell’impigato che e’ “hired”.

5) Si leggono i risultati dalla call allo stub e si usano.

6) Si rilascia la memoria occupata da ogni oggetti gestito

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 9 9 Dynamic InvocationDynamic Invocation 9 9

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 1 1 Dynamic InvocationDynamic Invocation 1 1 Una call e’ costruita completamente a run-time.

Equivale ad una costruzione dinamica della parte “parametri” del record di attivazione seguita dall’attivazione della call vera e propria

Di uso vantaggioso quando l’applicazione deve scoprire oggetti di nuovo tipo senza modifica e ricompilazione. Usa il repository delle interfacce per accedere alle segnature della operazione cui smistare la richiesta.

Vediamo in dettaglio come usare un’invocazione dinamica. Ci si basa sull’esempio gia’ visto relativo al framework del personale.

SD 22:SD 22:


Supporta tutti i tipi di invocation:

1. Synchronous

2. Deferred Synchronous

3. One way

Si basa su un modello consistente e generalizzato di attivazione object-oriented. Ha una struttura generale usata per ogni richiesta basata sui passi seguenti:

SD 22:SD 22:


1. Caricamento dell’interfaccia in un repository

2. Acquisizione del rifeimento all’oggetto necessario alla richiesta

3. Creazione di un request object e degli argomenti er la call.

4. Emissione della call (synchronous, deferred synchronous o one-way).

5. Acquisizione del risultato (se presente)

6. Eliminazione della richiesta per risparmio di memoria o (si mantiene solo se si prevede un suo riuso).

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 4 4 Dynamic InvocationDynamic Invocation 4 4 Una richiesta e’ formata da tre parti:

□ Object reference

□ Operations

□ Arguments

Vi sono tre modi per costruire le tre parti:

1. Automaticamente tramite CORBA_ORB_create_operation_list E’ il modo piu’ semplice

2. Aggiungendo argomenti alla richiesta tramite CORBA_Request_add_arg

3. Manualmente tramiteCORBA_ORB_create_list

SD 22:SD 22:


Costruzione automatica si eseguono i passi seguenti:

1. Tramite CORBA_ORB_create_operation_list si costruisce la argument list. Esempio/* C */status=CORBA_ORB_create_operation_list( ORB_obj, &Ev, hire_opdef_obj, &hire_op_NVList )

SD 22:SD 22:


Dove:

E’ l’object reference a un oggetto ORB (questa operazione e’ definita nell’ ORB). Qui va in ORB_obj.

Indirizzo dell’argomento environment

Riferimento a un oggetto OperationDef per un’operazione specifica su un’interfaccia specifica. L’oggetto OperationDef e’ usato nel repository per rapresentare l’operazione. Nell’esempio esso rappresenta l’operazione CORP_Personnel_hire memorizzata nel repository.

Indirizzo della named value list (NVL). L’argomento riceve la NVL che contiene gli argomenti dell’operazione da attivare.

SD 22:SD 22:


2. Si assegnano valori opportuni agli argomenti, buffers per i parametri OUT, e valori iniziali per i buffer INOUT.

3. Si crea un request object tramite

CORBA_Object_create_request

Il seguente codice C illustra come usare l’operazione su CORP_Personnel_hire.

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 8 8 Dynamic InvocationDynamic Invocation 8 8 /*C*/

Status=CORBA_Object_create_request

(

personnel_obj,

&Ev,

“hire”,

hire_op_NVList,

Emp_obj,

&req_obj,

0

)

SD 22:SD 22:


Object reference (ref. a oggetto ORB su cui l’op. e’ definita) per noi un oggetto Personnel.

Indirizzo dell’argomento environment

Stringa con il nome dell’operazione da attivare. Non occorre specificare lo scope intero “CORP_Personnel_hire” perche’ lo scope e’ gia’ aperto

La NVL per gli argomenti dell’operazione.

per risultati se ci sono, (NULL se non ci sono)

indirizzo dell’oggetto request da creare

argomento per passare flag a CORBA.

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 10 10 Dynamic InvocationDynamic Invocation 10 10 Si possono aggiungere gli argomenti uno

per volta. Questo avviene quando non si conoscono i valori di tutti gli argomenti di una call tramite chiamate a

CORBA_RequestAdd_arg

per aggiungere un singolo argomento. Ad esempio si usa questo metodo quando si costruisce una richiesta tramite i dati forniti da un utente che sta riempiendo i campi di una dialog box interattivamente.

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 11 11 Dynamic InvocationDynamic Invocation 11 11 Come implementare una dynamic invocation1. Si carica l’interfaccia in un interface repository, ad esempio

tramite un comando del tipo >idl_load CORP.idl

2. Si recupera l’ object reference dell’oggetto coinvolto nella riciesta

3. Si costruisce la richiesta mediante uno di tre possibili metodi (dettaglio non visto)

4. Si invoca la richiesta. A questo punto la call e’ attivabile in molti modi: Tramite call sincrona tramite CORBA_Request_invoke Tramite una call deferred syinchronous usandoCORBA_Request_send Tramite una multiple deferred syinchronous invocation tper mezzo

di CORBA_Send_multiple_request

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 12 12Dynamic InvocationDynamic Invocation 12 12

L’esempio seguente si basa su una synchronous invocation.

/* C */

status= CORBA_Request_invoke

(

Req_obj,

&Ev,

0

);

object-reference

environment argument addr.

Suporta il metodo di invocation richiesto fornendo l’interfaccia necessaria

SD 22:SD 22:

Dynamic InvocationDynamic Invocation 13 13Dynamic InvocationDynamic Invocation 13 13Come il client supporta il tipo di invocation

dipende da: il codice del client supporta solo una stub-stile invocation. Lo

stub viene generato dal codice IDL il codice del client supporta solo una dynamic invocation. Si

carica il codice dell’interfaccia nel repository. il codice del client supporta entrambi gli stili precedenti, ci si

comporta in modo misto.

4. Si scrive il codice client che esegue la invokation

5. Si scrive il codice client che riceve e usa i risultati di una richiesta che ha avuto successo

6. Si scrive il codice che tratta eccezioni ed errori

7. Se l’applicazione puo’ fungere anche da server bisogna dargli la struttura adeguata.

SD 22:SD 22:

CORBA 3.0CORBA 3.0CORBA 3.0CORBA 3.0

SD 35:SD 35:

Evoluzione di CORBAEvoluzione di CORBA

Introdotto nel 1991 come astrazione per la programmazione di oggetti distribuiti permette di integrare applicazioni distinte in un sistema distribuito ed omogeneo

il cuore di ogni sistema basato su CORBA è l’ORB (Object Request Broker).

SD 36:SD 36:

Da CORBA 1 a CORBA 3 Da CORBA 1 a CORBA 3

EVOLUZIONE di CORBA

CORBA 2 aggiunge (1995) • lo Standard General Inter-ORB Protocol

(GIOP) e relativa specifica di implementazione sul TCP/IP

• L’ Internet Inter-ORB Protocol (IIOP)

CORBA 3 aggiunge (1998)• Il Portable Object Adapter (POA)

• CORBA Messaging

• Objects By ValueSD 37:SD 37:

Portable Object Adapter POA Portable Object Adapter POA

RUOLO di POA

Mediare tra gli Oggetti CORBA (CO) e il mondo delle implementazioni, nei vari linguaggi di progr. dette Servants. In particolare

Creare Oggetti CORBA (CO)

Smistare le richieste fatte ai singoli CO

Dispatching delle richieste ai servant che incarnano o implementano CO target

Attivare disattivare CO

SD 38:SD 38:

POA - MotivazioniPOA - Motivazioni

Fino a CORBA 2.1 il solo standard Object Adapter definito dall’OMG è stato BOA

BOA fornisce solo servizi di base che permettono la creazione e l’implementazione di CO

Molte feature mancavano o erano definite in modo ambiguo con conseguente proliferazione di versioni proprietarie tra loro incompatibili

SD 39:SD 39:

POA - BasicsPOA - Basics

POA media tra l’ORB e e le applicazioni server

SD 40:SD 40:

POA - Basics 1POA - Basics 1

Il cliente invia la richiesta (invokes the request) mediante una Object Reference (OR) che specifica l’oggetto target

La richiesta è ricevuta dall’ORB del server• parte di essa contiene un ID detto Object Key

(OK) che identifica univocamente il CO nell’ambito dell’applicazione server

• Essendovi più POA la OK aiuta ORB nel dispatching verso il POA opportuno.

SD 41:SD 41:

POA - Basics 2POA - Basics 2POA - Basics 2POA - Basics 2

Il POA usa una parte della OK detta Object ID (OID) per associare il Target Object e il servant (livello di linguaggio programmativo)• le associazioni possono essere memorizzate in

una map oppure:

• POA può chiamare l’applicazione per provvedere ad un servant relativo al target object ID, o usarne uno di default stabilito dall’applicazione stessa

in ogni caso POA smista la richiesta all’appl.

SD 42:SD 42:


Il POA interagisce principalmente con tre entità:• Due l’ Object Reference - e l’ Object ID usate per

identificare

• La terza il Servant che implementa i CO

Una server Application prima chiede a POA di creare un nuovo CO - il POA restitusce una Object Reference che identifica univoc. Il CO nell’ambito di tutte le applicazioni server.

SD 43:SD 43:


All’ atto della creazione di un CO l’ OID viene fornito dal’applicazione stessa o dal POA che identifica in modo unico il CO nel proprio scope

Un Servant è detto Incarnare (o to provide a body) di un CO. In definitiva la richiesta per un CO viene eseguita dal suo Servant . Nel caso di uso di C++ e Java i Servant sono istanze di classi del linguaggio.

SD 44:SD 44:

Oggetti Persistenti e TransientiOggetti Persistenti e Transienti

Una delle caratteristiche migliori di CORBA è il meccanismo di attivazione automatica e trasparente di oggetti. Se un’ applicazione Client emette una richiesta ad un Target Object non in esecuzione o non attivato, CORBA chiede alle implementazioni di ORB di attivare un processo server per tale oggetto (se necessario) e quindi di attivare l’oggetto stesso.

SD 45:SD 45:

Oggetti Persistenti e Transienti 2Oggetti Persistenti e Transienti 2

Ogni attivazione di processo server e di target object è trasparente ai rispettivi clienti

Gli Oggetti CORBA che hanno un ciclo di vita che trascende quello del processo specifico che li crea o attiva sono detti persistenti.

E’ anche utile avere oggetti il cui ciclo di vita è limitato da quello del processo o dell’ Object Adapter che li crea. SD 46:SD 46:

Oggetti Persistenti e Transienti 3Oggetti Persistenti e Transienti 3

POA supporta due tipi di CO• Persistent objects (nella versione originale)

• Transient objects (TCO) il cui ciclo di vita è limitato da quello del POA in cui viene creato

Gli Oggetti transient richiedono meno bookkeeoing da parte dell’ORB. Una volta distrutto il POA che ha creato un TCO non può più essere riattivato sempificando le operazioni dell’ORB.

SD 47:SD 47:

POA aspetti ulterioriPOA aspetti ulteriori

POA supporta anche i seguenti meccanismi• Explicit and on-demand activation

• Separation of servant and CORBA object life cycles

• Different policies of multithreading

CORBA multithreading• permette ad un’applicazione server di usare più

thread per servire più richieste concorrentemente

SD 48:SD 48:

CORBA & OMA in ETERPRISE COMPUTINGCORBA & OMA in ETERPRISE COMPUTINGCORBA & OMA in ETERPRISE COMPUTINGCORBA & OMA in ETERPRISE COMPUTING

Dopo Corba 2.0 l’OMG si è mosso in diverse direzioni:

Multiple interfaces per object,

Object passed by value,

Beans-like component model,

Real-time support

Fault-tolerance

Embedded CORBASD 49:SD 49:

USO di IDLUSO di IDLUSO di IDLUSO di IDL

Le imprese operanti nel mercati verticali hanno iniziato ad usare IDL per descrivere le specifiche di oggetti standard da usare in modo pubblico e condiviso. OMG ha ampliato il proprio scopo con un allargamento di orizzonti a:

Finanza /Asicurazioni

Commercio Elettronico,

Healthcare,

Manufactoring, Telecomunicazioni

Trasporti

Life Science & Research Business Objects

SD 50:SD 50:

OMG Specification SuiteOMG Specification Suite

Come risultato si è avuta un’ampia gamma di specifiche OMGCome risultato si è avuta un’ampia gamma di specifiche OMG

SD 51:SD 51:

ARCHITECTURAL OVERVIEWARCHITECTURAL OVERVIEW ARCHITECTURAL OVERVIEWARCHITECTURAL OVERVIEW

L’ architettura OMG offre: Supporto per analisi e design: UML e MOF

Basic o-o computing model: ORB; OMG/ISO IDL e suo mapping verso C,C++,Java,Smalltalk,Cobol e Ada

Distribuzione: il protocollo GIOP e il suo mapping verso TCP/IP e varie forme alternative di messaging e asynchronous invocation

Component Model: CORBA Components and Scripting; multiple interfaces; oggetti passati per valore

Modi specializzati: real-time, fault-tolerance, embedded CORBA

SD 52:SD 52:

ARCHITECTURAL OVERVIEW (cont)ARCHITECTURAL OVERVIEW (cont)ARCHITECTURAL OVERVIEW (cont)ARCHITECTURAL OVERVIEW (cont)

CORBAservices. Basic services for distributed object applications: naming and trader services, event & notification, Object Transaction Serv. (OTS), Security serv.

Horizontal CORBAfacilities: System Management, print spooling, etc..

Vertical Market (Domain) CORBAfacilities: Supporto per l’impresa, oggetti standard per funzioni standard, condivisibilità ecc.

SD 53:SD 53:

UML e MOF: Supporting Analysis and UML e MOF: Supporting Analysis and DesignDesign

UML e MOF: Supporting Analysis and UML e MOF: Supporting Analysis and DesignDesign

Il modelingmodeling è il primo passo chiave per costruire sistemi software di impresa con requisiti industrial-strength. industrial-strength. Questo ha portato l’OMG a promuovere l’ Unified Unified Modeling Language (UML)Modeling Language (UML)

un linguaggio visuale per lo scambio di modelli di sviluppo software ben definiti

UML è definito nella guida UML Notation Guide www.corba.org

SD 54:SD 54:

CORBA Computing ModelCORBA Computing ModelCORBA Computing ModelCORBA Computing ModelPassaggio di una richiestarichiesta da un clientclient ad un

object implementationobject implementation (vrdi figura): entrambi client e implementation sono isolati

dall’ORB tramite una OMG/ISO IDL interface. La richiesta non passa direttamente dal cliente

all’implementazione ma è sempre gestita da ORB

• ogni richiesta sia locale che remota ha sempre la stessa forma

• I dettagli per la distribuzione risedono in ORB

SD 55:SD 55:

CORBA Distribution ModelCORBA Distribution ModelCORBA Distribution ModelCORBA Distribution Model

Il passaggio di una richiestarichiesta èda un clientclient ad un object object implementationimplementation nel caso distribuito (figura) si basa sulla comunicazione ORB-to-ORBORB-to-ORB. IDL supporta la distribuzione in vari modi. In particolare GIOP (lo Standard general Inter ORB Protocol) specifica tutti gli aspetti di interoperabilità.

SD 56:SD 56:

COMPONENT PROGRAMMINGCOMPONENT PROGRAMMINGCOMPONENT PROGRAMMINGCOMPONENT PROGRAMMING

Si basa sullo sviluppo di componenti che implementano un’interfaccia ben definita (esempio: interfacce CORBA implementate in IDL). La base è costituita dalle interfacce che una componente esporta verso il mondo esterno. Ciascuna di queste è un socket su cui altre componenti ed applicazioni si agganciano (plug-in).

La programmazione basata su componenti separa la costruzione di unità computazionali dalla loro configurazione tramite connettori in un sistema computazionalmente complesso

SD 57:SD 57:

CORBA Component Model (CORBAbeans)CORBA Component Model (CORBAbeans)CORBA Component Model (CORBAbeans)CORBA Component Model (CORBAbeans)

Rappresenta un’estensione naturale del modello CORBA object.

Un container environment che incapsula • transactionality• security• persistence • provvede un’ interfaccia ed event resolution

Integrazione con Entreprise JavaBeans Software distribution format che facilita il marketing di

software CORBAcomponent

L’ambiente CORBAcomponents è sicuro, persistente e transactional.

SD 58:SD 58:

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (inheritance C++)(inheritance C++)

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (inheritance C++)(inheritance C++)

Ci riferiamo all’esempio IDL seguente

// IDL

interface A

{ void op_a(); };

interface B

{ void op_b(); };

interface I: A, B

{ void op_I(); };

SD 19:SD 19:

CORBA Implementazione dei CORBA Implementazione dei Servant(inheritance in C++)Servant(inheritance in C++) CORBA Implementazione dei CORBA Implementazione dei Servant(inheritance in C++)Servant(inheritance in C++)

// C++

2 class A_impl: virtual public POA_A

3 { public: virtual void op_a() throw(CORBA::SystemException); };

4 class B_impl: virtual public POA_B

5 {public: virtual void op_b() throw(CORBA::SystemException); };

6 class I_impl: virtual public POA_I, virtual public A_impl, virtual public B_impl

7 {public: virtual void op_i() throw(CORBA::SystemException); };

SD 20:SD 20:

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Inheritance in C++)(Inheritance in C++)

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Inheritance in C++)(Inheritance in C++)

Commenti sull’ implementazione in C++

2-3 definizione della classe A_impl. Essa eredita dalla class skeleton POA_A. Nel caso in cui a_impl avesse parametri questi verrebbero mappati secondo le regole di mapping IDL-to-C++;

4-5 idem per B_impl;

6-7 la class I_impl e’ derivata sia da POA_I che da A_impl e B_impl

E’ obbligatorio l’uso di ereditarieta’ “public virtual”; la keyword public e’ evitabile solo se I non eredita da altre interfacce, cioe’ se eredita solo da POA_I e nessuna classe implementazione eredita da I_impl. Infine non e’ necessario avere una classe implementazione per ogni interfaccia.

SD 21:SD 21:

CORBA Implementazione dei CORBA Implementazione dei ServantServant


Commenti sull’ implementazione in C++ (cont.)

Non e’ strettamente necessario provvedere una classe implementazione per ogni interfaccia. Qui I_impl e’ sufficiente purche’ implementi tutte le operazioni incluse quelle definite nelle interfacce base.

SD 21:SD 21:

CORBA Implementazione dei ServantCORBA Implementazione dei Servant (Inheritance in Java)(Inheritance in Java)

CORBA Implementazione dei ServantCORBA Implementazione dei Servant (Inheritance in Java)(Inheritance in Java)

// Java

2 public class I_impl extends IPOA

3 {

4 public void op_a() { };

5 public void op_b() { };

6 {public void op_i() { }

};

2-6 Viene definita una classe servant I_impl, che implementa op_i e le oerazioni ereditate op_a e op_b.

SD 22:SD 22:

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Inheritance in Java)(Inheritance in Java)

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Inheritance in Java)(Inheritance in Java)

Il compilatore IDL-to-Java genera parecchi file tra cui:

I.java, che definisce una interfaccia Java I contenente i metodi pubblici e gli attributi di I

IPOA.java, scheletro astratto di una classe da usare come base delle classi del servant

Diversamente dal C++, Java non ha ereditarieta’ multipla il che impedisce a una servant class di ereditare implementazioni di operazioni da altre servant class, escluso il caso di usare un’ implementazione basata sulla delegazione. Nel nostro caso e’ necessario implementare tutte le operazioni in una sola servant class I_impl, senza riferimenti al fatto che esse siano definite in I o in un’interfaccia da cui I e’ derivata.

SD 23:SD 23:

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Delegation)(Delegation)

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Delegation)(Delegation)

Implementazione di un servant tramite delegation

A volte non conviene usare l’inheritance quando questo porti a gerarchie di inheritance estremamente complesse (ad esempio l’uso di una classe di libreria che richiede uso eccessivo di inheritance).

Si puo’ far uso di una classe speciale, detta tie class, per delegare l’implementazione di un’interfaccia ad un’altra classe.

Delegation in C++

Il compile IDL-to-C++ puo’ generareuna tie class per un’ interfaccia in forma di template class che e’ derivata derivata dalla relativa skeleton class, ne ha lo stesso nome ma con suffisso _tie.

SD 23:SD 23:

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Delegation in C++)(Delegation in C++)


Implementazione di un servant tramite delegationDall’interfaccia dell’esempio C++ precedente si genera un template POA_I_tie da istanziare con una classe che implementi tutte le operazioni di I. Inoltre non e’ necessario che la classe che implementa le operazioni di I cioe’ I_impl_tie derivi da una classe skeleton. Un’istanza di I_impl_tie dellega la chiamata di tutte le operazioni a POA_I_tie nel modo seguente:

POA_I

^

POA_I_tie

^

(delega a)

^

I_impl_tie

SD 23:SD 23:



1 // C++

2 class I_impl_tie

3 {

4 public:

5 virtual void op_a() throw(CORBA::SystemException);

6 virtual void op_b() throw(CORBA::SystemException);

7 virtual void op_i() throw(CORBA::SystemException);

8 };

2 I_impl_tie e’ definita ma non derivata da un’altra classe.

5-7 I_impl_tie deve implementare tutte le operazioni di I, incluse quelle ereditate.

SD 23:SD 23:



1 // C++

2 typedef POA_I_tie< I_impl_tie > I_impl;

2 La classe servant I_impl e’ definita come template instance di POA_I_tie, parametrizzata con I_impl_tie.

Il template tie generato dal compilatore IDL contiene funzioni per cambiare l’ istanza denotata dal tie:

1 // C++

2 template<class T>

3 class POA_I_tie : public POA_I

4 {

5 public:

6 // ...

7 T* _tied_object();

8 void _tied_object(T& obj);

9 void _tied_object(T* obj, CORBA::Boolean release = true);

10 // ...

11 }SD 23:SD 23:



7-9 La funzione dell’oggetto _tied_object e’ quella di supportare l’ individuazione ed eventuali cambiamenti dell’ implementazione.

La prima modifier function chiama delete sulla istanza currente di tied prima di accettare la nuova istanza tied quando il flag release ha valore true; mettendolo poi a false per la nuova tied instance.

Anche la seconda modifier function chiama delete per la tied instance corrente prima di accettare la nuova istanza ma imposta il flag release al valore ad essa passato.

SD 23:SD 23:



I_skel_tie template:7-9 The _tied_object function permits you to retrieve

and change the implementation instance that is currently associated with the tie. The first modifier function calls deleteon the current tied instance before accepting the new tied instance if the release flag is currently true; the release flag for the new tied instance is set to false. The second modifier function also calls delete on the current tied instance before accepting the newinstance but sets the release flag to the passed value.

SD 23:SD 23:

CORBA Implementazione dei ServantCORBA Implementazione dei Servant ( con Delegation in Java)( con Delegation in Java)

CORBA Implementazione dei ServantCORBA Implementazione dei Servant ( con Delegation in Java)( con Delegation in Java)

Per ogni interfaccia IDL, il mapping IDL-to-Java genera un’ interfaccia per le “operations” che contengono metodi relativi agli attributi ed operazioni IDL. L’interfaccia alle operations viene anche utiizzata per supportare implementazioni di servant basate sulla delegazione.

Ad esempio, si genera la seguente classe relativa ad un’interfaccia I:

• IPOATie.java, tla classe che eredita da IPOA e delega tutte le richieste a un’istanza di IOperations.

SD 24:SD 24:

CORBA Implementazione dei ServantCORBA Implementazione dei Servant (Delegation in Java)(Delegation in Java)

CORBA Implementazione dei ServantCORBA Implementazione dei Servant (Delegation in Java)(Delegation in Java)

Per implementare la nostra classe servant tramite delegazione ci serviamo di una classe che implementa l’interfaccia di IOperations.

La figura seguente illustra tra le classi generate dal IDLtoJava translator e le clssi che implementano il servant:

IPOA

^

I_Impl IPOATie (delegation)

SD 24:SD 24:

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Delegation Java)(Delegation Java)

CORBA Implementazione dei Servant CORBA Implementazione dei Servant (Delegation Java)(Delegation Java)

IPOA

^

I_Impl IPOATie <--- IOperations

(delega) ^

I_Impl_TieSD 24:SD 24:

CORBA Implementazione dei ServantCORBA Implementazione dei Servant (Java)(Java)


1 // Java

2 public class I_impl_tie implements IOperations

3 {

4 public void op_a()

5 {

6 }

7 public void op_b()

8 {

9 }

10 public void op_i()

11 {

12 }

13 }

2 The servant class I_impl_tie is defined to implement the IOperations interface.

4-13 I_impl_tie must implement all of I’s operations, including inherited operations.

SD 24:SD 24:



Segue l’implementazione tramite delegation del nostro esempio

1 // Java

2 public class A_impl implements AOperations

3 {


5 {

6 }

7 }

8

SD 24:SD 24:



9 public class B_impl implements BOperations

10 {

11 public void op_b()

12 {

13 }

14 }

16 public class I_impl extends B_impl implements IOperations

17 {


19 {

20 }

22 public void op_i()

23 {

….

SD 24:SD 24:



1 // Java

2 public class A_impl implements AOperations

3 {


5 {

6 }

7 }

8

9 public class B_impl implements BOperations

SD 24:SD 24:

Creazione dei ServantCreazione dei Servant (C++) (C++)Creazione dei ServantCreazione dei Servant (C++) (C++)

1 // C++

2 I_impl* servant_pointer = new I_impl;

3 I_impl* another_servant_pointer = new I_impl;

2,3 Si sono creati due servants tramite new. Si noti che il codice precedente istanzia i servant ma non informa l’ORB della loro esistenza. Il run time di ORB server-side e’ informato dell’esistenza dei servant dopo la loro attivazione.

Se le classi servantsono state sviluppate tramite delegation, e’ necessario passare come parametro, al costruttore del servant, un oggetto della classe che implementa le operazioni di I:

SD 24:SD 24:


1 // C++

2 I_impl_tie* impl = new I_impl_tie;

3 POA_I_tie< I_impl_tie >* tie_pointer =

4 new POA_I_tie< I_impl_tie >(impl);

2 A new I_impl_tie is created with new.

3,4 An instance of POA_I_tie parameterized with I_impl_tie is created, taking impl a s a parameter. All operation calls to tie will then be delegated to impl.

In questo esempio, il lifetime di impl e’ accoppiato a quello del servant tie. Cioe’ quando il tie viene eliminato, il distruttore di tie opera una deletedi impl. Se si volesse disaccoppiare il lifetime di impl da quello di tie, ad esempio perche’ si vuole creare un servant sullo stack ma non sullo heap (rendendo illegale una call a delete su tie), si userebbe il codice seguente:

SD 24:SD 24:


1 // C++

2 I_impl_tie impl;

3 POA_I_tie< I_impl_tie >* tie =

4 new POA_I_tie< I_impl_tie >(&impl, false);

2 A new I_impl_tie is created, this time on the stack, not on the heap.

3,4 An instance of POA_I_tie is created. The false parameter tells tie not to call delete on impl.

SD 24:SD 24:

Creazione dei ServantCreazione dei Servant (Java) (Java)Creazione dei ServantCreazione dei Servant (Java) (Java)

Ogni classe tie generata dal traduttore IDL-to-Java ha due costruttori:

// Java

public class IPOATie extends IPOA

{

public IPOATie(IOperations delegate) { ... }

public IPOATie(IOperations delegate, POA poa) { ... }

...

}

Il secondo construttore permette di fornire un’stanza di POA da usarsi come valore di ritorno del metodo di tie _default_POA. In caso di macanza di tale istanza il metodo _default_POA restituisce il root POA dell’ ORB cui e’ stato associato il tie.

SD 24:SD 24:


Questo esempio mostra come creare servant in Java:

1 // Java

2 I_impl impl = new I_impl();

3 I_impl anotherImpl = new I_impl();

2,3 Two servants, impl and anotherImpl, are created with new.

Se la classe servant fosse stata scritta con delegazione, si sarebbe dovuto passare al costruttore di tie un oggetto che implementi la interfaccia di IOperations:

1 // Java

2 I_impl_tie impl = new I_impl_tie();

3 IPOATie tie = new IPOATie(impl);

2 A new I_impl_tie is created.

3 An instance of IPOATie is created, taking impl as a parameter. All operation calls to tie will then be delegated to impl.

SD 24:SD 24:


La classe tie fornisce metodi per accedere e cambiare l’oggetto implementazione:

1 // Java

2 public class IPOATie extends IPOA

3 {

4 ...

5 public IOperations _delegate() { ... }

6 public void _delegate(IOperations delegate) { ... }

7 ...

8 }

5 This method returns the current delegate (i.e., implementation) object.

6 This method changes the delegate object.

SD 24:SD 24:

CORBA (Un Esempio completo)CORBA (Un Esempio completo) CORBA (Un Esempio completo)CORBA (Un Esempio completo)

Hello World

Classico esempio introduttivo qui realizzato in forma client-server. Versione C++: #include <iostream.h>int main(int, char*[]){cout<< “Hello World!” << endl;return 0}

SD 25:SD 25:

CORBA (Hello World)CORBA (Hello World)CORBA (Hello World)CORBA (Hello World)

Hello World, versione Java: public class Greeter{ public static void main (String args[]) { System.out.println(“Hello World!”); }}

SD 26:SD 26:


Hello World in Corba Codice IDL: interface Hello;{ void say_hello();} Un’interfaccia IDL equivale ad una classe astratta in C+

+ o ad un’interfaccia Java

SD 27:SD 27:

CORBA (Hello World) CORBA (Hello World) CORBA (Hello World) CORBA (Hello World)

Hello World in Corba (linguaggio C++) Si deve prima tradurre il codice IDL in C++ con il

compilatore IDL idl Hello.idl (comando di attivazione)

questo comando crea quattro files

Hello.h,

Hello.cpp,Hello_skel.h,

Hello_skel.cpp

Quindi si implementano server e client SD 28:SD 28:

CORBA (Hello World) CORBA (Hello World) CORBA (Hello World) CORBA (Hello World)

Hello World in Corba (C++) Implementazione del server: si crea una classe

implementazione Hello_impl

#include <Hello_skel.h>

class Hello_impl: public POA_Hello;

public PortableServer::RefCountServantBase

{

public:

virtual void say_hello() throw(CORBA::SystemException);

{ } }; SD 29:SD 29:


Questa classe eredita dallo skeleton Questa classe eredita dallo skeleton POA_Hello, quindi si inPOA_Hello, quindi si include Hello_skel.hlude Hello_skel.h

Hello_impl e’ classe derivata da POA_HelloHello_impl e’ classe derivata da POA_Hello Inoltre si devono implementare tutte le Inoltre si devono implementare tutte le

operazioni della interfaccia in IDL (qui solo operazioni della interfaccia in IDL (qui solo say_hello). Hello_impl.cpp e’ quindi:say_hello). Hello_impl.cpp e’ quindi:#include <OB/CORBA.h>#include <Hello_impl.h>

void Hello_impl::say_hello() throw(CORBA::SystemException)

{ cout<< “Hello World!” << endl;}

#include <iostream.h>SD 30:SD 30:


Includiamo OB/CORBA.h che contiene le definizioni delle classi standard CORBA

Infine includiamo la definizione della classe Hello_impl

#include <iostream.h>

#include <OB/CORBA.h>

#include <Hello_impl.h>

void Hello_impl::say_hello() throw(CORBA::SystemException)

{ cout<< “Hello World!” << endl;

}SD 31:SD 31:


Si salvano quindi la class definition in Hello_impl.h e l’implementazione in Hello_impl.cpp

Infine si scrive il programma server. Il trattamento delle eccezioni e’ semplificato e sdoppiato in due funzioni main() e run().

main() crea l’ ORB e chiama run()

SD 32:SD 32:


#include <OB/CORBA.h>

#include <Hello_impl.h>

#include <fostream.h>

int run(CORBA::ORB_ptr);

int main(int argc,char* argv[])

{ int status = EXIT_SUCCESS;

CORBA::ORB_init(argc, argv);status = run(orb);

try

{

orb -> destroy();

}

SD 33:SD 33:


La funzione run() (commenti):La funzione run() (commenti):• un servant di tipo Hello_impl viene creato ed assegnato a un servant di tipo Hello_impl viene creato ed assegnato a

ServantBase_var:ServantBase_var:

int run(CORBA::ORB_ptr orb)

{ CORBA::Object_var poaObj= orb ->resolve_initial_references(“RootPOA”);

PortableServer::POA::_var rootPoa =PortableServer::POA::_narrow(poaObj);

PortableServer::POAManager_var manager =rootPoa -> the_POA Manager();

Hello_impl* helloImpl = new Hello_impl();

PortableServer::POA::ServantBase_var servant = helloImpl;}

SD 34:SD 34:

EVENT DRIVEN PROGRAMMINGEVENT DRIVEN PROGRAMMING

Event-Driven programmingEvent-Driven programmingEvent-Driven programmingEvent-Driven programming

Molti task di programmazione richiedono l’integrazione di fatti (eventi) che avvengono in modo asincrono: essi non avvengono a tempi fissi e controllati ed il sistema deve essere pronto a trattarli in ogni momento essi avvengano.

Ad esempio una GUI non può obbligare un utente a premere un tasto del mause dopo ogni spostamento.

SD 60:SD 60:

Event-Driven programmingEvent-Driven programmingEvent-Driven programmingEvent-Driven programmingThe most commonly used technique for doing this is called event-based

programming, and it is such a good coding idiom that it is used in

nearly every practical programming language in use today. Of course,

some languages offer better support for it than others...

The basic idea is that you have a queue of possible events, and as the

environment (i.e. the world outside the program) does things, so events

are generated and added to the queue. Meanwhile, the program sits

there, grabbing events off the queue and doing whatever it takes to deal

with them, usually by way of a gigantic [switch] statement (or whatever

that language's equivalent is.)

SD 61:SD 61:

Event-Driven programmingEvent-Driven programmingEvent-Driven programmingEvent-Driven programming

Event-driven programming è quindi uno stile di programmazione in cui il programma è driven da eventi esterni. I programmi Event-driven sono composti da piccole porzioni di codice dette:

event handlers, attivati in risposta a eventi esterni

un dispatcher, che attiva gli event handlers, sulla base di eventuali event queue che memorizzano gli eventi non ancore processati.

SD 62:SD 62:

Event-Driven programming cont.Event-Driven programming cont.Event-Driven programming cont.Event-Driven programming cont.

Event: - Unlike traditional programs, which follow their own control flow pattern, onlysometimes changing course at branch points, the control flow of event-driven programs is largely driven by external events.

event handler: an event handler is the code that is executed when an event occurs. See also event.

SD 63:SD 63:

Event-Driven programming cont.Event-Driven programming cont.Event-Driven programming cont.Event-Driven programming cont.In molti casi gli event handlers possono

attivare (to trigger) a loro volta nuovi eventi, provocando una cascata di eventi.

Event-driven programming rinforza flessibilità e asincronia e tende ad essere praticamente modeless. Le graphical user interface sono solitamente programmate in stile event-driven.

Gli Operating Systems costituiscono un altro esempio di programmi event-driven.

SD 64:SD 64:

Interrupt-Driven programmingInterrupt-Driven programmingInterrupt-Driven programmingInterrupt-Driven programming

The style of programming where the program is not in control all the time but rather responds to interrupts or signals in order to get started.

At the lowest level, interrupt handlers act as direct event handlers for hardware events, with the CPU hardware performing the role of the dispatcher.

SD 65:SD 65:

Event-Driven programmingEvent-Driven programmingEvento

come un’eccezione un evento è una condizione (hardware) “segnalata” (espressa tramite segnale)

al contrario di un eccezione (meccanismo simile) un evento rappresenta una condizione normale

La tecnica usata per per gestire eventi è detta event-based o event-driven programming,

Nella programmazione event-driven (ad eventi) non si ha un flusso di controllo normale ma sostanzialmente solo event handlers

SD 66:SD 66:

Event-Driven programmingEvent-Driven programming

L’idea base è quella di gestire una coda di eventi in modo tale che quando l’ambiente (mondo esterno al programma) è operativo genera eventi che vengono inseriti nella coda (in attesa di essere serviti)

Il programma cicla all’interno di un outermost (switch) statement (o usa tecniche equivalenti) in cui si chiede se vi sono eventi in attesa nella coda, in caso affermativo li preleva e li gestisce (li serve).

SD 67:SD 67:

Event-Driven programmingEvent-Driven programming

Event-driven programming è quindi uno stile di programmazione in cui il programma è pilotato (driven) da eventi esterni. I programmi Event-driven sono composti da piccole porzioni di codice dette:

event handlers, attivati in risposta a eventi esterni e da un

event dispatcher, che attiva gli event handlers, tramite l’uso di event queue che memorizzano gli eventi non ancora processati.

SD 68:SD 68:

Event-Driven programming cont.Event-Driven programming cont.

Ne consegue che, al contrario dei programmi tradizionali che seguono un proprio flusso di controllo (own control flow pattern) e solo raramente cambiano direzione ai punti di salto

( detti “branch points”), il flusso di controllo dei programmi a eventi (event-driven) è sostanzialmente pilotato dagli eventi esterni. Un event handler è una porzione di codice eseguita quando si verifica un evento.

SD 69:SD 69:

Event-Driven programming cont.Event-Driven programming cont.

In molti casi gli event handlers possono attivare (to trigger) a loro volta nuovi eventi, provocando una cascata di eventi.

Event-driven programming potenzia flessibilità e asincronia e tende ad essere praticamente modeless. Le graphical user interface sono solitamente programmate in stile event-driven.

Gli Operating Systems costituiscono un altro esempio di event-driven programs.

SD 70:SD 70:

Interrupt-Driven programmingInterrupt-Driven programming

The style of programming where the program is not in control all the time but rather responds to interrupts or signals in order to get started.

At the lowest level, interrupt handlers act as direct event handlers for hardware events, with the CPU hardware performing the role of the dispatcher.

SD 71:SD 71:

Interrupt-Driven programmingInterrupt-Driven programming

Lo stile di programmazione in cui il programma non ha il controllo in modo continuo ma responde ad interrupts, cioè a segnali che ne risvegliano l’esecuzione.

Al livello più basso, gli interrupt handlers operano come gestori diretti di eventi hardware, mentre la CPU gioca il ruolo del dispatcher.

SD 72:SD 72:

SistemiDistribuiti January 24, 2000

Computer Science Department Genova University

SYNCHRONOUS/ REACTIVE

PROGRAMMING

SYNCHRONOUS/ REACTIVE

PROGRAMMING

In Sistemi Software Concorrenti

April 25, 2004

74

SD

Sistemi Reattivi (Reactive Systems)Sistemi Reattivi (Reactive Systems)

Un sistema reattivo è un sistema event-driven che interagisce continuamente con l’ ambiente (environment) reagendo agli stimoli che da esso gli pervengono. Si assume che i sistemi reattivi:

eseguano con una velocità mai sopraffatta da quella dell’ambiente.

usualmente non terminino mai e quindi non siano facilmente caratterizzabili da semplici funzioni che partendo da uno stato iniziale li portino ad uno stato finale.

SD 74:SD 74:

April 25, 2004

75

SD

Sistemi Reattivi real-timeSistemi Reattivi real-time

Un sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints).

Il termine reactive è più specifico di event-driven (piuttosto overloaded in letteratura)

ma è più generale di soft real-time e near real-time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time.

I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi).

SD 75:SD 75:

April 25, 2004

76

SD

Event-Driven programming contEvent-Driven programming cont.Event-Driven programming contEvent-Driven programming cont.

a reactive system is an event-driven systeminterrupt-driven is event-driven thus

reactive systems |

|

interrupt-driven systems | ==> event-driven systems |

|

signal-driven systems |

SD 76:SD 76:

April 25, 2004

77

SD

Sistemi Reattivi (Cont.)Sistemi Reattivi (Cont.)

I linguaggi sincroni (synchronous languages) sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints).

Il termine reactive è più specifico di event-driven (piuttosto overloaded in letteratura)

ma è più generale di soft real-time e near real-time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time.

I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi).

SD 77:SD 77:

Architetture Software SincroneArchitetture Software Sincrone

Le architetture software sincrone sono state esplicitamente introdotte per la programmazione dei sistemi reattivi. I sistemi risultanti includono architetture data-flow e dichiarative ed anche quelle derivate dai tradizionali linguaggi imperativi.

SD 78:SD 78:

Architetture Software Sincrone (Cont.)

Architetture Software Sincrone (Cont.)

L’ ipotesi di sincronia (synchrony hypothesis) assume che tutte le computazioni avvengano in passi atomici discreti durante i quali il tempo viene ignorato (come se venissero eseguite in tempo nullo), inoltre si ipotizza che:

Il tempo avanzi solo quando non vi è codice eligible for execution.

Durante un singolo step tutti gli output ed input avvengano allo stesso istante: cioè output e input sono mutuamente sincroni

il concetto di tempo continuo è sostituito da una serie ordinata di passi (step) discreti tra i quali avvengono cambi discreti nello stato globale.

Il codice eseguito in ogni passo è detto una reazione (reaction) SD 79:SD 79:

Ipotesi di sincronia (Cont.)Ipotesi di sincronia (Cont.)

L’ ipotesi di sincronia permette di gestire la concorrenza interna di tipo cooperativo in modo deterministico.

Gli eventi concorrenti asincroni si manifestano solo nell’ambito di global state ‘shapshots’

Nessuna sezione critica esplicita occorre nel codice sorgente né in forma di monitor o di oggetti concorrenti

tutto il codice può essere pensatocome interno a sezioni critiche implicite eseguite con lo stile di programmazione dei guarded command

SD 80:SD 80:

Linguaggi sincroniLinguaggi sincroni

I linguaggi syncroni/reattivi si focalizzano sulla concorrenza interna di tipo cooperativo comunemente presente in driver e controller di sistema

essi incapsulano nella compilazione tutta la concorrenza interna cooperativa producendo una singola macchina a stati finiti che gestisce tutte le attività

I principali sono Meta/NPL di ISIS [Marzullo & Wood] Estrel e Reactive C

SD 81:SD 81:


catch(const CORBA::Exception&){

status = EXIT_FAILURE;}

}

return status;} la prima cosa che fa e’ inizializare ORB. Questa operazione

richiede i parametri con cui il programma e’ stato attivato

la funzione run() viene poi attivata

il codice cattura e stampa tutte le eccezioni sollevate da ORB_init() o run()

Se ORB e’ stato creato con successo viene anche distrutto viene restituito lo stato di ritorno

SD 82:SD 82:


La funzione run() e’:La funzione run() e’:int run(CORBA::ORB_ptr orb)

{ CORBA::Object_var poaObj=

orb ->resolve_initial_references(“RootPOA”);PortableServer::POA::_var rootPoa =

PortableServer::POA::_narrow(poaObj); PortableServer::POAManager_var manager =

rootPoa -> the_POA Manager();Hello_impl* helloImpl = new Hello_impl();

PortableServer::POA::ServantBase_var servant = helloImpl;

}SD 83:SD 83:


La funzione run() (continuazione):La funzione run() (continuazione):Hello_var hello = helloImpl ->_this();

CORBA::String_var s = orb -> object_to_string(hello);

const char* refFilw = “Hello.ref”;

ofstream out(refFile);

out << s << endl;

out.close();

manager ->activate();

orb -> run();

return EXIT_SUCCESS;

}

SD 84:SD 84:


La funzione run() (commenti):La funzione run() (commenti): Il client accedera’ all’oggetto implementazione tramite Il client accedera’ all’oggetto implementazione tramite

una “stringfied” una “stringfied” object referenceobject reference salvata su un file, che salvata su un file, che sara’ in seguito letto dal client e riconvertito in un object sara’ in seguito letto dal client e riconvertito in un object referencereference

Hello_var hello = helloImpl ->_this();

CORBA::String_var s = orb -> object_to_string(hello);

const char* refFilw = “Hello.ref”;

ofstream out(refFile);out << s << endl;out.close();

SD 85:SD 85:


Implementazione del client:Implementazione del client:#include <OB/CORBA.h>

#include < Hello.h>

#include <fstream.h>

int run(CORBA::ORB_ptr);

int main(int argc, char* argv[])

{

…// come il server

}

SD 86:SD 86:


Implementazione del client (commenti):Implementazione del client (commenti): se l’applicazione usa piu’ di un oggetto non e’

necessario salvarne il riferimento per ciascuno: solitamente ne basta uno che restituisce riferimenti agli altri

Diversamente dal server il client non include

Hello_impl.h

SD 87:SD 87:


Implementazione del client (continuazione):Implementazione del client (continuazione):int run(CORBA::ORB_ptr orb);

{

const char* refFile = “Hello.ref”;

ifstream in(refFile);

char s[2048];

in >> s;

CORBA::Object_var obj = orb -> string_to_object(s);

Hello_var hello = Hello::_narrow(obj);

hello -> say_hello();

return 0

} SD 88:SD 88:


Implementazione del client (commenti):Implementazione del client (commenti): l’object reference “stringfield” scritto dal server

viene letto dal client e convertito in

CORBA::Object object reference. E non e’

richiesto un riferimento alla root di POA (o POA

Manager)

l’op. _narrow genera un riferimento ad un

oggetto Hello (effetto simile a un cast dinamico)

SD 89:SD 89:



{

const char* refFile = “Hello.ref”; ifstream in(refFile);

char s[2048];

in >> s;




return 0

} SD 90:SD 90:



{

const char* refFile = “Hello.ref”; ifstream in(refFile);

char s[2048];

in >> s;




return 0

} SD 91:SD 91:

Documents

Sistemi Distribuiti RPC E CORBA