Dove sei:

 
Sfumatura blu






Notizie

gio 1 mar 2012

Ritorna alla griglia

giovedì 3 novembre 2011
Caratteristiche PortalBuilder
StampaInvia ad un amico

Caratteristiche tecniche

Il Web Server
Il Web Server costituisce il front-end comunicativo tra il browser che richiede attraverso protocollo HTTP l’avvio di una transazione applicativa e l’application server delegato all’esecuzione della stessa.
Per motivi di performance, sul web server risiedono le risorse statiche dell’applicazione (file aspx, xhtml, css, jpg, gif, etc.). 

L’Application Server
L’application server costituisce il componente su cui opera la logica di business propria dell’applicazione.
Nell’application server girano le quattro componenti essenziali dell’applicazione:

 

  • l’engine ASP.NET, che si occupa del rendering XHTML;
  • l’engine web service, che si occupa dell’implementazione dell’architettura SOA (Service Oriented Architecture) tramite invio e ricezione di web services;
  • la business logic, che racchiude i componenti veri e propri della logica applicativa;
  • i DAO (Data Objects), che sono  oggetti  che accedono al DB, disaccoppiando così la logica applicativa dal database dalla logica di accesso alla base dati. 

Il Database Server
Il database server è il componente responsabile delle funzioni di accesso e di memorizzazione dei dati gestiti da un database relazionale. Nel modello di sviluppo, il Database Server viene acceduto dai DAO (che implementano lo strato ORM) attraverso connettori specifici  per l’accesso ai diversi RDBMS.

Gestione dispositivi di accesso (multicanalità)
Portal Builder è progettato per supportare la multicanalità di siti e portali in modo da interfacciare i vari canali di comunicazione, per rendere disponibili agli utenti , le informazioni ed i contenuti .
La muiticanalità prevede Ia gestione delle caratteristiche fisiche del dispositivo di accesso, In modo da rendere trasparenti agli strati applicativi Ie peculiarità dello specifico dispositivo e Ia strutturazione dinamica dell'interfaccia utente. Attraverso quest'area e possibile che un utente esterno possa raggiungere i servizi resi a disposizione (componente middle-tier) i quali possono ritenersi indipendenti dal canale utilizzato.
Sono disponibili diverse funzionalità che  consentono  di decidere, contenuto per contenuto, se veicolarlo o meno nei diversi canali di comunicazione.

  • Output su dispositivi portatili ( WAP/GPRS /UMTS)
  • Il codice generato da Portal Builder è compatibile con la tecnologia WAP rendendo semplice ed automatica la generazione di una versione del sito fruibile via WAP/GPRS.
  • Output su SMS
  • Portal Builder è predisposto anche all'invio di informazioni attraverso messaggi SMS
  • Output su Feed RSS
  • Tutte le informazioni disponibili nel sito Web  ( News - documenti  ect)  possono essere rese condivise grazie al modulo RSS.
  • Esportazione ed Importazione  dati ( xml)
  • Portal Builder consente l’esportazione dei contenuti inseriti nel sito in formato XML, per l'elaborazione con eventuali altre applicazioni, ed è altresì in grado di importare, manipolare e pubblicare informazioni in formato XML provenienti da altri sistemi (caso frequente è rappresentato dall'esportazione XML di dati provenienti da database esterni e successiva importazione in Portal Builder ).

Porta di dominio
La porta di dominio rappresenta un elemento concettuale che ha la funzione di tramite (proxy) per l'accesso aIle risorse applicative del dominio da parte di altri sistemi consentendo, tra l'altro, di realizzare servizi di cooperazione esterni.
La soluzione Portal Builder  è stato realizzato utilizzando una piattaforma per i servizi Web  (Web Services) che garantisce l'integrazione e lo scambio informativo con altri Portali e Siti, dette integrazioni sono rese possibili grazie all'adozione di metodologie di sviluppo e di tecnologie aperte conformi allo standard  SPCoop Sistema Pubblico di Cooperazione gestito dal CNIPA , che norma le modalità di comunicazione ed organizzative relative alle comunicazioni applicative tra gli Enti.
Uno dei componenti principali dell'architettura SPCoop è la Porta di Dominio che delimita il confine di responsabilità di un ente o soggetto amministrativo e racchiude al suo interno tutte le applicazioni da esso gestite. Le comunicazioni da e verso un dominio devono quindi attraversare la sua Porta di Dominio.
La Porta di Dominio OpenSPCoop è il risultato di un progetto open source per l'erogazione e la fruizione di Servizi da parte delle Pubbliche Amministrazioni, in maniera aderente alle più recenti specifiche del Sistema Pubblico di Cooperazione (SPCoop 1.1).
Le Porte di Dominio si parlano tra di loro scambiandosi richieste e risposte in un formato standard, denominato busta eGov, che è sostanzialmente una specializzazione di un messaggio SOAP, esteso con un apposito header per definire le caratteristiche del protocollo SPCoop. Poiché il formato della busta non è parlato nativamente (e non è previsto che lo sia) dalle applicazioni, la Porta di Dominio deve anche occuparsi di convertire le richieste applicative in formato proprietario nel formato busta eGov.
La specifica SPCoop prevede poi la presenza di un registro dei soggetti e degli accordi di servizio tra essi stipulati. Si prevede l'esistenza di un registro di primo livello, gestito dal CNIPA e che includa tutti i servizi ufficiali SPCoop a livello nazionale, e di registri di secondo livello che possano contenere un sottoinsieme dei servizi SPCoop. La specifica prevede infine la presenza di un Gestore Eventi per permettere lo scambio di buste eGov secondo l'architettura event-driven (EDA).

Architettura "Multi Layers" e SOA Service Oriented Architecture
Il sistema è stato progettato con un'architettura che consentisse di risolve problematiche d'affidabilità, scalabilità, portabilità, interoperabilità ed integrazione. A tal fine è stata adottata  una architettura "multi layers". basato sulla separazione delle funzionalità logiche:

  • Presentation Layer: rappresenta l'interfaccia utente dell'applicazione e si occupa di acquisire dati e visualizzare risultati.
  • Business Logic Layer: rappresenta la parte principale dell'applicazione, si occupa delle elaborazioni dei dati in base alla cosiddetta business logic, cioè all'insieme delle regole per cui i dati sono considerati significativi e le loro relazioni consistenti; le elaborazioni del livello intermedio generano i risultati richiesti dall'utente; Non contiene alcun riferimento a come i dati saranno presentati all'utente o a come verranno salvati.
  • Data Access Layer: rappresenta l'insieme dei servizi offerti da applicazioni indipendenti dal Web, come ad esempio un gestore di database.Questo tipo di architettura ha principalmente il vantaggio di fornire una separazione logica così da aumentarne la manutenibilità, la scalabilità e il riutilizzo.
  • Il sistema è stato inoltre  progettato con un'architettura orientata ai servizi “ Service Oriented Architecture “(SOA). La SOA è un paradigma architetturale che definisce le caratteristiche con cui i componenti software (servizi) presenti nel perimetro di una organizzazione, devono essere descritti nell'ottica del riuso e dell'integrazione.

Ambiente Operativo
Il servizio può essere gestito sia direttamente dall’Amministrazione acquirente, sia attraverso l’assegnazione (di tutto o parti di esso) in outsourcing presso  il  Service Provider della Esytec.
Le modalità di gestione sono le seguenti:

  • servizio in modalità ASP (tutto il servizio è gestito dalla Esytec “Service Provider”);
  • soluzione in hosting (la licenza d’uso  della soluzione applicativa Portal Builder  è  acquistata all’Amministrazione, mentre il Provider (Esytec)  fornisce hardware e connettività ed esercisce il servizio).;
  • soluzione in housing (l’Amministrazione possiede non solo la soluzione applicativa ma anche lo hardware; il Service Provider esercisce il servizio e fornisce la connettività);
  • soluzione on site presso il Cliente, che si fa carico di acquisire e gestire hardware, software di base  e connettività ed  eventualmente  il servizio  potrà essere eventualmente gestito direttamente  dal  centro EDP  del’Ente (Amministrazione) o dalla Esytec   in qualità di “Service Provider” con un contratto di application management.
  • I principali motivi che possono spingere a una gestione esterna totale o parziale sono:
  • contenimento e controllo dei costi operativi, riduzione degli investimenti iniziali in conto capitale, a favore di costi correnti almeno in parte variabili in base all’effettivo utilizzo (Esytec  è già dotata di infrastrutture, connettività ed operatori e beneficiano di economie di scala nella web server farm);
  • maggiori livelli di disponibilità e flessibilità operativa per far fronte a picchi di traffico e accessi, sfruttando la maggiore banda disponibile presso un adeguato Service Provider.