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. 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. 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. 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. 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. 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. Object Broker e CORBA
• CORBA significa:
– Common
– Object
– Request
– Broker
– Architecture
• Cosa c’è dietro a questo nome?
8
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. 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. Definiamo CORBA
• Le specifiche CORBA fissano quindi i
requisiti per realizzare un ORB (Object
Request Broker) che rispetti una
architettura comune
11
12. Importanza dell’architettura
comune
• 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. 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. 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. 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. 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. 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
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. 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. 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. Le risposte di CORBA
• Ciascuno dei problemi enunciati trova
risposta in una delle branche della
architettura CORBA
22
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 persistence
Copyright Springer Verlag Berlin Heidelberg 2004 CORBAservices
23
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. Servizi multi-linguaggio in
CORBA
• 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. 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. 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. 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. 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. 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. Traduzione da IDL a Java
interface Purchasing {
IDL
float getQuote ( in long productId);
float purchaseGoods (in long productId, in long quantity);
};
Java
public interface PurchasingOperations
{
float getQuote (int productId);
float purchaseGoods (int productId, int quantity);
}
31
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. 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
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Esempio: la costruzione di un
oggetto 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. Esempio: la costruzione di un
oggetto 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. Esempio: la costruzione di un
oggetto 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. Esempio: la costruzione di un
oggetto 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. Esempio: la costruzione di un
oggetto 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. Esempio: la costruzione di un questo indica che
è un servente
oggetto CORBA in Java (6) CORBA basato su
POA
public 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. Esempio: la costruzione di un
oggetto CORBA in Java (7) l’ORB
inizializza
public 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. Esempio: la costruzione di un
oggetto 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. Esempio: la costruzione di un
oggetto 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. Esempio: la costruzione di un
oggetto CORBA in Java (10)
$ java hello.HelloImpl
HelloServer ready and waiting ...
IOR:000000000000001449444c3a68656c6c6f2f48656c6c6f3a312e30000000000
1000000000000006c000102000000000d31302e3130322e33372e383400000ae400
000021afabcb0000000020d55d3a6b0000000100000000000000000000000400000
0000a00000000000001000000010000002000000000000100010000000205010001
00010020000101090000000100010100
56
57. Esempio: invocazione di un
oggetto 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. Esempio: invocazione di un
oggetto CORBA in Java (2) l’ORB
inizializza
public 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 Hello
orb.string_to_object(args[0]);
hello = HelloHelper.narrow(objRef);
System.out.println("Ho ottenuto il riferimento
all'oggetto CORBA: " + hello);
System.out.println(hello.sayHello(args[1]));
}
invoca l’oggetto
CORBA remoto
58
59. Esempio: invocazione di un
oggetto CORBA in Java (3)
$ java hello.HelloClient
IOR:000000000000001449444c3a68656c6c6f2f48656c6c6f3a312e30000000000
1000000000000006c000102000000000d31302e3130322e33372e383400000ae400
000021afabcb0000000020d55d3a6b0000000100000000000000000000000400000
0000a00000000000001000000010000002000000000000100010000000205010001
00010020000101090000000100010100 Francesco
Hello, Francesco
$ java hello.HelloImpl
HelloServer ready and waiting ...
IOR:000000000000001449444c3a68656c6c6f2f48656c6c6f3a312e30000000000
1000000000000006c000102000000000d31302e3130322e33372e383400000ae400
000021afabcb0000000020d55d3a6b0000000100000000000000000000000400000
0000a00000000000001000000010000002000000000000100010000000205010001
00010020000101090000000100010100
Saying Hello to Francesco
59
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
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. 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
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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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. 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. 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. 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
