UNIVERSITÀ DI PARMA
DIPARTIMENTO DI SCIENZE MATEMATICHE, FISICHE E INFORMATICHE

Consente di eseguire chiamate a procedure remote nello stesso modo utilizzato per chiamate a procedure locali. Il client esegue una chiamata allo “stub del client” che è un adattatore con lo stesso nome della procedura del server. Lo stub del client si occupa di contattare lo stub del server e passare al client il valore di ritorno.

La comunicazione tra gli stub consiste in

• un messaggio di richiesta in cui i parametri vengono rappresentati in un formato indipendente dall’architettura dell’host (marshalling)
• Un messaggio di risposta con il valore di ritorno

Per poter trasferire i dati attraverso la rete devono essere codificati/decodificati mediante una procedura denominata “Argument Marshalling” mentre la decofidica e' detta “Unmarshalling” (terminologia proveniente dal protocollo SunRPC).

• I numeri reali. Non tutti i calcolatori utilizzano il formato standard IEEE754.
• I numeri interi a 16 o 32 bit possono essere rappresenti sull'host in formato little endian o big endian.
• Le strutture possono avere padding arbitrari tra i campi che la compongono.

Per CSV (Comma Separated Value) si intende una codifica dei dati semplici in formato ASCII separati da un carattere speciale ( , ; : ecc.)

Le codifiche di tipo TLV (Type-Length-Value) consentono codifiche piu' complesse in cui ogni dato ha una propria codifica simbolica (Type), una dimensione in byte (Length) e un valore (Value). Vedi ad esempio l'extersion Header di IPv6.

Per rappresentazioni piu' complesse i dati possono essere accompagnati da Metadati mediante Marcatori (Tag) come ad esempio “Tipo di dato”, “lunghezza del dato”, “architettura” .

• XDR

L'External Data Representation (XDR) Fornisce supporto completo dei tipi di dati del linguaggio C (ad eccezione dei puntatori a funzione) Non usa marcatori Principali utilizzi: SunRPC e Ganglia

• ASN.1

Abstract Syntax Notation One (ASN.1) e' uno standard ISO che definisce fra altre cose la rappresentazione dei dati in rete (BER). Fornisce supporto completo dei tipi di dati del linguaggio C (ad eccezione dei puntatori a funzione) Usa marcatori e gli Stub possono essere compilati o interpretati. Principali utilizzi: SNMP (Simple Network Management Protocol) e LDAP.

• XML Schema

Sono codifiche basate su marcatori rappresentati in XML Usati da XMLRPC e Soap.

I parametri non possono essere passati per riferimento, ma si può usare il metodo copia/ripristino:

• Sun RPC, sviluppato originariamente da SUN e' utilizzato in alcune applicazioni in ambiente Unix e Linux come NFS.
• Java RMI (Remote Method Invocation) e' una interfaccia RPC in ambiente Java.
• Web Services: XML-RPC SOAP e REST sono protocolli RPC che usano XML Schema per codificare le chiamate e utilizza il protocollo http come trasporto.

Sviluppato in origine da Sun, Sun RPC e' stato il primo protocollo di RPC. Sun RPC fornisce il programma rpcgen che genera i 2 stub a partire da un file ( con estensione .x ) in cui viene descritto in modo astratto il formato dei dati che devono essere scambiati. Ad esempio volendo creare una rpc che calcola la media di un set di reali

http://www.linuxjournal.com/node/2204/print - http://www.fis.unipr.it/~roberto.alfieri/didattica/matdid/prog/rpc/sunrpc/

• creiamo il file avg.x
• il comando rpcgen avg.x

genera i file:

• avg_clnt.c → stub del client
• avg_svc.c → stub del server
• avg_xdr.c → Marshalling dei parametri
• avg.h → Header file comune

Il programmatore deve solo scrivere il programma server con le funzioni rese disponibili (es. avgservice.c) e il programma client (es. avgclient.c) che le chiama come se fossero funzioni locali, con lo stesso nome utilizzato dal server.

Sun RPC utilizza una architettura 3-tier nel senso che il server registra le sue funzioni (numerate) su un demone denominato Portmapper il quale ha il compito di assegnare una porta al servizio RPC. Il client dovrà contattare il portmapper per conoscere la porta utilizzata dal servizio. Il demone portmapper usa la porta 111 (tcp e udp).

Il comando

/usr/sbin/rpcinfo -p localhost   

ci dice quali sono le porte mappate per il servizio RPC. Ogni procedura e' identificata mediante un numero di programma.

E' possibile associare anche un nome registrandolo in /etc/rpc

Le comunicazioni RPC utilizzano il servizio UDP.

I Web services ( Wikipedia) sono uno strumento innovativo per costruire Middleware per la chiamata remota di metodi utilizzando componenti standard e aperti come XML per la codifica dei dati e HTTP, HTTPS o SMTP per il trasporto.

• XML-RPC e' una implementazione di Web Services
• vedi presentazione : XML-RPC.pdf

E' una specifica creata nel 1998 da UserLand Software. Da questo progetto e' poi evoluta la specifica Soap, anche se XML-RPC e' ancora utilizzato per la sua semplicità. Le chiamate e le risposte sono codificate il XML e trasportate all'interno del Body di HTTP. Le chiamate sono bloccanti. Esistono implementazioni per tutti i principali linguaggi moderni (C/C++, java, php, python, ..)

L'interfaccia e' indipendente dal linguaggio di programmazione e supporta un sottoinsieme dei tipi di dati semplici e composti:

• string (stringhe Ascii)
• int (intero con segno a 32 bit)
• double ( float a 64 bit)
• boolean (valori 0 e 1)
• dateTime.iso8601 (orario nello standard ISO)
• base64 (dati binari codificati in Ascii con base64)
• array ( insieme di dati di tipo semplice)
• struct (array associativi)

xmlrpc in PHP

esempi

xmlrpclib di Python

esempi

wikipedia

L'architettura logico-funzionale è basata sull'interazione tra 3 entita':

• Service Provider
• Service Requester
• Service Registry

Componenti principali:

• XML: Meta-linguaggio usato come base per descrivere qualunque aspetto del servizio
• SOAP: protocollo di interazione tra gli oggetti
• WSDL: Linguaggio per descrivere gli oggetti
• UDDI: Name & Service directory

gSOAP e' un toolkit OpenSource sviluppato da Robert Van Engelen (Florida State Univ.) per lo sviluppo di applicazioni SOAP/XML in C e C/C++. http://www.cs.fsu.edu/~engelen/

Attualmente e' un progetto SourceForge: http://sourceforge.net/projects/gsoap2

Un client Soap deve possedere una routine, denominata Stub, per ogni medoto remoto che il client intende chiamare. Lo stub simula quindi l'oggetto remoto sul lato client. Lo skeleton si occupa del contrario: simula la presenza dell'oggetto client sul server. Le due routine, che dovranno essere linkate ai programmi client e server, vengono generate automaticamente dal preprocessore soapcpp2 a partire dalle definizioni specificate in un header file (ad esempio servizio.h).

 soapcpp2    servizio.h

I file generati sono:

• servizioClient.c → Stub
• servizioServer.c → Skeleton
• servizioC.c → Marshalling dei parametri (serializzazione e deserializzazione)

Wikipedia