1 / 146

Sistemi Distribuiti RPC E CORBA

Sistemi Distribuiti RPC E CORBA. Massimo Ancona. SD 1:. COMUNICAZIONI CLIENT-SERVER. 2. Il protocollo RPC. Si presenta in tre forme: request protocol (R) - isi usa quando non e’ richiesto un valore di ritorno (tipo void).

chandler
Download Presentation

Sistemi Distribuiti RPC E CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sistemi Distribuiti RPC E CORBA Massimo Ancona SD 1:

  2. COMUNICAZIONI CLIENT-SERVER 2 • 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

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

  4. 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

  5. OSF/DCEDistributed 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

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

  7. GROUP COMMUNICATION 7 Si basa sul concetto diMulticast - 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 8 • Atomicità Tutti i membri di un gruppo devono ricevere tutti i request message aloro 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 9 • 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

  10. CORBACommon Object Broker Architecture SD 10:

  11. 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. 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. 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) • 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:

  16. 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:

  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 unservant. • 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: • Synchronous • Deferred Synchronous • 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 • Caricamento dell’interfaccia in un repository • Acquisizione del rifeimento all’oggetto necessario alla richiesta • Creazione di un request object e degli argomenti er la call. • Emissione della call (synchronous, deferred synchronous o one-way). • Acquisizione del risultato (se presente) • 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: • Automaticamente tramite CORBA_ORB_create_operation_list E’ il modo piu’ semplice • Aggiungendo argomenti alla richiesta tramite CORBA_Request_add_arg • Manualmente tramite CORBA_ORB_create_list SD 22:

  46. Dynamic Invocation 5 Costruzione automatica si eseguono i passi seguenti: • 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 inORB_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 perrapresentare 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:

More Related