Anna Rita Fasolino » 10.Ingegnerizzazione dei Servizi

Argomenti

• Ingegnerizzazione dei Servizi (Service Engineering)
• Sviluppo di software basato su Servizi

Service-oriented software engineering

Gli approcci di ingegneria del software esistenti devono necessariamente cambiare per tener conto dell’approccio di sviluppo software service-oriented.

Due temi fondamentali:

1. Service engineering. Tratta lo sviluppo di servizi ‘dependable’ e riusabili - Sviluppo di software per il riuso.
2. Sviluppo Software basato su servizi. Si occupa di sviluppare software fidato riusando servizi software - Sviluppo di software con il riuso.

Service engineering

É il processo di sviluppo di servizi riusabili per applicazioni service-oriented.
Il servizio deve essere progettato come una astrazione riusabile nell’ambito di diversi sistemi.
Richiede

• L’identificazione del servizio candidato.
• La progettazione del servizio.
• L’implementazione e consegna del servizio.

Il Processo di Service Engineering

(1): Identificazione dei servizi candidati

I servizi possono essere classificati in tre categorie fondamentali:

1. Servizi di utilità che implementano funzionalità di carattere generale, applicabili a diversi problemi.
2. Servizi di business, utili all’interno di una particolare tipologia di dominio aziendale.
3. Servizi di coordinazione che supportano la composizione di servizi complessi. Interagiscono con i servizi più generali, consentendo di ricavarne astrazioni di domini.

Un’altra classificazione distingue tra servizi orientati alle attività (task) o alle entità.

Esempi di servizi

Domande utili per la ricerca di servizi riusabili

Nel caso di un servizio orientato alle entità, il servizio è associato ad una singola entità logica che è usata in diversi prcessi di business?
Nel caso di un servizio orientato alle attività, tale attività è eseguita da più persone di una organizzazione?
Il servizio è indipendente o fino a che punto ha bisogno di altri servizi?
Il servizio ha bisogno di mantenere aggiornato uno stato interno? a tal fine, ha bisogno di un database?
Il servizio potrebbe essere usato anche all’esterno, da più clienti?
É probabile che clienti diversi del servizio richiedano diversi requisiti non funzionali ad esso?

Il servizio di un Catalogo

É un esempio di servizio orientato alle entità che supporta operazioni di business. Le operazioni devono permettere ad un produttore di articoli di mostrare il catalogo degli articoli acquistabili (es. Computer) dai suoi clienti.
Requisiti Funzionali del servizio
Una versione specifica del catalogo dovrebbe essere creata per ciascun cliente (con prezzi e config. concordate).
Deve essere possibile fare il download del catalogo.
Si devono confrontare specifiche e prezzi di fino a 6 articoli del catalogo.
Devono essere fornite funzionalità di ricerca e Browsing.
Deve esserci una funzione che permette di stimare la data di consegna per gli articoli indicati.
Gli utenti devono potre fare ordini virtuali da confermare entro 48 ore con un ordine reale.

Il Servizio di un Catalogo (segue)

Requisiti non funzionali del servizio
L’accesso al catalogo deve essere consentito solo agli impiegati di organizzazioni accreditate.
I prezzi e le configurazioni offerte ai vari clienti saranno confidenziali.
Il catalogo deve essere disponibile dalle 07:00 alle 11:00.
Il catalogo deve essere in grado di elaborare fino a 10 richieste al secondo.

Descrizione delle Operazioni del Servizio di Catalogo

(2) Progettazione dell’Interfaccia del servizio

Richiede la definizione delle operazioni associate al servizio e dei loro parametri.
Il numero di messaggi scambiati per completare una richiesta di servizio dovrebbe essere minimo.
I servizi devono essere senza stato: pertanto potrà essere necessario passare informazioni sullo stato (in ingresso o uscita) per mezzo dei messaggi di input/output.

Le fasi di progettazione dell’Interfaccia

Logical interface design
Si identificano I nomi delle operazioni associate al servizio, i parametri di input e output, e le eventuali eccezioni.
Message design
Progettazione dei messaggi (struttura dei messaggi in input ed output, ed il tipo dei parametri). Preferibile l’uso di linguaggi come l’UML (da tradurre poi in XML) piuttosto che direttamente l’XML.
WSDL description
La specifica logica dell’interfaccia del servizio è tradotta in WSDL.

Progettazione dell’Interfaccia del catalogo

Struttura dei messaggi di Input e output per l’operazione CheckDelivery

(3) Implementazione e consegna del Servizio

Il servizio può essere implementato usando linguaggi standard di programmazione (come C# o Java) che forniscono librerie per lo sviluppo di servizi.
Alternativamente, i servizi possono essere implementati usando componenti preesistenti, sistemi ereditati, o definendo una composizione di servizi pre-esistenti con linguaggi di workflow.
I servizi devono essere poi testati partizionando gli input, creando vari messaggi di input, e verificando che i messaggi di output prodotti siano corretti rispetto alla specifica.
La consegna richiede che il servizio sia pubblicizzato usando UDDI e che venga installato su un web server. Molti server forniscono supporto per una semplice installazione del servizio.

Ulteriori caratteristiche

I Web Service mostrano solamente l’interfaccia dei servizi forniti, mentre non dovrebbero aver bisogno di altre risorse.

• Se il Web Service dovesse aver bisogno di dati persistenti, nel suo codice dovrà essere inglobato il codice per l’accesso alla risorsa (ad esempio un database).
• In questo modo il WS può operare da proxy nell’accesso al database.

I Web Service possono mantenere lo stato unicamente sfruttando variabili di sessione e le altre possibilità messe a disposizione dai protocolli della famiglia http.

Application server

I Web Service devono essere installati (deployed) all’interno di un application server
L’application server, analogamente ad un web server, ascolta su alcuni porti le richieste http in arrivo.
Le richieste codificate con linguaggi come SOAP vengono processate:

• Viene eseguito il Web Service richiesto con i parametri che è possibile estrarre dal messaggio SOAP di richiesta.
• Viene generato e inviato al sender un messaggio SOAP di risposta contenente tra l’altro i parametri risultato dell’elaborazione.

L’application server rende accessibile anche il catalogo dei WSDL dei servizi messi a disposizione.
Esempio di application server: Apache Tomcat. Tomcat è in realtà un’estensione al web server Apache.

UDDI

Elemento fondamentale delle architetture SOA è la descrizione della semantica del servizio fornito che permetta, idealmente, la ricerca automatica di un servizio data la sua descrizione funzionale e, eventualmente, i requisiti di qualità richiesti o graditi.
Il linguaggio più spesso utilizzato per fornire tale descrizione semantica é UDDI (dialetto XML). Un documento UDDI contiene:

• Dettagli sul fornitore del servizio.
• Descrizione (informale) delle funzionalità fornite.
• Posizione della descrizione WSDL dell’interfaccia.

C’è un ampio dibattito sulla definizione di standard:

• che permettano una più precisa descrizione semantica dei servizi (utilizzando eventualmente anche ontologie);
• che permettano di descrivere più precisamente i requisiti di qualità (Quality of Service – QoS).

Legacy system services

Un importante vantaggio nell’uso dei servizi è che essi danno la possibilità di accedere alle funzionalità di legacy systems.
I Legacy systems offrono funzionalità mature e stabili, il cui riuso può ridurre i costi di sviluppo dei servizi.
Le applicazioni esterne potranno accedere a queste funzionalità attraverso l’interfaccia offerta dai servizi.

Accesso al sistema Legacy

Le funzionalità del sistema legacy sono rese disponibili sotto forma di Servizi.

Migrazione di sistemi legacy verso SOA

Le tecnologie SOA (e i Web Service in particolare) sono particolarmente utili per la migrazione di funzionalità critiche di sistemi legacy.

Spesso, infatti, le funzionalità presenti nei sistemi legacy risolvono problemi particolarmente critici e sono da considerare molto affidabili, in quanto sono in opera da molti anni.

Migrando tali funzionalità sotto forma di Web Services, si aprono scenari per:

• L’adattamento a interfacce moderne (ad esempio interfacce web).
• La composizione all’interno di architetture moderne.

Una tecnica di migrazione basata su Wrapping per rendere accessibili le funzionalità di un sistema legacy sotto forma di servizi web è presentata in [1].

[1] G. Canfora, A.R. Fasolino, G. Frattolillo, P. Tramontana, “A Wrapping Approach for Migrating Legacy System Interactive Functionalities to Service Oriented Architectures”,
Journal of Software and Systems JSS, Elsevier, n° 81, 2008, pp. 463-480.

Il ruolo del Wrapper nella migrazione di sistemi legacy con interfaccia utente basata su form

Il wrapper ha il ruolo di interagire col sistema legacy (fornendo ad esso dati e comandi) al posto dell'utente. Grazie al wrapper il sistema legacy esporterà una interfaccia da Web Service.

Sviluppo Software basato su servizi

L’idea è di comporre e configurare servizi esistenti per creare nuovi servizi composti ed applicazioni.

La base per la composizione del servizio è spesso un workflow:

• I Workflow sono sequenze logiche di attività che, insieme, modellano processi aziendali
• Ad esempio, una composizione di servizi per prenotare un viaggio che cordina vari servizi di prenotazione volo, auto ed albergo.

Esempio: workflow per la prenotazione di una vacanza

Composizione di servizi

Lo scenario ideale prospettato dalle SOA è uno scenario nel quale:

• Si descrive un problema in un linguaggio formale (ma il più possibile intuitivo e vicino al linguaggio naturale).
• Un motore di interpretazione scompone il problema in un workflow di sottoproblemi.
• Vengono automaticamente ricercati e reperiti Web Service in grado di risolvere ogni sottoproblema.
• Viene automaticamente composto il workflow in grado di risolvere il problema proposto.

Construzione di un servizio mediante composizione

Processo di composizione

Le difficoltà legate alla realizzazione di un workflow di servizi provenienti da fonti eterogenee sono comunque notevoli.

In particolare bisogna tener conto di tutte le possibili eccezioni di ogni servizio e delle conseguenti azioni da intraprendere per recuperare dall’eccezione.

Ad esempio, se la prenotazione del viaggio va a buon fine ma fallisce quella dell’albergo, la semantica del servizio potrebbe prevedere la necessità di annullare la prenotazione del viaggio. Per fare ciò è necessario un ulteriore Web Service di annullamento prenotazione.

Il workflow per la prenotazione di una camera di hotel

Progetto e implementazione dei workflow

Sono stati proposti diversi linguaggi per la descrizione di workflow di servizi web

• WS-BPEL è al momento il più comune. E’ anch’esso un dialetto XML.
• Esistono componenti che vanno a estendere le funzionalità dell’application service, che agiscono da interpreti di documenti BPEL ed esecutori di Workflow. Esempio: BPEL4WS.
• Esistono inoltre strumenti come BPMN per la definizione visuale di workflow di web service.

Il Testing dei Servizi

Il Testing ha lo scopo di trovare difetti e dimostrare che un sistema soddisfa I suoi requisiti funzionali e non-funzionali.

Il testing dei servizi da parte del cliente del servizio è difficile in quanto I servizi (esterni) sono ‘black-boxes’. Le tecniche di Testing basate sul codice sorgente non possono essere usate (se non nell’ambiente del produttore), mentre sono usabili tecniche black-box (es. Partition testing).

Alcuni problemi nel Testing di Servizi

Eventuali modifiche ad un Servizio potrebbero invalidare i test già effettuati.
Se si utilizza in binding dinamico (ovvero la ricerca “on-line” del servizio più adatto alla risoluzione di un problema), si dovrebbero rieseguire tutti I test progettati prima di utilizzare effettivamente il servizio.
Le caratteristiche di qualità del servizio (ad esempio velocità, tempo di risposta), dipendono dal carico e non possono essere previste
Se i servizi sono a pagamento, il loro utilizzo a scopo di test è costoso.
Può essere difficile esercitare le azioni per la gestione delle eccezioni in servizi esterni, giacchè esse possono dipendere da fallimenti di altri servizi che non possono essere simulati.