Definire e implementare la Soa: dalla teoria alla pratica

Quali sono i reali problemi che un’azienda deve affrontare quando decide di implementare un’architettura orientata ai servizi? Come integrarvi le applicazioni esistenti? Sono alcune delle risposte alle quali risponde Max Dolgicer.

Pubblicato il 25 Apr 2006

mdolgicer-p

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

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati