dcom corba - unimi.ithomes.di.unimi.it/piuri/pages/didattica/so/mat/distributed/dcom_corba.… ·...

Architetture degli ambienti di sviluppo distribuiti: DCOM e CORBA

Esame di: Sistemi Operativi

Prof. Vincenzo Piuri Dipartimento di Elettronica e Informazione

Politecnico di Milano Luca Cristelli

Luca Dal Molin 2 dicembre 1999

DCOM CORBA

Architetture degli ambienti di sviluppo distribuiti - DCOM - CORBA

- 2 -

Sommario

Sommario.................................................................................................. 2

Introduzione ............................................................................................. 6

Obiettivi del documento ...................................................................................................6

Reperimento delle informazioni e del materiale ...........................................................6

Metodologia seguita............................................................................................................7

I sistemi di sviluppo distribuiti ............................................................. 8

DCOM – Microsoft.............................................................................. 10 Trovare e attivare gli oggetti ............................................................... 12

Identificazione delle istanze degli oggetti ........................................ 13

Passaggio di parametri e marshalling................................................ 14

Distrubuted Garbage Collection........................................................ 16

Gestione delle versioni di un oggetto............................................... 18

Gestione della sicurezza....................................................................... 19

Sicurezza di accesso......................................................................................................... 21

Sicurezza di esecuzione................................................................................................... 21

Identità dell’oggetto......................................................................................................... 21

Protezione delle comunicazioni.................................................................................... 22

Object RPC............................................................................................. 22

Sistemi operativi supportati................................................................. 23

Windows............................................................................................................................ 23

Apple Macintosh.............................................................................................................. 23

Unix.................................................................................................................................... 23

Mainframe......................................................................................................................... 23

Java ..................................................................................................................................... 24

Integrazione con Iternet ...................................................................... 24

DCOM e Active Directory.................................................................. 27

Il futuro di DCOM ............................................................................... 27


- 3 -

CORBA .............................................................................................. 30

Common Object Request Broker Architecture............................ 30

Object Request Broker......................................................................... 35

Clients....................................................................................................... 36

Implementazioni di oggetti ................................................................. 36

Object References ................................................................................. 37

Interface Definition Language ........................................................... 37

Language Mapping................................................................................ 38

Client Stubs............................................................................................. 38

Dynamic Invocation Interface ........................................................... 39

Implementation Skeleton..................................................................... 40

Dynamic Skeleton Interface................................................................ 41

Object Adapters..................................................................................... 43

Interfaccia dell' ORB ............................................................................ 43

Interface Repository.............................................................................. 43

Implementation Repository ................................................................ 46

Esempi di ORBs.................................................................................... 48

ORB basato su Servers................................................................................................... 48

ORB basato sul Sistema Operativo.............................................................................. 48

ORB basato sulla Libreria .............................................................................................. 48

Struttura di un Client............................................................................ 49

Struttura di un Object Implementation............................................ 51

Struttura di un Object Adapter .......................................................... 52

Esempi di Object Adapters................................................................. 54

Object Adapter di base ................................................................................................... 55

Object Adapter di Libreria............................................................................................. 55

Object-Oriented Database Adapter............................................................................. 55


- 4 -

Integrazione di altri sistemi ad oggetti.............................................. 55

Interoperabilità....................................................................................... 58

I Servizi di CORBA .............................................................................. 59

Componenti di un Object Service................................................................................ 62

Common Facilities ................................................................................ 73

Horizontal Common Facilities........................................................... 75

Vertical Market Facilities ..................................................................... 75

DCOM – CORBA : Confronto delle due tecnologie................... 76

Limiti dell’architettura DCOM...................................................................................... 76

Interoperabilità....................................................................................... 78

Linguaggio di supporto................................................................................................... 78

Piattaforme di supporto ................................................................................................. 79

Comunicazioni tra i sistemi attraverso la rete ............................................................ 79

I Servizi Comuni.............................................................................................................. 79

Affidabilità............................................................................................... 80

Le transazioni................................................................................................................... 80

Messaging.......................................................................................................................... 80

La Sicurezza...................................................................................................................... 81

Il Servizio di Directory ................................................................................................... 81

Tolleranza ai guasti.......................................................................................................... 82

Performance............................................................................................ 82

Scalabilità........................................................................................................................... 82

Maturità del prodotto ........................................................................... 83

Rete di computer e sistema distribuito............................................. 84

Client .................................................................................................................................. 84

Server ................................................................................................................................. 85

Servizi Distribuiti ................................................................................... 86

Rischi per la sicurezza..................................................................................................... 86

Violazione di dati riservati.............................................................................................. 87


- 5 -

Accessi non autorizzati................................................................................................... 87

Rifiuto di un servizio....................................................................................................... 87

Sicurezza nelle applicazioni distribuite ........................................................................ 87

Servizi di sicurezza OSF DCE ........................................................... 89

DCE - Distribuited Computing Environment............................... 89

Directory............................................................................................................................ 91

Servizio di tempo............................................................................................................. 91

Sistema di file distribuito................................................................................................ 91

Sicurezza DCE....................................................................................... 92

Componenti della sicurezza DCE................................................................................ 92

Autenticazione.................................................................................................................. 92

RPC Autenticata............................................................................................................... 93

Autorizzazione ................................................................................................................. 93

Crittografia .............................................................................................. 94

DES (Data Encryption Standard)...................................................... 95

Distribuzione delle chiavi .................................................................... 95

Crittografia con chiave pubblica ( Diffie e Hellman ) .................. 96

Problema di Protezione........................................................................ 96

Bibliografia .............................................................................................. 99

[Whitepapers].................................................................................................................... 99

[Princibali Risorse WWW]...........................................................................................100


- 6 -

Introduzione

Obiettivi del documento Lo scopo dei questo documento e’ descrivere i principali

ambienti di sviluppo distribuiti disponibili - DCOM e CORBA - cercando di evidenziarne le principali caratteristiche e infine confrontando pregi e difetti dei due ambienti.

Reperimento delle informazioni e del materiale Per la documentazione di CORBA la principale fonte di

informazioni e’ stato sicuramente il sito dell’ Object Management Group (http://www.omg.org). Infatti questa organizzazione ha il compito di gestire le specifiche e lo sviluppo dello standard CORBA. Ottima la qualità della documentazione disponibile su questo sito.

Per DCOM, invece, il riferimento piuttosto scontato e’ il sito di Microsoft che offre una discreta quantità di informazione sia nelle pagine dedicate a DCOM (http://www.microsoft.com/dcom) sia nel sito MSDN (Microsoft Developer Network) dedicato alla documentazioni degli strumenti di sviluppo e comunque a tutte le problematiche di sviluppo negli ambienti Microsoft. La qualità della documentazione e’ risultata piuttosto buona anche se densa di riferimenti a temi commerciali sull’uso di questa tecnologia.

Oltre a queste due fonti principali sono stati consultati vari testi - soprattutto sui sistemi operativi - che hanno fornito una visione globale


- 7 -

dello sviluppo di applicazioni distribuite evidenziandone le problematiche teoriche. Molto interessante e’ stata la fase di confronto tra la teoria offerta da questi testi e le effettive implementazioni trovate in CORBA e DCOM.

Metodologia seguita Eseguita una prima fase di raccolta delle informazioni dalle

varie fonti elencate sopra - specificate in dettaglio nella bibliografia - queste sono state suddivise tra “specifiche CORBA”, “specifiche DCOM” e “documenti generici”. Successivamente abbiamo rielaborato queste informazioni cercando di estrarre le caratteristiche salienti dei due ambienti di sviluppo esaminandone le specifiche tecniche e le scelte implementative senza tuttavia addentrarsi eccessivamente nei dettagli delle sintassi dei singoli comandi o protocolli. Infine abbiamo raggruppato in un confronto “side by side” i due sistemi definendo pregi e difetti sia sul lato tecnologico che applicativo.


- 8 -

I sistemi di sviluppo distribuiti

Scopo dei sistemi distribuiti è quello di permettere la costruzione di infrastrutture composte da oggetti in grado di comunicare e usare i servizi mesi a disposizione di altri oggetti. Questa comunicazione deve poter avvenire sia fra oggetti appartenenti allo stesso spazio di indirizzamento, a spazzi di indirizzamento diverso e perfino fra macchine diverse nel modo più trasparente possibile. Senza un meccanismo di comunicazione tra oggetti (un “object-bus”) le applicazioni sarebbero confinate ai singoli desktop.

Gli ambienti di sviluppo distribuiti offrono notevoli vantaggi nel riutilizzo del codice: oggetti già sviluppati e testati possono essere inseriti in altri progetti o subire evoluzioni in modo asincrono rispetto ad una applicazione monolitica. Quindi molti dei vantaggi che hanno portato i linguaggi ad oggetti nello sviluppo di software vengono ulteriormente sfruttati negli ambienti distribuiti:

• Riuso di componenti già sviluppati

• Sviluppo indipendente dei vari oggetti

• Manutenzione del codice più efficiente

• Applicazioni client più leggere: l’esecuzione della logica del programma e distribuita su più nodi e non concentrata sul client o sul server.

Per alcuni, distribuire e interconnettere software basato su componenti standard può essere visto come una soluzione in cerca di un


- 9 -

problema non ancora reale. Al contrario l’industria del software continua ad evolversi verso un modello di sviluppo a “catena di montaggio” dove è indispensabile l’impostazione di standard per permettere ai vari componenti di comunicare anche in ambienti eterogenei sia dal punto di vista delle architetture hardware che del sistema operativo.

Due particolari architetture emergono in questo ambito: CORBA dell’Object Management Group (OMG) e DCOM di Microsoft. Più recentemente altri due acronimi sono apparsi nella letteratura dei sistemi distribuiti: Jini di Sun Microsystems e DNA ancora di Microsoft. Queste piattaforme di sviluppo offrono un’interessante occasione di confronto sia sul piano commerciale, che in questo documento sarà marginalmente accennato, sia tecnico, oggetto specifico della relazione.


- 10 -

DCOM – Microsoft

DCOM è stato sviluppato sulla base di protocollo DCE (Distributed Computing Environment) RPC (Remote Procedure Call) di OSF (Open Software Fundation). DCOM è una versione estesa di “Component Object Model” (COM) sempre di Microsoft che è alla base della tecnologia ActiveX. La principale differenza tra DCOM e COM è che i componenti COM vivono su una singola macchina mentre i componenti DCOM possono essere distribuiti su macchine diverse connesse attraverso una rete. Nonostante la disponibilità di ambienti DCOM anche per piattaforme non Windows le limitazioni esistenti su queste piattaforme ne rendono l’uso di fatto confinato ad ambienti Windows.

Uno dei principali vantaggi di DCOM è la qualità e la varietà di strumenti di sviluppo disponibili per la creazione di componenti COM e DCOM:

• Microsoft Visual C++ per sviluppo il C/C++

• Microsoft Visual Basic per sviluppo RAD

• Imprise Delphi

• PowerBuilder Inoltre è disponibile una vastissima libreria di componenti

ActiveX commercializzati da varie case di software per gli scopi più disparati.


- 11 -

Client

Client

Client

Client

Client

Client

Client

Client

Client

Server Component

Server Component

Server Component

L’architettura di DCOM è fortemente orientata agli oggetti e ogni

applicazione è definita oggetto. All’interno di un ambiente DCOM le applicazioni client comunicano con altri oggetti COM solamente attraverso interfacce. Le interfacce contengono una lista di puntatori ai metodi messi a disposizione dall’oggetto.

In DCOM le interfacce rappresentano il cuore dell’architettura. I

componenti sono solamente l’implementazione delle interfacce. Un componente può essere rimosso e rimpiazzato in modo trasparente con un altro se il nuovo componente supporta la stessa interfaccia. DCOM supporta l’ereditarietà dell’interfaccia il che significa che un’interfaccia può essere derivata da un’altra ma l’interfaccia derivata non può ereditare i componenti della vecchia interfaccia. DCOM permette di riusare componenti esistenti passando il puntatore di un’interfaccia esistente.

Ogni oggetto deve essere registrato sulla macchina locale per permettere al client di trovare l’oggetto attraverso il “Global Unique Identifier” nel registry.


- 12 -

Client

Client

Client

Client

Client

Client

Client

Client

Client

Business RuleComponent



"Bottleneck"Component

DatabaseComponent

Duplicated Servers Dedicated Server

Dedicated Server

Per quanto riguarda la sicurezza DCOM si basa sul modello

implementato in Windows NT. Per gli ambienti non Windows NT DCOM usa i meccanismi disponibili fornendo uno strato software di compatibilità. DCOM permette l’uso di ACL (Access Control Lists) che memorizzano i diritti di accesso di utenti e gruppi all’uso di particolari componenti. Queste liste possono essere configurate attraverso un opportuno software o attraverso funzioni Win32 di sistema all’interno di applicazioni.

Trovare e attivare gli oggetti

Alla base del funzionamento di DCOM ci sono le funzioni per trovare e attivare gli oggetti. Nell’ambiente DCOM le classi sono identificate attraverso un codice GUID (Global Unique IDentifier). Quando i GUID sono utilizzati per specificare particolari classi di oggetti allora sono chiamati Class ID. I Class ID sono dei numeri interi da 128 bit. Attraverso un Class ID il sistema è in grado di trovare il corrispondente codice binario dell’oggetto, crearlo e passare il puntatore all’interfaccia al client. Il meccanismo di creazione degli oggetti è in grado di creare oggetti anche su altre macchine collegate attraverso la rete. Perché questo sia possibile le librerie di DCOM devono conoscere il nome del server e il CLSID. Con queste due informazioni il Service Control Manager (SCM) del client è in grado di collegarsi al SCM del server e richiedere la creazione dell’oggetto.


- 13 -

Client ComponentProxy Object

DCE RPC

Protocol Stack

Stub

DCOM network-protocol

SecurityProvider

DCE RPC

Protocol Stack

SecurityProvider

SCM SCM

OLE32

"CoCreateInstance"

(Remote)Activation

"CoCreateInstance"

Struttura generale di DCOM

Ci sono due modi per specificare il nome del server su cui creare

l’oggetto: attraverso il registry del client o specificandolo esplicitamente nei

parametri delle chiamata di libreria.

Identificazione delle istanze degli oggetti

Spesso le applicazioni client necessitano di collegarsi ad istanze specifiche di un oggetto creato. Infatti, è possibile creare più oggetti appartenenti alla stessa classe e ogni oggetto ha un proprio stato che lo rende diverso dalle altre istanze. DCOM eredita da COM il meccanismo per l’identificazione (naming) delle istanze ovvero i monikers. I monikers rappresentano i nomi delle istanze e nella struttura DCOM sono essi stessi degli oggetti. Questi oggetti contengono il codice necessario per trovare una particolare istanza di un oggetto ed eventualmente ricrearla se non è in esecuzione. Un oggetto ha il compito di crearsi il proprio moniker e passarlo a tutti i client interessati a ricollegarsi all’oggetto in momenti successivi. Il sistema operativo mantiene una tabella di tutte le istanze degli oggetti chiamata ROT (Running Object Table).


- 14 -

Component

Component

Component

Component

Component

Component

Component

ReferralComponent

Client

1. Requests connection 2. Creates connection to "best"component

3. Return connection to client

Uno dei vantaggi dei monikers è la possibilità di identificare le

istanze con nomi facilmente leggibili come URL, percorsi, o altri meccanismi basati su stringhe. I monikers contengono anche informazioni sullo stato persistente dell’oggetto, che può essere memorizzato in molti modi, e distribuito su più server. Questo è un altro modo di DCOM per trovare un oggetto che rende assolutamente trasparente dove l’oggetto è istanziato. Gli oggetti possono indicare ai propri monikers dove essere attivati secondo dove sono registrate le informazioni del loro stato. Eseguire il codice di un oggetto sulla stessa macchina dove risiedono i dati ha il notevole vantaggio di diminuire il traffico di rete necessario al trasferimento delle informazioni, soprattutto nelle applicazioni di gestione di database. Inoltre non è necessario replicare sui singoli client il codice dell’oggetto e quindi si ha un risparmio di spazio e facilitazioni nella manutenzione del sistema.

Passaggio di parametri e marshalling

Quando un client deve comunicare con un oggetto appartenente a un diverso spazio d’indirizzamento i parametri del metodo invocato devono essere in qualche modo tradotti. Normalmente il passaggio di parametri avviene attraverso lo stack del processo ma questo non è possibile per sistemi distribuiti. Il meccanismo per la traduzione dei parametri dallo stack del processo chiamante ad un buffer temporaneo di memoria è chiamato marshalling. Questa traduzione non è assolutamente semplice in quanto i parametri possono essere arbitrariamente complessi (puntatori, strutture, altri oggetti). Per eseguire una traduzione corretta è necessario attraversare tutta la struttura dei parametri rendendoli


- 15 -

trasportabili e utilizzabili nello spazio d’indirizzamento dell’oggetto chiamato. Il processo simmetrico di conversione dei parametri dal buffer temporaneo allo stack di destinazione è chiamato unmarshalling. Una volta ricreato lo stack, il metodo può essere invocato e quindi i risultati subiscono il passaggio inverso per raggiungere lo stack del processo chiamante.

DCOM fornisce un avanzato meccanismo di

marshalling/unmarshalling i parametri dei metodi che è comunque basato su RPC (remote procedure call) definito nello standard DCE. Infatti RPC di DCE definisce un modo di rappresentare i dati per tutti i più importanti tipi. Questa rappresentazione è chiamata NDR (Network Data Representation). Per poter eseguire correttamente le procedure di marshalling, DCOM deve conoscere esattamente la dichiarazione di tutti i metodi con i tipi di dati utilizzati, le strutture e le dimensioni dei vettori nella lista dei parametri. La descrizione di queste informazioni è data dall’ Interface Description Language (IDL): anche questo è parte dello standard RPC – DCE. I file IDL che descrivono le interfacce degli oggetti vengono compilati da uno specifico compilatore :il Microsoft IDL compiler, o MIDL, incluso nel Win32 SDK (Software Development Kit). Il compilatore MIDL genera del codice C che provvede a eseguire le operazioni di marshalling e unmarshalling per l’interfaccia descritta nel file IDL. Il codice generato per il lato client viene chiamato proxy mentre il codice per il lato server è chiamato stub. I Proxy e gli stub generati dal compilatore MIDL sono oggetti COM che vengono caricati dalle librerie COM quando sono necessari. Quando COM necessita di trovare lo stub e il proxy per una particolare interfaccia di un oggetto viene consultato il registry, nella chiave HKEY_CLASSES_ROOT\Interfaces, cercando il valore corrispondente di Interface ID.

Buffer server marshallin unmarshalli

Buffer unmarshalli marshalling

client

Figura 1 - masrshalling dei parametri


- 16 -

[HKEY_CLASSES_ROOT\Interfaces\{<IID_Interface>}\ProxyStubClsid32]

@={<CLSID_ProxyStub>}

[HKEY_CLASSES_ROOT \CLSID\{<CLSID_ProxyStub>}\InprocServer32]

@="c:\proxy-stub.dll"

processo

rpc channel

proxy

stub

stream

thread 1 thread 2

1.Marshal Ifoo Interface 2. Unmarshall IFoo

3. Marshaling process completed, object communicates thrrough stub / proxy

IFoo

Per quanto riguarda i puntatori, COM definisce un nuovo tipo

non presente nello standard RPC DCE : il tipo interface pointer. Le operazioni di marshalling e unmarshalling di questo nuovo tipo di dato comportano la creazione di una coppia stub + proxy in grado di manipolare i metodi dell’interfaccia. Il processo ricevente utilizza il puntatore al proxy mentre il processo chiamante usa lo stub.Un unico meccanismo gestisce tutte le possibilità. La gestione dei puntatori, come altre parti dell’architettura DCOM, può essere estesa o anche sostituita. Infatti COM notifica all’oggetto che sta creando una coppia proxy/stub per una particolare interfaccia. L’oggetto, a questo punto, può decidere se usare le routine standard di marshalling o definirne di nuove.

Distrubuted Garbage Collection

Il meccanismo principale per il controllo della vita di un oggetto è il conteggio dei riferimenti ad esso da parte dei client. Due chiamate della libreria COM modificano il contatore: AddRef () e Release (). Entrambi sono metodi dell’interfaccia IUnknown. Quando un oggetto è richiesto la prima volta viene istanziato e il relativo contatore impostato a 1. Successivi riferimenti allo stesso oggetto aumentano il contatore mentre


- 17 -

rilasci da parte dei client decrementano il contatore. Quando si raggiunge 0 (equivalente a “nessun riferimento attivo”) l’oggetto è deallocato dalla memoria.

Comp DatabaseComponent

DCOMClient

Custom Proxy

Database

Snapshot/ Cache

Per migliorare le prestazioni e diminuire il carico sulla rete,

l’aggiornamento dei contatori viene eseguito dopo un certo numero di invocazioni o dopo un predeterminato periodo di tempo. AddRef () e Release () mantengono una versione locale del contatore mentre altre due funzioni di libreria (RemAddRef e RemRelease) provvedono a gestire la sincronizzazione tra i sistemi remoti. Questa architettura sarebbe adeguata e sufficiente se la rete fosse immune da malfunzionamenti e i client privi di errori. Entrambi le condizioni non sono sempre verificate e quindi DCOM implementa dei meccanismi per mantenere gli oggetti in uno stato coerente e il più robusto possibile. Il problema principale è la possibilità che un client richieda la creazione di un oggetto che poi non viene mai più rilasciato a causa di errori di programmazione o per terminazione anomala del client. Questo porta il server a mantenere in memoria l’oggetto per un tempo indefinito occupano inutilmente risorse. Per ovviare a questa possibilità è stato introdotto un meccanismo di pinging. Il pinging provvede a controllare in modo periodico che il client sia ancora vivo e che necessiti dell’oggetto inviando dei semplici messaggi a intervalli di 2 minuti e con un tempo limite di risposta di 3 minuti.


- 18 -

Client

Client 1

Client 2

Application A - Vendor AComponent 1

Component 3

Component 2

pingping

pingping

Client 1

Client 2

Application B - Vendor B

Component 1

Component 2

ping

ping

Server"ping"

Trascorsi 3 minuti il server considera il client non attivo e

decrementa il contatore. Anche nel pinging protocol ci sono delle ottimizzazioni per diminuire il carico sulla rete: invece di spedire un messaggio per ogni istanza di oggetto, il server crea un unico passaggio per tutti gli oggetti utilizzati dal client.

Gestione delle versioni di un oggetto

Una delle dei vantaggi introdotti da DCOM è la possibilità di sviluppare e far evolvere i vari oggetti in modo asincrono. Durante la vita di un’applicazione distribuita è necessario aggiungere nuove funzioni o modificarne di esistenti. In un ambiente tradizionale sia i client che i server dovrebbero essere aggiornati simultaneamente per mantenere funzionante il sistema altrimenti i componenti sui server devono aspettare fino a che tutti i client subiscano l’aggiornamento. Operazione questa che può essere difficile e costosa se la reste è estesa.

DCOM offre un meccanismo per far evolvere i client e i server. I client possono chiedere in modo dinamico le funzionalità messe a disposizione dagli oggetti. Gli oggetti, invece di esporre un’unica interfaccia composta da metodi e proprietà per tutti i client, possono apparire in modo diverso a diversi client. Un client che usa una particolare funzione necessita di utilizzare solo i metodi e le proprietà per questa funzione. I client possono usare più di una funzionalità di un oggetto contemporaneamente. Se, durante l’evoluzione di un oggetto, sono aggiunte nuove funzionalità, queste non influiscono il funzionamento di quelle preesistenti e soprattutto il funzionamento dei client che non le utilizzano.


- 19 -

ClientVersion 1

ClientVersion 2

ServerVersion 1

ServerVersion 2

Interface 1

Interface 1

Interface 2

ClientVersion 2

ClientVersion 1

Con questa struttura è possibile un nuovo schema di evoluzione.

All’inizio il componente espone un insieme di funzioni che costituisce un nucleo che ogni client può utilizzare in modo affidabile. Poi il componente viene arricchito di nuovi metodi e proprietà e vengono inserite in nuove interfacce lasciando inalterate le precedenti così da garantire il buon funzionamento sia dei client che utilizzano la vecchia interfaccia sia dei nuovi client che possono controllare l’esistenza della nuova interfaccia e quindi riescono a utilizzare le nuove funzioni.

Gestione della sicurezza

L’impiego di modelli di programmazione distribuita comporta molte differenze di gestione della sicurezza rispetto al modello tradizionale client/server. Determinare chi può accedere agli oggetti, che operazioni sono permesse agli oggetti, quale livello di riservatezza devono avere i messaggi che attraversano la rete rappresentano compiti che richiedono una solida struttura della sicurezza direttamente integrata nell’architettura. Inoltre la gestione della sicurezza deve essere configurabile per permettere lo sviluppo di applicazioni distribuite sia in situazioni dove vi sono stringenti necessità di riservatezza sia in situazioni dove questo punto non è prioritario. Inoltre, in ambienti distribuiti, c’è la necessità di dover integrare vari modelli di sicurezza. Infatti piattaforme diverse usano meccanismi di protezione diversi spesso incompatibili. DCOM offre una efficiente struttura di sicurezza che rende uniforme nell’intero ambiente sia le API per l’accesso alla sicurezza sia gli strumenti per la sua gestione.


- 20 -

Validate

Obtain SequenceNumber

Update Database

Return Result

Client Component

La base di un sistema di sicurezza è l’identificazione di un utente.

Normalmente questa identificazione avviene controllando una coppia username/password1 con una entità centrale in grado di verificarla. Se un client richiede l’accesso a una risorsa protetta, deve trasmettere i dati per potersi autenticare che il fornitore della risorsa controlla con l’entità centrale in grado di verificarla.

1 Recentemente si sono sviluppati molti altri sistemi oltre le

password per la verifica dell’identità degli utenti: sistemi biometrici che sono in grado di rilevare caratteristiche fisiche uniche delle persone come impronte digitali e retine oculari. Altri meccanismi di autenticazione prevedono l’uso di carte magnetiche (es: bancomat) o più recentemente ancora carte intelligenti (provviste di una CPU, una memoria permanente e addirittura di un sistema operativo) (es: GSM, pay-tv, …).


- 21 -

Client

User-InterfaceComponent

ValidationComponent


DatabaseComponent

Database

COM

COM

DCOM

ValidationComponent

DCOM

COM

DCOM

Client Middle-tier Back-end

DCOM permette di definire quattro aspetti della sicurezza:

Sicurezza di accesso E’ il requisito minimo di qualsiasi sistema di protezione.

Solamente a utenti che ne hanno diritto è permesso utilizzare una particolare risorsa. Inoltre può essere necessario permettere a utenti non autorizzati di potersi collegare a oggetti protetti ma solamente ad alcune funzioni.

DCOM prevede tutte queste possibilità sia in fase di sviluppo – attraverso apposite API - sia durante l’uso delle applicazioni.

Sicurezza di esecuzione Altro requisito nei sistemi distribuiti è il poter controllare chi è

abilitato alla creazione degli oggetti. Poiché ogni oggetto COM è potenzialmente accessibile via DCOM, è importante prevenire richieste non autorizzate di creazione di certi oggetti. Questa protezione è implementata direttamente in DCOM e non richiede particolari sforzi di programmazione. Quando è richiesta la creazione di un oggetto le librerie COM controllano che il client abbia sufficienti diritti per farlo prima di acconsentire all’operazione. Le informazioni su chi è abilitato alla creazione sono contenute nel registry e non nell’oggetto, questo per aumentare l’affidabilità del meccanismo.

Identità dell’oggetto Un altro aspetto della sicurezza in ambienti distribuiti è il controllo

degli oggetti stessi. Molti oggetti possono compiere operazioni in vece di


- 22 -

altri oggetti; quindi non è sempre evidente l’identità del client. L’approccio più semplice è l’assumere che l’oggetto che richiede un servizio abbia la stessa identità dell’utente chiamante. Di conseguenza qualsiasi operazione venga richiesta dall’oggetto subisce gli stessi vincoli di protezione dell’utente chiamante.

Uno scenario più complesso prevede che un oggetto sia condiviso tra più utenti e che questo richieda dei servizi. Ovviamente non è possibili far assumere all’oggetto l’identità di un utente chiamante e quindi DCOM prevede di poter assegnare all’oggetto un identificativo proprio, come se l’oggetto fosse un utente.

Protezione delle comunicazioni Sempre più importante è la necessità di disporre di canali di

comunicazione protetti. Infatti le linee di comunicazione sono potenzialmente le più esposte a tentativi di forzare il sistema di sicurezza. Sarebbe impossibile – ad esempio – proteggere fisicamente tutti i cavi di comunicazione che collegano i nodi di un sistema distribuito.

Per risolvere questo problema sono necessari meccanismi che impediscano a un utente non autorizzato di interpretare i messaggi che gli oggetti si scambiano e di spedire messaggi falsificando la propria identità.

DCOM offre sia al processo chiamante, sia al processo ricevente una ampia scelta di metodi di protezione delle comunicazioni. Apposite chiamate API permettono di determinare l’origine dei dati e se questi dati hanno subito alterazioni sia casuali che maligne durante il tragitto. Poiché il meccanismo di autenticazione dei client è piuttosto oneroso, DCOM permette di specificare come e quanto spesso controllare l’identità del client.

Come accennato sopra ci sono due caratteristiche principali della sicurezza nella trasmissione dei dati: la loro integrità e la loro riservatezza. I client e gli oggetti possono richiedere che i dati vengano trasmessi con informazioni addizionali che garantiscono l’integrità. Se una parte dei dati ha subito modifiche durante la trasmissione, DCOM lo rileva e automaticamente rifiuta la trasmissione.

La riservatezza, invece, prevede che nessuno possa intercettare e interpretare i dati trasmessi. Per questo gli oggetti e i client possono richiedere la cifratura dei dati prima della loro trasmissione.

Object RPC

Il protocollo usato da DCOM si chiama Object RPC (o ORPC. Consiste in un insieme di definizioni che estendono il protocollo standard DCE RPC. E’ stato progettato specificatamente per un ambiente orientato


- 23 -

agli oggetti quale è DCOM e specifica come devono essere effettuate le chiamate attraverso la rete e come devono essere gestiti i riferimenti agli oggetti. Il protocollo ORPC è stato progettato per la comunicazione sia in ambienti Intranet che Internet. Inoltre è stato proposto a degli organismi di certificazione (IETF).

Al livello più basso, ORPC usa i pacchetti standard come definiti da RPC aggiungendo solo alcune informazioni specifiche per DCOM come un “Interface Pointer Identifier” (IPID), informazioni sulla versione, e alcuni altri dati che consentono estensioni future. L’ IPID è usato per identificare una specifica interfaccia di uno specifico oggetto su un server dove la chiamata deve essere eseguita. I dati, che hanno subito il processo di marshalling, sono memorizzati in un formato standard chiamato “Network Data Representation” (NDR) in modo da superare i problemi di eventuali conversioni necessarie tra piattaforme diverse. DCOM introduce un nuovo tipo di dati NDR per permettere la trasmissione di un’interfaccia.

Normalmente i programmatori non devono preoccuparsi di gestire questo basso livello di comunicazione. Come gia accennato il compilatore MIDL genera automaticamente tutto il codice necessario al corretto trasferimento dei dati tra oggetti. E’ comunque possibile utilizzare altri strumenti al posto di MIDL.

Sistemi operativi supportati

Windows DCOM è nato all’interno della piattaforma Microsoft Windows e

questa rimane per il momento il suo ambiente principale. Attualmente le librerie DCOM sono disponibili per Windows NT 4.0, Windows 95 e Windows 98.

Apple Macintosh Il supporto della piattaforma Apple ha subito molteplici rinvii e

ritardi da parte di Microsoft. Non c’è ancora una release definitiva.

Unix Terze parti stanno sviluppando varie implementazioni di DCOM

per integrare Windows NT con Sun Solaris, AIX di IBM e Linux (Software AG e Digital ora Compaq).

Mainframe Sempre Software AG sta sviluppando DCOM su MVS di IBM.


- 24 -

Java Notevoli sono stati gli sforzi di Microsoft per integrare DCOM

con Java. Il risultato è un aspro scontro tra Sun Microsystems che promuove un suo ambiente distribuito (Jini basato su RMI) e Microsoft che ha definito sue API per la gestione degli oggetti distribuiti basate su DCOM.

Le implementazioni di DCOM su piattaforme diverse da Windows

sono costruite incapsulando funzionalità esistenti della piattaforma in oggetti DCOM. Vari servizi del sistema operativo come la gestione della sicurezza, il file system, la rete sono mascherati da appositi oggetti dell’implementazione DCOM che rendono omogeneo l’uso di questi servizi da parte di tutto l’ambiente distribuito.

Avere a disposizione un ambiente DCOM su molte piattaforme rende più semplice il porting delle applicazioni da un ambiente a un altro.

Da questa breve panoramica appare chiaramente che in questo momento DCOM rappresenta una valida soluzione solo in ambienti omogenei Windows. Le implementazioni su altre piattaforme sono o incomplete o addirittura in fase di progetto.

Integrazione con Iternet

La rete Internet può essere vista come un enorme sistema distribuito dove convivono le molte piattaforme diverse tra loro. Dato il livello di astrazione delle comunicazioni tra oggetti DCOM, è possibile utilizzare i protocolli di Internet per unire sottoreti DCOM e creare quelle che vengono chiamate “Virtual Private Network” (VPN). Questo modello di connessione usa Internet solo come canale di comunicazione a basso costo soprattutto se i punti da collegare sono distanti e molti. Per queste comunicazioni è necessari disporre di una struttura che garantisca un alto livello nella riservatezza delle trasmissioni attraverso la crittazzione dei messaggi. DCOM offre tutte le caratteristiche necessarie in quanto è in grado di usare in modo trasparente i più diversi protocolli e include nelle sue librerie la parte di protezione delle comunicazioni.


- 25 -

LAN

Client

PPTP

RAS Server

Modem

Component

DCOMDCOM

Più nel dettaglio le caratteristiche che rendono DCOM

compatibile con molti protocolli di comunicazione sono:

• La capacità di poter usare qualsiasi porta definita da protocollo TCP/IP e quindi è possibile rispettare i vincoli imposti da eventuali firewall che separano zone diverse della rete.

• E’ possibile costruire degli “Application proxy” che consentono di instradare le comunicazioni attraverso dei nodi della rete che dispongono di funzioni di controllo autenticazione molto robuste.

• La possibilità di instradare i messaggi attraverso il protocollo HTTP.

Con queste caratteristiche è possibile utilizzare le applicazioni DCOM utilizzando Internet come canale di comunicazione economico per unire due uffici della stessa azienda, oppure per unire una sede centrale a molt i uffici periferici o infine per connettere un grande numero di utenti in tutto il mondo.


- 26 -

Internet Information Server

SQL Server

Checking Application Component

Checking ISAPI ext.

Stock ISAPI ext.

... ISAPI ext.

Stock Application Component

... Application Component

Internet Explorer

ActiveX Controls

ActiveX Scripts

Client Server Window 98 / Windows NT Workstation

Windows NT Server

HTML static files

HTTP

COM

Inoltre è possibile integrare documenti HTML con oggetti

DCOM. Infatti è spesso necessario e richiesto dagli utenti di poter spostare parte dell’intelligenza di un’applicazione dal server ai client. La codifica HTML permettono una interazione limitata e non sufficiente in ogni caso. DCOM offre vari modi per poter progettare e distribuire componenti intelligenti che si integrano con codice HTML e vengono eseguiti sui client e nella maggio parte dei casi direttamente nei browser. Grazie alla neutralità di DCOM rispetto ai vari linguaggi è possibile unire e gestire gli oggetti con programmi scritti in C++, Java, Visual Basic, Cobol, JavaScript e altri.

Active Desktop

ActiveX Controls

Web ServerBrowser HTTP

ActiveX Scripting

sub Buy_OnClick Cart.Purchaseend sub

Active Server

ActiveX Controls

ActiveX ScriptingDCOM

Any DCOM Server A questo proposito Microsoft ha introdotto la tecnologia ActiveX.

Gli oggetti ActiveX sono oggetti DCOM progettati per essere distribuiti ai client attraverso internet e fornire gli strumenti necessari alla loro integrazione con i browser Web.


- 27 -

SQL Server

HTML Webpage

ActiveX ServerControl

ActiveX ClientControl DCOM

HTTPInternet

InformationServer

DCOM e Active Directory

Con l’introduzione di Windows 2000 (o NT 5.0) Microsoft apporterà molti miglioramenti a DCOM. Infatti sostituendo il modello dei domini di Windows NT 4.0 con “Active Directory Service Interface” (ADSI) il sistema operativo offre migliori servizi per quanto riguarda la gestione della sicurezza, del registry e delle API.

Tutto il sistema di gestione delle autenticazioni delle password è stato riscritto e pensato per un ambiente distribuito: in NT 4.0 c’era un nodo centrale (PDC – Primary Domain Controller) a cui erano demandate le responsabilità di autenticazione degli utenti. Nella nuove versione di Windows non c’e’ più una sola autorità centrale ma c’è un vero e proprio sistema distribuito per la gestione della sicurezza con una struttura ad albero.

Gli oggetti DCOM sono inseriti nell’albero e appaiono come qualsiasi altra risorsa della rete.

Il futuro di DCOM

Il futuro di DCOM appare molto tranquillo. La notevole base installa consente un vantaggio competitivo all’architettura. Microsoft, infatti, mostra molto spesso le cifre che confermano questa situazione: più di 150 milioni di sistemi usano in qualche forma DCOM. Impressionanti sono anche le previsioni di mercato per applicazioni e componenti DCOM sviluppati da terze parti il che attira ancora di più sviluppatori.

Un altro elemento che migliora il futuro di DCOM è il passaggio della sua gestione dalle mani di Microsoft a un organismo più aperto, “The Open Group” (TOG). Gli obbiettivi di questo organismo sono:

• Promuovere la disponibilità e lo sviluppo delle tecnologie ActiveX su vari sistemi e architetture


- 28 -

• Migliorare l’interoperabilità con “Distributed Computing Environment” (DCE).

• Accelerare lo sviluppo delle tecnologie ActiveX

I membri di “The Open Group” sono

• Adobe Systems Inc.

• Computer Associates International Inc.

• Digital Equipment Corp.

• Hewlett-Packard Corp.

• Lotus Development Corp.

• Microsoft Corp.

• NCR Corp.

• The Powersoft Division of Sybase Inc.

• SAP AG

• Siemens Nixdorf Informationssysteme AG

• Software AG

DCOM amministrato da TOG influenzerà molto l’evoluzione delle tecnologie per ambienti distribuiti. All’inizio subirà un rallentamento dello sviluppo a causa delle molte società che ne fanno parte. Queste possono avere obbiettivi diversi che devono essere conciliati. Infatti CORBA, lo standard antagonista a DCOM, soffre particolarmente del fatto che OMG è composto da così tante società che il suo sviluppo è molto lento. Tuttavia più società coinvolte nelle specifiche e nello sviluppo significano un prodotto migliore, più stabile, adattabile a più situazioni e utilizzabile da un pubblico sicuramente più ampio.

Inoltre, ora che DCOM non è più nelle mani di Microsoft, molti altri sviluppatori sono propensi a sviluppare su questa piattaforma. Prima ritenevano che il controllo esercitato da Microsoft potesse rivelare molti effetti negativi, soprattutto in questioni di royalty e marketing.

E’ molto importante per la crescita di DCOM riconoscere che CORBA esiste e non scomparirà, ci sono moltissime aziende che hanno investito su CORBA, continuano a farlo e difficilmente cambieranno


- 29 -

direzione. Per questo è necessario sviluppare nuove tecnologie che consentano l’integrazione dei due sistemi nel modo più omogeneo possibile.

E’ invece molto improbabile che le due tecnologie si convergano in un modello unificato, almeno nel breve termine. E’ questo ancora un buon motivo per costruire strumenti di integrazione tra le due architetture.


- 30 -

CORBA Common Object Request Broker Architecture

CORBA è strutturata in maniera tale da permettere l' integrazione

di un’ ampia varietà di sistemi ad oggetti. La figura 1 mostra una richiesta mandata da un Client

all'implementazione di un oggetto (Codice e dati che implementano l'oggetto).

FIG. 1 Viene inviata una richiesta attraverso l’ Object Request Broker Il Client chiede l' esecuzione di un servizio e l' ORB è il

responsabile per tutti i meccanismi necessari per trovare l'implementazione dell' oggetto utile per la richiesta, per preparare l'implementazione dell' oggetto a ricevere la richiesta e per comunicare i dati per accontentare la richiesta.

L' interfaccia che il Client vede è completamente indipendente dalla locazione dell' oggetto, dal linguaggio di programmazione con cui è


- 31 -

implementato e da tutti gli aspetti non presenti nell' interfaccia dell’oggetto.

La figura 2 mostra la struttura di un ORB, le interfacce sono rappresentate dai rettangoli colorati e le frecce indicano se è l' ORB ad essere chiamato o se esegue delle chiamate attraverso l' interfaccia. ( Up-call interface ).

FIG. 2 La struttura delle interfacce dell' Object Request Broker Per fare una richiesta il Client può utilizzare l' interfaccia di

Invocazione Dinamica indipendente dall' interfaccia dell' oggetto obiettivo oppure può utilizzare un IDL stub specifico e dipendente dall' interfaccia dell’ oggetto.

Il Client può inoltre interagire direttamente con l' ORB per alcune funzioni di sistema.

L' implementazione dell' oggetto riceve una richiesta attraverso lo


- 32 -

Static IDL Skeleton oppure attraverso lo Dynamic Skeleton e può chiamare l’ Object Adapter e l' ORB mentre sta eseguendo il processo causato da una richiesta o durante altre operazioni.

Le interfacce agli oggetti possono essere definite staticamente nel linguaggio definito dall' OMG ( Object Management Group ) : l' IDL ( Interface Definition Language ), che definisce i tipi degli oggetti tenendo conto delle operazioni che possono essere eseguite su di essi e i parametri necessari per quelle stesse operazioni; oppure le interfacce possono essere aggiunte ad un servizio di Interface Repository che rappresenta i componenti di una interfaccia come degli oggetti ai quali è possibile accedere in modo runtime.

Il Client fa una richiesta per un oggetto attraverso l' accesso ad un Object Reference, conoscendo il tipo di oggetto e l' operazione desiderata.

La richiesta incomincia chiamando le stub routines specifiche per quello oggetto o costruendo la chiamata dinamicamente.

(Come in figura 3).

FIG. 3 Un Client che utilizza la Stub o la Dynamic Invocation Interface


- 33 -

Le due distinte chiamate per una richiesta utilizzano la stessa

semantica e il ricevente del messaggio non è in grado di distinguere in quale modo sia partita la richiesta.

L' ORB localizza il corrispondente codice d' implementazione, gli trasmette i parametri e trasferisce il controllo all' Object Implementation attraverso un IDL Skeleton oppure un Dynamic Skeleton.

Gli Skeleton sono specifici dell' interfaccia e dell' Object Adapter. Durante la realizzazione della richiesta, l' Object Implementation

può ottenere alcuni servizi dall' ORB attraverso l' Object Adapter ; a fine computazione vengono ritornati i risultati al Client.

L' Object Implementation può scegliere di utilizzare l' Object Adapter migliore per i tipi di servizi richiesti e quindi per una migliore computazione.

FIG. 4 Un Object Implementation sta ricevendo una Richiesta


- 34 -

La figura 5 mostra come l' interfaccia e le informazioni

d'implementazione sono rese disponibili al Client e all' Object Implementation.

L' interfaccia viene definita in IDL oppure in Interface Repository ( può esistere in entrambi i metodi ); la definizione è utilizzata per generare gli Stubs del Client e gli Skeletons dell' Object Implementation.

Le informazioni dell' Object Implementation sono fornite all' atto dell’ installazione e sono immagazzinate nell' Implementation Repository per il loro utilizzo durante lo svolgimento di una richiesta.

FIG. 5 L' interfaccia e l' Implementation Repository


- 35 -

Object Request Broker

L' ORB non ha la necessità di essere implementato come un singolo componente ma è piuttosto definito dalle sue interfacce; una implementazione di un ORB che fornisce delle appropriate interfacce è accettabile.L' interfaccia si può considerare organizzata in tre categorie, a seconda del tipo di operazioni richieste : 1. Operazioni che sono le stesse per tutte le implementazioni di un

ORB. 2. Operazioni che sono specifiche per particolari tipi di oggetti. 3. Operazioni che sono specifiche per particolari modi

d'implementazione di oggetti. . Le implementazioni degli ORBs possono portare a scelte

differenti, che valgono anche per i compilatori IDL, i repositories e i vari Object Adapters, con la conseguenza di avere a disposizione certi servizi per i Clients e le implementazioni di oggetti con differenti proprietà e qualità.

Ci possono essere anche implementazioni multiple degli ORBs che hanno diverse rappresentazioni degli object references e diversi metodi di realizzare le invocazioni.

Un Client potrebbe così accedere contemporaneamente a due object references controllati da implementazioni di ORBs differenti. Gli ORBs che lavorano in sintonia devono essere in grado di riconoscere i loro object references senza l' intervento del Client.

L' ORB Core è quella parte del sistema che fornisce la rappresentazione base degli oggetti e la comunicazione delle richieste.

CORBA è realizzato per supportare più sistemi ad oggetti grazie alla struttura dell' ORB, che sopra all' ORB Core presenta quei componenti che realizzano le interfacce in grado di mascherare tutte quelle differenze, che si presentano a causa delle implementazioni, tra gli ORB Cores.


- 36 -

Clients

Un Client di un oggetto ha accesso ad un object reference per quello oggetto e chiama le operazioni disponibili sull' oggetto.

Un Client conosce solo la struttura logica di un oggetto in base alla sua interfaccia e al comportamento che ha l' oggetto stesso in presenza delle invocazioni.

Un Client è considerato essere un processo che incomincia a fare delle richieste su un oggetto o anche una parte di implementazione relativa ad un particolare oggetto che realizza richieste su altri oggetti.

I Clients vedono gli oggetti e le interfacce dell' ORB attraverso la prospettiva di un language mapping; i Clients posseggono massima portabilità e non posseggono informazioni sull' implementazione di un oggetto o sull' Object Adapter utilizzato dall' implementazione o su quale ORB è utilizzato per accedere ad esso.

Implementazioni di oggetti

Un Object Implementation fornisce la semantica dell' oggetto per

mezzo della definizione dei dati dell' istanza dell' oggetto e del codice per i metodi dello oggetto stesso.

Per definire il comportamento dell' oggetto spesso vengono utilizzati dalla implementazione altri oggetti. In alcuni casi la funzione principale da considerare per l' implementazione è quella di avere effetti secondari sugli altri componenti tranne che sugli oggetti.

Si possono utilizzare più implementazioni differenti per gli oggetti, per le librerie, avere servers diversi, un programma specifico per ogni metodo, o avere un Object-Oriented Database e attraverso l' utilizzo di più Object Adapters è possibile supportare virtualmente ogni tipo di implementazione di oggetti.

Le implementazioni degli oggetti non dipendono in linea generale dall' ORB o da come i Clients chiamano gli oggetti e possono

scegliere le interfacce più opportune verso i servizi dell' ORB per mezzo della scelta dell' Object Adapter.


- 37 -

Object References

Un Object Reference è l' informazione necessaria per specificare

un oggetto all' interno di un ORB. I Clients e le implementazioni di oggetti non hanno una conoscenza specifica degli Object References perché sono in sintonia con il language mapping e sono quindi isolati dalla loro rappresentazione.

Due implementazioni di ORBs possono differire dalla scelta delle rappresentazioni dei loro Object References. La rappresentazione di un Object Reference mantenuta da un Client è valida solamente per il tempo di vita di quel Client.

Tutti gli ORBs devono fornire lo stesso language mapping ad un Object Reference per un particolare linguaggio di programmazione. Questo permette ad un programma scritto in un particolare linguaggio di programmazione l' accesso agli Object References indipendentemente dal tipo di ORB.

Il language mapping può anche fornire dei modi di accesso addizionali agli Object References convenienti al programmatore.

Esiste un Object Reference differente da tutti gli altri che non denota nessun oggetto.

Interface Definition Language

L' Interface Definition Language definisce i tipi degli oggetti per mezzo della realizzazione delle loro interfacce. Un' interfaccia consiste di un insieme di operazioni prefissate e di parametri per quelle operazioni.

L' IDL fornisce la struttura concettuale per la descrizione degli oggetti manipolati dall' ORB e non è necessaria la presenza del codice sorgente affinché l' ORB possa operare.

Purché l' informazione sia presente nella forma di stub routines o in un runtime interface repository un particolare ORB potrebbe funzionare correttamente.

L' IDL è il mezzo con il quale un particolare Object Implementation fornisce ai suoi potenziali Clients le operazioni disponibili e i metodi per mezzo dei quali devono essere invocate.

Inoltre è possibile mappare gli oggetti CORBA in particolari linguaggi di programmazione o in sistemi ad oggetti.


- 38 -

Language Mapping

Per i linguaggi di programmazione object-oriented è preferibile vedere gli oggetti CORBA come oggetti di un linguaggio di programmazione, ma anche per i linguaggi non object-oriented è meglio nascondere l' esatta rappresentazione dei componenti dell' ORB.

Per tutte le implementazioni degli ORB dovrebbe essere presente uno stesso mapping di IDL perché il Language Mapping include la definizione dei tipi di dati specifici del linguaggio trattato e le interfacce delle procedure per accedere a tutti gli oggetti attraverso l' ORB.

Queste includono la struttura dell' interfaccia Stub del Client ( non necessaria per i linguaggi object-oriented ), l' interfaccia di invocazione dinamica, l' Implementation Skeleton, gli Object Adapters e l' interfaccia diretta dell' ORB.

Un Language Mapping definisce anche l' interazione presente tra le invocazioni agli oggetti e i threads di controllo presenti nel Clients o nell' implementazione del sistema. Il Mapping più comune fornisce chiamate sincrone nelle quali le routines di chiamata ritornano quando termina l' operazione dell' oggetto. Altri Mapping possono permettere di riavere il controllo subito dopo una chiamata e in questi casi è necessario avere delle routines addizionali e specifiche per il linguaggio per garantire la sincronizzazione dei threads di controllo con l' invocazione all' oggetto.

Client Stubs

Per il mapping di un linguaggio non object-oriented deve essere presente una interfaccia di programmazione per gli Stubs per ogni tipo di interfaccia presente. Gli Stubs presentano gli accessi alle operazioni su un oggetto, definite in IDL, in modo che sia semplice per i programmatori da imparare.

Gli Stubs realizzano le chiamate verso l' ORB utilizzando le interfacce ottimizzate per il particolare ORB Core. Se è disponibile più di un ORB ci possono essere più Stubs corrispondenti ai diversi ORB e in questo caso è necessaria una cooperazione tra il language mapping e l'ORB per avere la corretta associazione tra Stubs e object reference. I linguaggi di programmazione object-oriented come C++ e Smalltalk non hanno bisogno della presenza di interfacce Stubs.


- 39 -

Dynamic Invocation Interface

Nel sistema è presente un' interfaccia che permette la costruzione dinamica delle invocazioni agli oggetti, così invece di chiamare una Stub routine che è specifica per una particolare operazione su un oggetto particolare, un Client può specificare l' oggetto da chiamare, l' operazione da eseguire e l' insieme dei parametri per l' operazione attraverso una o una sequenza di chiamate.

Il codice del Client deve possedere informazioni sull' operazione da richiedere e sui tipi dei parametri da passare ( ottenibili ad esempio da un Interface Repository ).

Un Client che utilizza questa interfaccia per inviare una richiesta a un oggetto ottiene la stessa semantica di un Client che utilizza l'operazione di Stub.

Una richiesta consiste di un Object Reference, di un' operazione e di una lista di parametri. I parametri della richiesta sono forniti dagli elementi di una lista; ogni elemento è un' istanza del tipo di dato NamedValue e ogni parametro è passato nella propria forma di dato.

I parametri forniti ad una richiesta possono essere soggetti ad un controllo di tipo run-time e devono essere forniti nello stesso ordine dei parametri definiti per l' operazione nell' Interface Repository.

Il tipo di dato NamedValue è definito in IDL e può essere utilizzato direttamente come tipo di un parametro o come un meccanismo per descrivere gli argomenti per una richiesta.


- 40 -

Il tipo NVlist è utile per costruire liste di parametri.

typedef unsigned long Flags;

struct NamedValue {

Identifier name; // nome dell' argomento

any argument; // argomento

long len; // lunghezza del valore dell' argomento

Flags arg_modes;// flags del modo dell' argomento

}; //definizione in IDL

CORBA_NamedValue *CORBA_NVList; /* definizione in C */

NamedValue e Flags sono definiti nel modulo di CORBA. I tipi NamedValue e NVList sono utilizzati nelle operazioni di

richiesta per la descrizione degli argomenti e per ritornare i valori computati.

Quando vengono utilizzate le strutture NamedValue per descrivere gli argomenti di una richiesta, i nomi sono gli identificatori dell'argomento specificati nella definizione IDL per una specifica operazione.

Il tipo any consiste di un Typecode e di un puntatore al valore del dato; il tipo Typecode può codificare una descrizione di un qualsiasi tipo specificabile in IDL. Per la maggior parte dei tipi di dati len rappresenta il numero di bytes che occupa il valore; per gli Object Reference len vale 1.

Implementation Skeleton

Per un particolare language mapping esiste un' interfaccia per i metodi che implementano tutti i tipi di oggetti. Generalmente tale interfaccia è dipendente dall' Object Adapter ed è di tipo up-call; l'Object Implementation scrive in essa quelle routines adatte per le chiamate dell'ORB attraverso lo Skeleton. L' esistenza di uno Skeleton non implica l'esistenza di un corrispondente Client Stub perché un Client può fare delle richieste anche attraverso l’Interfaccia di Invocazione Dinamica. È possibile scrivere un Object Adapter che non utilizzi gli Skeletons per invocare i metodi : si possono creare implementazioni dinamiche per linguaggi come Smalltalk.


- 41 -

Dynamic Skeleton Interface

Esiste anche un' interfaccia che consente di manipolare dinamicamente le invocazioni di oggetti. Questa permette di accedere ad una implementazione di un oggetto per un servizio e per dei parametri in maniera analoga alla modalità di operabilità della Dynamic Invocation Interface, così da evitare la staticità dell' accesso tramite uno Skeleton statico che è specifico per una particolare operazione.

Il codice di implementazione deve provvedere la descrizione di tutti i parametri delle operazioni all' ORB e l' ORB deve fornire i valori dei parametri di input per poter eseguire tali operazioni.

Il codice deve quindi fornire all' ORB i parametri di output oppure una eccezione.

La natura della Dynamic Skeleton Interface può variare considerevolmente in concomitanza del tipo di language mapping o dell'Object Adapter utilizzato ma sostanzialmente è un' interfaccia di tipo up-call.

I Dynamic Skeletons possono essere invocati sia dai Client Stubs sia dall’interfaccia d' invocazione dinamica : il risultato della richiesta è lo stesso.

La Dynamic Skeleton Interface ( DSI ) è quindi un modo per distribuire richieste da un ORB ad un' implementazione di oggetto che ignora il momento della compilazione del tipo dell' oggetto che sta implementando.

La DSI è quella parte del Server paragonabile alla Dynamic Invocation Interface ( DII ), che corrisponde ad una parte del Client.

Così come l' implementazione di un oggetto non è in grado di distinguere se il proprio Client utilizza la DII o gli Stubs specifici per i tipi in considerazione, così il Client che invoca un oggetto non può determinare se l' implementazione utilizza uno Skeleton o se è la DSI a connettere l’ ORB all’implementazione stessa.


- 42 -

FIG 5.1 Le richieste sono distribuite attraverso gli Skeletons, inclusi quelli dinamici

La DSI, come pure la DII ha molte applicazioni per le soluzioni

che conducono all' interoperabilità; il loro uso include lo sviluppo di interfacce per la realizzazione di software interattivo basato su debuggers, interpreti e monitors che vogliono intervenire dinamicamente sugli oggetti e fare da supporto per i linguaggi definiti con tipi dinamici come il LISP.

L' idea di base della DSI è quella di implementare tutte le richieste su di un particolare oggetto in modo tale che l' ORB invochi sempre la stessa up-call routine chiamata Dynamic Implementation Routine ( DIR ).

Una singola DIR può essere utilizzata come implementazione per molti oggetti e con diverse interfacce.

Alla DIR vengono passati i parametri per tutte le operazioni esplicite, una indicazione dell' oggetto che è stato invocato e l' operazione che è stata richiesta.

L' informazione viene codificata nei parametri della richiesta; inoltre la DIR può utilizzare l' oggetto invocato, l' Object Adapter e l'Interface Repository per acquisire più dati sul particolare oggetto e sul tipo di invocazione.

La DIR può accedere e operare su singoli parametri e può fare lo stesso per un Object Adapter e per altre implementazioni di oggetti. La DSI può essere supportata da un qualsiasi Object Adapter e come gli Skeletons per tipi specifici può anch' essa avere un Object Adapter specifico per certe funzioni.


- 43 -

Object Adapters

Un Object Adapter è il mezzo principale con il quale un object implementation accede ai servizi forniti dall' ORB. Sono presenti pochi Object Adapters ma con la caratteristica di avere un' ampia disponibilità e con interfacce che sono adatte per specifici tipi di oggetti.

I Servizi forniti dall' ORB verso un Object Adapter spesso includono la generazione e l' interpretazione di Object References, l'invocazione dei metodi, la sicurezza delle azioni, l' attivazione e la deattivazione di oggetti e implementazioni, il mapping di object references per le implementazioni e la registrazione delle implementazioni.

La larga gamma di caratteristiche proprie di un oggetto come la granularità, la durata della vita, la politica, lo stile di implementazione e altre proprietà, rendono difficile all' ORB il compito di fornire una singola interfaccia che sia conveniente ed efficiente per tutti gli oggetti.

Ecco quindi che per mezzo degli Object Adapters è possibile per l'ORB fornire a particolari gruppi di oggetti con requisiti simili, interfacce fatte su misura per essi.

Interfaccia dell' ORB

L' ORB Interface è l' interfaccia che permette l' accesso diretto all' ORB, è la stessa per tutti gli ORBs e non dipende dall' interfaccia dell'oggetto o dall' Object Adapter. Siccome la funzionalità dell' ORB è principalmente fornita dall' Object Adapter, dagli Stubs, dallo Skeleton o dall’ invocazione dinamica, ci sono solo poche operazioni comuni a tutti gli oggetti che sono utili sia ai Clients che alle implementazioni degli oggetti.

Interface Repository

L' Interface Repository è un servizio che fornisce oggetti persistenti che rappresentano l' informazione IDL in modalità di esecuzione.

L' informazione dell' Interface Repository può essere utilizzata dall' ORB per accontentare delle richieste e anche perché un programma possa incontrare un oggetto la cui interfaccia era sconosciuta durante la


- 44 -

compilazione del programma stesso, affinché possa in seguito conoscere le operazioni valide su quell' oggetto e possa fare una chiamata su di esso.

Inoltre l' Interface Repository è un mezzo per immagazzinare informazione addizionale associata con le interfacce agli oggetti dell' ORB, come l' informazione di debugging, le librerie degli Stubs o degli Skeletons o le routines che possono formattare particolari tipi di oggetti.

L' Interface Repository è quindi quella componente dell' ORB che fornisce una memorizzazione persistente delle definizioni delle interfacce utilizzate e gestisce l' accesso ad un insieme di definizioni di oggetti specificate in IDL.

Un ORB fornisce l' accesso in modalità distribuita ad un insieme di oggetti, per mezzo di quelle interfacce di pubblico dominio specificate in IDL e l' Interface Repository realizza la memorizzazione, la distribuzione e la supervisione delle definizioni di tali interfacce.

Un ORB per accontentare correttamente una richiesta, deve poter accedere alle definizioni dell' oggetto che sta manipolando; queste possono essere rese disponibili in due modi :

1. Incorporando l' informazione in forma di procedure nelle Stub

routines, ad esempio con il codice che mappa le subroutines in linguaggio C in protocolli di comunicazione.

2. Con oggetti ai quali si accede attraverso l' Interface Repository che possiede un accesso dinamico alle proprie informazioni.

In modo particolare l' ORB è in grado di utilizzare le definizioni degli oggetti contenute nell' Interface Repository per manipolare e interpretare tutti i valori che vengono forniti con una richiesta : 1. Per fornire il controllo del tipo di una richiesta ( se è fornita dalla DII

oppure attraverso uno Stub ). 2. Per fornire un aiuto nel controllo della correttezza dei grafi di

comunicazione tra i vari componenti presi in eredità dalle interfacce. 3. Per fornire un aiuto alla realizzazione dell' interoperabilità tra

implementazioni differenti di ORBs. Così come l' interfaccia alle definizioni degli oggetti contenute in

un Interface Repository è di pubblico dominio, l' informazione in esso contenuta può essere utilizzata dai Clients e dai vari servizi che la richiedono.


- 45 -

Per esempio il Deposito può essere utilizzato per : 1. Disporre l' installazione e la distribuzione delle definizioni delle

interfacce. 2. Fornire i componenti ad esempio di un browser di interfaccia. 3. Fornire l' informazione necessaria dovuta alla presenza di un

linguaggio, come un compilatore. 4. Fornire i componenti necessari per costruire un ambiente specifico

per uso utente. Le definizioni delle interfacce sono contenute nell' Interface

Repository come un insieme di oggetti accessibili attraverso delle definizioni di interfaccia implementate in IDL.

Una definizione di interfaccia contiene una descrizione delle operazioni che questa supporta, i tipi dei parametri, le eccezioni alle quali può condurre e l' informazione che può utilizzare.

Inoltre l' Interface Repository può contenere valori costanti che possono essere utilizzati da altre definizioni di interfaccia oppure semplicemente dal programmatore.

L' Interface Repository utilizza i moduli per catalogare le interfacce e per orientarsi attraverso queste per mezzo dei loro nomi.

I moduli possono contenere costanti, definizioni di tipi, typecodes ( valori che descrivono un tipo in forma di struttura ), definizioni di interfacce e altri moduli.

L' Interface Repository è un insieme di oggetti che rappresentano la informazione in essi contenuta; gli oggetti possono essere presenti in modo del tutto persistenti o essere creati al momento di una loro richiesta da parte di una certa operazione.

Esistono operazioni in grado di ottenere dal Repository un intero blocco di informazione che riesce a descrivere un' interfaccia o un' intera operazione.

Un ORB può avere accesso contemporaneamente a più Interface Repositories, questo perché ogni ORB ha esigenze proprie e particolari per l' implementazione del Repository : un particolare tipo di implementazione di oggetto può richiedere di immagazzinare l'informazione specifica per il proprio funzionamento oppure perché serve proprio avere informazione diversa in differenti Repositories.

Una particolare specificazione di un Interface Repository fornisce le particolari operazioni con cui poter trarre l' informazione desiderata e


- 46 -

per creare nuove definizioni con essa; ci sono inoltre vari metodi per memorizzare nuova informazione in un Repository, come ad esempio compilare definizioni implementate in IDL oppure copiare oggetti da un deposito ad un altro.

Un utilizzo critico dell' informazione contenuta nell' Interface Repository è per la connessione di più ORBs :

Quando viene passato un oggetto da un ORB ad un altro in una certa richiesta, potrebbe essere necessario creare nell' ORB ricevente la richiesta stessa un nuovo oggetto per rappresentare quello da passare.

Questa operazione può richiedere l' esatta localizzazione della informazione per l' interfaccia dell' oggetto contenuta in un certo Interface Repository dell' ORB ricevente la richiesta.

Per ottenere ciò viene utilizzato un identificatore dell' interfaccia particolare definita in un Repository : il Repository id viene quindi passato all' ORB ricevente tenendo conto del fatto che l' interfaccia con lo stesso identificatore deve essere presente in entrambi i Repositories dei due ORBs differenti.

Implementation Repository

L' Implementation Repository contiene l' informazione che permette all' ORB di localizzare ed attivare le implementazioni di oggetti.

Nonostante questa informazione presente nell' Implementation Repository sia specifica di un ORB o di un ambiente di operazione, l'Implementation Repository è il luogo convenzionale per registrare tale informazione.

L' installazione delle implementazioni e il controllo delle politiche relative all' attivazione e all' esecuzione di object implementations è realizzata per mezzo di operazioni sull' Implementation Repository.

Inoltre l' Implementation Repository è un mezzo per immagazzinare informazione addizionale associata con le implementazioni degli oggetti dell' ORB, come il controllo amministrativo, l' allocazione delle risorse o il controllo della sicurezza.

Un' implementazione di un Interface Repository richiede delle forme di memorizzazione di oggetti persistenti che determinano la distribuzione delle definizioni delle interfacce in tutto il dominio di rete.

Se per l' implementazione di un Interface Repository viene utilizzato un file system, su di una singola macchina ci potrebbe essere solo una singola copia delle interfacce; se invece viene utilizzato un OODB ( Object-Oriented Database ) possono essere realizzate più copie


- 47 -

delle definizioni delle interfacce ognuna delle quali è distribuita su molte macchine per garantire un' alta disponibilità e un buon bilanciamento.

Il tipo di memorizzazione può determinare lo scopo delle definizioni delle interfacce fornite da tale implementazione :

- può determinare se per ogni utente è presente una copia locale di interfacce oppure se ne esiste una sola da condividere tra tutti gli utenti.

- può anche determinare se i Clients di un insieme di interfacce vedono esattamente lo stesso insieme ad un certo istante di tempo oppure se la latenza presente per la distribuzione delle copie di quell' insieme fornisce agli utenti viste differenti per stesso istante.


- 48 -

Esempi di ORBs

Esiste un' ampia varietà possibile di implementazioni di ORBs all'interno della Common ORB Architecture.

Se è presente un appropriato meccanismo di comunicazione è possibile implementare un ORB per mezzo di routines presenti nei Clients e nelle implementazioni; gli Stubs nel Client possono utilizzare un meccanismo di chiamata trasparente o accedere direttamente ad un servizio di locazione per stabilire la comunicazione con le implementazioni.

Il codice collegato con l' implementazione è utilizzato per stabilire i Databases adatti affinché vengano utilizzati dai Clients.

ORB basato su Servers

Per centralizzare il controllo effettuato dall' ORB, tutti i Clients e le implementazioni possono comunicare per mezzo di uno o più Servers il cui lavoro consiste nel dirigere le richieste dei Clients verso le implementazioni. L' ORB potrebbe essere realizzato come un normale programma con mansioni del tutto simili a quelle realizzate per il sottostante sistema operativo e con normali funzioni di chiamate a procedura per le comunicazioni.

ORB basato sul Sistema Operativo

Per accrescere la sicurezza, la robustezza e l' esecuzione, l' ORB potrebbe essere realizzato in modo da essere un servizio di base del sottostante sistema operativo.Le Object References potrebbero essere rese infalsificabili, riducendo così il costo di autenticazione per ogni richiesta.

Il sistema operativo potrebbe conoscere la locazione e la struttura dei Clients e delle implementazioni, così da rendere possibile la implementazione di varie ottimizzazioni, come ad esempio evitare il marshalling quando sia i Clients che le implementazioni sono residenti sulla stessa macchina.

ORB basato sulla Libreria

Le implementazioni di oggetti che possono essere condivise e che non sono troppo onerose possono stare in una Libreria.

In questo caso gli Stubs possono essere i veri metodi : ciò rende


- 49 -

possibile per un programma di un Client accedere ai dati per gli oggetti in modo tale che l' implementazione sia sicura del corretto utilizzo di tali dati da parte del Client stesso.

Struttura di un Client

Un Client di un oggetto ha un Object Reference che si riferisce a quello oggetto. Un Object Reference può essere invocato o passato come parametro ad una invocazione su di un altro oggetto.

Invocare un oggetto significa specificare l' oggetto da essere invocato, l’ operazione da essere eseguita e i parametri da passare all'operazione e quelli necessari per il risultato.

L' ORB supervisiona il trasferimento del controllo e dei dati all'Object Implementation per poi ritornare al Client. Nel caso in cui l'ORB non possa completare l' invocazione fornisce come risposta di ritorno una eccezione. Normalmente un Client chiama una routine presente nel suo programma che realizza l' invocazione e che ritorna ad operazione completata.

I Clients accedono agli Stubs specifici per il tipo di oggetto per mezzo di routines di libreria presenti nel loro programma.

Come mostrato in figura 6 il programma del Client vede così le routines normalmente chiamabili nel modo corrispondente al proprio linguaggio di programmazione. Tutte le implementazioni forniscono un tipo di dato specifico per il linguaggio da utilizzare per fare riferimento agli oggetti.

Il Client quindi passa quell' Object Reference alle Stub routines per poter avviare un ' invocazione.

Gli Stubs hanno accesso alla rappresentazione dell' Object Reference e interagiscono con l' ORB per realizzare l' invocazione stessa.


- 50 -

FIG. 6 La struttura di un Client

Un addizionale codice di libreria è disponibile per realizzare invocazioni su oggetti, per esempio quando l' oggetto non era ancora definito al momento della compilazione.

In questo caso il programma del Client deve anche fornire quella informazione necessaria per nominare il tipo di oggetto e il metodo da essere invocato, e per realizzare una sequenza di chiamate per specificare i parametri e incominciare l' invocazione.

I Clients normalmente ottengono gli Object References ricevendoli come parametri di output dalle invocazioni su altri oggetti per i quali essi hanno dei riferimenti.

Quando un Client è un' implementazione esso riceve gli Object References come parametri di input su oggetti che esso stesso implementa.

Un Object Reference può anche essere convertito in una stringa che può essere immagazzinata in files o preservata o comunicata e in seguito ritrasformata dall' ORB che l' ha creata in un riferimento di oggetto.


- 51 -

Struttura di un Object Implementation

Un Object Implementation fornisce il reale stato e il comportamento di un oggetto e può essere strutturata in molteplici modi.

Oltre a definire i metodi per le loro operazioni, l' Object Implementation presenta anche le procedure per attivare e deattivare gli oggetti e utilizza le facilities di altri oggetti o quelle fornite da altri componenti per rendere persistente lo stato dell' oggetto, per controllare gli accessi all' oggetto e per implementare i metodi.

L' Object Implementation come mostrato in figura 7, interagisce con l' ORB con diversi metodi per stabilire la propria identità, per creare nuovi oggetti e per ottenere dei servizi che dipendono dall' ORB.

L' interazione avviene principalmente attraverso un Object Adapter, il quale fornisce un' interfaccia per i servizi dell' ORB conveniente per un particolare stile di implementazione di oggetto.

FIG. 7 La struttura di un' implementazione di oggetto


- 52 -

Quando è presente un' invocazione, l' ORB Core, l' Object Adapter, e lo Skeleton realizzano che è stata fatta una chiamata ad un determinato metodo dell' implementazione.

Un parametro a quel metodo specifica l' oggetto che è invocato, inoltre il metodo utilizza tale parametro per localizzare i dati necessari all'oggetto.Sono presenti anche dei parametri aggiuntivi in accordo con la definizione dello Skeleton.

Quando il metodo è completato ritorna, fornendo come risultati da essere ritrasmessi al Client i parametri di output o in alternativa un'eccezione.Quando viene creato un nuovo oggetto lo si rende noto all'ORB così che possa sapere dove trovare l' implementazione per quell'oggetto.L' implementazione si registra in una particolare interfaccia e specifica come avviare l' implementazione stessa se non è già in esecuzione. Le Object Implementations determinano il loro comportamento utilizzando le facilities oltre all' ORB e all' Object Adapter.Ad esempio benché l' Object Adapter di base fornisce dei dati persistenti associati ad un oggetto, questi dati vengono utilizzati per identificare i dati reali dell' oggetto immagazzinati in un servizio di memorizzazione.Più implementazioni possono utilizzare lo stesso servizio di memorizzazione e gli oggetti possono anche scegliere quello più adatto.

Struttura di un Object Adapter

Un Object Adapter è il mezzo principale per un Object Implementation di accedere ai servizi dell' ORB, ad esempio per la generazione di un Object Reference. Un Object Adapter esporta un'interfaccia pubblica all' Object Implementation e una privata allo Skeleton ed è costituito da una interfaccia privata dipendente dall' ORB.

Gli Object Adapter sono responsabili per le seguenti funzioni :

1. Generazione e interpretazione di Object References.

2. Invocazione di metodi.

3. Sicurezza per le azioni fra i vari componenti.

4. Attivazione e deattivazione di oggetti e implementazioni.


- 53 -

5. Mapping di Object References per le corrispondenti a implementazioni di oggetti.

6. Registrazione delle implementazioni.

Queste funzioni sono realizzate utilizzando l' ORB Core e qualsiasi altro componente necessario.Un particolare Object Adapter è in grado di delegare una o più responsabilità all' ORB Core, sopra il quale esso è costituito.Come mostrato in figura 8 l' Object Adapter è implicitamente coinvolto

nell' invocazione dei metodi, nonostante l' interfaccia utilizzata direttamente è quella attraverso gli Skeletons.

Ad esempio l' Object Adapter può essere coinvolto nell'attivazione della implementazione o nell' autenticazione della richiesta.

FIG. 8 La struttura di un Object Adapter

L' Object Adapter definisce la maggior parte dei servizi forniti


- 54 -

dall'ORB, sui quali può dipendere l' Object Implementation.ORBs differenti forniscono diversi livelli di servizio e diversi ambienti operativi che possono fornire alcune proprietà implicitamente e richiederne altre dall' Object Adapter.Ad esempio, le implementazioni di oggetti immagazzinano certi valori nell' Object Reference per permettere una più facile identificazione di un oggetto durante un' invocazione.

Se l' Object Adapter permette all' implementazione di specificare quei valori che caratterizzano la creazione di un nuovo oggetto, li immagazzina nell' Object Reference se l' ORB permette tale operazione.

Se l' ORB Core non possiede questa caratteristica, l' Object Adapter registra i valori nella propria memoria per fornirli quindi all'implementazione durante un' invocazione.Un Object Implementation ha la possibilità, per mezzo degli Object Adapters, di accedere ad un servizio anche se non è implementato nell' ORB Core; se il servizio è fornito dall' ORB Core, l' adattatore fornisce semplicemente un'interfaccia verso di esso; se non è fornito,l' adattatore deve implementarlo sull' ORB Core.Ogni adattatore deve fornire la stessa interfaccia e gli stessi servizi per tutti gli ORBs sui quali è implementato.

Non è necessario per tutti gli Object Adapters fornire la stessa interfaccia o le stesse funzionalità; infatti alcuni Object Implementations hanno delle richieste speciali : per esempio un sistema di database object-oriented può voler registrare implicitamente i suoi migliaia di oggetti senza dover fare ogni volta delle singole chiamate all' Object Adapter.

In questo caso sarebbe improponibile per l' Object Adapter mantenere lo stato di ogni oggetto per questo viene utilizzata un'interfaccia sincronizzata con le implementazioni degli oggetti che rende possibile l' utilizzo di particolari dettagli forniti dall' ORB Core per fornire un efficace accesso all' ORB.

Esempi di Object Adapters

Esistono molti Object Adapters differenti e nonostante le implementazioni di oggetti dipendono dalla loro interfaccia, si cerca di fornire delle realizzazioni il più pratiche possibili.

La maggior parte di Object Adapters sono disegnati per coprire un' ampia gamma di implementazioni di oggetti così da soddisfare il


- 55 -

maggior numero di richieste di servizi o di interfacce.

Object Adapter di base

La specificazione definisce un Object Adapter che può essere utilizzato per tutti quegli oggetti dell' ORB che hanno una implementazione convenzionale.

Di solito tali implementazioni sono programmi separati e questo permette che ci sia un processo per ogni metodo, un programma separato per ogni oggetto o uno condiviso per tutte le istanze del tipo dell' oggetto.

Ciò comporta una piccola quantità di memoria persistente per ogni oggetto, che può essere utilizzata come un nome o un identificatore per altre memorizzazioni, per accedere a liste di controllo o ad altre proprietà dell' oggetto stesso.Se l' implementazione non è attiva al momento di una invocazione il BOA penserà ad attivarne una.

Object Adapter di Libreria

Questo Object Adapter è principalmente utilizzato per oggetti che hanno implementazioni di libreria; accede a memorizzazioni in files e non supporta l' attivazione o l' autenticazione benché si sia supposto che gli oggetti stiano nel programma dei Clients.

Object-Oriented Database Adapter

Questo adattatore utilizza una connessione verso un database di tipo object-oriented per fornire l' accesso agli oggetti immagazzinati in esso. Benché l' OODB fornisce i metodi e una memorizzazione persistente, gli oggetti possono essere registrati implicitamente senza che sia richiesto alcuno stato dall' Object Adapter stesso.

Integrazione di altri sistemi ad oggetti

La Common ORB Architecture è disegnata per permettere l'interoperabilità con un' ampia gamma di sistemi ad oggetti, come è mostrato in figura 9.

Siccome ci sono molti sistemi ad oggetti nasce spontanea la richiesta di poter accedere agli oggetti presenti in quei sistemi per mezzo


- 56 -

dell' ORB.

Naturalmente gli altri sistemi ad oggetti possono essere a loro volta degli ORBs.

FIG. 9 Modi diversi per integrare differenti Sistemi ad Oggetti

Per quei sistemi che vogliono semplicemente mappare i loro oggetti dentro quelli dell' ORB e ricevere invocazioni attraverso quest'ultimo, si cerca di realizzarli in modo tale che appaiano come implementazioni dei corrispondenti oggetti dell' ORB. Il sistema ad oggetti così realizzato registra i propri oggetti tramite l' ORB, è in grado di ricevere delle richieste e può comportarsi anche come un Client che formula le richieste.

In alcuni casi non è conveniente per un altro sistema ad oggetti comportarsi come un' implementazione di oggetto di tipo BOA perché un Object Adapter potrebbe essere disegnato per oggetti che sono creati per essere invocati principalmente dall' ORB.

Un altro sistema ad oggetti potrebbe volere creare oggetti senza la cooperazione dell' ORB, aspettandosi così più invocazioni da se stesso


- 57 -

piuttosto che attraverso l' ORB. In questo caso un appropriato Object Adapter potrebbe permettere agli oggetti di essere registrati implicitamente quando sono passati attraverso l' ORB.


- 58 -

Interoperabilità

L’ Interoperabilità rappresenta la facoltà che possiede un Client che lavora su un ORB A di invocare un’ operazione, definita in IDL, su un oggetto presente su un ORB B, dove l’ ORB A e l’ ORB B sono sviluppati indipendentemente l’ uno dall’ altro.

Le richieste generali per tale funzionalità sono : 1. L’ abilità degli ORBs forniti da due differenti venditori di poter

interoperare senza possedere una conoscenza a priori di ogni altra implementazione.

2. Il supporto di tutte le funzionalità dell’ ORB. 3. La conservazione dei contenuti e delle semantiche delle informazioni

dell’ ORB attraverso funzionalità specifiche come la sicurezza. La finalità ultima è quella che le invocazioni tra Clients e Server

Objects risultino essere indipendenti dalla locazione degli oggetti, sia che si trovino sullo stesso ORB che su ORBs differenti, e in modo tale da non dover agire per modificare le implementazioni esistenti.

CORBA identifica varie trasparenze che devono essere supportate all’ interno dello ambiente di un singolo ORB, come la trasparenza di locazione.

L’ Interoperabilità può essere viste come l’ estensione di tali trasparenze verso molti ORBs; essa introduce molte distinzioni rappresentabili dagli scopi associati a ciascun ORB; intervengono quindi i domini per descrivere tali scopi e le loro implicazioni.

Un dominio può essere inteso come un insieme di oggetti che condividono una caratteristica comune; ci possono essere molti tipi di domini, come i management domains, i naming domains, i language domains o i technology domains.

Essi permettono la partizione dei sistemi in collezioni di componenti che possiedono caratteristiche in comune.


- 59 -

I Servizi di CORBA

Allo scopo di avere una concreta standardizzazione delle interfacce a tutte le applicazioni presenti in un ambiente ad oggetti distribuito, nasce l’ idea di organizzare gli oggetti in Object Services, Common Facilities e Application Objects.

FIG. 10 Object Services Un Object Service definisce così le interfacce e le corrette

semantiche più largamente utilizzate per supportare le applicazioni presenti in un tale ambiente.

L’ API ( Application Program Interface ) degli Object Services è realizzato in moduli in modo da permettere una completa compatibilità con le applicazioni, le quali possono così utilizzare i servizi che esse richiedono.

Tutte le operazioni fornite dagli Object Services sono rese disponibili dall’ Interface Definition Language.

Le richieste necessarie per organizzare questo tipo di architettura : 1. Le interfacce degli Object Services sono espresse in IDL e

sono di tipo object-oriented. 2. Tutte le estensioni proposte per l’ IDL e per il modello

utilizzato vengono identificate.


- 60 -

3. Il comportamento specifico e la sequenza di operazioni fanno parte delle specifiche del particolare servizio richiesto.

4. Le specifiche del servizio non contengono descrizioni delle implementazioni, questo per mantenere una massima flessibilità per chi sviluppa le applicazioni.

5. Le specifiche presenti sono complete per avere la corretta collaborazione fra tutti i componenti.

6. Tutti i Servizi hanno una completa e precisa descrizione della loro semantica.

Gli obiettivi di tale architettura sono : 1. Indipendenza e modularità dei Servizi in modo tale da poter

specificare e implementare separatamente ogni servizio stesso. 2. Minimizzazione della duplicazione di funzionalità equivalenti

per fare in modo che lo stesso Servizio sia utile a più componenti.

3. Trasparenza delle interfacce presenti tra i Servizi per mezzo di una loro adeguata specifica in modo tale che le implementazioni possano essere facilmente sostituite e tutte le parti possano cooperare correttamente.

4. Consistenza tra Servizi diversi affinché possa esistere quella cooperazione necessaria per il funzionamento del sistema.

5. Estensibilità di Servizi individuali attraverso un processo iterativo attraverso la capacità di eredità dell’ IDL che rende più semplice la definizione di un insieme di interfacce che possono essere utilizzate da Servizi diversi; ad esempio una interfaccia può ereditare da altre interfacce la specifica delle operazioni che essa implementa.

6. Estendibilità della collezione dei Servizi in modo da poter definire e rendere standard nuovi Servizi senza il bisogno di dover ridisegnare un nuovo sistema che possa utilizzare anche i vecchi Servizi.

7. Configurabilità dei vari Servizi in diverse combinazioni per diversi servigi.

8. Descrizioni precise ed accurate delle semantiche dei Servizi. 9. Sicurezza affinché il Servizio utilizzato, che è parte integrante

di un sistema considerato sicuro, risponda a tutti quei requisiti necessari per l’integrità, la riservatezza, la responsabilità e la


- 61 -

disponibilità, in modo tale da includere ad esempio il controllo dell’ accesso ai dati o alle operazioni e alla loro verifica ( auditing ) in maniera del tutto consistente con la sicurezza presente in CORBA e con i Security Object Services.

10. Performance presente nelle interfacce ai Servizi. 11. Scalabilità : i Servizi hanno tutte le specifiche necessarie

affinché più implementazioni possano essere ottimizzate per ambienti diversi; l’ IDL e un language mapping adatto possono rendere trasparente la locazione di un Servizio e siccome i vari Servizi possono avere implementazioni prelevate da librerie condivise, gli utenti non devono accorgersi del tipo particolare di implementazione utilizzata.

12. Portabilità delle implementazioni attraverso una larga gamma di piattaforme HW.

Esistono varie proprietà che devono essere sviluppate prima che le interfacce vengano definite :

1. Le interfacce degli Object Services debbono ottenere i massimi

benefici dalla eredità multipla; un’ implementazione di un oggetto potrebbe supportare molte e diverse interfacce ed essa per mezzo dell’ eredità multipla può avere la possibilità di specificare il completo insieme di operazioni che vengono implementate. I Clients possono scegliere di utilizzare solo quella parte di un oggetto utile per i loro scopi e possono vedere l’ oggetto stesso per mezzo di quella interfaccia di cui hanno bisogno.

2. Le specifiche di CORBA descrivono un modello di terminazione multipla per le operazioni; per ogni richiesta ad un’ operazione sarà ritornato un adeguato insieme di terminazioni.Una di queste terminazioni viene designata per essere quella che riporta il risultato per mezzo dei parametri presenti nella richiesta di invocazione. Inoltre vengono definite delle speciali terminazioni che ritornano in caso di specifici esiti delle operazioni dei risultati detti eccezioni; questo permette ai Clients di migliorare notevolmente la capacità di rilevare gli errori commessi da tali operazioni.


- 62 -

Per esempio se si considera la Naming Service Interface :

si analizza che sono state definite cinque differenti terminazioni per operazioni con un esito singolare; tali terminazioni hanno un significato semantico per la manipolazione di un NamingContext object.

3. I Servizi devono rendere standard il metodo di allocazione e deallocazione di quella memoria necessaria per memorizzare i parametri il cui contenuto rappresenta il risultato di un’ operazione da ritornare al Client.

4. Deve essere presente una certa convenzione per i nomi utilizzati per le interfacce, i tipi, le operazioni, i parametri, le strutture, le eccezioni e per tutti i componenti necessari alle varie implementazioni.

Componenti di un Object Service Ogni Servizio è caratterizzato dalle interfacce che esso fornisce,

dagli oggetti che gli permettono di fornire tali interfacce e da vari aspetti della propria implementazione che indirizzano il suo utilizzo.

Un Servizio può coinvolgere un solo oggetto ( come ad esempio avviene per il time server object ) oppure più oggetti, che forniscono lo


- 63 -

stesso tipo di interfaccia ( come avviene per i thread objects ) o anche più oggetti che forniscono tipi di interfaccia distinte ereditate da un tipo di interfaccia di un servizio ( come avviene per tutti gli oggetti che forniscono il lifecycle service ).

Ogni Object Service fornisce il suo servizio ad un insieme di utenti quali gli Application Objects oppure i Common Facility Objects o anche altri tipi di Object Services.

FIG.11 Gli utenti di un Object Service Le interfacce ad un Object Service sono caratterizzate da : 1 Audience che rappresenta il tipo di utente di un’ interfaccia;

questo può essere un utilizzatore di un certo servizio oppure una funzione di gestione del sistema. Per alcuni servizi è necessaria la cooperazione di oggetti non forniti direttamente dall’ Object Service in questione, in questo caso le interfacce vengono utilizzate per creare la funzione desiderata a partire da tutti gli oggetti necessari; l’ audience per tali interfacce non è rappresentato dall’ utente del servizio e neppure da un manager del sistema ma da tutti gli oggetti necessari per fornire il servizio richiesto.

Le interfacce che realizzano un Object Service si possono così distinguere dal tipo di audience che le utilizza :


- 64 -

• Interfacce di funzione che definiscono le operazioni invocate dagli utenti di un Object Service, ad esempio l’ interfaccia OperationDef definisce quella parte di interfaccia all’ Interface Repository che gli utenti del servizio invocano per avere una corretta descrizione delle operazioni.

• Interfacce di gestione che realizzano la comunicazione con i System Management Services; queste detengono il controllo operazionale di un servizio e il controllo della sua installazione e del suo funzionamento.

• Interfacce di costruzione che definiscono le operazioni utilizzate per la comunicazione tra il core di un Object Service e tutti gli oggetti che devono cooperare per fornire il servizio.

Ad esempio gli oggetti transazionabili devono ereditare le interfacce di costruzione del Transaction Service e fornire le implementazioni di tali interfacce.

2 Bearer che rappresenta il tipo di oggetto che fornisce una interfaccia;un oggetto è caratterizzato dal fatto che esso ha una propria interfaccia, ad esempio per un name server object ci si aspetta come obiettivo principale che fornisca come servizio il tipo di interfaccia del name service, anche se esso può possedere ad esempio anche l’ interfaccia lifecycle.

Le prime due tabelle seguenti riportano i nomi dei vari servizi

disponibili con le loro funzioni; le altre due riportano invece le dipendenze tra i servizi e le loro cause .

Nella prima colonna delle prime due tabelle sono presenti tutti i Servizi mentre nella seconda colonna corrispondente è riportata la funzione da essi fornita.


- 65 -

Tabella 1.1. Categorie di Object Sevices


- 66 -

Tabella 1.2. Categorie di Object Services


- 67 -

Le due tabelle seguenti rappresentano le dipendenze presenti per ogni Servizio con la specifica della più probabile causa per tali dipendenze.

Tabella 2.1. Cause di Dipendenze tra Object Services


- 68 -

Tabella 2.2. Cause di Dipendenze tra Object Services


- 69 -

• Object Event Notification Service : tale servizio degli eventi definisce due distinti ruoli per gli oggetti; tali ruoli sono rappresentati dai Suppliers che producono i dati degli eventi e i Consumers che processano i dati degli eventi. Tutti i dati vengono trasmessi attraverso richieste standard. Esistono due diversi metodi per incominciare la comunicazione, il push model e il pull model; il primo permette ad un fornitore di eventi di incominciare a trasmettere i dati degli eventi ai consumatori; il secondo permette ad un utilizzatore di eventi di richiedere i dati degli eventi ad un fornitore. Caratteristiche del servizio sono quelle di avere un ambiente distribuito che porta ad una realizzazione delle interfacce in modo tale da permettere ai consumatori e agli utilizzatori di eventi di essere disconnessi di volta in volta, per evitare così che tutti i controlli necessari agli eventi stessi siano centralizzati.

• Object Lifecycle Services : definiscono quei servizi e quelle convenzioni utilizzate dai Clients per creare, cancellare, copiare e spostare gli oggetti senza badare alla loro locazione. Ogni Client può essere visto come quella parte di codice che richiede un’ operazione di life cycle per qualche oggetto. Naturalmente un Client possiede una visione semplificata di tali operazioni; il modello di creazione di un Client è definito fabbrica. Una fabbrica è un oggetto che crea un altro oggetto, fornendo al Client che lo richiede le operazioni specifiche per creare e inizializzare nuove istanze. I Factory Finders realizzano un’ operazione che ritorna una sequenza di fabbriche e sono passati dai Clients alle operazioni di move e copy.

• Object Name Service : definisce quel contesto di nomi simbolici unici che identificano gli oggetti; nomi differenti possono essere legati ad un oggetto nello stesso o in diversi contesti e allo stesso istante. Risolvere un nome significa determinare l’ oggetto associato con quel nome e definito in un certo contesto.

• Persistent Object Service : fornisce le interfacce per i meccanismi utilizzati per mantenere e gestire lo stato persistente degli oggetti in un modo di memorizzazione indipendente. Lo stato di un oggetto si può considerare costituito di due parti distinte, una è costituita dallo stato dinamico, che risiede normalmente in memoria e non esiste per tutta la durata di vita dell’ oggetto e una è costituita dallo stato persistente che l’ oggetto potrebbe utilizzare per ricostruire lo stato dinamico.


- 70 -

L’ oggetto ha la responsabilità di gestire il proprio stato ma può delegare il Persistent Object Service per svolgere tale lavoro. Tale servizio definisce anche le interfacce affinché i Clients possano gestire la persistenza dei loro oggetti.

I componenti del servizio sono : Ø Persistent Identifier ( PID ) che descrive la locazione dei dati

persistenti di un oggetto. Ø Persistent Object ( PO ) che è un oggetto la cui persistenza è

controllata esternamente dai suoi Clients. Ø Persistent Object Manager ( POM ) che fornisce un’interfaccia

per la implementazione di operazioni persistenti di un oggetto. Ø Persistent Data Service ( PDS ) che fornisce un’ interfaccia

uniforme per le combinazioni di Protocol e Datastore. Ø Protocol che fornisce un metodo per scambiare dati con un

oggetto. Ø Datastore che fornisce un metodo per memorizzare i dati di un

oggetto indipendentemente dallo spazio di indirizzamento che contiene l’ oggetto stesso.

• Object Concurrency Control Service : definisce il modo in cui un oggetto realizza un accesso simultaneo da parte di uno o più Clients in modo tale che esso e gli oggetti a cui accede rimangano consistenti e coerenti.

• Object Externalization Service : definisce i protocolli e le convenzioni per esternalizzare e internalizzare gli oggetti; esternalizzare un oggetto significa memorizzare lo stato dell’ oggetto in un flusso di dati ( in memoria, su un disk file o ad esempio in rete ) che può esistere per un tempo arbitrario e può essere trasportata al di fuori dell’ ORB; per avere una completa portabilità i dati vengono memorizzati in un file utilizzando un formato standard. Internalizzare un oggetto significa di conseguenza creare un nuovo oggetto nello stesso o in un altro processo.

• Object Relationships Service : fornisce la capacità di poter creare, cancellare, navigare e gestire le relazioni esistenti tra gli oggetti. In particolare vengono definiti tre livelli di servizio;

1. Il livello di base che definisce le relazioni e i ruoli. 2. Il livello grafo formato dalla relazione esistente tra gli oggetti. 3. Il livello di relazioni specifiche.


- 71 -

• Object Transaction Service : fornisce il supporto per garantire che una computazione che è composta da una o più operazioni che coinvolge uno o più oggetti abbia le seguenti proprietà : Atomicità ( una transazione che si completa : commit; una che non si completa : rollback ), Consistenza, Isolamento che permette una esecuzione concorrente delle transazioni senza inconsistenze, Durabilità che non permette la perdita dei risultati. L’ infrastruttura è implementata da un insieme di servizi che permettono ai threads che eseguono le operazioni sugli oggetti all’ interno di una transazione di operare insieme armoniosamente.

• Object Security Services : la sicurezza coinvolge l’ intero sistema e riguarda la Confidenzialità ( informazione accessibile solo agli utenti autorizzati ), la Integrità ( l’ informazione è modificata solo da persone autorizzate ), la Responsabilità ( gli utenti sono responsabili delle proprie azioni ), la Disponibilità ( l’ utilizzo del sistema non può essere negato agli utenti autorizzati).

• Object Time Service : fornisce un meccanismo per la sincronizzazione dei clocks su macchine multiple presenti in un ambiente distribuito.

• Object Licensing Service : fornisce una struttura per le specifiche e la gestione delle politiche delle licenze di tutte le entità presenti e per il corretto controllo del loro utilizzo.

• Object Properties Services : tali interfacce permettono la gestione delle proprietà legate agli oggetti definendole per nome, enumerarle, attribuire loro dei valori e cancellarle.

• Object Query Service : forniscono le interfacce per le operazioni sulle collezioni di oggetti con specifiche in grado di accettarle.

• Object Change Management Services : supportano l’identificazione e la consistente evoluzione degli oggetti e comporta la gestione di versioni alternative degli oggetti ( stati istantanei di un oggetto in punti differenti del suo ciclo vitale ) per garantire che sia mantenuta la consistenza tra istanze e interfacce e per dirigere le politiche di aggiornamento.

• Object Replication Service : fornisce la replica esplicita degli oggetti in un ambiente distribuito e la gestione della consistenza delle copie.

• Object Trader Service : quando un Client desidera ottenere un riferimento ad un servizio che svolge un particolare lavoro, esso invoca una operazione di esporto fornita dall’ Object Trader Service che mette a disposizione l’ interfaccia adatta per il servizio richiesto.


- 72 -

Candidati per gli Object Services :


- 73 -

Common Facilities

Le Common Facilities riempiono lo spazio concettuale tra gli elementi definiti da CORBA e gli Object Services, e i servizi di applicazione specifici ( Application Objects ). Tali funzionalità mettono a disposizione specifiche per servizi ad un livello di astrazione più elevato e delle aree specializzate dette Vertical Market Facilities. Esempi di Common Facilities possono includere l’ email, la stampa e la composizione di documenti. Esse si possono dividere in :

Horizontal Common Facilities, condivise da più sistemi; Vertical Market Facilities, che supportano oggetti per la gestione di

interfacce verso aree precise.

La figura mostra le Common Facilities.


- 74 -

I confini che separano le Common Facilities dagli Application Objects e dagli Object Services riflettono l’ evoluzione della tecnologia del sistema.

L’ area rappresentata dalle Common Facilities è in effetti in continua evoluzione;le operazioni fornite dagli Object Services vengono utilizzate sia dalle Common Facilities che dagli Application Objects. Le Common Facilities forniscono un più alto livello di interfacce interoperabili agli Application Objects, i quali possono specializzarsi per domini di applicazioni specifiche.

Tra le tre identità deve esistere la proprietà di ereditarietà, questo per facilitare notevolmente il riuso di interfacce standard per l’interoperabilità tra oggetti e per incrementare la consistenza delle interfacce che operano tra tipi di oggetti diversi.

La figura mostra il riutilizzo degli Object Services e delle Common

Facilities. In sistemi di tipo non-object spesso viene definita una application

program interface ( API ) per mezzo di una interfaccia monolitica; l’ API delle Common Facilities è modulare e quindi estensibile e suscettibile.


- 75 -

Horizontal Common Facilities

Esse includono funzioni condivise da molti sistemi e vengono divise in quattro principali domini :

• User interface : gestisce l’ interfaccia utente mettendo a disposizione una interfaccia omogenea per tutti i sistemi operativi per rappresentare un sistema di monitoraggio e di controllo.

• Information Management : gestisce le informazioni, anche quelle codificate e mantenute in databases o in formato immagine o testo, in maniera tale da poter essere modellate, descritte, memorizzate, utilizzate, spostate e rese interagibili all’ interno di un sistema di informazioni.

• System Management : gestisce il sistema informativo fornendo un insieme di interfacce per le funzioni di amministrazione del sistema quali il monitoraggio, il controllo, la gestione della sicurezza, la configurazione e la politica necessaria per gestire le operazioni del sistema di gestione.

• Task Management : gestisce l’ automazione del lavoro sia per i processi degli utenti che per quelli del sistema.

Vertical Market Facilities

Mentre le Horizontal Common Facilities indirizzano verso esigenze universali, le Vertical Market Facilities sono standard per l’ interoperabilità in particolari aree specializzate come il commercio elettronico, la contabilità, lo sviluppo di applicazioni, la circolazione monetaria, la sicurezza e la telecomunicazione.


- 76 -

DCOM – CORBA : Confronto delle due tecnologie

“Common Object Request Broker Architecture” (CORBA), sviluppato dal “Object Management Group” (OMG) nel 1990, permette l’invocazione di metodi di oggetti distribuiti residenti ovunque sulla rete, come se fossero locali. L’implementazione di CORBA prevede l’uso di “Object Request Brokers” (ORB), collocati sia sui server sia sui client per creare e gestire le comunicazioni tra oggetti. Gli ORBS sono il nucleo dell’architettura distribuita di CORBA.

Permettono ai client di inviare richieste agli oggetti sui server senza conoscere a priori dove questi oggetti esistono, con che linguaggio sono stati scritti e che sistema operativo utilizzano. Per facilitare queste richieste per permettere l’interoperabilità tra gli ORB, le specifiche CORBA 2.0 prevedono un protocollo chiamato “Inter-ORB Protocol” che è stato subito acquisito dai principali sostenitori di CORBA: IBM , Netscape e Oracle.

Tecnicamente le due architetture si assomigliano moltissimo. Entrambi forniscono meccanismi per l’attivazione di oggetti e metodi remoti in modo trasparente rispetto ai livelli inferiori di comunicazione. Una differenza tecnica è che DCOM offre più interfacce per lo stesso oggetto. Una applicazione può chiedere a un oggetto con la chiamata QueryInterface() la lista dei metodi supportati da una particolare interfaccia. Questo concetto non esiste in CORBA. Altra differenza è la diversa gestione dei costruttori degli oggetti. In CORBA il tutto è gestito automaticamente poiché ogni oggetto è figlio di CORBA::Object che definisce un costruttore che implicitamente svolge i compiti di registrazione dell’oggetto, generazione dei riferimenti e inizializzazione. In DCOM tutto questo deve essere fatto in modo esplicito.

Limiti dell’architettura DCOM Il migliore vantaggio di DCOM è sicuramente la sua integrazione

con i sistemi operativi e le applicazioni Microsoft. Ad esempio lo sviluppo di applicazioni distribuite basate su Microsoft Internet Information Server e Microsoft Transaction Server è notevolmente facilitato dalla loro stretta integrazione con DCOM. Infatti questi due strumenti usano per le comunicazioni tra nodi DCOM e esportano molte delle loro funzionalità attraverso interfacce DCOM. Terze parti forniscono moltissime librerie per gli usi più diversi compatibili con DCOM, se non addirittura basate su questo ambiente.

Sviluppare con DCOM permette di utilizzare moltissimi


- 77 -

componenti già messi a disposizione dello sviluppatore senza doversi preoccupare dei dettagli: il sistema di sicurezza, il registry, le comunicazioni, ecc.

Invece gli svantaggi di DCOM sono principalmente tre: complessità della scrittura del codice, dipendenza dalla piattaforma Windows e problemi di sicurezza di ActiveX.

Scrivere oggetti DCOM comporta il rispetto di sintassi di dichiarazione degli oggetti e loro uso molto complessa. In effetti osservando un esempio di codice che crei e utilizzi oggetti DCOM appare in modo evidente quanto la sintassi delle chiamate sia complessa e articolata. Microsoft ha speso molte energie per creare strumenti di sviluppo che riescano a nascondere il più possibile questi problemi. Infatti sia con Visual C++ (attraverso le librerie ATL) e Visual Basic lo sviluppatore può creare oggetti DCOM in modo abbastanza semplice. Anche altri strumenti di sviluppo come Delphi di Imprise e PowerBuilder offrono valide alternative ai prodotti Microsoft per linguaggi diversi.

Essendo incluso in ogni copia di Windows NT e Windows 98, DCOM è diffusissimo ed ha una base installata sicuramente superiore ad altri ambienti di sviluppo distribuiti. Tuttavia risulta ristretto a Windows e i vari tentativi di porting su altre piattaforme non hanno visto la stessa diffusione di Windows. Per questo motivo Microsoft sta cercando di collaborare con terze parti per supportare altre piattaforme. Se DCOM riuscisse a funzionare su molte piattaforme diventerà un ambiente credibile per lo sviluppo in ambienti eterogenei.

Recentemente sono emersi alcuni limiti nella gestione della sicurezza per quanto riguarda gli oggetti ActiveX. Varie critiche sono state avanzate affinché ActiveX incorpori meccanismi di gestione della sicurezza simili a quelli degli applet Java dove i componenti scaricati ed eseguiti sul client vivono in uno spazio dove le operazioni sono strettamente sorvegliate e limitate. Inoltre gli applet possono accedere a un numero molto limitato di risorse della macchina client. In questo modo applet potenzialmente pericolosi non possono compromettere la stabilità e i dati del client. Al contrario un componente ActiveX, una volta scaricato e installato sul client, è soggetto a restrizioni molto più blande e sicuramente meno efficaci. Molti sono stati i casi riportati di falle nella gestione della sicurezza dei componenti ActiveX: potenzialmente, una pagina HTML potrebbe contenere codice Visual Basic in grado di accedere a risorse locali come il disco fisso o la memoria e di modificarne il contenuto senza l’autorizzazione del client. Microsoft ha spesso risposto a questi problemi con aggiornamenti gratuiti che tamponavano queste situazioni. Benché siano stati risolti di volta in volta questi casi si percepisce la necessità di introdurre uno schema di sicurezza più


- 78 -

affidabile. Interoperabilità

Linguaggio di supporto Il linguaggio di supporto è una parte delle capacità di

interoperabilità più critiche richieste da CORBA e DCOM. CORBA è stato disegnato per essere indipendente sia dal

linguaggio che dalla piattaforma attraverso l’ utilizzo del Linguaggio di Definizione dell’ Interfaccia ( IDL ) che permette di fornire l’ indicazione necessaria per la descrizione della piattaforma utilizzata e del linguaggio per le interfacce dei programmi applicativi ( APIs).

L’ IDL è utilizzato per definire l’ interfaccia del componente e non il suo funzionamento interno. Le interfacce IDL sono tradotte in linguaggi standard attraverso il Language Mapping.

L’ IDL è stato mappato per il linguaggio C, C++, Smalltalk, Ada, OLE ( Visual Basic, PowerBuilder, Delphi, ecc.), Java.

I benefici dell’ interoperabilità non sono comunque esenti da costi : siccome l’ IDL è nato per descrivere interfacce generalizzate, esso limita i tipi dei dati dei linguaggi utilizzati per costruire i componenti ad un minimo comune denominatore che può essere supportato da tutti i linguaggi.

Nonostante alcuni tipi di dato specifici per un certo linguaggio non sono direttamente utilizzabili, l’ IDL permette l’ utilizzo del tipo “any“ per poter aggirare questo ostacolo.

La portabilità di linguaggio di DCOM ( eterogeneità ) è basata su di uno standard binario. Affinché sia garantita la compatibilità a questo livello, è necessario che debba essere controllato il modo in cui ogni linguaggio viene tradotto in codice macchina binario.

Pur avendo anche i suoi benefici questo metodo presenta alcuni ostacoli : le differenze con cui vengono tradotti i linguaggi sono fondamentali e avere la compatibilità binaria richiede che i componenti supportino tutte le possibili variazioni di traduzioni;ci sono molti compilatori e interpreti anche per lo stesso linguaggio e una specifica compatibilità ad un livello hardware così basso crea vulnerabilità dovuta alla continua modifica dell’ hardware stesso per migliori prestazioni.

Il predecessore COM è supportato da Java, PowerBuilder, Delphi e Micro Focus COBOL, DCOM richiede comunque un supporto addizionale Microsoft.


- 79 -

Piattaforme di supporto Le piattaforme di supporto sono sempre state l’ obiettivo

principale per CORBA; gli ORBs esistono per più di 30 piattaforme e supportano perfino più sistemi operativi Microsoft di DCOM : Orbix supporta ad esempio 20 piattaforme.

DCOM ha pensato alle piattaforme di supporto solo in un secondo tempo : nel 1993, la Microsoft ha incaricato la società tedesca Software AG di portare DCOM verso altre piattaforme; questa ha portato il sistema DCOM a supportare molte varianti di Unix ma con l’ esclusione di molti componenti di DCOM stesso.

Alcune tecnologie critiche di supporto trascurate sono l’ MTS e l’MSMQ e ciò implica semplicemente che DCOM non può essere definito un middleware intraprendente e vitale.DCOM è stato anche portato verso sistemi Macintoshes e DEC Alphas con Windows NT. Attualmente si è in fase di sviluppo per Open VMS, Digital Unix, HP-UX, Solaris, IBM OS/390, IBM AIX, Linux).

Comunicazioni tra i sistemi attraverso la rete Un supporto robusto per la comunicazione permette ai sistemi di

fornire interoperabilità con altri sistemi in modo del tutto trasparente al protocollo di comunicazione.

Il modello di comunicazione utilizzato da CORBA è basato su di una forma di TCP con il nome di IIOP ( Internet Inter-ORB Protocol ), il quale permette a tutti gli ORBs di utilizzare un protocollo comune di comunicazione.

Inizialmente DCOM ha utilizzato internamente al sistema il protocollo UDP/DCOM, basato sulle specifiche modificate della RPC del DCE dell’ OSF.

DCOM ora offre un protocollo di comunicazione TCP come opzione sacrificando però molte efficienti caratteristiche.

I Servizi Comuni I Servizi formano l’ infrastruttura di base del middleware e si

accoppiano con le molteplici attività che vengono intraprese con il sistema; ad esempio un modello bancario è altamente orientato verso le transazioni e ciò richiede un sicuro Servizio di supporto.

Le attività di qualunque genere esse siano richiedono comunque la presenza contemporanea di un certo numero di Servizi chiave e ciò comporta che ci sia completa compatibilità e interoperabilità tra tutti i Servizi presenti.


- 80 -

L’ OMG si è concentrato sullo sviluppo e l’ integrazione di servizi chiave per la architettura del sistema in modo tale che questi vengano implementati in modo che siano interoperabili; ad esempio i COS (Common Object Services) dell’ IBM comprendono tutti i servizi standard dell’ OMG compatibili con DSOM e altri brokers.

I Servizi DCOM sono meno definiti da un punto di vista architetturale e implicano per l’ interoperabilità la piattaforma NT.

Affidabilità

Le transazioni L’ Object Transaction Service (OTS) di CORBA offre un insieme

di servizi di supporto per le transazioni in ambienti distribuiti; tali servizi permettono sia alle applicazioni ORB che a quelle non-ORB di partecipare alla stessa transazione in modo che le transazioni oggetto e quelle procedurali ( che supportano lo standard DTP di X/Open ), possano interoperare.

L’ OTS supporta le transazioni attraverso ORBs eterogenei in modo tale che più ORBs possano partecipare alla stessa transazione. Anche la Microsoft ha affrontato con decisione questo aspetto realizzando il supporto per le transazioni per mezzo del Microsoft Transaction Service (MTS), che è considerato essere un’ estensione di DCOM.

Messaging La trasmissione e la ricezione di messaggi in maniera affidabile,

efficace, conveniente all’ utente e conveniente al sistema, rappresentano qualità fondamentale per i sistemi distribuiti.

La convenienza per l’ utente o per il sistema comporta l’ utilizzo della tecnica di comunicazione asincrona : il sistema non deve così stare in stato di attesa finché il messaggio non è stato inviato e ricevuto ma può tranquillamente svolgere il suo lavoro. Per questo motivo l’ OMG ha recentemente indirizzato le specifiche presenti nell’ Event Service verso un modello di comunicazione più robusto, in modo tale che comprenda l’opzione di comunicazione asincrona. Formalmente DCOM non supporta le comunicazioni asincrone ma ha risposto all’ affidabilità per mezzo del Microsoft Message Queue Server ( MSMQ ), il quale risponde alle principali qualità di comunicazione richieste ma non è parte totalmente integrata con DCOM.

Il prodotto EntireX della Software AG, piattaforma di DCOM, è integrato con il servizio proprietario EntireX Message Broker che non si


- 81 -

appoggia a MSMG e permette la memorizzazione persistente di messaggi per rendere possibile la comunicazione asincrona tra clients e servers.

La Sicurezza Il Security Service di CORBA rappresenta un’ insieme delle più

comprensive specifiche disponibili per ambienti distribuiti. Queste coprono in modo approfondito ogni aspetto che riguarda la sicurezza, la integrità, la responsabilità, la disponibilità e la riservatezza dei dati.

Il Security Service riconosce la necessità dell’ esistenza di differenti livelli di sicurezza e ne definisce tre (0-2).

Gli ORBs differiscono però largamente nel loro supporto per la sicurezza; per esempio, il DAIS di ICL è stato il primo ORB a fornire una sicurezza conforme agli standards GSS API e Kerberos.

L’ Orbix fornisce sia lo standard SSL_IIOP (sicurezza delle comunicazioni in Internet) che l’ implementazione del primo livello di sicurezza definito dal Security Service di CORBA. É in fase di sviluppo il primo ORB che supporta il secondo livello di sicurezza definito da CORBA.

DCOM utilizza invece i meccanismi NT come supporto alla sicurezza; la versione 3.5 di NT è stata stimata di livello C2 dal proprio Centro Nazionale per la Sicurezza e assicura una comprensibile gamma di controlli come l’ accesso riservato, il servizio di autenticazione e di auditing. DCOM fornisce inoltre una CriptoAPI per attivare un sistema avanzato di sicurezza sull’ informazione.Questo servizio richiede il supporto di un Cryptographic Service Provider (CSP) che è fornito con NT. La combinazione di NT, MTS, e COM fornisce sicuramente un ambiente di sicurezza molto sviluppato.

Il Servizio di Directory L’ OMG ha specificato il Naming Service per permettere ad un

componente di CORBA di consultare un servizio per nome; esso mantiene la traccia della locazione dei servizi chiave nello spazio distribuito della rete.

Questo meccanismo permette di abbassare il peso di ogni applicazione grazie alla trasparenza di locazione. VisiBroker fornisce un servizio tollerante ai guasti e persistente (sopravvive ad eventi di caduta improvvisa di sistema) .

La risposta della Microsoft a questa necessità è chiamata Active Directory Service (ADS) che combina le migliori caratteristiche di X.500 e DNS e fornisce un’interfaccia standard (ADSI) .


- 82 -

Tolleranza ai guasti Le specifiche di CORBA non supportano direttamente i servizi di

tolleranza ai guasti, tuttavia molti ORB sono realizzati in modo da fornire questo tipo di servizi.

Ad esempio il Visibroker della Visigenic fornisce un tipo di supporto simmetrico che permette di legarsi automaticamente ad un altro object server su un diverso host, nel caso di un fallimento del servizio.

La maggior parte degli ORBs forniscono un semplice meccanismo di timeout per poter determinare la caduta o la disconnessione dei clients, anche se questo approccio non è sufficiente a coprire significativamente tutti i possibili casi di guasti presenti con le applicazioni.

DCOM supporta la tolleranza ai guasti utilizzando i contatori di referenza aumentati da messaggi di “tenuta in vita” come un componente essenziale del ciclo di vita oggetto DCOM.

Questo meccanismo richiede il successo della trasmissione e ricezione di un singolo segnale ogni due minuti tra un client e il server.

Se tre segnali consecutivi vengono perduti il server dichiara la caduta del client e decrementa il contatore. I problemi per DCOM sono nella configurazione esatta dei tempi tra tutti i componenti e se uno di questi entra in loop perché il messaggio sarà sempre inviato. Inoltre questo approccio utilizza significanti risorse di rete per un largo numero di connessioni.

Performance

Scalabilità La performance del middleware dipende anche dal modo in cui

viene sviluppata la abilità di esecuzione quando la misura del problema aumenta ( scalabilità ). Ad esempio la granularità dei componenti è un ottimo approccio per la valutazione del grado di esecuzione corrente.

CORBA non indirizza specifici servizi per la scalabilità, al contrario gli ORBs forniscono librerie di threads adatte per ogni modello di sistema operativo; questo permette ai clients, agli objects e anche agli specifici metodi di chiamata di un oggetto di creare i threads necessari. Inoltre gli ORBs forniscono meccanismi di regolazione per ottimizzare l’esecuzione per specifiche situazioni.

DCOM offre meccanismi di scalabilità simili, i quali come per


- 83 -

CORBA richiedono dettagliate conoscenze delle interazioni client/server per essere implementati; non esiste quindi la caratteristica di trasparenza.

Maturità del prodotto

Molti ORBs sono giunti alla terza generazione di sviluppo e si vedono così parecchi servizi presenti in prodotti differenti e sebbene le specifiche OMG sono state disegnate esplicitamente per assicurare un’ ottima integrazione di tali servizi, nessun singolo venditore li ha in realtà portati insieme verso la stessa conformità. Nonostante ciò gli ORBs sono sempre più spesso utilizzati per sviluppare sistemi per l’industria in generale, includendo quella delle telecomunicazioni, l’ aerospaziale e quella finanziaria. Anche per quanto riguarda DCOM, la presenza dei servizi detti predatori, Falcon, Viper, Wolfpack e Active Directory, è indice di una situazione non completamente integrata ( anche solo per l’ ambiente NT ), anche per il fatto che questi servizi non sono parte esplicita del sistema DCOM. Da ciò partono gli sforzi della Microsoft verso lo sviluppo di un’ ottima integrazione dei prodotti su piattaforme NT a basso costo .


- 84 -

Rete di computer e sistema distribuito

Con l’ espressione rete di computer si intende un insieme interconnesso di calcolatori autonomi in grado di scambiarsi informazioni.

Con una rete un utente deve collegarsi ad una macchina, sottoporre ad esecuzione lavori remoti, trasferire files e perfino gestire la rete stessa.

In un ambiente con un sistema distribuito e’ il sistema operativo che svolge tutti i compiti in modo automatico, senza la necessità che l’utente ne sia a conoscenza.

Consideriamo una tipica LAN ( Local Area Network : rete locale ) composta da molte workstations e da uno o più servers:

Client Le singole workstations denominate client hanno un proprio

sistema operativo e un insieme di programmi e applicazioni che gestiscono un set di funzioni che includono:

• interagire con l’ utente tramite un interfaccia grafico

• preparare un’ interfaccia standard per le richieste di accesso ai servers

• comunicare ai servers tramite un’ interfaccia di comunicazione


- 85 -

• preparare ad uso utente una rappresentazione dei dati ricevuti dai servers.

Server Un server fornisce uno o più servizi: dalla stampa alla gestione del

file system, dalla gestione di una base di dati fino alla realizzazione della grafica.

I server possono avere processi e comunicazioni condivise senza interazioni con i client.

I server creano quella comunicazione con i client necessaria allo sviluppo di applicazioni distribuite, programmi che possono risiedere su una o più workstations che puntano ad esempio collettivamente verso obbiettivi comuni.

Componenti di una rete Client/Server:


- 86 -

Servizi Distribuiti

I servizi distribuiti devono comprendere servizi per la sicurezza come ad esempio l’ autorizzazione di accesso alle risorse e la protezione dei dati; ogni workstation richiede una sicurezza locale per proteggere il proprio sistema da virus o con il fine di codificare e decodificare dati trasmessi.

In ogni client e in ogni server per ricevere e mandare servizi che possono riguardare anche la sicurezza e’ necessario avere un codice per la sicurezza.

Server Servizio Security Server Provvede ai servizi di Sicurezza per proteggere i dati,

l’ accesso alle risorse,l’ identificazione utente, l’ accesso ai codici,alle passwords,.....

Directory Server Provvede alla locazione di utenti e risorse. Time Server Sincronizza il tempo nella rete. File Server e Database Server

Provvede l’ accesso ai files e alle basi di dati.

Communications Server

Provvede all’ accesso di Server Remoti.

Print Server Provvede ai servizi di stampa. Management Server

Provvede all’ organizzazione della rete Client/Server compresa la configurazione, la sua manutenzione e le sue prestazioni.

Rischi per la sicurezza Possono essere divisi in tre grandi categorie :

• violazione di dati riservati


- 87 -

• accessi non autorizzati a sistemi riservati

• rifiuto non previsto alla richiesta di un certo servizio.

Violazione di dati riservati Una violazione di questo tipo implica che una persona non

autorizzata ha avuto accesso a dati strettamente privati all’ interno del sistema o durante la loro trasmissione; questo e’ dovuto a scarso livello di protezione generale o ad uno schema di codifica e decodifica dati non sufficientemente protettivo.

Spesso può capitare che le chiavi di tale schema vengano ad esempio distribuite agli utenti attraverso la rete stessa , aumentando così i rischi di intercettazione, manomissione o utilizzo di tali dati.

Accessi non autorizzati Accessi non autorizzati ad un sistema possono essere dovuti ad un

meccanismo inappropriato di verifica delle passwords degli utenti e dei programmi, o addirittura per l’ uso di codici rubati.

Possibile rimedio : utilizzo di passwords che variano al passare del tempo.

La Token Card Per poter avere l’ accesso garantito ad un certo sistema l’ utente e’

in possesso di una token card ( della grandezza di una carta di credito ) che contiene un processore, il quale genera un nuovo codice a intervalli regolari.

Ogni Token card genera un’ unica sequenza di codici grazie all’inserimento di un PIN ( numero di identificazione personale ); tale codice e’ sincronizzato con quello generato dal software del Security Server che e’ in collegamento con la workstation alla quale si cerca di accedere.

L’ applicazione client riceve così un identificatore ID dall’ utente e la password a tempo dal Server per la sicurezza.

Rifiuto di un servizio E’ l’ interesse a danneggiare l’ intero sistema, degradandone le

prestazioni, o riducendone le risorse ; questo scopo viene spesso raggiunto per mezzo di viruses, o l’ installazione di software nel sistema che si attiva ad un tempo determinato.

Sicurezza nelle applicazioni distribuite In un sistema Client/Server ci sono molte applicazioni condivise


- 88 -

che necessitano un controllo accurato per mantenere una certa integrità dei dati e per una elevata riservatezza.

Un’ applicazione client in una certa workstation C può ad esempio richiedere l’ uso di certi servizi applicativi collocati su di un server S.

Questo processo e’ realizzato per mezzo di un programma

applicativo distribuito che consiste in un codice che risiede in C e uno che risiede in S. La comunicazione tra i due codici passa attraverso un API di sicurezza (API : application program interface).

Per accedere al Server della sicurezza, l’ applicazione distribuita in C esegue una chiamata API, questa e’ pensata come se fosse una chiamata ad una procedura di sistema che esegue un codice ad alto livello di sicurezza presente in C. Questo realizza una connessione con il Security Server che offre così l’ applicazione di sicurezza richiesta dalla chiamata ,ad esempio un processo che codifica dei dati da trasferire da C a S.

La stessa procedura avviene nel server S, quindi con la chiamata API, una volta che questo riceve i dati trasferiti. Il Security Server governa il modo in cui questi dati vengono codificati. L’ API deve poter realizzare la sua funzione attraverso diversi sistemi di codifica dei dati :

o deve mantenere l’ integrità dei dati; o deve essere indipendente dal protocollo di comunicazione

utilizzato.


- 89 -

-

Servizi di sicurezza OSF DCE

OSF (Open software Foundation ) e’ un’ organizzazione sostenuta da centri di ricerca, università, agenzie di governo, utenti, compagnie di sistemi e software; OSF ha sviluppato ambienti di computer distribuiti indipendenti dalla eterogeneità dei sistemi utilizzati.

Ha sviluppato un sistema UNIX (OSF/1), un’ interfaccia utente grafico (MOTIF) e l’ ambiente distribuito di computer DCE che fornisce un insieme integrato di servizi di sistema per ambienti eterogenei distribuiti.

DCE - Distribuited Computing Environment

DCE indirizza il requisito dell’ interoperabilità dei servizi di sistema attraverso un ambiente di computer distribuito.Gli utenti finali e le varie compagnie hanno la necessità di assimilare hardware e software forniti da diversi venditori ;l’ obiettivo del DCE e’ quello di fornire un insieme di servizi di sistema omogeneo per l’ uso e lo sviluppo di applicazioni in un ambiente distribuito. DCE consiste di molti componenti.

Chiamata di procedura remota


- 90 -

La chiamata di procedura remota e’ usata per la comunicazione tra

i vari componenti di una applicazione distribuita. Usando la RPC un programma può chiamarne un altro indipendentemente dalla sua locazione.

RPC estende quindi la locale chiamata di procedura all’ ambiente distribuito in maniera tale che risulti del tutto trasparente all’ utente.

Un Client che invia un messaggio ad un Server e riceve una risposta e’ come un programma ad esempio applicativo, che chiama una procedura e gli fornisce un risultato.In tutti e due i casi, il chiamante aspetta la terminazione dell’ azione da lui avviata per avere a disposizione il risultato.

L’ efficienza del meccanismo e’ essenzialmente dovuta al fatto che la comunicazione Client / Server diventa una semplice chiamata a procedura e non una funzione di I/O oppure una funzione di interruzione.

Tutte le implementazioni necessarie all’ uso della rete sono nascoste al programma applicativo, vengono poste in procedure locali come ad esempio la read e sono chiamate stub.

Le operazioni eseguite da una RPC si possono riassumere in dieci passi:

1. Il processo Client invoca con una normale chiamata locale la procedura stub.

2. La stub del Client raccoglie i parametri e li sistema in un messaggio tramite la operazione parameter marshalling preparandoli così per il trasporto.

3. L’ entità di trasporto si occupa del trasferimento vero e proprio dei dati nella rete tenendo conto dei protocolli utilizzati.

4. Il messaggio arriva al Server, l’ entità di trasporto lo passa alla stub del Server che effettua l’ operazione inversa alla sistemazione dei parametri.

5. La stub del Server attiva il nuovo processo che non si accorge dell’ attivazione remota.

6. Finita la computazione viene riportato il risultato al chiamante. 7. La stub sistema il risultato e lo prepara al trasporto passandolo

all’ entità di trasporto. 8. La risposta fa ritorno al Client. 9. Viene passata alla sua stub.


- 91 -

10. La stub del Client fa ritorno alla sua chiamante passandogli il risultato della computazione. Viene fornita alla procedura del Client l’ illusione di effettuare una

chiamata diretta alla procedura del Server creando così un meccanismo trasparente.

Passi dell’esecuzione di una RPC

Directory Il componente directory fornisce immagazzinamento e accesso

all’informazioni degli oggetti nella rete, che possono essere workstations, utenti o files. E’ indipendente dalla locazione e dal sistema.

Servizio di tempo Fornisce la sincronizzazione del tempo attraverso tutti i sistemi di

computazione presenti nella rete. La sincronizzazione del tempo assicura l’ordine esatto con il quale devono essere eseguiti gli eventi, calcola l’intervallo esatto tra gli eventi e permette la schedulazione degli eventi ai tempi specificati.

Sistema di file distribuito Estende il modello locale di file system alla rete distribuita

permettendo così il corretto accesso ai files attraverso la rete stessa. L’ integrazione dei computers permette l’utilizzo di risorse

attraverso la rete, che sono risorse di stampa,di accesso a database o a files. La componente di amministrazione fornisce un completo servizio globale. I threads permettono un processo parallelo di sequenze di esecuzioni multiple.


- 92 -

Sicurezza DCE

Il componente alla sicurezza e’ realizzato per prevenire accessi non autorizzati alle risorse dell’ ambiente distribuito.E’ basato su tre principali requisiti: 1. L’ identificazione dell’ utente deve basarsi sull’ utilizzo della

password; tale mezzo e’ realizzato con alti vincoli di garanzia per non permettere la sua esposizione durante la trasmissione.

2. Agli utenti dovrebbe essere concessa la possibilità di accedere a qualsiasi servizio della rete resogli disponibile, con un solo collegamento. Una volta che l’ utente e’ stato autorizzato ad accedere al sistema dovrebbe immediatamente poter utilizzare tutte le applicazioni fornite senza la necessità di essere riconosciuto e verificato altre volte.

3. Lo schema di sicurezza dovrebbe fornire agli utenti un accesso al giusto livello operativo.Inoltre dovrebbe essere possibile fare selezione sui permessi o poter negare accessi a certe operazioni individuali.

Componenti della sicurezza DCE La sicurezza DCE utilizza il concetto di cella.Una cella e’ l’ unità

base di ogni tipo di operazione che viene attivata durante l’ utilizzo dell’ ambiente distribuito e ognuna di essa fa riferimento ad un personale servizio di sicurezza.

Autenticazione L’ utente identifica il suo permesso di accesso al sistema

registrando un ID ( identificatore ) e una password e lo schema per la sicurezza gli restituisce una certa struttura dati codificata (Server della sicurezza ) detta ticket.

Il ticket e’ la chiave di accesso per gli utenti nell’ utilizzo delle applicazioni o per la comunicazione per lo scambio di informazioni tra i Servers stessi. Durante il processo di registrazione l’ utente o il server riceve dal Server della Sicurezza un PAC ( Privilege Attribute Certificate ).

Per iniziare, la funzione dedicata del DCE manda una richiesta al Security Server ( che fa sempre parte del Server della sicurezza ) per un ticket di servizio privilegiato; alla sua ricevuta il codice dedicato del DCE fa quindi richiesta al Privilege Server di un PAC.


- 93 -

Il Privilege Server crea il PAC e lo manda all’ utente ed e’ utilizzato dal processo attivo per l’identificazione.

RPC Autenticata Il Client che deve utilizzare un’ applicazione disponibile in rete

manda così al Server che la gestisce il ticket e quest’ ultimo ottiene una chiave di accesso condivisa.Il Client la utilizza per codificare una parte del codice della RPC destinata al Server e il Server la utilizza per decodificare tale codice.

Autorizzazione Il processo di autorizzazione parte appena terminato quello di

autenticazione (che utilizza le passwords ); identifica il tipo di macchina e di conseguenza tutti i suoi privilegi.

Il Server della sicurezza crea il PAC utilizzando i registri forniti dal DCE che contengono entrate per clients,servers, accounts, gruppi e organizzazioni.

Quando il PAC viene creato esso contiene le identità di tutti i gruppi ai quali l’ utente appartiene.


- 94 -

Crittografia

La cifratura per rendere i dati leggibili solo al destinatario di questi e’ utilizzabile per coprire i seguenti servizi di sicurezza: 1. Protezione dei dati contro l’ accesso a persone non autorizzate. 2. Esclusione d’ intervento su messaggi da parte di persone non

autorizzate. 3. Verifica del mittente del messaggio. 4. Possibilità per gli utenti di inviare messaggi firmati.

Il collocamento della cifratura ad esempio nel modello standard

OSI ( Open Systems Interconnection ) dell’ ISO ( International Standards Organization ) può essere effettuato nello strato fisico, di trasporto o di presentazione.

Nello strato fisico e’ necessaria un’ unità di cifratura tra ciascun

calcolatore ed il mezzo fisico; si realizza la cifratura di collegamento quando ciascun bit in uscita e’ cifrato e ciascun bit in entrata e’ decifrato.

Nello strato di trasporto e’ necessaria la cifratura dell’ intera sessione, realizzando cos anche in questo caso una struttura poco conveniente.

Nello strato di presentazione e’ invece presente la necessità di


- 95 -

realizzare la cifratura solamente delle strutture dati o dei campi che ne hanno bisogno, riducendo così drasticamente l’ appesantimento dovuto all’ elaborazione.

Lo strato di presentazione ha il compito di gestire il processo con il quale gli utenti si accordano sul contesto da utilizzare per la rappresentazione delle strutture dati.

Il modello di cifratura

DES (Data Encryption Standard)

Per avere un modello standard ufficiale per le informazioni non classificate e’ stato implementato in Hardware (costi bassi ed alta velocità) l’ algoritmo di cifratura noto come Data Encryption Standard o DES.

Il testo in chiaro viene cifrato in blocchi di 64 bit per poter produrre il testo cifrato sempre di 64 bit.

L’ algoritmo e’ parametrizzato da una chiave di 54 bit ed e’ formalizzato da 19 stati distinti, per mezzo dei quali viene manipolata l’ informazione iniziale per renderla protetta alla lettura da parte di utenti non autorizzati.

La stessa chiave viene poi riutilizzata per la decifrazione del messaggio.

Distribuzione delle chiavi

Nasce dunque il problema della distribuzione di tali chiavi con un certo livello di sicurezza, perché tale chiave deve essere la medesima sia


- 96 -

per il trasmettitore ad esempio di un messaggio che per il suo o i suoi riceventi.

Una soluzione possibile al problema e’ l’ impiego di una gerarchia di chiavi: per mezzo di una chiave principale vengono cifrate e spedite attraverso la rete le chiavi locali che a loro volta servono per cifrare chiavi di sessione per la comunicazione di processi applicativi degli utenti.

La sicurezza si realizza in questo modo con il poco frequente utilizzo delle chiavi ad alto livello che sono il mezzo di accesso all’ intero sistema.

Un altro metodo per avere una comunicazione ragionevolmente sicura e’ quello di Merkle che utilizza un crittogramma detto puzzle che deve essere risolto dal ricevente per poter stabilire con il mittente la chiave di lettura e codifica dei dati.

Questo metodo richiede però un grande sforzo computazionale e un utilizzo di una quantità di calcolo utilizzabile per altri fini.

Crittografia con chiave pubblica ( Diffie e Hellman )

Si tratta dell’ impiego di un algoritmo di cifratura E e uno di decifrazione D, in modo che valgano i seguenti requisiti :

1 D ( E (M) )=M dove M e’ il messaggio. 2 Non e’ possibile dedurre D da E. 3 E non può essere svelato per mezzo di un testo in chiaro. E può e deve essere di pubblico dominio. Ogni utente realizza così

i 2 algoritmi E e D, ponendo quello di cifratura in un file di libero accesso agli utenti della rete.

Per mezzo della crittografia con chiave pubblica e’ così possibile eseguire l’ autenticazione in un sistema interconnesso con un alto livello di sicurezza, senza il rischio di esporre l’ utente, che desidera usufruire di un servizio, ad un’ intercettazione passiva e senza il bisogno, da parte del Server, di dover memorizzare tutte le passwords-utenti necessarie.

Problema di Protezione

L’ obiettivo di proteggere informazioni in un sistema operativo e’ presentabile in vari problemi, alcuni dei quali possono non avere una facile soluzione.

Modifiche : quando un utente passa un oggetto come argomento ad


- 97 -

una procedura, può essere necessario che l’ oggetto non venga modificato. Possiamo implementare la restrizione passando anche un diritto di accesso che non contenga la funzione write. Questa protezione realizzata dall’ utente può però essere facilmente evitata : i diritti di accesso di una procedura sono indipendenti e addirittura possono essere superiori a quelli del processo chiamante. Questo e’ ciò che accade ad esempio con il sistema di protezione Hydra, che permette un’ amplificazione dei diritti delle procedure chiamate, che possono in questo modo accedere al tipo di rappresentazione delle variabili di un tipo di dati astratto definito nel processo chiamante. I diritti tenuti da un processo possono quindi variare dinamicamente per la corretta computazione legata all’ obiettivo finale da raggiungere e un sistema basato sulla correzione dinamica dei diritti, e’ necessario per avere una fondamentale consistenza dei dati. Per non avere errori a livello software o hardware il sistema Hydra attua le restrizioni di amplificazione necessarie per il mantenimento dell’ integrità dell’ oggetto.

• Limitazione alla propagazione dei diritti di accesso : Quando un utente vuole condividere l’ accesso ad un oggetto da

lui creato con gli altri utenti e in maniera tale che tali diritti non possano essere rilasciati ad eventuali altri utenti non autorizzati, deve realizzare la protezione associando la copia dello oggetto e i suoi diritti solamente a se stesso. Solamente con la sua identificazione ID si ha accesso a tutti i diritti.

• Revoca :

Un utente o un sistema può avere la necessità di revocare i diritti di accesso di un oggetto; tale revoca può essere totale o parziale, con azione immediata o ritardata, selettiva o generale, temporanea o permanente.

• Cavallo di Troia :

Molti sistemi permettono a certi programmi scritti da utenti di essere utilizzati da altri utenti, ma se questi programmi vengono eseguiti nel dominio che fornisce i diritti di accesso dell’ utente che li sta eseguendo, un segmento di codice detto cavallo di Troia può danneggiarli modificando tale ambiente.

• Sospetto reciproco : Un programma applicativo fornito in rete utilizzabile da molti

utenti può presentare al momento della sua esecuzione dei malfunzionamenti che possono danneggiare il programma stesso o i dati dell’ utente; una soluzione possibile e’ quella di avere un corretto controllo delle risorse del proprio sistema utilizzate da ciascun processo in stato attivo.

• Sconfinamento :


- 98 -

Il problema del sconfinamento si ha quando dell’ informazione contenuta in un oggetto sconfina dal suo ambiente di esecuzione.

• Trappola : Un sistemista potrebbe generare delle trappole nel codice del suo

programma o sistema ad esempio con un’ errata procedura di controllo di identificazione utenti o peggio ancora in errori contenuti in un certo compilatore nascondendoli così al codice sorgente. E’ necessario a volte dover controllare milioni di linee di codice.

• Vermi e Virus :

Nei sistemi operativi e’ utilizzato il meccanismo con il quale un processo può creare altri processi; un verme e’ un processo si basa proprio su questo concetto,esso e’ un processo che riproduce se stesso in modo tale da degradare le risorse del sistema. Propagato in rete può causare velocemente la sua caduta. Un Virus e’ invece una porzione di codice legato ad altri programmi si può propagare copiandosi in altre applicazioni ed entra in azione in concomitanza con certi eventi prestabiliti. Possono danneggiare i dati su disco o nella memoria creando grossi problemi al sistema.


- 99 -

Bibliografia

[Whitepapers] Zhonghua Yang and Keith Duddy CORBA: A Platform for Distributed Object Computing

Steve Vinoski (Helwett Pakard Company) CORBA: Integrating Diverse Applications whithin distributed Heteregeneous Environments

Microsoft Server Operating System A Technology Overview Microsoft DCOM Architecture White Paper Microsoft DCOM Technical Overview Microsoft DCOM—Cariplo Home Banking Over The Internet Vijay Ahuja (Manager, Network Security Products, IBM Corporation.) Network & Internet SECURITY Andrew S. Tanenbaum. Computer Networks Abraham Silberschatz.


- 100 -

Operating System Concepts

[Princibali Risorse WWW] Sito Microsoft su COM/DCOM http://www.microsoft.com/com/ Sito Object Managemet Group su CORBA http://www.omg.org/

dcom corba - unimi.ithomes.di.unimi.it/piuri/pages/didattica/so/mat/distributed/dcom_corba.… ·...

Documents