Affrontare progetti di tipo Enterprise significa spesso misurarsi anche con strutture aziendali di grandi dimensioni e con alcuni approcci ‘tradizionali’ ormai consolidatisi negli anni. L’obiettivo di questo articolo è proporre un approccio alternativo al mondo Enterprise che sia semplice, essenziale, orientato agli obiettivi; in una parola: agile.
Enterprise: come interpretare il termine?
Molti sviluppatori, a un certo punto della loro carriera, si ritrovano nel mondo Java Enterprise. La parola “Enterprise” può evocare diversi tipi di reazioni: spesso propone sfide tecniche interessanti da affrontare in un ambiente di lavoro complesso, incline a malfunzionamenti e che richiede un notevole sforzo per la gestione della manutenzione e della sua evoluzione.
Spesso i problemi che si riscontrano in grandi progetti sono dovuti alla gestione; ma in tanti altri casi sono gli sviluppatori che prendono decisioni sbagliate, le quali portano inevitabilmente alla creazione di software terribile. E tutto questo… per un “atto di fede” all’Enterprise. L’obiettivo di questo articolo è proporre un approccio al mondo Enterprise che sia semplice, essenziale, orientato agli obiettivi; in una parola: agile.
Caratteristiche dei progetti Enterprise
È importante anzitutto fare chiarezza su che cosa si intenda per Enterprise. Un tipico progetto enterprise ha queste caratteristiche:
- solitamente si trova all’interno di un ambiente aziendale grande;
- vi sono più livelli di gestione/direzione coinvolti;
- c’è una preferenza per soluzioni proposte da large vendors (Red Hat, IBM, Microsoft, etc.);
- c’è una preferenza per prodotti e standard che siano già ben noti e consolidati, anche se qualche volta poi si rivelano inadeguati;
- il focus è concentrato su tematiche tipiche di scenari grandi (Enterprise appunto) come fault-tolerance, transazionalità, sicurezza, scalabilità, performance.
Ora che abbiamo definito il tipo di progetto di cui stiamo parlando, vediamo quale forma può assumere.
Il tipico progetto Java Enterprise
Potrebbe essere utile avere un esempio di riferimento: pensiamo a una piattaforma di e-commerce con alcune funzionalità B2B. Di seguito, vediamo per sommi capi come potrebbe presentarsi lo scenario tecnologico, perch��� questo ci aiuta a delineare meglio l’ambito in cui ci muoviamo e a sostenere le ragioni per le scelte che proporremo.
EJB3, JPA, JSF
Queste tecnologie costituiscono uno standard molto diffuso per la gestione di logica di business, persistenza e livello di presentazione. È una combinazione di specifiche e tecnologie sicura.
SOAP
SOAP è uno standard consolidato nella comunicazione di servizi web. Definisce il funzionamento di aspetti critici quali la sicurezza. Anche questa rappresenta una scelta sicura.
JMS Message-Driven Beans
JMS MDB per disaccoppiare i sottosistemi è adatto a una piattaforma, offre affidabilità e bilanciamento di carico.
Quartz
Quartz è adatto per il job-scheduling: una scelta sicura semplicemente perchè è molto diffuso.
JBoss
Il deploy avviene generalmente su JBoss, application server open source supportato da una grande azienda che fornisce canali per il supporto a pagamento.
Quali criteri per lo stack tecnologico enterprise?
Il problema con un progetto di questo tipo non è necessariamente nelle singole tecnologie selezionate; il vero problema è il criterio con il quale vengono fatte le scelte e quali sono le motivazioni dietro l’utilizzo di determinate tecnologie.
Lo stack tecnologico “usuale”, appena illustrato, è notoriamente più difficile da gestire e da far funzionare rispetto ad altri. Lo sviluppo andrà a regime in più tempo, sarà più difficile apportare cambiamenti in rapporto all’evoluzione dei requisiti. Il progetto risulterà, così, più complesso rispetto ad altre possibili soluzioni.
Processo decisionale Enterprise
Quando si tratta di fare delle scelte, gli obiettivi sui quali solitamente un progetto di questo tipo si focalizza sono basso rischio, aderenza agli standard, supporto tecnico anche a pagamento, adattabilità agli sviluppi futuri. Vediamoli un po’ più in dettaglio, mettendo in luce anche eventuali limiti di questi obiettivi.
Basso rischio tecnologico
Ricercare il rischio tecnologico più basso si traduce il più delle volte nel fare scelte rassicuranti, quelle che sembrino garantire di non avere conseguenze negative a lungo termine, senza esplorare eventuali alternative migliori.
Adesione agli standard
Gli standard sono importanti, ma possono diventare un’ossessione… e spesso si finisce per preferire certe specifiche solo perchè sono ben definite, come EJB3 o SOAP, invece di scegliere la soluzione più semplice per lavorare in modo efficace.
Supporto tecnico a pagamento
Il supporto tecnico riveste un ruolo cruciale e se occorre pagarlo, è un costo che si affronta volentieri. Però occorre valutare bene, poichè “a pagamento” non sempre è sicura garanzia per quanto riguarda la qualità o tempestività delle risposte.
Adattabilità per i requisiti futuri
Quando si affronta un nuovo progetto, si punta alla definizione di uno schema architetturale e all’adozione di uno stack tecnologico che rispondano alle esigenze attuali, ma che al contempo permettano una facile evoluzione e un adattamento a nuovi requisiti sconosciuti al momento in cui si inizia il progetto: l’approccio è corretto e sensato, ma in vari casi è onestamente difficile da perseguire nel concreto.
Tutti questi obiettivi hanno le loro ragioni e di per sè non sono sbagliati, ma tendono a offuscare le vere finalità di un progetto software. Infatti, gli obiettivi primari di tutti i progetti software consistono nel consegnare un progetto:
- nel tempo prefissato;
- che soddisfi i requisiti;
- che sia affidabile e robusto;
- che abbia buone prestazioni;
- che sia facile da mantenere ed estendere.
Questi dovrebbero essere i fattori decisionali su cui focalizzarsi per un progetto software, piccolo o grande che sia. È ovvio che, per fare delle scelte, occorrerà tener conto anche di altre eventuali particolari esigenze della struttura aziendale; ma fondamentalmente una buona scelta si applica a tutti i tipi di organizzazione.
Quindi, se dovessimo reimmaginare il nostro progetto tenendo in mente questi ultimi obiettivi, cosa potremmo adottare?
Un progetto enterprise “leggero”
Una premessa doverosa: non voglio sostenere che le tecnologie che proporrò siano migliori delle precedenti. Il mondo Java offre una miriade di soluzioni e ogni strumento deve essere valutato in base alle proprie esigenze. E sia chiaro che, in certi contesti specifici, anche questo stack potrebbe avere i suoi svantaggi: come sempre, occorre valutare puntualmente il particolare ambito aziendale e progettuale in cui si mettono le mani.
Intendo piuttosto presentare un esempio di stack tecnologico alternativo al precedente, con una motivazione per ogni scelta. Questo per dimostrare che è possibile creare sistemi enterprise semplici e ben progettati senza sottostare a scelte in alcuni casi inopportune, ma che vengono comunque adottate per svariate ragioni (rapporti con i fornitori consueti, “policy” aziendali pregresse, “tradizionalismo” o, semplicemente, mancanza di conoscenze alternative). La semplicità unita a un processo adeguato si declina in efficienza, qualità, rapidità di risposta all’evoluzione dei requisiti e riduzione dei costi.
Vediamo quindi, nei vari componenti, lo stack tecnologico alternativo suggerito.
Spring
Oltre alla dependency injection, Spring gestisce transazioni e sicurezza in modo più semplice rispetto agli EJB, liberandoci anche dalla necessità di utilizzare application server Java EE (come JBoss, Glassfish o WebSphere).
Spring MVC + Thymeleaf o un framework JavaScript
Spring MVC implementa il classico pattern Model-View-Controller in modo esemplare, permette facilmente di costruire ed esporre servizi REST, di centralizzare la gestione delle eccezioni e di testare agilmente il tutto.
Thymeleaf basa i suoi template sugli attributi e non sugli elementi (diversamente da JSP). Questa caratteristica gli permette di produrre un vero e proprio file HTML, che potrà essere visualizzato immediatamente su browser garantendo una fase di prototipazione veloce e agevolando la collaborazione tra sviluppatore e web designer.
Sia Spring MVC che Thymeleaf hanno una storia ed una evoluzione stabile, molte risorse a disposizione e consentono uno sviluppo rapido e flessibile.
Utilizzare invece un framework JavaScript al posto di Thymeleaf è una scelta che permette di portare il livello di presentazione completamente al lato client, consentendo quindi di ottenere alti livelli di User eXperience. L’ecosistema JavaScript ha subito una forte evoluzione negli ultimi anni: adesso è possibile creare fat-client su browser riutilizzando concetti di design comprovati negli anni da framework lato server come l’MVC con AngularJS, l’event bus per la gestione disaccoppiata degli eventi (presente in ExtJS) e di adottare TDD con ambienti di continuous integration (YUI-Test, Karma, JS-Test-Driver, etc.).
jOOQ
Per il livello di persistenza, scegliamo jOOQ: permette di gestire le performance con una granularità più fine, mantiene un’interazione semplice con il DataBase, alleviando le controindicazioni dell’Object Relational Impedance Mismatch.
REST + Jackson JSON Processor
REST e JSON sono entrambi popolari perchè facili da usare e comprendere, poco costosi da sviluppare, usano standard semplici e sono familiari agli sviluppatori. Il lock-in non è più un problema: possiamo facilmente cambiare un JSON processor con un altro, senza molte difficoltà, diversamente da quanto avviene con SOAP.
REST è il paradigma nativo del web, promuove una architettura distribuita dinamica (HATEOAS) e disaccoppiata, senza aggiungere sovrastrutture non necessarie.
La specifica SOAP è indipendente dal livello di trasporto, per questo motivo ha una specifica dedicata alla sicurezza. REST assume che il livello di trasporto è HTTP (o HTTPS), e dispone quindi dei meccanismi già presenti nel protocollo: la sicurezza può essere facilmente gestita con SSL e basic authentication.
Esistono inoltre dei tool come Swagger per documentare le nostre REST API e due possibili tecniche di versionamento (URL versioning e HTTP header versioning).
JMS con messaggi JSON su Active MQ
La gestione della messaggistica può essere risolta con JMS con messaggi JSON su ActiveMQ, ottenendo accoppiamento lasco, robustezza e bilanciamento di carico, senza il fastidio dell’ essere vincolati ai Message-Driven Beans.
Obsidian Scheduler
Per il job scheduling una possibile alternativa al classico Quartz è Obsidian Scheduler: è semplice da usare, ha una interfaccia utente adeguata e possiede funzionalità avanzate.
Tomcat
Il deploy, adesso che ci siamo liberati dagli EJB, può essere effettuato su Tomcat, un semplice servlet container senza funzioni proprietarie. Ci aiuta a seguire gli standard, a evitare problemi di aggiornamento e ad aumentare quindi la manutenibilità. Chi ha bisogno di supporto SLA quando non si incorre continuamente in malfunzionamenti?
Penso che questo stack, e le motivazioni per la sua scelta fornite qui sopra, aiutino a dare un’idea di che forma possa assumere un progetto enterprise se approcciato da un punto di vista sanamente alternativo. L’idea è mostrare che anche un progetto enterprise può essere semplice e facilmente integrato, e che framework e piattaforme “pesanti” non sono sempre necessari ma anzi offrono benefici tangibili solo in rare occasioni.
Si potrebbe tuttavia pensare, che oltre un certo grado di complessità e dimensioni, risulti comunque più opportuno l’uso di stack “pesanti”. Eppure, ultimamente è emersa una tendenza architetturale detta microservices (o anche fine-grained SOA) che configura lo sviluppo di applicazioni come un insieme di piccoli servizi indipendentemente deployabili e scalabili, che comunicano usando protocolli semplici come REST piuttosto che quelli complessi come WS-Choreography, BPEL oppure tool centralizzati come ESB. Questo stile architetturale è rivolto ad ambienti grandi e complessi e si sposa naturalmente con l’adozione di stack tecnologici “leggeri”.
Conclusioni
Gli ultimi trend architetturali e tecnologici come REST prendono sempre più piede nel mondo Enterprise. Sempre più sviluppatori stanno prendendo atto che la semplicità porta a soluzioni affidabili ed efficaci dal punto di vista dei costi, posto che le tecnologie scelte soddisfino i requisiti di performance, sicurezza, scalabilità etc. del progetto.
Il mondo del software si muove rapidamente, e ci sono segnali promettenti che indicano che la direzione giusta da seguire è proprio quella dell’Enterprise “leggero”.
Riferimenti
[1] Carey Flichel, “Java Enterprise Software Versus What it Should Be”
http://java.dzone.com/articles/java-enterprise-software
[2] An Introduction to the Enterprise JavaBeans 3.0 (EJB 3) Specification
http://www.oracle.com/technetwork/articles/entarch/ejb-3-085455.html
[3] Andrea Como, “L’alternativa a Java EE: come implementare lo stack JSF+Spring+Hibernate con Java SE e Tomcat – Parte I”
[4] The Java EE 6 Tutorial
http://docs.oracle.com/javaee/6/tutorial/doc/gipko.html
[5] La voce SOAP su Wikipedia
http://en.wikipedia.org/wiki/SOAP
[6] La voce WS-Security su Wikipedia
http://en.wikipedia.org/wiki/WS-Security
[7] Quartz, job scheduler
[8] JBoss, application server
[9] Web MVC framework
http://docs.spring.io/spring/docs/4.0.x/spring-framework-reference/html/mvc.html
[10] Designing and Implementing RESTful Web Services with Spring
https://spring.io/guides/tutorials/rest/4/
[11] Exception Handling in Spring MVC
http://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc
[12] Thymeleaf
[13] AngularJS
[14] ExtJS
http://www.sencha.com/products/extjs/
[15] YUI test
http://yuilibrary.com/yui/docs/test/
[16] Karma
http://karma-runner.github.io/0.12/index.html
[17] js-test-driver
https://code.google.com/p/js-test-driver/
[18] La voce REST su Wikipedia
http://it.wikipedia.org/wiki/Representational_State_Transfer
[19] Jackson
https://github.com/FasterXML/jackson
[20] Swagger
https://helloreverb.com/developers/swagger
[21] jOOQ
[22] La voce Object Relational Impedance Mismatch su Wikipedia
http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch
[23] ActiveMQ
[24] Apache Tomcat
[25] Obsdian Scheduler
[26] Martin Fowler, “Microservices”
http://martinfowler.com/articles/microservices.html