Concetto: Portafoglio servizi
Questo concetto descrive i vantaggi dei servizi dell'abilitazione delle organizzazioni per promuovere il riutilizzo componendo le applicazioni da un portafoglio di servizi. Verrà discussa anche la divisione per categorie dei servizi per una valida memorizzazione, scoperta e recupero dei servizi dai repository.
Relazioni
Descrizione principale

Introduzione

Uno dei vantaggi espressi della SOA (Service-Oriented Architecture) è l'abilità di allontanarsi dal pensiero del "silos" all'interno di IT, lo sviluppo di applicazioni come isole di funzionalità. Oggi giorno si tende a pensare alle applicazioni come ad un'integrazione verticale di un insieme di componenti creati per questo unico scopo. E' spesso il caso che i progetti di sviluppo vengano impostati attorno allo sviluppo o alla manutenzione di un'applicazione ed in alcuni casi estremi i team di sviluppo sono responsabili solamente per una singola applicazione. La figura seguente rappresenta una struttura dell'applicazione del business comune, mostrando che realmente il solo riutilizzo tra le applicazioni è la condivisione di un database comune.

Il diagramma viene descritto nel contenuto testuale.

Mentre l'approccio orientato al servizio condurrebbe ad una vista più orizzontale delle applicazioni come integrazione dei servizi, così infatti tutti i servizi sono peer in un portafoglio di capacità da cui è possibile sviluppare le applicazioni, che è ora possibile pensare come a quelle parti delle soluzioni IT che interagiscono con gli utenti. Quanto segue mostra il modo in cui è possibile sviluppare un'applicazione di ordinamento come una serie di portlet rivolti all'utente per l'integrazione in un server portale e che la logica del business viene fornita da un insieme di servizi che a turno utilizzano un insieme di servizi dell'infrastruttura.

Il diagramma viene descritto nel contenuto testuale.

I servizi forniscono componenti sviluppati indipendentemente forniti ad una granularità che gli consente tipicamente di essere interamente autonomi, ciò conduce ai servizi che gestiscono e proteggono i propri archivi dei dati piuttosto che condividere la memoria del database. Ciò sembra essere in contrasto con quanto scelto da alcune imprese durante l'anno: di introdurre archivi di dati comuni o almeno modelli di dati comuni condivisibili da tutte le applicazioni. Al contrario una SOA (service-oriented architecture) tende a condurre i progettisti non allo sviluppo di modelli di memorizzazione dati comuni ma a modelli di messaggi comuni per facilitare l'integrazione dei servizi attraverso le tecnologie del middleware.

Vista Enterprise 

Come prima menzionato entrambi i team dei progetti e di sviluppo dispongono di un ambito limitato ed anche di una visibilità limitata per quello che riguarda le capacità, i requisiti e gli obiettivi più ampi dei servizi e ancora più importante, il business che i servizi supportano. E' perciò critico che durante  lo spostamento verso le soluzioni orientate al servizio e la vista orizzontale di soluzioni integrate, gli architetti da parte dell'IT siano in grado di visualizzare il portafoglio dei servizi che supportano le soluzioni del business richieste affinché il business stesso funzioni. Un vantaggio dei servizi di modellamento è che un modello astratto è in grado di elidere determinati dettagli e perciò presenti un'ampia vista del portafoglio servizi in una modalità scalare, ad es. in presenza di molti servizi il modello è in grado di presentare le viste del portafoglio che supportano le decisioni dell'Architetto del software e del Progettista.

Ovviamente la transizione delle organizzazioni alla SOA (Service-Oriented Architecture) comporterà una crescita nei servizi quindi il portafoglio non inizierà come un modello grande, ma sarà possibile riportare lo stato della transizione in termini di servizi disponibili oltre che pianificati. La Partizione del servizio è vitale anche nell'organizzazione del modello e nella divisione per categorie dei servizi come viene sviluppato il portafoglio.

Divisione per categorie dei servizi 

Durante le prime fasi dell'identificazione del servizio (consultare Attività: Analisi asset esistente) è comune che i servizi candidati vengano riportati semplicemente come un elenco di nomi, possibilmente strutturati come un elenco gerarchico o memorizzati in un foglio di lavoro. Tale elenco è utile quando si lavoro in un ambiente workshop e si elidono i servizi candidati dal materiale di origine. Quando il numero di servizi candidati aumenta, è possibile che un elenco non strutturato diventi non gestibile. Quindi, è necessario identificare una divisione per categorie del servizio il prima possibile in modo che i servizi candidati possano essere organizzati in gruppi nella gerarchia della categoria.

Mentre un semplice elenco di nomi del servizio può essere un veloce punto di inizio, sarà infine importante riportare ulteriori informazioni relative ad ogni servizio. Queste informazioni possono essere suddivise in due tipi: le informazioni che supportano l'identificazione del servizio e le informazioni che supportano la specifica del servizio. L'identificazione del servizio è incentrata sulla creazione di un portafoglio di servizi che può essere associato a funzioni di business, a obiettivi di business, ad asset come ad esempio i sistemi esistenti e ad un'indicazione se il servizio è considerato candidato o se è stato scelto per l'esposizione. Il modello del portafoglio del servizio può essere utilizzato per documentare i servizi al livello del dettaglio necessario nel portafoglio del servizio.

E' importante essere in grado di suddividere in categorie i servizi del portafoglio in alcuni modi, ma più comunemente si utilizza una terminologia che descrive lo scopo dei servizi, la proprietà o l'organizzazione. Per supportare questa divisione per categorie o classificazione, ogni partizione del servizio dispone di una proprietà Classification che è possibile utilizzare per indicare il tipo di classificazione, il nome della partizione diventa un valore nello schema di classificazione.

Ad esempio il diagramma seguente (o alcune varianti) è stato sviluppato da alcune imprese per aiutare la visualizzazione dei "tipi" di servizi nel portafoglio. Si noti che questa divisione per categorie, se comune, è semplicemente un modo possibile di segmentare il portafoglio servizi. In questo esempio ciascuna partizione è denominata con la proprietà di classificazione impostata su "zona".

Il diagramma viene descritto nel contenuto testuale.

  • I Servizi di interazione utente vengono utilizzati per descrivere il modo in cui l'utente interagisce con l'applicazione; per esempio per  un un servizio che ha bisogno di assegnare un lavoro ad un utente, è necessario che vi siano servizi che conoscano il modo di notificare all'utente questo lavoro e quindi di notificare al servizio di origine il completamento del lavoro.
  • I Servizi specifici dell'applicazione sono servizi che vengono sviluppati come parte di un'attività di sviluppo ritenuta non appropriata per il riutilizzo e quindi non sono considerati parte del portafoglio. E' inoltre possibile che, poiché i servizi sono entità componibili, un servizio sia parte del portafoglio anche se i servizi nidificati che utilizza non sono pubblicati.
  • I Servizi di integrazione del processo sono servizi, di solito forniti da middleware commerciale, che forniscono la coreografia dei servizi in modo che i processi possano essere emessi nel middleware ed utilizzino i servizi del portafoglio per implementare un processo.
  • I Servizi di integrazione delle informazioni sono di nuovo servizi commerciali del middleware che forniscono i servizi per la mediazione di formati di dati e il contenuto dei messaggi tra i servizi; ad esempio un messaggio utente può essere generato dal servizio che è un'aggregazione di dati richiamati da altri servizi nel portafoglio.
  • I Servizi del business sono servizi specifici del business, sviluppati per il business e che forniscono un supporto diretto alle applicazioni sviluppate per supportare il business. Esempi potrebbero essere CustomerMgmt, Inventory, HR, ecc.
  • I Servizi di infrastruttura sono servizi che forniscono le funzioni IT comuni richieste non solo dai Servizi del business ma anche dai Servizi di integrazione. Esempi potrebbero essere Messaging, Directory, Authentication, Legacy access, ecc.

Per ulteriori esempi di tipi di classificazione consultare il concetto Partizionamento del servizio.

Repository del servizio 

Oltre che da un modello del portafoglio servizi è importante che i progettisti e gli sviluppatori abbiano accesso alle specifiche di servizio in modo dettagliato alla progettazione ed all'implementazione. E' inoltre possibile per più servizi implementare la stessa specifica e così un registro che consenta query del tipo "tutti i servizi che implementano la specifica IOrdering" che permette agli sviluppatori di comporre soluzioni dai servizi esistenti ed agli sviluppatori di integrazione di identificare i servizi da utilizzare per soddisfare i requisiti del business e quelli tecnici.

I repository del servizio sono inoltre in grado di utilizzare i valori di classificazione introdotti utilizzando le partizioni del servizio precedentemente indicate per prepopolare i valori come metadati che descrivono i servizi contenuti dal repository.

Ad esempio, una soluzione potrebbe chiamare un servizio di spedizione, il registro potrebbe identificare 3 servizi che forniscono spedizioni, due forniscono uno scambio di messaggi sicuro ma solo uno utilizza JMS (Java Message Service) mentre l'altro utilizza SOAP su HTTP. I requisiti del business specificano solo che le informazioni dell'utente siano mantenute riservate e quindi è richiesto uno scambio di messaggi protetto, gli standard IAT raccomandano che JMS non venga utilizzato in un servizio remoto e di conseguenza la scelta si è ridotta.

Quanto segue presenta alcune delle tecniche di implementazione disponibili attualmente per i registri del servizio.

  • UDDI; Il registro standard dei servizi web, ha un'ampia adozione ed è previsto per supportare sia lo sviluppo che l'integrazione delle query di tempo. Tuttavia, il livello di personalizzazione richiesto per tenere traccia di tutti i dati associati ad una specifica di servizio ha certamente condotto a chiedersi se l'UDDI come è adesso, sia sufficiente per supportare il portafoglio servizi dell'azienda, qui discusso.
  • Repository RAS; La RAS (The Reusable Asset Specification) è prevista per supportare una descrizione di metadati personalizzabile per le risorse riutilizzabili e dispone di un profilo metadati per i servizi web. Se non c'era l'intento che RAS fornisca un portafoglio servizi, ciò sarebbe possibile per i metadati del tempo di sviluppo sebbene non sia attualmente appropriato per le query del tempo di integrazione.
  • Personalizzazione; Molte organizzazioni, di fronte a queste scelte, hanno scelto di implementare repository del servizio personalizzati, che gestiscono un insieme di metadati o di documenti di progettazione per i servizi al momento della progettazione e artefatti del servizio web associati per il momento dell'implementazione. Nella maggior parte dei casi viene utilizzato un repository UDDI separato durante la distribuzione dei servizi di produzione per le query del tempo di integrazione.