Enterprise Search & Retrieval Platform

Rosario Turco Uno dei temi emergenti nellIT quello che oggi catalogato sotto il nome Enterprise Search & Retrieval, intendendo con questo termine la possibilit di offrire una piattaforma sicura, in grado di ricercare informazioni enterprise nel senso pi generale possibile, di presentarle nel modo pi opportuno, e su cui poterci fare un uso pi generale possibile. Sicuramente una tale piattaforma ha caratteristiche diverse da una ricerca del tipo Google. Il tema di notevole interesse per le grandi aziende, oltre per lintegrazione delle amministrazioni pubbliche e il cittadino (riduzione barriera e burocrazia), le regioni, i comuni, gli uffici anagrafe, il governo, le organizzazioni militari o civili di soccorso etc. La definizione di sopra di una piattaforma Enterprise Search & Retrieval, che nel seguito indicheremo brevemente ESR, abbastanza larga e vale la pena di soppesare bene ogni termine di essa, anzicch buttarsi a capofitto nella giungla emergente. Piattaforme ESR possono far coppia spesso con piattaforme di collaborazione anche di PMI (Piccole e Media Imprese), per mettere in cooperazione e integrazione rapida, varie aziende e contribuire a migliorare lefficienza del processo di Logistica, Produzione, Approvvigionamenti, Ordini etc. in termini di Business Process. Features Vediamo quali sono i requisiti o le features di una piattaforma ESR. Per ricerca sintende, quindi, una qualsiasi tipologia di ricerca fra tutte quelle possibili: Web Search, limitata a documenti pubblici in ambito INTERNET Desktop Search, limitata a documenti sul PC o la workstation in gioco Enterprise Search, limitata a documenti aziendali, nellambito dellINTRANET.

La frase ricercare informazioni enterprise nel senso pi generale possibile indica che sono cercati non solo i documenti di qualsiasi estensione e tipo, ma che si possono cercare le risorse sorgenti in generale: documenti locali o remoti, immagini, video, audio, filesystem locali o remoti, repository locali o remoti, etc. Le risorse sorgenti possono essere di ogni tipo: dati strutturati o non strutturati, testo o binario, formato compound (zip). Un uso generale indica non solo la possibilit di una qualsiasi elaborazione/presentazione: datamining, report, etc, ma anche la possibilit manuale o automatica di elaborazione o di business processing. Il termine piattaforma sicura, comporta la sua integrazione con linfrastruttura aziendale, tenendo conto della classe di rischio in gioco, prendendo ogni precauzione di sicurezza (protocolli, sicuri, firewall per isolare in un verso i dipartimenti dellINTRANET da ci che offerto su INTERNET etc) e disponendo, anche di un sistema software Identity Manager, che permetta la profilazione degli utenti, per fornire loro in base al profilo vari tipi di elaborazioni, report, funzionalit, etc.

Il termine ricerca, per comporta altre esigenze, nascoste in prima battuta, dalla definizione piuttosto larga vista prima di piattaforma ESR. Una ricerca, efficiente e grana fine, ha necessit di ci che sono chiamati Extended Metadata: pi ce ne sono, pi pu essere raffinata la ricerca; oppure se ci sono maggiori controlli sugli Schemi come ad esempio i Dynamic Fields. Uninformazione necessita per la ricerca di un Ranking, che permette di mandare a galla quelle che maggiormente possano essere utili al dipendente, in base ad un algoritmo dimportanza specifico; in tal modo il ranking personalizzabile in vari modi o mirato al gruppo dinteresse lavorativo, in altre parole al social network enterprise. Una ricerca comporta sempre una fase di Data extraction and derivation. Per lestrazione si possono usare tecniche Xpath, XQuery; mentre per derivare i dati si possono usare tecniche di knowledge base esterne/interne allenterprise: Database RDBMS, RDF Store, D2RDF (vedi database d2r-server), OWL Store, etc. Gli stessi database RDBMS e ORDBMS, si prevede, che evolveranno ancora sotto la spinta innovativa ed utile delle Ontologie e del Knowledge Management; ne esistono molti altri nuovi che stanno nascendo. Per lESR richiesto, come per qualsiasi piattaforma, che possa essere gestita e monitorata on the fly e in real time, sfruttando risorse JMX. Una piattaforma ESR deve fornire un accesso utente per la ricerca; ma per questo evidente che esiste una sostanziale differenza tra il Web Search e lEnterprise Search. Il Web Search concentrato innanzitutto sulla vendita di pubblicit alla massa di persone che vi accede e, di conseguenza, le videate per la ricerca sono minimizzate e generiche (focus on advertising) e con pochi criteri di scelta. UnEnterprise Search focalizzata proprio sulla sua rapidit, la ricchezza dinformazioni fornite e le modalit di ricerca. Inoltre laudience delle informazioni ristretta o di gruppo (non orientata alla massa), le schermate sono pi specializzate e orientate alla presentazione efficace del concetto da rappresentare, usando tecniche ontologiche, classificazioni e tassonomie. La profilazione e lIdentity Management spingono ancora di pi alla customizzazione secondo il profilo del dipendente; per cui c anche una diversa fruibilit delle informazioni. UnEnterprise Search, per, pu far leva anche sulle possibilit di raggruppamento: fields collapsing, faceted search & clustering. Una piattaforma ESR non una banalit e richiede anche altri requisiti: Scalabilit e performance Ricchezza di Funzionalit Maneggiabilit Flessibilit Facile manutenzione Rapido problem solving Riduzione dei costi di ownership

Architettura Logica

Larchitettura logica di una piattaforma ESR si presenta come uno Stack tecnologico basato su almeno le seguenti parti: Collection Process Publication Process Enrichment Process

Nella parte processo di Collezione dati osserviamo la parte Sorgenti. Per Sorgenti nellESR intendiamo: Documenti di qualsiasi formato Di ogni tipo: strutturato, non strutturato, testuale o binario, compound Localizzate ovunque Con necessit di sicurezza

La parte Content Inbound dove arrivano i contenuti in ingresso alla piattaforma ESR e prevede tre modalit di collezione dei dati: Modalit Pull - crawling semantico e non, spidering, dove agenti software navigano in rete (Internet, Intranet & extranet, macchina) e collezionano i dati di interesse, indicizzandoli come vedremo di seguito; Modalit Pull Harvesting, collezionando dati su Database, Content Repository, Management System, Webservices Inbound. modalit Push: Webservices (SOAP/REST), Real time Indexing

La parte Content Validation dove avvengono le validazioni sintattiche, semantiche per qualsiasi direzione di flusso (anche per le eventuali risposte); inoltre gestisce le eccezioni che si verificano. Per le validazioni sintattiche lESR si avvale in alternativa di: DTD XML-Schema

Per le validazioni semantiche lESR si avvale di: 3

Groovy XPath Regex Etc

La validazione si pu avere sia durante lInbound, sia durante lEnrichment. Il processo di Content Enrichment, lavora sui seguenti sotto-processi: Extraction: lavorando sui metadati e/o sul contenuto text free; Enhancing: derivando (deducendo) nuovi metadati o aggiungendoli o alterando/mappando alcuni. Filtering: rimuovendo parte dei metadati

Per tutto questo il processo fa leva su knowledge base, DB esterni e su tecniche di Conditional Enrichment. Eccoci arrivati a un altro punto cruciale: dopo aver collezionato i dati occorre un processo di Indexing, che permetter successivamente al Search Engine di cercare le informazioni rapidamente. Tali attivit coinvolgono processi di ricerca dei metadati da memorizzare indicizzati, il ranking etc. e tipicamente sono attivit pesanti fatte off-line. Passando al Publication Process, questo il processo che rende disponibili le informazioni collezionate e indicizzate. Il processo attivato dalle richieste degli utenti. La parte Request Inbound riceve le richieste in varie modalit e vari tipi di protocollo, anche nella versione sicura: http/Get: url con parametri, response in XML, JSON etc http/Post: XML request (SOAP o REST), XML response (SOAP o REST), etc API: Java, Perl, etc

La parte Request Validation riceve le richieste e le valida, sintatticamente e semanticamente: Validazione sintattica: le richieste o le query sono qui verificate sintatticamente. Validazione semantica: le richieste sono vagliate con strumenti come Groovy, Regex, etc.

Anche qua le validazioni sono o nellInbound o nellEnrichment del processo. La parte Request Enrichment lavora con due sotto processi: Redirection: o Con spelling suggestion (suggerimento ortografico), a completamento o correzione o Con Metadata suggestion: in modo analogo a quanto sopra ma riferito ai metadati Enhancing: o Per aggiungere/rimuovere clausole o Per avere parole stop words, sinonimi etc

La parte Search & Ordering, lavora con tre sotto processi: Filtering: per permette una ricerca sui campi

Grouping: per aggiungere informazioni inerenti un gruppo, oppure fare Field Collapsing, Faceted Search & Clustering Sorting: principalmente sort sui campi e tecniche di ranking

Il processo Response Enrichment inizia il processo di risposta allutente ed suddiviso nelle parti: Redirection: dove sono veicolati i suggerimenti di aiuto Enhancing: o per aggiungere/rimuovere campi o per avere degli schema information o per avere degli editorial information

Il processo Response Outbound il processo di presentazione della risposta allutente ed ha due possibili soluzioni operative rispetto allo stato delle informazioni: Stateless: o Richiede meno sicurezza o Usa soluzioni come XSLT, SolrJS Statefull o Richiede Sicurezza o Si basa sul Web 2.0 e su Web Application Framework

Prodotti per realizzare il Collection Process Sul mercato non esiste una piattaforma ESR che copra tutte le esigenze e comunque spesso non si ha il massimo controllo su esse, ma la sorpresa pi grande che possibile mettere insieme diversi prodotti Open Source maturi (vedi [DR2]). Sostanzialmente la parte di Collection Process richiede un Enterprise Service Bus (ESB) che possibile realizzare con Apache ServiceMix (ultima versione 4.3.0) e Camel, grazie allo standard Java Business Interface (JBI). LESB fornisce in questo modo le funzionalit di: Trasformers, Validation, Splitter, Filter, Routers, Scripting e si pu facilmente far leva sugli standard event-driven SOA e tutte i protocolli: WS, SMTP, SMNP, JMS, JCR, JDBC, FILE,SFTP, FTPS etc. Per il crawling esiste Apache Nutch che basa il suo funzionamento sullIndice prodotto da Lucene. Nutch ha il vantaggio che si pu estendere in Java (NuchIndexWriter) e serve come crawler che inoltra allESB i documenti trovati in modalit asincrona e push. LESB pu mantenere un flusso distribuito avvalendosi di pi macchine e in questo il Content based Routing di ServiceMix aiuta e favorisce tale tecnica. Lutilizzo di ServiceMix, basato sullo standard JBI, permette una facile gestione con Hot deploy. Architettura EIP Collection Process In termini di architettura Enterprise Integration Pattern (EIP), [DR1] il flusso del Collection Process si presenta come in figura. 5

C da aggiungere che possibile anche integrare, arricchire, memorizzare i dati, elaborarli con tecniche ETL e datamining, per ottenere predizioni/previsioni (come deduzione da aggiungere ad esempio); per cui possono essere coinvolti anche altri strumenti Open Source come Weka, oppure Rapid Miner, Rapid Net etc che hanno una miriade di funzionalit (ETL, data mining, presentation etc) oltre alla possibilit di usare le loro API da Java e integrare col resto della piattaforma. Prodotti per realizzare il Publication Process

Si pu far leva sui prodotti SOLR e Lucene per: sinonimi, stopwords, stemming, spelling, faceted search. Usando lestendibilit di framework di SOLR possibile sfruttare anche Apache Shiro per la sicurezza; mentre per la parte Stateless XSLT, SolrJS e per la parte Statefull Apache Wicket con Spring. La parte pi delicata la parte di Enrichment sia per il processo Collection che Publication. Questo perch gli attuali ESB Open Source e SOLR da soli non forniscono tutte le features necessarie. LEnrichment avviene con una o pi azioni (extraction, enhancing & filtering). La soluzione in questi casi da implementare su ServiceMix o i componenti da deployare su ServiceMix sono da acquistare.

Architettura EIP Enrichment Framework Il Framework di Enrichment utilizza in termini EIP un Pipe-and-Filters Pattern.

I documenti passano attraverso una serie di azioni e loutput di unazione input alla successiva. Sono possibili eventuali condizioni di scelta flusso e riuso di flussi e sotto flussi. Si pu utilizza Spring DML o Java DML. Un buon Enricher configurabile proprio per supportare varie cose, come: Conditional: if-then-else & switch-case-else (with regex support) o Actions: Add & remove fields and field values using expressions Expression handlers currently supported: o Field 7

o o o o o o o

Function (execute methods via Java Reflection) HttpClient (retrieve content by URL described by field values) Xslt, Xpath, Xquery (external XML databases) JDBC SparQL (OpenRDF) Apache Lucene/Solr Apache Tika (Meta and Text extraction)

Una soluzione che offre tale configurabilit con utilizzo sotto Apache ServiceMix e Karaf lEnricher Framework della Luminis, molto interessante. Inoltre un Database Open Source possibile da usare col tutto anche MySQL, anche in versione cluster.

Esempio Governo Olandese In [DR2] mostrato come esempio il governo olandese che usa una piattaforma ESR (vedi figura successiva). Tale soluzione ESR espone al pubblico tutte le informazioni attraverso i seguenti Sorgenti: Siti web pubblici con la collaborazione di tutte le agenzie governative (vedi 4) Agenzie locali governative pubblicano i dati internamente relativamente ad annunci e altre informazioni a agenzie terze parti che aggregano le informazioni e le arricchiscono con addizionali metadati e li rendono disponibili con canale RSS-feed (vedi 2). Gli RSS-feed sono retrieved su base giornaliera e contengono solo i metadati dei documenti di origine. Se fossero necessari anche i contenuti sono forniti separatamente. Webservices offerto per la pubblicazione real time ogni minuto delle informazioni (vedi 1). Attraverso il webservices possono essere pubblicati metadati e il riferimento al documento che pu essere cercato. Anche qui se fossero necessari anche i contenuti sono forniti separatamente. 8

Informazioni editoriali da un Content Management System (CMS) (vedi 4). Le informazioni editoriali sono fornite su base giornaliera e sono utilizzate per fornire suggerimenti e risultati preferiti. Qua usano come CMS Apache Jackrabbit accessibile con le API JCR (Java Content Repository). Database locale relazionale (vedi 5), di cui ogni colonna mappa un metadato dellESR. Il suo contenuto consultato su base giornaliera. Filesystem locale (vedi 6), il filesystem su base giornaliera sottoposto a tecnica pull per ricevere le informazioni.

In questa soluzione tutte le sorgenti usano differenti standard e naming convention. Per mettere ordine a tutto questo si usa lo standard Dublin Core per i metadati ([DR3]). La strategia difatti di far leva su standard aperti per lintegrazione. Riferimenti [DR1] Enterprise Integration Patterns Gregor Hohpe, Bobby Woolf [DR2]Enterprise Search in Action Marc Teutelink [DR3] Dublin core http://dublincore.org.