vittorio scarano · lezione 5 confronto tra corba, com e rmi (1) vittorio scarano corso di sistemi...

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




• 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




• OMG Corba• Microsoft COM


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


• 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


• 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


• 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


Team

-name:string

+bookGoalies()

coaches 1..*

1..*Player


+book()

+transfer(p:Player)

Club


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


Team

-name:string

+bookGoalies()

coaches 1..*

1..*Player


+book()

+transfer(p:Player)

Club


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




• OMG Corba

• Microsoft COM


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

vittorio scarano · lezione 5 confronto tra corba, com e rmi (1) vittorio scarano corso di sistemi...

Documents