I Web service offrono la possibilità di avere una facile integrazione di applicazioni e contenuti all’interno del software di un portale. Un rapporto di Ovum illustra i passi compiuti e da compiere per la loro definitiva affermazione. Quando ciò accadrà, sarà l’e-business.
I servizi Web avranno un grosso futuro nei portali: diventeranno lo standard per l’accesso ai contenuti e alle applicazioni, eliminando la necessità di centinaia di connessioni specifiche, ciascuna delle quali collegata a una singola sorgente di dati o a un software specifico. Questo è quanto sostiene la società di analisi Ovum, che assicura che la riprova di questa affermazione si avrà in un periodo di tempo variabile tra i sei e i diciotto mesi.
Nell’idea della società di analisi, i Web service giocheranno, inoltre, un ruolo chiave nella capacità dei portali di collegare insieme diverse funzioni in processi di business complessi. Rimane, però, un ostacolo da superare, ossia il fatto che è ancora da verificare se le attuali funzioni discrete, presenti in un formato riutilizzabile, consentiranno ai processi end-to-end di essere completati. Occorrerà, comunque, aspettare abbastanza a lungo affinché tutto questo possa diventare un processo di routine.
Il software come servizio
Molta della confusione che si è creata attorno ai Web service deriva dal fatto che il tema può essere affrontato secondo una prospettiva sia di business, sia tecnologica. Per quanto riguarda il primo aspetto, i Web service sono "un software visto come servizio", per mezzo del quale le applicazioni diventano utility: sono comprate, vendute e fornite alla stregua dell’elettricità o delle telecomunicazioni. Nel corso del decennio appena trascorso, la tecnologia Web è stata sviluppata in diversi modi per poter fornire una piattaforma in grado di distribuire il software come servizio.
Questo aspetto dei servizi Web propone la principale definizione secondo la prospettiva business: Web service è un termine usato per descrivere applicazioni software e funzioni che possono essere fornite su Internet.
Dal punto di vista tecnologico, i Web service sono un insieme di specifiche che vengono usate per "confezionare" il software in componenti facilmente accessibili in modo da poter essere usati su altri computer. La definizione secondo una prospettiva tecnologica, quindi, deriva primariamente dalla componentizzazione del software che sta alla base dell’It dell’ultimo decennio.
Qui si tratta di elaborare un insieme di specifiche necessarie a creare la tecnologia che permetta alle funzioni di un sistema software aziendale di essere pubblicate (Wsdl), localizzate (Uddi) ed eseguite (Soap) da altri programmi su Internet, intranet ed extranet, indipendentemente dallo loro dislocazione o implementazione. Molte delle applicazioni già create fanno capire come oggi i Web service aderiscano sostanzialmente alla definizione di business, ma non facciano ancora uso di tecnologie specifiche.
In quella che è la letteratura tecnologica (ovvero ciò che si trova su Internet, sui siti dei produttori), molti vendor di portali usano sia la definizione di business sia quella tecnologica, spesso scambiandole tra loro e, alla fine, generando confusione in chi vuol capirci qualcosa di più e negli utenti.
I componenti individuali forniti dai portali sono sempre più di frequente chiamati portlet, qualche volta, però, prendono direttamente il nome di Web service. Questa abitudine sta diventando pericolosamente fuorviante, specie da quando l’uso dei Web service (secondo la definizione tecnologica) ha un effetto significativo sul modo in cui i portali fanno il loro lavoro, di veicolazione di informazioni in senso lato, e sul potenziale che hanno in serbo per il futuro. La stessa cosa non è però vera per la definizione business.
La connettività tradizionale
Una delle caratteristiche distintive del software dei portali è la capacità di connettersi a un ampio range di sorgenti di dati e di applicazioni. Per fare ciò i vendor hanno scritto piccoli programmi (cioè i portlet) che contengono codici personalizzati volti a fornire la connettività. Questi portlet hanno inoltre consentito di creare la finestra che è visualizzata nel portale. Tutto ciò fornisce una semplice connessione tra il portale e i contenuti o le applicazioni.
Il problema principale di questo approccio è che ogni sorgente di contenuto e di applicazione richiede un differente connettore, a volte addirittura connettori multipli. Alcuni vendor hanno orgogliosamente annunciato di averne centinaia, certi addirittura migliaia. Chiaramente, la gestione di questi connettori come sorgenti di applicazioni e contenuti diventa un vero "incubo" per chi realizza portali. I maggiori vendor di applicazioni hanno compreso che per loro può rappresentare un vantaggio competitivo sviluppare portlet per i principali portali. Ciò, infatti, garantisce l’accessibilità del loro software attraverso i portali stessi. Tuttavia, la soluzione migliore sarebbe di avere alcuni form di interfaccia comuni che potrebbero essere usati per collegare dati e applicazioni ai portali.
La teoria e la pratica
A tutti gli effetti, i portali sono complessi pezzi di "spago e colla" che forniscono funzionalità e informazioni che diventano quasi esclusive al di fuori dei portali stessi. Il portale amalgama il tutto e aggiunge un ulteriore strato di funzionalità per offrire una proposta coerente e l’integrazione tra le diverse fonti di contenuto. L’operazione, solitamente, è eseguita artigianalmente impiegando un vasto numero di connessioni.
Quello che differenzia la tecnologia dei Web service è il fatto che è semplice e universalmente riconosciuta come una sorta di metodo di "inscatolamento", accessibile su Internet e che non necessita di essere legata alle piattaforme dei vendor. I meccanismi descritti per fornire la connessione tra i sistemi sono tutti specializzati per particolari tipi di integrazione.
La tecnologia dei Web service è differente perché fa apparire tutti i tipi di "collante" come se si trattasse di uno solo. Se l’impresa usa lo stesso tipo di "colla" per la connessione di tutti i portali, allora i contenuti interni con relative applicazioni, le informazioni esterne, le applicazioni per i partner commerciali, i servizi online e le applicazioni in affitto possono essere tutti messi assieme: saranno, infatti, i Web service a fornire il collante.
I Web service in pratica
I vendor di portali stanno progressivamente fornendo semplici portlet che possono accedere ai Web service. In teoria, l’utente deve fare solo una copia del portlet di default, identificare il Web service adatto e generare il nuovo portlet. Nelle implementazioni correnti, questo richiede quasi sempre qualche intervento nel codice da parte dell’utente del portale, abitualmente per la creazione di un’interfaccia e nella definizione delle chiamate Soap richieste.
Un approccio più sofisticato consiste nella possibilità per i portlet Web service di localizzare automaticamente i Web service (usando Uddi), leggere la descrizione dei servizi (codificati in Wsdl) e quindi generare automaticamente un’interfaccia utente.
Il portale di Epicentric, giusto per fare un esempio applicativo, è in grado di comportarsi in questo modo e può quindi creare un’interfaccia utente standard partendo dalla definizione Wsdl. Tale procedimento automatizza completamente i processi.
Un effetto significativo di questo tipo di impiego dei Web service è che riducono drasticamente la necessità di gestire più connessioni, elemento che, invece, alcuni vendor di portali impiegano come fattore di differenziazione. Sebbene i contenuti e le applicazioni possano essere inseriti nel portale automaticamente tramite i Web service, non c’è nessuna necessità di creare connessioni personalizzate. Questo è sicuramente vero per le applicazioni e i contenuti standard (come i database), verso i quali la maggior parte dei vendor si aspetta di fornire l’accesso attraverso i Web service nei prossimi mesi. Ovviamente, dove non ci sono Web service disponibili, c’è ancora bisogno di creare connessioni scrivendo il codice.
La "carica" degli standard
Da parte dell’Oasis (Organization for the Advancement of Structured Information Standard) sono in corso due iniziative.
La prima, Wsia (Web Service for Interactive Applications), intende portare i Web service oltre l’ambiente di comunicazione macchina-macchina per permetterne la fornitura direttamente agli utenti. Questo progetto è stato costruito basandosi su Wsui (Web Services User Interface), proposta avviata da Epicentric nel corso del 2001. Le specifiche Wsia non saranno però disponibili fino al 2003.
La seconda iniziativa, il Wsrp (Web Service for Remote Portal), è esplicitamente focalizzata sui portali e non sulla fornitura generica di Web service.
Tutto questo sta portando alla definizione di un Web service standard interattivo con l’utente piuttosto che non a uno strumento plug and play per il portale. La prima specifica dovrebbe essere disponibile a breve termine.
I due nuovi standard sono progettati in modo da presentare funzioni sovrapposte nel loro core.
Workflow e funzionalità
L’impiego dei Web service per connettersi a contenuti e funzionalità è comunque solo il primo passo da fare. Il prossimo sarà quello di fornire funzionalità tra i portali che possano consentire di collegare diversi Web service per attivare processi di business complessi. Anche se scarsamente implementato, il workflow è un elemento essenziale dei portali ed è volto a fornire funzioni per spostare automaticamente i contenuti tra portlet. Può inoltre essere usato per costruire flussi attraverso processi individuali che possono apparire all’interno di un singolo portlet.
Facendo un ulteriore passo in avanti, dovrebbe essere possibile definire interi processi di business creando i workflow adatti ed eseguendo le funzioni specifiche richieste da ciascun processo.
I Web service rappresentano la base ideale per questo tipo di funzionalità. Il workflow gestisce i codici di risposta provenienti dai Web service e controlla i flussi conseguenti. Tutto ciò offre la possibilità di creare processi di business end-to-end che possono essere automatizzati, devolvendo l’intervento dell’utente ad altre fasi. Le funzioni di alerting dei portali possono essere gestite per assicurare interventi appropriati e per garantire che i processi raggiungano il completamento.
In questo modo, l’implementazione completa dei processi di business può sembrare una chimera. Tuttavia già oggi esiste praticamente tutta la tecnologia e la sua messa in opera è solo una questione di tempo. I vendor stanno già lavorando su quest’area.
Il più grosso problema è l’incompatibilità tra i nuovi processi di business e i componenti dei processi già esistenti. I processi computerizzati possono, invece, esistere e anche essere convertiti in Web service, ma dovranno essere progettati per l’esecuzione in circostanze molto specifiche.
Quando tale contesto viene rimosso tramite l’estrazione di funzionalità in Web service, il processo non può più essere eseguito in modo appropriato. Si tratta di un vecchio problema già incontrato qualche anno fa con l’object orentation, che è nata come parte di un’applicazione più grande spesso non facilmente riutilizzabile.
Uno dei problemi riscontrati con la maggior parte dei portali è che questi forniscono agli utenti soltanto accessi personalizzati alle tecnologie esistenti e ai contenuti ma niente più. Questo è stato il modello seguito dai primi Web portal, come Yahoo!, che era principalmente un aggregatore di contenuti. Tutto ciò ha portato a una semplice architettura di portlet che ha accesso a una singola fonte di contenuti, i quali sono forniti attraverso un’interfaccia utente costruita nel portlet stesso (come mostra la figura della pagina precedente). Questo incoraggia la creazione di portlet "cilindrici", che comprendono l’accesso back end e l’interfaccia utente. Attraverso questo approccio, è difficile fornire funzionalità che estendono molteplici fonti di contenuti e di applicazioni. Si è arrivati anche ad avere una pletora di portlet differenti creati dai vendor in modo che potessero avere acceso a contenuti e applicazioni. Ciò ha però rappresentato una differenziazione tra i vendor di portali.
L’integrazione dei portlet
Ora che gli utenti business si sono abituati ai portali, c’è un forte desiderio di avere qualcosa di più, ovvero di poter disporre di forme di integrazione attraverso sorgenti differenti di informazione.
In questo senso, stanno per essere rilasciate alcune funzioni che collegano insieme feature e contenuti. I portlet possono talvolta essere sincronizzati: per esempio, il cambiamento del cliente visualizzato attraverso dei dati in una finestra causa l’apertura di un’altra finestra che mostra il nuovo cliente, i cui riferimenti provengono da un sistema differente.
Elementi come i documenti possono essere usati in tool collaborativi e, attraverso il portale, possono essere gestiti automaticamente da un sistema di content management, fornito tramite il portale stesso. I dati possono essere ottenuti attraverso il "drag and drop" da un portlet a un altro, avviando una serie di azioni automatiche, come per esempio il tracciamento di una parcella in un sistema esterno ottenuto trascinando il numero d’ordine da un sistema di processo degli ordini.
La chiave di tutto ciò è l’integrazione tra differenti funzioni fornita dal portale. Al momento, però, il livello d’integrazione è veramente limitato e, per lo più, tende a riguardare soltanto un paio di funzioni.
I Web service, quindi, renderanno l’accesso ai contenuti e alle applicazioni più facile e porteranno all’architettura descritta nella figura di questa pagina. Al livello più semplice, i portlet individuali useranno un Web service comune per accedere ai contenuti e alle applicazioni. Il successivo livello di complessità permetterà al portlet di accedere a funzionalità di altri portlet per poter offrire i link.
A un livello ancora più complesso, il motore del portale permetterà la progettazione di processi di business più completi attraverso l’uso di workflow e l’esecuzione di Web service multipli. Questo approccio renderà molto più facile per un portale fornire funzioni di integrazione per accedere a molteplici fonti di contenuti e ad applicazioni.
