SISTEMA DI TIPI PER JOLIE ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA - SEDE DI CESENA FACOLTA' DI SCIENZE MATEMATICHE, FISICHE E NATURALI CORSO DI LAUREA SPECIALISTICA IN SCIENZE DELL'INFORMAZIONE IMPLEMENTAZIONE DI UN SISTEMA DI TIPI PER JOLIE Relatore Chiar.mo Prof. Zavattaro Gianluigi Correlatori Dr. Guidi Claudio Dott. Montesi Fabrizio Controrelatore Chiar.mo Prof. Maniezzo Vittorio Presentata da Ciotti Elvis

Sommario presentazione JOLIE - panoramica - creazione messaggi e invio SISTEMA DI TIPI PER JOLIE - dichiarazione tipi e controlli di conformità - esportazione tipi XML Schema DEMO - applicazione distribuita JOLIE con sistema di tipi CONCLUSIONI In questa presentazione un breve panoramica su jolie, con particolare attenzione al sistema di messaggistica. Proprio su questo sistema che viene introdotto il sistema di tipi. Prima di concludere effettuerò una dimostrazione di un app distribuita creata con jolie in cui il sistema di tipi attivo

Alcune caratteristiche Java Orchestration Language Interpreter Engine Linguaggio di programmazione Orchestrazione di servizi web Alternativa a WS-BPEL Basato su calcolo formale SOCK (primitive per descrizione meccanismi SOC) Sintassi linguaggio in stile C/Java Interprete rende operativi i servizi Ldp open source sviluppato dall’univ di bologna all’interno del progetto europeo sensoria Serve a programmare e orchestrare servizi web. È un’alternativa a ws-bpel, linguaggio basato su xml, sviluppato da ibm e microsoft. progettato su calcolo formale che fornisce primitive di descrizione meccanismi alla base di programmaz distribuita. Servizio si può programmare con una sintassi in stile C e java, l’interprete li legge e li rende operativi. Progetto europeo SENSORIA, Università di Bologna http://jolie.sourceforge.net/

Primitive di comunicazione B NOTIFICATION ONE WAY <xml …> …. </xml> A RETE Operatori di composizione Sequenza Parallelo Scelta non deterministica sugli input SOLICIT RESPONSE REQUEST RESPONSE C <xml …> …. </xml> D RETE Conformemente allo standard wsdl di descrizione servizi, in jolie abbiamo 4 primitive di comunicazione (o operazioni). Una notification invia semplicem un msg a una 1w in ascolto. [click] Una sr invia messaggio alla rr in ascolto e riceve un altro messaggio in risposta Il msg può contenere un fault che descrive un errore sollevato o propagato da servizi coinvolti dalla RR È possibile comporre le primitive componendoli con gli operatori seq, par e scelta nd. In questo modo è possibile realizzare l’orchestrazione dei servizi. <xml …> …. </xml> <xml …> FAULT </xml>

invio con notification Strutture dati Rappresentazione XML Codice JOLIE ordine> <cliente>Mario Rossi</cliente> <articoli> <prodotto> a128 <qta>1</qta> </prodotto> <prodotto> b131 <qta>3</qta> </prodotto> </articoli> </ordine> ordine.cliente = “Mario Rossi”; ordine.articoli.prodotto[0] = “a128”; ordine.articoli.prodotto[0].qta = 1; ordine.articoli.prodotto[1] = “b131”; ordine.articoli.prodotto[1].qta = 3; invio con notification inviaOrdine@ServizioOrdini( ordine ) Vediamo come si creano strutture dati con jolie. Una variabile jolie ha un contenuto nativo e ricorsivamente un vettore di variabili. Si può quindi rappresentare un contenuto strutturato come xml. In questo esempio un ordine ha : [click] Sottoelemento cliente con solam contenuto nativo Sottoelemento articoli che contiene primo e [click] secondo prodotto. Ognuno con cont nativo e sottoelem q.tà La variabili può essere inviata con una operazione, in questo caso una notification. nella rete viaggio in formato xml (codificato nel protocollo specificato) e verrà ricevuta dalla 1w in ascolto mantentendo questa struttura.

In questa tesi… Introduzione sistema di tipi per JOLIE - Sintassi per la definizione dei tipi - Controllo di conformità messaggio / tipo - Associazione tipi alle operazioni - Controlli inseriti in ingresso e uscita nelle operazioni Estensione generatore WSDL con tipi XML Schema “Strumento per la generazione di documenti WSDL che descrivono servizi JOLIE” Tesi di Laurea di Malagoli Davide - a.a. 07/08 Relatore: prof Gorrieri Roberto, Correlatori: Dr, Guidi Claudio, Dott. Montesi Fabrizio Questa tesi consiste nell’introduzione di un sistema di tipi che consente di dichiarare i tipi, ovvero la struttura dei mssaggi, associarle alle operazioni e controllare a runtime che i messaggi siano conformi ai tipi. Con la tesi di malagoli davide era presente uno strumento che creava documenti standard wsdl descriventi servizi jolie. Tale strumento è stato esteso consentendo di esportare i tipi dichiarati in formato xsd e inserendoli nel documento wsdl relativam alla operazioni.

Introduzione sistema di tipi 1) Sintassi per la definizione dei tipi dei messaggi TYPE_DECLARATION NATIVE_YPE SUB_TYPE_LIST_N TYPE_LIST_N SUBTYPE CARDINALITY type id: NATIVE_YPE SUB_TYPE_LIST_N void | string | int | double | any | undefined { SUBTYPE TYPE_LIST_N } | { ? } | Є , SUBTYPE TYPE_LIST_N | Є .id CARDINALITY: NATIVE_YPE SUB_TYPE_LIST_N | .id CARDINALITY: idTypeDeclared [NUMBER, NUMBER] | [NUMBER, *] | * | ? | Є Questa è la sintassi per definire un tipo strutturato di messaggio. [click] Un tipo ha un nome univoco nel servizio, un tipo nativo e una eventuale lista di sottotipi Un tipo nativo può essere: vuoto, …double, qualsiasi di questo o undefined (ovvero completamente vuoto) Un sottotipo ha un nome univoco nel tipo, un’intervallo di occorrenza, tipo nativo e ricorsivamente lista di sottotipi. Riusciamo quindi a rappresentare interamente l’albero del messaggio. Notare che con questa produzione è possibile dichiarare qualsiasi contenuto per un ramo dell’albero

Introduzione sistema di tipi Esempio di dichiarazioni di tipo del messaggio “ordine” type ORDINE_TYPE: void { .cliente: string .articoli: void { .prodotto[1,*]: string { .qta: int } } .altre_info: any {?} } <ordine> <cliente>Mario Rossi</cliente> <articoli> <prodotto> a128 <qta>1</qta> </prodotto> <prodotto> b131 <qta>3</qta> </prodotto> </articoli> </ordine> Qui abbiamo come esempio la dichiarazione del messaggio ordine, usato nel prec esempio. [click] Sottotipo cliente dichiara solo un contenuto nativo [click] sottotipo articoli dichiara cont nativo vuoto e almeno 1 sottotipo prodotto [click] ogni prodotto ha tipo nativo e sottotipo qta

Introduzione sistema di tipi 2) Algoritmo di controllo conformità messaggio al tipo dichiarato type ORDINE_TYPE: void { .cliente: string .articoli: void { .prodotto[1,*]: string { .qta: int } } .altre_info: any {?} } <ordine> 20081218A12 <cliente>Mario Rossi</cliente> <articoli> <prodotto> a128 <qta>1</qta> </prodotto> <prodotto> b131 ??? </prodotto> <data>2008/12/18</data> </articoli> </ordine> È stato realizzato algoritmo che prende input messaggio e tipo e rileva ogni errore. In questo esempio [click]Tipo nativo non valido [click] elemento q.ta mancante [click] nodo data non dichiarato [click] messaggio non conforme

Introduzione sistema di tipi 3) Associazione tipi alle operazioni outputPort OrdiniServicePort { Location: “http://xyz:2002” Protocol: soap OneWay: inviaOrdine RequestResponse: opRR throws fault1 fault2 } ( ORDINE_TYPE ) ( TIPO1 )( TIPO2 ) In jolie le operazioni vanno dichiarate nella porta. L’associazione dei tipi [facoltativa] avviene accanto alla dichiarazione. [click] possiamo dichiare tipo x operazione notification [click] possiamo dichiarare tipo in ingresso e uscita da op req-resp Una op rr deve dichiarare fault che può sollevare [click] anche il loro contenuto si può dichiarare (TIPO3) (TIPO4)

Introduzione sistema di tipi 4) Controlli nelle operazioni a tempo di esecuzione ONE WAY NOTIFICATION A B <ordine> … </ordine> <ordine> … </ordine> Invio effettivo solo se il messaggio è conforme al tipo locale TypeMismatch ricezione effettiva solo se il messaggio è conforme al tipo locale RETE A tempo di esecuzione, vengono effettuati controlli in ingresso e uscita dalle operaz. Il controllo è del messaggio corrente con la dichiarazione locale del servizio. [click] il messaggio in uscita dalla not viene controllato e inviato solo se è conforme, altrimenti sollevato localm fault [click] messaggio dalla 1 ricevuto solo se conforme alla relativa dichiaraz locale, altrimenti scartato e torna in ascolto. Sono effettuati controlli più complessi anche in ingresso e uscita nelle sr e rr, controllando anche gli eventuali fault.

GESTORE DELLA COMUNICAZIONE Introduzione sistema di tipi COMPONENTE CONTROLLO CONFORMITA’ CONTROLLI IN/OUT OPERAZIONI AMBIENTE DI ESECUZIONE Modifiche apportate all’architettura JOLIE SCANNER PARSER CONTROLLORE SEMANTICO OOIT BUILDER OOIT … … Jolie realizzato in linguaggio java, l’ambiente runtime chiama prima il parser che legge il codice del servizio, lo controlla e costruisce un albero di sintassi astratta con tutti gli oggetti dei componenti del servizio, resi operativi dal componente runtime [e gestore comunicazione]. [click] nel parser si è inserito il parsing e controllo dei tipi e parseing dell’assocazione alle operazioni [click] nel cs si controllano che i tipi associati esistano e siano validi (es: intervallo cardinalità stipi valido) [click] nell’albero gli oggetti dei tipi sono inseriti nelle operazioni e il componente runtime controlla tramite il nuovo componente di controllo che i messaggi siano conformi. op1 - ESISTENZA TIPI - CARDINALITA’ … opN - TIPI - ASSOCIAZIONI TIPI-OPERAZIONI Codice JOLIE servizio OGGETTI DICHIARAZIONI TIPO INSERITI NELLE OPERAZIONI GESTORE DELLA COMUNICAZIONE

Introduzione sistema di tipi Demo: gestore sessioni esami DATABASE CORSI E VOTI DATABASE ACCOUNTS PROFESSORE 1 STUDENTE 1 GESTORE SESSIONI D’ESAME sessione … sessione … … PROFESSORE N STUDENTE M È stata realizzata con jolie un’applicazione distribuita in cui più professori lanciano sessioni d’esame a cui partecipano gli studenti. Tutte le comunicazioni sono realizzate tramite il servizio centrale che gestisce le autenticazioni e il giusto indirizzamento dei messaggi nelle giuste sessioni contemporanee. Vediamo questa applicazione in esecuzione [1] ho lanciato il servizio centrale, servizi database: corsi e account, che stanno sempre in ascolto. [zava] lanciamo professore, che si autentica, riceve lista esami e corsi, lanciamo sessioni per corso “fi”, studente 1 e 2 (ognuno di questi è servizio embeddato). [stud1] dall’altra parte si autentica lo studente 1 e chiede di partecipare a sessione per “fi”, la sessione esiste e i servizi sono agganciati. Il professore invia 3 domande e riceve 3 risposte. [digita…] Prof e studenti, cosi come gestore esami e servizi db possono stare su macchine diverse e usare protocolli differenti. La comunicazione avviene tramite messaggi xml codificati nel protocollo scelto. [fine esame..] alla fine prof propone voto, lo studente accetta e avviene la registrazione. questa sess è terminata. [stud3] Se ora lo studente 3 si autentica e chiede di partecipare alla sessione, rimane in attesa, non esiste sessione per lui. [zava sess3] appena il prof attiva sessione per stud3 avviene l’aggancio dei servizi. In questa applicaz è attivo sistema di tipi. Lo studente 4 ha un servizio obsoleto e usa l’interfaccia vecchio del gestore esami. Invia infatti nome e cognome che sono stati sostituiti da username ottenendo un fault in risposta. sessione … sessione Autenticazione Creazione sessione (esame, studente) Domande Proposta voto Autenticazione Partecipazione sessione (esame, studente) Risposte a domande Accettazione voto

Esportazione WSDL Codice JOLIE del servizio Documento WSDL TRASFORMATORE JOLIE -> WSDL outpuPort outPort { Location:… Protocol: soap{ .schema=“file.xsd” ... } OneWay: op1 } … ESPORTAZIONE TIPI -> XSD type TIPO1 {...} outpuPort outPort { Location: ... Protocol: soap OneWay: op1(TIPO1) } … <wsdl:definitions ..> <wsdl:types> … </wsdl:types> <wsdl:message…> … <wsdl:message…> <wsdl:portType …> <wsdl:operation…> … </wsdl:operation…> <wsdl:input … /> <wsdl:output … /> </wsdl:portType …> Jolie comprendeva un tool di esportaazione dei servizi in formato wsdl. documento wsdl è uno standard w3c in cui si dichiarano le operazioni e i tipi XSD dei messaggi usati dalle operazioni. I tipi dovevano essere scritti manualmnete in formato xml schema su un file esterno al servizio. [click] è stato aggiunto un componente al tool che consente di eportare i tipi dichiarati jolie in tipi corrisp xml schema. Adesso, se non è specificato il file xsd esterno, nel file wsdl vengono inseriti i relativi tipi xsd. DICHIARAZIONI XML Schema ESTERNE

Conclusioni Sistema di tipi: considerazioni Sviluppi futuri Con questa tesi si è introdotto un sistema di tipi per JOLIE che permette la dichiarazione dei tipi dei messaggi ed effettua dei controlli in ingresso e uscita dalle operazioni, in modo che le operazioni inviino e ricevano messaggi conformi ai relativi tipi dichiarati. E’ stato anche modificato lo strumento per la creazione di documenti WSDL descriventi servizi JOLIE, inserendo l’esportazione dei tipi dichiarati in formato XSD nelle relative operazioni. Sistema di tipi: considerazioni Messaggi strutturalmente corretti: diminuzione anomalie di funzionamento Visualizzazione dettagliata errori di conformità: strumento di debug Dichiarazione tipi molto flessibile: qualsiasi contenuto per sottostruttura del tipo Sviluppi futuri Supporto per altri tipi derivati e costrutti XSD Sviluppo linguaggio di coreografia complementare a JOLIE con supporto tipi Messaggi strutturati correttamente diminuiscono quindi le eventuali anomalie di funzionamento e Con opportuni handler dei fault offrono anche uno strumento di debugging per i messaggi creati. Il sistema di tipi è molto flessibile, è possibile dichiarare qualsiasi contenuto per un sottotipo per il quale non verrà effettuato il matching. E’ anche possibile omettere la dichiarazione del tipo in alcune operazioni in modo da escludere totalmente i controlli. Una aggiunta futura al sistema di tipi potrebbe essere il supporto per altri tipi e costrutti XSD (tipo booleano, tipo data, tipo numero intero limitato in intervallo) e il costrutto di alternativa. In futuro potrebbe essere sviluppato un linguaggio di coreografia complementare a JOLIE in cui inserire questo sistema di tipi

Grazie dell’attenzione Domande ?

Received TypeMismatch Introduzione sistema di tipi 3) Controlli nelle operazioni a tempo di esecuzione Invio effettivo solo se il messaggio è conforme al tipo locale Ricezione effettiva solo se il messaggio è conforme al tipo locale TypeMismatch TypeMismatch SOLICIT RESPONSE REQUEST RESPONSE A <xml …> <soap…> … </soap> <xml …> <soap…> … </soap> B RETE 1) In uscita dall’operazione SR è inserito un controllo come nella notification, ovvero invio se il mess è conforme, fault se errato. 2) Nella RR in ascolto la ricezione avviene solo se il messaggio è conforme, altrimenti viene inviata una risposta contenente un fault e RR torna in ascolto. Il fault è necessario poiché la SR si aspetta una risposta. 3)Se il messaggio è conforme, la RR compone la risposta. Se questa è conforme viene inviata, altrimenti viene inviato il fault IOfault. 4)È effettuato un altro controllo prima che la SR riceva la risposta rispetto al tipo locale. Se è corretta continua l’esecuzione, altrimenti viene sollevato un fault di msg ricevuto errato. 5)È possibile che nel processo di risp della RR venga sollevate un fault, in questo caso il fault viene normalmente inviato. La conformità di tale fault è controllata in entrambi i servizi e in caso di mismatch avviene una semplice notifica a video 6) Come per l’altra coppia di operazioni, i doppi controlli sono necessari da entrambi i lati piochè un servizio potrebbe cambiare l’interfaccia all’insaputa degli altri servizi. 7) I fault sollevati dal sistema di tipi contengono l’elenco completo degli errori di matching e possono essere catturati da un handler e gestiti dal servizio (effettuando stampe dell’errore o operazioni di recupero) <xml …> <soap…> … </soap> <xml …> <soap…> … </soap> Se il messaggio creato non è conforme al tipo locale: invio fault Ricezione effettiva solo se il messaggio è conforme al tipo locale Received TypeMismatch IOFault

Web Services WS-BPEL Orchestrazione Web service: sistema software Pubblicazione interfaccia servizi: WSDL e UDDI Scambio di messaggi: HTTP e SOAP (XML) Comunicazione nella rete tra sistemi eterogenei Composizione: coreografia e orchestrazione Un web service è un sistema software che permette lo scambio di messaggi tra elaboratori sulla stessa rete. un servizio descrive la sua interfaccia nel formato standard WSDL e la pubblica su un registro tramite protocollo UDDI, in modo che altri servizi possano interagire con esso. Lo scambio di messaggi è tipicamente realizzato sul protocollo di trasporto HTTP e con messaggi XML codificati nello standard SOAP. L’utilizzo di questi protocolli aperti e standard e messaggi di formati di messaggi testuali consente una facile interazione tra piattaforme operative differenti e sistemi eterogenei. La composizione tra servizi può avvenire con due differenti approcci. Con la coreografia abbiamo una descrizione dall’alto dell’intera applicazione distribuita. Con l’orchestrazione invece i servizi sono progettati separamente, ogni servizio definisce la propria logica applicativa e di interazione con gli altri servizi. Il linguaggio di orchestrazione attualmente più accreditato è BPEL for web services. A questo si è recentemente affiancato il progetto open source JOLIE, nato all’interno del progetto europeo SENSORIA di cui l’università di bologna è parte attiva B C WS-BPEL Orchestrazione