Installeremo la versione standalone di OC4J, ovvero quella in cui verrà installata  una singola istanza di OC4J, che può essere fatta partire, fermata e comunque gestita direttamente come una componente self-contained.

Per poter utilizzare la versione 10g di OC4J è necessario che sulla macchina su cui girerà l’application server sia installata una Java2 Standard Edition (J2SE) SDK versione 5.0 o, come minimo, la versione 1.4.2.

Procediamo pertanto con lo scaricare la versione 10.1.3.2.0 di OC4J, l’ultima attualmente disponibile per il download.
Per poter fare questo è necessario registrarsi sul sito tecnico della Oracle (tale registrazione è assolutamente gratuita).

Dal seguente link  http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html scarichiamo il pacchetto oc4j_extended_101320.zip che ha una dimensione di circa 89 MB.

La distribuzione scaricata va bene per qualunque piattaforma in quanto OC4J è scritto in Java.

Estraiamo il contenuto dello zip in una directory a nostra scelta sul file system, ad esempio: C:\OC4J, che
d’ora in poi, nel proseguo dell’articolo, considereremo come la directory d’installazione della nostra distribuzione.

Se l’estrazione è andata a buon fine dovremmo avere una struttura simile a quella presente nella fig. 1:

Fig. 1: struttura sul file system dell’installazione di OC4J 

Tra le directory presenti nell’installazione sicuramente quella più importante è la C:\OC4J\j2ee\home (vedi fig. 2) dove oltre ai file necessari per far girare l’application server sono presenti anche importanti directory per le diverse tipologie di configurazione. 

Fig.2 : struttura sul file system dell’installazione di OC4J

Elenchiamo pertanto alcune tra le directory più importanti presenti nella home:

- application: contiene tutte le applicazioni deployate nel container

- application-deployments: contiene le directory di lavoro delle applicazioni deployate e generalmente non dovrebbero essere utilizzate dagli sviluppatori 

- config: contiene tutti i file di configurazione (soprattutto xml) utilizzati per gestire OC4J

- default-web-app: è la directory utilizzata dalle web application di default ed inizialmente contiene la Welcome Page (la rivedremo in seguito), le JSP e le Servlet di esempio installate con il container.

- jazn: contiene tutte i file che gestiscono la sicurezza in OC4J

- lib: contiene le librerie di uso più comune come leAPI J2EE, i drivers JDBC, ecc. e sono automaticamente referenziate nel classpath quando parte il container

- log: contiene i vari file di log scritti dai vari moduli di OC4J

Prima dello startup del container è necessario configurare le seguenti due variabili d’ambiente:

ORACLE_HOME : rappresenta la directory d’installazione in cui è stato estratto oc4j_extended_101320.zip
JAVA_HOME : rappresenta la directory in cui è installata la J2SDK che si vuole utilizzare.

Nel nostro caso possibili valori che queste due variabili potrebbero assumere sono:
ORACLE_HOME = C:\OC4J
JAVA_HOME = C:\Java\jdk1.5.0_11

Terminata, pertanto, l’estrazione dei files dal pacchetto e configurate le suddette variabili d’ambiente, il server è pronto per poter essere utilizzato senza che ci sia la necessità di eseguire ulteriori task, ad eccezione del primo startup del server, dove ci verrà richiesta la password dell’utente amministratore della console dell’application server.
L’installazione di OC4J contiene un command script, presente nella directory C:\OC4J\bin, che può essere utilizzato per startare e per fermare la nostra istanza.
L’elenco delle opzioni contenute in questo script lo si ottiene lanciando il comando oc4j –help

Adesso utilizziamo questo script per far partire la nostra istanza: apriamo una shell dos e ci posizioniamo nella directory C:\OC4J\bin da dove lanceremo il comando  oc4j –start
Dopo i messaggi relativi ai vari auto-deployment delle applicazioni e alla richiesta della password per l’amministratore di OC4J (di default è oc4jadmin), Oracle Containers verrà inizializzato, come mostrato in fig. 3

Fig. 3: Inizializzazione di Oracle Containers for J2EE 10g

Oltre al command script visto in precedenza è possibile startare direttamente il server utilizzando oc4j.jar dalla J2EE_HOME directory ovvero dalla directory C:\OC4J\j2ee\home; pertanto lanciando il comando  
java -jar oc4j.jar  
OC4J verrà startato utilizzando i file della configurazione di default di OC4J, presenti nella directory C:\OC4J\j2ee\home\config.
E' inoltre possibile far partire il server utilizzando un file server.xml configurato “ad hoc” dall’amministratore, presente in una opportuna directory (es. /mypath), eseguendo ad esempio il seguente comando: 
java -jar oc4j.jar -config /mypath/server.xml

Per fermare il server si può usare o il command script visto prima nella forma:
oc4j -shutdown -port <ORMI port> -password <password>     dove:

 <ORMI port> - rappresenta la porta ORMI in uso in locale al nostro processo OC4J (di default è la 23791)
 <password>   - rappresenta la password dell'utente di amministrazione

oppure mediante una delle seguenti tre opzioni:

- pulsante "Stop" dell’Application Server Control Console presente nella pagina "Home" (vedi fig. 6)
- utility di comando admin_client.jar (ci ritorneremo in seguito nell'articolo)
- combinazione di tasti CTRL+C nella shell in cui è stato fatto partire il processo OC4J

A questo punto verifichiamo che l’installazione sia terminata con successo effettuando il testing della stessa, accedendo cioè alla Welcome Page di OC4J mediante la url http://localhost:8888, come mostrato in fig. 4:



Fig. 4: Welcome Page di Oracle Containers for J2EE 10g

Sulla destra della Welcome Page è presente la portlet “Quick Check” tramite la quale è possibile testare delle JSP e delle Servlet di esempio messe a disposizione dal container.

Nel caso in cui ci siano conflitti con la porta di default (8888) utilizzata da OC4J, è possibile cambiarla andando a modificare il valore dell’attributo port nel tag <web-site>  nel file default-web-site.xml presente nella directory C:\OC4J\j2ee\home\config; in questo caso è necessario stoppare e riavviare l’istanza.

Come avete avuto modo di vedere dai messaggi presenti in fig. 2  l’Application Server Control Console è stata configurata per poter essere auto-deployata al momento del primo startup dell’istanza OC4J.
Una volta che il server è stato inizializzato possiamo accedere all’Application Server Control Console con la seguente url:   http://<oc4j_host>:8888/em   
dove 8888 è la porta di default della nostra istanza OC4J standalone e <oc4j_host> è il nome della macchina su cui gira OC4J e poiché il server su cui stiamo effettuando queste prove gira in locale possiamo accedere anche con la url http://localhost:8888/em  (dove em sta per enterprise manager) come mostrato in fig. 5:

Fig. 5: pagina di login dell’Application Server Control Console

 
Una volta inserita la password dell’amministratore della console (la stessa che ci è stata richiesta al primo startup del server) verremo indirizzati alla pagina principale (Home) della console come mostrata in fig. 6:

 

Fig. 6: pagina home dell’Application Server Control Console

Poiché OC4J è un container J2EE-1.4 compliant, come tale, supporta l’archiviazione (o packaging) delle applicazioni J2EE in differenti moduli che possono eventualmente essere deployati assieme o separatamente; tali moduli possono essere classificati come appartenenti ad uno dei seguenti due gruppi:

-    moduli Application: contenenti un’ applicazione J2EE o una Web Application
-    moduli Standalone: contenenti Enterprise Java Beans (EJB), resource adapters o application clients

Un’applicazione J2EE è archiviata come un Enterprise Archive (EAR), un file con estensione .ear, che oltre ad  includere il descrittore J2EE standard, può anche opzionalmente includere il descrittore del vendor, nel nostro caso, OC4J (ad esempio: orion-application.xml), e se si utilizza una JDK 5.0, anche una directory lib (vedi di seguito la struttura di un’applicazione J2EE).
Un EAR, sostanzialmente, è un meta-container che può includere uno o più tra i seguenti moduli:

-    i moduli “Web application”sono archiviati come Web Application Archive (WAR) file; analogamente anche i “web services” sono archiviati come file WAR
-    i moduli “EJB” sono archiviati come file JAR
-    i moduli “resource adapter” sono archiviati come file JAR con estensione .rar (Resource Adapter Archive)
-    i moduli “client application” sono archiviati come file JAR

E’ importante notare come ciascuno dei suddetti  moduli può essere deployato singolarmente in OC4J, piuttosto che essere archiviati in un .ear come parte di una intera applicazione J2EE; in questo modo è possibile deployare moduli aggiornati senza la necessità di rideployare l’intera applicazione.
 
Nella figura seguente viene rappresentata la struttura standard di un’applicazione J2EE in OC4J, che conviene utilizzare già in fase di sviluppo per facilitare la successiva fase di packaging; vengono inoltre evidenziati i nomi e le location degli specifici descrittori opzionali di OC4J. 
Come menzionato in precedenza se nel nostro deployment non vengono inclusi tali descrittori, OC4J automaticamente li genererà per noi nella successiva fase di deploy dell’applicazione J2EE, usando come valori di default sia quelli ereditati dai corrispondenti file di configurazione di OC4J. Tali descrittori di deployment specifici di OC4J non fanno altro che estendere lo standard J2EE dei descrittori di deployment.

Struttura di un'applicazione J2EE in OC4J

Supponiamo di voler effettuare, tramite console d’amministrazione di OC4J, il deploy di una semplice applicazione web, un war per la precisione che, nel nostro caso, si chiamerà somma.war

La struttura di questo WAR che contiene una pagina html e una servlet è il seguente:

META-INF/MANIFEST.MF
WEB-INF/classes /TestSommaServlet.class
WEB-INF/web.xml
somma.html

Opzionalmente potremmo pensare d’includere nel nostro WAR un file orion-web.xml nella directory /WEB-INF, altrimenti tale file sarà aggiunto da OC4J durante il deploy del modulo.
In J2EE, quindi, un WAR file per quanto detto in precedenza, è tipicamente contenuto in un file EAR, e nel caso includesse solo il nostro modulo war avrebbe la seguente struttura:

META-INF/MANIFEST.MF
META-INF/application.xml
somma.war

Anche qui potremmo aggiungere un file orion-application.xml nella directory /META-INF altrimenti OC4J lo aggiungerà di default durante il deploy dell’EAR.

Poniamo quindi il nostro war nella directory C:\OC4J \j2ee\home\applications; adesso dalla console (vedi fig. 6) andiamo nella pagina “Applications” (vedi fig. 7) e clicchiamo sul pulsante “Deploy”:




Fig. 7: pagina “Applications” dell’Application Server Control Console


A questo punto la console di amministrazione presenterà un wizard composto di tre pagine che assisterà l'utente nelle varie fasi del deploy.
La prima pagina è quella relativa alla selezione dell’archivio (vedi fig.8);
qui oltre a selezionare l’archivio possiamo decidere di associargli anche un deployment plan (JSR-88), ovvero un file xml che conterrà i parametri necessari per il deploy dell’applicazione e che potrà quindi essere applicato all’archivio o semplicemente essere utilizzato come template per generarne uno nuovo.
Se non viene specificato alcun deployment plan, OC4J, di default, ne creerà uno automaticamente. 



Fig. 8 - Step 1 del processo di deploy: Selezione dell’archivio

Nella seconda pagina (vedi fig. 9) verranno settati i parametri dell’applicazione e verrà effettuato il binding dell’applicazione al sito web che verrà utilizzato per il suo accesso.
Dovremmo inserire il nome dell’applicazione, che verrà utilizzato per individuare l’applicazione web all’interno di OC4J e che di seguito verrà mostrata nella pagina “Applications” della console e la context root necessaria per accedere all’applicazione nella url.



Fig. 9 - Step 2 del processo di deploy: Parametri dell’applicazione

In questa fase è possibile selezionare un’applicazione padre, diversa da quella predefinita default disponibile in ogni istanza OC4J. Poiché le applicazioni figlie vedono lo spazio dei nomi delle relative applicazioni padre, queste impostazioni verranno utilizzate per la condivisione dei servizi tra più applicazioni.
E’ anche possibile scegliere un file di configurazione, utile per l’associazione dell’applicazione o del modulo al sito web, diverso da quello predefinito default-web-site.xml, le cui modifiche apportate allo stesso a seguito del successivo deploy sono visibili in fig. 10, relativamente alla riga con attributo application=”testSomma”.



Fig. 10. Modifiche apportate al file default- web-site.xml a seguito del deploy del modulo somma.war

Nell’ultima pagina (vedi fig. 11) si ha la possibilità di eseguire, prima dell’effettivo deploy, dei deployment task, eseguibili per l’applicazione o per il modulo (nella pagina saranno abilitati solamente quelli che effettivamente si possono applicare all’applicazione o al modulo), fornendo così un’alternativa all’editing dei deployment plan. 
Sarà comunque possibile modificare il suddetto deployment plan direttamente prima del deploy oppure salvarlo sul file system per poterlo successivamente riutilizzare.



Fig. 11 - Step 3 del processo di deploy: Impostazioni di deployment

A questo punto, non resta che cliccare sul pulsante “Deploy”; così facendo il deplyoment plan che sino a quel punto esisteva solo lato client, verrà inviato al server insieme all’archivio, completando così il processo di deploy che verrà tracciato nel file di log (nel nostro caso relativi all’applicazione testSomma) come mostrato in fig. 12.



Fig. 12: Messaggi di log durante il deploy dell’applicazione

Dopo che la fase di deploy si è conclusa correttamente accederemo, mediante il pulsante “Return”, direttamente alla pagina “Applications”, che pertanto risulterà aggiornata in quanto conterrà anche la nostra applicazione (vedi fig. 13):



Fig. 13: pagina “Applications” aggiornata a seguito del deploy del modulo

La pagina “Applications” permette di deployare e di gestire le applicazioni e quindi oltre al deploy di un’applicazione sarà possibile, a seconda dello stato in cui questa si trova,  stoppare, riavviare,  rideployare o eliminare la stessa.
Abbiamo anche detto che quando si deploya un war questo viene automaticamente “wrappato” dall’Application Server Control Console in un’applicazione J2EE e quindi in un .ear; adesso se clicchiamo sul nome dell’applicazione deployata poco fa, ci verrà presentata la home page della stessa, con le sue informazioni generali (vedi fig.14) e con il nome dell’archivio testSomma.ear.



Fig. 14: home page dell’applicazione testSomma

Riepilogando, disponiamo di un EAR che incapsula il nostro modulo WAR; per cui all’atto del deploy troveremmo nella directory C:\OC4J \j2ee\home\applications oltre al nostro somma.war anche il testSomma.ear insieme alla sua struttura esplosa, mentre nella directory C:\OC4J\j2ee\home\application-deployments\testSomma troveremmo i descrittori opzionali creati da OC4J durante il deploy ed in particolare orion-application.xml relativamente all’EAR e orion-web.xml relativamente al modulo WAR.
Adesso testiamo l’applicazione cliccando sul link del modulo Web “somma” di cui si compone la nostra applicazione ottenendo un’altra pagina di dettaglio in cui sarà presente un’icona “Test del modulo Web” che, se cliccata (vedi fig. 15), ci indirizzerà alla pagina in cui sarà possibile effettuare il test del modulo web (vedi fig. 16):



Fig. 15: home page del modulo di cui si compone la nostra applicazione



Fig. 16: pagina relativa al test del nostro modulo web

Se non si desidera deployare un’applicazione web o un modulo utilizzando l’Application Server Control Console, ma semplicemente utilizzando l’utility admin_client.jar, si devono usare i seguenti due comandi:

- per deployare un war:

java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin <admin_pwd>
     -deploy
     -file <path-to-war-file>
     -deploymentName <name>
     -contextRoot </context-root>

    dove:
        <path-to-war-file>  rappresenta il path per raggiungere il war da deployare
        <name> rappresenta il nome della Web application e
        </context-root> necessaria per accedere all’applicazione nella url

- per deployare un ear:

java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin <admin_pwd>
     -deploy
     -file <path-to-ear-file>
     -deploymentName <name>
     -bindAllWebApps

dove:
        <path-to-ear-file>  rappresenta il path per raggiungere l’ear da deployare
        <name> rappresenta il nome dell’applicazione
       
In questo articolo si è data una sorta d’introduzione alla versione 10g di OC4J, per cui abbiamo avuto modo di vedere soltanto alcuni degli aspetti che caratterizzano e che rendono OC4J un ulteriore punto di riferimento nel panorama mondiale degli application server.