L'implementazione di una Soa va vista come un'evoluzione e non come una rivoluzione. Perché 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. Che consigli dare quindi ai Cio impegnati in questo difficile compito?
" Le regole base sono semplici", spiega Massimo Cazzaniga, Regional Director Southern Europe di Iona. E sono le seguenti:
- 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:
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.
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.
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.
