Le difficoltà nella creazione di soluzioni software di scala dell'impresa hanno origine da almeno quattro sfide
principali:
-
Conoscenza di domini del business assai complessi.
-
Valutazione dell'utilizzo più efficiente delle risorse IT per incontrare le necessità del business.
-
Gestione di uno sforzo nello sviluppo che coinvolga grandi team di ingegneri in più fasi di un progetto che dura
molti mesi.
-
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.
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]
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.
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.
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.
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.
|