Contents. Stefano Sabatini. 04 July Informazioni generali sul corso 2

Transcript

1 cr Stefano Sabatini 04 July 2011 Contents 1 Informazioni generali sul corso 2 2 Programma XML e XMLPath Richiami sul protocollo HTTP Service Oriented Architecture - SOA SOAP - Simple Object Access Protocol WSDL - Web Service Description Language UDDI - Universal Discovery Description Infrastructure Macro architettura dei servizi web (lezione del ) Process oriented workows e BPEL (lezione del ) REST - Representation State Transfer JAX-RS (Lezione del ) Compagnie e organizzazioni Compagnie Organizzazioni Prodotti Materiale didattico 17 5 Strumenti JDK Firefox+Firebug NetBeans OpenESB

2 6 Esercitazioni Creazione di un web service a partire dal codice Orchestrazione di web services Esami Esame del Informazioni generali sul corso Il corso è tenuto da Antonio Pintus. Contatto: 2 Programma Il programma completo si trova in un documento fornito da Pintux. 2.1 XML e XMLPath Basato su una presentazione di Pintux. ˆ XML ˆ cenni ai namespaces ˆ XML Schema ˆ Schema Denisce gli elementi che deniscono un documento, e le loro relazioni. In altre parole denisce il tipo di un documento (o vari tipi in esso contenuti). ˆ XPath 1.0/2.0 W3C XQuery e XPointer utilizzano espressioni XPath. Linguaggio di espressioni Tipi di nodi referenziabili da XPath: root nodes: il root che contiene l'intero documento, ossia il root element e tutti i rimanenti nodi 2

3 element nodes: gli elementi del documento XML text nodes: testo contenuto all'interno di un elemento attribute nodes: gli attributi di ciascun elemento comment nodes: i commenti presenti nel documento processing instructions: istruzioni di elaborazione del documento namespace nodes: i namespace dichiarati nel documento Elementi del linguaggio: espressioni predicati wildcards e path multipli assi di ricerca (axis): axisname::nodetest[predicate] operatori funzioni 2.2 Richiami sul protocollo HTTP Basato sulla lezione 2 di [PINTUX] ˆ Metodi OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT 3

4 2.3 Service Oriented Architecture - SOA Basato sul capitolo 1 di [PAPA], poi ampliato in dettaglio nel capitolo 8. ˆ Denizione di servizio web Denizione di web service: A web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP messages, conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. (W3C) Il concetto di servizio è alla base delle SOA. Si distingue tra web-pages e web-services secondo i seguenti criteri (Aldrich) (vedi [PAPA], 1.2): i WS sono risorse accessibili ad altre applicazioni / servizi (non solo fruibili da operatori umani) i WS sono modulari, auto-descriventi e auto-coscienti del loro stato i WS sono più visibili e più gestibili in particolare possono essere monitorati tramite un'interfaccia uniforme i WS possono essere oggetto di brokering o di au Una caratterizzazione più precisa di un WS ([PAPA] 1.3): un WS è un'applicazione web con le seguenti caratteristiche: indipendente dalla piattaforma debolmente accoppiato auto-contenuto programmabile dispone di un sistema di pubblicazione, descrizione, scoperta e congurazione Qualche concetto che caratterizza un web service: evoluzione: ASP -> software as a downloadable service -> web service software as a service 4

5 ASP - Application Service Provider proprietà funzionali / non funzionali di un WS stateless/stateful service coupling: loose/strict service granularity: atomic / ne-grained / coarse-grained denisce quanto SOA - Service Oriented Arvhitecture WS technology stack in SOAP QOS - Quality of Service SLA - Service Level Agreement SLA usato per denire il QOS di un dato WS. event-driven architecture basato sul concetto e sull'impiego di un ESB (Enterprise Service Bus) Limitazioni di WS-*: * problemi di performance * mancanza di supporto di gestione di transazioni * mancanza di supporto per gestire la semantica dei vari business * complessità e presenza di molteplici standard in competizione Proprietà di un WS (papa-mantra): debolmente accoppiato (loosely coupled) indipendente da piattaforma/protocollo specico (protocol/platform independent) basato su standard aperti (open-standards - based) ˆ Denizione di SOA SOA denisce un tipo di architettura di architettura (di fatto implementata dagli standard SOAP e WS-*), basata sul concetto di servizio. Lo scopo di SOA è quello di garantire applicazioni distribuite e interoperabili, operato tramite la composizione di web-services, precedentemente deniti. In sintesi una SOA è un'architettura che presenta le seguenti caratteristiche: 5

6 è composto da una composizione di servizi web (applicazioni web distribuite accoppiate debolmente, basate su standard aperti, indipendenti da protocollo e applicazione) fornisce un meccanismo di descrizione, scoperta, pubblicazione dei servizi Dal punto di vista tecnologico esistono varie implementazioni di SOA, ad esempio: J2EE CORBA JMS (Java Messaging System) WS-* Nel corso si considera come riferimento l'implementazione di maggior portata, quella basata su WS-* (XML+SOAP+WSDL+UDDI+WS- *). Una SOA è caratterizzata dalla presenza di ruoli: WS provider WS requestor (detto anche client) WS broker (in particolare un registry è un tipo particolare di broker, un cosiddetto aggregator è pure un tipo particolare di broker) ˆ Standard rilevanti L'architettura SOA trova la sua specicazione più rilevante nella serie di standard W3C referenziati come WS-*, che deniscono servizi web basati su SOAP. Segue una lista (non esaustiva) degli standard rilevanti per SOA/WS: XML, XML schema, XPath SOAP UDDI (Universal Description and Discovery Integration) WSDL (denisce formalmente un servizio web) BPEL (denisce la composizione di vari servizi web tramite orcherstrazione) WS-Policy 6

7 WS-ReliableMessaging WS-ReliableMessagingPolicy WS-Address WS-Security WS-Topic WS-MEX WS-Transaction WS-PolicyFramework WS-ResourceFramework WS-Coordination WS-Notication WS-Topics WS-Trust SAML (Security Assertion Markup Language) 2.4 SOAP - Simple Object Access Protocol Standard usato per denire il formato dei messaggi scambiati dai WS. Strutturato in questo modo: envelope, contiene ˆ header (0 o 1) ogni header contiene uno o più cosiddetti header block contiene informazioni addizionali per processare il messaggio ˆ body - obbligatorio contiene l'xml specico dell'applicazione (payload) o un messaggio d'errore (fault message) Ogni body contiene uno o più elementi glio detti body entry. Il fault message (denito come env:fault contiene i seguenti elementi: ˆ env:code: che a sua volta può contenere env:value ed env:subcode ˆ env:reason: contiene la spiegazione dell'errore in linguaggio naturale (per utenti umani) ˆ env:detail: altra spiegazione in linguaggio naturale, più dettagliata rispetto a env:reason Un messaggio SOAP è caratterizzato da uno modello di comunicazione, che a sua volta è denito da: 7

8 ˆ stile di comunicazione (communication style): può essere document o RPC ˆ stile di codica (encoding style): può essere literal o encoded 2.5 WSDL - Web Service Description Language Denisce formalmente e precisamente l'interfaccia di un servizio. Il WS è visto come una collezione di endpoint comunicanti tra loro. Consta attualmente di due parti distinte: ˆ denizione dell'interfaccia: abstract interface (operazioni, tipi) ˆ denizione dell'implementazione: concrete endpoints questa parte eettua un'associazione tra l'interfaccia astratta e gli indirizzi di network associati, i protocolli, etc. L'XML che denisce un WSDL è così denito: ˆ denitions: è l'elemento radice del WSDL. ˆ tipi ˆ messaggi: ogni messaggio è composto di parti ˆ porttype: denisce un'insieme di operazioni ˆ operazione: ogni operazione è caratterizzata da un nome e da dei messaggi di input e di output, è contenuta all'interno di un elemento porttype ˆ binding ˆ service binding e service deniscono la cosiddetta implementazione. 2.6 UDDI - Universal Discovery Description Infrastructure È un sistema formalizzato e standardizzato per: ˆ descrivere l'ambito d'uso di un servizio, categorizzarlo e classicarlo mediante metadata. Nella classicazione rientrano caratteristiche funzionali e non funzionali del WS 8

9 ˆ pubblicare dei WS, accedibili tramite un registry. Quello maggiormente utilizzato si chiama UBR (Universal Business Registry ˆ accedere ai WS tramite delle API di interrogazione e ricerca dei WS pubblicati. In particolare lo standard UDDI denisce le seguenti categorie usate per la catalogazione dei WS pubblicati: ˆ white pages contengono gli indirizzi a cui è possibile reperire i WS pubblicati ˆ yellow pages forniscono una tassonomia dei servizi pubblicati, in funzione delle categorie e delle richieste dei client ˆ green pages deniscono le caratteristiche tecniche dei vari servizi pubblicati, in particolare le interfaccie supportate, e le caratteristiche nonfunzionali (che determinano ad esempio il QoS del servizio stesso) 2.7 Macro architettura dei servizi web (lezione del ) Basato sul capitolo 8. ˆ WSDL: denisce l'interfaccia del servizio ˆ Service provider: fornisce una funzionalità di ricerca e uso di specici web service, l'equivalente del motore di ricerca per le pagine web Il client accede al service provider, e tramite l'interfaccia e la funzionalità messa a disposizione da questo utilizza i servizi (che sono deniti formalmente dal WSDL). ˆ Concetto di message reliability (adabilità del messaggio) 2.8 Process oriented workows e BPEL (lezione del ) Basata sul capitolo 9 di [PAPA], vedere esercitazione numero 4 per quanto riguarda la parte sul BPEL e la lezione corrispondente in [PINTUX]. 9

10 ˆ Flusso delle attività In un modello di usso vengono descritte le modalità di orchestrazione dei servizi, e come vengono passati i messaggi da un servizio ad un altro. Esistono due modalità di gestione dei workow: orchestrazione tutti i processi sono visti dal punto di vista di un attore principale, che coordine le attività di tutti i WS coordinati Può essere descritto da un documento BPEL (Business Process Execution Language). Nell'ambito dell'orchestrazione viene denito in [PAPA] il cosiddetto value chain process, il processo che racchiude tutti processi di business di un'azienda. coreograa: basato su CDL (Coreography Description Language), prevede una visione più di alto livello, non c'è un'entità che orchestra ma viene solo descritta la modalità di interazione dei servizi/componenti. Denisce le interazioni tra i singoli WS da un punto di vista globale, senza assumere un punto di vista particolare. Può essere denito usando CDL (Choreography Description Language), rappresenta un approccio alternativo e complementare rispetto a quello dell'orchestrazione. ˆ BPEL - Business Process Execution Language BPEL è necessario per gestire processi di business, che coinvolgono più di un web service. Viene usato per denire interazioni stateful, asincrone e di lunga durata tra WS. basato su XML garantisce portabilità ultima versione: 2.0 viene letto e processato dai cosiddetti BPEL-engine permette di mantenere uno stato / ambiente durante l'esecuzione di un processo standard di fatto per l'orchestrazione di servizi web ore un sistema di correlazione dei messaggi permette di gestire un'applicazione in modalità concorrente fornisce un modello robusto per la gestione delle eccezioni Modello di esecuzione Processo di business: prevede: 10

11 gestione workow gestione errori supporto invocazioni gestione sincrona/asincrona dei messaggi Ogni servizio in BPEL viene descritto tramite WSDL, e viene chiamato partner link. Precisamente un partner-link viene denito come un collegamento ad una porta (port) di un web service. Il processo risultante viene rappresentato mediante un WSDL, cioè è esso stesso un WS. In un processo BPEL si hanno: partnerlink: denisce tutti i dierenti partecipanti coinvolti nel processo (in pratica i Web service utilizzati nel processo) variables: dichiara tutte le variabili usate nel processo e sono denite referenziando direttamente i tipi dei messaggi deniti nei WSDL dei servizi coinvolti. Tipi ed elementi deniti mediante XML Schema. Attività di base: <invoke> <receive> <reply> <assign> <throw> <exit> <empty> <sequence> <ow> <scope> <if> <while>, <repeatuntil>: equivalenti ai loop classici condizionati <foreach>: permette di iterare le attività in esso racchiuse in relazione ai valori di start ed end. Le attività possono essere anche eseguite in parallelo se l'attributo parallel=yes 11

12 ˆ ESB - Enterprise Service Bus An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing and trasformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components ow [Gartner] Infrastruttura software (middleware) Realizza la comunicazione fra i servizi utilizzando diversi protocolli Permette l'invocazione dei servizi su sistemi eterogenei: Supporto allo scambio dei messaggi Trasformazione dei dati Routing intelligente dei messaggi (anche per topic e content) Gestione dell'adabilità e sicurezza Monitoring e management dei servizi Gestione delle transazioni (anche long-running) Scalabilità Sistema bus di altissimo livello che permette di far comunicare tra loro servizi con interfacce eterogenee, utilizzando particolari adapter verso interfacce standard. Gli adapter (adattatori) sono fondamentali in quanto rendono possibile l'utilizzo di servizi legacy (e.g. implementati in COBOL o in linguaggi ormai poco conosciuti) che altrimenti dovrebbero essere sostituiti. Un ESB costituisce una backbone nella quale le applicazioni sono servizi, consentendo la composizione e la comunicazione tra queste con caratteristiche di: loose coupling messaggi asincroni e sincroni Plug & Play di applicazioni enterprise eterogenee (per piattaforma e linguaggi di programmazione) 2.9 REST - Representation State Transfer Non è trattato in [PAPA], solo nelle presentazioni di [PINTUX]. Questa lezione è fortemente basata sulla tesi di Fielding: fielding/pubs/disser REST viene anche considerato nell'ambito delle cosiddette Resource Oriented Architecture - ROA, in contrapposizione al concetto di SOA. 12

13 REST signica Representation State Transfer, ed è denito come uno dei possibili stili architetturali per la realizzazione di sistemi distribuiti, al pari di SOA. Secondo l'analisi di Fielding, ogni stile architetturale è basato su una serie di vincoli sulle interfacce. Per quanto riguarda REST, tali vincoli sono così deniti: ˆ identicazione delle risorse ˆ manipolazioni delle risorse tramite rappresentazioni ˆ messaggi auto-descrittivi ˆ hypermedia denito come il motore dello stato dell'applicazione (in originale: hypermedia as the engine of application state) In REST è fondamentale: ˆ il concetto di risorsa ˆ il concetto di stato di una risorsa, che può essere manipolato come una risorsa ˆ il concetto di trasferimento, rende possibile trasferire mediante una interfaccia uniforme le rappresentazioni delle risorse (e.g., mediante HTTP) Vari framework sono disponibili per gestire REST in Java. In particolare JAX-RS è il framework (basato su JAX-WS) per la creazione di applicazioni Rest. ˆ Concetto di risorsa In REST è fondamentale il concetto di risorsa, che viene referenziata da vari URI. Una risorsa può essere rappresentata in vari modi (e.g. tramite XML o JSON). Qualsiasi entità esposta sul Web è una risorsa: documenti, utenti, prodotti, libri, video,... Di converso ogni entità per essere utilizzabile in REST deve essere esposta come una risorsa web, eventualmente è possibile impiegare degli adapter per creare tali risorse (al contrario di WS basati su SOAP, dove non viene forzato l'uso di un protocollo). Ogni risorsa deve essere identicata e referenziata univocamente. Si impiegano gli URI HTTP per identicare le risorse. 13

14 ˆ Concetto di stato Si basa sul principo cosiddetto: Hypermedia As The Engine of Application State (HATEOAS) ovvero le risorse e il loro stato possono essere raggiunti attraverso link presenti nelle rappresentazioni stesse (state machine). In sintesi: REST sposta la gestione dello stato sui client o sulle risorse (evita lo stato nella parte server-side) lo stato delle risorse è gestito dal server; se un client cambia lo stato di una risorsa, tutti i client vedono questo cambiamento lo stato del client è mantenuto sul client (stato specico del client stesso) ˆ Concetto di trasferimento Denisce come trasferire e aggiornare mediante una interfaccia uniforme le rappresentazioni delle risorse (e.g., mediante HTTP). Le operazioni di trasferimento in REST sono le cosiddette operazioni CRUD: Create Read Update Delete Nota che esiste una corrispondenza tra i verbi HTTP e le operazioni fondamentali REST così denita: Create - POST Read - GET Update - PUT Delete - DELETE Questo rende possibile implementare REST usando HTTP, ovvero usando HTTP come livello applicativo (piuttosto che come livello trasporto come nei WS basati su SOAP), pertanto HTTP può essere usato come veicolo per REST, e su questo si basa il suo utilizzo nell'ambito dei servizi web RESTful. 14

15 ˆ Principi di applicazione di REST a un servizio web In pratica si seguono i seguenti cinque principi per l'implementazione id un servizio web in stile rest REST: primo: associare un ID a ciascuna risorsa secondo: collegare con un link le risorse terzo: usare metodi standard HTTP quarto: modellare le risorse in modo che abbiano rappresentazioni multiple quinto: usare interazioni stateless tra client e server ˆ Sintesi In sintesi, i concetti fondamentali di REST: risorse accessibile e soggette a rappresentazioni multiple stati accessibili e manipolabili come risorse (stato del client sul client, stato delle risorse sul server) possibilità di trasferire le risorse mediante interfaccia CRUD uniforme (indipendente dallo specico livello trasporto scelto, di fatto REST viene usato in congiunzione con HTTP) JAX-RS (Lezione del ) JAX-RS - JAX for ReStless JAX-RS è una specica, esistono varie implementazioni, Jersey è l'implementazione di riferimento per Java Ampio uso di annotations nel codice (ma: molto più limitato) Operazioni REST: ˆ GET ˆ PUT ˆ DELETE ˆ POST Ogni risorsa è rappresentata da un URI, con diverse rappresentazioni. Annotazioni: ˆ il verbo REST (può essere: PUT, GET, POST, DELETE) 15

16 specica l'uri patch della risorsa rappresentata dalla classe Java Può usare JAXB (Java Architecture for XML Binding) per le operazioni di serializzazione/deserializzazione. JAX-RS POJO (JAX-RS Plain Old Java Object) permette di creare una associazione automatica tra un oggetto Java e una risorsa, rappresentata in diversi modi (XML, JSON, etc.). 3 Compagnie e organizzazioni Segue una lista sommaria di compagnie e organizzazioni coinvolte nello sviluppo di web-services. 3.1 Compagnie ˆ Microsoft ˆ IBM ˆ Oracle ˆ Sun (acquisita da Oracle) ˆ BEA systems (acquisita da Oracle) ˆ SAP 3.2 Organizzazioni ˆ IETF (Internet Engineering Task Force) ˆ OASIS ˆ W3C (WWW Consortium) 16

17 3.3 Prodotti Questi prodotti vengono citati da [PAPA], alcuni sono dei precursori di WS basati su WS-*. ˆ Websphere MQ (IBM) ˆ.NET (Microsoft) ˆ WebLogic (BEA) 4 Materiale didattico Disponibile alla sezione del materiale didattico su informatica.unica.it, il materiale fornito dal docente è denito in questi appunti come [PINTUX]. Il corso si basa sul libro Web Services Basics di Papazoglou, detto [PAPA]. Su slideshare è possibile trovare delle risorse molto interessanti, specie per quanto riguarda il discorso SOA vs REST. vs-soap-making-the-right-architectural-decision-1st-international-soa-symposiumamsterdam-october-2008-presentation 5 Strumenti 5.1 JDK Firefox+Firebug 5.3 NetBeans È l'ide che viene usato per lo sviluppo. In particolare viene usato per generare web services, client associati e orchestrazioni di servizi. Contine integrato un BPEL editor. È integrato con Glasssh, infatti il deploy dei web services creati con esso verrà fatta automaticamente su un server Glasssh lanciato automaticamente dall'editor. 5.4 OpenESB open source enterprise service bus 17

18 6 Esercitazioni 6.1 Creazione di un web service a partire dal codice È implementato nell'esercitazione 3 (creazione di AccountManagerService). L'esercizio utilizza le cosiddette annotazioni dello standard JAX-WS supportato da Netbeans. Permette di generare dei servizi web associati a dei metodi una classe java. Le annotazione @Web- Fault Nota che i metodi annotati vengono visualizzati nell'editor, nella vista dei progetti: $PROJECT -> Web Services -> Account Manager Nota anche che il WSDL generato non risulta presente nella directory del progetto, ma risulta visualizzabile tramite web browser dopo il deploy, all'indirizzo: Nota anche che a causa di un bug il link al WSDL non funziona, il link precedente è il link corretto da utilizzare. Il link di sopra in particolare viene anche usato nell'esercitazione successiva, quindi sarà il link da importare. 6.2 Orchestrazione di web services Netbeans IDE: permette di generare il le bpel.xml che descrive l'orchestrazione. Per far ciò si importano i servizi da orchestrare, che sono rappresentati da un WSDL. In questo caso i WSDL da importare possono essere o su disco (in caso di progetti già implementati in NB) oppure possono essere referenziati tramite URL (servizi pubblici e/o disponibili in rete). Il le generato bpel.xml da NB dovrà essere processato da un BPEL engine, in questo caso quello presente in OpenESB. Per importare i le WSDL: $ProjectName->New->Other->XML->External WSDL Document(s), In questo caso si vogliono importare i servizi: ˆ PasswordGeneratorService ˆ AccountManagerService I servizi sono stati prodotti nelle esercitazioni precedenti. In particolare i WSDL generati si trovano in: $PROJECT/src/java/*.wsdl Il le WSDL importato risulterà automaticamente inserito nella top-dir del progetto. Creazione di un business project: 18

19 7 Esami Un'esame scritto alla ne del corso Il corso prevede diverse sessioni d'esame: ˆ 2 appelli a Giugno (inizio e ne Giugno) ˆ Luglio ˆ Settembre ˆ Ottobre L'esame consiste in uno scritto con domande di teoria e problemi da risolvere del tipo: ˆ come implementare un web-service SOAP usando JAX-WS ˆ come implementare un web-service REST usando JAX-RS Al primo appello è stato richiesto a grandi linee: ˆ descrizione di concetto di SOA (Service Oriented Architecture) ˆ domande su uno schema XML (XSDL - XML Schema Denition Language) ˆ descrizione di come può essere implementato un WS usando i vari framework visti a lezione (JAX-RS/WS) ˆ domande su concertazione (BPEL?) 7.1 Esame del Segue l'elenco delle domande dell'appello del Tempo 2 ore e mezza. Sono stati assegnati tre compiti diversi, ciascuno con 5 domande e un esercizio (sull'xml schema), alcune delle domande erano comuni a più compiti. ˆ Date una denizione di XML e XML Schema e spiegare che relazione intercorre tra essi. Quando un documento XML si dice valido? ˆ Dato il seguente XML Schema, scrivere un possibile documento XML conforme ad esso (opzionalmente omettere nell'xml i riferimenti ai namespace e allo schema location). 19

20 ˆ Da quali passi è tipicamente composta una transazione HTTP tra client e server? Cosa è un messaggio HTTP di richiesta e da quali informazioni esso è composto? ˆ Cosa è la tecnologia dei WS? Spiegare in modo esauriente i concetti di base le descrizioni dell'interfaccia dei servizi, il formato dei messaggi ˆ Che cosa è una web service orchestration e cosa permette di denire? ˆ Cosa sono le risorse in REST e con quale semantica vengono solitamente utilizzati i metodi HTTP standard in questo stile architetturale (modello Create Read Update Delete)? ˆ Cosa è REST e quali sono i principi pratici nella realizzazione in HTTP? ˆ REST perché è stateless e come avviene negoziazione tra client e server per una determinata risorsa ˆ Descrivere i passi di una transazione http e descrivere il messaggio di richiesta ˆ HTTP: come avviene interazione client server e cosa contiene il messaggio di risposta http ˆ Cos'è SOAP, come viene usato e descrivere struttura messaggio SOAP? ˆ Cosa è MOM (Message Oriented Middleware), cosa è un ESB (Enterprise Service Bus) ˆ Descrivere SOA 20