Prosegue l’attiività esclusiva di formazione online sul linguaggio Java, in particolare sulla versione 2 Enterprise Edition, pubblicata sul sito di Linea EDP, grazie al contributo, questa volta, di un Senior consultant di ObjectWay. Le immagini citate nell’articolo sono linkate a fondo pagina.
La realizzazione di applicazioni distribuite e multilivello, sta diventando ormai una costante nella maggior parte dei progetti di rilevanza strategica. Conseguentemente coloro che si trovano impegnati nella progettazione, costruzione di applicazioni software, hanno la necessità che queste ultime rispondano a requisiti vincolanti quali:
- La possibilità di distribuire le transazioni di business.
- Il riutilizzo di funzionalità già realizzate.
- Tempi di risposta alla domanda sempre più esigui.
Per poter soddisfare tali requisiti la Java 2 Platform, Enterprise Edition (J2ee) tecnologies ha previsto un approccio incentrato su componenti, in quanto la piattaforma J2ee è stata concepita per permettere la distribuzione di applicazioni basate su una Architettura a Strati.
Tale struttura prevede la possibilità di modellare, implementare e distribuire i componenti (oggetti logici), che realizzano le applicazioni, in base alle funzionalità per cui sono stati realizzati, in maniera assolutamente indipendente l’uno dall’altro.
Naturalmente per soddisfare tali esigenze si è reso necessario il rilascio di una serie di librerie (Api), basate anch’esse su una organizzazione a strati.
Questa suddivisione ne facilita la comprensione e la assimilazione ed inoltre permette di individuare in maniera semplice il contesto di utilizzo.
Di seguito sono riportate una serie di figure che permettono di avere una rappresentazione grafica della struttura delle librerie (Vedi fig. 01), di una possibile architettura a strati (Vedi fig. 02) ed il mapping tra tipologia dei componente e la relativa libreria da utilizzare (Vedi fig. 03).
Nel corso di questo articolo analizzeremo a grandi linee le opportunità derivanti da tale architettura e lo scheletro della medesima.
Applicazioni transazionali distribuite
La sempre più frequente richiesta da parte delle società di poter suddividere i componenti, in base alla funzione logica che realizzano, di poterli inoltre installare in ambienti differenti, con caratteristiche dal punto di vista software ed hardware diverse, ha reso necessario la creazione di un modello applicativo distribuito. Tale modello, in una applicazione di Business, che è J2ee compliant, è rappresentato e realizzato mediante una struttura a tre strati funzionali.
Un’architettura così pensata prevede:
- una sezione logica dedicata ai Client, avvero a tutte quelle funzioni applicative desktop e/o web che forniscono input e richiedono output e che quindi permettono una interazione continua con l’utente finale.
- una sezione logica dedicata alle operazioni di business, ovvero a tutte quelle funzioni applicative server che permettono la realizzazione dei processi (flussi di business).
- una sezione logica dedicata alle operazioni di persistenza, ovvero a tutte quelle funzioni applicative server che interagendo con i Data Base garantiscono il continuo allineamento dei dati e la loro persistenza (flussi di persistenza).
Tale configurazione logica può essere riprodotta in una configurazione ad N-Strati dal punto di vista della distribuzione dei componenti (Vedi fig. 04).
Componenti riutilizzabili
I vantaggi apportati dal mapping sono notevoli e si evidenziano nella rilocazione dei componenti, senza la necessità di effettuare alcuna modifica nel codice durante la fase di porting.
Di conseguenza, nell’enorme riutilizzo di interi "pezzi di codice" o per meglio dire di "funzionalità", i vantaggi sono enormi dal punto di vista della riduzione dei costi e dei tempi di risposta alla domanda.
Inoltre la logica funzionale che il componente deve realizzare diventa il fattore discriminante di una serie di proprietà quali:
- la definizione del ruolo. Vengono definite in maniera univoca le operazioni e le funzionalità che tali oggetti devono eseguire.
- la velocità di realizzazione: Sono ridotte al minimo le probabilità di possibili errori nella valutazione dei costi del progetto.
- la locazione fisica: Vengono definiti i contesti in cui operano i componenti che devono realizzare l’applicazione.
Proviamo quindi a descrivere tali componenti raggruppandoli in base allo strato funzionale che essi assumono in una architettura 3-Tier.
Client
I client vengono differenziati in base al tipo di applicazione che devono interfacciare; nel nostro specifico caso poiché stiamo trattando le applicazioni internet e di e-commerce la nostra attenzione si rivolge verso i WebClient.
Questi sono essenzialmente implementati tramite la tecnologia Jsp (Java Server Page) e Servlet.
Tale tecnologia ci permette di poter scrivere in java alcune funzioni logiche e nello stesso tempo ci consente la visualizzazione delle informazione di input e output che abbiamo rispettivamente utilizzato ed ottenuto.
Un WebClient è molto spesso anche chiamato un "thin client", in quanto le sue funzioni logiche sono esclusivamente relative all’acquisizione di informazioni ed alla restituzione di informazioni, uguali o diverse che siano; tutto quello che è relativo a funzioni più complesse, come interazione con Data Base, elaborazioni di regole di business, connessioni con sistemi di legacy, è rimandato ad altri componenti.
Molte volte il protocollo di comunicazione tra i Thin Client e i componenti logici più complessi è realizzato tramite una tecnologia particolare chiamata JavaBeans.
I JavaBeans sono oggetti che prevedono una serie di attributi con modalità di accesso "private" e i relativi metodi set e get con modalità di accesso "public"per la loro gestione. Naturalmente è possibile inserire all’interno di tali componenti ulteriori metodi funzionali, tale possibilità è lasciata a discrezione del programmatore.
La locazione fisica dei componenti JavaBean, Jsp e Servlet sono i Web Server.
Componenti di Business e di Persistenza
La realizzazione delle regole che risolvono le necessità di un particolare dominio, quale potrebbe essere quello bancario o finanziario, sono implementate mediante la tecnologia Enterprise JavaBeans (Ejb).
Questo tipo di tecnologia permette di risolvere i problemi relativi sia al "flusso di business che al "flusso di persistenza". Infatti facilita enormemente il lavoro del team di sviluppo sia dal punto di vista analitico concettuale che realizzativo, permettendo quindi a quest’ultimo di concentrare esclusivamente le sue risorse su che cosa una applicazione deve realizzare ovvero sul Business Case.
Tale vantaggio è dovuto alla possibilità di relegare al Server la responsabilità di gestire la logica puramente transazionale; logica che si viene a creare tra i vari elementi che realizzano le regole e al tempo stesso tra quest’ultimi e il Data Base per il continuo allineamento dei dati persistenti.
La locazione fisica di tali componenti sono gli Application Server
Vantaggi
Possiamo affermare che gestire in maniera indipendente le problematiche inerenti i vari componenti, che realizzano una applicazione, ha permesso ai designer, che utilizzano la piattaforma J2ee, di poter raggiungere alcuni obiettivi ormai di primaria importanza nel mondo informatico attuale, obbiettivi che hanno reso questa tecnologia leader di riferimento.
Come gia anticipato precedentemente questi sono:
- Estendibilità e Manutenzione. Diventa molto semplice aggiungere nuove funzionalità o modificarne di già presenti, senza avere un impatto invasivo sul codice preesistente, data la struttura ad "oggetti" e la definizione dei ruoli di questi all’interno dell’applicazione.
- Divisione del lavoro in base allo skill. È noto che non tutti i partecipanti ad un Team di sviluppo abbiano le medesime conoscenze; questo in passato poteva essere un problema nella definizione delle competenze all’interno di un progetto; invece l’utilizzo di J2ee permette di assegnare "al posto giusto la persona giusta".
- Riutilizzo del codice. Poiché realizzando una applicazione si realizzano componenti che rispettano i business case, esiste la concreta possibilità di riutilizzo di componenti, nel caso si debbano realizzare i medesimi business case.
- Interoperabilità: Questa piattaforma dà la possibilità di poter operare con altri sistemi informativi o legacy in maniera semplice; in quanto implementare il "protocollo" di comunicazione viene ad avere una difficoltà paragonabile a quella che viene riscontrata nell’implementazione di un componente interno qualsiasi, data la semplicità di utilizzo delle Api J2ee dedicate alla comunicazione con sistemi esterni.
Inoltre tramite questa piattaforma è possibile integrare in maniera semplice e veloce tecnologie oramai di riferimento per la scambio di informazioni tra le applicazioni quali Xml e i Web Service. Infatti al suo interno sono contenute una serie di librerie che permettono di leggere, modellare, e modificare documenti Xml e di poter gestire il protocollo Soap.
Criticità
Naturalmente questo tipo di vantaggi porta si ad una semplificazione della scrittura del codice e ad una notevole riduzione dei tempi di implementazione e manutenzione con una sensibile riduzione dei costi; ma è importante tenere sempre presente a mente che la fase critica di un progetto ora non è più la "mera fase di sviluppo" bensì la "mera fase di progettazione" in cui ogni scelta condiziona pesantemente le sorti di una applicazione.
Infatti una scelta errata può rendere una applicazione complessa, poco mantenibile, pesante dal punto di vista delle performance e soprattutto relativamente distribuibile.
Quindi nel costruire un "progetto" bisogna sempre tenere conto che i componenti che si andranno a realizzare devono svolgere ruoli ben precisi, che ogni componente ha un suo ruolo ed uno solo, ed inoltre che ogni tecnologia utilizzata ha un suo ambito dei definizione che ne accresce le potenzialità.
Di seguito viene riportata la struttura di una possibile architettura da utilizzare come riferimento e punto di partenza per futuri progetti (Vedi fig. 05).
Tale struttura risponde ad una organizzazione Model View Control (Mvc) dei componenti, organizzazione che rispetta le specifiche rilasciate da Sun (Vedi fig. 06).
