Architettura CORBA  Francesco Meschia                      1
Programma•   Da RPC agli Object Broker•   Le specifiche CORBA•   L’Interface Definition Language•   Il modello a oggetti d...
Da RPC agli Object Broker• Il paradigma RPC (Remote Procedure  Call) è evidentemente legato al mondo  della programmazione...
Gli Object Broker• La realizzazione di un sistema ad  architettura distribuita richiede in ultima  analisi un meccanismo p...
Gli Object Broker• Il perseguimento di un modello a oggetti  non termina però con l’invocazione di  metodi remoti• Un “ogg...
Gli Object Broker• Un middleware per oggetti distribuiti  deve rendere possibile il mantenimento  completo della metafora ...
Gli Object Broker• Un Object Broker deve:  – onorare il suo carattere “object” rendendo    fruibili in un modello distribu...
Object Broker e CORBA• CORBA significa:  –   Common  –   Object  –   Request  –   Broker  –   Architecture• Cosa c’è dietr...
Definiamo CORBA• CORBA è una ARCHITETTURA e non  un prodotto  – CORBA è emanazione del consorzio OMG    (Object Management...
Definiamo CORBA• E’ una architettura COMUNE, perché  condivisa dai partecipanti al consorzio  che la promuove  – sono rapp...
Definiamo CORBA• Le specifiche CORBA fissano quindi i  requisiti per realizzare un ORB (Object  Request Broker) che rispet...
Importanza dell’architetturacomune• Mentre il consorzio definisce e revisiona  le specifiche CORBA, i produttori di  middl...
La visione CORBA/OMG• L’interoperabilità è fondamentale per il  perseguimento della “visione” del consorzio  OMG  – una vi...
Non ogni ORB è CORBA• La partecipazione al consorzio OMG è  su base volontaria• Nulla vieta (fuori dal consorzio) la  real...
L’evoluzione di CORBA• La versione 1.0 delle specifihe è del  1991  – comprendeva già le idee di base e le    specifiche p...
L’evoluzione di CORBA• La versione 2.0 giunge nel 1996  – viene introdotto lo schema di interoperabilità inter-    ORB• La...
L’evoluzione di CORBA• 2002: CORBA 3.0  – CORBA 3 segna il passaggio da una    visione di “oggetti distribuiti” ad una vis...
Oggetti CORBA, usodell’ORB, uso del POA                  18
Definiamo il problema• Supponiamo che qualcuno decida di  realizzare un oggetto di utilità comune,  decida di installarlo ...
Definiamo il problema• L’oggetto di servizio, una volta  concepito, realizzato e dispiegato, è  ancora sostanzialmente inu...
Definiamo il problema• Ciascuna di queste domande  rappresenta uno dei servizi cruciali di  una architettura distribuita  ...
Le risposte di CORBA• Ciascuno dei problemi enunciati trova  risposta in una delle branche della  architettura CORBA      ...
Le risposte di CORBA                                                                                                    CO...
Le parti di CORBA• Dalla figura precedente si vede che una  architettura CORBA è composta:  – dall’Object Request Broker (...
Servizi multi-linguaggio inCORBA• Una delle fondamenta di CORBA è la  possibilità di realizzare serventi e clienti  in qua...
Il CORBA IDL• Nel modello object-oriented il comportamento  “ai morsetti” di un oggetto è rappresentabile  con una “interf...
Il CORBA IDL• Se si vuole mantenere l’astrazione rispetto ai  linguaggi di programmazione occorre definire  una grammatica...
Il CORBA IDL• “IDL” è un termine generico che si  applica anche ad altre architetture ORB• “CORBA IDL” indica invece la  g...
Relazioni tra IDL e i linguaggi• OMG definisce anche formalmente  come i costrutti IDL devono essere  tradotti nei diversi...
Relazioni tra IDL e i linguaggi• La traduzione è solitamente affidata ad  uno strumento software, detto  “compilatore IDL”...
Traduzione da IDL a Javainterface Purchasing {                                                                IDL         ...
Traduzione da IDL a Java• In realtà quello che abbiamo visto è solo  l’output della interfaccia Java• Il compilatore IDL p...
Il ruolo dei binding IDL• Gli artefatti prodotti dal compilatore IDL  (binding di IDL nel linguaggio target)  servono da “...
Stub e Skeleton             application object             application object         application object                  ...
Binding statico e dinamico• Oltre all’invocazione statica esiste la  possibilità di costruire dinamicamente le  invocazion...
Il ruolo dell’ORB• Sia che si usino stub e skeleton statici,  sia che si preferiscano dinamici, il loro  compito è quello ...
Il ruolo dell’ORB• I compiti principali dell’ORB sono  pertanto:  – l’instradamento dall’ambiente cliente a    quello serv...
Il ruolo dell’ORB: lato cliente• Dal punto di vista cliente, un oggetto  CORBA è semplicemente una entità  che offre le op...
Il ruolo dell’ORB: lato cliente• Sul lato cliente, l’ORB fornisce anche i  punti di accesso per i servizi di  esplorazione...
Il ruolo dell’ORB: lato servente• Sul lato servente l’ORB funge da  resource manager, occupandosi di:  – gestione del cicl...
Lato servente: il POA• Sul lato servente, l’ORB mette a  disposizione i propri servizi (attivazione,  disattivazione, invo...
Il Portable Object Adapter• Il POA è il componente dell’ORB lato  server che ha il compito di ottimizzare la  scalabilità ...
Il Portable Object Adapter• La politica di base per l’amministrazione delle  risorse consiste nell’attivare i serventi qua...
Il Portable Object Adapter• Il POA richiede “prescrizioni” da parte di  chi sviluppa il servizio per capire come  riconosc...
Il Portable Object Adapter• Le specifiche del POA prevedono sette tipi di  policy, che rappresentano prescrizioni su temi ...
Il Portable Object Adapter• Per quale motivo sono necessarie le policy?  – solo chi ha ideato il servizio può intuire qual...
Esempio: la costruzione di unoggetto CORBA in Java• Prendiamo un frammento IDL che  descrive una interfaccia di servizio d...
Esempio: la costruzione di unoggetto CORBA in Java (2)• Invochiamo il compilatore IDL-to-Java  per produrre gli artefatti ...
Esempio: la costruzione di unoggetto CORBA in Java (3)• Il compilatore IDL produce i seguenti artefatti  Java lato server:...
Esempio: la costruzione di unoggetto CORBA in Java (4)org.omg.Portable Server.Servant    org.omg.CORBA.port    HelloOperat...
Esempio: la costruzione di unoggetto CORBA in Java (5)• L’implementazione concreta del  servente deve essere fornita dal  ...
Esempio: la costruzione di un                     questo indica che                                                    è u...
Esempio: la costruzione di unoggetto CORBA in Java (7) l’ORB                      inizializzapublic class HelloImpl extend...
Esempio: la costruzione di unoggetto CORBA in Java (8)• Eseguendo il main() della classe  hello.HelloImpl si attiva l’ORB ...
Esempio: la costruzione di unoggetto CORBA in Java (9)• Per permettere ai clienti di utilizzare  l’oggetto CORBA è necessa...
Esempio: la costruzione di unoggetto CORBA in Java (10)$ java hello.HelloImplHelloServer ready and waiting ...IOR:00000000...
Esempio: invocazione di unoggetto CORBA in Java• Usando gli artefatti lato cliente prodotti  dal compilatore IDL si può fa...
Esempio: invocazione di unoggetto CORBA in Java (2) l’ORB                      inizializzapublic class HelloClient {      ...
Esempio: invocazione di unoggetto CORBA in Java (3)$ java hello.HelloClientIOR:000000000000001449444c3a68656c6c6f2f48656c6...
Interoperabilità tra ORB• L’ORB lato cliente e l’ORB lato servente  comunicano con un protocollo inter-ORB  – le specifich...
CORBA servicese CORBA facilities                 61
I CORBA services• Per il perseguimento della visione SOA  del consorzio OMG non è sufficiente  l’implementazione della spe...
La OMA• Il consorzio OMG ha studiato la Object  Management Architecture (OMA) per  categorizzare le “parti in causa” nella...
Sintesi della OMA                    64
I CORBA services• Le specifiche CORBA comprendono la  descrizione di 16 “services” che trattano  argomenti di comune utili...
I CORBA services• I servizi CORBA offrono le funzionalità  necessarie per costruire un modello di oggetti  portabile e ric...
Il Naming Service• Il Naming Service è certamente il più  comunemente usato tra i servizi  CORBA• Il NS mette a disposizio...
Il Naming Service• Il NS è a sua volta un oggetto CORBA• Un NS può essere “inserito” come parte  dell’albero di directory ...
Il Trading Service• E’ funzionalmente simile al naming (permette  di reperire gli object reference a oggetti  CORBA) ma fi...
Il Transaction Service• Il Transaction Service permette il  coordinamento di transazioni distribuite tra  oggetti CORBA  –...
Le CORBA facilities• Ad un livello più alto rispetto ai CORBA  services si collocano le CORBA  facilitites• Sono lo strato...
Le CORBA facilities• Le CORBA facilities si distinguono in facilities  “orizzontali” e facilities “di dominio”   – le prim...
CORBA 3, CCM, J2EE               73
Software a componenti• Il mercato sembra aver individuato il  suo “mattoncino Lego” ideale non nel  livello dell’ “oggetto...
Software a componenti• Gli Enterprise Java Bean (EJB) descritti  nelle specifiche J2EE sono i più  rappresentativi esempi ...
CORBA 3 e il CCM• Le specifiche CORBA v3.0 hanno introdotto il  CORBA Component Model (CCM) che ricalca  molto da vicino i...
CORBA e J2EE• La parentela tra le specifiche EJB e il CCM è  davvero molto evidente  – i componenti CORBA hanno il concett...
CORBA e J2EE• Le specifiche CCM dedicano un capitolo a  definire come un componente CORBA debba  essere “visto” sotto la m...
CORBA e J2EE• Sembra quindi che l’ibridazione di CORBA  con J2EE sia ancora sterile, almeno dal punto  di vista dell’adozi...
Q&A      80
Riferimenti• OMG http://www.omg.org• CORBA http://www.corba.org• Java http://java.sun.com  – JavaIDL, J2EE, RMI/IIOP• IONA...
Upcoming SlideShare
Loading in...5
×

Corba

341

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
341
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Corba

  1. 1. Architettura CORBA Francesco Meschia 1
  2. 2. Programma• Da RPC agli Object Broker• Le specifiche CORBA• L’Interface Definition Language• Il modello a oggetti di CORBA• CORBAservices e CORBAfacilities• Verso il modello a componenti CORBA• CORBA e J2EE 2
  3. 3. Da RPC agli Object Broker• Il paradigma RPC (Remote Procedure Call) è evidentemente legato al mondo della programmazione procedurale• L’affermarsi del paradigma di programmazione a oggetti ha richiesto un cambio di prospettiva anche nel campo delle architetture dei sistemi distribuiti 3
  4. 4. Gli Object Broker• La realizzazione di un sistema ad architettura distribuita richiede in ultima analisi un meccanismo per attivare l’esecuzione di codice su sistemi remoti• In una metafora ad oggetti questo modello evolve “naturalmente” nell’invocazione di metodi su oggetti remoti. 4
  5. 5. Gli Object Broker• Il perseguimento di un modello a oggetti non termina però con l’invocazione di metodi remoti• Un “oggetto” si differenzia da una “procedura” per le sue proprietà di identità, ereditarietà, polimorfismo 5
  6. 6. Gli Object Broker• Un middleware per oggetti distribuiti deve rendere possibile il mantenimento completo della metafora ad oggetti• Questo è precisamente il compito degli Object Broker 6
  7. 7. Gli Object Broker• Un Object Broker deve: – onorare il suo carattere “object” rendendo fruibili in un modello distribuito le caratteristiche degli oggetti: ereditarietà, polimorfirsmo, ecc. – agire da “broker” cioè da agente nelle comunicazioni tra oggetti clienti e oggetti serventi rendendo trasparenti i dettagli di indirizzamento fisico, rete, ecc. 7
  8. 8. Object Broker e CORBA• CORBA significa: – Common – Object – Request – Broker – Architecture• Cosa c’è dietro a questo nome? 8
  9. 9. Definiamo CORBA• CORBA è una ARCHITETTURA e non un prodotto – CORBA è emanazione del consorzio OMG (Object Management Group, gli stessi di UML) che produce specifiche di architettura, non prodotti software 9
  10. 10. Definiamo CORBA• E’ una architettura COMUNE, perché condivisa dai partecipanti al consorzio che la promuove – sono rappresentate sia le grandi compagnie di middleware (IBM, BEA – non Microsoft per sua scelta) sia esponenti delle industrie “verticali” (sanità, trasporti, manufacturing, finanza, ecc.) 10
  11. 11. Definiamo CORBA• Le specifiche CORBA fissano quindi i requisiti per realizzare un ORB (Object Request Broker) che rispetti una architettura comune 11
  12. 12. Importanza dell’architetturacomune• Mentre il consorzio definisce e revisiona le specifiche CORBA, i produttori di middleware le implementano• E’ fondamentale nel modello CORBA l’interoperabilità tra implementazioni – L’object brokerage deve poter funzionare anche in una catena formata da diverse implementazioni 12
  13. 13. La visione CORBA/OMG• L’interoperabilità è fondamentale per il perseguimento della “visione” del consorzio OMG – una visione SOA “estrema”, che promette un mondo di servizi in rete loosely-coupled, in cui il modello dei servizi è condiviso e si fa business offrendo un servizio ai clienti ovunque questi siano e indipendentemente dai differenti ambienti tecnologici• CORBA è quindi “agnostico” rispetto alle implementazioni, ai linguaggi, alle reti 13
  14. 14. Non ogni ORB è CORBA• La partecipazione al consorzio OMG è su base volontaria• Nulla vieta (fuori dal consorzio) la realizzazione di Object Broker non rispondenti alle specifiche CORBA – Così è, per esempio, per Microsoft COM/DCOM 14
  15. 15. L’evoluzione di CORBA• La versione 1.0 delle specifihe è del 1991 – comprendeva già le idee di base e le specifiche per l’implementazione in C – indicava essenzialmente come realizzare un ORB che permettesse ai client di comunicare con gli oggetti serventi 15
  16. 16. L’evoluzione di CORBA• La versione 2.0 giunge nel 1996 – viene introdotto lo schema di interoperabilità inter- ORB• La versione 2.3 è del 1999 – CORBA mette radici sulla piattaforma Java• Nel 2000-2001 arrivano CORBA 2.4, 2.5 e 2.6 – il modello si arricchisce di funzionalità di interoperabilità, sicurezza, fault-tolerance 16
  17. 17. L’evoluzione di CORBA• 2002: CORBA 3.0 – CORBA 3 segna il passaggio da una visione di “oggetti distribuiti” ad una visione di “componenti distribuiti” (CCM) – CORBA 3 dà l’impressione di rincorrere i mondi J2EE e .Net che hanno preso con convinzione la strada del componentware e del software come composizione di servizi 17
  18. 18. Oggetti CORBA, usodell’ORB, uso del POA 18
  19. 19. Definiamo il problema• Supponiamo che qualcuno decida di realizzare un oggetto di utilità comune, decida di installarlo su un host e voglia rendere utilizzabile questo oggetto attraverso la rete 19
  20. 20. Definiamo il problema• L’oggetto di servizio, una volta concepito, realizzato e dispiegato, è ancora sostanzialmente inutile – Come si fa a sapere che c’è? – Come si fa a sapere dov’è? – Come si fa a sapere cosa fa? – Come si fa a usarlo? 20
  21. 21. Definiamo il problema• Ciascuna di queste domande rappresenta uno dei servizi cruciali di una architettura distribuita – il servizio di discovery (che cosa c’è?) – il servizio di location (dov’è?) – il servizio di repository dei metadati (cosa fa) – il servizio di invocazione remota (come lo uso) 21
  22. 22. Le risposte di CORBA• Ciascuno dei problemi enunciati trova risposta in una delle branche della architettura CORBA 22
  23. 23. Le risposte di CORBA CORBA facilities vertical facilities: financials supply chain … horizontal facilities: distributed information systems task user-defined documents management management management objects Object Request Broker naming transactions events lifecycle properties relationships time licensing trader concurrency query security collection externalization startup persistenceCopyright Springer Verlag Berlin Heidelberg 2004 CORBAservices 23
  24. 24. Le parti di CORBA• Dalla figura precedente si vede che una architettura CORBA è composta: – dall’Object Request Broker (ORB) – da un insieme di “servizi” di basso livello (CORBAservices) – da un insieme di “facilities” di alto livello (CORBAfacilities)• Su questo schema si dispiegano i servizi 24
  25. 25. Servizi multi-linguaggio inCORBA• Una delle fondamenta di CORBA è la possibilità di realizzare serventi e clienti in qualunque linguaggio – per fare questo è necessario un livello di astrazione dalle specificità dei singoli linguaggi 25
  26. 26. Il CORBA IDL• Nel modello object-oriented il comportamento “ai morsetti” di un oggetto è rappresentabile con una “interfaccia”• Se conosco l’interfaccia di un oggetto so: – quali sono le operazioni consentite – quali sono i parametri attesi da ciascuna operazione – quali sono i risultati attesi da ogni operazione 26
  27. 27. Il CORBA IDL• Se si vuole mantenere l’astrazione rispetto ai linguaggi di programmazione occorre definire una grammatica per descrivere l’interfaccia abbastanza potente e generica da comprendere come casi particolari i diversi linguaggi concreti• Questa grammatica, in CORBA, è l’Interface Definition Language (IDL) 27
  28. 28. Il CORBA IDL• “IDL” è un termine generico che si applica anche ad altre architetture ORB• “CORBA IDL” indica invece la grammatica definita da OMG per CORBA• Il CORBA IDL non è un linguaggio di programmazione ma solo una grammatica dichiarativa – non descrive “come” ma “cosa” 28
  29. 29. Relazioni tra IDL e i linguaggi• OMG definisce anche formalmente come i costrutti IDL devono essere tradotti nei diversi linguaggi – queste definizioni sono dette IDL binding – esistono ovviamente per i tipici linguaggi ad oggetti (Java, Smalltalk, C++) – ma anche per ambienti procedurali (COBOL, C) 29
  30. 30. Relazioni tra IDL e i linguaggi• La traduzione è solitamente affidata ad uno strumento software, detto “compilatore IDL”• Il compilatore IDL non fa parte della specifica OMG, viene prodotto dai singoli implementatori per consentire un più comodo sviluppo 30
  31. 31. Traduzione da IDL a Javainterface Purchasing { IDL float getQuote ( in long productId); float purchaseGoods (in long productId, in long quantity);}; Javapublic interface PurchasingOperations{ float getQuote (int productId); float purchaseGoods (int productId, int quantity);} 31
  32. 32. Traduzione da IDL a Java• In realtà quello che abbiamo visto è solo l’output della interfaccia Java• Il compilatore IDL produce in realtà tutti i componenti necessari a riprodurre nel linguaggio target la metafora dell’oggetto remoto descritta dall’IDL – questo rende possibile il mantenimento della metafora anche negli ambienti non object-oriented – e permette la rappresentazione di concetti non direttamente mappabili (come per Java i parametri in output) 32
  33. 33. Il ruolo dei binding IDL• Gli artefatti prodotti dal compilatore IDL (binding di IDL nel linguaggio target) servono da “colla” tra l’ambiente di sviluppo (sia esso lato servente o cliente) e l’ORB• Nella cosiddetta “static invocation” si parla di stub lato cliente e di skeleton lato servente 33
  34. 34. Stub e Skeleton application object application object application object (client) (client) (service provider) stub skeleton Dynamic Invocation Interface Object Request Broker interface repositoryCopyright Springer Verlag Berlin Heidelberg 2004 34
  35. 35. Binding statico e dinamico• Oltre all’invocazione statica esiste la possibilità di costruire dinamicamente le invocazioni ad oggetti la cui interfaccia non è nota al momento in cui si compila il codice• Viene usato a questo scopo un deposito di interfacce (Interface Repository)• La DI è più macchinosa, non mantiene la metafora delle operazioni su oggetti nell’ambiente client, ma è molto flessibile 35
  36. 36. Il ruolo dell’ORB• Sia che si usino stub e skeleton statici, sia che si preferiscano dinamici, il loro compito è quello di collegare l’ambiente applicativo all’ORB• Gli ORB si occupano di tutta la parte di comunicazione tra stub e skeleton – che quindi, a basso livello, non parlano direttamente l’uno con l’altro 36
  37. 37. Il ruolo dell’ORB• I compiti principali dell’ORB sono pertanto: – l’instradamento dall’ambiente cliente a quello servente delle richieste di operazioni – l’instradamento dall’ambiente servente a quello cliente delle risposte• L’ORB nasconde a cliente e servente tutti i dettagli di rete e protocollo sottostanti 37
  38. 38. Il ruolo dell’ORB: lato cliente• Dal punto di vista cliente, un oggetto CORBA è semplicemente una entità che offre le operazioni pubblicizzate nell’IDL. L’entità appare come se fosse locale, sempre disponibile dal momento in cui viene creata. 38
  39. 39. Il ruolo dell’ORB: lato cliente• Sul lato cliente, l’ORB fornisce anche i punti di accesso per i servizi di esplorazione dell’IR, agisce a supporto della DI, permette la localizzazione dei serventi, supporta la fault-tolerance 39
  40. 40. Il ruolo dell’ORB: lato servente• Sul lato servente l’ORB funge da resource manager, occupandosi di: – gestione del ciclo di vita (attivazione e disattivazione dei servizi) – gestione di diverse policy di attivazione dei serventi 40
  41. 41. Lato servente: il POA• Sul lato servente, l’ORB mette a disposizione i propri servizi (attivazione, disattivazione, invocazione, ecc.) attraverso uno strato software detto object adapter• Le specifiche CORBA (da v2.2) fissano i requisiti del cosiddetto POA (Portable Object Adapter) 41
  42. 42. Il Portable Object Adapter• Il POA è il componente dell’ORB lato server che ha il compito di ottimizzare la scalabilità gestendo le risorse del sistema – intendiamo come “scalabilità” il modo in cui il sistema risponde all’aumentare delle richieste di servizio 42
  43. 43. Il Portable Object Adapter• La politica di base per l’amministrazione delle risorse consiste nell’attivare i serventi quando ve ne sia necessità, e disattivarli quando la necessità viene meno – “attivazione” e “disattivazione” fanno qui riferimento alle attività, dispendiose in termini di memoria e tempo di CPU, necessarie al reperimento del codice servente, alla creazione del processo o del thread che lo ospita, all’allocazione di memoria, ecc. 43
  44. 44. Il Portable Object Adapter• Il POA richiede “prescrizioni” da parte di chi sviluppa il servizio per capire come riconoscere le condizioni di “necessità” – a seconda del caso d’uso, possono essere convenienti diversi “pattern” di attivazione/disattivazione• Queste prescrizioni sono dette policy 44
  45. 45. Il Portable Object Adapter• Le specifiche del POA prevedono sette tipi di policy, che rappresentano prescrizioni su temi come la gestione della concorrenza, del ciclo di vita degli oggetti, ecc.• Ogni tipo di policy può prevedere diversi comportamenti, il che porta le possibili varianti nell’ordine delle centinaia 45
  46. 46. Il Portable Object Adapter• Per quale motivo sono necessarie le policy? – solo chi ha ideato il servizio può intuire quale sia il suo modello di utilizzo prevalente • un servizio che elabora un gran numero di richieste in breve tempo offre performance migliori se non viene disattivato immediatamente (cedo risorse per avere performance), mentre un servizio di uso limitato può essere disattivato subito – chi ha scritto il servizio sa quale sia il tipo di concorrenza che può sostenere (multithread? multiprocess?) 46
  47. 47. Esempio: la costruzione di unoggetto CORBA in Java• Prendiamo un frammento IDL che descrive una interfaccia di servizio detta “Hello”: module hello { interface Hello { string sayHello(in string name); }; }; 47
  48. 48. Esempio: la costruzione di unoggetto CORBA in Java (2)• Invochiamo il compilatore IDL-to-Java per produrre gli artefatti previsti dal binding IDL nel linguaggio Java idlj –fall hello.idl 48
  49. 49. Esempio: la costruzione di unoggetto CORBA in Java (3)• Il compilatore IDL produce i seguenti artefatti Java lato server: – l’interfaccia hello.Hello che rappresenta lo “object reference” agli oggetti aventi l’interfaccia IDL specificata – l’interfaccia hello.HelloOperations che raccoglie le operazioni prescritte dall’interfaccia IDL – la classe astratta hello.HelloPOA che rappresenta lo skeleton di collegamento con il POA• altri oggetti vengono prodotti lato client – holder, helper, stub 49
  50. 50. Esempio: la costruzione di unoggetto CORBA in Java (4)org.omg.Portable Server.Servant org.omg.CORBA.port HelloOperatio org.omg.CO org.omg.CORBA.port able.InvokeHandler ns RBA.Object able.IDLEntity sayHello() <<abstract>> HelloPOA Hello HelloImpl 50
  51. 51. Esempio: la costruzione di unoggetto CORBA in Java (5)• L’implementazione concreta del servente deve essere fornita dal programmatore. I compiti sono essenzialmente due: – fornire implementazione ai metodi dichiarati nella interfaccia HelloOperations – effettuare nel metodo main() un “bootstrap”, istanziando il servente e collegandolo all’ORB attraverso un POA 51
  52. 52. Esempio: la costruzione di un questo indica che è un serventeoggetto CORBA in Java (6) CORBA basato su POApublic class HelloImpl extends HelloPOA { public String sayHello(String name) { String out = "Hello, "+name; questa è l’implementazione System.out.println("Saying hello to "+name); return out; dell’interfaccia di servizio } ...} 52
  53. 53. Esempio: la costruzione di unoggetto CORBA in Java (7) l’ORB inizializzapublic class HelloImpl extends HelloPOA { ... public static void main(String args[]) { trova il Root POA istanzia il ORB orb = ORB.init(args, null); servente POA rootpoa =POAHelper.narrow(orb.resolve_initial_references("RootPOA"));POA attiva il trasforma lo object rootpoa.the_POAManager().activate(); Manager HelloImpl helloImpl = new HelloImpl(); reference in stringa org.omg.CORBA.Object ref =rootpoa.servant_to_reference(helloImpl); String ior = orb.object_to_string(ref); System.out.println("HelloServer ready and waiting"); System.out.println(ior); orb.run(); attende i clienti...} 53
  54. 54. Esempio: la costruzione di unoggetto CORBA in Java (8)• Eseguendo il main() della classe hello.HelloImpl si attiva l’ORB della Java Virtual Machine (CORBA 2.4 con JDK 1.4.2) e si attiva un servente con una policy POA di default – server “transiente” – vedere documentazione Java se interessati 54
  55. 55. Esempio: la costruzione di unoggetto CORBA in Java (9)• Per permettere ai clienti di utilizzare l’oggetto CORBA è necessario fornire loro un object reference – vi sono vari modi per farlo – un modo semplice è convertire il reference in uno IOR (Interoperable Object Reference) rappresentabile come stringa 55
  56. 56. Esempio: la costruzione di unoggetto CORBA in Java (10)$ java hello.HelloImplHelloServer ready and waiting ...IOR:000000000000001449444c3a68656c6c6f2f48656c6c6f3a312e300000000001000000000000006c000102000000000d31302e3130322e33372e383400000ae400000021afabcb0000000020d55d3a6b00000001000000000000000000000004000000000a0000000000000100000001000000200000000000010001000000020501000100010020000101090000000100010100 56
  57. 57. Esempio: invocazione di unoggetto CORBA in Java• Usando gli artefatti lato cliente prodotti dal compilatore IDL si può facilmente costruire un cliente per l’oggetto CORBA così realizzato ed avviato – l’object reference all’oggetto remoto viene ricostruito a partire dallo IOR ottenuto sul lato server 57
  58. 58. Esempio: invocazione di unoggetto CORBA in Java (2) l’ORB inizializzapublic class HelloClient { prende lo IOR dalla public static void main(String args[]) { di comando e lo linea converte (narrow) ORB orb = ORB.init(args, null); converte in object Hello hello; lo object reference reference org.omg.CORBA.Object objRef = all’interfaccia Helloorb.string_to_object(args[0]); hello = HelloHelper.narrow(objRef); System.out.println("Ho ottenuto il riferimentoalloggetto CORBA: " + hello); System.out.println(hello.sayHello(args[1]));} invoca l’oggetto CORBA remoto 58
  59. 59. Esempio: invocazione di unoggetto CORBA in Java (3)$ java hello.HelloClientIOR:000000000000001449444c3a68656c6c6f2f48656c6c6f3a312e300000000001000000000000006c000102000000000d31302e3130322e33372e383400000ae400000021afabcb0000000020d55d3a6b00000001000000000000000000000004000000000a0000000000000100000001000000200000000000010001000000020501000100010020000101090000000100010100 FrancescoHello, Francesco$ java hello.HelloImplHelloServer ready and waiting ...IOR:000000000000001449444c3a68656c6c6f2f48656c6c6f3a312e300000000001000000000000006c000102000000000d31302e3130322e33372e383400000ae400000021afabcb0000000020d55d3a6b00000001000000000000000000000004000000000a0000000000000100000001000000200000000000010001000000020501000100010020000101090000000100010100Saying Hello to Francesco 59
  60. 60. Interoperabilità tra ORB• L’ORB lato cliente e l’ORB lato servente comunicano con un protocollo inter-ORB – le specifiche di CORBA dettagliano il protocollo in modo tale da avere interoperabilità anche tra implementazioni di fornitori diversi – il protocollo è denominato GIOP (General Inter- Orb Protocol) ed è “agnostico” rispetto alla tecnologia di rete – su reti TCP/IP si usa una “declinazione” IP del protocollo denominata IIOP (Internet Inter-Orb Protocol) 60
  61. 61. CORBA servicese CORBA facilities 61
  62. 62. I CORBA services• Per il perseguimento della visione SOA del consorzio OMG non è sufficiente l’implementazione della specifica “core” CORBA/IIOP• Per rendere fruibile ed appetibile il modello è necessario offrire anche uno spettro di servizi di base 62
  63. 63. La OMA• Il consorzio OMG ha studiato la Object Management Architecture (OMA) per categorizzare le “parti in causa” nella costruzione di una architettura ad oggetti distribuiti – l’architettura è definita come la “colla” che lega insieme le parti di un sistema informativo complesso 63
  64. 64. Sintesi della OMA 64
  65. 65. I CORBA services• Le specifiche CORBA comprendono la descrizione di 16 “services” che trattano argomenti di comune utilità – collections, concurrency, enhanced time, event, externalization, naming, licensing, life cycle, notification, persistent state, property, query, relationship, security, time, trading, transaction. 65
  66. 66. I CORBA services• I servizi CORBA offrono le funzionalità necessarie per costruire un modello di oggetti portabile e ricco di funzionalità – dando accesso a funzioni come la gestione delle transazioni, delle licenze, degli eventi, del naming, della sincronizzazione temporale, ecc. – sono un equivalente funzionale, per il mondo a oggetti, delle librerie di sistema del mondo procedurale 66
  67. 67. Il Naming Service• Il Naming Service è certamente il più comunemente usato tra i servizi CORBA• Il NS mette a disposizione una directory in cui pubblicare gli object reference dei propri servizi• Gli oggetti server “iscrivono” il proprio object reference nell’albero di naming per mezzo di un identificatore (nome) 67
  68. 68. Il Naming Service• Il NS è a sua volta un oggetto CORBA• Un NS può essere “inserito” come parte dell’albero di directory di un altro NS dando vita ad una struttura di naming federata• L’ORB permette di ottenere il reference al “proprio” NS attraverso un meccanismo di bootstrap, detto “initial reference” 68
  69. 69. Il Trading Service• E’ funzionalmente simile al naming (permette di reperire gli object reference a oggetti CORBA) ma filosoficamente diverso• Il NS permette di cercare gli oggetti di cui si conosce l’esistenza e il nome• Il TS permette di “scoprire” di oggetti che “pubblicizzano” la propria esistenza e i servizi offerti – la ricerca si può effettuare non solo per nome ma per tipo e qualità del servizio offerto 69
  70. 70. Il Transaction Service• Il Transaction Service permette il coordinamento di transazioni distribuite tra oggetti CORBA – permette di distribuire unità di lavoro dotate delle proprietà ACID (atomicity, consistency, isolation, durability) tra una rete di oggetti CORBA• In un modello che mira a costruire applicazioni per mix-and-match di servizi precostruiti il Transaction Service è fondamentale 70
  71. 71. Le CORBA facilities• Ad un livello più alto rispetto ai CORBA services si collocano le CORBA facilitites• Sono lo strato logico di collegamento tra i servizi e le applicazioni• Sono lo strato di livello più alto tra quelli standardizzati da OMG – gli application objects, infatti, non possono chiaramente essere standardizzati 71
  72. 72. Le CORBA facilities• Le CORBA facilities si distinguono in facilities “orizzontali” e facilities “di dominio” – le prime sono quelle che possono essere utili in diversi contesti applicativi o industriali • internazionalizzazione, supporto per i dispositivi mobili – le seconde sono pensate per rispondere alle esigenze di specifiche branche dell’industria • assistenza al volo, ricerca bibliografica, trattamento dati biomedici, CAD, contabilità, finanza, sanità, manufacturing, telecomunicazioni, ecc. 72
  73. 73. CORBA 3, CCM, J2EE 73
  74. 74. Software a componenti• Il mercato sembra aver individuato il suo “mattoncino Lego” ideale non nel livello dell’ “oggetto distribuito” ma in un livello immediatamente superiore – questo livello può aggregare più oggetti in un insieme di funzionalità logicamente collegate• Questo è il livello dei componenti 74
  75. 75. Software a componenti• Gli Enterprise Java Bean (EJB) descritti nelle specifiche J2EE sono i più rappresentativi esempi del modello a componenti – sono “contenitori” di oggetti collegati, che seguono un comune ciclo di vita, e possono combinare più interfacce per formare un servizio unico e coerente 75
  76. 76. CORBA 3 e il CCM• Le specifiche CORBA v3.0 hanno introdotto il CORBA Component Model (CCM) che ricalca molto da vicino il modello EJB – nel CCM i componenti incapsulano interamente gli oggetti che li compongono – i componenti espongono un comportamento “ai morsetti” attraverso dei punti di accesso detti “port” • esistono port per permettere l’invocazioni di interfacce degli oggetti interni (“facet”), per ricevere e inviare eventi, per permettere l’accesso agli attributi, ecc. 76
  77. 77. CORBA e J2EE• La parentela tra le specifiche EJB e il CCM è davvero molto evidente – i componenti CORBA hanno il concetto di “home” per la gestione del ciclo di vita delle istanze di componente, analogo alla home interface di J2EE – i componenti CORBA hanno nei documenti Component Implementation Definition Language (CIDL) un equivalente dei deployment descriptor degli EJB 77
  78. 78. CORBA e J2EE• Le specifiche CCM dedicano un capitolo a definire come un componente CORBA debba essere “visto” sotto la metafora EJB, e come un EJB possa essere “visto” come componente CORBA• Attualmente però nessuno degli application server J2EE di punta offre supporto a CORBA 3.0 CCM – specifiche arrivate fuori tempo massimo? 78
  79. 79. CORBA e J2EE• Sembra quindi che l’ibridazione di CORBA con J2EE sia ancora sterile, almeno dal punto di vista dell’adozione di CCM• In realtà gli A/S J2EE sono da tempo “buoni vicini” di CORBA – IBM WebSphere usa l’ORB “ObjectBroker” – BEA WebLogic indica l’uso di CORBA/IIOP come strada per la realizzazione di thin client in Java e in altri ambienti per l’accesso allo strato EJB – altre implementazioni ormai fuori mercato (IONA iPortal AS e Borland AS) sono interamente basate su CORBA ORB (Orbix e Visibroker) 79
  80. 80. Q&A 80
  81. 81. Riferimenti• OMG http://www.omg.org• CORBA http://www.corba.org• Java http://java.sun.com – JavaIDL, J2EE, RMI/IIOP• IONA http://www.iona.com – Orbix• Borland http://www.borland.com – Visibroker 81
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×