L’Evoluzione del Portale di e-Business (Parte Seconda)
Gli agganci alla directory del portale sono organizzati tipicamente per soggetto, intendendo per soggetto la relazione specifica con un preciso argomento o concetto proprio dell’impresa.
La tassonomia dell’impresa che definisce tale struttura di aree di soggetto viene sviluppata nel corso del processo di progettazione del portale e costituisce uno degli elementi più importanti dello sviluppo e manutenzione successiva del portale.
Le regole dell’impresa per tale tassonomia sono utilizzate dal categorization manager per determinare le aree di soggetto appropriate, con le quali associare metadati e informazioni dell’impresa.
Le regole di tassonomia vengono valutate dal categorization manager con l’ausilio di informazioni estratte dal medesimo contenuto dei dati a disposizione, oppure dai metadati relativi ai contenuti informativi da gestire (nome dell’applicazione, nome del file, URL e pagina web, autore, ecc.).
I servizi (ad es.: i servizi di pubblicazione) e gli strumenti che usano l’interfaccia verso la directory del portale, possono impiegare il categorization manager per essere assistiti nell’assegnazione ad un’area adatta degli agganci alla directory del portale.
I prodotti sul mercato presentano notevoli variazioni circa le capacità dei rispettivi categorization manager e il tipo di metadati utilizzati per il mantenimento della directory del portale.
Alcuni documentano semplicemente il nome e la dislocazione del contenuto, mentre altri supportano informazioni più dettagliate circa il suo significato e uso all’interno dell’impresa.
Analogamente, alcuni prodotti forniscono categorization manager robusti e automatici, mentre altri richiedono una categorizzazione manuale. Le rispetive funzionalità della directory del portale e del categorization manager sono fattori chiave di distinzione tra i prodotti.
Il componente adattatori di portale fornisce un insieme di servizi per raccogliere informazioni sul contenuto dei dati e sulle modalità di accesso relative.
Come abbiamo già detto, le informazioni a disposizione dell’utente del portale sono registrate sotto forma di metadati nella directory del portale stesso.
Gli adattatori di portale possono assumere forme diverse – gli esempi comprendono interfacce programmabili, meccanismi di import/export di file e strumenti automatici (spesso denominati crawler) che possono effettuare una scansione dei contenuti informativi a intervalli regolari.
Un portale può fornire adattatori per basi dati e per semplici file, prodotti di business intelligence, sistemi di gestione dei documenti e dei contenuti, oggetti di groupware e di office automation (ad esempio: e-mail, documenti di word processing, fogli elettronici e pagine Web), oppure applicazioni (front-office, back-office ed e-business).
Gli adattatori di portale possono essere più o meno sofisticati. Alcuni consistono in interfacce rudimentali e generiche per file o basi dati, mentre altri risultano strettamente integrati nel contenuto informativo originario come, ad esempio, nelle applicazioni di e-commerce.
Per la scelta di un prodotto, non è importante il numero di adattatori forniti da un portale, ma piuttosto le loro rispettive capacità. I venditori aggiungono adattatori sempre più sofisticati ai loro prodotti.
Gli esempi comprendono adattatori per l’interoperabilità con il software EAI (Enterprise Application Integration) per l’integrazione delle applicazioni dell’impresa, per il text mining, ovvero la ricerca dei testi per contenuto e, infine, per la catalogazione delle esperienze e l’identificazione delle relazioni tra diverse professionalità, basate sui dati di uso delle informazioni.
Gli sviluppatori di portali possono aggiungere adattatori di contenuto a un portale utilizzando il kit di sviluppo del portale. Un PDK dovrebbe fornire funzionalità che consentano di scrivere elementi Java o Microsoft Active X in grado di accedere alle informazioni dell’impresa, presentando al portale, sotto forma di un flusso di dati basato su XML, questi contenuti con i relativi metadati associati.
Il PDK dovebbe essere in grado di supportare gli adattatori di contenuto che possono interagire con altri servizi del portale, in modo da costruire un portale verticale sofisticato in grado di gestire le interrelazioni tra vari tipi di contenuti informativi e di elaborazioni dell’impresa.
Ad esempio, un adatatore di portale può avere la necessità di interagire con servizi di workflow, in modo da poter sviluppare un’applicazione di portale verticale per gestire il flusso di informazioni dell’impresa tra diversi utenti del portale stesso.
Questi tipi applicazioni di portale verticali saranno svilippati da società di software, per essere poi personalizzate per adeguarsi alle necessità dell’impresa.
Le applicazioni pacchettizzate di portale verticale realizzate utilizzando una piattaforma aperta di sviluppo di portali riducono in maniera significativa lo sforzo richiesto a un’organizzazione per implementar e integrare un portale.
La maggior parte dei portali interagisce con gli utenti dell’organizzazione mediante un’interfaccia basata sul Web. I servizi Web che forniscono tale interfaccia possono essere contenuti nell’infrastruttura del portale, ma i prodotti normalmente usano un server Web separato per gestire queste elaborazioni.
I tipi di server Web utilizzati dai prodotti di portale variano da un semplice servizio di ascolto HTTP al collegamento con il server Web per le funzioni di amministrazione e sviluppo, per la sicurezza e per le interfacce sui contenuti informativi disponibili nel back end dell’impresa.
Anche se per i prodotti di portale è importante assicurare la portabilità tra i server Web più diffusi, diviene fondamentale, con la crescita dei volumi di utenza, che i prodotti dispongano di funzioni come i servizi di directory, di uso della memoria cache, di bilanciamento del carico e di ripartenza, nell’ambito dei server Web per le applicazioni.
Evoluzione del portale
Da quanto abbiamo detto sopra, appare chiaro come i prodotti di portale stiano evolvendo rapidamente, così come si delineano alcune tendenze del mercato dei portali.
1) Supporto per le applicazioni transazionali dell’impresa (sistemi proprietari, package applicativi di front- e di back-office, applicazioni di e-business) che usano adattatori dal contenuto del portale realizzati dal cliente, oppure software EAI.2) Supporto per uno spettro più allargato di informazioni dell’impresa (strumenti di business intelligence, sistemi di gestione dei contenuti, basi dati, documenti di ufficio, informazioni Web, dati protetti) oltre che di esperienze, utilizzando adattatori proprietari del contenuto del portale.3) Creazione di PDK (Portal Development Kit), ovvero kit di sviluppo dei portali che consentono agli sviluppatori IT, alle società di software e agli integratori di sistemi di aggiungere e personalizzare adattatori di portali in grado di accedere al contenuto informativo dell’impresa.Gli esempi di prodotti comprendono Ascential Axelle type manager, i moduli per portale Epicentric, le portlet IBM WebSphere Portal, le parti Microsoft Web, le portlet Oracle, i gadget Plumtree, le portlet Top Tier iViews e Viador.
Un problema è che la maggior parte dei PDK supportano interfacce documentate ma proprietarie, con il risultato che gli adattatori non possono essere interscambiati tra prodotti diversi.
Il Java Apache Project ha pubblicato un’interfaccia per adattatore di portale aperta, basata su XML (conosciuta come Jetspeed), supportata però da pochi venditori oltre IBM. Alcuni venditori stanno lavorando sul supporto ad adattatori di altri.
Ad esempio, Plumtree sta lavorando con Microsoft per consentire alle parti Microsoft Web di operare nell’ambiente di portale Plumtree. Top Tier, (acquistata recentemente da SAP) ha instaurato relazioni con Microsoft per consentire a Top Tier iViews di girare come parte Microsoft Web.4) Supporto per un vasto spettro di apparecchiature Web, compresi i terminali mobili e senza fili che usano strumenti come XML e XSl. Esempi di prodotti che si focalizzano sul supporto mobile e senza fili comprendono Corechange Coreport 3g, IBM WebSphere Everyplace Suite e Oracle9iAS Wireless Edition di Oracle.5) Integrazione delle tecnologie di portale nei server Web per le applicazioni e per l’e-commerce. In quest’area, gli esempi comprendono BroadVision InfoExchange Portal, IBM WebSphere Portal, Oracle9iAS Server, e Sun iPlanet Portal Server.6) Integrazione delle tecnologie di portale in soluzioni groupware e office. Esempi principali sono Lotus Knowledge Discovery System, Microsoft SharePoint Portal Server, e Correlate K-Maps per Lotus e Microsoft.7) Funzionalità dei prodotti di portale nelle aree della sicurezza, dei servizi di ricerca, dell’elaborazione delle regole, del supporto ai metadati e del workflow e delle collaborazioni. Esempi di prodotti di questo tipo sono Ascential Axelle (gestione dei metadati). Verity Portal One (servizi di ricerca) e Viador E-Portal (sicurezza).8) Integrazione della tecnologia di portale in pacchetti applicativi verticali. Esempi di venditori importanti sono Oracle, PeopleSoft e SAP.9) Consolidamento del settore mediante acquisizioni di prodotti e fusioni. Esempi di acquisizioni recenti sono costituiti da Top Tier (da parte di SAP per formare SAP Portals) e Sequoia Software (da parte di Citrix Software).Attualmente, nessun prodotto di portale risulta conforme a tutte le prescrizioni di una soluzione completa di portale.Questa considerazione è importante nel momento della valutazione di prodotti di portale le cui funzionalità debbano trovare corrispondenza con le specifiche delle applicazioni, oppure nella scelta di prodotti che debbano fornire supporto a un ambiente di portale aperto.