Un servizio è la risorsa chiave in una SOA (Service-Oriented Architecture), ma cos'è un servizio? Segue la voce del
glossario RUP (Rational Unified Process).
Un servizio è una risorsa software (scopribile) con una specifica di servizio esternata. Questa specifica di
servizio è disponibile per la ricerca, il binding e la chiamata da parte di un utente del servizio. Il provider del
servizio realizza l'implementazione della specifica di servizio ed inoltre distribuisce la qualità dei requisiti del
servizio all'utente del servizio. I servizi saranno governati dalle politiche dichiarate e pertanto supporteranno uno
stile strutturale riconfigurabile dinamicamente.
E, mentre la sezione seguente traccia alcune delle istruzioni chiave nella voce precedente, è importante notare un
ulteriore aspetto dei servizi che realmente li diversifica dagli elementi della progettazione nelle tecnologie
precedenti; i servizi sono ad un livello di granularità che ne consente l'identificazione da un livello del business.
Perciò in seguito verrà discussa la natura allineata al business dei servizi.
I servizi non sono parte di un'architettura dell'applicazione monolitica. Esistono nel runtime indipendentemente da
qualsiasi altro servizio all'interno di una soluzione data. Ciò significa che si richiede un metodo per la
registrazione e la scoperta di servizi basati su criteri come Risorsa: Specifica del servizio che realizza, Risorsa: Provider del servizio, oltre ad altre classificazioni
business e tecniche. Questo processo di scoperta potrebbe aver luogo durante il periodo dello sviluppo per far
corrispondere i servizi dati ai servizi supportati o potrebbe verificarsi nel runtime per abilitare la creazione
dinamica dei servizi (chiamata mediata). Per essere scopribile, è necessario che un servizio fornisca una serie di
metadati che consentano la suddivisione in categorie. Questi metadati sono una parte della specifica esterna.
Per ulteriori informazioni, consultare il Concetto: Portafoglio del servizio e la Linea guida: Mediazione del servizio.
La specifica esterna consente un servizio per pubblicare i dettagli come interfaccia, posizione, politiche,
classificazioni e così via senza la necessità per il client di accedere al servizio stesso. Tali informazioni vengono
memorizzate di solito in una posizione nota e in un registro del servizio specializzato che supporti le query dei
metadati. Attualmente nel mondo dei servizi web, lo standard accettato per la descrizione delle interfacce dei servizi
è WSDL (Web Services Description Language), che deriva da World Wide Web
Consortium.
Il prodotto di lavoro della specifica servizi è in realtà una combinazione di tre parti:l'interfaccia, il funzionamento
e la specifica della politica. Per questa ragione, la realizzazione di questi aspetti diversi richiede più che
semplicemente la definizione dell'interfaccia fornita da WSDL.
Per ulteriori informazioni sui registri del servizio, consultare il Concetto: Portafoglio del servizio.
Si noti che, nella definizione del glossario precedente, la specifica di servizio fornisce una vista sia per il
provider del servizio che per l'utente del servizio. Tali viste corrispondono alle due metà di un contratto che
consente la chiara separazione della specifica dall'implementazione.
La tabella seguente descrive il modo in cui aspetti differenti di una specifica del servizio influiscano sia sul
provider che sull'utente della specifica.
Ruolo
|
Specifica dell'interfaccia
|
Specifica del funzionamento
|
Specifica della politica
|
Provider
|
Fornisce informazioni sull'insieme delle operazioni e dei messaggi a cui deve rispondere il servizio. E'
necessario che tutte le operazioni rispondano e replichino con i messaggi corretti.
|
Fornisce informazioni sul funzionamento che è necessario che questo servizio supporti. Se questo
funzionamento è formale e completo, è possibile testare un'implementazione per verificarne la conformità
alla specifica.
|
Fornisce informazioni riguardo ad una serie di vincoli a cui deve sottostare l'implementazione del servizio
oltre che un insieme di qualità del servizio che è necessario realizzare.
|
Utente
|
Fornisce informazioni sull'insieme di operazioni che è possibile richiamare.
|
Fornisce informazioni riguardo ai requisiti del protocollo che è necessario che un utente realizzi (ordine
dell'operazione, flussi di dati e così via). Indica inoltre le operazioni che è necessario che l'utente
implementi per supportare le collaborazioni.
|
Fornisce le informazioni riguardo ai vincoli che è necessario che l'utente conosca, come i requisiti della
sicurezza, nella comunicazione con questo servizio. Identifica inoltre le qualità del servizio che è
possibile che un utente ottenga da un provider dato.
|
E' possibile vedere una tale specifica di servizio come un'applicazione della progettazione per contratto ma è un passo
necessario nell'acquisizione dei servizi scopribili e riconfigurabili dinamicamente.
In generale, la connessione tra i modelli del business che rappresentano le operazioni del business ed i modelli della
progettazione per il supporto delle applicazioni IT è stata eseguita al meglio debolmente. Nella maggior parte dei
casi, sono stati completamente disconnessi. Mentre il RUP fornisce una guida sulla transizione dai modelli del business
ai modelli di casi d'uso del sistema (consultare la linea guida Dai modelli del business ai sistemi), la
connessione richiede alcune trasformazioni come le modifiche del livello di granularità e di astrazione dal business
alle prospettive IT.
In generale, è chiaro che è possibile classificare quei servizi nei servizi del business o dell'infrastruttura.
Consultare il Concetto: Portafoglio del concetto per una discussione delle classificazioni del
servizio.
Un'aspetto importante delle SOA è che il livello di granularità dei servizi descritto in una soluzione orientata al
servizio è tale che le operazioni fornite dai servizi possono essere spesso identificate a livello del business. Questo
aumento nel livello di granularità nel supporto IT significa che, in molti casi, le attività identificate nei modelli
del processo business possono essere realizzate direttamente come operazioni sui servizi. Pertanto gli utenti del
business delle soluzioni IT diventano sempre più parte del processo si analisi e di progettazione. E' anche
interessante notare che questa connessione stretta con il modello del processo del business associa più direttamente i
servizi come prodotti di lavoro IT, agli Obiettivi del business modellati nella disciplina di modellamento del
business.
Per ulteriori dettagli sulla connessione tra i modelli di business e di servizio, consultare l'Attività: Analisi asset esistente.
Nel modellamento del servizio, utilizzare il Profilo UML (Unified Modeling Language) per i servizi software e la guida fornita
per ciascun elemento nel profilo. In generale, gli elementi che compongono la vista statica dei servizi e delle
specifiche di servizio in un modello del servizio, vengono mostrati nel diagramma sottostante.
-
The Service Provider "UpdateCustomerAddressLegacyProvider" fornisce un "UpdateCustomerAddress" del servizio.
-
Il servizio "UpdateCustomerAddress" implementa la specifica di servizio "IUpdateCustomerAddress."
-
La specifica di servizio "IUpdateCustomerAddress" dispone di un'operazione singola "execUpdateCustomerAddress."
-
L'operazione "execUpdateCustomerAddress" utilizza un singolo messaggio di input, "UpdateCustomerRequest."
-
L'operazione "execUpdateCustomerAddress" restituisce un singolo messaggio di output, "UpdateCustomerResponse."
Le viste della struttura e della composizione del modello riportano la comunicazione tra i servizi ed il
partizionamento della soluzione. Questo è l'indirizzo nel Concetto: Composizione e coreografia del servizio eConcetto: Partizionamento della soluzione.
Metodi alternativi
Come succede spesso con il modellamento, esistono metodi alternativi per modellare la stessa struttura logica e, in
alcuni casi, le tecniche possono essere utilizzate per rappresentare ulteriori dettagli tecnici. Ad esempio, nel
modellamento della nozione delle funzioni fornite e richieste per un servizio, è possibile scegliere di stereotipare le
interfacce che descrivono queste funzioni come Specifiche di servizio ed utilizzare una classe non stereotipata
per rappresentare il tipo combinato, o scegliere di stereotipare la classe stessa e non le interfacce. Entrambe queste
opzioni sono illustrate nella figura di seguito riportata.
In generale, è necessario stereotipare le interfacce se queste saranno utilizzate da altri servizi in un contesto
diverso, così la regola è che qualsiasi elemento che viene considerato come le descrizione riutilizzabile andrebbe
stereotipato. Quando si crea un servizio su un provider di servizi (in termini UML una porta su una classe o
componente) selezionare la classe ServiceType o MyService come tipo di porta stereotipata, come di seguito illustrato.
Notare che la struttura risultante sarà identica per ServiceType o MyService, la porta indica un'interfaccia richiesta
ed un'interfaccia fornita - possibilmente un'interfaccia di richiamata che al client è richiesto fornire. Tuttavia, in
alcuni casi, è utile separare esplicitamente le funzioni richieste e fornite in diverse descrizioni del servizio. In
questo caso sono necessarie due classi che realizzano le specifiche del servizio presentate precedentemente. La figura
di seguito riportata dimostra queste classi.
Ora, quando viene creato il provider del servizio, sono necessarie due porte stereotipate, come di seguito illustrato,
una per rappresentare le funzioni di chiamata e una per la funzione di richiamata.
La necessità di altra flessibilità dipende molto dall'attività e dal livello di formalità necessaria da includere nei
modelli. L'esempio alla fine è molto chiaro ed è molto chiaro che esistono nozioni separate di un'interfaccia di
chiamata e di richiamata; tuttavia, cosa accade se lo stesso provider implementa un numero di endpoint del
servizio? La proliferazione di porte potrebbe rendere il risultato finale difficile da leggere e comprendere.
Per ulteriori informazioni sulla progettazione e l'implementazione dei servizi, consultare Attività: Decisioni di realizzazione del servizio del documento.
|