Linea guida: Servizio
Tale linea guida elabora la definizione di un servizio come risorsa software scopribile come una specifica di servizio esternata.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

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.

Scopribile

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.

Esternamente Specificato

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.

Basato sul contratto

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.

allineamento del business

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.

Modellamento di un servizio

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.

Il diagramma viene descritto nel contenuto testuale.

  • 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.