Sistemi distribuiti

2,352 views

Published on

Guida ai sistemi distribuiti per chi informatico non è :)

Argomenti principali:
Architettura internet, Protocolli, Architettura Web, Web application standard, Ajax, Servlet, Jsp, Javascript, Web service, SOA, Soap, WSDL, UDDI, Web process, Rest, Owl-s, RDF, Mashup, webscraping, API, Virtualizzazione, Json, Rss, XML, Web service contract, it value, Cloud computing...

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,352
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sistemi distribuiti

  1. 1. SISTEMI DISTRIBUITI (Prof. De Paoli – Unimib) ARCHITETTURA DEL WEB Web è una architettura software di client-server che comunicano con HTTP. Server spesso sono chiamati web server o HTTP server. HTTP caratterizza le applicazioni WEB dalle altre: il WEB è HTTP, non INTERNET. Il client (o user agent) è lo strumento a disposizione dell'utente, gli permette l'accesso e la navigazione nell'ipertesto del Web. Esso: trasmette all'opportuno server le richieste di reperimento dati che derivano dalle azioni dell'utente; riceve dal server le informazioni richieste; visualizza il contenuto della pagina Web richiesta dall'utente gestendo in modo appropriato tutte le tipologie di informazioni in esse contenute; consente operazioni locali sulle informazioni ricevute. I client usano I browser per navigare. Browser dunque è una applicazione client che utilizza il protocollo HTTP per inoltrare le richieste dell’utente ad un web server. Interpreta codice in cui sono espresse le informazioni (pagina web) e lo visualizza in forma di ipertesto. È caratterizzato dalla capacità di “parlare” con HTTP. Consente la navigazione. Qualsiasi software che usa HTTP è un browser. In sintesi browser: chiede documenti a un server tramite HTTP + rendering (resa grafica di tali documenti à motore di rendering: parte del browser che si occupa di mostarare a video le pagine secondo le specifiche proprie dello strumento – pc, smartphone, ecc). Client invia domanda a server (HTTP request) componente attivo/server risponde alla domanda del client (HTTP response) fornisce il servizio al client, è componente passivo perchè risponde alle azioni fatte dal client. PAGINA WEB è costituita da diversi oggetti (file) è memorizzata su un server ed identificata da un URL (inidirizzo univoco per la risorsa) quindi 1FILE = 1URL. La maggior parte delle pagine web sono costituite da un file HTML che definisce struttura e contenuti testuali della pagina + altri oggetti aggiuntivi. HTML (Hyper Text Markup Language) linguaggio di tipo statico utilizzato per la realizzazione dei contenuti di una pagina web. Utilizza dei tag per indicare a un browser come deve interpretare e visualizzare l'ipertesto (permette di definire l’aspetto della pagina, link, ecc). Quindi linguaggio HTML permette di definire la presentazione del documento nonché dei link ipertestuali verso altri documenti attraverso dei tag di formattazioneIPERTESTO insieme di testi (o pagine) leggibili tramite interfaccia elettronica in maniera non sequenziale, tramite hyperlink (o link) che costituiscono I collegamenti tra un testo (o pag) e un altro. LINGUAGGI DEL WEB la parte testuale dei documenti è espressa con linguaggi standard: 1) HTML (focus su PRESENTAZIONE DEI DATI, imaginazione): CSS, HTML DINAMICO, ecc. 2) XML (focus su DATI E LORO STRUTTURA): XSL, RDF. 3) LINGUAGGI DI SCRIPTING (arricchiscono interazione): JAVASCRIPT, VBSCRIPT. INTERNET rete di reti, a livello mondiale, che interagiscono. Ha struttura parzialmente gerarchica, composta appunto da reti, diverse (locali, regionali, nazionali, ecc che devono essere collegate e “parlare”). Non c’è grande controllo, in questo modo ogni rete può crescere e/o evolversi. È composto da segmenti pubblici e intranet private. BLACKBONE è Il livello gerarchicamente più alto dell’architettura di una rete. E' una linea di connessione ad alta velocità' che connette le reti di velocità e capacità inferiore tra di loro. Tipicamente canali in fibra ottica, controllate da provider nazionali/internazionali. STRUTTURA RETE: 1) host end-system: dispositivi (pc, smartphone, ecc) collegati, eseguono applicazioni di rete (es. broweser) 2) mezzi trasmissivi: rame, fibra ottica, ecc. 3) router. I protocolli regolano la comunicazione tra sistemi (ex. TCP, IP). STANDARD INTERNET: RFC request for comments; IETF internet engineering task force. La rete di comunicazione permette di eseguire applicazioni (www, mail, giochi, ecc). Comunicazione basata sul concetto di protocollo. I protocolli di rete coivolgono la macchina e governano tutte le comunicazioni in internet (tra macchine). PROTOCOLLI [*pag.5]: definiscono il formato, l’ordine di invio e di ricezione dei msg tra dispositivi e azioni prese quando si riceve un msg. 5 LIVELLI DI PROTOCOLLO: per dare una struttura ai protocolli è stata adottata un’architettura a livelli, ogni protocollo appartiene a uno o più livelli. Ogni livello possiede un service model: ogni livello usa i servizi del livello immediatamente inferiore per fornire il proprio servizio, effettuando determinate azioni all’interno del proprio livello. La stratificazione ha come vantaggio il fatto che fornisce un modo strutturato per trattare I componenti dei sistemi. Come svantaggio potenziale c’è il fatto che due livelli possono duplicare le funzionalità o, ancora, un livello può richiedere info presenti solo in un altro livello. Protocol stack è l’insieme dei protocolli dei vari livelli. I livelli sono: 1) di applicazione Sede delle applicazioni di rete e dei relativi protocolli. Appartengono: HTTP, FTP, SMTP, DNS, POP. 2) di trasporto Trasferisce i msg a livello di applicazione tra modulo client e server di un’applicazione. Nelle reti sono 2: TCP (permette un controllo della congestione) e UDP (fornisce un servizio senza connessioni, non controlla congestione). 3) di rete Trasferisce I pacchetti a livello di rete; generalmente incapsula I msg del livello precedente in datagrammi dotati di un network layer header. Questo livello possiede un protocollo, detto IP, che definisce I campi del datagramma + come I sistemi terminali e I router possono agire su tali campi.
  2. 2. (protocolli aggiuntivi in questo livello: protocolli di instradamento). 4) di collegamento Instrada un datagramma attraverso una serie di commutatori di pacchetto (= router) tra l’origine e la destinazione. A ogni nodo della rete i datigrammi entrano dal liv inferiore (fisico) salgono a quello di collegamento che li instrada al nuovo nodo o sistema terminale, passando di nuovo il pacchetto al livello precedente (fisico, che li spedisce). 5) fisico trasferisce I singoli bit da un nodo a quello successivo e dipende dall’effettivo mezzo trasmissivo. LIVELLO APPLICATIVO è sede delle applicazioni e dei loro relativi protocolli à applicazioni sono processi distribuiti in comunicazione, in esecuzione su host remoti; si scambiano msg per eseguire l’applicazione; es. posta, FTP, www. Un processo è un programma in esecuzione su un host. Sullo stesso host: comunicano mediante meccanismi definiti dal SO. Processi in comunicazione su host diversi: comunicano mediante meccanismi definiti dal protocollo dello starto di applicazione (HTTP). User agent è l’interfaccia tra utente e applicazione di rete. Un programma è una sequenza di istruzioni eseguibili dalle “macchine” (fisiche o virtuali) e I processi sono entità gestite dal SO e costituiti da: area di memoria ram per effettuare le operazioni e memorizzare i dati + registro che ricorda la prossima istruzione da eseguire + canali di comunicazione. Ogni processo comunica tramite I canali: canale gestisce I flussi di dati in ingresso/uscita; canale: schermo, tastiera, rete, ecc; dall’esterno ogni canale è identificato da un numero intero detto”porta”. Per il SO tutti I processi sono uguali. Il SO attiva un processo che andrà a lanciare un programma, ma tutti questi processi per il SO sono identici. Applicazione di rete tipica è divisa in 2 parti: client e server. Client inizia dialogo col server (speaks first), di solito richiede un servizio; nel caso del web il client è integrato nel browser. Server fornisce il servizio al client, su richiesta. URL Uniform Resource Locator servono a “identificare” quello con cui si vuole comunicare (indirizzo della risorsa). IP ADDRESS identifica l’host su cui l’altro processo è in esecuzione; PORT NUMBER permette all’host ricevente di identificare il processo locale destinatario del msg (il programma a cui bisogna dare i dati). URL quindi identifica un oggetto nella rete e specifica il modo per accedere ad esso: protocollo. Ha tre componenti: nome del protocollo, indirizzo dell’host (IP+PORTA) e percorso nell’host. Protocollo://indirizzo_IP [:porta]/cammino/file. La porta è opzionale PROTOCOLLO HTTP è un protocollo di livello applicativo; usa il modello client/server. Client: browser che richiede, riceve e visualizza oggetti web. Server: web server che invia oggetti in risposta alle richieste. HTTP request, formato pacchetto e specifiche: 1) request line method/sp/url/version/cr/lf à request line identifica una request HTML. A)Metodi (tipo di operazioni che client richiede al server) GET usato per richiedere una pag web; POST usato quando utente compila una form – contenuto dei campi è posto nell’entity body. Comando serve per richiedere una pag web il cui contenuto dipende da info inviate dal client, nel body. HEAD come il get ma viene restituito solo l’head della pagina web. B)Carattere spaziale C)URL richiesta D)Versione HTTP (es. 1.1) E)Carriage return e F)Line Feed sono due caratteri speciali. 2) Header line: righe testuali free-format che specificano caratteristiche. Sono di molti tipi e possono essere più o meno numerose. Formato generale è “header name : valore (es. User agent : Mozzila/4.0. 3) + cr/lf e altre ipotetiche righe di header. Tra header e body c’è sempre una riga vuota (composta da cr/lf) sia nelle HTTP request che response. 3) Entity body è opzionale, campo contenente dati (es. documento richiesto dal client). HTTP response, formato pacchetto e specifiche: 1) response line, identifica una HTML response – protocol/sp/status code/sp/status phrase/cr/lf. A)protocol identifica la versione del protocollo usata B)codice dello stato (200 OK: Successo, oggetto richiesto più avanti nel messaggio. 301 Moved Permanently: L’oggetto richiesto è stato spostato. Il nuovo indirizzo è specificato più avanti. 400 Bad Request: Richiesta incomprensibile al server. 404 Not Found: Il documento non è stato trovato sul server. 505 HTTP Version Not Supported). C)significato del codice di stato. 2) Headers line: insieme di linee facoltative che permettono di dare delle info supplementari sulla risposta e/o il server. Formato generale è “Header name: valore”. 3) Body contiene il documento richiesto. // HTTP per funzionare si basa su TCP: il client inizia una connessione TCP (crea una socket) verso il server (sulla porta 80); il server accetta la connessione TCP dal client; scambio di msg HTTP tra browser (che è il client HTTP) e il web server (che è il server HTTP); connessione viene chiusa. HTTP è stateless: server non mantiene informazioni sulle richieste precedenti del client, ogni richiesta è indipendente da quelle precedenti e si conclude al momento della chiusura della connessione (I protocolli che mantengono le info sono complessi). Il server web quindi non ha "memoria" di quanto comunicato precedentemente con un certo client: per questo motivo, per realizzare applicazioni web complesse, sono stati sviluppati meccanismi a livello superiore come i cookies per costruire "sessioni" e permettere al server di recuperare informazioni riguardanti un certo client. Es. Utente accede alla url
  3. 3. www.someSchool.edu/someDepartment/home.index (testo + riferimenti a 10 jpeg) à [PARTE CLIENT 1] apertura connessione TCP verso il server (processo) http sull’host www.someSchool.edu. Porta standard: 80 [PARTE SERVER 2] Il server http presso l’ host www.someSchool.edu è “in ascolto” sulla porta 80. Accetta la richiesta di connessione e ne dà conferma al client [PARTE CLIENT 3] client invia una HTTP REQUEST contenente la url desiderata. [PARTE SERVER 4] server http riceve il messaggio di richiesta, costruisce un messaggio di rispota (response message) contenente l’oggetto richiesto (someDepartment/ home.index), invia il messaggio. Chiude connessione. [PARTE CLIENT 5] ricezione msg di risposta contente il file HTML, visualizzazione pagina. Si accorge che ci sono I riferimenti a 10 immagini: ripete I passi 1-4 per ogni immagine. HTTP interagisce con server tramite METODI (o comandi): GET (Restituisce una rappresentazione di unarisorsa; è una operazione safe: può essere ripetuta senza conseguenze; può essere gestita con una cache) Conditional GET (nell’head di una richiesta si possono inserire condizioni sulla restituzione della risorsa: If-Modified-Since) Partial GET (usando il campo Range nell’head di un msg ottengo solo una parte della risorsa; Conditional e partial GET riducono il traffico inutile di rete) HEAD (come la GET ma non deve includere un body nella risposta) POST (crea una nuova risorsa come figlia di una risorsa esistente, indicata dalla URI associata; La risposta è 201 e il campo Location indica l’URI della nuova risorsa; NON è in generale gestibile con una cache) PUT aggiorna una risorsa o crea una risorsa in una particolare destinazione; è idempotente: se la eseguo più volte ottengo sempre lo stesso risultato) DELETE (Elimina una risorsa, è idempotente, non è safe) OPTIONS (permette ricevere informazioni - possibilità e requisiti – su una risorsa o sul server, quindi di “scoprire” come operare. es: le operazioni che si possono eseguire). HEADER: con header si gestisce accesso ad un url che richiede autenticazione da parte dell’utente. Obiettivo: controllare l’accesso ai documenti sul server (email, form, ecc). Autenticazione tipicamente viene fatta tramite log (nick e password). Si introduce nell’header la riga “authorization”. Se utente non si autentica, server rifiuta connessione. Problema: HTTP è stateless. Utente dovrebbe autenticarsi ogni volta. Si risolve con COOKIE (stringhe di carattere restituite dal server insieme alle risposte, nell’header del msg HTTP di risposta) Server invia un cookie al client con la risposta in caso di autenticazione avvenuta con successo. Il server memorizza le credenziali dell’utente. Ad accessi successivi, client presenta cookie che viene controllato dal server in cerca di autenticazione precedente + traccia delle preferenze dell’utente. Si usa la GET condizionale per inviare all’utente solo “dati nuovi” cioè: client comunica data dell’ultimo oggetto che ha in memoria (If-modified-since: <date>) e server risponde inviando il/i nuovo/i documento/I o risposta vuota se non ci sono aggiornamenti. Per fare queste operazioni si usano le FORM: [definizione, in relazione a tecnologie lato server più avanti: I form sono pagine web composte da testo e "campi" che l'utente può riempire; è un eccellete modo di raccogliere informazioni sulle persone che visitano il sito, permettendogli, così, di interagire con esso. I Form sono scritti in HTML e, normalmente, processati da tecnologia lato server ASP JSP PHP CGI ecc.. L'output può essere mandato sotto forma di e-mail, memorizzato on line, stampato, e/o rimandato all'utente come pagina HTML] si usa uno dei due metodi di invio dati, GET o POST + si usano caselle di testo di vario tipo (text, password, ecc) per l’autenticazione + si usano checkbox/radio button per eventuali ulteriori comunicazioni + si usano tasti (es. Submit) per inviare le comunicazioni. LIMITI DI HTTP A CARATTERI: Utilizzo dell’interfaccia browser (uso di FORM); lentezza: occorre tradurre e ritradurre i dati; costruzione delle pagine HTML in risposta; essendo stateless ogni richiesta è un messaggio autonomo; per creare sessioni di lavoro (legare più richieste tra loro) occorre includere informazioni con mezzi espliciti, campi nascosti e cookie. POSTA ELETTRONICA 3 componenti base: 1) user agent – client di posta che permette di leggere/ricevere/scrivere email. I msg in ingresso/uscita vengono memorizzati su 2) mail server – contiene msg e permette traffico delle mail; nello specifico: contiene I msg ricevuti (mail box); coda dei msg in uscita; 3) protocollo SMTP, che permette al mail server di scambiarsi I msg di posta fin quando non arrivano al servere di posta finale. USER AGENT MITTENTE à MAIL SERVER1 à(SMPT)à MAIL SERVER 2 à(IMAP/POP3)à USER AGENT RICEVE. User agent mittente, invia il msg al mail server 1 e qui viene messo nella coda dei msg in uscita. Mail server 1 apre connessione SMTP con mail server 2; se contatto fallisce ci si riprova (ogni 30 minuti, se fallisce per giorni si manda un msg di notifica a user agent mittente) se contatto riesce ok. Mail server 2 (ricevente) riceve msg inviato via SMTP e lo mette nella mail box in attesa di lettura. User agent può accedere tramite protoccolo IMAP o POP3. PROTOCOLLO SMTP utilizza TCP sulla porta 25 pe ril trasferimento affidabile dei msg tra server. Interazione avviene tramite comandi/risposte. 3 fasi: 1) handshaking: saluto, creacione connessione 2) trasferimento di 1 o più msg. sfruttando connessione 3) chiusura connessione. Formato usato: comandi = testo ASCII a 7 bit; risposta = testo ASCII a 7 bit (codice di stato e frase); MSG = testo ASCII a 7 bit (anche se contengono dati multimediali). In sintesi: SMPT usa connessione TCP persistente; richiede che il msg (header e body) sia in formato ASCII a 7 bit; alcune sequenze di caratteri non sono consentite nel msg (es. CRLF) questo implica la necessità di codificare il msg.
  4. 4. il server SMTP usa CRLF.CRLF per terminare il msg. CONFRONTO SMTP/HTTP: HTTP è pull, il client chiede I dati (“tira” la richiesta) SMTP è push, c’è un unico trasferimento, non fa richieste (“spinge” dati). Entrambi usano msg in ASCII a 7 bit per comandi/risposte. In HTTP ogni oggetto è incapsulato nel msg di risposta, in SMTP si usa la frammentazione dei msg per inviare un msg con più oggetti. FORMATO MSG SMTP: header (to; from; subject) + linea vuota + body (msg vero e proprio in ASCII a 7 bit). MIME Multipurpose Internet Mail Extension: Qualifica dati multimediali e di specifiche applicazioni. Permette quindi il riconoscimento/invio di file del tipo: Text (plain, html) Image (jpeg, gif) Audio (basic, 32kadpcm) Video (mpeg, quicktime) Application (dati che devono essere processati da un’applicazione prima di essere “visibili” es. msword, octet-stream). La maggior parte delle mail è spedita via SMTP in formato MIME. FORMATO MSG MIME: si aggiungono sigle all’header (quello del msg formato SMPT di prima) per specificare il tipo di contenuto MIME. HEADER campi standard (from, to, suject) + MIME version (1.0) + MIME transfer-encoding (base 64: tipo di codifica per traferimento) + Content-type (image/jpg: file da trasmettere). Una volta che il server mail ha in memoria la mail ci sono diversi protocolli di accesso ai dati: POP3/IMAP (+HTTP, es. Hotmail, Yahoo mail, ecc) POP3 autenticazione tra utente e server + scaricamento posta. Si può usare in modalità 1) scarica e elimina: elimina la posta della mailbox dopo averla scaricata; disperde la posta sui diversi host da cui accede alla mailbox; user agent permette di creare cartelle, sopstare msg, effettuare ricerche nei msg. 2) scarica e conserva: User Agent conserva la posta sulla Mailbox; utente può leggere i messaggi da macchine diverse; non permette di strutturare i messaggi in directory (è stateless tra sesisoni diverse). IMAP: permette di gestire cartelle di posta remote come se fossero locali; deve mantenere una gerarchia di cartelle per ogni utente; permette allo User Agent di scaricare solo parti del messaggio (header, intestazione MIME, ecc). E’ statefull (mantiene stato tra sessioni) 4 stati possibili: 1)Non-authenticated; utente deve fornire username e password per la connessione 2)AuthenticatedState; utente deve specificare una cartella prima di eseguire comandi che influiscono sul messaggio 3) Selected State; utente può dare comandi che influiscono sul messaggio, es. elimina, salva, sposta 4) LogoutState: sessione terminata. DNS Domain Name System: Servono per associare indirizzi numerici e indirizzi simbolici (o logici) più facilmente memorizzabili. Gli indirizzi numerici sono utilizzati da server e client, quelli simbolici dagli utenti finali. Bisogna che esista un sistema per rendere disponibili tali associazioni. Il DNS è il directory service della rete Internet. I nomi sono costituiti da un elenco di labels. Poichè i nomi sono tanti bisogna usare un database distribuito implementato come una gerarchia di server, ramificazioni di DSN (o NAME) SERVER. Comunicano tramite protocollo applicativo: usato da host, router, server per risolvere I nomi logici in IP. esistono quattro tipi di name servers: 1)Root name servers; vengono contattati dai server locali per risolvere gli indirizzi (conosce tutti i TLD servers. Esso: contatta il name server di riferimento se la traduzione non è nota; ottiene la traduzione; restituisce la traduzione al name server locale) 2)TLD: hanno tutte le info sugli authorative server (.com, .edu, .org), più uno per ogni dominio 3)authorative: sono gestite dalle organizzazioni che forniscono i sottodomini. Conoscono hosts e sottodomini 4)local name server: viene contattato dalla macchina che cerca traduzione. Gestisce ricerca in modo trasparente. DSN dunque è una funzione base della rete implementata come protocollo applicativo dai name server. Non è un’applicazione con cui gli utenti interagiscono direttamente; fornisce una funzionalità di base di internet per le applicazioni utente; Rispecchia la filosofia di concentrare la complessità nelle parti periferiche della rete. È usato da diverse applicazioni (HTTP, SMTP, FTP, ecc). Http richiede la conoscenza dell’indirizzo IP e del nome simbolico corrispondente, si interroga quindi un Name server con una richiesta UDP per ottenere l’IP (si usa una cache per ridurre ritardo) N.b. Distribuzione del carico tra Server replicati; DNS fornisce un gruppo di indirizzi alternando l’ordine, ciò permette di dirigere un client al server più vicino. Non c’è un DSN centrallizzato perchè avrebbe: Minore tolleranza ai guasti; Traffico eccessivo; Database centrale troppo distante in molti casi; Scarsa scalabilità; Autorizzazione ed accesso per registrare nuovo host. Nessun name server contiene tutte le associazioni nome simbolico/indirizzo IP. Schema ricorsivo (recoursive query): I root name server potrebbero non conoscere il name server di riferimento ma possono conoscere un server intermedio che permette di raggiungere quello di riferimento. Si trasferisce il carico della traduzione al name server contattato. In caso di sovraccarico: richieste ripetute (iterated query): il name server contattato risponde con l’indirizzo del prossimo name server da contattare, con un msg del tipo “non conosco questo name ma prova a rivolgerti a quest’altro server”. Quando un name server traduce un nome lo memorizza localmente (caching). Il processo di caching conferisce ai DNS servers la capacità di fornire informazioni sugli indirizzi di macchine che non fanno parte del loro stesso dominio e non sono sotto il loro stretto controllo: in altre parole, un server DNS impara dai suoi "colleghi" e può validamente rispondere ad una richiesta di un client senza avere l'"autorità formale" per farlo. Queste memorizzazioni sono temporanee, scadono (timeout) dopo un certo tempo (un paio di giorni). Il mapping è mantenuto nei database sotto forma di resource
  5. 5. record (RR); ogni RR mantiene un mapping; i record vengono spediti tra server e all’host richiedente all’interno di messaggi DNS; Un messaggio può contenere più RR. Formato RR: Name, Value, Type, TTL. Ci sono 4 possibili type: Type A: Hostname à IP address; name è il nome dell’host; value è l’indirizzo IP. Type NS: Domain name à Name Server; name è il dominio; value è il nome dell’host del server di competenza di questo dominio. Type CNAME: Alias à Canonical Name; name è il nome alias di qualche nome “canonico” (nome vero); value è il nome canonico. Type MX: Alias è mail server canonical name; value è il nome canonico del server di posta associato a name. Protocollo DNS per domande (query) e messaggi di risposta (entrambi con lo stesso formato) struttura del pacchetto: Intestazione del messaggio (header) à 1) Identificazione: numero di 16 bit per la domanda; la risposta alla domanda usa lo stesso numero 2) Flag: domanda o risposta; richiesta di ricorsione; ricorsione disponibile; risposta di competenza (il server è competente per il nome richiesto) 3) Numero di: numero di occorrenze di risposta, di RR di risposta, di RR autorevoli, di RR addizionali. Poi Questions (numero di variabili di questions) Answer (numero di variabili di record di risorsa) Authority (numero di variabili di record di risorsa) + Additional informations. MODELLI PER L’INTERAZIONE sono 2: client/server e peer to peer à le entità partecipanti condividono le proprie risorse per contribuire attivamente alla fornitura del servizio (si contrappone alla tradizionale architettura client/server). In un sistema peer-to-peer ogni entità (peer) partecipa alla fornitura del servizio (interazione simmetirca). Es: un'applicazione di file-sharing. Un peer agisce contemporaneamente come client e come server (servant): come server, fornisce parte delle sue risorse e come client, richiede le risorse degli altri peer. I servizi della rete si dividono in: 1) ORIENTATI ALLA CONNESSIONE e 2) NON ORIENTATI (CONNECTIONLESS) obiettivo comune è trasferimento di dati tra host. 1) Connection oriented è la modalità di comunicazione dati tramite cui i dispositivi terminali usano un protocollo di comunicazione per stabilire una connessione logica o fisica end-to-end tra gli agenti della comunicazione prima della trasmissione di qualsiasi tipo di dato. Si crea un canale “virtuale” (preceduto da scambio di info di controllo – handshaking) che permette ai due host di comunicare, tale canale è uno stato nei due host che indica che sono in comunicazione. TCP è un protocollo orientato alla connessione (prima di poter trasmettere dati deve stabilire la comunicazione, negoziando una connessione tra mittente e destinatario, che rimane attiva anche in assenza di scambio di dati e viene esplicitamente chiusa quando non più necessaria) a pacchetti: scompone il msg in pacchetti e implementa I meccanismi di avvenuta ricezione e eventuale reinvio dei pacchetti persi/danneggiati. Fornisce: trasferimento affidabile (reliable) di flussi di byte; in caso di perdita viene conferma con gli ack (acknowledgement) e avviene ritrasmissione; ordine: numerazione dei pacchetti e scarto dei duplicati. Controllo di flusso (flow control): il sender rallenta (in caso di congestione della rete) o accelera (in caso di rete libera e veloce) gli invii al receiver. Controllo della congestione (congestion control): il ritmo (rate) di trasmissione diminuisce se la rete è congestionata. 2) SERVIZI NON ORIENTATI ALLA CONNESSIONE: lo scambio di dati a pacchetto tra mittente e destinatario (o destinatari) non richiede l'operazione preliminare di creazione di un circuito, fisico o virtuale, su cui instradare l'intero flusso dati in modo predeterminato e ordinato nel tempo (sequenziale). Servizi non preceduti dunque da handshaking. UDP è un protocollo connectionless: suddivide il flusso di dati in entità in pacchetti che vengono instradati singolarmente in modo indipendente l'uno dall'altro, senza interazioni di ritorno tra sorgente e destinatari/o (per esempio per verificare se il destinatario è raggiungibile) e senza controllo sulla corretta sequenza temporale di inoltro. Fornisce quindi: trasferimento di dati non affidabile; nessun controllo di flusso (velocità di invio fissa) e nessun controllo della congestione. CONFRONTO TCP/UDP: TCP è un protocollo orientato alla connessione, pertanto per stabilire, mantenere e chiudere una connessione, è necessario inviare pacchetti di servizio i quali aumentano l'overhead di comunicazione. UDP invece è senza connessione ed invia solo i datagrammi richiesti dal livello applicativo. UDP non offre nessuna garanzia sull'affidabilità della comunicazione ovvero sull'effettivo arrivo dei datagrammi, sul loro ordine in sequenza in arrivo, al contrario il TCP tramite i meccanismi di acknowledgement e di ritrasmissione su timeout riesce a garantire la consegna dei dati, anche se al costo di un maggiore overhead (raffrontabile visivamente confrontando la dimensione delle intestazioni dei due protocolli). L'oggetto della comunicazione di TCP è il flusso di byte mentre quello di UDP è il singolo datagramma. L'utilizzo del protocollo TCP rispetto a UDP è, in generale, preferito quando è necessario avere garanzie sulla consegna dei dati o sull'ordine di arrivo dei vari segmenti (es. nel caso di trasferimenti di file). Al contrario UDP viene principalmente usato quando l'interazione tra i due host è idempotente o nel caso si abbiano forti vincoli sulla velocità e l'economia di risorse della rete (es. instant messaging, streaming audio/video). TCP non offre garanzia di banda e ritardo minimi. Perchè uno, perchè l’altro: le applicazioni hanno dei requisiti da soddisfare affinchè possano funzionare correttamente. In base ai tipi di requisiti si sceglie il protocollo di comunicazione più adatto. Requisiti: PERDITA; alcune applicazioni sono tolleranti (es. streaming audio/video) alla perdita di pacchetti, altre (es. transazioni online) richiedono
  6. 6. affidabilità totale. BANDA alcune apllicazioni (es. quelle multimediali) richiedono una banda minima, altre (elastiche) usano la banda a disposizione.RITARDO alcune appl (es. telefonia internet) richiedono una banda minima per funzionare. Alcuni requisiti sono determinati da esigenze percettive umane. *COMMUTAZIONE DI PACCHETTO/DI CIRCUITO: La commutazione è l’operazione che predispone il percorso che le informazioni emesse dal mittente devono seguire per raggiungere il destinatario. La commutazione di circuito (circuit switching) è utilizzata nelle linee telefoniche di natura analogica e prevede una connessione tra due nodi della sottorete realizzata attraverso un cammino fisico scelto, nodo per nodo, con assegnate modalità di instradamento. Il messaggio rimane compatto e gli viene assegnato un percorso riservato unicamente ad esso fino al termine della trasmissione. Il vantaggio è di avere la garanzia che, una volta stabilita la chiamata, questa godrà per tutta la sua durata delle prestazioni richieste (banda passante, ritardo costante). L'eventuale frazione di capacità trasmissiva non utilizzata (es. le pause di una conversazione telefonica) è persa, e questo è uno dei grossi limiti della commutazione di circuito. La commutazione di pacchetto (packet switching) è una tecnica che si basa sulla suddivisione del messaggio da trasmettere in più unità autonome, i pacchetti, ciascuna corredata delle opportune informazioni di controllo, es. gli identificativi del mittente e del destinatario e del numero d’ordine del pacchetto all’interno dell’intero msg. Questa tecnica è utilizzata in ambito strettamente digitale e deve esistere una capacità di instradamento autonoma allocata nei singoli organi di commutazione della rete detti nodi. Tipico della comunicazione di pacchetto è il disordine nell’arrivo dei pacchetti che in genere non crea nessun problema, anzi viene usato come strumento di controllo per il corretto arrivo dei dati. i pacchetti viaggiano autonomamente quindi può succedere che pacchetti appartenenti ad uno stesso file seguano percorsi diversi. Infatti quando un nodo intermedio riceve un pacchetto decide qual è il percorso migliore che il pacchetto può prendere per raggiungere la sua destinazione. Questa strada può cambiare da pacchetto a pacchetto dipendentemente dalle condizioni di congestione della rete. i pacchetti, proprio in virtù dei propri diversi percorsi possono giungere a destinazione in un ordine diverso; vengono poi riassemblati nella loro forma originale quando arrivano sul computer di destinazione. La commutazione di pacchetto permette quindi a più utenti di inviare informazioni attraverso la rete in modo efficiente e simultaneo, risparmiando tempo e costi sulle linee trasmissive. Infatti una rete a commutazione di pacchetto, permettendo a più comunicazioni la condivisione di uno stesso canale trasmissivo (cavo elettrico, etere, fibra ottica, ecc.), consente a tutti i computer connessi di condividere la capacità trasmissiva della rete (utilizza meglio la rete). Mentre in una rete a commutazione di circuito la capacità del canale trasmissivo è interamente dedicata ad una specifica comunicazione. SOCKET (letteralmente “presa”) rappresentazione a livello software utilizzata per interfacciare i due terminali (endpoint) in gioco in una connessione tra due computer. In altre parole, potremmo considerare i socket come delle prese (una per ogni macchina) che siano interconnesse tra loro attraverso un ipotetico cavo in cui passi il flusso di dati che i computer si scambiano. Es: pensare ai socket come alle prese telefoniche presenti ai due capi opposti durante una conversazione al telefono. Le due persone che colloquiano al telefono comunicano attraverso le rispettive prese. La conversazione, in tal caso, non finirà finché non verrà chiusa la cornetta e fino ad allora la linea resterà occupata. I protocolli coinvolti nell’implementazione dei Socket sono TCP e UDP. Funzioni per TCP/IP: 1) per stabilire una connessione: socket à crea una nuova socket; connect à Lato client: stabilisce la connessione con il server indicando indirizzo e porta del processo da connettere; bind à Associa una socket a una porta; listen à Lato server: rende una socket passive,cioè in grado di ricevere richieste di connessione; accept à Lato server: Accetta connessioni su socket passive. L’effetto è la creazione di una nuova socket che verrà usata per la comunicazione. 2) dopo la connessione: write à Per scrivere sequenze di byte, cioè inviare messaggi; read à Per leggere sequenze di byte, cioè ricevere messaggi; close à Chiude la comunicazione rilasciando la socket. [queste funzioni sono le API di internet – API: application Programming Interface. Sono le stesse funzioni usate per gestire i dati]. *STRATIFICAZIONE PROTOCOLLARE Le reti sono complesse e contengono molti elementi: host, router, link fisici dalle caratteristiche diverse, applicazioni, protocolli, hardware, software. I sistemi sono complessi: la stratificazione permette una più facile organizzazione e individuazione delle funzionalità. La modularità facilita la manutenzione e la modifica dei sistemi. La modifica dell’implementazione dei servizi resi da uno strato è trasparente (non si modifica l’interfaccia). 5 strati o livelli: 1) application: supporto per le applicazioni di rete (ftp, smtp, http) 2) transport: trasferimento dati end-to-end (tcp, udp) 3) network: trasferimento di datagrammi da sorgente a destinazione (ip, routing protocols) 4) link: trasferimento di dati tra elementi di rete adiacenti (ppp, ethernet) 5) physical: bit “sul cavo”. COMUNICAZIONE TRA ELEMENTI IN RETE ogni componente di rete ha delle componenti che implementano le funzionalità di alcuni o tutti gli starti della rete. Es. Host (computer) implementano funzionalità di tutti gli strati. COME FUNZIONA LA COMUNICAZIONE ogni strato riceve dati
  7. 7. dallo strato superiore (in invio) o inferiore (in ricezione). Aggiunge (in invio) o toglie (in ricezione) l’header aggiunto dallo strato corrispondente e passa il datagramma al livello inferiore (in invio) o superiore (in ricezione). EVOLUZIONE WEB Web 1.0, portali: siti che costituiscono porte di accesso ad un gruppo consistente di risorse internet di vario tipo, spesso organizzati per canali tematici. Predecessori dei motori di ricerca, modello finito nel 2000. Possono essere generalisti o verticali, spesso personalizzabili sulla base di singole esigenze. Web 2.0 slogan che identifica un grande cambiamento nel web. Si iniziano a mettere sul web delle applicazioni, si creano pagine dinamiche. Grande cambio del web: si inizia ad inserire logica nel server. Questi vantaggi non sono funzionali perchè che siano pagine statiche o dinamiche, se rispondono entrambe alle richieste, funzionalmente non ci sono differenze. Requisito funzionale è lo scopo ultimo, ma oggi la differenza la fa il modo in cui vengono svolte le operazioni per soddisfare i requisiti funzionali. Il vantaggio sta nella flessibilità di queste nuove pagine, la possibilità di di poter fare di tutto con piccoli cambiamenti. Caratteristiche Web 2.0: piattaforme che consentono una forte interazione tra utenti; utenti usufruiscono di servizi innovativi mediante potenti interfacce grafiche. Gli utenti forniscono il valore aggiunto con l’autoproduzione di contenuti e la condivisione della conoscenza. Si sfrutta e si valorizza l’intelligenza collettiva, vero motore del Web 2.0 (autoproduzione di contenuto + condivisone della conoscenza). I servizi offerti vengono aggiornati di continuo, in modo da correggere rapidamente gli errori e aggiungere nuove funzionalità non appena disponibili. Caratteristica fondamentale quindi: centralità + protagonismo dell'utente che da fruitore diviene sempre più un controllore dei propri dati e dei contenuti che naviga, facendosi stesso produttore di info e, contemporaneamente, principale giudice di quanto prodotti da altri. Si passa dalla comunicazione "da uno a molti" a quella "da molti a molti": il web 2.0 ribalta i paradigmi di comunicazione classica. Nel web 1.0 gli editori pubblicano i contenuti, modello di comunicazione adottato: “pochi a molti” (portale). Nel Web 2.0 si forma il concetto di comunità online tra utenti, distinte in base al modello di comunicazione adottato: “uno a uno”(e-mail istant messaging) “uno a molti” (blog) “molti a molti” (wiki e blog). Elemento tecnologico innovativo di rilievo è l’assemblaggio (Innovation in Assembly) di tecnologie e servizi preesistenti, i mash-up, che hanno il vantaggio di essere semplici da realizzare e di non aver bisogno di conoscenze informatiche approfondite. Combinazione di vecchie tecnologie e standard (come HTML, CSS, XML, JavaScript, DOM) per realizzarne di nuove (come AJAX), che consentono lo sviluppo di applicazioni Web di nuovo tipo, le RIA. Un es. di mashup è dato dall’unione di Google Maps e Flickr che consente di visualizzare su una mappa le foto relative alla zona selezionata. In sintesi, web 1.0: contenuti generati da pochi; Taxonomy; Navigazione: menu; Interazione utente/sito; Online quando serve; Pesantezza (browser con plug-in, computazione fatta dal client); Banda stretta; Servizi “chiusi” non si integrano; E-commerce (si paga); Release successive // web 2.0: User generated content; Folksonomy (categorizzazione dell’info proposta dagli utenti); Navigazione: ricerca e consigli peer; Social network; Sempre online; Leggerezza (funzioni server side); Banda larga; Servizi aperti, integrazione (mashup); Freemium (non si paga); “Perpetual beta”. Il prossimo passo è il web sematico: l’idea chiave è quella di associare opportuni metadati ai contenuti del web in modo da ottenere classificazione rigorosa + possibilità di ottenere info certe (certificate). APPLICAZIONI WEB BASED: Il web è basato su Internet, quindi l’ambiente è standard (TCP/IP); ha una larga diffusione ed è indipendente dalla piattaforma. Ha un’interfaccia grafica (browsers) che definisce modi di interazione standard, è quindi semplice da usare. Ha un’infrastruttura completa: supporta sistemi aperti (si possono aggiungere/togliere componenti senza alterare la struttura del sistema) e sono disponibili strumenti sempre più potenti per elaborazioni complesse lato server e lato client (evoluzioni di HTML, CGI, JavaScript, Java, ecc). Le applicazioni web based comunicano via HTTP non via TCP (livello applicativo); girano su client e su server. 1) vantaggi applicazione web: Nessun software da installare nel proprio PC; Utilizzabile da qualsiasi punto della rete dalla quale sia accessibile il server; Sempre aggiornata (tutti gli utenti condividono la stessa installazione, questa è sempre l’ultima versione per tutti); Possibilità di integrazione: uso più applicazioni per ottenere un risultato; Possibilità di collaborazione (web 2.0, es. wikipedia) e 2) svantaggi: Impossibilità di utilizzare l'applicazione se la rete è fuori servizio; Transito in rete di dati sensibili/personali. Un’applicazione web fornisce all’utente, per mezzo dell’infrastruttura web: servizi (ricerca, home banking, commercio elettronico, ecc) e info dinamiche attraverso pagine costruite in base all’interazione con l’utente stesso. Problema: L’infrastruttura web si basa sul protocollo HTTP, che non prevede lo sviluppo di applicazioni che coinvolgano una fase di elaborazione oltre che di passaggio di dati. Occorre costruire una architettura più complessa di quella client/server basato su HTTP: per realizzare un’applicazione, oltre a client/server serve un’application server a supporto del Web Server. Un’Application server è caratterizzato dal protocollo di interazione con il Web Server e l’interazione con il client è sempre HTTP. Web e application server seguono quindi un modello logico, sono entrambi programmi, servono entrambi richieste. La computazione, che avviene lato server, può avvenire
  8. 8. tramite PROGRAMMI COMPILATI: il web server invoca, su richiesta del client, un eseguibile, che può essere scritto in un qualsiasi linguaggio che supporti l’interazione con il web server, es. Java, C#, C++. O tramite SCRIPT INTERPRETATI: il web server ha un motore in grado di interpretare il linguaggio di scripting usato (PHP, Pyton e Perl). Questo implica: velocità di esecuzione ridotta (compilazione durante l’esecuzione) ma facilità di scrittura programmi e portabilità (possono essere eseguiti su macchine diverse, basta che sia presente un motore di scripting). CGI Common Gateway Interface: È un’Application Server molto elementare, definisce le caratteristiche dei programmi lato server e le modalità con cui i dati vengono trasferiti tra Web Servers e programmi. Un’applicazione CGI è un programma che legge una REQUEST ed elabora una RESPONSE, I msg sono in formato HTTP. Vantaggi: scrittura applicazioni web in modo efficiente ed ottimizzato; si può utilizzare qualsiasi linguaggio di programmazione. Svantaggi: è poco flessibile, se si cambiano i dati in quantità e tipo occorre riscrivere sia la parte di elaborazione che l'interfaccia col web server; richiede la realizzazione di tutti gli aspetti dell’applicazione (un Application Server vero e proprio fornisce maggior supporto). ARCHITETTURA CGI: 1) nel caso di un eseguibile il web server lancia lo specifico processo che esegue l’applicazione richiesta. 2) nel caso di applicazioni interpretate (simile alle macchine virtuali) viene usato un interpreteper lo scripting (in PHP, Pyton e Perl) web server lo lancia all’interprete che si occuperà di eseguire lo specifico programma. Quindi: web browser richiede script, nel web server viene individuato lo script, analizzato e tramite il parser del linguaggio viene generata la pagina HTML da fornire al browser che l’ha richiesta. MODELLO SERVLET/JSP [pag.9] JavaServer Pages è una tecnologia di programmazione web in Java per lo sviluppo di applicazioni web che forniscono contenuti dinamici in formato HTML o XML. La scrittura di apllicazioni JSP richiede la definizione di pagine HTML contentente istruzioni in Java; Le pagine vengono tradotte in Servlet (programmi Java con una struttura speciale); supporto all’esecuzione di JSP fornito da application server (come Tomcat). REQUEST e RESPONSE HTTP vengono tradotte in strutture dati in Java (classi pre-esistenti. HTTPServletRequest e HTTPServletResponse) che vengono manipolate. à APPLICAZIONI WEB (a e c) suddividono così il carico di lavoro perchè il bilanciamento dell’esecuzione fra client e server migliora le prestazioni e permette la personalizzazione delle applicazioni. Prestazioni: Alleggerire il server da computazioni elementari (es. controllo ortografico); Ridurre traffico di rete. Personalizzazione: scelta dell’organizzazione dei dati sulla pagina (es. scelta dei colori, dei dati visualizzati, ecc); Carico incrementale dei dati (no necessario caricare un’intera pagina ma solo dati che servono ad aggiornare una parte dei dati). AJAX Asynchronous Javascript and XML: è una tecnica (estensione di javascript) di sviluppo software per la realizzazione di applicazioni web interattive (RIA). Tecnologia (ma anche una metodologia e un modello d’implementazione) composta da una serie di strumenti già esistenti, che uniti insieme danno vita ad un potente modello di iterazione. Come metodologia richiama le funzioni RIA, portando piccole parti di dati piuttosto che ricaricare l’intera pagina, dal punto di vista implementativo riguarda più da vicino l’interfaccia utente UI e il rapporto sistema/utilizzatore. Tecnologie Ajax comprendono: HTML, usato x costruire le pagine web e identificare i campi per il successivo uso nel resto dell'applicazione. Un display dinamico di iterazione DOM (Document Object Model). DOM è utilizzato (tramite Javascript) per manipolare sia la struttura della pagina HTML sia le risposte XML restituite dal server DHTML o Dynamic HTML che aiuta a caricare i form in modo dinamico (aggiornamento dinamico delle pagine) con comandi come div, span e altri elementi HTML. JavaScript, cuore del codice tramite cui funzionano le Architetture multilivello !  Alternative per applicazioni client-server (a) – (e) !  Le applicazioni Web sono di tipo (a) – (c) 50 1-29 Modello Ajax 54
  9. 9. applicazioni Ajax ed è di supporto per la comunicazione con le applicazioni server. CONFRONTO CON ARCHITETTURE WEB APPLICATION STANDARD termine ASINCRONO significa che si ottiene la risposta da parte del server quando disponibile, senza aspettare l’apertura di una nuova pagina. Il modello di una classica applicazione web fa in modo che le azioni dell’utente diano il via ad una richiesta, veicolata dal protocollo HTTP verso il server. Questo elabora i dati e restituisce i risultati al cliente, con una pagina HTML. Così l’esperienza dell’utente è completamente ai margini. Utente non dovrebbe bloccare le proprie azioni ogni volta che l’applicazione richieda info al server, ne dovrebbe percepire la richiesta stessa. Un’applicazione Ajax elimina la tradizionale natura d’iterazione INIZIO-FINE/INIZIO-FINE, creando la figura di un mediatore tra l’utente e il server: intermediario è il motore Ajax, che viene caricato dal browser al principio della sessione di lavoro e si sostituisce ad una classica pagina web. Il motore, che consiste di funzioni JavaScript e non richiede alcun plug-in o installazione da parte dell’utente, è responsabile della comunicazione tra utente e server e si occupa sia di ciò che deve apparire sull’interfaccia utente, sia di trasmettere le richieste al server con linguaggio XML. Grazie a questo sistema, l’iterazione ha luogo asincronicamente, cioè in modo indipendente dall’attività del server. L’utente non si troverà di fronte a pagine bianche e non percepirà il lavoro svolto dalla trasmissione per mezzo dei protocolli. Se nelle tradizionali applicazioni web, le azioni dell’utente generano una richiesta HTTP, con le applicazioni Ajax l’evento è una chiamata da parte di JavaScript al motore Ajax. Questo passo intermedio permette di evitare il rinvio al server se la richiesta di dati può essere fornita dal motore stesso. In caso contrario il motore comunicherà “asincronicamente” con il server. PRO E CONTRO AJAX le applicazioni AJAX devono essere testate su più browser per verificarne la compatibilità + è richiesto che nel client sia attivato Javascript. Il vantaggio di usare AJAX è la grande velocità alla quale un'applicazione risponde agli input dell'utente. Un problema è che, senza l'adozione di adeguate contromisure, le applicazioni AJAX possono rendere non utilizzabile il tasto "indietro" del browser: con questo tipo di applicazioni non si naviga da una pagina all'altra, ma si aggiorna di volta in volta una singola parte del medesimo documento. Proprio per questo i browser, che sono programmi orientati alla pagina, non hanno possibilità di risalire ad alcuna di tali versioni "intermedie". JAVASCRIPT è un linguaggio di scripting orientato agli oggetti. È interpretato dal browser, lato client (= codice non viene compilato, ma interpretato: l'interprete è incluso nel browser che si sta utilizzando). In JavaScript lato client, il codice viene eseguito direttamente sul client e non sul server. Il vantaggio di questo approccio è che, anche con la presenza di script particolarmente complessi, il web server non viene sovraccaricato a causa delle richieste dei clients. Di contro, nel caso di script che presentino un codice sorgente particolarmente grande, il tempo per lo scaricamento può diventare abbastanza lungo. Può definire un oggetto capace di effettuare richieste in HTTP al server, in maniera trasparente all'utente. Originariamente tale oggetto era stato pensato per ottenere documenti XML. Una volta ottenuti dei dati XML (da un’applicazione Web), è possibile cambiare certe parti della pagina già caricata utilizzando le capacità di Javascript di modificare gli elementi del DOM. Javascript più richiedere anche dati come testo semplice e HTML. DOM Document Object Model: modello a oggetti del documento, è una forma di rappresentazione dei documenti strutturati come modello orientato agli oggetti. PARADIGMA A OGGETTI: oggetto = struttura composta da dati + operazioni che possono essere fatti su quei dati. I dati sono le informazioni che caratterizzano un oggetto (definiscono un modello dell’oggetto) i metodi descrivono le operazioni che si possono applicare all’oggetto stesso (e quindi ai suoi dati). I metodi definiscono l’interfaccia di un oggetto. Un metodo è definito da un nome e dai parametri (i dati usati dal metodo per eseguire l’operazione desiderata). Una classe implementa una interfaccia associando ai metodi i programmi che realizzano le operazioni. Un oggetto è un’istanza (una realizzazione concreta) di una classe (che ne è quindi la sua descrizione). Ogni oggetto può: usare un altro oggetto, lo ingloba come un proprio dato e può accedervi tramite I suoi metodi; ereditare da un altro oggetto le sue proprietà (relazioni tra oggetti). JAVA SERVLET applicazioni lato server dotate di una interfaccia standard, il che le rende limitate (non posso fare ciò che voglio) ma semplici (basta realizzare le parti mancanti). Sono residenti in memoria, cioè mantengono uno stato (posso realizzare delle sessioni) e consentono interfaccia con altre servlet. Vantaggi: più efficienti e potenti delle CGI in quanto utilizzano un linguaggio e un ambiente completo (Java); consentono di integrare sistemi e applicazioni dando accesso via web. Una servlet è un componente gestito in modo automatico da un container (engine). L’interfaccia definisce un set di operazioni predichiarate e (ri)definibili di volta in volta. Container controlla le servlet (attiva/disattiva) in base alle richieste dei client (le chiama in modo intelligente). Ogni servlet implementa l’interfaccia javax.servlet.Servlet con 5 metodi: 1) init: Inizializza la servlet 2) destroy: chiamata quando la servlet termina (es. per chiudere un file o una connessione con un database) 3) getServletConfig: Restituisce i parametri di inizializzazione e il ServletContext che da accesso all’ambiente 4) getServletInfo: restituisce informazioni tipo autore e versione 5) service: invocato per gestire le richieste dei client. L’interfaccia è solo la dichiarazione dei metodi che, per essere utilizzabili, devono essere implementati in una classe (implementare = associare il codice, cioé le
  10. 10. istruzioni, che definiscono il compito assegnato al metodo). Sono presenti 2 CLASSI ASTRATTE: javax.servlet.GenericServlet e javax.servlet.http.HTTPServlet permettono di creare servlet implementando solo I metodi che di fatto servono, facilitando di molto la scrittura vera e propria delle servlet. HTTPServlet implementa il metodo service in modo da legare le invocazioni al protocollo HTTP (ai tipi GET, POST, ecc), cioè: doGet, processa le richieste GET e doPost processa le richieste POST. Anche i paramentri (HTTPServletRequest e HTTPServletResponse) sono stati adattati al protocollo HTTP, cioè consentono di costruire dei msg HTTP specificando i dati da inserire nell’head e nel body. HTTPServletRequest: viene passato un oggetto da service; Contiene la richiesta del client; Estende ServletRequest. HTTPServletResponse: Viene passato un oggetto da service; Contiene la risposta per il client; Estende ServletResponse. Una servlet viene creata dal container quando viene effettuata la prima chiamata. Viene invocato il metodo init()per inizializzazioni specifiche. Una servlet viene distrutta, invocando il metodo destroy() quando non ci sono servizi in esecuzione e quando è scaduto un time out predefinito. Server può anche restituire cookie (stringhe di carattere che permettono di gestire la sessione) insieme alle risposte, inserendole nell’header. HTTPsession: gestito direttamente dal container, sopperisce alla non persistenza di HTTP. *JSP/SERVLET Nella servlet la logica per la generazione del documento HTML è implementata completamente in Java: il processo di generazione delle pagine è lungo e passibile di errori, è scomodo aggiornare la struttura delle pag quando necessario. Le JSP nascono per facilitare l’aggiornamento delle pagine: è possibile produrre pagine senza la necessità di conoscere i dettagli della logica server side, la generazione di codice dinamico è implementata sfruttando un linguaggio di scripting. Di default si utilizza Java, il codice delle JSP viene compilato in Servlet. Vantaggi di JSP: contenuti sono separati dalla logica di presentazione; lo sviluppo delle applicazioni è semplificata rispetto alla programmazione tramite servlet; manutenzione delle JSP è automatica. Le JSP vengono ricompilate “automaticamente” quando sono apportate modifiche alla pagina; l’authoring delle pagine è particolarmente semplice; essendo compilate in servlet anche le JSP sono portabili. Limiti Servlet: le servlet forniscono un adeguato supporto per la generazione di pagine dinamiche ma hanno svantaggi: per generare le pagine (anche gli elementi statici) bisogna scrivere del codice; ogni modifica alla pagina richiede la ricompilazione e l’installazione della nuova release della servlet; la compilazione e l’installazione può essere tediosa. Dunque, le JSP non rendono inutili le servlet: le servlet forniscono agli sviluppatori delle web application un completo controllo dell’applicazione. Se si vogliono fornire contenuti differenziati a seconda di diversi parametri (quali l’identità dell’utente, ecc) può essere conveniente lavorare con le servlet. Le JSP rendono invece molto semplice presentare documenti HTML o XML all’utente. Servlet e JSP sono perciò usate congiuntamente in applicazioni strutturate in accordo al modello Model-View-Controller (MVC*). Nel contesto della piattaforma Java, la tecnologia JSP è correlata con quella delle servlet: all'atto della prima invocazione, le pagine JSP vengono infatti tradotte automaticamente da un compilatore JSP in servlet. Una pagina JSP può essere vista come una rappresentazione ad alto livello di una servlet. Per via di questa dipendenza concettuale, anche l'uso della tecnologia JSP richiede la presenza, sul Web server, di un servlet container, oltre che di un server specifico JSP, il motore JSP (che include il compilatore JSP); in genere, servlet container e motore JSP sono integrati in un unico prodotto (es. Tomcat svolge entrambe le funzioni). JSP è una tecnologia alternativa rispetto a numerosi altri approcci alla generazione di pagine Web dinamiche, per esempio PHP, o ASP o la più tradizionale CGI. Differisce da queste tecnologie non tanto per il tipo di contenuti dinamici che si possono produrre, quanto per l'architettura interna del software che costituisce l'applicazione Web. JSP Tecnologia per la creazione di applicazioni web, specifica l’interazione tra un contenitore/server ed un insieme di “pagine” che presentano informazioni all’utente. Queste pagine sono costituite da tag tradizionali (HTML, XML, WML) e da tag applicativi che controllano la generazione del contenuto. Rispetto ai servlet, facilitano la separazione tra logica applicativa e presentazione. Analogo alla tecnologia Microsoft Active Server Page (ASP) ma, mentre una Java Server Page chiama un programma Java eseguito sul Web server, una ASP contiene uno script VBScript o Jscript. Un file JSP viene prima compilato e la versione compilata viene tenuta in memoria per rendere più veloce una successiva richiesta della pagina. Gli elementi di una JSP sono: 1) Template text: le parti statiche della pagina. I contenuti statici sono porzioni della pagina JSP che devono essere mantenute integralmente nella pagina Web generata dinamicamente, senza alcuna elaborazione. Devono pertanto essere scritte nel linguaggio di tag di cui il client può usufruire direttamente, per esempio HTML (se il client è un browser) WML (se il client è un cellulare che accede alla pagina in WAP) o XML (vari tipi di client). 2) Commenti <%-- commento --> 3) Direttive <%@direttiva%> Le direttive JSP si possono interpretare come comandi rivolti al motore JSP. Questi comandi vengono eseguiti in una fase di preprocessing, prima che siano elaborate le porzioni della pagina contenenti script. Sono: a) page liste di attributi/valore, valgono per la pagina in cui sono inseriti, es <%@
  11. 11. page import="java.util.*" buffer="16k" %> <%@ page import=“java.math.*, java.util.*” %> b) include include in compilazione pagine HTML o JSP <%@ include file="copyright.html" %> c) taglib dichiara tag definiti dall’utente implementando opportune classi d) forward determina l’invio della richiesta corrente, eventualmente aggiornata con ulteriori parametri, all’URL indicata, es. <jsp:forward page=“login.jsp” %> e) include: invia dinamicamente la richiesta ad una data URL e ne include il risultato, es. <jsp:include page=“login.jsp” %> f) useBean: localizza e distanzia (se necessario) un javaBean nel contesto specificato. Il contesto può essere la pagina, la richiesta, la sessione, l’applicazione. Es. <jsp:useBean id=“cart” scope=“session” class=“ShoppingCart” />. 4) Azioni: in XML <tag attributes>body</tag> 5) Elementi di scripting: istruzioni nel linguaggio specificato nelle direttive. Sono: a) Declaration <%! declaration [declaration] ...%> Variabili (che valgono per la durata della servlet) o metodi usati nella pagina, essi andranno a far parte della classe "servlet" generata dal compilatore JSP, la loro posizione all'interno del testo della pagina JSP è irrilevante. b) Expression <%= expression %> Una espressione nel linguaggio di scripting che viene valutata e sostituita con il risultato (il risultato viene convertito in stringa, e la stringa immersa nel codice HTML/XML nel punto corrispondente a quello dove compariva l'espressione stessa). c) Scriptlet <% codice %> Frammenti di codice che controllano la generazione della pagina, valutati alla richiesta. Le variabili valgono per la singola esecuzione, ciò che viene scritto sullo stream di output sostituisce lo scriptlet. Si può immaginare che durante la costruzione della pagina Web dinamica, il motore JSP includa senza elaborazioni i contenuti statici, procedendo dall'alto verso il basso nel documento, ed esegua immediatamente eventuali scriptlet incontrati durante l'operazione. Tecnicamente, questi scriptlet vengono inclusi nei metodi del servlet generato dalla pagina JSP, all'interno dei metodi che producono la risposta a una richiesta HTTP. Linguaggio di script ha lo scopo di interagire con oggetti java e gestire le eccezioni java. Gli oggetti impliciti sono gli elementi delle servlet (sono9, es. request, response, out, page). Tali oggetti possono essere creati: 1) implicitamente usando le direttive JSP 2) esplicitamente con le azioni 3) direttamente usando uno script (raro). Gli oggetti hanno un attributo che ne definisce la visibilità: scope. Visibilità crescente da page a request a session e a application. Sessione: da la possibilità di gestire efficientemente i cookie (come per le servlet), esiste un oggetto session implicito che può essere utilizzato per la sessione: utilizza lo stesso sistema delle servlet; sessione server side; la sessione scade dopo un determinato time-out. Tutte le JSP che partecipano alla gestione della sessione di interazione con un utente possono memorizzare informazioni nell’oggetto implicito session. Attenzione alla memoria richiesta per la gestione della sessione degli utenti ed al tempo in cui questa è mantenuta. FUNZIONAMENTO JSP Il client richiede via HTTP un file .JSP. Il file .JSP viene interpretato e accede a componenti lato-server (Java Beans, Servlet) che generano contenuti dinamici. il risultato viene spedito al client sotto forma di pagine HTML. La richiesta viene inviata ad un Java Servlet che genera i dati dinamici richiesti dall’utente. Il Servlet richiama un file .jsp, che si occupa di formattare in HTML i risultati e inviarli all’utente. JAVABEAN sono classi scritte in Java secondo una particolare convenzione. Sono utilizzate per incapsulare più oggetti in un oggetto singolo (il bean), cosicché tali oggetti possano essere passati come un singolo oggetto bean invece che come multipli oggetti individuali. Al fine di funzionare come una classe JavaBean, una classe di un oggetto deve obbedire a certe convenzioni in merito ai nomi, alla costruzione e al comportamento dei metodi. Queste convenzioni rendono possibile avere tool che possono usare, riusare, sostituire e connettere JavaBean. Le convenzioni sono: la classe deve avere un costruttore senza argomenti; le sue proprietà devono essere accessibili usando get, set, is e altri metodi (metodi accessori) seguendo una convenzione standard per i nomi; la classe dovrebbe essere serializzabile (capace di salvare e ripristinare il suo stato in modo persistente); non dovrebbe contenere alcun metodo richiesto per la gestione degli eventi. Lo scope determina la vita del bean: page è lo scope di default (viene messo in pageContext ed acceduto con getAttrubute) request (viene messo in ServletRequest ed acceduto con getAttrubute) session e application: se non esiste un bean con lo stesso id, ne viene creato uno nuovo. Il type permette di assegnargli una superclasse (al posto della classe si puo’ usare il nome del bean. beanName="nome" nome è la classe o un file serializzato). È raccomandabile usare MVC con le pagine JSP in modo da dividere il livello di presentazione da quello dell'elaborazione della request e dalla memorizzazione dei dati. Le normali servlet o pagine JSP dedicate vengono utilizzate per processare i dati. Dopo che l'eleborazione è terminata, il controllo passa ad una pagina JSP che serve solo a visualizzare l'output. Quest'ultima pagina JSP dovrebbe contenere solo HTML, XML e action e tag JSP; la pagina dovrebbe far uso dei JavaBeans per ottenere i dati. Quindi, nello sviluppo di un'applicazione web la convenzione vuole che nelle JSP ci sia meno codice Java possibile e quello presente vada a richiamare codice Java nativo (oggetti e metodi) implementato in classi separate
  12. 12. apposite dette appunto JavaBeans. Questa separazione consente infatti un facile riuso di codice dei Java beans una volta richiamato in un qualsiasi punto richiesto dell'applicazione web. MVC: è un pattern architetturale molto diffuso nello sviluppo di sistemi software, soprattutto nella programmazione orientata agli oggetti, in grado di separare la logica di presentazione dei dati dalla logica di business. Il pattern è basato sulla separazione dei compiti fra i componenti software che interpretano 3 ruoli principali: 1) il model fornisce i metodi per accedere ai dati utili all'applicazione (è JAVABEAN) 2) il view visualizza i dati contenuti nel model e si occupa dell'interazione con utenti e agenti (è JSP) 3) il controller riceve i comandi dell'utente (in genere attraverso il view) e li attua modificando lo stato degli altri 2 componenti (è la SERVLET). SOA E WEB SERVICE Un servizio è un componente software che esegue task (compiti) predefiniti ed è dotato di contratti/interfacce pubblici. Può essere visto semplicemente come la caratterizzazione astratta e l'incapsulamento in un'interfaccia di uno specifico contenuto o risorsa o capacità di elaborazione. Es. capacità di spostare file, creare processi, fornire informazioni, ecc. Altra def: procedura, metodo o oggetto con una interfaccia pubblica e stabile che può essere invocato da un client. Sia la richiesta sia l’esecuzione del servizio impongono che vi sia un programma che ne “chiama” un altro. L'interfaccia di un servizio è: il protocollo (come interagire con il servizio) da usare per interagire con esso; il formato dei dati scambiati (come sono strutturati i dati scambiati) e il comportamento atteso a seguito dei diversi scambi di messaggi (che cosa il servizio fa). Caratteristiche: utilizzatore li vede come black-box; sono indipendenti da piattaforma; hanno un’alta interoperabilità (possono agevolmente scambiarsi informazioni da usare ognuno nella propria elaborazione). Le azioni svolte da un servizio creano un insieme coerente dal punto di vista sia dell’utilizzatore sia del fornitore. SERVICE ORIENTATION indica l’integrazione di differenti applicazioni presentate come servizi. SOA service oriented architecture: particolare architettura che sfrutta i principi della service orientation. Filosofia di progetto: i processi di business sono sempre più estesi nel mercato globale e coinvolgono numerose e svariate parti di una o più imprese. Si devono poter cambiare rapidamente e a basso prezzo le modalità del business (quello che si fa, gli strumenti usati) e le persone coinvolte. Composite application: insieme di servizi collegati e integrati a supporto di un processo di business (ciò che produce un output che crea profitto). Attori: offerente; colui che offre il servizio a terzi. Sa dell’esistenza di un terzo quando questo gli richiede il servizio. Richiedente: colui che necessita/richiede un servizio per raggiungere un obiettivo prefissato. Non ha conoscenza dei fornitori (solitamente), deve scoprire l’esistenza di un servizio e contattare il fornitore. Componenti: servizio e descrizione dei servizi. Ruoli: service providers, discovery agencies, service requestors. Operazioni: pubblicare, trovare, interagire. Es: io (service requestor) guardo sulle pagine bianche (discovery agency) alla ricerca di una pizzeria a domicilio (service provider). Una volta trovata quella che mi interessa, copio il numero e per avere il servizio ci interagisco cioè chiamo. Principi dell’architettura SOA: minimizzazione della dipendenza (tra servizi); presenza di contratti (relativi a come I servizi devono comunicare); astrazione (servizio come black box, non si sa come lavora); riutilizzabilità (logica è divisa in più servizi per poter essere riusata); compatibilità (I servizi possono essere composti in servizi più complessi); I servizi possono essere scoperti tramite meccasismi noti. SOA ≠ WEB SERVICE: soa è un modello architetturale, I web services sono le migliori tecnologie che implementano I principi della SOA. Web services perchè: per far comunicare 2 applicazioni tramite internet; per costruire programmi tramite composizione di altri programmi; per usare un metodo di comunicazione standardizzato; perchè possono far cambiare radicalmente metodi di sviluppo/funzione delle applicazioni. I punti di forza dei web services sono: 1) interoperabilità dinamica di business: possibilità di costruire dinamicamente nuove partnership in quanto I WS garantiscono iteroperabilità tra sistemi 2) accessibilità: servizi di business sono decentralizzati, distribuiti in rete e possono essere usati da una grande quantità di devices (servizio di business è una delle fasi che compongono un processo di business) 3) specifiche universali: note e accettate, riguardano lo scambio di dati, la scoperta di servizi, descrizione dell’interfaccia, ecc 4) Legacy integration: maggior integrazione coi sistemi legacy, questo garantisce più flessibilità (un sistema legacy è un'applicazione o un componente obsoleto, che continua ad essere usato poiché l'utente - tipicamente un'organizzazione - non intende o non può rimpiazzarlo). Inoltre, un Web service è self-describing (se si pubblica un Web service, si dovrebbe pubblicare anche la sua interfaccia pubblica. L’interfaccia pubblica, scritta in XML, viene utilizzata per identificare tutti i metodi pubblici, gli argomenti dei metodi e i valori di ritorno) ed è discoverable (se si crea un Web service, esiste un meccanismo relativamente semplice che permette la sua pubblicazione. Similmente, esiste un meccanismo semplice che permette, alle parti interessate, di cercare un servizio e localizzare la sua interfaccia pubblica). Web service è un’interfaccia di rete accessibile alle funzionalità di un’applicazione, costruito usando tecnologie standard di Internet. Sono identificati da URI. Definizione (creazione) descrizione e scoperta fatte con XML. Sono una tecnologia che permette alle applicazioni di comunicare tra loro in modo indipendente da piattaforma e linguaggio di
  13. 13. programmazione. Essendo basati su XML per la rappresentazione dei dati per tutti i protocolli e le tecnologie dei Web services, possono raggiungere la più completa indipendenza dal linguaggio di programmazione e dalla piattaforma utilizzata. Sono strutturati a livello, ogni livello ha le sue finalità. Nomi/protocolli/linguaggi per regolamentare/implement varie funzioni. 1)Architettura in base ai ruoli: Service provider è il fornitore del servizio; implementa il servizio e lo rende disponibile su Internet. Da una prospettiva business rappresenta il proprietario del servizio, dal punto di vista architetturale è la piattaforma che ospita l’accesso al servizio. Service requestor è il responsabile dell’invocazione del servizio. Il service requestor localizza il Web service usando il service broker, invoca il servizio richiesto che viene eseguito dal service provider. Da una prospettiva business è il cliente richiedente la soddisfazione di determinate funzioni, da prospettiva architetturale questa è l’applicazione che effettua la ricerca e invoca o inizializza un’interazione con il servizio. Service registry è l’elenco logicamente centralizzato dei servizi. Il registry fornisce un punto centrale dove gli sviluppatori possono pubblicare nuovi servizi e trovarne uno già esistente. Il registry si comporta da intermediario (broker) per le società ed i loro servizi 2)Architettura in base a stack dei protocolli: La pila, ancora in fase di evoluzione, possiede 5 strati principali: Network i web services devono essere accessibili tramite rete per essere invocati da un service requestor. I Web services che sono disponibili comunemente su Internet utilizzano a questo strato HTTP (altri protocolli cmq sono supportati) XML-Based Messaging rappresenta l’uso di XML come protocollo per lo scambio dei messaggi. Il protocollo scelto per lo scambio di messaggi XML è SOAP (standard document-centric utilizzato per ‘avvolgere’ i msg e le chiamate di procedura remota usando XML. Il msg SOAP viene spedito come richiesta HTTP di tipo POST) Service Description strato responsabile della descrizione dell’interfaccia pubblica di un Web service. WSDL è lo standard de facto, basato su XML, per la descrizione di un servizio. Oltre a garantire l’interoperabilità, definisce l’interfaccia e il modo in cui si interagisce con il servizio. Service Publication e Service Discovery rappresenta lo strato responsabile della centralizzazione dei servizi fornendo le funzionalità di pubblicazione e ricerca di un servizio. Attualmente, lo standard utilizzato, basato su XML è UDDI. Service Flow descrive come comunicazioni service-to-service, collaborazioni e flussi sono eseguiti. XML è un linguaggio di markup, permette di: definire tag e loro grammatica (come devono essere strutturati) indipendentemente da sistema usato e dal fornitore. Rispetto all'HTML, l'XML ha uno scopo diverso: il primo definisce una grammatica per la descrizione e la formattazione di pagine web e, in generale, di ipertesti, il secondo è un metalinguaggio utilizzato per creare nuovi linguaggi atti a descrivere documenti strutturati. HTML ha un insieme ben definito e ristretto di tag, con l'XML è possibile definirne di propri a seconda delle esigenze. A supporto di XML ci sono I linguaggi schema (permettono di creare nuovi linguaggi XML): DTD (Document Type Definition) è un documento attraverso cui si specificano le caratteristiche strutturali di un documento XML attraverso una serie di "regole grammaticali". In particolare definisce l'insieme degli elementi del documento XML, le relazioni gerarchiche tra gli elementi, l'ordine di apparizione nel documento XML e quali elementi e quali attributi sono opzionali o meno. XSD (XML Schema) come la DTD, serve a definire la struttura di un documento XML. Tecnica più recente ed avanzata della DTD. XML SCHEMA definisce la struttura che deve avere il documento; definisce gli attributi e gli attributi che possono apparire in un documento, definisce quali elementi sono “figli” e il loro numero; definisce se l'elemento è vuoto o può includere testo; definisce i tipi di dati per gli elementi e gli attributi e definisce valori di default e fissi per elementi e attributi. Migliore di DTD in quanto: XML schema sono estendibili a future aggiunte; sono più ricchi e più utili di DTD; sono scritti in XML; supportano data types e namespace. XML è portable (trasportabile) in quanto un XSD associato ad un documento permette al ricevente di validare (vedere se è strutturato bene) il
  14. 14. documento; in quanto XSD è leggibile/riscrivibile dall’uomo. WSDL Web Service Description Language: linguaggio di definizione dei WS. Basato su XML, fornisce il meccanismo con cui le definizioni dei WS sono rese pubbliche. Non solo descrizione delle procedure d’impiego di un servizio ma definisce anche il protocollo di trasporto. WSDL consente ai Service Providers di fornire il modo in cui le richieste, da inoltrare ai Web services, dovranno essere definite. In un documento WSDL si specificano la locazione fisica e le operazioni disponibili per il servizio descritto. Si ha una descrizione astratta che comprende i tipi, i messaggi e le operazioni e una descrizione concreta che dipende dal binding e dalla posizione in cui si trova il servizio. Svolge in sintesi 3 funzioni fondamentali: WHAT (descrive I msg e I tipi di dati coinvolti durante interazione con WS) HOW (descrive come accedere al WS attraverso il livello ditrasporto – es. con TCP) WHERE (descrive locazione per accedere al WS). I principali tag XML che compongono una descrizione WSDL sono: <types> all'interno sono definiti i tipi di dato complessi utilizzati dal Web service, servendosi della stessa sintassi degli XSD. <message> indica quali sono le parti di cui è composto un msg, che dati verranno comunicati. Un msg può essere composto da 1 o più parti (dati). <portType> raggruppa le operations disponibili per il Web service, elencando per ognuna quali messages ne fanno parte (libreria). Types, message e portType sono il WHAT. <binding> raggruppa un insieme di operazioni e gli assegna un tipo di binding (che indica un portType). È l’HOW. <service> collezione di endpoint; raccoglie tutte le ports del Web service. <port> rappresenta una singola implementazione del Web service: contiene un binding e un indirizzo di rete (al quale le richieste verranno inviate). Service e binding sono il WHERE. WSDL 2.0, cambiamenti: aggiunta di semantiche al linguaggio di descrizione; rimozione dei costrutti dei msg; portTypes rinominate Interfacce; port rinominate endpoint. Problema dei ws: come scoprire partner di business con soluzioni WS compatibili, come far conoscere ai partners I WS di cui dispongo? I web services sono una gran cosa ma il processo di scoperta è difficile. Problema risolto da UDDI. UDDI (Universal Description Discovery and Integration) è un directory service, dove le aziende possono registrare i propri Web services e cercarne altri. Un registro UDDI contiene informazioni riguardanti un insieme di Web services, tra le quali anche la loro descrizione WSDL, e i dati in esso contenuti sono accessibili tramite SOAP. UDDI è stato proposto per fornire uno standard che mettesse in comunicazione le aziende con i clienti e i partners fornendo informazioni riguardanti i propri prodotti e servizi. (È dunque uno degli standard alla base del funzionamento dei Web Service: è stato progettato per essere interrogato da messaggi in SOAP e per fornire il collegamento ai documenti WSDL che descrivono i vincoli protocollari e i formati dei messaggi necessari per l'interazione con i Web Service elencati nella propria directory). Il registro UDDi fornisce tre tipi di servizi: le pagine bianche, comprendono le informazioni di base sui contatti dell'azienda (ragione sociale, indirizzo, codice DUNS) le pagine gialle, comprendono le informazioni sui servizi Web in base alle loro categorie, per consentire, a chi esegue ricerche, di localizzare un certo tipo di servizio (ad esempio produttori di automobili); le pagine verdi comprendono info tecniche sulle funzioni supportate dal servizio Web ospitato dall'azienda (riferimento alle descrizioni dei Web services, localizzazione). Un registro UDDI può essere pubblico o privato. MODELLO UDDI Le specifiche UDDI definiscono 1) l’interfacce Web del servizio: publish API e inquiry API e 2) strutture dati utilizzate: a) Business entity: descrizione di un’azienda o altra organizzazione che fornisce il servizio b) Business service: descrive una collezione di WS collegati offerta da un organizzazione descritta da una Business entity (L’elemento businessService rappresenta un servizio logico di business che pu`o essere erogato in modi diversi. c) Binding template (modello vincolante): descrive info tecniche necessarie per l’uso di un WS (L’elemento bindingTemplate contiene le informazioni tecniche per l’accesso al servizio. Uno stesso servizio logico pu`o essere associato a piu` binding template) d) tModel: e un tipo di dato che permette la definizione di etichette utili alla classificazione delle informazioni caratterizzate da una chiave unica. Attraverso un tModel è possibile definire: technical fingerprints per Web services; namespaces utili per identitificare business entities o per classificare business entities, business service, e tModels. La realtà è che UDDi non è così diffuso anche se ha il supporto di compagnia quali IBM e Microsoft. È molto usato in piccoli ambienti, ma a tale scopo è troppo complesso e fornisce troppi tipi di dato. Microsoft, IBM, ecc hanno spento I loro nodi UDDI pubblici nel 2006. SOAP Simple Object Access Protocol: è un protocollo (per SOA) leggero che permette lo
  15. 15. scambio di messaggi tra componenti software/applicazioni (in ambienti distribuiti) usando protocolli standard di internet. Progettato per essere il più semplice possibile in modo da essere compreso/adottato con semplicità, ma al tempo stesso abbastanza completo da poter trasmettere dati complessi. È basato su XML, gestisce info strutturata e tipata; non definisce alcuna semantica per applicazioni o scambio messaggi, ma fornisce un mezzo per definirla. STRUTTURA un msg SOAP è composto da: 1)Envelope: elemento radice, obbligatorio, che identifica il documento XML come un msg SOAP 2)Header: opzionale. Trasporta info non facenti parte del msg, destinate agli “attori” (varie parti che il msg attraverserà per arrivare al destinatario finale) 3)Body, obbligatorio. Contiene il msg vero e proprio msg che deve essere processato/recapitato + info su chiamate/risposte. Le regole principali che un messaggio SOAP deve seguire sono: deve essere codificato in XML valido; deve far uso del SOAP Envelope Namespace; deve far uso del SOAP Encoding Namespace; non deve contenere riferimenti ad un DTD ne istruzioni di XML processing. DATA ENCODING: il concetto di encoding riguarda le info applicative contenute nel tag Body: defisce come i dati vengono rappresentati in XML. I dati possono essere semplici (scalari) o composti (fatti da più parti, ognuna è un dato semplice). TERMINOLOGIA: <accessor>value</accessor> accessor è chi può accedere al valore; value è il valore del dato e/o combinazione di dati. I tipi strutturati sono una combinazione di uno o più tipi semplici raggruppati come figli in un singolo accessor. Una struttura dati SOAP è codificata tramite un elemento che contiene altri elementi nidificati. Ogni elemento è identificato da un nome. SOAP CONTAINER accetta richieste in arrivo e le invia al servizio adeguato; traduce da SOAP al linguaggio del servizio (es. Java). I clienti devono così conoscere solo l’indirizzo del servizio, non il linguaggio, la piattaforma o la posizione. SOAP usa HTTP come protocollo di trasporto: si usa la modalità POST per i msg (il blocco di dati è costituito dal msg SOAP vero e proprio). PROCESSI DI BUSINESS sono una serie di attività (servizi) logicamente correlate che permettono di avere un outcome ben definito che crea profitto. Peculiarità: possono richiedere interazioni più o meno formali tra i partecipanti; la durata è molto variabile, attività possono essere manuali/automatiche; a lungo termine. WORKFLOW è la sequenza di passi durante cui info/oggetti fisici vengono passati da uno step produttivo all’altro. Caratterizzato da presenza di regole, punti di decisione, ruoli. PROCESSI WEB sono la prossima generazione di tecnologie per definire i workflow. Sono creati tramite la composizione dei web services scoperti. WEB SERVICE COMPOSTI I service provider offrono funzionalità che il workflow specifica che devono essere fornite da un business partner al fine di creare un processo di business. Cioè, un service provider è un business partner che offre un servizio indicato nel workflow, per eseguire un processo di business. Tale servizio è presentato tramite un’interfaccia pubblica nella forma di documento WDSL. Composizione di WS: WS interconnessi che possono essere usati come un nuovo servizio in altre composizioni. Mediante la composizione si crea un nuovo servizio a valore aggiunto. Per farlo è necessaria la compatibilità fra le operazioni fatte dai WS. BPEL Business Process Execution Language: linguaggio di programmazione testuale basato su XML costruito per la specifica formale di processi di business e per I protocolli che definiscono le modalità di interazione fra processi di business (in modo da permettere una suddivisione dei compiti tra attori diversi). ll linguaggio BPEL permette di descrivere un business process mediante un insieme di attività, semplici o composte. BPEL fornisce molte funzionalità per facilitare modellazione/esecuzione di processi di business basati sull’uso di WS, come: modellazione del controllo dell’esecuzione dei processi di business; rappresentazione dei ruoli dei partecipanti e dei loro rapporti, ecc. STRUTTURA: BPEL usa WSDL per specificare le attività che dovrebbero prendere parte in un processo di business. Documento BPEL influenza (estende) WSDL in 3 modi: 1) un processo BPEL espresso come WS usa WSDL: questo descrive entry pubbliche e endpoint del processo 2) I tipi di dati WSDL usati in un processo BPEL descrivono le info scambiate tramite richieste 3) WSDL può essere usato per referenziare servizi esterni richiesti da un processo di business. BPEL permette di considerare un Web Service come un processo di collaborazione composto da altri Web Service, definendone una natura di tipo ricorsivo e questo “processo di processi” così definito avrà una sua propria interfaccia WSDL. Un processo definito mediante BPEL è composto da attività che rappresentano sia richieste di tipo client, sia risposte al client medesimo; il processo si basa su una serie di Web Service che vengono chiamati partner invocati attraverso l’attività di “invoke” che può essere di tipo sincrono o asincrono. BPEL “ORGANIZZA” WSDL: wsdl insieme disordinato di operazioni (scambio di msg), BPEL fornisce: regole di ordinamento; supporto per sequenzialità/concorrenza delle operazioni. Lo fa con 2 metodi: ORCHESTARTION; gestita da BPEL. Un processo (eseguibile) di business descrive un flusso sotto il controllo di un endpoint vedendolo dalla prospettiva di questo (= come un processo di business è visto da un endpoint). CHOREOGRAPHY (gestita da WSDL) Il pubblico scambio (osservabile) di msg, le regole di interazione e di accordi tra due o più endpoint di un processo di business. ATTIVITA’ BPEL – semplici: <invoke> Attività utilizzata per invocare una determinata operazione di un Partner Link. <receive> esegue una wait bloccante aspettando che arrivi un
  16. 16. messaggio (una richiesta); è l'attività delegata ad istanziare il processo business. <reply> viene utilizzata per rispondere al Partner Link che ha inviato il messaggio di richiesta, a conclusione del processo business. La combinazione delle attività: <receive> e <reply> forma un’operazione di richiesta/risposta in WSDL. <assign> aggiorna il valore di una variabile. <throw> genera un’eccezione (Un processo BPEL può fallire per vari motivi: può esplicitamente lanciare un'eccezione; l'invocazione di un servizio esterno può non andare a buon fine; possono verificarsi problemi a livello di ambiente d'esecuzione. Come in Java, possiamo sollevare esplicitamente un'eccezione con il costrutto <throw>). <wait> mette in attesa per un tempo specificato. <empty> operazione “no-op” utile per sincronizzare attività concorrenti. – strutturate: <sequence> Consente l'esecuzione sequenziale di attivita. <flow> consente esecuzione parallela di attività. <switch> scelta tra attvità. <scope> permette la creazione di “pacchetti” di attività. Ogni <scope> ha un'attività primaria, solitamente <sequence> o <flow> + ogni <scope> ne può contenere altri annidati. RESTful web service Representational State Transfer: fu introdotto come uno STILE ARCHITETTURALE per costruire sistemi distribuiti su larga scala. Stile architetturale soggetto a questi vincoli: 1) risorse identificate tramite URI 2) interfacce uniformi per tutte le risorse 3) msg autodescrittivi (uso di metadati) 4) interazione stateful. 1) cosa identificano gli URI? Qualsiasi cosa debba essere identificata specialmente tutte le risorse ad alto livello che le applicazioni web forniscono (oggetti individuali o collezzione di oggetti, risultati di computazioni, ecc). Un processo o un passo di un processo, la richiesta per un preventivo, ecc. Queste “cose” identificate, in cambio, possono portare alla creazione di entità più persistente rispetto ad un approccio tipico. 2) l’interfaccia uniforme per tutte le risorse permette di avere 4 possibili azioni per tutte le risorse: PUT inizializza lo stato di una specifica risorsa ad un URI definita; GET riceve lo stato corrente di una risorsa puntata con un URI; POST modifica lo stato di una specifica risorsa; DELETE cancella una risorsa. Dopo questa operazione l’URI che la identifica non sarà più valida. 3) Msg autodescrittivi tramite metadati: L'approccio adottato da HTTP è quello di consentire una separazione tra quello che concerne la manipolazione dei dati e quel che riguarda l’invocazione di operazioni. Ogni msg (HTTP) include abbastanza info per descrivere come processare il msg a seconda se quetso serva a modificare dati o a invocare operazioni. 4) Interazione stateful attraverso hyperlink (à quello che rende il web ciò che è): il serve fornisce una serie di link a dei client; ciò consente al client di “muovere” un’applicazione da uno stato ad un altro (seguendo I link). Rest ha il compito di trasformare lo stato in uno stato della risorsa e tenerlo lui o salvare questo stato Della risorsa sul client. Così il server può salvare parte dei dati sui client, non deve necessariamente farsi carico di memorizzare tutte le info sullo stato. à Rest dunque ha una diversa struttura rispetto ai WS classici. WS SOAP (WSS) vs WS REST (WSR) Protocollo di trasporto: WSR HTTP, WSS molti protocolli (HTTP, TCP, SMTP, ecc). Formato dei msg: WSR molti formati (XML-SOAP, RSS, JSON) WSS formato dei msg definito da XML-SOAP (Envelope, Header, Body). Identificatore dei servizi: WSR URI, WSS URI e indirizzamento WS. Descrizione dei servizi: WSR documentazione testuale o WADL (Web Application Description Language) WSS WSDL (Web Service Description Language). Composizione servizi: WSR mashup WSS BPEL. Scoperta servizi: WSR nessuno standard WSS UDDI. Approfondendo: Anche se l’obiettivo dei due approcci è pressocchè identico (adozione del Web come piattaforma di elaborazione) la loro visione e la soluzione suggerita sono differenti. La prima evidente differenza è la visione del Web proposta come piattaforma di elaborazione: REST propone una visione del Web incentrata sul concetto di risorsa mentre SOAP su concetto di servizio. Un ws RESTful è custode di un insieme di risorse sulle quali un client può chiedere le operazioni canoniche del protocollo HTTP. Un ws SOAP espone un insieme di metodi richiamabili da remoto da parte di un client. Il protocollo SOAP definisce una struttura dati per lo scambio di messaggi tra applicazioni, riproponendo in un certo senso parte di quello che il protocollo HTTP faceva già. A differenza di HTTP, però le specifiche di SOAP non affrontano argomenti come la sicurezza o l’indirizzamento, quindi non sfrutta a pieno il protocollo HTTP, lo usa come semplice protocollo di trasporto. REST invece sfrutta HTTP per quello che è, un protocollo di livello applicativo, e ne utilizza a pieno le potenzialità. È evidente che l’approccio adottato dai ws basati su SOAP è derivato dalle tecnologie di interoperabilità esistenti al di fuori del Web. Questo approccio può essere visto come una sorta di adattamento di queste tecnologie al Web. L’approccio REST invece tende a conservare e ad esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere una piattaforma per l’elaborazione distribuita. Quindi non è necessario aggiungere nulla a quanto è già esistente sul Web per consentire ad applicazioni remote di interagire. Inoltre i ws basati su SOAP prevedono lo standard WSDL per definire l’interfaccia di un servizio. Questa è un’ulteriore evidenza del tentativo di adattare al Web l’approccio di interoperabilità basato su chiamate remote. Da un lato l’esistenza di WSDL favorisce l’uso di tool per creare automaticamente client in un determinato linguaggio di programmazione, ma allo stesso tempo crea una forte dipendenza tra client e server. REST non prevede esplicitamente nessuna modalità per descrivere come interagire con una risorsa, le operazioni sono implicite nel protocollo
  17. 17. HTTP. Qualcosa di analogo a WSDL è WADL, un’applicazione XML per definire risorse, operazioni ed eccezioni previsti da un Web Service di tipo REST. In conclusione, i ws basati su SOAP costruiscono un’infrastruttura prolissa e complessa al di sopra del Web per fare cose che il Web è già in grado di fare. Il vantaggio di questo tipo di servizi è che in realtà definisce uno standard indipendente dal Web e l’infrastruttura può essere basata anche su protocolli diversi. REST invece intende ripristinare il Web ad architettura per la programmazione distribuita senza aggiungere sovrastrutture non necessarie. WS SEMANTICI prima di tutto, concetto di ontologia: descrizione esplicita di un dominio. Riguarda: concetti (del dominio), proprietà e attributi del concetto, vincoli su proprietà/attributi. Ontologie definiscono: vocabolario comune + modalità condivisa di comprensione del vocabolario. Ontology engineering: consiste nella definizione dei termini del dominio e la relazione che sussiste tra essi. Quindi comprende: definizione dei concetti del dominio (classi); organizzazione gerarchica dei concetti (in superclassi, sottocalssi), definisce che attributi e proprietà una classe può avere e I vincoli sui loro valori. Sviluppare ontologie per: condividere la comprensione della struttura dell’info tra persone e tra agenti software; riutilizzare conoscenze relative a un dominio (per evitare di rifare cose già fatte e per introdurre standard che permettono l’interoperabilità). Nb. I metodi standard per descrivere I WS pongono il focus sul garantire l’interoperabilità su diverse piattaforme ma non forniscono buoni strumenti per scoprire/integrare WS differenti. WS semantici permettono sviluppo autonomo di processi che rappresentano complesse interazioni tra organizzazioni. Ad oggi no standard condiviso/accettato per gestire WSS ma 2 approcci promettenti: 1) WSMO Web Service Modeling Ontology: fornisce un modello concettuale per descrivere i vari aspetti dei Web Services semantici. È un ontologia, basato su WSML (web services modeling language). I web service sono descritti in WSMO secondo tre differenti punti di vista: proprietà non funzionali, funzionalità e comportamento. Quindi un web service e definito dalle proprietà non funzionali, le ontologie importate, i mediatori utilizzati e le sue interfacce. Un web service può essere descritto da interfacce multiple, ma ha una ed una sola funzionalità. La funzionalità di un web service incapsula le sue funzionalità e l'interfaccia di un web service descriver il comportamento del web service da due prospettive: comunicazione e collaborazione. WSMO è composto da quattro elementi: 1) ontologia, che fornisce la terminologia usata dagli altri elementi WSMO. Un’ontologia è composta da proprietà non funzionali (l’insieme esistente di proprietà core predefinite), le ontologie importate, e la definizione dei concetti, relazioni, assiomi, funzioni e istanze dell’ontologia. In aggiunta, questo meta-livello definisce gli ooMediator che sono utilizzati per importare tutte le ontologie per le quali i problemi di allineamento, fusione e trasformazione devono essere risolti durante l’importazione. 2) descrizione del Web service, che descrive gli aspetti funzionali e comportamentali del Web service. 3)goal, obiettivi che formalizzano i desideri dell’utente; 4)mediatori, che hanno lo scopo di gestire automaticamente i problemi d’interoperabilità tra differenti elementi WSMO. I Mediators hanno l’obiettivo di risolvere i problemi di eterogeneità. I mediatori in WSMO sono elementi speciali utilizzati per collegare componenti eterogenee coinvolte nella modellazione di un Web service. WSMO enfatizza il ruolo dei mediatori per superare i problemi d’interoperabilità. Essi definiscono tutti i mapping, le trasformazioni o le riduzioni necessarie tra gli elementi collegati. Ci sono quattro differenti tipologie di mediatori: a) ggMediators, questi collegano tra loro due goal, ed esprimono la riduzione da un goal sorgente ad un goal target. Possono utilizzare gli ooMediator per superare le differenze nella terminologia utilizzate per riferirsi a questi goal. In aggiunta, WSMO permette il linking non solo dei goal, ma anche dei goal dei ggMediator, permettendo di conseguenza il riuso di più goal per la definizione di nuovi goal b) ooMediators, questi importano le ontologie e risolvono possibili incongruenze di rappresentazione tra loro, come ad esempio per i linguaggi di rappresentazione differenti o concettualizzazioni differenti dello stesso dominio c) wgMediators, essi collegano un Web service ad un goal. Questi collegamenti rappresentano il raggiungimento (totale o parziale) del goal da parte del Web service. I wgMediator possono utilizzare gli ooMediator per risolvere problemi di eterogeneità tra i Web service e i goal d) wwMediators, questi collegano due Web service, che contengono gli ooMediator necessari per superare i problemi di eterogeneità che possono sorgere nelle situazioni in cui i servizi utilizzano vocabolari differenti. 2) OWL-S Il Web semantico dovrebbe consentire un ottimo accesso non soltanto ai contenuti ma anche ai servizi presenti nel Web. Utenti ed agenti software dovrebbero essere in grado di ritrovare, invocare, comporre e monitorare le risorse del Web oltre che farlo con un grado di automazione scelto a priori. OWL-S è una ontologia di servizi che rende queste funzionalità possibili. OWL-S nasce con l’obiettivo di rispondere alle seguenti domande: Cosa fornisce il servizio ad eventuali client? Come è utilizzato? Come si interagisce? Per fornire risposta a queste domande sono necessari tre tipi essenziali di conoscenza riguardo un servizio. La struttura di OWL-S fornisce essenzialmente un modello di rappresentazione astratta del servizio. E’ un’ontologia di alto livello la cui radice è rappresentata dalla

×