Anna Rita Fasolino » 9.Ingegneria del Software orientato ai Servizi

Argomenti

• Servizi software come componenti riusabili
• Ingegnerizzazione dei Servizi (Service Engineering)
• Sviluppo software basato su Servizi

Premessa

La realizzazione di sistemi distribuiti su piattaforme eterogenee richiede l’utilizzo di middleware che forniscono i servizi atti a consentire la comunicazione fra componenti distribuiti.

• I middleware possono essere più o meno difficili da usare (es. CORBA vs. Java RMI), e fornire servizi più o meno sofisticati.
• Non è possibile far comunicare componenti aderenti a diversi modelli di componente e relativi middleware (es. client DCOM e server RMI).
• I middleware sono usabili sono in ambito intranet, data l’impossibilità per i dati scambiati (in binario basati su specifici protocolli) di superare i firewall aziendali.

Il futuro: Architetture orientate ai servizi

Le Architetture Orientate ai Servizi (SOA) sono state proposte per consentire una sistematica interazione fra applicazioni (application-to-application). Svincolandosi dai limiti delle architetture a componenti basate su middleware.

In particolare:

• I “Web services” rappresentano uno sforzo verso la costruzione di una piattaforma di calcolo distribuita basata sull’infrastruttura offerta dal Web.
• I Web services possono essere definiti come servizi che possono essere pubblicati, localizzati, ed invocati via Internet.
• I Web Services consentono il passaggio dal modello primario del Web ‘Human-Centric‘ al modello ‘Application-Centric‘, fino alla visione del ‘Web Automatico‘.

Service-oriented architectures (SOA)

Le Architetture Orientate ai Servizi (SOA) sono un modo di progettare sistemi distribuiti i cui componenti sono costituiti da servizi indipendenti.

I servizi sono componenti stand-alone, in grado di risolvere specifici problemi, che possono essere offerti da differenti fornitori ed essere eseguiti su computer diversi.

Per rendere possibili tali attività, devono essere adottati protocolli standard per supportare:

• la comunicazione fra servizi;
• lo scambio di informazioni fra servizi.

Attori nelle SOA

Attori nelle SOA (segue)

Sviluppo di Servizi

Obiettivi:

• Consentire l’interoperabilità universale;
• Consentire una diffusa adozione e l’ubiquità dei servizi;
• Abilitare il binding dinamico (su scala geografica);
• Supportare efficacemente sia ambienti aperti (Web) che più vincolati.

Sviluppo di Servizi (segue)

Requisiti:

• Basati su standard (che forniscono un supporto pervasivo);
• Si richiede solo la disponibilità di una minima infrastruttura (è richiesto solo l’implementazione di un set minimo di standard);
• Possibilità di concentrarsi su messaggi e documenti scambiati, piuttosto che su API.

Sviluppo di servizi: vantaggi

I servizi possono essere sviluppati localmente, o essere prodotti da fornitori esterni.

Per accedere ai servizi è necessario conoscere unicamente la loro interfaccia. L’accesso ai servizi è possibile attraverso un linguaggio standard, indipendentemente dal linguaggio con cui i servizi sono stati implementati.

E’ possibile recuperare (tramite wrapper) funzionalità di sistemi esistenti (legacy systems).

Aziende o altre organizzazioni possono cooperare utilizzando funzioni di business altrui e avvalendosi di un meccanismo di scambio dati semplificato: supporto al Collaborative Computing.

Stack e protocolli per i Web Services

Alcuni standard

SOAP
Protocollo per lo scambio di messaggio, tipicamente implementato su http o https.

WSDL (Web Service Definition Language)
Protocollo per lo scambio di informazioni descriventi l’interfaccia del Web Service e il collegamento con il servizio vero e proprio.

UDDI (Universal Description, Discovery, and Integration)
Definisce la semantica del servizio, in maniera tale da consentire la scoperta automatica dell’esistenza del servizio.

WS-BPEL
Permette di definire la modalità di composizione di servizi.

Servizi come componenti riusabili

Definizione di servizio e di Web Service

• Un componente software riusabile, debolmente accoppiato, che incapsula una funzionalità discreta, può essere distribuito e vi si può accedere mediante programmazione.
• Un Web Service è un servizio a cui si accede attraverso protocolli standard Internet e protocolli basati su XML.

Principali analogie e differenze fra servizi e componenti in CBSE

Anche i servizi incapsulano funzionalità riusabili in diversi contesti.
Ma i servizi devono essere necessariamente indipendenti da altri servizi e debolmente accoppiati:

• La loro funzione deve essere eseguita in maniera indipendente dall’ambiente di esecuzione.
• In pratica per i servizi non è definita l’interfaccia “richiede”, ma solo l’interfaccia “fornisce”.

L’interazione con i servizi è basata unicamente sullo scambio di messaggi. Diversamente dalla comunicazione fra componenti che richiede l’invocazione di metodi (API).

Differenti modalità di interazione

La comunicazione fra componenti è basata sull’invocazione di metodi.
L’interazione con i servizi è basata unicamente sullo scambio di messaggi.

• Lo scambio di messaggi è del tipo Request/ Response (e può essere basato su XML).
• I servizi possono essere visti come funzioni remote (scambio basato su RPC), non come oggetti (scambio basato su chiamata -eventualmente sincrona- di metodi).

I servizi adottano un modello di comunicazione asincrona, mentre l’interazione fra componenti è più aderente ad un modello di interazione sincrona.

Esempio di Interazione Sincrona

L'ordinazione viene composta secondo una interazione sincrona tra cameriere e cliente.

Un’ordinazione espressa in XML

L'ordinazione verrà passata in cucina attraverso un unico messaggio XML.

Web service description language (WSDL)

Le interfacce dei servizi sono espresse in linguaggio WSDL. Una specifica WSDL definisce

• Quali operazioni sono fornite dal servizio (Interfaccia astratta)
  • Per ogni operazione è specificato il formato del messaggio di richiesta e il formato del messaggio di risposta.
• Come accedere al servizio
  • Binding: specifica come devono essere costruiti I messaggi di I/O ed il protocollo da seguire nello scambio di messaggi.
• Dove si trova il servizio, in termini di URI (Universal Resource Identifier)
  • URI è l’indirizzo di una risorsa accessibile via Internet ed è una generalizzazione del concetto di indirizzo web.

Struttura di una specifica WSDL

Struttura XML di una specifica WSDL (segue)

Un frammento di specifica WSDL

Un frammento di specifica WSDL (segue)

Un Web Service in pratica

Consideriamo un semplice esempio di Web Service
Quest’esempio è fornito insieme all’interfaccia utente che si integra con NetBeans per la generazione e testing di Web Service.

Si vuole realizzare un semplice Web Service add che è in grado di restituire la somma di due numeri interi, avuti come parametri di ingresso.

Si tratta, evidentemente di un servizio che fornisce una interfaccia ma non ne richiede.

Codice del Web Service

// Copyright (c) 2007, Sun Microsystems, Inc. All rights reserved.
package org.me.calculator;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

@WebService()
public class CalculatorWS {
/**
* Web service operation
*/
@WebMethod(operationName = "add")
public int add(@WebParam(name = "i") int i, @WebParam(name = "j") int j) {
return i + j;
}

}

Con la @ sono indicati dei commenti.
La classe CalculatorWS in questo caso implementa un unico metodo add: sarà questo metodo ad essere esposto come Web Service.

Codice del documento WSDL (1)

Codice del documento WSDL (2)

Codice del client di prova