Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria

Transcript

1 Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Stefano Iannucci: lucidi su SOA di Sistemi Distribuiti e Cloud Computing, A.A. 2011/12 1

2 BPEL, BPMN, Service Integration UDDI Service Discovery Service Publication WSDL SOAP Service Description XML-based messaging HTTP Transport 2! Scommessa architetturale e tecnologica: integrazione di applicazioni eterogenee! Nuove applicazioni costruite secondo paradigmi orientati ai servizi non creano problemi! Integrazione di applicazioni legacy?! Cos'è un Enterprise Service Bus (ESB)?! Non esiste una definizione univoca per ESB E' un modello? Un prodotto? Un componente architetturale? 3

3 Contesto architetturale di un ESB! Obiettivo: disaccoppiare le applicazioni client dai servizi! ESB fornisce un middleware di comunicazione! Nella situazione iniziale il client deve conoscere ed implementare tutti i protocolli necessari per eseguire l'applicazione... e se cambia il protocollo con il quale viene esposto un servizio? 4! Servizio di business: funzionalità (ad alto livello) offerta dall'azienda al cliente finale; definisce input/output! Es: PlaceTrade! Implementazione di un servizio: parte della business logic necessaria per portare a termine un servizio di business! Es: savetradeorder() 5

4 6! Capacità di smistare una richiesta verso un particolare service provider utilizzando criteri deterministici o probabilistici! Tipologie di routing:! Statico o deterministico! Content-based! Policy-based! Complex rules-based 7

5 ! Capacità di convertire la struttura ed il formato del payload della richiesta effettuata dal client nel formato effettivamente gestibile dal service provider! Esempi:! XML! XML! XML! Object (RMI verso il service provider)! Object! XML 8! Capacità di aggiungere, modificare o eliminare l'informazione contenuta in un messaggio in modo da renderlo compatibile col service provider! Tipologie di message enhancement:! Conversione del formato della data! Aggiunta di informazioni non presenti originariamente! Conversione dei dati (es. eliminazione spazi)! Enhancement basati su regole! Esempio: acquisto con conversione di valuta 9

6 ! Capacità di accettare un tipo di protocollo nei confronti del client (es. SOAP, JMS, HTTP) e comunicare al service provider attraverso un altro protocollo (es. RMI)! Protocol transformation diverso da message transformation! Message transformation modifica il payload! Protocol transformation modifica la struttura del messaggio 10! Capacità di mappare un servizio di business con la corrispondente implementazione e di fornire informazioni relative a binding e locazione! Soltanto l ESB conosce i dettagli sulla locazione del servizio! fornisce al client trasparenza della locazione 11

7 ! Capacità di gestire lo stato e le richieste assicurando il delivery del messaggio di risposta al client 12! Service orchestration:! Capacità di gestire processi di business complessi che richiedono la coordinazione di diversi servizi di business per portare a termine una singola richiesta! Transaction management:! Capacità di trattare una richiesta ad un servizio di business come se fosse una singola unità di lavoro; in particolare dovrebbe offrire un framework per la compensazione 13

8 ! Capacità di proteggere i servizi da accessi non autorizzati! Tutti i servizi pubblicati sul bus! Fondamentale quindi il supporto di:! Autenticazione! Autorizzazione! Auditing! Amministrazione 14! Non esiste un singolo prodotto in grado di offrire tutte le funzionalità descritte! Un ESB può essere diviso in 4 componenti:! Mediator! Service Registry! Orchestrator! Rules Engine 15

9 ! Orchestrator:! Process orchestration! Rules Engine:! Rules-based Routing Message transformation Message enhancement! Service Registry;! Service mapping! Mediator:! Routing! Message transformation! Message enhancement! Protocol transformation! Transaction management! Security 16 17

10 Benefits Increased flexibility Easier to change as requirements change Scales from point-solutions to enterprise-wide deployment (distributed bus) More configuration rather than integration coding No central rules-engine, no central broker Incremental patching with zero down-time Disadvantages Increased overhead Slower communication speed 18 Commercial IBM WebSphere Oracle Enterprise Service Bus Oracle Enterprise Service Bus Open source Apache ServiceMix JBOSS ESB TIBCO ActiveMatrix Service Bus OpenESB 19

11 ! Obiettivo: creare un architettura basata su standard esistenti per integrare componenti middleware in modo da formare un ESB! JBI controlla le interazioni tra client e service provider interni! Dipendente da J2SE, non J2EE! Definisce due tipologie di componenti:! Service Engines (SE)! Binding Components (BC)! OpenESB è basato sullo standard JBI 20! Disaccoppiamento tra servizio di business e sua implementazione! Funzionalità di routing (NMR)! Funzionalità di protocol transformation (BCs) 21

12 22! BPEL SE è il BPEL engine in OpenESB! Fornisce un punto di accesso per applicazioni SOA sviluppate in ambiente JBI! Esegue processi di business codificati in BPEL! Permette l'orchestrazione di servizi (partner) raggiungibili tramite qualche tipo di BC e descritti da un file WSDL! Manipola e trasforma i dati per interagire correttamente con i partner! Implementa il processamento parallelo delle attività (attività <flow> di BPEL)! Gestisce le eccezioni ed implementa logiche di compensazione (le cosiddette operazioni di undo) 23

13 BPEL: Relazioni con i partner Partner Service Partner Service Partner Service 24 BPEL: le attività 25

14 BPEL: l'attività <receive> 26 BPEL: l'attività <reply> 27

15 BPEL: l'attività <invoke> 28 BPEL: l'attività <assign> 29

16 BPEL: attività strutturate 30 BPEL: attività scope 31

17 BPEL: attività throw 32 33

18 ! SOAP, WSDL, UDDI realizzati per standardizzare lo sviluppo di applicazioni distribuite! Parallelamente: proposta nel 2000 di Representational State Transfer (REST) nella tesi di dottorato di R. Fielding, uno dei principali autori di HTTP! Scopo di REST: snellire l'architettura dei Web service realizzando un modello più semplice da utilizzare! Negli ultimi anni REST è emerso come stile architetturale e progettuale predominante per applicazioni distribuite a larga scala 34! Principi dello stile architetturale REST:! Utilizzo esplicito dei metodi HTTP: GET, PUT, POST e DELETE! Interazioni stateless! Esposizione dei servizi con URI strutturati in forma di directory! Rappresentazione dei contenuti in una varietà di formati standard: XML, JavaScript Object Notation (JSON), MIME, 35

19 ! Utilizzo dei metodi HTTP così come definito nell RFC 2616 per HTTP/1.1! Esempio: metodo GET! Utilizzato per scaricare una risorsa! Utilizzato per eseguire query che richiedono al web server la ricerca e l'invio dei dati trovati! Non deve essere usato per alterare una risorsa! REST definisce mapping tra operazioni CRUD e metodi Creazione di una risorsa sul server (C)! POST! Richiesta di trasferimento di una risorsa (R)! GET! Cambio di stato (aggiornamento) di una risorsa (U)! PUT! Cancellazione di una risorsa (D)! DELETE 36! Richiesta HTTP non utilizzata correttamente (dal punto di vista REST): GET /adduser?name=stefano HTTP/1.1! Perchè?! Sembrerebbe solamente una questione semantica! In realtà è un invito ai crawler ad aggiungere sul nostro DB dei contenuti indesiderati 37

20 POST /users HTTP/1.1 Host: myserver Content-Type: application/xml <?xml version= 1.0?> <user> <name>stefano</name> </user> 38 GET /users/stefano HTTP/1.1 Host: myserver Accept: application/xml! Utilizzo corretto del metodo GET! Il metodo GET dovrebbe essere idempotente! 39

21 ! Non REST-style: GET /updateuser?name=stefano&newname=pippo HTTP/1.1! REST-style: PUT /users/stefano HTTP/1.1 Host: myserver Content-Type: application/xml <?xml version= 1.0?> <user> <name>pippo</name> </user> 40 Sample REST Request-Response for Creating an S3 Bucket REST Request PUT /[bucket-name] HTTP/1.1 Host: s3.amazonaws.com Date: Wed, 15 Mar :45:15 GMT Authorization: AWS [aws-access-key-id]: [header-signature] REST Response HTTP/ OK x-amz-id-2: VjzdTviQorQtSjcgLshzCZSzN +7CnewvHA +6sNxR3VRcUPyO5fmSmo8bWnIS52qa x-amz-request-id: 91A8CC60F9FC49E7 Date: Wed, 15 Mar :45:20 GMT Location: /[bucket-name] Content-Length: 0 Connection: keep-alive

22 ! Problema: aumento di carico sul server! Soluzione: replicazione, bilanciamento del carico! Difficoltà: cosa succede se si stabilisce una sessione con un server che potrebbe essere soggetto a malfunzionamenti?! Replicazione dello stato tra i server! Progettazione stateless: libera dalla necessità di replicare lo stato! Richiede che tutte le informazioni necessarie al completamento di un ciclo richiesta/risposta vengano inviate in fase di richiesta 42! Stateful design:! Stateless design: 43

23 ! La URI determina quanto il servizio RESTful sarà intuitivo nell'utilizzo! URI gerarchiche che espongono le caratteristiche principali dei servizi! Esempio: forum di discussioni {topic} 44 A mashup is a Web page or application that combines data, presentations or functionality from two or more sources to create a new service Example: take images from an online repository such as Flickr and overlay them on Google Maps By orchestrating RESTful services we can do mashup is a registry of a variety of Web 2.0 applications, such as mashups and APIs, organized by category, date, or popularity Similar goals to UDDI, but does not use UDDI specifications 45