Lezione 5Lezione 5
Confronto tra Confronto tra Corba, COM e RMI (1)Corba, COM e RMI (1)
Vittorio ScaranoCorso di Sistemi Distribuiti (2003-2004)
Laurea Specialistica in Informatica
Università degli Studi di Salerno
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
2
Obiettivo della lezioneObiettivo della lezione
• Iniziamo lo studio delle 3 principali tecnologie a oggetti distribuiti: CORBA, COM e Java RMI
• La domanda:Quali sono i principi che condividono e quali scelte progettuali sono invece diverse, e perché?
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
3
StrutturaStruttura delladella lezionelezione
• Lo sviluppo con Middleware OO
• Un confronto tra 3 tecnologie
• OMG Corba
• Microsoft COM
• Sun Java RMI
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
4
DefinizioneInterface
Progettazione
GenerazioneServer Stub
GenerazioneClient Stub
CodificaServer
CodificaClient
RegistrazioneServer
I passi per lo sviluppo di una applicazione distribuita I passi per lo sviluppo di una applicazione distribuita con un con un MiddlewareMiddleware OO OO
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
5
1. Progettazione1. Progettazione
• Classica attività basata sui requisiti– del server e dei client dei servizi
• Produce:– diagrammi di classe
• relazioni tra server e client
• struttura statica delle classi (operazioni e attributi)
– diagrammi di sequence• relazioni tra server e client
• Prossimo passo:– definizione delle interface
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
6
2. Definizione 2. Definizione InterfaceInterface
• Interface Definition Language– peculiare per ogni piattaforma MW
• Le interface definite arricchiscono i diagrammi di classe prodotti in precedenza– fornendo informazioni utili per il MW per poter fornire gli
strati di presentazione e sessione
• IDL non sono completi computazionalmente– stabiliscono un “contratto” tra client e server
– in termini di tipi di parametri passati, eccezioni lanciate e tipi dei risultati
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
7
3. Generazione 3. Generazione clientclient e server e server stubstub
• Implementazione del design pattern “proxy”
• Permette di separare progettualmente il client dal server– per ogni progettista, lo stub rappresenta la “controparte”
CalledCalled
StubStubStubStub
CallerCaller
Layer di Layer di trasportotrasporto (TCP o UDP)(TCP o UDP)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
Team.idl
“included in”generalegge
IDL-Compiler
Teamcl.hhTeamcl.cc Teamsv.cc
Teamsv.hh
GenerazioneGenerazione Stub server e clientStub server e client
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
C++ Compiler, Linker
Server
Client.cc Server.cc
C++ Compiler, Linker
Client
Team.idl
“included in”generalegge
IDL-Compiler
Teamcl.hhTeamcl.cc Teamsv.cc
Teamsv.hh
ImplementazioneImplementazione client e serverclient e server
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
10
4. Implementazione 4. Implementazione clientclient
• Definizione di una richiesta statica– realizzata attraverso una invocazione di metodo locale
• Il client dipende dallo stub– se lo stub cambia, allora il client va ricompilato
• in alcuni casi (vedi Java RMI), lo stub può essere caricato dinamicamente
• Le richieste devono essere type-safe– rispettare il “contratto” firmato (cioè la definizione dei tipi di
parametri e di valori restituiti dai metodi)
• Lo stub implementa metodi locali con la stessa firma dei metodi remoti– permette la trasparenza di accesso
• Il MW a volte può rendere più efficiente la esecuzione in locale
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
11
5. Implementazione server 5. Implementazione server
• Necessario che si controlli che lo stub server chiami i metodi del server in modo da preservare la type-safety
• Due sono gli approcci usati, a seconda delle caratteristiche offerte dai linguaggi – la ereditarietà
– il meccanismo delle interface
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
Player_Impl
Player_Server
Player_Dispatch<<uses>>
ImplementazioneImplementazione typetype--safe con la safe con la ereditarietàereditarietà
• Il MW genera una classe astratta – funzioni virtuali pure in C++, deferred methods in Eiffel
• La classe server deve estendere la classe astratta
• Lo stub ha un riferimento che staticamente è alla classe astratta ma che a run-time riferisce ad una istanza del server
Controllato dal compilatore del
linguaggio
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
Player_Impl<<interface>>
Player_Server
Player_Dispatch<<uses>>
<<implements>>
ImplementazioneImplementazione typetype--safe con la interfacesafe con la interface
• In alcuni linguaggi è presente un meccanismo per le interface (come in Java)
• Anche in questo caso il compilatore controlla che il riferimento a run-time sia ad un oggetto istanza di una classe che implementa la interface (definita staticamente)
Controllato dal compilatore del
linguaggio
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
14
6. Registrazione del Server 6. Registrazione del Server
• In generale, gli object adapter devono poter localizzare gli oggetti (o il loro codice) per poterli fare eseguire
• Quindi un server deve essere registrato– in un implementation repository
• Il processo di registrazione è specifico per ogni middleware e per ogni prodotto
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
15
StrutturaStruttura delladella lezionelezione
• Lo sviluppo con Middleware OO
• Un confronto tra 3 tecnologie
• OMG Corba
• Microsoft COM
• Sun Java RMI (nella prossima lezione)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
16
La tecnica di presentazione dei 3 esempiLa tecnica di presentazione dei 3 esempi
• Per ogni esempio di Middleware OO si specifica:– il meta modello che il sistema supporta
– la architettura del sistema
– lo schema di esecuzione di una richiesta
• La necessità del meta modello– Il middleware deve definire un modello che serva come base
comune per le componenti eterogenee
• Per il confronto serve un modello di modelli (meta-modello) che– catturi le componenti comuni dei modelli ad oggetti dei
diversi middleware ad oggetti distribuiti
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
17
I diversi livelli di astrazioneI diversi livelli di astrazione
Meta-ObjectFacility
Meta ObjectModel
ObjectTypes
Objects Livello 0
Livello 1
Livello 2
Livello 3
Oggetti che forniscono servizi su richiesta
Tipi che specificano le caratteristiche comuni a tutti gli oggetti (classi)
Caratteristiche comuni a tutte i tipi di oggetti (modelli a oggetti dei linguaggi di program.)
Necessario per risolvere le differenze tra meta-modelli
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
18
Cosa definisce il meta modello:Cosa definisce il meta modello:
• Oggetti
• Tipi– tipi di oggetto
– tipi non-oggetto
• Richieste
• Eccezioni
• Subtyping e Ereditarietà multipla
• Polimorfismo
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
19
Quali sono le tecnologie che Quali sono le tecnologie che presentiamo…presentiamo…
OMG CORBA Microsoft
COM
SunJava RMI
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
20
StrutturaStruttura delladella lezionelezione
• Lo sviluppo con Middleware OO
• Un confronto tra 3 tecnologie
• OMG Corba• Microsoft COM
• Sun Java RMI (nella prossima lezione)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
Cosa è la Cosa è la ObjectObject Management Management GroupGroup
• Organizzazione non-profit basata negli Stati Uniti– rappresentanti ufficiali in UK, Germania, Giappone, India,
Australia
• Fondata nel 1989• Più di 800 membri• Obiettivo
– sviluppo di interfacce e protocolli che consentano lo sviluppo di applicazioni distribuite e multipiattaforma basate su oggetti
• capaci di interoperare tra loro
– creazione e diffusione di popolari standard industriali OO per la integrazione di applicazioni come CORBA e UML
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
22
La “visione” dell’OMGLa “visione” dell’OMG
• L’importanza dei dati, del loro reperimento e della loro elaborazione nelle moderne aziende– rendere i dati aziendali disponibili indipendentemente dalla
loro “posizione” deve essere il fine delle moderne applicazioni
• In questo contesto il singolo elaboratore non può più essere la piattaforma di riferimento...– ... la piattaforma è oggi la rete
• Occorre sviluppare tecnologie che permettano lo sviluppo di applicazioni distribuite capaci di sfruttare questa nuova piattaforma– e promuoverne la diffusione
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
23
La “visione” dell’OMGLa “visione” dell’OMG
• Problema:– La complessità del software continua a crescere...– … e di conseguenza i costi di sviluppo
• La distribuzione delle applicazioni aggrava ancora di più il problema
• Scopo dell’OMG è ridurre lo sforzo necessario a sviluppare applicazioni distribuite
• Proposta di una architettura di riferimento– multipiattaforma, capace di favorire il riuso di componenti e
l’interoperabilità tra applicazioni– con il consenso dei produttori di software– open standard
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
Application Objects
CORBAfacilities
CORBAservices
DomainInterfaces
Object Request Broker
Object Management ArchitectureObject Management Architecture
operazioni per creare/accedere oggettidistribuiti, gestire lasicurezza, gestire transazioni che coinvolganodiversi oggetti, ecc.
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
25
CORBA CORBA servicesservices (1)(1)
• Naming service– Fornisce la possibilità di avere il riferimento ad un oggetto
noto il suo nome simbolico…
– ... all’interno di un “contesto”
– può essere implementato in maniera distribuita
• Event service:– servizio di comunicazione asincrono e multicast
• Un componente può inviare “eventi” su un canale
• Tutti i componenti in ascolto su tale canale ricevono gli eventiinviati
• I canali possono essere collegati tra loro
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
26
CORBA CORBA servicesservices (2)(2)
• Life cycle service– metodi per copiare, muovere e cancellare insiemi di oggetti
collegati in un grafo di dipendenza
• Relationship service– metodi per “navigare” all’interno di un grafo di oggetti
• Persistent object service– permette di salvare lo stato di componenti per recuperarlo in
futuro
• Transaction service– un supporto all’implementazione di sistemi transazionali...– ... in cui ogni transazione coinvolga più componenti
distribuiti
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
27
CORBA CORBA servicesservices (3)(3)
• Concurrency control service– Fornisce metodi per coordinare l’accesso a risorse condivise
da parte di componenti diversi
• Externalization service– Permette il marshalling e l’unmarshalling dello stato dei
componenti CORBA
• Query service– Permette l’invocazione di “query” su insiemi di oggetti
distribuiti• una query è un predicato (espresso in forma dichiarativa) sul
valore degli attributi degli oggetti coinvolti
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
28
CORBA CORBA servicesservices (4)(4)
• Security service– servizi di identificazione, autenticazione, controllo di
accesso, auditing e sicurezza nella comunicazione
• Collection service– servizi per gestire insiemi di componenti distribuiti
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
29
Common Common FacilitiesFacilities
• Sono un insieme di componenti che forniscono funzionalità applicative di utilizzo comune
• Includono componenti per gestire:– Stampa
– Accesso a DB
– Accesso a servizi di e-mail
– Help distribuito
– supporto per caratteri estesi (asiatici, etc.)
• L’OMA descrive solo le interfacce di questi componenti
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
OMG Interface Definition LanguageOMG Interface Definition Language
• Linguaggio per esprimere i concetti del modello a oggetti di CORBA
• OMG/IDL è– indipendente dal linguaggio di programmazione
– orientato verso il C++
– non computazionalmente completo
• Sono disponibili diversi “mapping” verso linguaggi di programmazione:– C, C++, Smalltalk, ADA, JAVA, OO-Cobol (!)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
31
L’esempioL’esempio di di riferimentoriferimento
Team
-name:string
+bookGoalies()
coaches 1..*
1..*Player
-name:string-Number:int
+book()
+transfer(p:Player)
Club
-noOfMembers:int-location:Address
Trainer
-name:string
Organization
#name:string
works for
1 1..*uses
plays in
1 11..16
has1
*
+train()
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
32
Il meta modello per CORBAIl meta modello per CORBA
• Oggetti
• Tipi
• Attributi
• Operazioni
• Richieste
• Eccezioni
• Subtyping
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
33
CORBA: gli oggettiCORBA: gli oggetti
• Oggetti con un unico identificatore– che risulta opaco ai client
• ad esempio, il nome dell’host non risulta visibile, anche se presente
• Il broker ha il compito di gestire le richieste agli oggetti– in particolare, offre il servizio di persistenza
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
34
CORBA : i tipiCORBA : i tipi
typedef struct _Address {string street;string postcode;string city;
} Address;typedef sequence<Address> AddressList;interface Team { ... };
Tipi atomici
Tipooggetto
Tipi costruiti
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
35
CORBA: i CORBA: i modulimoduli per per limitarelimitare la la visibilitàvisibilità
module Soccer {typedef struct _Address {string street;string postcode;string city;} Address;};module People {typedef struct _Address {string flat_number;string street;string postcode;string city;string country;} Address;};
ModuliSoccer::Address
People::Address
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
36
CORBA: i tipi atomiciCORBA: i tipi atomici
• short : 16 bit, complemento a 2• long : 32 bit, complemento a 2• long long : 64 bit, complemento a 2• unsigned short : 16 bit• unsigned long : 32 bit• unsigned long long : 64 bit• float : 32 bit IEEE single precision• double : 64 bit IEEE double precision• long double : IEEE extended double precision (mantissa ≥ 64 bit,
esponente ≥ 15 bit) • char : ISO Latin-1• octet : 8 bit, non soggetti ad alcuna conversione durante il trasferimento
da client a server• string : array di caratteri di lunghezza variabile• boolean : TRUE o FALSE• enum• any
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
37
L’esempioL’esempio di di riferimentoriferimento
Team
-name:string
+bookGoalies()
coaches 1..*
1..*Player
-name:string-Number:int
+book()
+transfer(p:Player)
Club
-noOfMembers:int-location:Address
Trainer
-name:string
Organization
#name:string
works for
1 1..*uses
plays in
1 11..16
has1
*
+train()
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
38
CORBA: CORBA: AttributiAttributi
interface Player;typedef sequence<Player> PlayerList;interface Trainer;typedef sequence<Trainer> TrainerList;interface Team {
readonly attribute string name;attribute TrainerList coached_by;attribute Club belongs_to;attribute PlayerList players;...};
tipo dell’attributonome dell’attributo
modificabile
non modificabile
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
39
CORBA: CORBA: OperazioniOperazioni
interface Team {...void bookGoalies(in Date d);string print();};
Lista parametri
Tipo del parametro
Nome parametroIl nome delle operazioniusato nelle richieste
Tipi restituiti
• [oneway]<op_type_spec> <identifier> (p1, p2, .., pL) [raises(ex1,ex2,..exN)] [context(name1, name2…, name M)]– oneway: best-effort (altrimenti la semantica è exactly-once o at-most-once se c’è
una eccezione)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
40
CORBA: RichiesteCORBA: Richieste
• Le richieste sono definite dagli oggetti client:
• Consistono di– riferimento all’oggetto server
– nome della operazione
– parametri
– informazioni di contesto
• La richiesta viene eseguita in modalità sincrona
• Le richieste possono essere definite – staticamente (compilation-time)
– dinamicamente (run-time)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
41
CORBA: CORBA: EccezioniEccezioni
• Tipo di eccezioni– generiche (rete non funzionante, riferimento non valido, out-
of-memory, etc.)
– specifiche di applicazione
exception PlayerBooked{sequence<Date> free;};interface Team {...void bookGoalies(in Date d) raises(PlayerBooked);
};
Dati della eccezione
Le operazioni dichiaranoquali eccezioni possono lanciare
Nome eccezione
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
42
L’esempioL’esempio di di riferimentoriferimento
Team
-name:string
+bookGoalies()
coaches 1..*
1..*Player
-name:string-Number:int
+book()
+transfer(p:Player)
Club
-noOfMembers:int-location:Address
Trainer
-name:string
Organization
#name:string
works for
1 1..*uses
plays in
1 11..16
has1
*
+train()
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
43
CORBA: CORBA: EreditarietàEreditarietà
interface Organization {readonly attribute string name;
};interface Club : Organization {
exception NotInClub{ };readonly attribute short noOfMembers;readonly attribute Address location;attribute TeamList teams;attribute TrainerList trainers;void transfer(in Player p) raises NotInClub;
};
Ereditata da Club
Supertipo
Supertipo implicito: Object
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
Interfaccia standardUna interfaccia per ogni operazione
Interfaccia dipendente dall’ ORBUna interfaccia per ogni object adapter
DynamicInvocation
ClientStubs
ORBInterface
ImplementationSkeletons
Client Object Implementation
ORB Core
ObjectAdapter
La La architetturaarchitettura di CORBA di CORBA
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
45
Una altra visione della architetturaUna altra visione della architettura
Protolli per interoperabilità
tra ORB
DynamicInvocationInterface
DynamicSkeletonInterface
Basic OA (BOA)
Portable OA (POA)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
46
La La interoperabilitàinteroperabilità tra ORB in CORBAtra ORB in CORBA
CORBAIDL
General Inter-ORB Protocol(GIOP)
Internet Inter-ORBProtocol
(IIOP)
TCP/IP
Altri protocolli
comeOSI
IPX/SPX
Trasporto
Sintassi dei messaggi tra ORB e
trasferimento dati
Semanticadelle richieste
agli oggetti
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
47
StrutturaStruttura delladella lezionelezione
• Lo sviluppo con Middleware OO
• Un confronto tra 3 tecnologie
• OMG Corba
• Microsoft COM
• Sun Java RMI (nella prossima lezione)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
48
COMCOM
• Tecnologia presentata da Microsoft nel 1993 – estesa successivamente per trattare oggetti distribuiti
– il “motivo” per la querelle con Sun e la introduzione di J++
• Meccanismo di comunicazione basato su RPC
• Principi guida:– Incapsulamento binario (Binary encapsulation)
• modifiche al server non devono richiedere la modifica dei client
– Compatibilità binaria• indipendenza dall’ambiente/linguaggio in cui è stato creato
l’oggetto
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
49
Il meta modello per COMIl meta modello per COM
• Interfacce
• Implementazione e oggetti
• Classi
• Attributi
• Operazioni
• Richieste
• HRESULTS
• Ereditarietà Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
Microsoft IDL (MIDL)Microsoft IDL (MIDL)
• Linguaggio per esprimere i concetti COM
• MIDL è– indipendente dal linguaggio di programmazione
– evoluto dall’IDL di OSF/RPC
– non completo computazionalmente
• Diversi mapping su linguaggi disponibili
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
51
COM: COM: InterfacceInterfacce, implementazioni, classi, implementazioni, classi
• Una interfaccia COM definisce la maniera in cui un client comunica con un server (protocollo)
• I nomi delle interfacce iniziano per convenzione con I
• Ogni interfaccia ha un UUID di 128 bit– generati da una utility COM
• che si basa su data, orario, ID della scheda di rete (indirizzo Ethernet) e un contatore interno aggiornato molto frequentemente
• In pratica, una interface DCOM è una tabella di funzioni virtuali (metodi della interfaccia) con puntatori a funzioni “nello stesso spazio di indirizzamento del processo” (?)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
52
InterfacceInterfacce COMCOM
[object, uuid(1CF2B120-547D-101B-8E65-08002B2BD118)]
interface IOrganization : IUnknown {...
};[object, uuid(1CF2B120-547D-101B-8E65-08002B2BD116)]
interface IClub : IOrganization {...
};
UUID
Interfacce
Ereditarietà di interfaccia
Interfaccia root
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
53
COM: Interfacce, COM: Interfacce, implementazioniimplementazioni, classi, classi
• Una implementazione COM è una classe che implementa un interfaccia
• Disponibili vari linguaggi (C++, Visual Basic, J++, etc.)
• Le istanze di una implementazione di una interfaccia sono dette Oggetti COM
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
54
ImplementazioneImplementazione COM in C++COM in C++
#include "Soccer.h"class Player : public IPlayer {private:char* name; short Number; protected:virtual ˜TrainerPlayer(void);public:TrainerPlayer(void);IMPLEMENT_UNKNOWN(TrainerPlayer)BEGIN_INTERFACE_TABLE(TrainerPlayer)IMPLEMENTS_INTERFACE(ITrainer)IMPLEMENTS_INTERFACE(IPlayer)END_INTERFACE_TABLE(TrainerPlayer)void book(); // IPlayer methods
};
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
55
COM: Interfacce, implementazioni, COM: Interfacce, implementazioni, classiclassi
• Implementazioni di interfacce con un nome– possono avere più interfacce
• Sono identificate dal Class ID (CLSID)– generato in maniera unica come UUID
• Sono il meccanismo principale per creare oggetti COM
• Restituiscono puntatori per specifici oggetti COM
• Le classi vengono istanziate in class objects– uno per ogni host
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
56
COM: OggettiCOM: Oggetti
• Sono istanze di implementazioni COM
• I riferimenti a oggetti COM sono chiamati puntatori di interfaccia– che sono puntatori in memoria principale
• I puntatori di interfaccia supportano la trasparenza alla locazione – vedremo come, in seguito
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
57
implements
1..*
1..*
Interface
uuid : GUID
implements
instantiates 0..*
1
Implementation
1..*
instantiates
11
Class
clsid : GUID
1..*
0..*
Object
location : int
0..*
1
creates&locates
ClassObject
11
0..*
Le Le relazionirelazioni tratra OggettiOggetti, , ClassiClassi, , ImplementazioniImplementazionie e interfacceinterfacce
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
58
COM: AttributiCOM: Attributi
• COM supporta gli attributi– come operazioni di accesso (get e set) definite dal progettista
• Esempio:
interface IOrganization : IUnknown {[propget] HRESULT Name([out] BSTR val);
};
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
59
COM: COM: OperazioniOperazioni
interface IClub : IOrganization {[propget] HRESULT NoOfMembers([out] short *val);[propget] HRESULT Address([out] ADDRESS *val);[propget] HRESULT Teams([in] long cMax, [out] long *pcAct,
[out,size_is(cMax),length_is(*pcAct)] ITeam *val);[propput] HRESULT Teams([in] long cElems,
[in,size_is(cElems)] ITeam *val);[propget] HRESULT Trainers([out] ITrainer *val[3]);[propput] HRESULT Trainers([in] ITrainer *val[3]);
HRESULT transfer([in] IPlayer *p);};
Lista parametriTipo del parametro
Valore di ritorno che indicasuccesso/fallimento operazone
Parametro: puntatore a una interfaccia
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
60
31 30-29 28-16 15-0
COM: HRESULTSCOM: HRESULTS
• Sono interi a 32 bit
• Strutturati in 4 campi
• Esistono costanti predefinite che si possono usareSeverity
Code ReservedFacilityCode
InformationCode
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
61
COM: Invocazione delle operazioniCOM: Invocazione delle operazioni
• La chiamata è definita dagli oggetti client
• Per ogni invocazione si deve determinare:– interface pointer dell’oggetto server
– nome della operazione
– parametri attuali
• L’invocazione può essere – statica
– dinamica
• Il Client riconosce l’esito da HRESULTS
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
62
InvocazioneInvocazione delladella operazioneoperazione
Client
Server
Object
COMLibrary
….….C:\SERVER1.EXECLSID_Y
Elvis.acme.comCLSID_X
Windows Registry
….….C:\SERVER2.EXECLSID_X
Windows Registry
1. Client chiamaCoCreateInstance(CLSID_X, IID_A)
2. Il Registry Windows identifica l’oggetto suun’altra macchina
3. COM localizza la macchina remota e crea l’oggetto
4. Viene restituito ilpuntatore a interfaccia(locale)
5. Il client può ora invocare la operazione
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
63
I I tretre tipi di tipi di operazionioperazioni COM (1)COM (1)
local RPC
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
64
I I tretre tipi di tipi di operazionioperazioni COM (2)COM (2)
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
65
Altre componenti della architettura COMAltre componenti della architettura COM
• Service Control Manager (SCM)– localizzazione ed attivazione di un oggetto
– in collaborazione SCM locale con SCM remoto
– utilizza il CLSID presente nel registry
• Object Remote Procedure Call (ORPC)– protocollo orientato a oggetti specificamente usato da COM
• OXID Resolver– mantiene connessioni tra client/server (uno per host)
– COm registra tutte le interfacce esportate su OXID resolver
– controlla (ping) le interfacce utilizzate e fa garbagecollection di riferimenti alle interfacce che non rispondono
Sist
emi D
istr
ibui
ti (
2003
-200
4).
Vi.t
tori
oSc
aran
o
ArchitetturaArchitettura di COM di COM
ObjectProxy
COMLibraryInterface
proxy
Client
Objectstub
COMLibraryInterface
stub
SCM
Registry
SCM
Registry
OXIDResolver
OXIDResolver
Microsoft RPCsOXIDObject
ApplicationLayer
PresentationLayer
SessionLayer
Server
Implementation
COM Class