Enterprise Search & Retrieval Platform

8/6/2019 Enterprise Search & Retrieval Platform

http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 1/9

1

Enterprise Search & Retrieval Platform

Rosario Turco

Uno dei temi emergenti nell’IT è 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 l’integrazione 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

l’efficienza 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 s’intende, quindi, unaqualsiasi 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, nell’ambito dell’INTRANET.

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 l’infrastruttura aziendale, tenendo conto

della classe di rischio in gioco, prendendo ogni precauzione di sicurezza (protocolli, sicuri, firewall per

isolare in un verso i dipartimenti dell’INTRANET 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.



2

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.

Un’informazione 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 d’importanza specifico; in tal

modo il ranking è “personalizzabile” in vari modi o mirato al gruppo d’interesse lavorativo, in altre parole al

social network enterprise.

Una ricerca comporta sempre una fase di “Data extraction and derivation”. Per l’estrazione si possono

usare tecniche Xpath, XQuery; mentre per derivare i dati si possono usare tecniche di knowledge base

esterne/interne all’enterprise: 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 edutile delle Ontologie e del Knowledge Management; ne esistono molti altri nuovi che stanno nascendo.

Per l’ESR è 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 l’Enterprise 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.

Un’Enterprise Search è focalizzata proprio sulla sua rapidità, la ricchezza d’informazioni fornite e le

modalità di ricerca. Inoltre l’audience 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 l’Identity Management

spingono ancora di più alla customizzazione secondo il profilo del dipendente; per cui c’è anche una diversa

fruibilità delle informazioni.

Un’Enterprise 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



3

Architettura Logica

L’architettura 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 nell’ESR 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 l’ESR si avvale in alternativa di:

DTD

XML-Schema

Per le validazioni semantiche l’ESR si avvale di:



4

Groovy

XPath

Regex

Etc

La validazione si può avere sia durante l’Inbound, sia durante l’Enrichment.

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 nell’Inbound o nell’Enrichment 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



5

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 all’utente 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 all’utente 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).

L’ESB 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 sull’Indice prodotto da Lucene. Nutch ha

il vantaggio che si può estendere in Java (NuchIndexWriter) e serve come crawler che inoltra all’ESB i

documenti trovati in modalità asincrona e push.

L’ESB può mantenere un flusso distribuito avvalendosi di più macchine e in questo il Content based Routing

di ServiceMix aiuta e favorisce tale tecnica.

L’utilizzo 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.



6

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 cuipossono 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



7

Si può far leva sui prodotti SOLR e Lucene per: sinonimi, stopwords, stemming, spelling, faceted search.

Usando l’estendibilità 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. L’Enrichment avvienecon 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 l’output di un’azione è 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



8

o Function (execute methods via Java Reflection)

o HttpClient (retrieve content by URL described by field values)

o Xslt, Xpath, Xquery (external XML databases)

o JDBC

o SparQL (OpenRDF)

o Apache Lucene/Solr

o Apache Tika (Meta and Text extraction)

Una soluzione che offre tale configurabilità con utilizzo sotto Apache ServiceMix e Karaf è l’Enricher

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.



9

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 dell’ESR. 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 l’integrazione.

Riferimenti

[DR1] Enterprise Integration Patterns – Gregor Hohpe, Bobby Woolf

[DR2]Enterprise Search in Action – Marc Teutelink

[DR3] Dublin core http://dublincore.org.

http://dublincore.org/




Documents

Enterprise Search & Retrieval Platform