In uno scenario organizzativo caratterizzato da uno spinto parallelismo delle attività di sviluppo, risolto il task di integrazione a compile time, è necessario affrontare l‘integrazione tecnologica e funzionale dei moduli Java EE sugli ambienti server. In questo articolo cercheremo di dare una panoramica su un‘ipotesi di provisioning server side utilizzando IBM WebSphere Application Server,
Sviluppo parallelo e ambienti di integrazione
Nel presente articolo cominceremo ad analizzare l’utilizzo di IBM WebSphere Application Server, del quale verranno illustrate le principali caratteristiche di funzionamento. Ci soffermeremo su come può essere scalato da una installazione stand-alone, utilizzabile per il test di integrazione di una unità di distribuzione, fino a una complessa architettura federata ad alta disponibilità, tipico ambiente di produzione per applicazioni critiche. Vedremo come, con l’aumentare delle richieste, quest’ultima può essere ulteriormente scalata verticalmente utilizzando le risorse di CPU e di RAM di ciascun calcolatore e/o orizzontalmente aggiungendo nuovi application server alla federazione.
Scenario di sviluppo e di integrazione
Un’organizzazione a linee di sviluppo parallele, caratterizzata da più livelli di parallelismo sia tra unità di distribuzione che all’interno di ciascuna di queste, trova il suo naturale complemento in una organizzazione a più livelli di integrazione. In questo contesto ciascun sviluppatore si occupa dello sviluppo del componente assegnatogli, risolvendo, nel caso in cui non fossero disponibili le implementazioni, eventuali dipendenze verso altri componenti attraverso l’implementazione di mock objects sulla base delle interfacce che, per questi, sono state dichiarate.
Terminate le attività di sviluppo, a test unitario positivo eseguito sulla postazione di sviluppo, ciascun programmatore rilascia il codice sorgente sul repository dell’SCM a partire dal quale viene eseguita la compilazione e l’export dei moduli Java EE. A questo punto è necessario un primo test di integrazione di ciascuna unità di distribuzione con i contributi di tutti coloro che ne hanno realizzato i componenti. I moduli Java EE vengono quindi distribuiti su un application server: è in questo ambiente che vengono integrati tutti i componenti appartenenti all’unità di distribuzione, dove non ci saranno mock object, se non quelli di eventuali dipendenze da altre unità di distribuzione o librerie condivise. Eventuali errori verranno corretti dai programmatori sulle loro workstation ripetendo l’aggiornamento dell’SCM, la compilazione, la distribuzione dei moduli Java EE e il test.
Completata l’integrazione a livello di ciascuna unità di distribuzione il passo successivo è quello di integrare tra loro tutte le unità di distribuzione, distribuendo sull’application server di integrazione i moduli Java EE che hanno superato l’integrazione precedente.
Superata con successo questa fase, il software arriva sull’ambiente di collaudo, dove ne viene verificata l’aderenza alle specifiche funzionali.
Da questa rapida descrizione di questa parte del ciclo di vita del software è evidente la necessità di creare gli ambienti per ciascuno livello di integrazione individuato.
Figura 1 – Ambienti di integrazione
Per leggibilità nella figura sono stati omessi i sistemi di back end quali database relazionali o ambienti legacy. Tipicamente a ciascun ambiente dovrebbe corrisponderne uno, ma con le opportune attenzioni è possibile condividerne uno per i due step di integrazione e uno ciascuno per il collaudo funzionale e per l’esercizio. Importante è mantenere separati “fisicamente” questi ambienti attraverso una opportuna definizione della rete. In questo modo vengono isolati tra loro gli ambienti logici, evitando possibili puntamenti incrociati.
Introduzione a WebSphere
Diamo una rapida panoramica sull’architettura di WebSphere Application Server. Poiche’ si tratta di un argomento molto vasto l’obiettivo che ci prefissiamo è quello di fornire alcune definizioni di sopravvivenza necessarie a comprendere quanto andremo a descrivere con la creazione di una architettura federata di application server.
Architettura di run time di WebSphere application server
Si tratta di un application server che implementa la specifica Java 2 Enterprise Edition 1.4. Senza dilungarci troppo sui livelli relativi alle tecnologie di questa specifica possiamo affermare che è una piattaforma dove distribuire applicazioni Java di livello enterprise orientate ai servizi. Nella figura che segue vengono rappresentate le principali tecnologie Java EE.
Figura 2 – WebSphere Application Server, tecnologie, protocolli e servizi.
La definizione di una istanza di WebSphere viene completata con l’installazione di un HTTP Server esterno in esecuzione su un’altra macchina. Nonostante WebSphere disponga di un proprio server HTTP, questo tipo di configurazione è giustificato da esigenze di sicurezza, scalabilità e gestione del carico. Le prime derivano dall’opportunità di non esporre direttamente un application server sul protocollo HTTP, su questo protocollo l’HTTP server di WebSphere accetterà richieste provenienti solo da un Web Server esterno attraverso il meccanismo di propagazione delle richieste HTTP per tutti i Web Server compatibili con WebSphere. Per quanto riguarda la gestione del carico all’HTTP Server esterno viene demandata la pubblicazione dei contenuti HTTP statici, oltre a limitare il numero di richieste processabili indirizzate a WebSphere.
Di seguito un esempio di una simile configurazione con IBM HTTP Server, per cui alcune delle funzionalità amministrative sono integrate nella console amministrativa di WebSphere.
Figura 3 – WebSphere Application Server e IBM HTTP Server.
Profili di WebSphere Application Server
Ciascuna istanza di application server è definita da un profilo WebSphere che sul file system si concretizza in un due gruppi di file:
- un insieme di file statici o binari (product file) condivisi da ciascuna istanza di application server;
- un insieme di file di configurazione in senso stretto modificabili dall’utente che rappresentano la configurazione dell’istanza di WebSphere in esecuzione (applicazioni installate, adattatori delle risorse, i file di log, ecc).
Ogni profilo in esecuzione con al sua specifica configurazione utilizza quindi gli stessi product file di WebSphere.
I profili possono essere gestiti attraverso il Profile Management Tool, un’applicazione Eclipse-based, oppure da linea di comando attraverso il comando di script manageprofile.
Riportiamo di seguito la rappresentazione sul file system di un profilo all’interno dell’installazione di WebSphere.
Figura 4 – Profilo sul file system di WebSphere Application Server.
Una volta definito un profilo con tutte le definizioni come, per esempio, risorse JDBC, librerie condivise e variabili di ambiente, questo sarà possibile esportarlo verso tutti gli altri ambienti definiti dal ciclo di vita.
Federazione di più istanze di application server. Architettura di esercizio
Un cluster è un raggruppamento logico di istanze di application server in esecuzione su uno o più calcolatori. Dal punto di vista del client il puntamento a questo ambiente è risolto attraverso una URL univoca, il client quindi non ha nessuna evidenza circa la topologia del cluster.
Una architettura di questo tipo viene messa in esercizio con l’obiettivo di avere a disposizione un ambiente di esercizio ad alta disponibilità, capace di gestire fault di sistema senza interrompere il servizio e scalabile al crescere delle richieste di elaborazione. Semplicemente, piuttosto che mandare in esecuzione servizi chiave su un server dedicato, questi vengono eseguiti su più server senza alcun vincolo per il consumer circa la risoluzione dei puntamenti.
Analizziamo come WebSphere Application Server nella versione Network Deployment realizza la federazione di un cluster di application server.
Innanzitutto diamo la definizione di cella di WebSphere: questa rappresenta un dominio amministrativo all’interno del quale il deployment manager, un particolare application server, fornisce l’amministrazione centralizzata di tutte le risorse pubblicate nella cella. La console di amministrazione della cella è in esecuzione nel profilo definito dal deployment manager. Il deployment manager è il processo che gestisce i node agent federati nella cella essendo responsabile del repository della configurazione dell’intero dominio amministrativo. Un nodo rappresenta il raggruppamento logico di più application server gestito da un singolo processo: il node agent.
WebSphere Network Deployment definisce i seguenti tipi di application server:
Application Server
All’Application Server inteso in senso stretto, è delegata l’esecuzione delle applicazioni Java EE. Può essere in esecuzione solo all’interno di un nodo, ma in ciascun nodo possono essere in esecuzione più application server.
Node Agent
Il Node Agent viene creato e installato al momento di federare un nodo in una cella: lavora assieme al deployment manager per eseguire attività amministrative sul nodo.
Deployment Manager
Amministra con una console centralizzata più istanze di application server. Opera con il node agent su ciascun nodo per gestire tutti i server di una topologia distribuita.
Con WebSphere Network Deployment viene anche esteso il concetto di profilo. Vengono introdotte due tipologie in relazione all’elemento del cluster che vogliamo creare.
Application Server
- un profilo di application server rappresenta una istanza WebSphere base;
- un application server in un network deployment può essere eseguito in una cella gestita da un deployment manager come nodo gestito o come server stand alone;
- più profili application server possono essere creati sul singolo calcolatore;
- ciascun application server può essere federato in una cella. Se ci fossero più profili base sullo stesso calcolatore, questi possono essere federati nella stessa cella, in celle diverse o rimanere stand alone.
Deployment Manager
- questo profilo viene usato per creare un processo Deployment Manager;
- può esistere su un calcolatore indipendente;
- può esistere su calcolatori assieme ad altri profili;
- fornisce, nell’ambito di una cella, l’amministrazione centralizzata dei nodi managed di application server e dei custom node;
- fornisce il supporto al clustering, ai meccanismi di caching, al failover e alla gestione del workload.
In figura 5 viene rappresentata l’architettura federata che ci proponiamo di creare e descrivere nei prossimi articoli. Al cluster di failover partecipano i tre application server gestiti nei nodi Node01, NodeC01, Node01.
Figura 5 – Esempio di un’architettura clusterizzata.
Federazione di WAS. Architettura amministrativa
WebSphere viene gestito attraverso una console amministrativa: un’applicazione web distribuita all’interno del suo web container, attraverso un client (sul protocollo SOAP-HTTP o RMI-IIOP) oppure da linea di comando attraverso WSAdmin
untimes ase_profiles in
L’amministrazione di WebSphere si basa sulla tecnologia JMX-Mbeans. JMX è lo standard Java per la gestione della configurazione delle risorse di una applicazione. All’interno di un application server WebSphere c’è un agent JMX e tutti i componenti di sistema sono instrumentati come Mbeans. L’agent JMX supporta i connettori RMI/IIOP e SOAP/HTTP/HTTPS, attraverso i quali è possibile accedere da remoto sulle risorse del server.
Vediamo come questa tecnologia sia necessaria in uno scenario Network Deployment dove abbiamo definito un cluster con più application server. Ciascun application server pubblica una classe Admin Service che, implementando l’interfaccia standard JMX MbeanServer, wrappa l’MBeanServer così da implementare le funzionalità di gestione distribuita della configurazione.
In una installazione stand-alone di WebSphere i server sono amministrati individualmente e ogni client amministrativo si connette direttamente all’application server. In una configurazione Network Deployment, dove esiste una gerarchia di application server all’interno di nodi e gruppi di nodi di una cella, i server di amministrazione esistono a livello di nodo e a livello di cella (deployment manager) e si comportano come punti di aggregazione di servizi amministrativi dei server sottostanti. Gli MBean di tutti i server appartenenti a un nodo sono visibili attraverso il node agent, e tutti gli MBeans in tutti i nodi sono visibili attraverso il deployment manager.
Figura 6 – Amministrazione del Deployment Manager attraverso wsadmin.
/usr/IBM/WebSphere/AppServer/bin/wsadmin.sh -user -password
Federazione di WAS. Flusso amministrativo e sincronizzazione
Ciascun processo application server, node agent e deployment manager va in esecuzione con i propri file di configurazione. Il deployment manager contiene la configurazione master e i file degli applicativi Java EE (EAR o WAR). Ogni modifica apportata a livello di server o node agent sono locali e verranno pertanto sovrascritte dalla configurazione master alla successiva sincronizzazione.
La sincronizzazione dei file dei node agent verso la configurazione master del deployment manager avviene automaticamente (all’avvio o periodicamente), e manualmente (attraverso la console di amministrazione o da linea di comando). In questa fase i node agent verificano i cambiamenti della configurazione master e aggiungono o modificano la configurazione su ciascun nodo.
Nell’immagine di seguito in giallo è rappresentato il flusso di propagazione delle configurazioni dal deployment manager verso i nodi federati.
Figura 8 – Propagazione della configurazione.
HTTP Server
Come illustrato in precedenza, un HTTP Server esterno viene introdotto in un’architettura federata di WebSphere per una più corretta e flessibile gestione della sicurezza, del carico e della scalabilità. Il deployment manager è in grado di gestire diversi tipi di HTTP Server federati alla cella in una topologia costituita da nodi WebSphere cosidetti “managed” e “unmanaged”. Per entrambi i tipi di nodi, il deployment manager gestisce la creazione e propagazione verso gli HTTP Server del file plugin-cfg.xml, che definisce la configurazione del plug-in sviluppato da IBM per il fornitore dell’HTTP Server. I nodi managed utilizzano il node agent per la propagazione della configurazione del deployment manager verso l’HTTP Server, per la modifica del file httpd.conf, e per le operazioni di gestione quali l’avvio e l’arresto dell’HTTP Server. Il responsabile della propagazione del file di configurazione, distribuito nella directory di configurazione, dei plug-in è il servizio di sincronizzazione dei file. I nodi unmanaged possono ospitare esclusivamente web server di tipo IBM HTTP Server, gestiti dal deployment manager attraverso un processo amministrativo dell’HTTP Server di IBM (IBM HTTP Server Admin Service). Per gli altri tipi di HTTP Server i file di configurazione possono essere copiati dalla macchina del deployment manager verso l’HTTP Server.
Virtual host
Il concetto di virtual host è associato alla definizione di una cella federata. I virtual host consentono ad un application server in esecuzione su un singolo calcolatore di apparire come più application server, ciascuno in esecuzione su uno specifico calcolatore. Le risorse associate ad un virtual host non possono condividere dati con risorse associate ad altri virtual host anche sei i virtual host condividono lo stesso application server o lo stesso calcolatore. I virtual host permettono quindi l’isolamento e la gestione indipendente di set multipli di risorse distribuite sullo stesso calcolatore.
La propagazione dei pacchetti HTTP tra il plug-in dell’HTTP Server e il Web Server integrato di un application server WebSphere è gestito attraverso la definizione su quest’ultimo del virtual host verso cui viene fatto il routing delle richieste. In una installazione di default di un deployment manager sono presenti almeno due virtual host: l’admin_host, in ascolto generalmente sulla porta 9060 dove è distribuita l’applicazione web della console amministrativa e il default_host è definito per le applicazioni web distribuite sulla cella. L’alias default_host a cui sono associate le porte di ascolto HTTP degli application server federati nella cella viene dichiarato in fase di deploy dei moduli Java EE. Un esempio di script di deploy in linguaggio JACL è
(-MapWebModToVH {{"IVT Application" ivt_app.war,WEB-INF/web.xml default_host}})
Conclusioni
Abbiamo cominciato a vedere l’Application Server WebSphere, presentandone alcuni aspetti fondamentali e indicando come esso possa essere utilizzato all’interno di uno scenario di sviluppo e di integrazione realistico. Nei prossimi articoli continueremo la trattazione, approfondendo tale scenario e presentando ulteriori aspetti della problematica.
Riferimenti
[1] WebSphere Application Server, Versione 6.1
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
[2] Steve Robinson, WebSphere Tools