L’Abc per creare un’architettura orientata ai servizi: approccio incrementale, endpoint intelligenti e neutralità tecnologica.
In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.
Le Soa sono un’evoluzione, non una rivoluzione. Se può essere allettante partire con la visione di processi di business orchestrati senza sforzo alcuno da una semplice interfaccia di tipo point-and-click, la realtà ci dice che la maggior parte degli ambienti It dispone già di importanti asset, ed ha processi complessi che non possono essere interrotti. Il passaggio a una visione point-and-click si basa su una solida base tecnologica a servizi, basata su standard e adattabile alle realtà di ambienti e attività It già esistenti.
Le regole base sono semplici: adottare un approccio incrementale, creare endpoint intelligenti, dinamici e adattabili, rimanere neutrali rispetto alla tecnologia.
Adottare un approccio incrementale
È importante adottare un approccio incrementale alle Soa, sia a livello tecnico che finanziario. Quando gli architetti prendono in esame le funzionalità necessarie per supportare una Soa, tra cui trasporto, trasformazione, sicurezza e gestione, vedono che molto di quello che serve è già disponibile.
Si possono evitare grandi investimenti iniziali, e invece lavorare con cosa è già stato installato, e pagato:
Step 1 – usare componenti di infrastruttura esistenti. Non è necessario sostituire sistemi esistenti, cosa che può creare significative interruzioni dell’operatività e generare errori. Molto meglio è mantenere i sistemi di trasporto, sicurezza e gestione che già si hanno in casa, ed incorporarli in una Soa.
Step 2 – abilitare gradualmente i sistemi di backend ai servizi. E’ saggio partire con un progetto che dia un ritorno misurabile e rischi di business limitati, e pian piano abilitare ai servizi i diversi sistemi, dai mainframe di backend ai dispositvi mobili, per creare gradualmente una rete di servizi.
Step 3 – aggiungere gradatamente QoS. Il supporto a nuove tecnologie e servizi di integrazione, quali sicurezza, enterprise management e alta disponibilità, può essere aggiunto gradatamente, sulla base delle necessità che si verificano, senza la necessità di implementare tutte le feature dell’inizio.
Creare endpoint intelligenti, dinamici e adattabili
È fondamentale prendere in esame l’estensibilità di tutti i nuovi investimenti sull’infrastruttura. Gli endpoint di ogni servizio possono evolvere indipendentemente dagli altri, evitando che le modifiche vengano forzatamente concentrate in un server, o hub, centralizzato. Trasformazione, sicurezza, protocolli di trasporto e gestione dei servizi possono essere aggiunti in maniera graduale e dinamica man mano che se ne verifica la necessità.
I team di sviluppo possono usare i plug-in per operare:
Nuovi QoS e policy enterprise – le nuove policy, comprese misure legate a sicurezza e gestione, sono governate da plug-in presso l’endpoint. Questo elimina la necessità di creare nuovi server o stack tecnologici.
Nuovi sistemi – man mano che i sistemi aggiuntivi vanno online, spesso introducono nuove interfacce e requisiti unici che mettono a dura prova le infrastrutture meno flessibili. I plug-in garantiscono una compatibilità locale, che non impatta sugli altri team di sviluppo.
Nuovi standard e nuove tecnologie – esisteranno sempre nuovi modelli di dati, nuovi protocolli o nuovi prodotti di infrastruttura che comportano modifiche al middleware. Piuttosto che aggiungere un nuovo livello di adapter, i plug-in permettono all’infrastruttura di supportare efficacemente questi nuovi requisiti.
Rimanere neutrali rispetto alla tecnologia
Una Soa non si costruisce su una sola tecnologia, per cui è importante che ogni servizio sia compatibile con tutte le piattaforme , i protocolli, i modelli di dati e di trasporto, esistenti o futuri. Gli architetti It non devono obbligare i loro sviluppatori a standardizzare su un singolo set di tecnologie o ad implementare lo stesso middleware su ogni endpoint di servizio.
Scegliendo plug-in agli endpoint al posto di un server centralizzato, l’It può dare il suo contributo.
La maggior parte delle aziende ha già in produzione un sistema di trasporto, e una sua sostituzione radicare metterebbe a rischio la continuità delle attività. I plug-in sono in grado di supportare ogni sistema di trasporto.
La maggior parte delle transazioni Soa sono di tipo “fire and forget”, ma molte transazioni enterprise richiedono affidabilità Acid a 2 fasi, ed altre ancora richiedono le prestazioni di una connessione punto-a-punto. I plug-in di gestione delle transazioni supportano ogni tipo di transazione, in modo che le aziende non debbano più dover decidere tra una buona architettura e necessità applicative.
Xml ha molte qualità utili, ma obbligare le applicazioni a convertire i loro dati in Xml può provocare errori. I plug-in permettono di spedire i dati in ogni formato, compresi quelli binari, con la semplice aggiunta di un plug-in a ogni endpoint chiamata a ricevere il payload.
Per preservare ulteriormente l’autonomia dei sistemi di back-end, ogni standard di sicurezza, ogni suite di system management e ogni piattaforma di sviluppo viene supportata a livello di endpoint individuale, piuttosto che obbligare tutte le applicazioni a seguire la stessa configurazione.
Ogni piattaforma, compresi mainframe, piattaforme e container Java, deve essere in grado di partecipare a tutti i processi allo stesso livello.
Questi principi guideranno alla costruzione di una Soa efficace, ed alla creazione di numerose soluzioni differenti.
(*) Regional Director Southern Europe Iona
