Massimo Ancona Sistemi Distribuiti RPC E CORBA SD 1:

Presentazione sul tema: "Massimo Ancona Sistemi Distribuiti RPC E CORBA SD 1:"— Transcript della presentazione:

1 Massimo Ancona Sistemi Distribuiti RPC E CORBA SD 1:

2 April 25, 2004 2 SD 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:

3 April 25, 2004 3 SD MECCANISMO RPC 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.

4 April 25, 2004 4 SD MECCANISMO RPC 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.

5 April 25, 2004 5 SD 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:

6 April 25, 2004 6 SD MECCANISMO RPC SD 6:

7 April 25, 2004 7 SD 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:

8 April 25, 2004 8 SD 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:

9 April 25, 2004 9 SD 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:

10 CORBA Common Object Broker Architecture SD 10:

11 CORB A 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:

12 CORB A 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:

13 CORB A 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:

14 CORBA (struttura di un’applic.) SD 14:

15 CORBA: tipi di invokation (call) 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

16 CORBA: stili di invokation (call) 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.

17 CORBA (architettura) SD 15:

18 CORBA (architettura) SD 15:

19 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:

20 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:

21 OGGETTI CORBA SD 18:

22 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:

23 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:

24 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:

25 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:

26 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:

27 CORBA (2) Common Object Broker Architecture SD 10:

28 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:

29 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:

30 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:

31 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:

32 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:

33 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:

34 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:

35 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:

36 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:

37 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:

38 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:

39 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:

40 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:

41 Dynamic Invocation 9 SD 22:

42 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:

43 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:

44 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:

45 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:

46 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:

47 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:

48 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:

49 Dynamic Invocation 8 /*C*/ Status=CORBA_Object_create_request ( personnel_obj,  &Ev,  “hire”,  hire_op_NVList,  Emp_obj,  &req_obj,  0  ) SD 22:

50 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:

51 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:

52 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:

53 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:

54 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:

55 CORBA 3.0 SD 35:

56 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:

57 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:

58 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:

59 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:

60 POA - Basics  POA media tra l’ORB e e le applicazioni server SD 40:

61 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:

62 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:

63 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:

64 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:

65 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:

66 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:

67 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:

68 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 concorrentemente SD 48:

69 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:

70 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:

71 OMG Specification Suite Come risultato si è avuta un’ampia gamma di specifiche OMG SD 51:

72 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:

73 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:

74 UML e MOF: Supporting Analysis and Design modeling industrial-strength. Unified Modeling Language (UML) 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:

75 CORBA Computing Model richiestaclientobject implementation 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:

76 CORBA Distribution Model richiestaclientobject implementation ORB-to-ORB 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:

77 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:

78 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:

79 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:

80 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:

81 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:

82 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:

83 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:

84 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:

85 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:

86 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:

87 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:

88 CORBA Implementazione dei Servant (Delegation in C++) 1 // C++ 2 typedef POA_I_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 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:

89 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:

90 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:

91 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:

92 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:

93 CORBA Implementazione dei Servant (Delegation Java) IPOA ^ I_Impl IPOATie <--- IOperations (delega) ^ I_Impl_Tie SD 24:

94 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:

95 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:

96 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:

97 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:

98 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 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:

99 Creazione dei Servant (C++) 1 // C++ 2 I_impl_tie* impl = new I_impl_tie; 3 POA_I_tie * tie_pointer = 4 new POA_I_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:

100 Creazione dei Servant (C++) 1 // C++ 2 I_impl_tie impl; 3 POA_I_tie * tie = 4 new POA_I_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:

101 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:

102 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:

103 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:

104 CORBA (Un Esempio completo) 8Hello World Classico esempio introduttivo qui realizzato in forma client-server. /Versione C++: #include int main(int, char*[]) { cout<< “Hello World!” << endl; return 0 } SD 25:

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

106 CORBA (Hello World) 8Hello 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:

107 CORBA (Hello World) 8Hello 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:

108 CORBA (Hello World) 8Hello World in Corba (C++) /Implementazione del server: si crea una classe implementazione Hello_impl #include class Hello_impl: public POA_Hello; public PortableServer::RefCountServantBase { public: virtual void say_hello() throw(CORBA::SystemException); { }{ } }; }; SD 29:

109 CORBA (Hello World)  Questa classe eredita dallo skeleton POA_Hello, quindi si inlude Hello_skel.h  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 void Hello_impl::say_hello() throw(CORBA::SystemException) { cout<< “Hello World!” << endl;} #include SD 30:

110 CORBA (Hello World)  Includiamo OB/CORBA.h che contiene le definizioni delle classi standard CORBA  Infine includiamo la definizione della classe Hello_impl #include void Hello_impl::say_hello() throw(CORBA::SystemException) { cout<< “Hello World!” << endl; } SD 31:

111 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:

112 CORBA (Hello World) #include 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:

113 CORBA (Hello World)  La funzione run() (commenti): un servant di tipo Hello_impl viene creato ed assegnato a ServantBase_var: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:

114 EVENT DRIVEN PROGRAMMING

115 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:

116 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:

117 Event-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: 8event handlers, attivati in risposta a eventi esterni 8un dispatcher, che attiva gli event handlers, sulla base di eventuali event queue che memorizzano gli eventi non ancore processati. SD 62:

118 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. 8event handler: an event handler is the code that is executed when an event occurs. See also event. SD 63:

119 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. 8Gli Operating Systems costituiscono un altro esempio di programmi event-driven. SD 64:

120 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:

121 Event-Driven programming Evento 8come un’eccezione un evento è una condizione (hardware) “segnalata” (espressa tramite segnale) 8al 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, 8Nella programmazione event-driven (ad eventi) non si ha un flusso di controllo normale ma sostanzialmente solo event handlers SD 66:

122 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:

123 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: 8event 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:

124 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:

125 Event-Driven programming cont. In molti casi gli event handlers possono attivare (to trigger) a loro volta nuovi eventi, provocando una cascata di eventi. 8Event-driven programming potenzia flessibilità e asincronia e tende ad essere praticamente modeless. Le graphical user interface sono solitamente programmate in stile event-driven. 8Gli Operating Systems costituiscono un altro esempio di event-driven programs. SD 70:

126 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:

127 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:

128 SistemiDistribuiti January 24, 2000 Computer Science Department Genova University SYNCHRONOUS/ REACTIVE PROGRAMMING In Sistemi Software Concorrenti

129 April 25, 2004 74 SD 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: 8 eseguano con una velocità mai sopraffatta da quella dell’ambiente. 8usualmente 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:

130 April 25, 2004 75 SD Sistemi Reattivi real-time Un sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints). 8Il termine reactive è più specifico di event- driven (piuttosto overloaded in letteratura) 8ma è più generale di soft real-time e near real- time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time. 8I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi). SD 75:

131 April 25, 2004 76 SD Event-Driven programming cont Event-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:

132 April 25, 2004 77 SD Sistemi Reattivi (Cont.) I linguaggi sincroni (synchronous languages) sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints). 8Il termine reactive è più specifico di event- driven (piuttosto overloaded in letteratura) 8ma è più generale di soft real-time e near real- time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time. 8I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi). SD 77:

133 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:

134 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. 8Durante un singolo step tutti gli output ed input avvengano allo stesso istante: cioè output e input sono mutuamente sincroni 8il concetto di tempo continuo è sostituito da una serie ordinata di passi (step) discreti tra i quali avvengono cambi discreti nello stato globale. 8Il codice eseguito in ogni passo è detto una reazione (reaction) SD 79:

135 Ipotesi di sincronia (Cont.) L’ ipotesi di sincronia permette di gestire la concorrenza interna di tipo cooperativo in modo deterministico. 8Gli eventi concorrenti asincroni si manifestano solo nell’ambito di global state ‘shapshots’ 8Nessuna sezione critica esplicita occorre nel codice sorgente né in forma di monitor o di oggetti concorrenti 8tutto il codice può essere pensatocome interno a sezioni critiche implicite eseguite con lo stile di programmazione dei guarded command SD 80:

136 Linguaggi sincroni I linguaggi syncroni/reattivi si focalizzano sulla concorrenza interna di tipo cooperativo comunemente presente in driver e controller di sistema 8essi incapsulano nella compilazione tutta la concorrenza interna cooperativa producendo una singola macchina a stati finiti che gestisce tutte le attività 8I principali sono Meta/NPL di ISIS [Marzullo & Wood] Estrel e Reactive C SD 81:

137 CORBA (Hello World) catch(const CORBA::Exception&) { status = EXIT_FAILURE; } } return status; } 8la prima cosa che fa e’ inizializare ORB. Questa operazione richiede i parametri con cui il programma e’ stato attivato 8la funzione run() viene poi attivata 8il codice cattura e stampa tutte le eccezioni sollevate da ORB_init() o run() 8Se ORB e’ stato creato con successo viene anche distrutto 8viene restituito lo stato di ritorno SD 82:

138 CORBA (Hello World) 8La 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:

139 CORBA (Hello World) 8La 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:

140 CORBA (Hello World) 8La 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:

141 CORBA (Hello World) 8Implementazione del client: #include int run(CORBA::ORB_ptr); int main(int argc, char* argv[]) { …// come il server } SD 86:

142 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:

143 CORBA (Hello World) 8Implementazione 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:

144 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:

145 CORBA (Hello World) 8Implementazione 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:

146 CORBA (Hello World) 8Implementazione 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: