ROMA – Max Dolgicer, direttore (e fondatore) di International Systems Group, Inc.(www.isg-inc.com), società newyorkese di consulenza in tecnologie middleware, è una riconosciuta autorità nel computing distribuito. Il seminario da lui tenuto a Roma di recente, nell’ambito dei programmi di www.technologytransfer.it, è un percorso strutturato che dalla definizione di valore per l’impresa della Soa, porta a una prospettiva implementativa sulle piattaforme disponibili (J2ee, .Net e open source), in cui le applicazioni composite si devono sviluppare. Max Dolgicer vede le aziende entrare con la Soa “nell’era dell’ingegnerizzazione dei servizi slegati dall’ambiente del fruitore”. Prevede anche che i servizi asincroni della Soa (basati sull’Enterprise Service Bus o Esb), portino al declino degli Integration Broker (CHI SONO? NON TROVO DINO PER CHIEDERGLIELO). Per fronteggiare l’inevitabile transizione organizzativa, raccomanda l’istituzione di un Enterprise Architecture Group (Eag).
ZeroUno: In che misura una Soa deve esser consapevole dei diversi ambienti operativi? E in particolare è dipendente da piattaforme di sviluppo basate sui componenti?
Dolgicer: Nel seminario parlo del livello implementativo perché la Soa si basa sui servizi Web e standard che utilizzano gli standard Xml, Soap e Wsdl, ormai “universali”, ma occorre pur sempre una piattaforma di sviluppo in un dato ambiente, dal cui punto di vista i servizi Web sono una “façade” che serve in sostanza a render poi lasco il legame dei servizi prodotti. A questa indipendenza dall’ambiente non si era arrivati né con Corba, né con le famiglie Com, .Net e J2ee dove resta lo stesso cruciale inventariare le specificità implementative su una data piattaforma, per rendere il più riusabile e portabile il codice associato al servizio. Dunque si guarda alle due piattaforme prevalenti, J2ee e .Net (oggi un 40% e un 25% rispettivamente, col resto ancora “legacy”) e alle piattaforme dei vari Integration Broker, per esempio Tibco. C’è poi la recente tendenza a vedere l’architettura orientata ai servizi non più legata per forza a una piattaforma capace di eseguire codice sviluppato per componenti, ma realizzabile anche con software open source; o addirittura con eseguibili non sviluppati sul client ma scaricati dal server: in quest’ottica Internet stessa diventa piattaforma per applicazioni business basate su Soa. Questa “dilatazione” delle piattaforme per applicazioni Soa potrebbe portare a licenze non più gratuite, che essenzialmente disaccoppiano il servizio di business dai vari ambienti client fruitori. Sono in piena corsa per proporsi come piattaforma Soa al proprio ecosistema anche Sap e Oracle Fusion, oltre a Ibm e Bea, tutti di provenienza J2ee, e naturalmente Microsoft.
ZeroUno: Nell’Implementazione pratica della Soa, lei sottolinea un dualismo fra Enterprise Service Bus e Integration Broker…
Dolgicer: Se è vero che anche i vendor più tecnologici standardizzano ormai su servizi Web, il ruolo degli Integration Broker, che realizzano grandi progetti Eai di applicazioni pacchetto con l’uso di diversi adattatori è destinato a diventare marginale nel tempo. Per quanto riguarda l’Esb, il mercato cresce, ma è difficile articolare in modo succinto quali sono i vantaggi: l’Esb è costruito dalla base su standard (servizi Web resi sicuri e scalabili), che però gli Ib li supportano “ex-post.” Alla fine gli Esb hanno dalla loro il momento di marketing, la facilità d’offerta di adapter “out-of-the box” (gli Ib devono supportare adapter per ogni possibile pacchetto applicativo, in qualunque settore) e soprattutto la predisposizione nativa a supportare servizi asincroni. Ibm e Bea si muovono per rilasciare il “loro” Esb basato su proprie tecnologie derivate dalle rispettive corazzate a base J2ee, Websphere e e Weblogic. [E ora anche Sun con Seebeyond, ndr].
ZeroUno: Cosa significa e/o implica la Service Oriented Development Architecture (Soda)?
Dolgicer: È l’approccio di “architettare in termini di servizi” con cui vanno pensate le nuove applicazioni, rimandando a una seconda iterazione oggetti, metodi, o modalità per invocare gli stessi servizi. Soda va a braccetto con l’Event & Service Oriented Architecture (E-Soa). La E-Soa non è altro che la generalizzazione di Soa, da insieme di servizi “sincroni”, sollecitati da richieste del client, a servizi anche “asincroni”, reattivi anche a un evento, oppure a stringhe di eventi, secondo regole. Alla fine la Soa non è davvero altro che il vecchio Cient/Server, solo rinato con un’Event Driven Architecture (Eda) per costituire assieme la “Enterprise Architecture” (Ea) tout-court, e farla funzionare da Real time enterprise. La doppia natura della causa scatenante (Richiesta o Evento) è irrilevante: un servizio è un servizio, indipendentemente se richiesto o se suscitato da (una combinazione di) eventi. (PERSONALMENTE TOGLIEREI TUTTA QUESTA PARTE PERCHE’ DA QUEL POCO CHE NE CAPISCO MI SEMBRA VERAMENTE UNA PIPPA)
ZeroUno: Quali le Best Practice per la trasformazione in chiave Soa delle Applicazioni Business e come si deve affrontare la transizione?
Dolgicer: È centrale definire un Gruppo Architetturale di livello Enterprise (Eag), responsabile di definire l’Enterprise Architecture, decidere standard (quali piattaforme adattare alla Soa e quali no) e realizzare “framework di utilità”, come servizi di sicurezza, jogging ecc.. L’Eag non risponde delle applicazioni business, al massimo delega suoi membri ad effettuare controlli di conformità e a garantire supporto produttivo nei vari progetti. L’idea è di una cipolla con al centro l’Eag e gli strati esterni costituiti dalle applicazioni delle linee di business: ogni linea di business ha una sua architettura applicativa, sottoinsieme dell’Enterprise Architecture, di cui l’Eag è l’unico depositario e responsabile dell’orientamento verso i servizi. Un processo collaborativo fra Eag e le varie linee di business garantisce l’allineamento architetturale delle implementazioni. Non si nascondono le difficoltà organizzative: chi paga l’investimento, a chi riporta l’Eag, quali regole di business deve rispettare e come si adatta a inevitabili evoluzioni. Gli impatti organizzativi vanno indirizzati strada facendo: comunque, per la transizione alla Soa il primo passo è l’Eag.
Scarica un estratto del seminario Max Dolgicer Implementazione pratica della Soa
