Quelle chiamate named pipe e mailslot sono API di programmazione sviluppate in origine da Microsoft per OS/2 LAN Manager e successivamente portate su NT. La prima consente ai programmi posti su computer diversi di instaurare un link affidabile di comunicazione bidirezionale. I server named pipe chiamano la funzione CreateNamedPipe per definire una pipe (canale) sul computer locale, mentre i client named pipe aprono una connessione con la pipe del server, specificandone il nome alla funzione Win32 CreateFile. Quando la connessione è stata instaurata, il client e il server possono usare le routine standard di NT per l'I/O dei file WriteFile e ReadFile per scambiare i dati. Le named pipe sono API di programmazione di NT molto use, anche se di solito le applicazioni che le utilizzano non possono essere portate su Windows 98 e Windows 95, dal momento che questi sistemi operativi non implementano nessuna API server named pipe.
Mailslot offre ai programmi una funzionalità broadcast senza connessione, non affidabile. Analogamente ai server named pipe, quelli mailslot definiscono un mail slot (slot di posta) usando la API CreateMailSlot. I client mailslot possono aprire il mail slot del server e inviare attraverso di esso i messaggi server. Il servizio mailslot non è tuttavia affidabile, dal momento che il server potrebbe non ricevere i messaggi inviati dai client. Mailslot supporta anche la trasmissione dei messaggi; con quest'ultima, quando due o più server mailslot del dominio creano un mail slot con lo stesso nome, ricevono i messaggi inviati dai client sul nome di quel mail slot. Quale applicazione potrebbe mai fare uso di un meccanismo di broadcast inaffidabile? Un esempio è costituito dal servizio di sincronizzazione dell'ora, che potrebbe trasmettere per tutto il dominio, ogni pochi secondi, l'ora esatta. La ricezione del messaggio con quest'ultima non risulta tuttavia cruciale per tutti i computer della rete.
Fino agli anni Novanta, la API di programmazione più utilizzata in assoluto sui personal computer è stata quella NetBIOS, che consente sia la comunicazione orientata alle connessioni affidabili, sia la comunicazione inaffidabile e priva di connessione. Anche se NT supporta NetBIOS per le proprie applicazioni legacy, Microsoft ne scoraggia tuttavia l'utilizzo da parte degli sviluppatori, dal momento che altre API (per esempio quelle named pipe e RPC) sono molto più flessibili e portabili.
Winsock costituisce l'implementazione di Microsoft di BSD Socket, una API di programmazione che è diventata uno standard da quando i sistemi Unix hanno iniziato a comunicare via Internet durante gli anni Ottanta e Novanta. Il supporto di NT per i socket rende relativamente semplice il compito di portare le applicazioni di networking Unix sul sistema operativo di Microsoft. Winsock offre la maggior parte delle funzionalità di BSD Socket, insieme ad alcuni miglioramenti apportati da Microsoft, in continua evoluzione; dispone di una modalità chiamata streams per la comunicazione orientata alle connessioni affidabili, e di un'altra chiamata datagrams per la comunicazione inaffidabile priva di connessione.
Quello chiamato RPC è uno standard per la programmazione di rete, sviluppato originariamente da Sun Microsystems. L'ente Open Software Foundation (attualmente The Open Group) lo ha inserito nello standard DCE (Distributed Computing Environment) per il computing distribuito. Un aspetto particolarmente interessante dell'implementazione di RPC effettuata da NT è costituito dalla particolarità che queste chiamate utilizzano altre API di programmazione di rete. Per questo motivo, nel sistema operativo di Microsoft RPC è un vero strato API di programmazione, che sta al di sopra di quelli named pipe, Winsock, NetBIOS e Message Queue.
I programmatori che sviluppano le applicazioni client/server RPC devono definire le funzioni implementate dal server; il programma client viene scritto come se potesse invocare direttamente le funzioni del server. Dietro le quinte, una libreria posta sul lato client preleva i parametri passati dal programma alla funzione server e li pone all'interno di un messaggio. Questo messaggio viene trasmesso al server, il quale dispone di una libreria che estrae i parametri dai suoi contenuti e li passa alla funzione del server. Quando quest'ultima termina la propria esecuzione, gli eventuali parametri restituiti utilizzano il medesimo processo quando vengono inviati dal server al client. Il fatto che la pacchettizzazione e de-pacchettizzazione dei parametri (chiamate rispettivamente marshalling e unmarshalling), oltre alla trasmissione del messaggio, risultino nascoste allo sviluppatore rende particolarmente attraente la API RPC. Il compilatore MIDL (Microsoft Interface Definition Language) crea automaticamente le librerie client e server per lo sviluppatore, sulla base delle definizioni delle funzioni che vengono fornite da quest'ultimo.
La API DDE (Dynamic Data Exchange) consente alle applicazioni Windows di comunicare reciprocamente attraverso particolari tipi di messaggi. Il sistema operativo di Microsoft utilizza lo schema DDE a partire dalla versione 2.x. Lo schema NetDDE (Network DDE) consente alle applicazioni Windows che comunicano attraverso la API DDE di essere localizzate su computer differenti. Anche se non si tratta di una API generica di comunicazione, dal momento che la base per le connessioni DDE è costituita dalle finestre grafiche, è sempre particolarmente comodo averla a disposizione.
La comunicazione SMB costituisce la base per la condivisione dei file client e server di NT (nota rispettivamente come servizi Workstation e Server). Microsoft ha recentemente migliorato la API SMB, offrendola sotto forma di API CIFS (Common Internet File System), nel tentativo di promuovere lo schema SMB quale standard per la condivisione dei file di rete, in grado di competere direttamente con il sistema Web NFS (Network File System) sviluppato da Sun Microsystems. Di solito, l'utilizzo della API SMB risulta trasparente per le applicazioni, le quali accedono ai file di rete specificando i nomi relativi alle lettere dei file locali, mappati su un punto condivisione del server nel file system remoto. Per questo motivo, le API standard per l'apertura, la lettura e la scrittura dei file consentono all'applicazione l'accesso ai file remoti. Il metodo UNC (Uniform Naming Convention) permette ai programmi di identificare direttamente i nomi dei file relativi ai punti di condivisione del computer remoto.
E' la successiva API di rete incorporata in NT, DCOM, quella alla quale Microsoft ha dedicato l'attenzione maggiore negli ultimi anni. La API COM di Microsoft consente alle applicazioni di essere formate da vari componenti, costituiti da moduli auto-contenuti e sostituibili. Gli oggetti COM esportano un'interfaccia OO (Object Oriented) verso i metodi, in modo da manipolare i dati posti all'interno dell'oggetto stesso. Dal momento che gli oggetti COM sono caratterizzati da interfacce ben definite, gli sviluppatori possono implementarne di nuovi al fine di estendere le interfacce già esistenti e di aggiornare dinamicamente le applicazioni con il nuovo supporto. Lo schema DCOM consente ai componenti delle applicazioni di risiedere su computer differenti; ciò significa che le applicazioni non si devono preoccupare del fatto che un certo oggetto COM debba trovarsi sul computer locale, mentre un altro potrebbe essere disponibile attraverso la LAN. Questo schema offre quindi la trasparenza della posizione, che semplifica lo sviluppo delle applicazioni distribuite. Analogamente a quella RPC, anche la API DCOM non è auto-contenuta, ma si basa sulla prima per compiere le proprie operazioni. COM+, la versione di COM che sarà inclusa in Windows 2000, permetterà di facilitare ulteriormente il lavoro degli sviluppatori nello scrivere le applicazioni basate su COM, dal momento che prevede un compilatore specifico al linguaggio e il supporto runtime per gli oggetti COM.
Microsoft ha introdotto nel NT 4.0 Option Pack la sua API di rete più recente, Message Queue: particolarmente simile a RPC, si basa anch'essa sullo scambio di messaggi client/server. Mentre RPC è un'interfaccia sincrona (prima di passare ad altre operazioni, il client deve attendere fino a quando il server ha terminato di elaborare la sua richiesta), le Message Queue sono asincrone. Per esempio, un client può inviare a un server molte richieste, che vengono inserite in una coda. Mentre il server elabora il più rapidamente possibile in sequenza le richieste del client, quest'ultimo può compiere altre operazioni. La API Message Queue è in grado di compiere transazioni affidabili, quando viene utilizzata con il server MTS (Microsoft Transaction Server).
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
