Transcript Nessun titolo diapositiva

Sistemi Distribuiti
RPC E CORBA
Massimo Ancona
SD 1:
2
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:
April 25, 2004
SD
MECCANISMO RPC
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 objectoriented, allora una RPC viene anche detta RMI (remote
method invocation).
RPC e' un ottimo metodo per implementare il modello clientserver. 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.
SD 3:
April 25, 2004
SD
MECCANISMO RPC
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.
SD 4:
April 25, 2004
SD
OSF/DCE Distributed Computing
Environment
5
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:
April 25, 2004
SD
MECCANISMO RPC
April 25, 2004
SD
6
SD 6:
7
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 wireless
SD 7:
April 25, 2004
SD
8
GROUP COMMUNICATION
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:
April 25, 2004
SD
9
GROUP COMMUNICATION
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:
April 25, 2004
SD
CORBA
Common Object Broker
Architecture
SD 10:
Common Object Request Broker
Architecture (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:
Common Object Request Broker
Architecture (CORBA)
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 server
SD 12:
Common Object Request Broker
Architecture (CORBA)
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
rete
SD 13:
CORBA (struttura di un’applic.)
SD 14:
CORBA: tipi di invokation (call)
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
SD 14:
CORBA: stili di invokation (call)
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.
SD 14:
CORBA (architettura)
SD 15:
CORBA (architettura)
SD 15:
OGGETTI 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:
OGGETTI CORBA
• 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:
OGGETTI CORBA
SD 18:
CORBA: 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:
IDL: 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:
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:
IDL: 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:
IDL: Ereditarieta’ Multipla 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:
CORBA (2)
Common Object Broker
Architecture
SD 10:
CORBA: Communication(Invocation) Stiles
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 communication
L’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:
CORBA Invocation 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:
CORBA 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:
CORBA 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:
Uso 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:
Stub Style Invocation 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:
Stub 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:
Stub 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:
Stub Style Invocation 4
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:
Stub Style Invocation 5
/* C */
new_emp_obj = CORP_Personnel_hire
(
personnel_obj
&Ev,
ctx_obj,
new_emp_data,
dept_obj,
new_emp_badge
);
SD 22:
Stub Style Invocation 6
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:
Stub Style Invocation 7
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:
Stub Style Invocation 8
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:
Dynamic Invocation 9
SD 22:
Dynamic Invocation 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:
Dynamic Invocation 2
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:
Dynamic Invocation 3
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:
Dynamic Invocation 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 tramite
CORBA_ORB_create_list
SD 22:
Dynamic Invocation 5
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:
Dynamic Invocation 6
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:
Dynamic Invocation 7
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:
Dynamic Invocation 8
/*C*/
Status=CORBA_Object_create_request
(
personnel_obj,
&Ev,
“hire”,
hire_op_NVList,
Emp_obj,
&req_obj,
0
)
SD 22:
Dynamic Invocation 9
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:
Dynamic Invocation 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:
Dynamic Invocation 11
Come implementare una dynamic invocation
1. 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:
Dynamic Invocation 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:
Dynamic Invocation 13
Come 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:
CORBA 3.0
SD 35:
Evoluzione 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:
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 Value
SD 37:
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:
POA - 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:
POA - Basics
 POA media tra l’ORB e e le applicazioni server
SD 40:
POA - 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:
POA - 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:
POA - Basics 3
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:
POA - Basics 4
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:
Oggetti 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:
Oggetti 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:
Oggetti 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:
POA 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
SD 48:
concorrentemente
CORBA & 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 CORBA
SD 49:
USO 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:
OMG Specification Suite
Come risultato si è avuta un’ampia gamma di
specifiche OMG
SD 51:
ARCHITECTURAL 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:
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:
UML e MOF: Supporting Analysis and Design
Il modeling è il primo passo chiave per costruire
sistemi software di impresa con requisiti
industrial-strength. Questo ha portato l’OMG a
promuovere l’ Unified 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:
CORBA Computing Model
Passaggio di una richiesta da un client ad un object
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:
CORBA Distribution Model
Il passaggio di una richiesta èda un client ad un object
implementation nel caso distribuito (figura) si basa sulla
comunicazione ORB-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:
COMPONENT 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:
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:
CORBA Implementazione dei Servant
(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:
CORBA Implementazione dei
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:
CORBA Implementazione dei Servant
(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:
CORBA Implementazione dei Servant
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:
CORBA Implementazione dei Servant
(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:
CORBA Implementazione dei Servant
(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:
CORBA Implementazione dei Servant
(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:
CORBA Implementazione dei Servant
(Delegation in C++)
Implementazione di un servant tramite delegation
Dall’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:
CORBA Implementazione dei Servant
(Delegation in C++)
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:
CORBA Implementazione dei Servant
(Delegation in C++)
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:
CORBA Implementazione dei Servant
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:
CORBA Implementazione dei Servant
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:
CORBA Implementazione dei Servant ( 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:
CORBA Implementazione dei Servant
(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:
CORBA Implementazione dei Servant
(Delegation Java)
IPOA
^
I_Impl
IPOATie <--- IOperations
(delega)
^
I_Impl_Tie
SD 24:
CORBA Implementazione dei Servant (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:
CORBA Implementazione dei Servant (Java)
Segue l’implementazione tramite delegation del nostro
esempio
1 // Java
2 public class A_impl implements AOperations
3{
4 public void op_a()
5{
6}
7}
8
SD 24:
CORBA Implementazione dei Servant (Java)
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 {
18 public void op_a()
19 {
20 }
22 public void op_i()
23 {
….
SD 24:
CORBA Implementazione dei Servant (Java)
1 // Java
2 public class A_impl implements AOperations
3{
4 public void op_a()
5{
6}
7}
8
9 public class B_impl implements BOperations
SD 24:
Creazione dei Servant (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 serverside 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:
Creazione dei Servant (C++)
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:
Creazione dei Servant (C++)
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:
Creazione dei Servant (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:
Creazione dei Servant (Java)
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:
Creazione dei Servant (Java)
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:
CORBA (Un Esempio completo)
8 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:
CORBA (Hello World)
8 Hello World, versione Java:
public class Greeter
{
public static void main (String args[])
{
System.out.println(“Hello World!”);
}
}
SD 26:
CORBA (Hello World)
8 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:
CORBA (Hello World)
8 Hello World in Corba (linguaggio C++)
/
Si deve prima tradurre il codice IDL in C++ con
il compilatore IDL
Widl Hello.idl (comando di attivazione)
Wquesto comando crea quattro files
Hello.h,
Hello.cpp,
Hello_skel.h,
Hello_skel.cpp
/
Quindi si implementano server e client
SD 28:
CORBA (Hello World)
8 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:
CORBA (Hello World)
Questa classe eredita dallo skeleton POA_Hello,
quindi si include Hello_skel.h
Hello_impl e’ classe derivata da POA_Hello
Inoltre si devono implementare tutte le
operazioni della interfaccia in IDL (qui solo
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:
CORBA (Hello World)
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:
CORBA (Hello World)
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:
CORBA (Hello World)
#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:
CORBA (Hello World)
La funzione run() (commenti):
•
un servant di tipo Hello_impl viene creato ed assegnato a
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:
EVENT DRIVEN
PROGRAMMING
Event-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:
Event-Driven programming
The 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:
Event-Driven programming
Event-driven programming è quindi uno stile
di programmazione in cui il programma è
driven da eventi esterni. I programmi Eventdriven sono composti da piccole porzioni di
codice dette:
8 event handlers, attivati in risposta a eventi
esterni
8 un dispatcher, che attiva gli event handlers,
sulla base di eventuali event queue che
memorizzano gli eventi non ancore processati.
SD 62:
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.
8 event handler: an event handler is the
code that is executed when an event
occurs. See also event.
SD 63:
Event-Driven programming cont.
In molti casi gli event handlers possono attivare
(to trigger) a loro volta nuovi eventi,
provocando una cascata di eventi.
8 Event-driven programming rinforza
flessibilità e asincronia e tende ad essere
praticamente modeless. Le graphical user
interface sono solitamente programmate in
stile event-driven.
8 Gli Operating Systems costituiscono un altro
esempio di programmi event-driven.
SD 64:
Interrupt-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:
Event-Driven programming
Evento
8 come un’eccezione un evento è una condizione
(hardware) “segnalata” (espressa tramite segnale)
8 al contrario di un eccezione (meccanismo simile) un
evento rappresenta una condizione normale
La tecnica usata per per gestire eventi è detta eventbased o event-driven programming,
8 Nella programmazione event-driven (ad eventi) non si
ha un flusso di controllo normale ma sostanzialmente
solo event handlers
SD 66:
Event-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:
Event-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:
8 event handlers, attivati in risposta a eventi
esterni e da un
8 event dispatcher, che attiva gli event handlers,
tramite l’uso di event queue che memorizzano
gli eventi non ancora processati.
SD 68:
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:
Event-Driven programming cont.
In molti casi gli event handlers possono attivare
(to trigger) a loro volta nuovi eventi,
provocando una cascata di eventi.
8 Event-driven programming potenzia
flessibilità e asincronia e tende ad essere
praticamente modeless. Le graphical user
interface sono solitamente programmate in
stile event-driven.
8 Gli Operating Systems costituiscono un altro
esempio di event-driven programs.
SD 70:
Interrupt-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:
Interrupt-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:
Computer Science Department
Genova University
SYNCHRONOUS/
REACTIVE
PROGRAMMING
In Sistemi Software Concorrenti
SistemiDistribuiti
January 24, 2000
Sistemi Reattivi (Reactive Systems)
74
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:
8 eseguano con una velocità mai sopraffatta da
quella dell’ambiente.
8 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:
April 25, 2004
SD
Sistemi Reattivi real-time
75
Un sistema real-time è un sistema reattivo che
deve rispettare vincoli temporali (timing
constraints).
8 Il termine reactive è più specifico di eventdriven (piuttosto overloaded in letteratura)
8 ma è più generale di soft real-time e near realtime: poiché esso non si riferisce a vincoli
temporali da rispettare in real-time.
8 I sistemi reattivi più semplici vengono spesso
programmati come macchine a stati finiti
(automi).
SD 75:
April 25, 2004
SD
Event-Driven programming cont.
76
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:
April 25, 2004
SD
77
Sistemi Reattivi (Cont.)
I linguaggi sincroni (synchronous languages)
sistema real-time è un sistema reattivo che
deve rispettare vincoli temporali (timing
constraints).
8 Il termine reactive è più specifico di eventdriven (piuttosto overloaded in letteratura)
8 ma è più generale di soft real-time e near realtime: poiché esso non si riferisce a vincoli
temporali da rispettare in real-time.
8 I sistemi reattivi più semplici vengono spesso
programmati come macchine a stati finiti
(automi).
SD 77:
April 25, 2004
SD
Architetture 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:
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.
8 Durante un singolo step tutti gli output ed input
avvengano allo stesso istante: cioè output e input
sono mutuamente sincroni
8 il concetto di tempo continuo è sostituito da una serie
ordinata di passi (step) discreti tra i quali avvengono
cambi discreti nello stato globale.
8 Il codice eseguito in ogni passo è detto una reazione
(reaction)
SD 79:
Ipotesi di sincronia (Cont.)
L’ ipotesi di sincronia permette di gestire la
concorrenza interna di tipo cooperativo in
modo deterministico.
8 Gli eventi concorrenti asincroni si manifestano
solo nell’ambito di global state ‘shapshots’
8 Nessuna sezione critica esplicita occorre nel
codice sorgente né in forma di monitor o di
oggetti concorrenti
8 tutto il codice può essere pensatocome interno
a sezioni critiche implicite eseguite con lo
stile di programmazione dei guarded
command
SD 80:
Linguaggi sincroni
I linguaggi syncroni/reattivi si focalizzano sulla
concorrenza interna di tipo cooperativo
comunemente presente in driver e controller
di sistema
8 essi incapsulano nella compilazione tutta la
concorrenza interna cooperativa producendo
una singola macchina a stati finiti che gestisce
tutte le attività
8 I principali sono Meta/NPL di ISIS [Marzullo &
Wood] Estrel e Reactive C
SD 81:
CORBA (Hello World)
catch(const CORBA::Exception&)
{
status = EXIT_FAILURE;
}
}
return status;
}
8 la prima cosa che fa e’ inizializare ORB. Questa operazione
richiede i parametri con cui il programma e’ stato attivato
8 la funzione run() viene poi attivata
8 il codice cattura e stampa tutte le eccezioni sollevate da
ORB_init() o run()
8 Se ORB e’ stato creato con successo viene anche distrutto
8 viene restituito lo stato di ritorno
SD 82:
CORBA (Hello World)
8 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:
CORBA (Hello World)
8 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:
CORBA (Hello World)
8 La funzione run() (commenti):
/
Il client accedera’ all’oggetto implementazione tramite
una “stringfied” object reference salvata su un file, che
sara’ in seguito letto dal client e riconvertito in un
object reference
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:
CORBA (Hello World)
8 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:
CORBA (Hello World)
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:
CORBA (Hello World)
8 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:
CORBA (Hello World)
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:
CORBA (Hello World)
8 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 90:
CORBA (Hello World)
8 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 91: