Concetto: architettura orientata ai servizi (Service-Oriented Architecture)
In questo concetto, la SOA (Service-Oriented Architecture) è caratterizzata in diverse dimensioni: come infrastruttura della tecnologia, come struttura concettuale per la progettazione, come ponte tra il business ed IT e come un'evoluzione di tecniche basate sul componente e 00.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

Le difficoltà nella creazione di soluzioni software di scala dell'impresa hanno origine da almeno quattro sfide principali:

  1. Conoscenza di domini del business assai complessi.
  2. Valutazione dell'utilizzo più efficiente delle risorse IT per incontrare le necessità del business.
  3. Gestione di uno sforzo nello sviluppo che coinvolga grandi team di ingegneri in più fasi di un progetto che dura molti mesi.
  4. La distribuzione delle soluzioni ad un assortimento complicato di tecnologie di infrastrutture evolute attraverso più anni, consiste in una varietà di software middleware acquisito da molti fornitori e assemblato attraverso sforzi di integrazione poveramente documentati di varia qualità.

Lo sviluppo delle soluzioni in questo contesto richiede un approccio all'architettura del software che aiuta gli architetti ad evolvere le proprie soluzioni in modi flessibili e a riutilizzare gli sforzi esistenti nel contesto di nuove capacità che implementano velocemente la funzionalità del business anche mentre è in evoluzione la stessa infrastruttura di destinazione. Per aiutare l'indirizzamento di queste necessità, molte organizzazioni cercano di riorganizzare le risorse delle informazioni come capacità sostanzialmente indipendenti, che creino un ambiente inerentemente adattabile. Descrivendo queste capacità riutilizzabili utilizzando protocolli aperti standard, è possibile che un'organizzazione crei servizi che si descrivono autonomamente che è possibile utilizzare indipendentemente dalla tecnologia descritta. L'indipendenza tecnica consente che i servizi vengano utilizzati in contesti diversi per realizzare una standardizzazione dei processi, delle regole e delle politiche del business. Questo approccio ai sistemi IT, a cui si fa riferimento come a SOA (Service-oriented Architecture), è adesso ampiamente riconosciuto come avente il potenziale per migliorare radicalmente la risposta delle organizzazioni business ed IT.

Andando avanti la SOA fornisce molte sfide ad una organizzazione. I concetti orientati al servizio, ad esempio, introducono nuovi termini e nuovi modelli e promuovono l'interoperabilità e l'integrazione del processo. Integrare, inoltre i molti livelli di tecnologia sottostanti che costituiscono una SOA può essere un'attività molto complessa. Le organizzazioni IT spesso richiedono modifiche nell'approccio, aggiornamenti dell'insieme di abilità, nuove capacità negli ambienti di sviluppo e modifiche ai processi di progettazione delle soluzioni. Il concetto di SOA, comunque, è un fenomeno recente e le relative caratteristiche sono in continua evoluzione. Tuttavia, esistono diverse chiare prospettive su cosa sia una SOA e sul ruolo di una SOA nell'indirizzare obiettivi chiave alla creazione di soluzioni software d'impresa.

SOA come un'infrastruttura di tecnologie

I sistemi sono composti da raccolte di servizi che effettuano chiamate su operazioni definite attraverso le relative interfacce del servizio. Molte organizzazioni esprimono adesso le proprie soluzioni in termini di servizi e delle relative interconnessioni. L'obiettivo ultimo dell'adattare una SOA è di realizzare flessibilità per il business ed all'interno di IT. Sono state definite alcune tecnologie importanti per supportare un approccio SOA, specialmente quando i servizi vengono distribuiti attraverso più macchine e connessi su Internet o su un Intranet. Questi approcci dei servizi web dipendono dai protocolli di comunicazione tra servizi come SOAP; consentono di registrare le interfacce del servizio web (espresse in WDSL (Web Services Definition Language)) in directory pubbliche e di ricercare nei repository UDDI (Universal Description, Discovery and Integration) e di condividere le informazioni in documenti definiti in XML e descritti in schemi standard. Inoltre, gli standard sono in fase di evoluzione per indirizzare aree aggiuntive di politica, sicurezza, affidabillità, scoperta e più; questa famiglia di standard è comunemente nota come "WS-* family".

Ma SOA non è più semplicemente un insieme di descrizioni di standard e di servizi di quanto l'orientamento all'oggetto è semplicemente un insieme di gerarchie di classi. Invero, è possibile creare una SOA che non utilizzi la tecnologia dei servizi web ed è possibile utilizzare la tecnologia dei servizi web in un modo che non sia considerato orientato al servizio. Esiste un grande accordo più che una necessità nel comprendere perché un punto di vista orientato al servizio aggiunga valore al business e come sono progettate le soluzioni orientate al servizio, implementate, distribuite e gestite. [di più, la SOA non è uguale a WS]

SOA come una struttura concettuale per la progettazione

Creare soluzioni per SOA significa ripensare ai tipi di sistemi creati oggigiorno, riconsiderando le abilità nelle organizzazioni e ridefinendo le modalità in cui i membri dei team collaborano. Ciò che è molto importante, è che l'adottare l'orientamento ai servizi per sviluppare le soluzioni richiede un ampio riesame dell'impatto sul modo in cui vengono progettate le soluzioni, su ciò che significa assemblarle da servizi diversi e di come le soluzioni orientate al servizio distribuite vengono gestite ed evolute.

Una modifica chiave in questo spostamento è che il termine "applicazione" come è noto, sta diventando problematico poiché ci si sposta dall'applicazione come centro di tutti i progetti al portafoglio servizi come punto focale, da cui dipende il business. A questo riguardo, è possibile pensare a questo spostamento dai progetti orientati all'applicazione ai progetti orientati al servizio come ad uno spostamento dalla progettazione di un insieme verticalmente integrato di componenti che formano un'applicazione verso la progettazione di un insieme orizzontale di servizi. In futuro, il termine applicazione verrà relegato alla descrizione di un piccolo livello di logica specifica del business accanto ai servizi di interazione dell'utente che crea la coreografia di un insieme di servizi business e d'infrastruttura che forniscono la maggior parte del valore.

Gartner fa riferimento a ciò in un contesto più ampio di orientamento al servizio come SODA (Service-Oriented Development of Applications). Gartner considera che i cinque principi chiave di SODA sono composizione, gestione adattabile del processo, interoperabilità basata sui servizi ed integrazione, scoperta e descrizione e manutenzione rapida dell'applicazione. Da una prospettiva di un fornitore di tool, queste aree relative al supporto alla tecnologia sono offerte in tre aree:

Ciclo di vita di SOA. I principi "Scoperta e descrizione" e "Manutenzione rapida dell'applicazione" fanno riferimento al ciclo di vita dei servizi ed al modo in cui vengono trovati, applicati, evoluti e mantenuti. I fornitori del tool stanno aumentando le offerte dei modi in cui memorizzare, catalogare, ricercare e recuperare i servizi. Il supporto per l'evoluzione dei servizi è un aspetto critico di ciò, in quanto conduce a più versioni dei servizi.

Piattaforma SOA e modello di programmazione. Il principio di interoperabilità ed integrazione basate sul servizio fa riferimento al modo in cui è possibile collegare, distribuire e gestire i servizi all'interno di una piattaforma di runtime specifica. I maggiori fornitori di piattaforme supportano le capacità orientate ai servizi direttamente come parte dei runtime del middleware ed evolvono i modelli di programmazione del proprio runtime per far emergere i concetti relativi al servizio come elementi di prima classe. Come risultato, è possibile concepire, progettare, implementare e gestire le soluzioni da una prospettiva singola basata sul servizio.

Prassi SOA e tool. Il principi di gestione di composizione e adattabile al processo fanno riferimento al modo in cui i servizi vengono creati e assemblati nel contesto di risoluzione di necessità del business che si modificano. I fornitori del tool supportano l'estrazione delle applicazioni per scoprire servizi potenziali, disponendo la funzionalità esistente in modo da rendere quelle capacità accessibili come servizi, per la creazione di servizi nuovi e collegando i servizi connettendo il comportamento esposto tramite le relative interfacce. E' fondamentale perciò la disponibilità di una guida chiara e delle prassi migliori per strutturare le soluzioni orientate al servizio in modi ripetibili e prevedibili.

Tutte e tre queste aree sono importanti per il successo nello sviluppo di soluzioni orientate al servizio. E' necessario che vengano indirizzate in modo da incontrare le necessità dell'organizzazione per creare in modo efficiente soluzioni flessibili che meglio si allineino con gli obiettivi del business.

SOA come approccio olistico alle soluzioni come ponte tra il business e IT

Una delle sfide principali da indirizzare allo sviluppo di soluzioni di scala dell'impresa è il collegare i requisiti specifici del dominio espressi dagli analisti del business alle soluzioni specifiche della tecnologia progettate dall'organizzazione IT. Tipicamente, il collegamento tra questi due mondi diversi non è buono. Le due comunità dispongono di abilità molto diverse, utilizzano concetti di modellazione e notazioni diversi (se li utilizzano) e raramente comprendono l'associazione tra questi concetti. L'utilizzo dell'approccio orientato al servizio è previsto per aiutare a colmare questo divario tra gli analisti del business e gli specialisti della linea del business e gli specialisti IT come gli architetti, gli analisti del sistema, gli integratori, i progettisti e gli sviluppatori. In particolare, è prevista l'integrazione di processo, risorse e consegnabili attorno ad un insieme principale di servizi per collegare questi due aspetti diversi del sistema in un modo chiaro e preciso.

SOA offre una vista focalizzata sul servizio come aiuto per superare queste sfide:

Compensazione del divario tra business e IT. E' essenziale allineare la vista del business di attività e processi alla tecnologia utilizzata per realizzare parti di tali attività. Questo allineamento include l'abilità dei modelli del business di condurre uno sviluppo discendente e di evolvere i modelli del business e le soluzioni IT in combinazione. Il concetto di servizio è critico per questo allineamento. I servizi ed il pensiero basato sul servizio formano il terreno comune che lega insieme gli analisti del business, gli architetti IT, gli integratori e gli sviluppatori. La vera natura dei servizi, il livello di granularità ed il livello di incapsulamento che promuovono, gli consente un allineamento molto stretto ai modelli del processo business che guidano il business. Le pratiche comuni di progettazione sono essenziali per assicurare che i concetti, i prodotti di lavoro e le attività siano sincronizzate attraverso queste prospettive differenti. Infine, disporre di tool che possono trasformare in modo efficiente i modelli che rappresentano l'intento del business in implementazioni efficienti di base è molto importante per compensare il divario tra il business ed IT.

Supporto dei ruoli mutevoli nell'organizzazione IT. Lo spostamento verso i servizi modifica le abilità e la composizione dei team in un'organizzazione. Il punto focale dello sviluppo è di trovare, definire, gestire e assemblare i servizi, con descrizioni strutturali che evidenzino gli SLA (service level agreements) ed i protocolli interni ai servizi. L'insuccesso tradizionale delle funzioni del tool nell'allineamento dei prodotti odierno non è appropriato per questo approccio. Vi sarà una diversa miscela di capacità richieste dai diversi membri nelle organizzazioni IT. Ad esempio, le abilità richieste dai ruoli esistenti come l'architetto del software stanno cambiando per includere un'enfasi maggiore sull'assemblaggio e la gestione dei servizi attraverso un insieme diverso di provider del servizio. In modo simile, stanno emergendo nuovi ruoli come gli specialisti dell'integrazione, focalizzando l'attenzione sull'assemblaggio di una catena di valori basati sui servizi in supporto agli obiettivi chiave del business chiave delle organizzazioni.

Focalizzazione sulle risorse ed il riutilizzo. Il considerare i servizi come risorse chiave nella progettazione dei sistemi modifica una vista dell'organizzazione del valore del riutilizzo di tali servizi. In precedenza, è stato discusso lo spostamento dallo sviluppo verticale di un insieme di componenti dell'applicazione all'integrazione orizzontale dei componenti. Un aspetto da valutare è che gli stessi servizi diventano molto più disponibili al riutilizzo. Infatti, la combinazione in nuove capacità, la composizione in servizi nuovi è un motore fondamentale per le modifiche. In molti business, questa promessa di un maggiore riutilizzo di una SOA giustifica il costo associato alla progettazione ed allo sviluppo di un portafoglio di servizi. Come risultato, le tecnologie e le tecniche per la gestione e la direzione delle risorse e delle modalità ripetibili per catturare i pattern per unire le risorse, diventa molto più importante. In un approccio dello sviluppo basato sulle risorse, queste risorse mantengono un valore critico nell'organizzazione e devono essere gestite ed amministrate con attenzione. L'infrastruttura del team per la gestione delle risorse acquista un ruolo chiave in questo approccio.

Aumento dei livelli di collaborazione all'interno ed attraverso ruoli praticanti. Lo sviluppo di applicazioni dell'impresa ha sempre riconosciuto che lo sviluppo del software richiede persone che lavorino assieme e un'attenzione focalizzata attraverso il ciclo di vita sulla gestione di risorse condivise, la tracciabilità del prodotto di lavoro e pratiche e processi condivisi. La natura collaborativa dello sviluppo del software sta aumentando con una maggiore distribuzione geografica delle organizzazioni, con una migliorata comunicazione tra individui nei team e con il software integrato come parte dell'iniziativa di uno sviluppo di sistemi più ampi. Sempre più, il ruolo delle infrastruttura di sviluppo del software verrà visto come un ambiente di sviluppo collaborativo per i partecipanti al software che incoraggi la condivisione ed il riutilizzo dei servizi attraverso i team.

SOA come un evoluzione delle tecniche basate sul componente e orientate all'oggetto

In ogni nuovo sviluppo nell'ingegneria del software, è molto facile prevedere l'applicazione delle stesse tecniche e degli stessi tool utilizzati nei progetti precedenti. Questa tendenza a risolvere i nuovi problemi con vecchie soluzioni non è nuova. In un modo simile, poiché gli sviluppatori hanno iniziato a creare le applicazioni basate sul componente, hanno tentato di indirizzare i problemi utilizzando la propria esperienza con lo sviluppo orientato all'oggetto. Con più esperienza, è stato poi capito che la tecnologia ed i linguaggi orientati all'oggetto sono delle modalità molto efficaci per implementare i componenti, benché sia necessario comprendere i compromessi fatti tra le decisioni e l'implementazione. I compromessi riguardano l'ereditarietà in confronto all'aggregazione per implementare il comportamento polimorfico o riprogettare librerie delle classi in modo da essere in grado di utilizzare insiemi di componenti piuttosto che la base di un'applicazione monolitica C++.

In un modo simile, i componenti vengono visti come il modo migliore per implementare i servizi, sebbene sia necessario comprendere che un'applicazione esemplare basata sul componente non rende necessariamente una SOA esemplare. Esiste una grande opportunità nel bilanciare gli sviluppatori dei componenti dell'impresa ed i componenti esistenti una volta compreso il ruolo giocato dai servizi nell'architettura dell'applicazione. La chiave per effettuare questa transizione è di realizzare che l'approccio orientato al servizio implica un livello di architettura dell'applicazione ulteriore. L'immagine sottostante mostra il modo in cui è possibile applicare i livelli di tecnologia per fornire implementazioni più a granularità complessa per essere più vicini all'utente della soluzione. Il termine coniato per fare riferimento a questa parte del sistema è "margine dell'applicazione", che riflette il fatto che un servizio è un modo migliore di esporre una vista esterna di un sistema, con riutilizzo interno e composizione utilizzando la progettazione del componente tradizionale. Un modo di guardare alle differenze tra oggetti, componenti e servizi è il modo in cui sono uniti alla propria implementazione; un oggetto è unito strettamente al linguaggio di programmazione, i componenti sono uniti ad alcuni runtime o al alcune piattaforme (COM, CORBA, J2E e simili) mentre i servizi sono realmente uniti solo all'insieme degli standard utilizzati per descrivere la relativa specifica.

Il diagramma viene descritto nel contenuto testuale.

In generale, lo spostamento dal pensiero orientato all'oggetto al pensiero basato sul componente è avvenuto in 6-18 mesi, poiché gli sviluppatori hanno appreso questa nuova tecnologia ed i relativi requisiti. Auspicabilmente, lo spostamento alle soluzioni orientate al servizio può accadere molto rapidamente. Per ottenere ciò, gli sviluppatori dovranno comprendere le sfide, i compromessi e le decisioni di progettazione che consentono lo sviluppo ed il riutilizzo dei componenti in supporto alle soluzioni orientate al servizio.