Di Simon Johnston, Architetto, IBM Corporation.
Questo documento descrive il profilo UML per i servizi software, un profilo per UML 2.0 che consente la modellazione dei servizi, le soluzioni orientate ai servizi e SOA. Lo scopo del profilo è di fornire un linguaggio comune per la descrizione dei servizi che copra un numero di attività attraverso il ciclo di vita dello sviluppo e che fornisca anche le viste ai diversi stakeholder. Così, ad esempio, il profilo fornisce le capacità all'architetto di progettare i servizi all'inizio del ciclo di vita utilizzando le partizioni logiche per descrivere l'intero portafoglio servizi per tutta l'organizzazione. Questa vista viene ulteriormente descritta in dettaglio dai progettisti che sviluppano le specifiche dei servizi, sia strutturali che comportamentali che fungono da contratti tra i client dei servizi e gli implementatori. La vista messaggi fornisce la capacità ai progettisti di riutilizzare i modelli delle informazioni per le definizioni dei dati dei servizi comuni.
Il profilo è stato realizzato in RSA (Rational Software Architect) ed utilizzato con successo nello sviluppo di modelli di scenari complessi dei clienti complessi ed anche ad educare agli obiettivi relativi allo sviluppo delle soluzioni orientate ai servizi.
Il diagramma seguente è un modello che illustra i concetti importanti nella modellazione dei servizi. Come si può vedere, il numero dei concetti è relativamente piccolo e dovrebbe essere ragionevolmente noto a chiunque abbia lavorato sulle soluzioni orientate ai servizi. E' bene notare, tuttavia che sebbene il profilo sia una realizzazione di questo modello alcuni concetti non sono stereotipi espliciti nel profilo. Ad esempio, non vi è alcuno stereotipo per l'operazione o per il protocollo poiché si tratta di nozioni esistenti in UML 2.0 riutilizzate dal profilo senza alcuna ambiguità o ulteriore limitazione.
La tabella seguente elenca gli elementi del meta modello UML 2.0 utilizzati come meta classi per gli stereotipi nel profilo UML.
Meta classe UML 2.0 | Stereotipi |
---|---|
Classe | Messaggio, Partizione del servizio, Fornitore del servizio |
Classificatore | Utente del servizio |
Collaborazione | Collaborazione del servizio |
Connettore | Canale del servizio |
Interfaccia | Specifica del servizio |
Porta | Servizio, Gateway |
Proprietà | Allegato del messaggio |
Il diagramma seguente (selezionabile) è un diagramma del profilo UML 2.0, illustra i dettagli attuali del profilo con ogni stereotipo, la meta classe relativa che utilizza la notazione di estensione (testa della freccia piena).E' inoltre possibile visualizzare alcune limitazioni nel modello, particolarmente quelle tra gli elementi del profilo.
Le sezioni seguenti trattano degli elementi del profilo UML 2.0 come correntemente definito. Ogni sezione tratta uno stereotipo singolo; i dettagli di ciascuno specificano la meta classe relativa, le proprietà e tutte le limitazioni che potrebbero essere applicate quando si utilizza il profilo.
Classe
Un messaggio rappresenta il concetto come definito nella specifica WSDL, ad es. un contenitore per dati reali che hanno significato per il servizio e l'utente. Un messaggio potrebbe non avere operazioni, potrebbe avere proprietà ed associazioni ad altre classi (si presume, classi di alcuni modelli di dominio).
Uno stereotipo di messaggio dispone di una proprietà per indicare la forma di codifica assunta (ad es.
SOAP-literal
, SOAP-rpc
, ASN.1
, ecc.).
L'utilizzo di questo elemento in uno strumento, potrebbe essere facoltativo per due motivi. In primo luogo, il modellatore potrebbe desiderare semplicemente di utilizzare gli elementi da un modello di dominio direttamente come parametri di un'operazione piuttosto che specificare un messaggio. In secondo luogo, il modellatore potrebbe desiderare di utilizzare la convenzione di specifica di un insieme di messaggi di input e output su un'operazione, nel qual caso lo strumento di modellazione dovrebbe costruire un messaggio di input e output che corrisponda ai parametri durante la generazione delle descrizioni del servizio in WSDL.
Genere | Nome | Tipo | Descrizione |
---|---|---|---|
Proprietà | codifica | Stringa | Indica il meccanismo di codifica della piattaforma da utilizzare nella generazione dello schema per il messaggio; come negli esempi seguenti SOAP-RPC, Doc-Literal, ASN.1 e così via.
|
Proprietà
Questo stereotipo viene utilizzato per indicare che alcuni componenti di un messaggio sono allegati (come contrapposti ad una parte diretta dello stesso messaggio). In generale ciò non viene utilizzato molto nelle attività di progettazione di livello più elevato, ma per molti dati allegati dei processi è importante differenziarsi dai dati integrati del messaggio. Ad esempio, un servizio di catalogo potrebbe restituire i dettagli generali del prodotto come parte del messaggio strutturato ma le immagini come allegati al messaggio; ciò consente anche di indicare che la codifica delle immagini è binaria(contrapposta alla codifica testuale del messaggio principale).
Genere | Nome | Tipo | Descrizione |
---|---|---|---|
Proprietà | codifica | Stringa | Indica il meccanismo di codifica della piattaforma da utilizzare nella generazione dello schema per il messaggio; come negli esempi seguenti SOAP-RPC, Doc-Literal, ASN.1 e così via.
|
Porta
L'elemento del modello di servizio fornisce il punto terminale per l'interazione del servizio (nella terminologia dei servizi web) mentre le definizioni di queste interazioni sono parte della specifica del servizio. Nel modello, un servizio non solo identifica l'interfaccia fornita, ma identifica anche le interfacce richieste (come interfacce di callback). Un servizio dispone di una proprietà aggiuntiva che indica il binding da utilizzare, come SOAP-HTTP
, SOAP-JMS
e così via.
Nessuna.
Connettore
Un canale rappresenta il percorso di comunicazione tra due servizi. E' importante notare che potrebbe verificarsi un'interazione su un canale, ma il canale non rappresenta nessuna interazione particolare. Nel mondo dei servizi web, ogni servizio indica il binding ad esso associato(così che un client possa accedervi). In un profilo di modellazione, è possibile indicare il binding sulla comunicazione tra i servizi o tra un servizio e gli utenti. In questo modo, è possibile essere flessibili nel comprendere i requisiti del binding .
Genere | Nome | Tipo | Descrizione |
---|---|---|---|
Proprietà | binding | Stringa | Indica il meccanismo di binding della piattaforma da utilizzare nella generazione del binding del servizio in WSDL; come negli esempi seguenti SOAP-RPC , SOAP-Doc , HTTP-Get e così via. |
Collaborazione
Una collaborazione del servizio è un modo di specificare la realizzazione di un servizio come collaborazione di altri servizi. Dal punto di vista di un servizio web, ciò corrisponde all'utilizzo di BPEL4WS nella specifica dell'implementazione del servizio. Ciò significa che una collaborazione del servizio viene utilizzata come comportamento di un servizio e, se è previsto, per generare in un linguaggio come BPEL -- potrebbero esservi altri vincoli specifici della realizzazione.
Genere | Nome | Tipo | Descrizione |
---|---|---|---|
Proprietà | Binding | Stringa | Indica il meccanismo di binding della piattaforma da utilizzare nella generazione della collaborazione come coreografia del processo, come negli esempi seguenti "BPEL", "WSFL", ecc. |
Classificatore
Ogni classificatore (classe, componente, ...) può agire come utente di un servizio, che include un altro servizio. Questo stereotipo è sicuramente facoltativo ma potrebbe essere utile nella definizione degli elementi di un modello -- che non sono essi stessi servizi -- come i client dei servizi. D'altro canto potrebbe essere un sovraccarico e quindi non utilizzato.
Nessuna.
Nessuna.
Porta
Un gateway del servizio appare come un servizio ma è disponibile solo per essere utilizzato sulle partizioni e non sui provider del servizio. Un gateway agisce come un servizio proxy e può essere utilizzato per mediare i protocolli o per indicare l'interfaccia disponibile ad una partizione. Ad esempio, si potrebbe indicare che sebbene un determinato numero di servizi venga realizzato all'interno di una partizione -- solo alcuni di essi sono disponibili per essere utilizzati al di fuori della partizione e pertanto i gateway vengono forniti per tali servizi. Ciò impedisce ad altri servizi o partizioni di comunicare con i servizi che non sono esposti tramite gateway.
Nessuna.
Classe
Una partizione rappresenta alcuni limiti logici o fisici del sistema. Per modellare le partizioni è facoltativa ma utile. Ad esempio, è possibile utilizzare le partizioni per rappresentare i livelli di dati, business e web di un'applicazione di livello -n tradizionale. E' possibile utilizzare le partizioni per indicare più limiti fisici (come il centro dati principale, il sito secondario, il sito dell'utente, i partner e così via), nel qual caso l'incrociarsi delle partizioni potrebbe presentare vincoli particolari per la sicurezza, i protocolli consentiti, la larghezza di banda e così via.
E' possibile che una partizione abbia solo le proprietà che rappresentano le parti nidificate, siano i servizi o altre partizioni. E' bene notare che questo è un vincolo - non è possibile rappresentare correntemente altri elementi in una partizione.
Una partizione è inoltre qualificata come "stretta", se una partizione indica che è necessario che tutte le comunicazioni tra di essa e altre partizioni vengano dirette attraverso i gateway digitati, viene qualificata partizione stretta.
Genere | Nome | Tipo | Descrizione |
---|---|---|---|
Proprietà | Classificatore | Stringa | Un nome di classificazione, per indicare l'ambito spazio nome di questa partizione. |
Classe
Il Fornitore del servizio è unelemento software che fornisce uno o più servizi. Nella modellazione dei termini ci si aspetterebbe di visualizzare qui un componente UML, tuttavia una tale restrizione sembra arbitraria e così la meta classe viene indicata come Classe per maggiore flessibilità. Un fornitore del servizio presenta una proprietà che cattura le informazioni relative alla sua ubicazione sebbene il significato dipenda dalla realizzazione. La classe che agisce come fornitore del servizio potrebbe non esporre gli attributi o le direttamente, potrebbero essere fornite solo le porte pubbliche (stereotipate come servizi) digitate dalle specifiche del servizio.
La proprietà Location, mentre la specifica di implementazione/piattaforma è utile nella generazione dei nomi di endpoint del servizio. Ad esempio, con WSDL la posizione potrebbe essere http://svc.myco.com/
ed un servizio potrebbe essere denominato CustInfo
, nel qual caso il nome endpoint per il servizio potrebbe essere generato come http://svc.myco.com/CustInfo
.
Genere | Nome | Tipo | Descrizione |
---|---|---|---|
Proprietà | allowedBindings | Stringa | Indica il meccanismo di binding della piattaforma consentito che potrebbe essere utilizzato da un canale nella connessione al servizio, come negli esempi SOAP-RPC , SOAP-Doc , HTTP-Get e così via. |
Proprietà | ubicazione | Stringa | La posizione del provider, può essere utilizzata dai generatori per creare i nomi degli endpoint. |
Interfaccia
L'utilizzo di un'interfaccia indica un'insieme di operazioni fornite da un servizio. Si noti che un servizio potrebbe implementare più di un'interfaccia. Per convenzione, è possibile attribuire una tale specifica ad una macchina di stato del protocollo o ad una collaborazione UML 2.0 per indicare l'ordine di chiamata delle operazioni su una specifica del servizio. Con una tale specifica comportamentale è possibile convalidare ogni servizio di implementazione non solo per una specifica statica ma anche per una specifica dinamica della struttura e del comportamento relativi. Si noti che la specifica del servizio fornisce solo operazioni pubbliche.
Genere | Nome | Tipo | Descrizione |
---|---|---|---|
Proprietà | publicato | Booleano | Questa proprietà indica se si prevede di pubblicare il servizio in un repository del servizio; è una nozione diversa dalla proprietà publica/privata fornita da UML. |