Service oriented architecture: di che cosa parliamo?

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 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-macal 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 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 BPM, BUSINESS PROCESS MANAGEMENT BAM, BUSINESS ACTIVITY MONITORING Consente una corrispondenza tra un modulo di un processo di business (business service) e un oggetto software che risponda agli standard SOA BUSINESS TECNICO 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 62 ICT Professional n.66

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 (Regichina 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 Fig. 2 - Correlazione tra processi, Business Services e Web Services Processi Business Services Web Services High Level Business Process Business Business Service Service Electronic Image Electronic Image of the High Level Business Proc. Fig. 3 - Il modello elementare dei Web Services Un protocollo standardizzato che definisce il formato di un messaggio fra le applicazioni <publish> A SOAP Messages PRODUCER Fornisce il servizio UDDI repository Business Service KPI, Real time Alerting 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 <bind> 1 2 SOAP Messages C SOAP Messages B <find> CONSUMER Utilizza il servizio Web Services Business Level 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 Utilizzare un Web Service 1) Il consumer manda una richiesta al producer 2) Il producer risponde alla richiesta del consumer 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 pre- SOA ma con le stesse finalità, quali CORBA-IIOP, RMI e COM+ usano ICT Professional n.66 63

Fig. 4 - Le tipiche operazioni elementari tra web services <publish> Producer Broker <bind> <use> Fig. 5 - BPEL nello Stack dei Servizi SOA WS- Reliable Messaging BPEL4WS WS- Security UDDI XSD, WSDL, WS-Policy SOAP XML HTTP, MQ, SMTP WS- Coordination WS- BA <find> Consumer Process Quality of Service Discovery Description Messaging Transport 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 tipiche 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 services. 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

Vendite Vendite Vendite Vendite Vendite Speciale SOA 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 Fig. 6 - Esempio di funzionamento dell orchestrazione dei web services via BPEL ed il relativo motore Progettista di processo Il Web Service viene pubblicato Fig. 7 - La visione d insieme dell associazione processi-ict in SOA con web services BAM BSM WSM System Mgmt High Level Business Process Business Business Service Service Explicit Processes Electronic Image Electronic Image of the High Level Business Proc. 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 Applications Server Storage...... Software di sviluppo <process> <sequence> Processo <receive> <.../> BPEL </sequence> </process> Motore di Orchestrazione Business Service KPI, Real time Alerting 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- Business Level Business Process Mgmt.NET Web Services Java ERP Application layer Web Services I.T. Levels ICT Professional n.66 65

Fig. 8 - Tipico schema funzionale di ESB (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 misurazione 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 Ma dove e come può operare una SOA? 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 OpenGroup 1 (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

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 incapsulamento 2 : si costruisce un apposita interfaccia che da un lato presenta WSDL e supporta il protocollo SOAP, dall altra Figura 10 - Schema di riferimento degli strumenti di sicurezza per i web service WS-SecureConversation WS-Policy WS-PolicyFramework WS-Policy Attrachments Policy Assertions 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 WS-Federation WS-Trust WS-Security SOAP Foundation WS-Authorizzation WS-Privacy 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 Process 3. 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. today time (Fonte: W3C) ICT Professional n.66 67

Fig. 11- Il passaggio da un agglomerato di architetture eterogenee alla SOA OGGI Roadmap 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 Infrastruttura integrazione DOMANI Fig. 12 - La trasformazione della UO-SI come fornitore di servizi e competenze ICT 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- 68 ICT Professional n.66

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: 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 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 Management 4 e BAM, Business Activity Monitoring 5 ) oltre che tramite un ripensamento ed una re-ingegnerizzazione dei processi stessi (BPR 6 ); di portare innovazione nei processi in maniera agile grazie all informatica; di migliorare significativamente l allineamento tra business/attività-processisistema 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 ICT Professional n.66 69

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 ITILV3 7. 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 (UO- SI) 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 effettivo 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; 70 ICT Professional n.66

Fig. 18 - L architettura tecnica del Sistema Pubblico di Cooperazione nelle PA Composizione dei servizi SPConnSPCoop Descrizione Messaggistica Orchestrazione AS SPCoop (WS-Security) Busta SPCoop (WS-Security) Fig. 19 - L interazione tra sistemi informativi diversi della PA tramite il Sistema Pubblico di Cooperazione AS SPCoop Registro SICA (XML, SOAP, MIME) Busta SPCoop (XML, SOAP, MIME) Connessione SSL, TLS HTTP Trasporto Tecnologie SCPCoop V.1.0 IPsec IP AS SPCoop (affidabilità) Affidabilità Sicurezza Interazione Affidabilità Piano di evoluzione SPCoop Pubblicazione/abbonamento Fonte: Cnipa Fonte: Cnipa 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 è complesso e vengono rilasciate diverse versioni; viene anche recepito in Java (RMI 8 ), 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: OLE 9, COM 10, 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 Integration: 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: ICT Professional n.66 71

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 troppo 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 12-14 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é 72 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

IL LIBRO BIANCO SULLA SOA (BOX 3) 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 NON- SOA, 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 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. ICT Professional n.66 75