LA TECHNOLOGY TRANSFER PRESENTA INTERNATIONAL. Roma Maggio 2010 Residenza di Ripetta Via di Ripetta, 231 CONFERENCE SOA MAKING SOA WORK

Transcript

1 LA TECHNOLOGY TRANSFER PRESENTA Roma Maggio 2010 Residenza di Ripetta Via di Ripetta, 231 INTERNATIONAL CONFERENCE SOA MAKING SOA WORK

2 D E S C R I Z I O N E Negli ultimi tempi ci sono state tantissime discussioni sui fallimenti dei progetti SOA, alcuni analisti hanno addirittura dato per morta la SOA. La verità è che non esiste niente di sbagliato con la SOA ma che spesso è stata la vittima di furto di identità : le tecnologie Web Services e i prodotti Middleware pretendono di essere la blueprint architetturale della Vostra SOA, mentre invece la vera identità della SOA si trova nelle Best Practices per la Service Orientation, architettura e processi di sviluppo. Questa Conferenza internazionale, tenuta da autorevoli esperti con grandissima esperienza pratica su SOA, risponderà a delle domande chiave e presenterà argomenti cruciali per tutte le aziende che vogliono andare oltre i progetti di piccola scala e che desiderano capitalizzare su SOA attraverso i progetti, l Enterprise e i Business partners. In particolare si discuterà: SOA è il Santo Graal che finalmente ci permetterà di allineare il Business e l IT? Esamineremo la transizione dalla Business Architecture alla SOA e come possono essere collegate Poiché il numero di progetti SOA che falliscono sono sempre numerosi, è importante che Vi attrezziate in termini di argomenti e fatti prima di incontrare i Vostri sponsors del Business. I calcoli della ROI possono convincere anche i Managers più scettici Andare da un approccio primitivo per costruire servizi a una strategia aziendale richiede la comprensione del livello di maturità della SOA nella Vostra organizzazione, la definizione di una Roadmap per l evoluzione della SOA e l impiego della giusta Governance per l implementazione della Vostra Roadmap Le architetture basate su REST sembrano competere con gli approcci tradizionali per costruire SOA: è vero? O è solo un altra opzione? E come decidere quando usarle? Web 2.0 continua ad essere uno degli argomenti più caldi dell IT, bisogna capire le implicazioni su come architettare i servizi I servizi proliferano nell organizzazione, ma quando cominceremo ad usare un approccio strutturato prima di perdere il controllo? Gli Enterprise Service Buses possono essere uno strumento importante per integrare e virtualizzare i servizi, ma non possono essere confusi con una blueprint di architettura Molte aziende stanno usando la virtualizzazione per consolidare l hardware e risparmiare, spesso però viene indirizzato da operazioni di data center non in linea con la SOA e questo non dovrebbe accadere, anche perché lo step successivo, il Cloud Computing, deve essere collocato sotto l ombrello SOA Il problema della sicurezza diventa sempre più critico nell ambiente SOA Capitalizzare su SOA implica una revisione dell approccio di sviluppo delle applicazioni. BPM ha una notevole sinergia con SOA che può fornire la flessibilità necessaria per rendere l allineamento IT-Business una realtà Tra gli argomenti trattati citiamo: Web 2.0: più che una graziosa facciata Da Service Virtualization a Server Virtualization al Cloud Mettere in sicurezza una SOA richiede molto di più che la tradizionale sicurezza Web Definire una Roadmap SOA basata su un SOA Maturity Model Business Architecture per SOA Sviluppare servizi semplici ottenendo grandi risultati Perché il Cloud ha bisogno della SOA Enterprise Service Bus Servizi senza SOA o SOA senza Servizi? Provate REST SOA e BPM: il meglio dei due mondi Web 2.0 e SOA: il collegamento mancante Come calcolare il ROI per la SOA

3 Max Dolgicer È Direttore dell ISG, una società di New York specializzata in IT strategy, sviluppo e integrazione di applicazioni distribuite su larga scala usando Service Oriented Architectures. Mr. Dolgicer è una riconosciuta autorità nel campo del computing distribuito. Durante i suoi 28 anni di esperienza ha gestito molti progetti di sviluppo per importanti aziende. La sua conoscenza tecnica copre tutto lo spettro delle tecnologie di Middleware con particolare enfasi sul design e sullo sviluppo di architetture distribuite. È Contributing Editor della rivista Application Development Trends e un autorevole speaker nelle principali conferenze del settore Frank Greco Ha più di 15 anni di esperienza nell Enterprise Computing fornendo expertise tecnologica e strategie alle istituzioni finanziarie. È stato coinvolto con SOA, Grid Computing e HPC fin dagli anni 90. Oggi si occupa di strategie tecnologiche e di Business per il Cloud Computing, infrastrutture elastiche di IT e nuovi modelli di sviluppo per multicore e parallel programming. Ha fondato il primo Java User Group, il NYJavaSIG, che è il più grande Java User Group del Nord America. Questo User Group conta oggi più di 6000 membri. Gerhard Bayer È un Senior Consultant della ISG (International Systems Group), una società di consulenza specializzata nello sviluppo e integrazione di applicazioni distribuite su larga scala usando SOA. Il suo lavoro include il design di architetture per Service Oriented Integration e lo sviluppo di applicazioni di e-business. Ha una laurea in fisica e una in Computer Science. SCHEDA D ISCRIZIONE SPEAKERS Mike Rosen Gerhard Bayer Max Dolgicer David Koosis Gabriele Pellegrinetti Frank Greco Da restituire compilata a: Technology Transfer Piazza Cavour, Roma Tel Fax info@technologytransfer.it

4 Partecipanti Questa Conferenza si rivolge a Professionisti, Managers e Architetti di IT che vogliono sapere come evitare insuccessi nelle implementazioni SOA e come renderla produttiva. QUOTA DI PARTECIPAZIONE Euro 1600 (+IVA) La quota di partecipazione comprende documentazione, colazioni di lavoro e coffee breaks. MODALITÀ DI ISCRIZIONE Il pagamento della quota, IVA inclusa, dovrà essere effettuato tramite bonifico, codice Iban: IT 34 Y Banca Intesa Sanpaolo S.p.A. Ag di Roma intestato alla Technology Transfer S.r.l. e la ricevuta di versamento inviata insieme alla scheda di iscrizione a: TECHNOLOGY TRANSFER S.r.l. Piazza Cavour, ROMA (Tel Fax ) Nome Cognome Funzione aziendale Azienda Partita IVA Codice fiscale Indirizzo CAP Città Provincia Telefono Fax entro il 27 Aprile 2010 ROMA Maggio 2010 Residenza di Ripetta Via di Ripetta, 231 In caso di rinuncia o di cancellazione dei seminari valgono le condizioni generali riportate sopra. Quota di iscrizione Euro 1600 (+IVA) Timbro e firma CONDIZIONI GENERALI In caso di rinuncia con preavviso inferiore a 15 giorni verrà addebitato il 50% della quota di partecipazione, in caso di rinuncia con preavviso inferiore ad una settimana verrà addebitata l intera quota. In caso di cancellazione del seminario, per qualsiasi causa, la responsabilità della Technology Transfer si intende limitata al rimborso delle quote di iscrizione già pervenute. SCONTI DI GRUPPO Se un azienda iscrive allo stesso evento 5 partecipanti, pagherà solo 4 partecipazioni. Chi usufruisce di questa agevolazione non ha diritto ad altri sconti per lo stesso evento. ISCRIZIONI IN ANTICIPO I partecipanti che si iscriveranno al seminario 30 giorni prima avranno uno sconto del 5%. DURATA ED ORARIO 3 giorni: SOA Conference È previsto il servizio di traduzione simultanea Tutela dati personali Ai sensi dell art. 13 della legge n. 196/2003, il partecipante è informato che i suoi dati personali acquisiti tramite la scheda di partecipazione al seminario saranno trattati da Technology Transfer anche con l ausilio di mezzi elettronici, con finalità riguardanti l esecuzione degli obblighi derivati dalla Sua partecipazione al seminario, per finalità statistiche e per l invio di materiale promozionale dell attività di Technology Transfer. Il conferimento dei dati è facoltativo ma necessario per la partecipazione al seminario. Il titolare del trattamento dei dati è Technology Transfer, Piazza Cavour, Roma, nei cui confronti il partecipante può esercitare i diritti di cui all art. 13 della legge n. 196/2003. Mike Rosen È Direttore per l Enterprise Architecture con il Cutter Consortium e Direttore editoriale del SOA Institute. La sua attuale e importante attività riguarda l implementazione di soluzioni SOA agili e flessibili. Ha molti anni di esperienza nell architettura e design di applicazioni e più di 20 anni di esperienza nello sviluppo di prodotti per tecnologie distribuite come DCE, CORBA, DCOM, J2EE, Web Services, Transaction Processing e Messaging. È uno speaker di fama internazionale e autore di molti libri, tra cui ricordiamo Applied SOA: Architecture and Design Strategies. È stato Chief Enterprise Architect alla IONA Technologies dove era responsabile dello sviluppo dell intera architettura di prodotto della piattaforma di Web Services di nuova generazione di IONA e della creazione della reference architecture per la costruzione di applicazioni su questa piattaforma. David Koosis È CIO e Deputy Commissioner del Department of Correction di New York City per l amministrazione Bloomerg. In particolare si interessa di Data Integration e di standards. Prima di lavorare per l amministrazione di New York è stato consulente software e tecnologie Web per Goldman Sachs, Morgan Stanley, IBM e Sun. È co-autore del primo best seller primer su Java Java Programming for Dummies e autore di molti articoli tecnici. I suoi teams e i suoi progetti hanno avuto prestigiosi riconoscimenti come il PC Week Best Practices Award e l NYC Technical Excellence Award. Gabriele Pellegrinetti È Senior Consultant alla Tecnet Dati, una azienda italiana che fornisce servizi professionali nel settore IT. Ha più di 15 anni di esperienza nel settore IT dove si è interessato di tecnologia multimedia, sviluppo di applicazioni Web e SOA. È laureato in Computer Science all Università di Torino e autore di molti corsi, più recentemente su Web 2.0 e SOA. Ha collaborato con importanti aziende italiane per progettare la loro infrastruttura di sicurezza per SOA e lo sviluppo di applicazioni Enterprise 2.0.

5 P R O G R A M M A Introduzione Max Dolgicer SOA è stata dichiarata morta da alcuni analisti. Quest affermazione per un certo periodo si è conquistata i titoli delle riviste specializzate, ma quando si guarda alla radice del problema ci si accorge che le rivelazioni non sono molto sorprendenti: tutti concordano che dobbiamo avere dei servizi (in senso lato), ci deve essere una architettura che favorisca la longevità e un approccio basato sulle Best Practices per ottenere efficienza. Quello che dovrebbe essere morto è l errore di scambiare le tecnologie Web Services e i prodotti Middleware in una blueprint architetturale per la SOA. Questa Conferenza Vi mostrerà come realmente far funzionare e rendere produttiva una SOA. La SOA sbagliata: come rendere funzionante e produttiva SOA Presentazione della Conferenza Sessione 1 Web 2.0: più che una graziosa facciata Gabriele Pellegrinetti Il Web 2.0 ha ridato nuova vita ad Internet fornendo un esperienza utente più interattiva che è comparabile alle applicazioni desktop fat client. Il Web 2.0 introduce nuovi tipi di servizi che sono progettati per condividere oggetti presentation o multimedia (presentation services) e permettere di sviluppare una nuova applicazione combinando servizi da differenti siti o applicazioni (ad esempio attraverso Mashups). Una delle componenti più popolari del Web 2.0 sono le Rich Internet Applications (RIAs). Queste includono nuove features per processare informazioni e interfacce utente basate su Ajax, Flex, JavaFX, Silverlight, ecc. Il problema allora è come i servizi dovrebbero essere progettati per supportare i requisiti dei clients RIA. La sessione esamina i servizi di supporto a RIA che sono inclusi in una infrastruttura SOA e sono gestiti attraverso tools di SOA governance. Web 2.0: si stanno presentando nuove opportunità Cosa sono le Rich Internet Applications (RIAs)? Relazione fra clients RIA e Servizi Sinergia fra Web 2.0 e SOA Tools di sviluppo Web 2.0 e conformità a SOA RIA e REST versus SOAP Sicurezza dei servizi SOA Web 2.0: estendere il contratto di servizio per soddisfare i nuovi requisiti Guidelines per progettare Servizi SOA in accordo con gli standards Web 2.0 Sessione 2 Da Service Virtualization a Server Virtualization al Cloud Gerhard Bayer L evoluzione di come le aziende usano SOA può essere classificata in 3 fasi: la fase iniziale si focalizza sulla migrazione dagli approcci precedenti ai servizi, la seconda fase si sposta sulla riusabilità, mettere in sicurezza un numero sempre crescente di clients che accedono ai servizi, rispettare gli SLA, ecc. In questa fase la Server Virtualization gioca un ruolo fondamentale. Mentre gli Enterprise Architects si focalizzano su SOA i Managers di Data Center e delle operations hanno in agenda la Server Virtualization per incrementare l efficienza e ridurre i costi. Questi due sforzi non sono stati trattati in maniera sinergica da molte aziende e invece avrebbe dovuto essere fatto. Questo approccio alla seconda fase sfocia naturalmente nella fase 3 dove i servizi vanno verso il Cloud. A prescindere che si tratti di un Cloud aziendale o esterno, tutto quello che abbiamo fatto e appreso nelle precedenti fasi rimane valido dal momento che la sicurezza e l integrazione diventano più complesse nel Cloud e la SOA Governance gioca un ruolo sempre più importante. SOA Fase 1: Proliferazione dei servizi e ruolo della SOA Governance SOA Fase 2: Service Virtualization e Server Virtualization SOA Fase 3: Andare nel Cloud Sessione 3 Mettere in sicurezza una SOA richiede molto di più che la tradizionale sicurezza Web Gabriele Pellegrinetti In una SOA la sicurezza gioca un ruolo molto importante e i tools standard usati per sviluppare applicazioni Web non sono spesso sufficienti. Inoltre le tecnologie per gestire la sicurezza dei Web Services (ad esempio WS-Security, WS-Policy, ecc.) non sono sempre in grado di soddisfare le necessità del Business, specialmente quando implementano una SOA basata su tecnologie eterogenee (ad esempio SOAP, CORBA, JMS, ecc). L avvento del Web 2.0 e del Cloud Computing enfatizza ulteriormente la necessità di avere una gestione efficace ed efficiente del servizio di sicurezza. La sicurezza di SOA deve essere configurata come un servizio distribuito, accessibile da tutte le applicazioni all interno dell azienda, processi di Business e servizi. Una soluzione è quella di implementare la sicurezza come un servizio. La necessità della sicurezza di SOA La sicurezza di SOA comparata con la sicurezza dell applicazione Web L infrastruttura di sicurezza della SOA Sicurezza come un Servizio (servizi di sicurezza centralizzati) Sicurezza della SOA per una SOA basata sulle tecnologie dei Web Services Sicurezza della SOA per una SOA basata su tecnologie eterogenee SOA Appliance (soluzioni di sicurezza basate sull hardware) Sicurezza e Governance Case Study Sessione 4 Definire una Roadmap SOA basata su un SOA Maturity Model Max Dolgicer Oggi sono disponibili molti SOA Maturity Models, prevalentemente forniti da vendors. L idea è quella di definire un numero di livelli in modo che un azienda possa progredire attraverso questi livelli per ottenere un più alto livello di maturità. Il Maturity Model mostra gli obiettivi e le caratteristiche di ciascun livello e i prerequisiti che si devono avere per andare al livello successivo. Dopo aver spiegato uno dei Maturity Models la sessione illustrerà come sviluppare una Roadmap personalizzata per la Vostra SOA. L obiettivo di una Roadmap è quello di guidare l evoluzione di una organizzazione IT attraverso gli stadi di una maturità crescente di SOA. Fornisce una guida per mettere a punto la vision di SOA e un benchmark per misurarne i progressi. Può sembrare che il Maturity Model sia la Roadmap, ma non è così. Ciascuna organizzazione IT si trova ad uno stadio differente, avendo differenti priorità e tempi per indirizzare i diversi

6 elementi dell evoluzione SOA, come per esempio il riuso del servizio, la sicurezza, la governance, la gestione del servizio, ecc. Il Maturity Model e la Roadmap saranno illustrati attraverso un esempio di progetto. Quali sono i Maturity Models per la SOA che esistono oggi? Esplorare i livelli e gli elementi principali per ciascun livello Sviluppare una Roadmap personalizzata per la SOA Un esempio di progetto per il mapping di un Maturity Model in una Roadmap Sessione 5 Business Architecture per SOA Mike Rosen La Business Architecture descrive strategie obiettivi, tattiche e struttura di una organizzazione. SOA è uno stile architetturale dove i servizi allineati al Business sono l unità fondamentale di analisi, design e implementazione delle soluzioni aziendali. Ovviamente queste dovrebbero essere collegate. Allora cosa è un servizio allineato al Business? Da dove viene il contesto di Business? Come è descritto? Come è implementato in un servizio? Come può essere collegato con i requisiti, tattiche, strategie e obiettivi del Business? Questa sessione comincia con una panoramica dei concetti architetturali di SOA: architettura, servizi, processi di Business e semantica. Quindi esplora la relazione fra SOA e Business Architecture, includendo la definizione di cosa è e cosa non è la Business Architecture. Avendo elaborato il contesto architetturale della SOA e i requisiti, vengono forniti metodi specifici per applicare la Business Architecture all identificazione, analisi e design dei servizi SOA. Introduzione alla Business Architecture Capire il collegamento fra Business Architecture e SOA Esame di metodi per applicare la Business Architecture al design della SOA Dimostrare il collegamento fra servizi e strategia di Business Sessione 6 Less is More: sviluppare servizi semplici ottenendo grandi risultati David Koosis Le applicazioni di Business prima dell avvento dei Web Services erano delle entità complete e autosufficienti. I Web Services d altra parte sono quasi sempre intesi come blocchi di costruzione da combinare, mash up o integrare come parte di una costruzione software più ampia e in molti casi il provider del servizio e il team che lo usano all interno del proprio sistema sono diversi. Se i Web Services sono usati per integrare dati o applicazioni all interno della Vostra organizzazione, o sono usati come una API a cui i clienti possono accedere tramite Internet, o per collaborare con partners esterni, e se il loro uso risulta lento e complicato allora danno veramente pochi vantaggi. I Web Services diventano popolari se sono facili da usare, questa è la grande forza dietro i servizi e le APIs fornite da Google e da Amazon giusto per fare due nomi noti. Le scelte di design che Voi farete avranno un impatto profondo sull utilizzo dei Web Services da parte dei Vostri colleghi, i Vostri clienti e i Vostri partners. Una considerazione chiave di design è rappresentata dalla tecnologia scelta. In questa sessione verranno esplorati i fattori che rendono i servizi facili da usare con particolare riferimento al perché REST sta diventando così di successo. Panoramica del Business Case Scelte di design collegate ai requisiti di Business Quali sono i fattori che rendono un Web Service facile da usare? Pro e contro di SOAP/WSDL nei confronti di soluzioni RESTful Case Study e lezioni imparate Sessione 7 Perché il Cloud ha bisogno della SOA Frank Greco Il modello di Business del Cloud Computing ha cominciato ad estendersi al di là delle applicazioni semplici come e sta cambiando rapidamente il modo in cui l IT risponde alle domande del Business. Le aziende stanno cominciando a mettere le applicazioni di Business, considerate importanti per le loro operations, nel Cloud. Questo richiede un attenta pianificazione su come queste applicazioni sono architettate per poter ottenere i vantaggi offerti dal Cloud. Inoltre i requisiti di integrazione fra le applicazioni nel Cloud e le applicazioni esterne al Cloud stanno assumendo un ruolo importante in questo scenario. Tutto questo sembra che si sposi bene con i benefici che possono essere ottenuti da una SOA ben pensata. Comunque non basta padroneggiare la SOA bisogna capire i concetti, vantaggi e problematiche del Cloud Computing, lo stato attuale della tecnologia Cloud, gli attori principali che giocano in questo settore e come possiamo fare il mapping fra la SOA e questo ambiente. Una panoramica del Cloud Computing e gli aspetti chiave da considerare Come fare il mapping fra i concetti SOA e quelli del Cloud Tecnologie chiave e principali providers di Cloud Dove può essere applicato oggi il Cloud Computing e nel prossimo futuro Sessione 8 Enterprise Service Bus: quando usarlo e quando evitarlo? David Koosis In passato abbiamo avuto una miriade di tecnologie, tools e approcci di integrazione, anche se distinte e separate. Oggi i vendors propongono una quantità di prodotti che attraversano differenti aree funzionali. Enterprise Service Bus (ESB) per esempio era inizialmente focalizzato sull integrazione delle applicazioni (near Real-Time) oggi si è posizionato come una soluzione one-stop per tutte le Vostre necessità di integrazione. Il cambiamento dello scenario del Middleware e il riposizionamento delle soluzioni dei vendors rendono difficoltoso differenziare le tecnologie e trovare la migliore soluzione per le Vostre necessità. Questa sessione presenta un Case Study che partendo da certi requisiti prospetta diverse potenziali soluzioni: abbiamo veramente la necessità di un ESB o possiamo semplicemente impiegare un tool ETL? O dovremmo confezionare i sistemi come Web Services ed esporli alle altre applicazioni? Allo stesso tempo abbiamo bisogno di tools di integrazione legacy non invasivi per le applicazioni che non possono essere cambiate. Questa sessione esplora l uso e il valore dell Enterprise Service Bus comparato con altri approcci di integrazione. Considera i criteri decisionali che aiutano a riconoscere quando e dove usare un ESB con la minima complessità e il massimo valore. Panoramica dei requisiti di integrazione del Case Study Comparare lo scenario dell integrazione: ETL, messaging più tools add-on, fare Voi stessi con i Web Services, ESB Quando scegliere ESB sulle altre tecnologie La Vostra organizzazione è pronta per lo strumento? Come determinare il punto di taglio della complessità per minimizzare il costo

7 Sessione 9 Servizi senza SOA o SOA senza Servizi? Provate REST! Gerhard Bayer Se SOA è morta qual è l alternativa? Dovremmo costruire le nostre applicazioni di Business basandoci su una Resource Oriented Architecture e abbandonare definitivamente la nozione di servizi? Ma progettare sistemi basati sul concetto di risorse è molto diverso dall implementare servizi e programmare clients che li invocano. Inoltre gli analisti che hanno parlato male di SOA sono ancora in favore dei servizi. Questa sessione discute le differenze fra i due approcci e spiega quali sono i punti di forza e di debolezza. Illustra anche qualche implementazione REST molto popolare che ha avuto largo seguito fra gli sviluppatori che usano questi sistemi. Quale tipo di architettura può essere chiamata RESTful? Quali sono gli inconvenienti di una architettura basata su Web Services puri? Dove REST viene meno e come lavorare attorno ad essa in tipiche architetture applicative Esempi di implementazioni REST di alto profilo La presentazione termina con una panoramica di alcune implementazioni REST di successo come Amazon e Google. Sessione 10 SOA e BPM: il meglio dei due mondi Mike Rosen SOA e BPM vengono spesso menzionati insieme e per buone ragioni. BPM ci aiuta a definire, gestire e monitorare processi di Business mentre SOA fornisce le sottostanti capacità per farlo. Ma come possiamo combinarli in modo da ottenere un risultato che è maggiore della somma delle parti? Quali altri vantaggi si possono ottenere? Noi sappiamo che la tecnologia da sola non risolve i nostri problemi, ma usata in modo intelligente può fornire soluzioni migliori che facilitano e rendono più agile e flessibile il nostro Business. Questa sessione descrive il ruolo di BPM e SOA all interno dell azienda, usando casi di studio, spiega come usarli insieme per massimizzare valore e flessibilità. Capire i ruoli e le relazioni fra BPM e SOA in azienda Capire come il Business Process Modeling è usato per identificare i servizi di Business Capire il ruolo del BAM (Business Activity Monitoring) Conoscere la nuova generazione di Collaborative Business Pocesses Sessione 11 Web 2.0 e SOA: il collegamento mancante Frank Greco Le applicazioni Web sono state tipicamente implementate attraverso un presentation layer basato su HTML che permette ai thin clients di accedere alle applicazioni di Business. SOA non ha cambiato molto, ora abbiamo i servizi, ma il modo di connetterli ai clients rimane lo stesso. Le Rich Internet Applications (RIAs) hanno introdotto una nuova user experience molto simile ad una applicazione desktop, ma dipendono ancora dai limiti dell attuale infrastruttura Internet. Il Web oggi ha bisogno di fornire una completa funzionalità alle applicazioni aziendali usando tutti i vantaggi di una infrastruttura Web sia all interno del firewall che nei centri esterni di Cloud Computing. Molte aziende come Google, Apple, Amazon, Opera, Mozilla, Palm, Oracle/Sun, Microsoft, ecc. stanno andando in questa direzione. Tutto questo cambierà con un nuovo standard che si chiama HTML5. Importanti sessioni di questo standard sono già stati implementati da molti browsers. Questo include nuovi tipi di Web forms, offline caching/database, capabilities grafiche sofisticate e un nuovo protocollo di comunicazione chiamato Web Sockets. Questo fornisce vantaggi di performance di parecchi ordini di grandezza rispetto alle attuali tecniche di comunicazione pseudo Real-Time e permette una vera interazione asincrona fra i clients Web 2.0 e i servizi SOA. Questa sessione discute come i servizi SOA possono interagire con i clients Web 2.0+ usando Web Sockets e altre caratteristiche di HTML5. Introduzione ai concetti base di HTML5 Comparazione fra le caratteristiche di HTML5 e Flash/Flex, Silverlight e Java/JavaFX Best Practices ed esempi di codice per connettere clients Web 2.0+ ai servizi SOA Attributi chiave di Web Sockets e come si comparano con le attuali tecniche di polling Casi d Uso che mostrano il ruolo di HTML5 nel Cloud Computing, includendo la SOA altamente scalabile di EC2 di Amazon e le caratteristiche avanzate di Facebook Strategie per sviluppare servizi Client/Server SOA usando questi strumenti Sessione 12 Come calcolare il ROI per la SOA Max Dolgicer Ci sono molti argomenti a favore e pochi contro, da un punto di vista di engineering, che ci fanno credere che SOA sia un approccio superiore per molti sviluppi applicativi e progetti di integrazione. Ma oggi non bastano brillanti argomenti tecnici per giustificare la transizione a SOA, in molti casi dobbiamo convincere il CFO che c è in definitiva un risultato positivo. Questa sessione presenta un modello di ROI per lo sviluppo applicativo basato sulla riusabilità del servizio in una SOA. Descrive come il costo del riuso può essere calcolato durante il ciclo di sviluppo e manutenzione di un portafoglio di applicazioni Service Oriented di Business. Il modello è basato su metriche che sono ampiamente accettate nell industria IT. Il modello sarà illustrato da un progetto dove applicazioni multiple di Business sono state sviluppate all interno di una SOA che impiega un insieme di servizi riusabili. Panoramica sui processi di Business e del Case Study Considerazioni sulla riusabilità del servizio L ultima linea: statistiche del riuso del codice Definire un modello ROI per il riuso del software Applicare il modello ROI: dalle linee di codice ai soldi risparmiati Mantenere traccia dell efficienza del riuso SOA Conference

8 TECHNOLOGY TRANSFER Piazza Cavour, Roma Tel Fax info@technologytransfer.it