Lesson 20 Orchestrazione e coreografia BPEL vs WS-CDL

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Lesson 20 Orchestrazione e coreografia BPEL vs WS-CDL"

Transcript

1 Lesson 20 Orchestrazione e coreografia BPEL vs WS-CDL Service Oriented Architectures Module 4 - Architectures Unit Ernesto Damiani Università di Milano

2 Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute Eseguono unità di lavoro discrete non posso invocare un servizio a metà Indipendenti dalla tecnologia (interoperabilità) Invocabili utilizzando standard di comunicazione Disaccoppiati Si conoscono unicamente tramite un interfaccia pubblica Devo poter modificare l implementazione di un servizio senza toccare gli altri Trasparenti rispetto alla locazione Recuperabili interrogando un repository

3 Basic SOA Service Provider Publish Bind Service Registry Find Service Client

4 Web Services XML XSD Publish Service Provider WSDL Bind Caso tipico HTTP Messaggi SOAP Service Registry UDDI Find Service Client

5 WS Stack Composition - Processes BPEL, BPELJ, WS-CDL Coordination - Context - Transactions - Security WS-Coordination, WS-AtomicTransactions, WS-Security, Description WSDL, WS-Policy Advertisement UDDI Messaging SOAP, WS-Addressing, WS-ReliableMessaging Transport HTTP, SMTP, HTTPS Format XML

6 Simple Object Access Protocol Envelope Header Body Document Messaggio, parametri, valori Fault Protocollo indipendente dal livello di trasporto per lo scambio di documenti XMLbased Messaggio SOAP: Header con informazioni aggiuntive - infrastrutturali (es: gestione della sicurezza) Body con il messaggio da comunicare Fault per l eventuale gestione di errori e eccezioni

7 Determinate dall encoding SOAP Tipo di interazione Tipo di codifica Modalità di interazione Due modalità fondamentali: RPC (sempre meno utilizzata) Document-based (message passing) Si tende a realizzare una invocazione con risultato con una coppia di messaggi ma non c è più attesa del cliente

8 Web Services Description Language 1/3 Dialetto XML per la descrizione dell interfaccia pubblica di un servizio Cosa fa il servizio (operazioni e relativi parametri) Dove si trova Come si invoca La descrizione si compone di una parte astratta (interfaccia) e di una concreta (realizzazione del servizio)

9 Parte astratta Messaggio WSDL 2/3 informazione effettivamente scambiata tra requestor e provider (per input, output, fault) Associato a parametri Tipi XSD Operation descrizione astratta di un attività supportata dal servizio si aggancia a messaggi Interface (o Port Type) = insieme di operazioni astratte

10 Parte concreta Types definizione dei tipi (tramite XSD) Binding WSDL 3/3 Specifica i protocolli di comunicazione e i formati dei dati per le operazioni e i messaggi definiti da un interfaccia Port (Endpoint) Specifica l indirizzo per legarsi al servizio Service aggregazione di un insieme di porte

11 Esempio 1/2 Tipo <element name= TradePrice > <complextype> <all> </all> </complextype> </element> Messaggio <element name= price type= float /> <message name= GetLastTradePriceOutput > <part name= body element= xsdl:tradeprice /> </message>

12 Esempio 2/2 porttype (request-response) <porttype name= StockQuotePortType > <operation name= GetLastTradePrice > <input message= tns:getlasttradepriceinput /> <output message= tns:getlasttradepriceoutput /> </operation> </porttype>

13 Modalità di interazione In base a come una operation viene legata ai messaggi otteniamo 4 diverse modalità di interazione One way Un solo messaggio in input all endpoint Request response L endpoint riceve un messaggio ed emette in output una risposta Solicit response (?) L endpoint invia un messaggio al client (sollecitazione) e attende un messaggio di risposta Notification (?) L endpoint invia un messaggio di notifica in output

14 Composizione di servizi Possiamo comporre servizi semplici per realizzare applicazioni più complesse Da servizi a processi di business Due approcci Orchestrazione Si definisce un servizio in termini di interazione con altri servizi + parti private Coreografia Si definisce, assumendo un punto di vista globale, come devono interagire differenti servizi al fine di raggiungere l obiettivo della composizione L interfaccia di comportamento di un servizio rappresenta la parte del servizio che interagisce con l esterno

15 Business Process Execution Language (for Web Services) Linguaggio XML-based per l orchestrazione di una serie di servizi al fine di realizzare un processo di business Il coordinatore è, in fase di esecuzione, il BPEL-engine che esegue la specifica Standard de-facto proposto dall IBM A partire da una serie di servizi stateless costruisco un processo con stato che può eventualmente esporsi a sua volta come servizio

16 Le due visioni di BPEL Linguaggio core per definire i ruoli (abstract WSDL) che interagiscono con il processo e specificare i pattern di interazione con tali ruoli Questo core si può poi istanziare su due differenti realtà La specifica di un protocollo di business o processo astratto (interfaccia di comportamento) La specifica di un processo eseguibile (processo astratto + attività private, interne al processo stesso) Idea fondamentale: finchè un processo espone la stessa interfaccia di comportamento, possiamo aggiornarlo senza toccare il mondo esterno

17 Parti fondamentali Variables Dati utilizzati dal processo WSDL message types Tipi semplici o elementi XSD partnerlinks Identificazione di chi interagisce con il processo Definizione del processo Definizione dei fault handlers Sia per cause interne che per cause esterne (vedi WSDL) Definizione degli handler di compensazione

18 Partner del processo Un partner è un insieme di partnerlink Deve fornire le funzionalità richieste Un partnerlink rappresenta un servizio con cui il processo interagisce È identificato da un partnerlinktype Un partnerlinktype è associato ad un ruolo e ad un porttype (vedi WSDL) Nota: una port implementa un porttype A livello di definizione, rimaniamo in astratto In fase di esecuzione è possibile definire staticamente o dinamicamente l istanza con cui si interagirà

19 Dati I dati costituiscono lo stato del processo Sono i messaggi scambiati, i valori intermedi delle variabili, i valori dei time-out Lo scoping è quello classico (vale l innestamento) Variabili o globali o valide all interno di uno scope Problemi nel caso di uso di variabili ancora non inizializzate Ci sono anche delle proprietà definite globalmente (tipi XSD semplici che rappresentano le informazioni principali del processo)

20 Correlazione In alcuni casi il processo vuole dialogare sempre con la stessa istanza di un partner In OO si usa un object reference Paradigma inutilizzabile nel contesto WS Si ricorre all uso dei dati (che determinano lo stato) e dei protocolli di comunicazione Usiamo un business token, dichiarando la sua struttura e la sua posizione nell envelope Dichiariamo che un gruppo di attività è correlato dicendo quali token di correlazione vengono condivisi dalle attività (correlation set) All inizio il correlation set non ha valore viene assegnato allo scambio di un certo messaggio

21 Inizio e fine di un processo BPEL descrive un processo con stato E che quindi ha un ciclo di vita Un processo viene istanziato implicitamente Attributo createinstance=yes sulla ricezione di un messaggio (receive o pick) Il processo viene istanziato sempre su stimolo esterno Terminazione Quando non c è più nulla da fare (terminazione implicita) Quando viene sollevato un fault Utilizzando <terminate> (terminazione anomala, solo per processi concreti)

22 Attività Utilizzate per modellare il comportamento del processo e degli handlers Attività semplici e costrutti complessi (diramazione del flusso, sincronizzazione, cicli) BPEL eredita da XLANG (Microsoft) Linguaggio strutturato WSFL(IBM) Basato su grafi

23 Invoke Invocazione di un servizio su un partner Invocazione asincrona Si specifica la variabile di input Invocazione sincrona Si specifica sia l input che l output Invocazione di un servizio Si può eventualmente verificare (e gestire localmente o rilanciare) un fault Associabile ad un handler di compensazione (in-line)

24 Ricezione di una richiesta Receive Ricezione di un messaggio da parte di un partnerlink, il quale indica porttype e operation che vuole invocare Eventualmente si utilizza una variabile per accogliere i dati spediti (fondamentale per un processo concreto) Può istanziare il processo Se è l unica attività iniziale (non preceduta da nessuno) Nel caso sia in parallelo con altre receive di questo tipo, tutte devono appartenere allo stesso correlation set Non è possibile l attivazione simultanea di due receive esattamente identiche

25 Reply Utilizzata per rispondere ad una richiesta sincrona (rilevata con una precedente receive) Risposta In caso di richiesta asincrona, l eventuale risposta si spedisce con una invoke Eventualmente associabile alla variabile contenente la risposta Semantica indefinita nel caso di una reply isolata Si può specificare se si tratta di una risposta normale o di un fault

26 Altre attività semplici Assign Assegna il contenuto di una variabile ad un altra variabile (anche tra parti di messaggi) Throw Genera un fault interno Wait Sospende il processo per un certo tempo o fino ad una certa deadline (es. attiva una attività il tal giorno) Empty No-op (utilizzato ad es. per catturare un fault e non fare nulla)

27 Specificano il flusso di esecuzione Attività complesse 1/3 Sequence Ordinamento sequenziale delle attività innestate Switch Scelta di uno e un solo percorso fra una serie, in base a una condizione logica (ramo otherwise per indicare l else) Si sceglie il primo ramo valutato vero (non deterministicamente) Se nessuna condizione è true e non c è l else si suppone ci sia un implicito <otherwise><empty/></otherwise>

28 Attività complesse 2/3 While Ripetizione finchè una condizione non diventa vera Pick Mette il processo in attesa di una serie di messaggi o di un allarme Attesa di un messaggio: tag onmessage (= a receive) Allarme: tag onalarm (stessi attributi della wait) Appena scatta l allarme o arriva uno dei messaggi il processo si risveglia (se arrivano due messaggi simultanei scelta non deterministica) Il pick viene disattivato Può creare un istanza del processo Non ci dev essere un allarme

29 Attività complesse 3/3 Flow Concorrenza/sincronizzazione di attività Si può imporre l ordinamento fra attività concorrenti utilizzando dei link (reminiscenza di WSFL) Posso realizzare sincronizzazioni intermedie Ad una attività qualsiasi possiamo associare uno o più link sia in ingresso che in uscita Ogni link può essere associato ad una condizione logica A B C D F A B E sequenza C

30 Links Un attività è associata ad una condizione di join sullo stato dei link entranti Default: true se almeno uno dei link dà valutazione positiva Valutazione dei link: A termina tutti i suoi link uscenti sono valutati B dipendente da A tramite link valuta Se B è strutturalmente pronto a partire Se lo stato di tutti i suoi link entranti è stato valutato Se sì viene valutata la condizione di join Se vera B viene attivata Altrimenti viene sollevato un fault speciale

31 Dead Path Elimination Attributo (a livello di scope) per dire che non vogliamo questo tipo di fault In caso di condizione di join negativa: L attività B viene saltata Tutti i link uscenti da B vengono valutati negativamente La valutazione negativa si propaga finchè non si trova un punto in cui la condizione di join dà riscontro positivo (DPE)

32 Esempio I link possono scavalcare le attività strutturate (entro certi limiti ben fissati) sequence Join condition: C1 C2 A B C C1 C2 X Y

33 Gestione a livello applicativo della compensazione Compensation handlers L handler di compensazione non può modificare lo stato del processo (agisce solo sull esterno) In futuro ci sarà interazione L handler viene installato quando la parte di processo a cui si riferisce è completata È può in seguito essere invocato con <compensate> da Un fault handler L handler di compensazione dello scope che lo contiene

34 Event handlers Possiamo associare a uno scope degli eventi che scattano in maniera asincrona rispetto al processo Attivano un attività (complessa) La regola di triggering è l arrivo di un messaggio o un timer L evento rimane sempre abilitato (può riscattare arbitrariamente)

35 Gestione più approfondita di Espressioni Variabili Assegnamenti Estensione: processi eseguibili Possibilità di terminare esplicitamente il processo con <terminate> Maggior numero di fault

36 Estensione: business protocols Le variabili possono essere utilizzate anche se non inizializzate Potrebbero essere state manipolate da attività private Si possono omettere parametri nei messaggi Output: suppongo che siano gestiti implicitamente Input: il dato non mi interessa a livello pubblico Ipotesi sulle correlazioni Assegnamento con copia da una variabile opaca Non sappiamo qual è il suo valore Ne viene preso uno non deterministicamente dal suo spazio dei valori

37 Esempio client agent onmsg ontaskresult Task response assign Extract status Task response status escalate claim evaluate claim receive rectaskresult Task response receive initiate Initiate message invoke evalclaim Initiate message invoke evalclaim Initiate message pick end pick Rejection handling Acceptance hangling throw illegalstatus end otherwise status= accepted status= rejected onalarm 10 days Event onmsg kill terminate correlation

38 Implementazioni Lo standard lascia alcuni punti non specificati Es: al processo viene consegnato un messaggio quando non se lo aspetta Lo butta via? Segnala un errore? Lo tiene in sospeso? Solitamente il BPEL-engine mantiene una coda in cui inserisce i messaggi in arrivo per consumarli quando possibile Receive A A B A B Receive B B B A

39 Problematiche Nessuna interazione con l utente Nessuna possibilità di invocare attività private Qualche nota BPELJ rende possibile inserire sezioni di codice JAVA all interno del processo BPEL Descrive davvero un processo di business? Composizione di servizi con un approccio fortemente centralizzato Ogni interazione deve per forza riguardare l orchestratore Non c è la possibilità di invocare un (sotto)processo BPEL

40 WS-CDL The Web Services Choreography Description Language (WS-CDL) is a declarative XML-based language that describes peer-to-peer collaborations of participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal. WS1 WS2 WS3 WS4

41 Note generali WS-CDL: contratto collaborativo che specifica come i partecipanti devono interagire Interazione non più legata ad un centro di controllo Si separa l interazione dai partecipanti I partecipanti devono esibire un interfaccia di comportamento conforme alla coreografia Interoperabilità garantita dall interfaccia Fornisce uno strumento per superare le resistenze ad integrare servizi propri con quelli di altre parti La coreografia è a tutti gli effetti un contratto È un linguaggio descrittivo, non eseguibile Non per forza i partecipanti devono essere servizi!

42 Panoramica di WS-CDL Principalmente abbiamo Una parte dichiarativa Ruoli partecipanti Relazioni fra ruoli (commitments) Canali di comunicazione fra partecipanti Una parte conversazionale Descrizione dell interazione Contempla anche la possibilità di specificare l avanzamento della collaborazione in termini di informazioni e stato dei partecipanti Che possono eventualmente sincronizzarsi

43 Semantica degli elementi WS-CDL permette di agganciare agli elementi una descrizione Opzionale In maniera Testuale Specificando un URI Agganciandosi ad OWL oppure RDF

44 Parte dichiarativa Descrizione delle funzionalità e dei legami che i peer devono esibire per poter collaborare roletype Ruolo che un peer può giocare Enumera una serie di comportamenti che il ruolo esibisce Ogni comportamento può essere opzionalmente agganciato a un interfaccia WSDL participanttype Collezione dei ruoli assunti da un partecipante

45 relationshiptype Relazione tra due ruoli che interagiranno (mutual commitments) Relazioni Si possono anche inserire esplicitamente quali comportamenti sono richiesti dalla relazione (default: tutti quelli del ruolo) Ovviamente un partecipante può partecipare alla relazione se realizza il ruolo richiesto

46 Canali 1/2 Identificano come e dove scambiarsi informazioni per realizzare la collaborazione I canali possono essere passati come argomenti di un messaggio (PI calcolo ) Comunicazione dinamica Esempio il cliente spedisce il canale di consegna al provider Il provider effettua il forward al fornitore Il fornitore utilizza questo canale per spedire il bene al cliente (che prima non conosceva) Il canale può vincolare il suo uso Numero massimo di messaggi supportati Restrizione delle informazioni trasportabili (canali compresi)

47 Canali 2/2 Utilizzo possibile di un canale Once: una volta da un partecipante Distinct: più volte da un partecipante Shared: più volte da più partecipanti Azioni: Receive, Respond o Receive/Respond Associato al ruolo (comportamento) che chi lo utilizza deve esibire Specifica vincoli sui messaggi che possono transire Eventualmente agganciandosi ad altri canali

48 Esempio <channeltype name= OrderChannel action= request usage= distinct > <roletype typeref= Supplier /> <identity usage="primary"> <token name="orderid" /> </identity> <identity usage="alternate"> <token name="txnid" /> </identity> </channeltype> Messaggi accettati dal canale: All inizio solo messaggi contenenti OrderID Poi messaggi contenenti OrderID o TxnId

49 Variabili Utilizzate per più scopi Memorizzare le informazioni scambiate via messaggi Catturare lo stato di un partecipante Es: quando il cliente spedisce l ordine salva in una variabile di stato ORDER_SENT Descrivere i canali (politiche, URL, ) Variabili globali o relative a un ruolo Se due ruoli di un partecipante def. la stessa c è condivisione Attributi per specificare Politiche di lettura/scrittura della variabile Passaggio di variabili da una sotto-coreografia Token referenziano parti di variabili (via Xpath)

50 Coreografie Definiscono i contratti di interazione Attività, eccezioni, finalizers Nel documento si inseriscono una o più toplevel choreographies Una può essere dichiarata root (abilitata per default) Le altre vengono abilitate quando eseguite Una coreografia può richiamarne un altra (riusabilità) O definita localmente O richiamandone una di top-level (o esterna)

51 Coordinamento Coreografia - attributi indica che tutti i partecipanti devono essere d accordo su come la coreografia è terminata Eventualmente con un coordination protocol Isolamento Indica che le variabili utilizzate dalla coreografia sono visibili dalle altre solo quando termina Altrimenti c è condivisione delle variabili

52 Linea di vita father successfully completed no more activity enabled waiting initiator interaction performed enabled Complete condition==true succesfully completed exception (catched) exception (propagated) no finalizer finalizerblock completed unsuccesfully completed exceptionblock completed closed Enclosing choreographies closed

53 Interaction Attività fondamentale Modella lo scambio di informazioni tra partecipanti ed eventuale sincronizzazione del proprio stato osservabile Consiste nell invio di un messaggio Associata a Coppia di ruoli coinvolti e canale Operazione richiesta al ricevente Informazione scambiata Variabili utilizzate da sender e receiver per lo scambio Eventuali variabili di stato che reagiscono all interazione

54 Allineamento Indica la necessità di avere concordanza sugli effetti di un interazione su sender e receiver Controllando la coerenza nella modifica delle variabili di stato Verificando la consistenza delle variabili che memorizzano l info scambiata I partecipanti possono capire che il messaggio è stato effettivamente consegnato Esempio: buyer e seller vogliono verificare che dopo l effettuazione di un ordine orderstate(buyer)= Sent e orderstate(seller)= Received Le variabili order(buyer) e order(seller) hanno = contenuto

55 Interaction - exchange Exchange (scambio di informazioni) Specifica del fault (compatibilità con WSDL) Request o respond Info scambiate Send: cosa viene inviato Receive: cosa viene ricevuto Eventuale time-out Record riferiti dall exchange e/o dal time-out Manipolazione di variabili dicendo quando e come Nota: se più di una respond scelta implicita

56 Esempio <exchange name="request" informationtype="tns:purchaseordertype action="request"> <send variable="cdl:getvariable('tns:purchaseorder','','')" /> <receive variable="cdl:getvariable('tns:purchaseorder','','') recordreference="record-the-channel-info" /> </exchange> <exchange name="response" informationtype="purchaseorderacktype" action="respond"> <send variable="cdl:getvariable('tns:purchaseorderack','','')" /> <receive variable="cdl:getvariable('tns:purchaseorderack','','')" /> </exchange> <exchange name="badpurchaseorderackexception faultname="badpurchaseorderackexception informationtype="badpoacktype action="respond"> <send variable="cdl:getvariable('tns:badpurchaseorderack','','')" causeexception="tns:badpoack" /> <receive variable="cdl:getvariable('tns:badpurchaseorderack','','')" causeexception="tns:badpoack" /> </exchange>

57 Indica che si passa a eseguire una nuova coreografia (enclosed) Non devono esistere dipendenze cicliche Performance Fase di bind in cui si legano variabili del chiamante a quelle del chiamato Attributo block True si attende la fine della enclosed choreography False l enclosed choreography viene attivata in parallelo col flusso del chiamante Se il chiamante termina con successo l enclosed termina automaticamente con successo

58 Altre attività semplici Assign (~BPEL) silentaction Il ruolo esegue un operazione non osservabile dall esterno noaction (empty in BPEL) Nota: se il ruolo non viene specificato vuol dire che riguarda tutti

59 Unità di lavoro Attività preceduta da un vincolo Workunit condizione che deve essere verificata affinchè la collaborazione possa continuare Solo se (o quando) il vincolo è soddisfatto l attività viene abilitata Attributo block Si testa la condizione o si attende finchè non diventa vera Attributo repeat (modellazione di cicli) Indica che quando la workunit è terminata si considera di nuovo la condizione

60 Funzioni specifiche Funzioni richiamabili nelle condizioni Data/ora corrente Si suppone che gli orologi siano più o meno sincronizzati Test su deadline/timer Conoscenza dello stato della coreografia Gestione delle variabili Recupero valore o attesa disponibilità Test sull allineamento Trigger globali Variabili di diversi ruoli

61 Esempi <workunit name="waitforalignment" guard="cdl:variablesaligned('purchaseorderatbuyer', 'PurchaseOrderAtSeller', 'tns:customer-retailer-relationship')" block="true" > <!--some activity --> </workunit> <workunit name="stockcheck guard="cdl:getvariable('stockquantity','', '/Product/Qty','tns:Retailer')>10" block="false" > <!--some activity --> </workunit> False se la variabile non è disponibile

62 Ordering Structures Sequence Parallel Choice Mutua esclusione classica (deferred) Quando viene scelto un ramo gli altri sono disabilitati Se i rami contengono workunits con guardie Si possono realizzare punti decisionali La prima workunit che fa match (se più d una non determinismo) determina la scelta

63 Eccezioni Coreografia associata a una o più exception workunit Non bloccanti e non cicliche Default: nessuna guardia Altrimenti si esprime l interesse per una certa eccezione (funzione apposita) Le workunit sono abilitate quando viene abilitato l exceptionblock Meccanismo di match (se più di una non determinsmo) o propagazione L eccezione può leggere le variabili

64 Finalization Quando la coreografia termina con successo Può essere invocato uno fra una serie di finalizerblocks Gestiscono la compensazione della coreografia commit, undo, cancel, rollback applicativi I finalizer si distinguono per nome e ne viene scelto uno solo

65 Coordinamento 1/2 Garantisce che tutti i ruoli siano d accordo su come la coreografia è terminata Indica che un insieme di interazioni è allineato (conoscenza condivisa) Tutti i ruoli sanno che la coreografia è terminata con successo o meno L accordo viene raggiunto con un coordination protocol

66 Coordinamento 2/2 Nel caso di enclosed choreography l accordo è anche sull eventuale finalizer Se non c è coordinamento viene sollevata un eccezione Se la coreografia termina con un eccezione e alcuni ruoli non se ne accorgono, il protocollo di coordinamento solleva un eccezione su questi

67 Esempio 1/3 Retailer r4w r4c Warehouse w4r w4c c4r c4w Consumer

68 Esempio 2/3 POc POackc Interaction handlepo POreq POresp sequence POr POackr POr okr assign Interaction handlepo RWreq RWresp POw okw okr result clientsatisfied

69 Esempio 3/3 NON NOTO A PRIORI choice workunit block=false repeat=false guard=boolean(customersatisfied) Interaction handleporesponse POResp POResp POposResp perform CWchoreo La warehouse invia una ricevuta al consumer (estraendo il canale dal messaggio precedentemente ricevuto dal retailer) workunit block=false repeat=false guard=not(boolean(customersatisfied)) Interaction handleporesponse POResp POResp POnegResp

70 Qualche spunto 1/2 Van der Aalst. Life After BPEL? Sostiene che BPEL astratto è una forzatura Serve un linguaggio dichiarativo Indica tre importanti topic Process mining Riscostruzione di un processo da un event log Conformance testing Verifica di compliance su un event log Mediation Adattamento di un servizio in modo da permettergli di partecipare a una coreografia Conformance test ++

71 Qualche spunto 2/2 Barros, Dumas, Oaks. A critical overview of WS-CDL Topic Separare il meta-modello di coreografia dall XML Ricondurre WS-CDL a un linguaggio formale Per la verifica di proprietà Per la verifica di conformance Supporto di interazioni multi-party e multi-instance Rapporto con BPEL Come mappare le workunit sui costrutti BPEL? Necessità di definire un core unitario Notazione grafica per esprimere la coreografia a livello alto

72 FINE

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Composizione e Coreografia di Web Services

Composizione e Coreografia di Web Services Composizione e Coreografia di Web Services Giusy Di Lorenzo Composizione Lo scopo della composizione è quello di comporre servizi esistenti al fine di definire un nuovo servizio a valore aggiunto Richiesta

Dettagli

Processi BPEL. Obiettivi

Processi BPEL. Obiettivi Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Processi BPEL Corso di Sistemi Distribuiti Stefano Iannucci Anno accademico 2009/10 Email: sd@chmod.it Obiettivi Esercitazione pratica su:

Dettagli

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL)

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Corso di Sistemi Distribuiti Stefano

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi Sistemi Operativi Lez. 13: primitive per la concorrenza monitor e messaggi Osservazioni I semafori sono strumenti particolarmente potenti poiché consentono di risolvere ogni problema di sincronizzazione

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

Web Service Architecture

Web Service Architecture Giuseppe Della Penna Università degli Studi di L Aquila dellapenna@di.univaq.it http://dellapenna.univaq.it Engineering IgTechnology Info92 Maggioli Informatica Micron Technology Neta Nous Informatica

Dettagli

Introduzione a Service Oriented Architecture e Web Service

Introduzione a Service Oriented Architecture e Web Service Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica Introduzione a Service Oriented Architecture e Web Service Corso di Sistemi Distribuiti e Cloud Computing

Dettagli

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

Service Oriented Architectures (SOA)

Service Oriented Architectures (SOA) Facoltà di Ingegneria dell Informazione Laurea Specialistica in Ingegneria Informatica Facoltà di Ingegneria dei Sistemi Laurea Magistrale in Ingegneria Biomedica Dipartimento di Elettronica e Informazione

Dettagli

Idee guida. Finite State Machine (1) Un automa a stati finiti è definito da una 5- pla: FSM = , dove: Finite State Machine (2)

Idee guida. Finite State Machine (1) Un automa a stati finiti è definito da una 5- pla: FSM = <Q,,, q0, F>, dove: Finite State Machine (2) Idee guida ASM = FSM con stati generalizzati Le ASM rappresentano la forma matematica di Macchine Astratte che estendono la nozione di Finite State Machine Ground Model (descrizioni formali) Raffinamenti

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

MODELLO AD AMBIENTE GLOBALE

MODELLO AD AMBIENTE GLOBALE MODELLI DI INTERAZIONE TRA PROCESSI Modello ad ambiente globale ( global environment ) Modello a scambio di messaggi ( message passing ) MODELLO AD AMBIENTE GLOBALE Il sistema è visto come un insieme di

Dettagli

Seminario di Sistemi Distribuiti RPC su SOAP

Seminario di Sistemi Distribuiti RPC su SOAP Seminario di Sistemi Distribuiti RPC su SOAP Massimiliano Vivian [777775] Massimiliano Vivian 1 Introduzione La comunicazione delle informazioni è l elemento fondamentale per lo sviluppo dei sistemi. SOAP

Dettagli

Laboratorio di Sistemi Distribuiti

Laboratorio di Sistemi Distribuiti Laboratorio di Sistemi Distribuiti Bianchi Marco Univ. Roma Tor Vergata December 6, 2006 Bianchi Marco (Univ. Roma Tor Vergata) Laboratorio di Sistemi Distribuiti December 6, 2006 1 / 29 SOAP (2/2) 1 Gestione

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4 i Manuale Gestione di OpenSPCoop 1.4 ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Prerequisiti per la Configurazione della Porta di Dominio 1 2.1 Verifica dell applicazione di gestione

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 Prerequisiti per

Dettagli

Gestione XML della Porta di Dominio OpenSPCoop

Gestione XML della Porta di Dominio OpenSPCoop i Gestione XML della Porta di Dominio ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Hello World! 2 3 Configurazione XML della Porta di Dominio 5 3.1 Soggetto SPCoop...................................................

Dettagli

Definizione di Web service (2) Un introduzione ai Web service. Caratteristiche dei Web service. Valeria Cardellini Università di Roma Tor Vergata

Definizione di Web service (2) Un introduzione ai Web service. Caratteristiche dei Web service. Valeria Cardellini Università di Roma Tor Vergata Definizione di Web service Definizione fornita del W3C http://www.w3.org/tr/ws-arch/ Un introduzione ai Web service Valeria Cardellini Università di Roma Tor Vergata A Web service is a software system

Dettagli

Modello a scambio di messaggi

Modello a scambio di messaggi PRIMITIVE PER LO SCAMBIO DI MESSAGGI Un messaggio si può considerare costituito da: origine, destinazione e contenuto Modello a scambio di messaggi type messaggio = record origine: ; destinazione: ; contenuto:

Dettagli

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1 Sommario Web Services e Grid Services OGSA e WSRF SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org

1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org 1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org Prefazione. Da Hello World a Hello World Wide Web. Hello World è la prima frase stampata a video dal primo programma di esempio scritto

Dettagli

Un introduzione ai Web service

Un introduzione ai Web service Un introduzione ai Web service Valeria Cardellini Università di Roma Tor Vergata Definizione di Web service Definizione fornita del W3C http://www.w3.org/tr/ws-arch/ A Web service is a software system

Dettagli

Modeling and Testing of Web Services

Modeling and Testing of Web Services Modeling and Testing of Web Services Andrea Polini Dipartimento di Matematica ed Informatica Università degli Studi di Camerino andrea.polini@unicam.it (Andrea Polini) Modeling and Testing of Web Services

Dettagli

Modelli per la descrizione di protocolli

Modelli per la descrizione di protocolli POLITECNICO DI MILANO Corso di Laurea in Ingegneria Informatica Modelli per la descrizione di protocolli asincroni basati sull usouso di servizi Web Relatore: Prof. Stefano Ceri Correlatori: Ing. Marco

Dettagli

Introduzione ad Architetture Orientate ai Servizi e Web Service

Introduzione ad Architetture Orientate ai Servizi e Web Service Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ad Architetture Orientate ai Servizi e Web Service Corso di Sistemi Distribuiti Stefano Iannucci iannucci@ing.uniroma2.it Anno

Dettagli

Web Services e Grid Services. OGSA e WSRF

Web Services e Grid Services. OGSA e WSRF Web Services e Grid Services OGSA e WSRF Sommario SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

Agenda. Seminario. Cedac Software - Hardware. Cedac Software S.r.l.

Agenda. Seminario. Cedac Software - Hardware. Cedac Software S.r.l. Seminario Architetture SOA in ambito bancario: Tecnologia ed applicazioni Agenda Cedac Software ed il suo Business SOA e Web Services Realizzazione di un Caso di Studio Nuove tecnologie WS-* Q&A Cedac

Dettagli

Manuale gestione Porta di Dominio OpenSPCoop 1.1

Manuale gestione Porta di Dominio OpenSPCoop 1.1 i Manuale gestione Porta di Dominio ii Copyright 2005-2008 Link.it srl Questo documento contiene informazioni di proprietà riservata, protette da copyright. Tutti i diritti sono riservati. Non è permesso

Dettagli

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE Università degli studi di Ferrara Facoltà di scienze MM.FF.NN. Corso di Laurea Specialistica in Informatica Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

Sistemi Informativi. Introduzione. Processi fisici. Tipologie di processi. Processi informativi. Processi aziendali

Sistemi Informativi. Introduzione. Processi fisici. Tipologie di processi. Processi informativi. Processi aziendali Introduzione Sistemi Informativi Linguaggi per la modellazione dei processi aziendali Paolo Maggi Per progettare un sistema informativo è necessario identificare tutti i suoi elementi

Dettagli

Web Services Security

Web Services Security Web Services Security Introduzione ai Web Services Davide Marrone Sommario Cosa sono i web services Architettura dei web services XML-RPC SOAP (Simple Object Access Protocol) WSDL (Web Services Description

Dettagli

JAVASCRIPT. Tale file è associato alla pagina web mediante il tag