Service oriented architecture: di che cosa parliamo?

Speciale SOA
Service oriented architecture:
di che cosa parliamo?
Anticipazioni dal Libro Bianco sulla SOA curato
dal Gruppo di Lavoro del ClubTI di Milano.
La prima edizione entro la fine del 2009
Il presente articolo raccoglie alcune considerazioni dell’autore sulla SOA derivate
principalmente dalla sua attività professionale e dal coordinamento del Gruppo
di Lavoro sulla SOA (si veda Box 1) del
ClubTI di Milano e di FidaInform (Box
2), che ha portato alla stesura della prima versione del Libro Bianco sulla SOA
(Box 3) che l’autore, assieme al Gruppo
di Lavoro sta aggiornando e completando nella prossima versione definitiva, che
sarà disponibile entro la fine del 2009.
Che cosa è la SOA:
una breve sintesi
La SOA, Service Oriented Architecture,
può essere definita come uno stile architetturale informatico - ICT, Information
and Communication Technology, che
supporta, integrandoli, i processi di business come un insieme di servizi tra loro
interoperanti. Essa rappresenta da un lato
una importante soluzione basata su standard per garantire l’interoperabilità tra
programmi software indipendentemente dai linguaggi e dai sistemi operativi, dall’altro tende a colmare il gap tra i processi
e le attività svolte dall‘Azienda/Ente e gli
strumenti ICT che le supportano.
La SOA consente di pianificare, progettare, sviluppare e fornire soluzioni ICT
come “servizi modulari di business” per
costruire un’organizzazione, impresa o
ente come una Pubblica Amministrazione (PA) che sia, agile, flessibile ed allineata
62
al business o alle attività, in modo da essere più competitiva, profittevole, efficace
ed efficiente. La fig. 1 sintetizza tale
doppia valenza della SOA, sia lato tecnico
che lato business.
L’approccio logico alla base della SOA per
consentire uno stretto allineamento tra
processi aziendali e moduli software che
li supportino si basa su:
1) individuazione dei processi e loro scomposizione in “business processes”;
2) realizzazione di moduli software interoperanti basati su oggetti e su standard
internazionali;
3) associazione tra processi ed applicativi software realizzate assemblando e coordinando i componenti software di cui
sopra.
I “Business Services” possono essere visti come l’immagine “elettronica” e concettuale di un processo reale o di una sua
parte (si veda Figura 2). La definizione dei
business services costituisce un vero e proprio progetto, che parte dalla fotografia
dei processi in essere nell’organizzazione
(o di un loro sotto insieme) e che arriva alla
loro analisi per individuare componenti
(ad esempio singole attività o gruppi di attività) che sono espletate in diversi processi o che sono specifici ed unici di uno
stesso processo. L’analisi deve tener conto che la “modularizzazione” dei processi servirà per associare poi ad essi gli idonei componenti software. Importante
quindi individuare la più conveniente
“granularità”, ossia l’insieme di funzioni
(e quindi la complessità) che ogni singolo servizio espleta: il singolo servizio può
essere elementare, ad esempio la registrazione di una informazione, o con
molteplici funzionalità, ad esempio espletare l’intero ciclo passivo o attivo (o entrambi!!) della contabilità.
In una Soa i “componenti software” sono
di norma i “web services”: per realizzare
una SOA possono essere usate anche altre tecnologie, ma sono questi ultimi i più
usati e diffusi.
Un Web Service è quindi un componente software disegnato per incapsulare una
funzione o un processo di business, che
supporta una interazione macchina-mac-
Fig. 1 - Le due facce della Soa: tecnica e di business
• più facile allineamento e più stretta
correlazione
tra processi di business e applicativi software
che li supportano
• migliore e maggiore governo ICT
• migliore e maggiore governo dei processi
tramite l’ICT
• più facile automazione dei processi e quindi
migliore BPM e BAM
• più facile ripensamento-reingegnerizzazione dei
processi
Consente
una corrispondenza tra un
‘modulo’
di
un
processo
di business (business service) e un oggetto
software che risponda agli standard SOA
BUSINESS
TECNICO
BPM, BUSINESS PROCESS MANAGEMENT
BAM, BUSINESS ACTIVITY MONITORING
• più facile e più efficiente interoperabilità tra applicativi
software
• riusabilità dei moduli (economia)
• più facile e più efficiente evoluzione delle architetture dei sistemi informativi
• migliore governance ICT sia a livello strategico che
operativo
più efficace valorizzazione del contributo dell’ICT al
business
Tramite standard internazionali e consolidati,
permette l’interoperabilità tra e la riusabilità dei moduli
software indipendentemente dal tipo di linguaggio
usato e dal tipo di sistema operativo
ICT Professional n.66
Speciale SOA
ICT Professional n.66
Fig. 2 - Correlazione tra processi , Business Services e Web Services
High Level Business Process
Business
Service
Processi
Business
Service
Business
Service
Business
Level
Electronic Image
KPI,
Real time
Alerting
Business
Services
Electronic Image of the High Level Business Proc.
Web
Services
Web
Services
Fig. 3 - Il modello “elementare” dei Web Services
UDDI repository
SO
AP
Me
ssa
ge
s
Un protocollo standardizzato
che definisce il formato
di un messaggio
fra le applicazioni
<publish>
A
Una directory (pubblica o privata)
BROKER
che serve per trovare e identificare
Registra il servizio
e aiuta a cercarlo
i Web Services di interesse
WSDL
Un linguaggio
XML based
utilizzato per scrivere
come utilizzare
il Web Service
C
I.T.
Levels
Registrare e rendere disponibile
un Web Service
A) Il producer registra
il suo Web Service con un broker
B) Il consumer chiede il servizio
attraverso il broker
C) Il broker identifica il producer
per il consumer
s
ge
sa
es
M
AP
SO
china e che è descritto mediante:
• Interfaccia: descrive i messaggi di input/output utilizztati/generati dal servizio;
• Implementazione: descrive il “comportamento” del servizio.
I Web Services vengono descritti e richiamati utilizzando tre standard universalmente consolidati ed accettati:
• WSDL, Web Services Description Language: è un dialetto del linguaggio
XML che fornisce la grammatica, la semantica e il formato di specificazione
delle interfacce esposte dai Web Service. È gestito da W3C, si veda:
http://www.w3.org/TR/wsdl20/
• SOAP, Simple Object Access Protocol: è
il protocollo per chiamare un servizio e
ricevere risposta. L’utilizzo di SOAP su
HTPP (ma si potrebbe usare SMTP,
FTP...) è la base dei Web Services, secondo quanto la maggior parte dell’industria del software ha ormai stabilito
come standard di fatto.
• UDDI,Universal Description Discovery
Integration: è lo standard per registrare e ricercare i Web Services all’interno
di directory, come delle pagine gialle.
Base comune a questi tre standard è l’
XML, Extensible Markup Language:
esso è un metalinguaggio creato e gestito dal World Wide Web Consortium
(W3C), utilizzato per creare nuovi linguaggi atti a descrivere documenti strutturati. Rispetto ad HTML, che descrive
con opportuni tag come l’informazione
deve essere presentata sul browser all’utente (posizionamento testo e fotografie, colore e caratteristiche caratteri,
ecc.), l’XML fornisce tag che indicano la
semantica delle informazioni, quindi il
tipo di informazione: ad esempio un indirizzo, una qualifica, la retribuzione
mensile, ecc.
L’XML è oggi la semantica di riferimento per i contenuti di protocolli, informazioni delle applicazioni, ecc. È
utilizzato anche come mezzo per l’esportazione di dati tra diverse banche dati.
Essendo un metalinguaggio, con XML
è possibile creare dei Dizionari specifici per specifici ambiti, quali ad esempio
<find>
Utilizzare un Web Service
B
1) Il consumer manda una richiesta al producer
<bind>
PRODUCER
Fornisce il servizio
1
2
CONSUMER
Utilizza il servizio
2) Il producer risponde alla richiesta
del consumer
SOAP Messages
matematica, chimica, medicina, architettura, commercio internazionale, e
così via. La fig. 3 mostra il modello di
base di un funzionamento dei web services, basato sull’interazione tra l’agente utente, nella figura indicato con “consumer” e l’agente “producer” che fornisce il web service richiesto. Sia “consumer” che “producer” hanno la stessa
“descrizione” tramite WSDL e comunicano tramite il protocollo SOAP (si vedano in figura i punti 1 e 2).
Il “Producer”, chiamato anche “provider”
realizza e mette a disposizione in rete uno
o più web services: li pubblica attraverso
un “broker” che costituisce una directory, ossia un elenco dei servizi “pubblicati”
con una descrizione standardizzata delle loro caratteristiche e funzionalità. La
pubblicazione avviene tramite l’operazione di <publish> (si veda fig. 4) . Il
“Producer” agisce come un service provider che rimane in attesa di richieste (da
parte di consumer) dei servizi offerti.
Il “Brooker”, chiamato anche “Service
Directory”, gestisce il registro (Regi-
stry) dei servizi pubblicati: svolge il
ruolo di “pagine gialle” per chi ricerca un
servizio sulla base delle caratteristiche e
funzionalità con le quali è stato registrato.
Il “Brooker” può seguire politiche di controllo e filtraggio delle richieste, limitando
la visibilità dei servizi registrati a seconda
del profilo del richiedente.
Il “Consumer”, chiamato anche “requestor”, è l’utente dei servizi forniti dai provider. Per conoscere se e dove è erogato
il servizio richiesto, interroga con l’operazione <find> il Brooker. Individuato
il producer, si collego ad esso con <bind>
ed utilizza il servizio richiesto con <use>.
In SOA il mezzo trasmissivo è la rete Internet ed il protocollo è SOAP. Questo
protocollo usa una sintassi ed una semantica dei messaggi XML ed utilizza
per trasporto dei suoi messaggi il sottostante protocollo HTTP tipico del mondo web e di Internet. L’uso di http ha favorito la diffusione di SOAP, dato che altri protocolli, tipici di ambienti preSOA ma con le stesse finalità, quali
CORBA-IIOP, RMI e COM+ usano
63
Speciale SOA
Fig. 4 - Le tipiche operazioni elementari tra web services
Broker
<publish>
<find>
<bind>
Producer
Consumer
<use>
Fig. 5 - BPEL nello Stack dei Servizi SOA
BPEL4WS
WS- Reliable
Messaging
Process
WSCoordination
WS- Security
WS- BA
Quality
of Service
UDDI
Discovery
XSD, WSDL, WS-Policy
Description
SOAP
Messaging
XML
HTTP, MQ, SMTP
porte in Internet spesso bloccate dai firewall.
Un elemento chiave dei web services è la
loro interfaccia “standard” realizzata tramite WSDL, anch’esso basato su XML.
Tale interfaccia descrive ciò che il web service effettua e con quali primitive e comandi si interagisce con esso. Praticamente tale interfaccia assomiglia alle ti-
Transport
piche e ben note interfacce di programmazione API, Application Program Interface.
Per la realizzazione di un applicativo i
Web services da soli non bastano: occorre il loro coordinamento. Dati i diversi livelli di granularità con i quali può esser
costruito un web service, un programma
normalmente è costituito da più web ser-
vices. Occorre quindi descrivere come
comporre questi web services, descrivere il loro flusso di esecuzione , in una parola coordinarli per ottenere l’applicativo voluto.
In ambito SOA esistono due differenti scenari per il coordinamento, che stabiliscono
i relativi modelli di regole:
•l’orchestrazione dei servizi;
•La coreografia dei servizi.
Definire standard per le politiche di coordinamento dei servizi non è un problema semplice e solo tecnologico. Nel
tempo sono emersi e si sono consolidati
due standard, il BPEL per l’orchestrazione ed il WS-CD per la coreografia.
Tutti gli scenari di coordinamento, indipendentemente dalla loro complessità, devono essere costruiti esclusivamente a partire dalla composizione di interazioni
elementari di tipo messaggio senza replica,
messaggio/replica sincroni, messaggio/replica asincroni.
Il termine orchestrazione fa chiaro riferimento ad un’orchestra nella quale i singoli musicisti hanno uno spartito, sanno
suonare il loro strumento ma devono essere coordinati dal direttore di orchestra
(orchestrator). La metafora dell’orchestra
evidenzia che questo modello richiede la
centralizzazione del controllo. Il modello dell’orchestrazione si basa comunque
sulla centralizzazione del controllo, e
consente una reale autonomia dei singoli servizi, che svolgono le loro funzioni,
quando attivati, sempre allo stesso modo
indipendentemente da chi e come svolge
l’orchestrazione. L’orchestrazione di fat-
1 The OpenGroup è molto attivo anche in ambito SOA, ed ha prodotto delle specifiche per approcciare soluzioni SOA nell’ambito del
proprio modello architetturale TOGAF, si veda http://www.opengroup.org/projects/soa-book/
2 Il termine incapsulamento è qui usato con un significato generico e diverso da quello della programmazione ad oggetti, per la quale
significa che un oggetto contiene (“incapsula”) al suo interno gli attributi (dati) e i metodi (procedure) che accedono ai dati stessi.
3 JCP, Java Community Process. è un processo formalizzato per le specifiche e le caratteristiche future delle piattaforme Java, ed emana i documenti, le Java Specification Request, univocamente identificati dalla sigla JSR xxx.
4 Con il termine di BPM, Business Process Management, si intende un insieme di attività per la gestione dei processi in un’ottica di integrazione e di supervisione complessiva dell’intera filiera, con l’obiettivo di migliorarli e renderli in maniera progressiva più efficaci ed efficienti per il business (azienda) e/o per i fini istituzionali.
5 Con il termine di BAM, Business Activity Monitoring, si intende un insieme di attività per la misurazione delle prestazioni dei processi
per il business. Spesso viene usato per indicare queste attività il termine BPM, Business Performance Management, ma l’acronimo si
confonde con il Business Process Management: per questo motivo si preferisce usare l’acronimo BAM.
64
ICT Professional n.66
Speciale SOA
ICT Professional n.66
Fig. 6 - Esempio di funzionamento dell’orchestrazione dei web services via BPEL
ed il relativo motore
Software
di sviluppo
Processo
BPEL
.NET
<process>
<sequence>
<receive>
<.../>
</sequence>
</process>
Java
Il Web
Service
viene
pubblicato
ERP
Web Services
Progettista
di processo
Motore di
Orchestrazione
Fig. 7 - La visione d’insieme dell’associazione processi-ICT in SOA con web services
High Level Business Process
BAM
Business
Service
Business
Service
Business
Service
Explicit Processes
Electronic Image
∝
to è un servizio logicamente di livello superiore rispetto ai web services che concorrono all’attuazione dell’applicativo:
essa non eroga uno specifico servizio, ma
attua il coordinamento tra i web services
per realizzare la loro cooperazione ed ottenere l’applicativo desiderato.
BPEL è un linguaggio basato su XML,
standardizzato da W3C e OASIS come
BPEL4WS o WS-BPEL per il coordinamento dei web services: si posiziona al
di sopra della pila (stack) dei web services, schematizzata in fig. 5.
L’applicazione SOA voluta viene assemblata con gli opportuni web services
che si attivano secondo le regole descritte tramite BPEL, che specifica l’esatto ordine secondo il quale i web services devono essere invocati. Tale ordine può essere sequenziale o parallelo, e con BPEL
si possono esprimere scelte condizionali:
un web service, ad esempio, può essere invocato in funzione del valore di un precedente web service o di un predefinito
parametro. Con BPEL, come un normale
linguaggio di programmazione, si possono costruire loop, dichiarare variabili, copie ed assegnare valori, ecc. Combinando tutti questi costrutti, è possibile definire praticamente qualsiasi processo di business complesso.
La fig. 6 mostra l’esempio di funzionamento dell’orchestrazione dei web services via BPEL ed il relativo motore. Il
progettista “monta” tra di loro i vari webservices, che possono anche essere remoti
e sviluppati in ambiente diversi: nella figura in Java, dotnet ed un’applicazione
ERP. Il montaggio avviene creando un
unico <processo> (si veda il tag <process>
di apertura e chiusura dell’intero programma BPEL in figura) al cui interno
si trovano tipicamente comandi quali <receive> per gestire richieste da parte del
client , <reply>per rispondere alle richieste
di <receive>, <invoke> per invocare
web services remoti, e così via.
BPEL è anche usato come “descrittore”
formale di processi, ed in questo ruolo si
affianca ad altri strumenti quali il BPMN,
Business Process Modeling Notation,
dell’OMG: è la notazione grafica standard
KPI, Real
time
Alerting
Electronic Image of the High Level Business Proc.
BSM
Business
Level
Business
Process
Mgmt
I.T.
Levels
Web
Services
WSM
.......
System
Mgmt
.......
Applications
↓ ↓↓ ↓ ↓ ↓↓
Vendite
↓
Vendite
Vendite
Vendite
Server
Vendite
↓ ↓↓ ↓ ↓ ↓ ↓ Storage
per disegnare processi di business in un
workflow (http://www.bpmn.org/).
Lo standard più consolidato per la descrizione di coreografie è WS-CDL, Web
Service Choreography Description Language. Questo linguaggio, basato su
XML, permette di specificare in una logica di contratto tra le parti, ossia tra i
web services componenti, come questi
devono interoperare ed a quali vincoli
devono sottostare perché ciascuno garantisca il corretto espletamento delle
proprie attività.
WS-CDL descrive la collaborazione interoperabile e “peer-to-peer” tra le parte
coinvolte: il corretto comportamento tra
le parti è raggiunto stabilendo mutue responsabilità tramite opportune “relazioni” (Relationships). La collaborazione
Application
layer
avviene tramite un insieme di regole e di
vincoli congiuntamente concordati, attraverso le quali avviene lo scambio di
messaggi.
La Figura 7 mostra una visione d’insieme di una architettura SOA basata su web
services, ed evidenzia sia le logiche tecniche che quelle di “governante”, più
avanti discusse.
Osservando la figura dall’alto verso il basso si evidenziano:
•sul lato “execution” che riguarda l’implementazione:
- la ristrutturazione dei processi di Business ad alto livello con la loro “decomposizione” in Business Services;
- la loro corrispondenza con uno o più
Web Services;
- l’uso di web service consente di mi-
65
Speciale SOA
surazione delle loro prestazioni
- a livello di sistemi ICT viene effettuato
il “tradizionale” monitoraggio e controllo
del funzionamento e delle prestazioni dei
sistemi ICT, in termini di applicazioni,
software di base (middleware), reti ed
hardware
Fig. 8 - Tipico schema funzionale di ESB
Ma dove e come
può operare una SOA?
(Fonte: Mule)
Figura 9 - Le principali tecniche di sicurezza per una SOA e web services
(Fonte: IBM)
gliorare la flessibilità, il time-to market,
l’efficienza nel supportare i servizi di business, oltre che nella creazione di nuovi web services, riutilizzando, modificando e componendo quelli esistenti. È
importante evidenziare che SOA non definisce modalità di sviluppo software per
i web service.
•sul lato monitoraggio e controllo:
- a livello processi di business tali funzioni sono attuate, in logica top-down,
dal BAM, Business Activity Monitoring
(concetto ripreso e approfondito più
avanti) e dal BSM, Business Service Management. Il primo fornisce informazioni
di sintesi e dettaglio per i decisori sul business, il secondo misura i livelli di servizio (SLA) e verifica gli impatti sui Business Services;
- a livello web services, il monitoraggio
di questi servizi viene attuato dal WSM,
Web Service Management, che si occupa
del monitoraggio dell’execution dei
web services e del controllo e della mi-
I web services operano prevalentemente
lato server, ma in taluni casi possono anche operare sui sistemi d’utente: condizione “sine qua non” è che siano fra loro
interconnessi con la tipica pila di protocolli di Internet, al cui top si trovi SOAP.
Il mondo dei server, analogamente a
quello per lo sviluppo software, si suddivide attualmente in due principali ambiti, che fanno riferimento ai sistemi
operativi prevalentemente utilizzati:
•Il mondo Linux e Unix, il primo opensource il secondo proprietario e con alcuni attori di riferimento, quali Sun, HP
ed IBM che hanno dato vita insieme ad
altre aziende ed enti al consorzio The
OpenGroup1
(http://www.opengroup.org/)
•Il mondo Windows della Microsoft per
i server: il primo sistema operativo per
i server è stato N; attualmente sono ancora in funzione server Windows 2000
e 2003, oltre all’ultima versione corrente,
Windows 2008.
Questa macro divisione dei sistemi operativi per le piattaforme server vale anche per gli ambienti per lo sviluppo del
software si dividono ormai in due differenti “filosofie”, che da anni si contendono
e si spartiscono il mercato:
™6 Con il termine di BPR, Business Process Reengineering, si intende l’attività di modifica radicale di uno o più processi aziendali che
muti le condizioni di produzione di un prodotto/servizio in modo percepibile dal cliente.
7 ITIL, IT Infrastructure Library, costituisce un insieme di “best practices” ben consolidate ed accettate per la gestione dei servizi ICT. Una
parte di tali best practices sono state standardizzate nell’ ISO 20000. L’attuale versione di ITIL è la 3, focalizzata a coprire l’intero ciclo di
vita di un servizio.
8 RMI, Remote Method Invocation, consente di invocare metodi di oggetti remoti: questo standard è stato incluso nell’ambito Java.
9 OLE, Object Linking and Embedding, è la tecnica Microsoft per il collegamento e l’incorporazione di oggetti.
10 COM, COM+ e DCOM costituiscono l’evoluzione nel tempo delle archietture Microsoft per applicazioni distribuite
11 Confronta articolo “La Soa è morta. Viva i servizi” pubblicato il 13 gennaio 2009 su www.eweekeurope.it nella sezione Opinioni
12 Centro Nazionale per l’Informatica nelle Pubbliche Amministrazioni
66
ICT Professional n.66
Speciale SOA
•quella Microsoft, che si basa sulla disponibilità di ogni tipo (o quasi) di linguaggio di programmazione, ma solo
nell’ambito dei propri sistemi operativi Windows; è una filosofia “proprietaria” ma molto diffusa anche per una certa facilità di sviluppo, che è andata sviluppandosi fino a raggiungere l’attuale framework architetturale .NET in
grado di sviluppare e gestire web services (propri o di altri);
•quella del “mondo Java”, guidato da
Sun, IBM ed Oracle, che si basa sul linguaggio Java2 che può operare su qualsiasi hardware e con qualsiasi sistema
operativo, basta che ci sia una JVM,
Java Virtual Machine; operante in ogni
ambiente operativo, dagli embedded system ai super computer; è un approccio
molto “open” ma più complesso, che ha
avuto varie implementazioni e sofisticazioni a seconda dei diversi fornitori;
•entrambi questi mondi adottano gli
standard SOA ed XML come semantica comune per l’interoperabilità.
Il mercato italiano degli sviluppatori si è
prevalentemente orientato :
•Per “piccoli” sviluppi al mondo .NET;
•Per applicazioni più complesse e più sofisticate (transazionali, real-time, software di base, ecc.) agli ambienti J2EE,
Java 2 Enterprise Edition.
L’architettura SOA ed i web services consentono di superare la demarcazione sopra
illustrata, in quanto sono e possono essere indipendenti sia dal linguaggio di programmazione che dal tipo di sistema operativo sul quale vengono fatti operare.
L’infrastruttura tipica per il supporto di
una architettura SOA con i web services
si base su server in logica multi-tier, tipicamente su web server – application
server – database server.
Il più delle volte occorre poi interfacciarsi
ad applicativi o a banche dati preesistenti,
che non si possono “mostrare” come web
services. Come presentarli come web services senza riscriverli? La tecnica è chiamata “wrapping”, in italiano “incapsulamento2”: si costruisce un’apposita interfaccia che da un lato presenta WSDL
e supporta il protocollo SOAP, dall’altra
ICT Professional n.66
Figura 10 - Schema di riferimento degli strumenti di sicurezza per i web service
WS-SecureConversation
WS-Federation
WS-Authorizzation
WS-Trust
WS-Privacy
WS-Policy
WS-PolicyFramework
WS-Policy
Attrachments
Policy
Assertions
WS-Security
today
SOAP Foundation
time
(Fonte: W3C)
si interfaccia all’applicazione con le sue
interfacce native (“as is”).
La necessità di interfacciare e far interoperare web services con sistemi legacy diversi ha portato alla creazione di una infrastruttura software chiamata Enteprise
Service Bus, ESB, in grado di fornire efficienti ed efficaci adattatori tra i diversi sistemi (si veda un esempio in fig. 8).
In un’infrastruttura ESB, tutte le applicazioni sono integrate ed operano come
“servizi“ e la logica d’integrazione è distribuita lungo gli endpoint connessi al
bus. Decentralizzando la logica di integrazione lungo il bus si migliora la scalabilità teorica ed è possibile effettuare gradualmente il rilascio delle funzionalità
d’integrazione strettamente necessarie.
Lo standard di riferimento per l’ ESB in
un’architettura SOA è dato da JBI, Java
Business Integration, la specifica emanata
da JCP, il Java Community Process3.
La SOA è sicura?
La SOA, per la sua logica architetturale
di un insieme di componenti che sono in-
IL GDL SOA DEL CLUBTI DI MILANO
(BOX 1)
Dal secondo semestre 2006 nel ClubTI di Milano è attivo il Gruppo di Lavoro
SOA, formato da CIO, consulenti, responsabili di aziende dell’offerta, e coordinato da Marco Bozzetti, con l’obiettivo di fornire una chiave di lettura della SOA e
dei web services (WS) non solo per i CIO ma anche per i decisori, ai diversi livelli, lato offerta e lato domanda. Il GdL iniziò a studiare il fenomeno con un taglio
manageriale, contestualizzandolo nella situazione ICT italiana, chiarendo che cosa
è e che cosa non è (le varie declinazioni, gli standard, …), a chi interessa e perché
(sia lato domanda che lato offerta), quali sono i modelli di business, quali i criteri e
le logiche per una “corretta” scelta ed implementazione da parte di un
Ente/Azienda. I risultati della corposa attività di “volontariato professionale” del
GdL SOA si sono concretizzati in:
• Pubblicazione a marzo 2008 del Libro Bianco sulla SOA v. 1, disponibile in formato elettronico, sul sito del Club (si veda anche Box 3); entro il 2009 verrà
pubblicata la versione 2 definitiva del Libro Bianco
• Workshop sulla SOA tenuto in Assolombarda del 23 giugno e del 16 settembre
2008, disponibile in streaming su www.soieltv.it
• Partecipazione e contributi in numerosi Convegni
• Realizzazione SOA University in streaming su www.cbritaly.it
Il GdL SOA ha operato in due fasi distinte: una prima fase che ha portato alla realizzazione della Libro Bianco v.1, ed una seconda fase, ancora in corso, per la realizzazione della v.2 e della SOA University. La prima fase non ha avuto alcuna sponsorizzazione, la seconda ha la sponsorizzazione di Accenture, HP e Microsoft.
67
Speciale SOA
Fig. 11- Il passaggio da un agglomerato di architetture eterogenee alla SOA
Roadmap
OGGI
Infrastruttura
integrazione
DOMANI
Fig. 12 - La trasformazione della UO-SI come fornitore di servizi e competenze ICT
dipendenti dalla locazione e rintracciabili
in rete, apre un insieme di problemi sulla sicurezza che sono stati in parte risolti con un insieme specifico di strumenti e
standard, nel seguito descritti.
Gli aspetti della sicurezza ICT per l’architettura SOA e per web services includono:
•aspetti architetturali e di configurazione: dipendono dalla progettazione complessiva del sistema;
•la sicurezza dei singoli web service: dipende da come è stato scritto il codice;
•le policy e gli strumenti per l’identificazione ed autenticazione degli interlocutori, che spesso sono altri programmi
e web services.
Gli standard per la sicurezza specifici per
la SOA sono emessi e gestiti soprattutto
da W3C (http://www.w3.org/Security/) e
68
da
OASIS
(http://www.oasisopen.org/specs/#wssv1.1).
A questi si devono aggiungere gli altri
standard tipici della sicurezza ICT, ed indipendenti dall’architettura SOA e dai
web services, in particolare la famiglia di
standard ISO 27000 per la gestione della sicurezza.
Molto importanti a livello implementativo
sono poi le specifiche per la realizzazione di soluzioni SOA sicure emanate da
WS-I, per le quali si rimanda a
http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity.
La fig. 10 mostra lo schema dei vari strumenti di sicurezza, dove:
•WS-Security descrive i miglioramenti
per SOAP e definisce come usare i security token con i messaggi SOAP.
XML Digital Signature e XML Encryption sono i meccanismi principali.
•WS-Policy descrive come mittenti e riceventi possano specificare le loro capacità ed i loro requisiti, grazie ad uno
specifico formato di messaggio SOAP
per la policy.
•WS-Trust descrive il modello per stabilire relazioni sicure sia in maniera diretta che tramite broker, incluse terze
parti e intermediari.
•WS-Privacy descrive il modello per inserire in una WS-Policy gli aspetti legati
alla privacy. L’obiettivo è di poter espletare la conformità a determinate politiche di privacy con la combinazione di
WS-Policy, WS-Securit e WS-Trust.
•WS-SecureConversation descrive come
gestire ed autenticare lo scambio di
messaggi, includendo il trattamento
delle chiavi di sessione.
•WS-Federation descrive come costruire scenari federati per la sicurezza usando WS-Security, WS-Policy, WS-Trust
e WS-SecureConversation.
•WS-Authorisation descrive come le politiche di accesso ed autorizzazione per
un web service debbono essere specificate e gestite.
Tra tutti gli standard e le specifiche inerenti la SOA SAML, Security Assertion
Markup Language, è uno standard basato su XML per lo scambio di dati di autenticazione ed autorizzazione, tipicamente tra un fornitore di web service ed
un fornitore di identità management. È
usato in particolare per omogeneizzare tra
ambienti diversi il Single Sign-On. SAML
fornisce la struttura per descrivere in maniera standard e in XML le informazioni di sicurezza di un utente. SAML è l’elemento fondante, nei web service, per l’autenticazione federata che facilita l’interazione tra domini di sicurezza diversi:
l’identity management federato consente di isolare ciascun dominio dai dettagli
di autenticazione e di autorizzazione delle altre infrastrutture grazie ai meccanismi ed ai messaggi standard SAML.
Le origini e le motivazioni
per la SOA
Le motivazioni per la SOA derivano da
un lato dalle necessità di business lato do-
ICT Professional n.66
Speciale SOA
manda, dall’altro dall’evoluzione tecnologica e dalla conseguente disponibilità di
soluzioni per l’interoperabilità con gli
standard precedentemente descritti, in
particolare WSDL e SOAP, da tutti adottati. Nel presente paragrafo sono discusse le motivazioni lato domanda e lato Offerta, oltre che di tipo tecnico e di Business.
La complessità dei sistemi informativi
aziendali nasce dalla sovrapposizione
nel tempo di soluzioni architetturali e applicative disomogenee tra loro, che rendono complessa e costosa la loro gestione: i vari “silos” disomogenei hanno creato, negli anni, una “barriera corallina” informatica con “n-plicazioni” di dati simili
ma diversi, difficoltà di interazione, mancanza di flessibilità ed agilità nel complesso. Alle veloci richieste di cambiamento del business nei confronti dei sistemi informativi, questi ultimi risultano
troppo spesso solo un vincolo ed un forte freno: affiancato al costo di gestione della “barriera” (mai come ora tale termine
assume il suo vero significato semantico!!)
il tutto non risulta più accettabile alla direzione dell’Azienda/Ente e richiede
La soluzione è la definizione e implementazione di una infrastruttura software
aziendale che permetta la comunicazione
flessibile tra le applicazioni.
Lo scopo primario è quello di passare da
un mondo eterogeneo dove le varie architetture si sommano in un agglomerato caotico ad un insieme più ordinato di
risorse le quali gravitano intorno ad un
nucleo detto “infrastruttura di integrazione”,
che si preoccupa di collegare tutto l’insieme impresa.
La prima forte spinta è avvenuta quindi
lato domanda, con l’aspettativa per il top
management dell’Azienda/Ente:
di migliorare la governance dell’ICT e
dell’Azienda/Ente nel suo complesso , anche grazie all’introduzione di strumenti
informatici per il monitoraggio ed il controllo dei processi e delle loro prestazioni (BPM, Business Process Management4 e BAM, Business Activity Monitoring5) oltre che tramite un ripensa-
ICT Professional n.66
Fig. 13 - Il modello Demand-Delivery per la UO-SI
Fig. 14 – Dall’analisi del Libro Bianco sulla SOA v.1: i benefici attesi
Fig. 15 - Dall’analisi del Libro Bianco sulla SOA v.1: i motivi per l’adozione
mento ed una re-ingegnerizzazione dei
processi stessi (BPR6);
di portare innovazione nei processi in maniera agile grazie all’informatica;
di migliorare significativamente l’allineamento tra business/attività-processi-
sistema informativo.
Le aspettative riguardano anche il Responsabile dei sistemi Informativi e la sua
Unità Organizzativa, che deve trasformarsi da puro centro di costo ad un Centro di Servizi e di Competenze ICT (si
69
Speciale SOA
Fig. 16 - Il lungo percorso per l’interoperabilità applicativa
Fig. 17 - La metafora della “mela SOA”
veda fig. 12), con una struttura ed i processi interni orientati ad un modello “demand-delivery” schematizzato nella fig.
13 e capace di gestire tutte le fasi del ciclo di vita di un servizio ICT in logica
ITILV37. Nella figura sono evidenziate
unità organizzate che espletano processi
primari ITIL delle varie fasi :
•SO, Service Operation;
•SS, Service Strategy;
•SD, service Design:
•CSI, Continual Service Improvement.
La SOA rappresenta un’occasione ed una
necessità per il cambiamento dell’unità organizzativa Sistemi Informativi (UOSI) con gli obiettivi di:
•parlare il linguaggio del business-attività
ed esserev più “vicini”, in maniera agile e flesibile, ai “process owner” ed agli
utenti;, in modo da garantire un’effet-
70
tivo “time to market” nel soddisfare le
richieste delle diverse Direzioni/linee di
business;
•creare un programma e una piano evolutivo (road map) dell’intera architettura
dei sistemi informativi capaci di una più
facile ed efficace interoperabilità tra sistemi ed applicativi diversi, per il superamento del problema dei silos e della conseguente inconsistenza dei dati;
sempre più stretto allineamento dell’ICT
alle esigenze del business e dei processi; maggior flessibilità e riusabilità di moduli (anche “vecchi” tecnicamente, ma
non funzionalmente obsoleti) con una significativa riduzione dei costi ICT;
•monitorare sistematicamente le prestazioni dei sistemi e dei servizi, introducendo metriche, quali ad esempio i Service Level Agreemnet (SLA) e rendendo il tutto trasparente all’utenza finale;
•Maggior disponibilità di soluzioni sul
mercato con conseguente maggior competitività e relativa riduzione dei costi.
Tali motivazioni ed aspettative sono confermate dai risultati dell’indagine condotta dal GdL SOA alla fine del 2007 e riportata nel Libro Bianco v.1. La fig. 14 riporta i principali benefici attesi dalle
Aziende, segmentate in funzione delle loro
dimensioni come numero di dipendenti.
La fig. 15 evidenzia le principali motivazioni da parte del top-management dell’Azienda/Ente.
Le motivazioni di business non sono
solo dalla parte della domanda, ossia dei
clienti utilizzatori dell’ICT: ci sono, e significative, anche lato offerta, ossia dalla parte dei fornitori e produttori di soluzioni ICT.
In primo luogo, dopo molto anni (si veda
fig. 14) , si è avuta la definizione di standard comuni universalmente accettati da
tutti i principali attori, con un totale indipendenza dai linguaggi di programmazione e dai sistemi operativi. Questo
comporta una più facile e più lineare integrazione dei sistemi e degli applicativi,
la riutilizzabilità e convertibilità dei “vecchi” software, un terreno comune per la
collaborazione con altri fornitori ICT, una
maggior focalizzazione alle esigenze reali dei clienti-utenti, una più facile produzione ed offerta di servizi “a consumo”,
noti anche con la dizione inglese di “software on demand” e “pay per use”. Questa tipologia di servizi viene oggi denominata SaaS, “Software as a Service” fornita in rete da fornitori chiamati ASP, Application service Provider.
Con la SOA svariate sono le opportunità di business per i diversi fornitori di ICT,
che includono:
• consulenza sui processi , in particolare
per BPR e per la definizione di “business services”;
• consulenza sull’evoluzione architetturale ICT: tempi e modalità, scelta fornitori, ecc.;
• sviluppo e fornitura di applicazioni specifiche e di moduli applicativi specifici via web services;
ICT Professional n.66
Speciale SOA
ICT Professional n.66
Fig. 18 - L’architettura tecnica del Sistema Pubblico di Cooperazione nelle PA
Composizione dei servizi
SPConn SPCoop
• fornitura piattaforme di sviluppo ed esecutive (run time): application server,
platform server, ecc.;
• Integrazione di sistemi e di applicazioni;
• fornitura di web services , semplici e
compositi, in logica SaaS;
• fornitura di particolari componenti
“iperspecializzati” (es. ESB, adapter,
ecc.);
• supporto per soluzioni in open source.
Gli elementi differenzianti di un approccio SOA:
1) SOA non è una nuova moda, ma è basata su standard consolidati (OMG, Oasis, W3C) e diffusi, recepiti da tutti i grandi player informatici;
2) SOA è business-centrica : ICT e business (LOB) iniziano ad avere un vocabolario comune e ad essere allineati;
3) I servizi SOA si focalizzano sui processi
di business e sulle loro interazioni;
4) I servizi SOA si connettono ed interoperano dinamicamente;
5) I servizi SOA possono essere riusati in
maniera intensiva.
Da un punto di vista strettamente tecnico, la SOA ed i Web Services rappresentano il punto d’arrivo di più di trent’anni di ricerca e sviluppo per consentire interoperabilità a livello applicativo.
Come è evidenziato nella fig. 16, il primo
standard de facto per l’interoperabilità è
stato l’RPC, Remote Procedure Call, inizialmente usato per chiamate tra programmi all’interno della stessa macchine e dello stesso sistema operativo: proposta nel 1984, implementata da SUN
(chiamata ONC) viene standardizzata
dall’Open Group nell’architettura-framework DCE, Distributed Computing
Environment, per applicazioni in logica
client-server:
(http://www.opengroup.org/dce/).
Sulla base e dall’evoluzione del DCE
OMG ha emanato è lo standard CORBA,
Common Object Requesting Broker Architecture, che consente a moduli software, scritti in differenti linguaggi ed operanti su macchine diverse, di cooperare
tra loro. CORBA introduce il concetto di
servizi di supporto: naming, versioning,
introspezione, ecc. Lo standard è com-
Pubblicazione/abbonamento
Orchestrazione
Descrizione
AS SPCoop
(WS-Security)
AS SPCoop
Registro SICA
(XML, SOAP, MIME)
AS SPCoop
(affidabilità)
Messaggistica
Busta SPCoop
(WS-Security)
Busta SPCoop
(XML, SOAP, MIME)
Affidabilità
Connessione
SSL, TLS
HTTP
IPsec
IP
Sicurezza
Interazione
Trasporto
Tecnologie SCPCoop V.1.0
Piano di evoluzione SPCoop
Affidabilità
Fonte: Cnipa
Fig. 19 - L’ interazione tra sistemi informativi diversi della PA tramite
il Sistema Pubblico di Cooperazione
Fonte: Cnipa
plesso e vengono rilasciate diverse versioni; viene anche recepito in Java (RMI8),
Con CORBA si è vicini all’attuale SOA,
ma è di fatto usato prevalentemente nel
mondo Linux-Unix e nell’ambito dell’open-source. Molti grandi fornitori hanno adottato CORBA, altri, in primis Microsoft, hanno sviluppato soluzioni diverse
e proprietarie. Microsoft si è basata su
RPC, in particolare per i PC: ha poi definito e sviluppato meccanismi di comunicazione ed architetture per l’interoperabilità man mano più sofisticate e basate
su DCE: OLE9, COM10, COM+, DCOM,
ActiveX. Solo recentemente, con il frame
work .NET Microsoft adotta gli standard
SOA ed i web services . Altri fornitori hanno proposto loro logiche proprietarie per
lo più basate sul messaging, che complessivamente sono individuate con il termine EAI, Enterprise Architecture Inte-
gration: tipici esempi le soluzioni MQseries di IBM e quelle di Tibco.
Dal punto di vista tecnico la SOA coi web
services è una tecnologia ormai affermata,
consolidata ed utilizzata da tutti i principali fornitori e produttori di ICT.
È presente su tutte le principali piattaforme server, sia proprietarie che open
source, ed in tutti i principali ambienti di
sviluppo, sia “integrati” (IDE, Integrated
Developement Environoment) che “rapidi” (RAD, Rapid Application Developement).
Data la complessità di progettazione e di
sviluppo, in particolare per il coordinamento, sono state introdotte delle metodiche specifiche o che ben si adattano al
mondo dei web services, in particolare:
Strumenti e tecniche di ausilio allo sviluppo di web services; tra le molte, significativi e standard:
71
Speciale SOA
Fig. 20 – Dall’analisi del Libro Bianco sulla SOA v.1 : le barriere all’adozione della SOA
Fig. 21 – Le figure ICT standardizzate da Eucip
- SCA , Service Component Architecture,
e la Open CSA, OASIS Open Composite Services Architecture;
- Gli strumenti WS-I, emessi dalla Web Service Interoperability Organization
(http://www.ws-i.org/default.aspx) quali
“best practices” e facilitatori per l’implementazione di applicazioni SOA;
MDA, Model Driven Architecture, dell’OMG (http://www.omg.org/mda/).
La SOA così affermata che essa costituisce la base tecnologica anche per le evoluzioni oggi al centro dei trend innovativi in informatica: AJAX, web 2.0, SaaS,
Cloud Computing. Ma la l’ampiezza e la
complessità di tali temi porterebbe trop-
72
po lontano e richiederebbe ben altro
spazio rispetto al presente articolo, ed essi
saranno quindi trattati in altre occasioni.
Ma la SOA allora c’è o è morta?
Dal precedente paragrafo si evince che la
SOA ed i suoi standard non sono concetti
nuovi, ma da tempo ormai consolidati, almeno a livello tecnico-architetturale. Negli ultimi anni la SOA ha raccolto interesse
ed è al centro di una forte spinta promozionale da parte dei principali fornitori di
ICT, ma recentemente questa spinta si è
affievolita e vari giornalisti e fonti di stampa hanno titolato articoli con “La SOA è
morta?” 11 , “La SOA non c’è più …”.
La maggior parte dei nuovi pacchetti software si basa su web service e la totalità
dei Fornitori basa le proprie soluzioni su
tale architettura, per renderle indipendenti
dalle piattaforme e dai sistemi operativi,
oltre che facilmente interoperanti con altri applicativi. Ma questo porta a considerarla il più delle volte solo come un’altra nuova architettura tecnologia sulla
quale tutti i produttori di software si sono
buttati per ovvie ragioni di mercato e di
marketing, relegandola quindi ad una
nuova offerta di prodotto o di soluzione
IT, e non aiuta a comprendere la sua doppia valenza, tecnica e di business, schematizzata nella Figura 1.
Facendo riferimento a tale figura come ad
una mela, è stata quasi totalmente “mangiata”, ossia adottata, la parte tecnologica, ma la parte business è stata solo “assaggiata” (la metafora in fig. 17).
Il “quasi” riferito alla parte tecnologica
sta ad indicare che, almeno in Italia, poche Aziende/Enti hanno intrapreso con
la SOA un vero e proprio programma
pluriennale per la trasformazione dell’intero sistema informativo. Sono stati
fatti progetti prototipali o per coprire nuovi processi e nuove attività, oppure sono
stati “wrappizzati” vecchi applicativi
ancora funzionanti (i così detti legacy) per
non doverli rifare, almeno nel breve
medio termine.
Con la generale crisi economica e finanziaria, oltre che con i grandi bagni di sangue di molti mega-progetti infirmatici degli anni passati, l’Alta Direzione vuole
avere dei risultati a breve, massimo in 1214 mesi, e ben difficilmente si vuole impegnare in programmi pluriennali …
L’introduzione dei concetti di BPR, BPM
e BAM, che ora potrebbero trovare una
più facile e reale attuazione tramite la
SOA, non sempre è visto di buon occhio
da parte dei massimi responsabili dell’Azienda/Ente: è doveroso misurare le
attività degli altri … ma le mie?
E questo è tanto più vero per le piccole realtà, che costituiscono l’ ossatura ed il sistema nervoso dell’economia italiana:
perché mettere in discussione i processi se
l’Azienda è in attivo e funziona? Perché
ICT Professional n.66
Speciale SOA
misurare, ed investire/spendere per farlo, attività che si crede siano sotto controllo
ed “a vista” da parte dei massimi responsabili?
L’osservazione è in parte vera, ma con
la forte terziarizzazione di molti processi,
con la filiera sempre più stretta tra
l’azienda ed i suoi clienti e fornitori, la
competitività “globale” richiede una
continua innovazione su tutti i processi, e quindi un sempre più forte supporto dei sistemi informatici sia per l’automazione di molti processi sia come strumenti decisionali. In tale contesto una facile ma efficace ed efficiente interoperabilità dei propri sistemi informativi con
quelli dei clienti e dei fornitori risulta
sempre più improcrastinabile.
Questo discorso vale anche per le Pubbliche Amministrazioni (PA), sia centrali che locali, che devono sempre più e meglio “digitalizzarsi” per offrire servizi a tutti i loro interlocutori, in primis i cittadini e le aziende. Il Cnipa12 ha definito propria la SOA come cuore del Sistema
Pubblico di Cooperazione (fig. 18). In tale
ambito, un sistema informativo di una PA
può far integrare i propri applicativi con
quelli di un altro sistema di un’altra PA,
indipendentemente da come sono fatti e
su quali piattaforme operano, tramite porte di dominio che “mappano” le realtà locali negli standard SOA ed in un formato di trasporto ad hoc, ma XML, chiamato “busta e-gov”.
La fig. 19 illustra tale interazione: per i
dettagli si rimanda a
http://www.cnipa.gov.it/site/it-IT/Attivit%c3%a0/Sistema_Pubblico_di_Connettivit%c3%a0_(SPC)/
I problemi nell’affrontare un programma/prigetto SOA sono ben emersi nella già
citata indagine del ClubTI-Fida, e sintetizzati nella fig. 20:
• Per le aziende “piccole” (< 10 dipendenti) il primo ostacolo è costituito dalla “non cultura informatica” dei decisori di massimo livello;
• Per le aziende medio grandi l’ostacolo
principali è costituito dalle competenze interne.
E proprio per le PMI la disponibilità di
ICT Professional n.66
73
Speciale SOA
disporre in logica “a consumo” tramite
SaaS di applicativi sofisticati, che non potrebbero né acquisire né gestire al loro interno, potrebbe consentire, a giudizio dell’autore, il salto di qualità per risalire le
classifiche internazionali (a d esempio
OECD, IMD, ecc.) che relegano, e non a
torto, il “sistema Italia” tra gli ultimi in
Europa ed in posizioni basse a livello
mondiale. Al di là del tipo di struttura organizzativa, l’elemento determinante per
il successo (o non) è dato dalle competenze
e dalle professionalità delle persone coinvolte. Coinvolte non tanto e non solo nella progettazione e sviluppo dei web services e, ma anche nell’analisi dei processi e nella definizione dei “business services”, nella riorganizzazione dell’UO-SI in
un’ottica di Centro servizi, nel supporto all’utenza, nella gestione dei progetti
e dei terzi fornitori, nella gestione opera-
74
tiva dell’intero sistema informativo.
Non è necessario che tutte le competenze siano espletate internamente, ma se si
terziarizza e si delega occorre che all’interno ci sia la capacità di controllo e di gestione del tutto.
La SOA, come ogni altro progetto che impatta sui processi e sulle modalità operative del personale, richiede a tutti i livelli, ma soprattutto al vertice, la capacità di gestire efficacemente il cambiamento, il così detto “change management”.
È un aspetto importante e che non deve
essere sottovalutato.
Per le competenze tecniche si può ora far
riferimento alle figure professionali ed alle
loro competenze così come definite dallo standard europeo Eucip. La fig. 21 mostra le varie figure per l’ICT ad oggi definite , suddivise nelle tre aree del “plan”,
del “build” e dell’”operate”. Ogni profilo
è descritto da un documento che definisce l’insieme delle competenze richieste
Seguire le indicazioni dello standard Eucip semplifica la selezione del personale
interno per un programma di crescita nella nuova logica ITIL-SOA, ed aiutare nella richiesta/selezione/acquisizione del
personale esterno da coinvolgere nei diversi progetti.
Per il personale interno è opportuno
svolgere l’analisi del gap, sia a livello tecnico che psico-attitudinale
Tempi e costi
Il progetto architetturale nel suo complesso fa parte della fase iniziale di un
“programma SOA”, che si articola nelle
diverse fasi per la migrazione della situazione e delle architetture “as-is”, normalmente a silos, in un’architettura SOA.
L’intero programma , al di là della fase ini-
ICT Professional n.66
Speciale SOA
IL LIBRO BIANCO SULLA SOA
ziale di impostazione che, a secondo della complessità e vastità del sistema informativo in considerazione può durare
tra i 2 ed i 12 mesi, ha una durata media
superiore ai quattro – cinque anni;
Il progetto realizzativo di una specifica soluzione SOA, relativo ad un solo o a pochi processi:, può richiedere, in funzione
della sua complessità e granularità, dai 2
ai 24 mesi (o più). Un intervento iniziale
di test costituisce un tipico progetto della durata di almeno 6-12 mesi.
Occorre tener conto, in logica “change management”, delle competenze ICT e della “cultura” interne. I tempi (ed i costi) per
la formazione del personale coinvolto nella SOA non devono essere sottovalutati.
I costi possono variare in maniera assai
significativa a secondo che si consideri
l’intero programma o, nel suo ambito, un
singolo progetto, ed a secondo delle opzioni scelte:
•da centinaia di €/anno in caso di Saas,
•a migliaia di €/anno (anche molte) in caso
di opzione “suite” o “best of breed”
Quando si considerano i costi per una soluzione SOA si dovrebbero considerare tutti i costi diretti ed indiretti, nella logica ormai consolidata del TCO, Total Cost of
Ownership, ed in particolare si deve porre attenzione, oltre ai costi hardware, di
sviluppo e di licenze software, anche ai :
• costi progettazione (in particolare per
l’intero Programma nella prima fase);
• costi (tempo-uomo) per l’approvazione
dall’Alta Direzione —> analisi rischio
e ritorno economico dell’iniziativa;
• costi formazione sia per il personale tecnico che per gli utenti;
• costi change management e di gestione dell’intero “programma”.
In ogni caso il costo complessivo è significativo, ma deve sempre essere confrontato con
il costo per l’Azienda/Ente di una NONSOA, ossia di un sistema informativo non flessibile e non strettamente allineato al business,
che difficilmente potrà portare effettivo valore a quest’ultimo.
Marco Bozzetti
Partner GeaLab
ICT Professional n.66
(BOX 3)
Il principale risultato delle attività del GdL SOA è stata la pubblicazione, a fine marzo
2008, del Libro Bianco sulla SOA v.1, reso disponibile in formato elettronico nel sito
del ClubTI di Milano, www.clubtimilano.it per i Soci e per tutti gli utenti che si registano (gratuito).
Questa prima versione è focalizzata ad una visione strategica del fenomeno a medio
ed a lungo termine, con un linguaggio ed un taglio manageriale-decisionale.
Indice e contenuti Libro Bianco sulla SOA v.1
1. Introduzione: illustra brevemente motivazioni ed obiettivi del LB
2.Allineare il sistema informativo ai processi di business: illustra la logica della
SOA in un’ottica “business centrica”, evidenziando la stretta relazione tra WS, business services ed i processi reali dell’Ente/Azienda.
3. Cosa sono le architetture SOA ed i web services: è il capitolo più tecnico, che
descrive i concetti base dell’architettura e dei WS, facendo riferimento ai vari ambiti
ed illustrando, con semplice esempi, in che cosa consistono.
4.L’impatto della SOA sui fornitori: analizza i diversi approcci lato offerta, e considera anche l’offerta di soluzioni open-source. Il capitolo si basa, e fa riferimento, all’indagine sui fornitori riportata nell’Allegato 1 e che il GdL intende nampliare nella v.2.
5.L’impatto della SOA sulla funzione ICT: è il capitolo che discute l’impatto della
SOA lato domanda e che discute logiche e criteri da seguire per decidere se e
come migrare il proprio sistema informativo in SOA. I diversi casi di studio
dell’Allegato 2 mostrano alcuni esempi di progetti SOA-WS sviluppati da aziende
ed enti italiani.
6.L’impatto della SOA sul sistema paese: dall’impatto sulla domanda e sull’offerta,
non solo per l’ICT ma anche per il ripensamento dei processi, viene discusso il più
generale impatto sul sistema paese in termini di miglioramento delle competitività
delle aziende e di opportunità di business per il mondo ICT, in particolare in logica
SaaS, Software as a Service.
7.I risultati dell’ indagine 2007 Fida-ClubTI Milano: sintetizza i risultati dell’indagine effettuata su tutti i Soci e simpatizzanti dei vari ClubTI.
8.Allegati:
All. 1 Schede prodotti e soluzioni sul mercato
All. 2 I casi di studio
All. 2.1 Architettura SCP e Porta di Dominio per le Pubbliche Amministrazioni
All. 2.1.1 L’implementazione della Porta di Dominio del Comune di Milano
All. 2.2 Il Progetto BPM
All. 2.3 L’ evoluzione dalla EAI alla SOA: il caso Telecom Italia
All. 2.4 Il progetto SEM in Seat
All. 2.5 Emessage
All. 2.6 Suite Cardinis
All. 2.7 Il progetto SI.R. Nuova Generazione di Lombardia Informatica
All. 2.8 Il caso Gruppo Monte dei Paschi di Siena (MPS)
All. 3 Tabella confronto caratteristiche tecniche ambienti sviluppo web services
opensource
All. 4 Questionario indagine decisori ed utenti SOA
I casi di studio rappresentano una parte significativa del LB: l’insieme dei casi considerati nella prima versione è ridotto, ma risponde alla logica di considerare l’impatto della SOA non solo nello sviluppo di applicazioni al’interno di sistemi informativi, ma
anche su prodotti e soluzioni software che il produttore ha voluto far evolvere per renderli interoperanti con altri ambienti grazie all’uso dei web services. È in corso la realizzazione della versione 2 definitiva del Libro Bianco che sarà disponibile a fine 2009.
75