Architettura OracleAS Portal 10g

             

 

Oracle Application Server Portal 10g (OAS Portal) e’ un ambiente completo ricco di funzionalita’ ma anche complesso sia nell’architettura che nella configurazione dei vari componenti necessari al suo corretto e completo funzionamento.

La predisposizione di una architettura completa richiede quindi un’attenta analisi ed un’accurata installazione.

 

Oracle Application Server Portal

Un portale permette agli utenti di accedere informazioni provenienti da differenti sorgenti di dati attraverso un singolo punto di ingresso. Un portale inoltre permette a ciascun utente di creare una propria vista privata dei dati definendone le sorgenti e personalizzandone i contenuti.

 

OAS Portal e’ un ambiente completo che consente la realizzazione, la messa in linea e la gestione di portali. OAS Portal e' un componente dell'architettura di Oracle Application Server 10g (OAS) che comprende un'ampia serie di strumenti di ambienti con cui OAS Portal si integra.

 

 

Un ambiente OAS Portal e' costituito da Page Group che costituiscono l'ambiente cui gli utenti finali accedono. Un Page Group e' costituito da uno o piu' pagine. Su ciascuna pagina i progettisti di OAS Portal introducono elementi che possono essere contenuti statici o Portlet dinamici. A disposizione dei progettisti vi sono una serie di Portlet gia' definiti ed e' inoltre possibile crearne di nuovi agganciandoli ad applicazioni (eg. J2EE). Ma forse e' piu' comprensibile una figura...

 

 

Tali definizioni sono contenute nelle tabelle dello schema PORTAL ed il deploy di tali oggetti viene svolto con una modalita' tipica del prodotto: l'export e l'import di un Transport Set.

 

In un portale le problematiche di autenticazione e di gestione degli utenti sono fondamentali. OracleAS Portal si integra con l'Oracle Identity Manager (OID) che e' un server LDAP che consente l'autenticazione delle utenze e con l'Oracle Single Sign-On (SSO) che consente la gestione del login singolo per tutte le applicazioni presentate dal portale in modalita' nativa (Partner Application) o come External Application.

 

Rispetto alla versioni precedenti Oracle Application Server Portal 10g (9.0.4) introduce una serie di nuove funzioni volte a migliorare l'usabilita', procedure guidate che offrono allo sviluppatore maggiore produttivita' e flessibilità e portlet per semplificare l'accesso ai dati. Tra gli elementi maggiormente interessanti:

• Syndication Services per impostare canali di sottoscrizione al contenuto
• Pubblicazione dichiarativa dei dati attraverso OmniPortlet
• Web Clipping per acquisire contenuto di pagine Web pubblico e protetto
• Semplificazione della fase di progettazione
• Costruzione ottimizzata delle pagine

 

Architettura

L’architettura di OAS prevede piu’ livelli su cui installare i diversi componenti. I componenti vengono distinti tipicamente su due livelli: Middle Tier ed Infrastructure.

Sul Middle tier vengono elaborate le richieste con l’esecuzione delle specifiche applicazioni, mentre sull’Infrastructure vengono mantenute le basi dati e gli archivi.

 

I componenti fondamentali per il corretto funzionamento di OAS Portal sono:

• Middle Tier:
• OracleAS Web Cache
• Oracle HTTP Server (con i moduli mod_oc4j, mod_oradav, mod_plsql vs OracleAS Portal DAD)
• OC4J (Portal)
• Portlet Providers :
• Web Providers
• Database Providers
• Infrastructure:
• Oracle HTTP Server (con i moduli mod_oc4j, mod_osso, mod_plsql vs ORASSO DAD)
• OC4J (Security)
• Oracle Internet Directory
• Oracle RDBMS Instance:
• OracleAS Portal repository (schema PORTAL)
• OracleAS SSO repository (schema ORASSO)

 

Catena di attivazione delle pagine

Descrivere in dettaglio le funzionalita’ di ogni singolo componente e’ sicuramente troppo complesso per lo scopo di questo documento. La figura seguente riporta le principali relazioni tra i componenti alla richiesta di una pagina da parte di un utente:

 

 

Le richieste degli utenti vengono immediatamente soddisfatte dalla WebCache se gia' presenti, altrimenti vengono inoltrate al Web Server. Questi richiama, a seconda del tipo di chiamata, un Stored Procedure sul Portal Repository oppure una funzione soddisfatta dai Servlet di Portal. I moduli Java di Portal sono chiamati Parallel Page Engine e sono ospitati su un Container OC4J dedicato.
Per semplicita’ nella figura non sono riportati i flussi relativi all’identificazione dell’utente ed al Single Sign On. In questo caso il Web Server verifica l'autenticazione dell'utente con il modulo mod_osso. Se si tratta del primo accesso l'utente viene ridiretto sulla pagina di login, gli accessi successivi utilizzano un security token rilasciato alla sessione utente come cookie.

 

Topologie

I componenti di OracleAS Portal possono essere configurati con topologie differenti. Partendo dal caso limite in cui tutti i componenti sono installati su un unico sistema, si possono poi elaborare architetture complesse in cui i vari componenti vengono separati ed isolati tra loro. Al crescere delle esigenze di sicurezza ed affidabilita’ le topologie diventano complesse e richiedono piu’ sistemi, segmenti di rete e tier.

 

L'architettura prevista da Oracle ha una notevole flessibilita'. E' infatti possibile utilizzare piu' installazioni di Middle Tier (ogni installazione prende il nome di OAS Instance) che fanno riferimento alla stessa Infrastructure. Il carico tra i Middle Tier puo' essere bilanciato in modo statico o con Load Balancer HW. L'Infrastructure puo' essere posta su un servizio Cluster o puo' essere utilizzata una configurazione in RAC.

 

Una topologia di riferimento per una completa installazione e’ la seguente:

 

 

Configurazioni in alta affidabilita'

Quando l’alta disponibilita’ del servizio diventa un requisito essenziale e’ necessario predisporre un’architettura in HA. Da questo punto di vista le scelte possono essere differenti a seconda del tipo di servizio.

Un servizio HTTP permette l’utilizzo di configurazioni Active-Active con un Load Balancer HW che ne distribuisce l’accesso sui due, o piu’, MidTier configurati.

Mentre per la parte RDBMS una configurazione in alta affidabilita’ richiede l’utilizzo di un software di clustering o la configurazione dell'istanza RDBMS in RAC.

A questo punto le configurazioni diventano piu’ complesse...

 

Configurazione in DMZ

Dal punto di vista della sicurezza una corretta configurazione degli accessi e’ fondamentale. E’ di particolare importanza l’utilizzo di Firewall per proteggere sistemi e servizi da accessi esterni. La definizione delle abilitazioni da definire dipende dai servizi presenti e dalla topologia scelta, la figura seguente riporta le impostazioni piu’ comuni.

 

 

Progetto ed installazione

Per la configurazione dell’ambiente di test per Oracle Application Server Portal 10g e’ necessario svolgere una serie di attivita’ riassunte sei punti seguenti:

• Raccolta ed analisi dei requisiti: e’ necessario raccogliere le diverse esigenze relative ai requisiti di sicurezza, di affidabilita’, alle tipologie applicative, prestazionali e di carico. E’ altresi’ importante raccogliere e/o creare standard aziendali e procedure per una corretta progettazione dei componenti.
• Assessment delle configurazioni gia’ attive: e’ opportuno procedere ad un assessment delle configurazioni gia’ implementate per avere un’installazione conforme, per suggerire eventuali raffinamenti ma anche per valorizzare i risultati gia’ ottenuti.
• Sizing sistemi ospite, definizione componenti, attivita’ di preinstallazione: e’ necessario uno studio sul dimensionamento dei sistemi ospite e dell’infrastruttura. Inoltre i prerequisiti per l’installazione di Oracle AS debbono essere verificati ed i sistemi ospite preparati adeguatamente. Indirizzi e nomi di server vanno stabiliti con esattezza.
• Definizione di dettaglio dei componenti di Oracle AS: e’ necessario determinare con esattezza l’elenco completo dei componenti necessari e la loro configurazione nella topologia scelta. Vanno verificate versioni e livelli d’aggiornamento. Vanno definiti dettagli quali le caratteristiche delle istanze di RDBMS da installare, le porte utilizzate per la comunicazione dei vari componenti, l’Identity Management Realm.
• Installazione Infrastruttura: l’installazione dei componenti di infrastruttura comprende i Repository ed il server LDAP. Deve essere svolta come prima poiche’ e’ poi utilizzata dai componenti del Middle Tier.
• Installazione Middle Tier: l’installazione dei middle tier comprende i server HTTP e la Web Cache.
• Test del sistema: il test del corretto funzionamento del sistema e’ fondamentale in ambienti complessi e richiede anch’esso un tempo adeguato.
• Tuning sistema: non sara’ possibile, ne probabilmente necessario, un tuning fine di componenti, istanze, sistemi, ... tuttavia un’affinamento delle configurazioni puo’ rendere l’ambiente maggiormente performante e, soprattutto, in grado di sopportare un carico maggiore di accessi.
• Documentazione: e’ naturalmente molto opportuno documentare le configurazioni effettuate.

 

Naturalmente quello che e’ stato presentato come una sequenza di passi in realta’ generalmente richiede alcuni ricicli per raggiungere la configurazione ottimale.