Veniamo ora ad una questione molto importante, spesso sottovalutata da chi ha il compito di scegliere e gestire piattaforme tecnologiche su cui sviluppare i servizi. Come abbiamo imparato in questa guida la tecnologia J2EE introduce numerosi vantaggi per lo sviluppatore, soprattutto quando quest'ultimo ha preso confidenza con la produzione di software distribuito.
D'altro canto, implementare un servizio che non ha nulla di distribuito e che non trae alcun beneficio dall'introduzione del middleware porta inutili appesantimenti insiti nelle risorse che un application server inevitabilmente consuma (quanto meno per la sua gestione). Per non parlare dello sviluppo e delle operazioni di test che, in ambiente distribuito, hanno sicuramente un impatto diverso rispetto al tradizionale sviluppo object oriented.
A mio avviso, in fase di analisi dei requisiti non funzionali (quindi quando dobbiamo scegliere la piattaforma tecnologica a cui aderire), bisognerebbe tenere a mente i seguenti punti:
- Carico atteso;
- Tempi di sviluppo;
- Manutenzione correttiva;
- Manutenzione evolutiva;
- Accesso a dati aziendali;
- Interfaccia sistemi esterni.
- Portabilità.
Per carico atteso, intendiamo la previsione sul numero di utenti che fruiranno del servizio. Se questo numero è limitato, non ci sarà alcun beneficio dallo sviluppo distribuito. Quando invece il numero è elevato, la gestione delle risorse diventa fondamentale: da considerare inoltre la possibilità di fare dei cluster mantenendo sempre la stessa logica applicativa.
I tempi di sviluppo sono un problema critico. Sviluppare in ambiente enterprise, a regime, porta degli enormi benefici dati dalla presenza del middleware di cui lo sviluppatore non deve preoccuparsi.
Per quanto riguarda la manutenzione correttiva, potrebbero esserci dei pro e dei contro. Come contro, sicuramente la maggiore difficoltà nell'identificare i bug e risolverli. Inoltre, una volta risolti c'è sempre la problematica di sostituire i componenti, quindi operazioni di deploy e di test di integrazione. Come pro, c'è la necessaria identificazione delle unità di sviluppo, che porta già in fase di progettazione un idea modulare del software e quindi ad uno sviluppo che segue una alta coesione delle componenti in gioco.
La manutenzione evolutiva sicuramente trae grossi vantaggi dall'adozione della tecnologia enterprise. Sviluppare nuovi livelli di servizi diventa davvero semplice assemblando i componenti sviluppati in precedenza.
L'accesso ai dati può essere facilmente risolto utilizzando gli Entity Bean CMP. In tal caso sarà facile creare dei servizi ed il relativo accesso ai dati. D'altra parte, la sincronizzazione tra application server e database può essere un collo di bottiglia che rallenta le performance del sistema. Se lo sviluppo trae un indubbio beneficio, le performance, in certi casi possono essere ridotte.
Grazie alla presenza degli application server diventa facile accedere (ed interfacciarsi) a sistemi esterni. Lo abbiamo visto con i web services e con quale relativa semplicità, a partire da uno strato di logica sia possibile esporre dei servizi.
Ultimo, la portabilità di codice scritto per piattaforma J2EE rende immediato il trasferimento da un application server ad un altro con la modifica di alcuni descrittori.
Proprio quest'ultima possibilità è uno dei punti a favore della tecnologia presentata in questa guida. Attraverso delle indicazioni testuali si può modificare il comportamento di una applicazione e dei servizi che la formano, garantendo quindi robustezza ed efficienza allo stesso tempo. Certo, un contesto di sviluppo enterprise porta a delineare un team con skill professionali ben specifici. Chi si occuperà di sviluppo sarà un esperto di un dominio applicativo, chi di deploy avrà una precisa conoscenza dell'application server e il DBA dovrà occuparsi di ottimizzare le problematiche di sincronizzazione tra application server e DBMS.
