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.
8/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 2/9
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
8/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 3/9
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:
8/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 4/9
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
8/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 5/9
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.
8/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 6/9
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
8/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 7/9
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/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 8/9
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.
8/6/2019 Enterprise Search & Retrieval Platform
http://slidepdf.com/reader/full/enterprise-search-retrieval-platform 9/9
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.