Oracle Secure Enterprise Search - omówienie oraz ocena praktycznej przydatności

Transkrypt

1 Oracle Secure Enterprise Search - omówienie oraz ocena praktycznej przydatności Artur Gramacki, Jarosław Gramacki Uniwersytet Zielonogórski Instytut Informatyki i Elektroniki ul. Podgórna 50, , Zielona Góra a.gramacki@iie.uz.zgora.pl, j.gramacki@iie.uz.zgora.pl Abstrakt. W artykule omówiono udostępniony w połowie 2006 roku przez firmę Oracle nowy, niezaleŝnie sprzedawany, produkt o nazwie Secure Enterprise Search (SES). Zastępuje on znany od dłuŝszego czasu moduł Ultra Search (US) dołączany bezpłatnie do wersjach 9i oraz 10g serwera bazodanowego Oracle. SES, w odróŝnieniu od US, stanowi niezaleŝny produkt instalowany w oddzielnym ORACLE_HOME (i niestety równieŝ oddzielnie nabywany). Zgodnie z oficjalnymi informacjami podawanymi przez firmę Oracle, moduł US będzie nadal dołączany do aktualnej wersji serwera 10g oraz wersji nowszych, jednak nie będzie juŝ wprowadzana do niego Ŝadna nowa funkcjonalność (utrzymywanie w tzw. trybie bug fix). W artykule pokrótce scharakteryzowano SES, pokazując jego najwaŝniejsze cechy uŝytkowe. 1. Wstęp UŜytkownicy bazy danych Oracle w wersji 9i oraz 10g z pewnością wiedzą, Ŝe jednym z wielu dostępnych w niej modułów jest moduł o nazwie Ultra Search (US) [USAdm]. Jest to w gruncie rzeczy bardzo rozbudowana nakładka na inny moduł o nazwie Oracle Text (OT) 1, który umoŝliwia wygodne i łatwe indeksowanie najprzeróŝniejszych danych (tabele bazodanowe Oracle, pliki dyskowe w wielu róŝnych formatach, np. pdf, doc, xls, strony internetowe, systemy poczty elektronicznej i inne). OT pełni w US rolę motoru indeksującego (ang. indexing engine). Zaindeksowane dane przechowywane są w repozytorium, którym jest baza danych Oracle. Dostęp do zaindeksowanych danych umoŝliwia dedykowana do tego aplikacja kliencka stworzona w technologii J2EE. Uruchamiana jest ona pod adresem: Większość czynności administracyjnych wykonywanych jest równieŝ z poziomu przeglądarki internetowej tym razem naleŝy uŝyć adresu: (domyślny port to w obu przypadkach 5620). Nabywca serwera w wersji 9i/10g otrzymuje moduł US niejako za darmo. Moduł instalowany jest jako opcja w trakcie kreowania bazy danych (zwykle robimy to z pomocą narzędzia Database Configuration Assistant 2 ). Po wykonaniu kilku (dość prostych) czynności konfiguracyjnych [3, rozdział 2] system jest gotowy do pracy. W przypadku SES twórcy przyjęli diametralnie inne załoŝenie co do sposobu jego dystrybucji. Tym razem jest to całkowicie niezaleŝny produkt 3, który moŝe być instalowany niezaleŝnie od istniejących juŝ na dysku innych produktów Oracle. Proces instalacji jest w tym przypadku maksymalnie uproszczony uŝytkownik musi w zasadzie wskazać tylko katalog, w którym system zostanie zainstalowany, podać port, na którym będzie działać aplikacja kliencka, hasło administratora oraz nazwę tworzonego serwera. Wszystkie te parametry podajemy w pierwszym oknie programu Universal Installer, a dalej proces instalacji przebiega juŝ całkowicie automatycznie. Po zainstalowaniu systemu okazuje się, Ŝe SES to nic innego jak kolejna instancja bazy danych Oracle wraz z serwerem aplikacyjnym zrealizowanym w technologii OC4J w wersji standalone [OC4J]. 1 Oracle Text moŝe być oczywiście uŝywany zupełnie niezaleŝnie i na przykład uŝywany w dowolnych aplikacjach uŝytkowych. 2 W przypadku serwera w wersji 10.2 w drugim okienku kreatora naleŝy wybrać opcję Custom Database a następnie w okienku dziesiątym wybrać komponent Oracle Ultra Search. 3 NaleŜy wykupić stosowną licencję, która do tanich nie naleŝy. Orientacyjne koszty: 30000$/CPU lub 60$ za nazwanego uŝytkownika.

2 Mamy więc do czynienia z sytuacją, którą moŝna by obrazowo ująć następująco: stare (i sprawdzone) narzędzie w nowym opakowaniu. Oczywiście SES wprowadza pewne zmiany i ulepszenia w stosunku do pierwotnego modułu US, jednak ogólna koncepcja (a więc uŝycie modułu Oracle Text wraz z repozytorium w postaci bazy danych Oracle) pozostaje niezmieniona. Niestety w Ŝadnym miejscu w dokumentacji [SESAdmin] nie znajdziemy informacji na ten temat. Firma Oracle najwyraźniej postanowiła promować SES jako całkowicie nowe, niezaleŝne i zamknięte środowisko zarządzane wyłącznie z poziomu internetowej aplikacji administracyjnej 4. Co więcej w dokumentacji [2, strona 4-1] wyraźnie zaznaczono, Ŝe ręczne czynności administracyjne (np. z poziomu programu SQL*Plus) są niewskazane. Jest to zdaniem autorów nieco dziwne podejście, gdyŝ nie moŝna całkowicie wykluczyć róŝnych sytuacji awaryjnych na poziomie serwera bazodanowego i wówczas nie będzie innego wyjścia jak próbować uratować zgromadzone dane w jakiś klasyczny dla serwerów Oracle sposób. Czynności administracyjne dostępne z poziomu aplikacji internetowej sprowadzają się w zasadzie wyłącznie do moŝliwości zmiany hasła administratora (de facto jest to hasło uŝytkownika SYS) oraz wykonywania backup-u ustawień konfiguracyjnych SES-a. W nazwie nowego produktu pojawia się słowo Secure. Wyjaśnijmy więc w jakim kontekście jest ono uŝyte. OtóŜ zakres działania systemu SES jest nieco szerszy niŝ klasycznych wyszukiwarek typu Google, gdzie niemalŝe z definicji zakłada się, Ŝe wszystkie zaindeksowane dane stają się dostępne dla kaŝdego zainteresowanego. UŜytkownicy takich wyszukiwarek, aby korzystać z ich zasobów, nie muszą się w Ŝaden sposób autoryzować. W przypadku systemu SES wygląda to nieco inaczej. SES moŝe być uŝywany w dwojaki sposób. MoŜe on indeksować dane ogólnodostępne (głownie zlokalizowane w internecie) jak równieŝ dane, do których dostęp musi być ograniczony tylko do wybranej grupy uŝytkowników. Klasycznym przykładem są tutaj zasoby korporacyjnych sieci Intranet, gdzie dostęp do róŝnych danych musi być ściśle kontrolowany. Aby z poziomu systemu SES skorzystać z takich danych, naleŝy się wcześniej prawidłowo autoryzować. Secure w systemie SES naleŝy więc rozumieć jako zapewnienie autoryzowanego dostępu do danych, które oczywiście same w sobie powinny być odpowiednio zabezpieczone przed ewentualnymi intruzami. 2. Struktura systemu SES Jak wspomniano w poprzednim rozdziale, produkt Secure Enterprise Search przygotowano w taki sposób, aby był praktycznie gotowy do uŝycia zaraz po zainstalowaniu i nie wymagał wykonywania Ŝadnych wstępnych czynności konfiguracyjnych 5 (brak opcji znanej jako Post-installation Tasks). Tak teŝ jest w istocie, choć aby wykorzystać pełne moŝliwości, jakie oferuje SES nie obejdzie się bez złoŝonego i czasochłonnego dostrajania systemu. W systemie Windows w grupie Start Menu tworzony jest folder Oracle - ses pokazany na Rysunku 1. Rys. 1. Panel administracyjny systemu SES Dwie pierwsze pozycje przenoszą nas do przeglądarki internetowej do modułów odpowiednio administratora (Rysunek 2) oraz zwykłego uŝytkownika (Rysunek 3) 6. Trzecia i czwarta opcja słuŝą jak łatwo się domyślić do uruchomienia oraz zamykania systemu. 4 Dostęp z adresu: 5 Domyślnie komunikacja pomiędzy aplikacją (aplikacjami) klienta a motorem SES nie jest szyfrowana (SSL wyłączony). MoŜna to jednak zmienić odpowiednio przekonfigurowując system szczegóły patrz dokumentacja [SESAdmin]. 6 Dostęp z adresu:

3 Rys. 2. Wygląd przykładowej strony z modułu administratora Rys. 3. Wygląd przykładowej strony modułu uŝytkownika (patrz teŝ opis w tekście) Jak wspomniano w rozdziale pierwszym, SES to w gruncie rzeczy odpowiednio skonfigurowana instancja serwera bazodanowego Oracle wraz z warstwą serwera aplikacyjnego działającego w warstwie pośredniej (ang. middle tire) zrealizowanej na bazie OC4J (ang. Oracle Containers for J2EE) w wersji standalone [OC4J] 7. Start systemu oznacza wiec w praktyce uruchomienie trzech komponentów: serwera bazodanowego, programu nasłuchującego (ang. listener), warstwy serwera aplikacyjnego. 7 MoŜna jednak tak skonfigurować system, aby wszystkie Ŝądania do SES-a przyjmowane były najpierw przez niezaleŝny Oracle HTTP Server, który korzystając z modułu mod_oc4j przekaŝe następnie Ŝądanie (poprzez protokół AJP13) do OC4J-a systemu SES. Komunikację między Oracle HTTP Server a OC4J SES naleŝałoby wówczas zabezpieczyć za pomocą SSL-a.

4 Łatwo odszukać te elementy na liście usług systemowych (patrz Rysunek 4). Rys. 4. Komponenty systemu SES 2.1. Roboty internetowe (ang. crawlers) w systemie SES Właściwe działanie systemu SES oparte jest na pracy tzw. robotów internetowych (ang. crawler. Dla uproszczenia będziemy je nazywać krótko robotami). Robot to program (w systemie SES jest on napisany w czystej Javie, działa jako wielowątkowy proces), którego zadaniem jest odczytywanie danych z róŝnych źródeł zdefiniowanych wcześniej przez administratora systemu oraz ich indeksowanie 8. Indeksowanych moŝe być kilka predefiniowanych źródeł są to: strony internetowe, dane przechowywane w bazie Oracle, pliki dyskowe, serwery pocztowe (tylko IMAP), dane z OracleAS Portal. Mogą być równieŝ indeksowane inne źródła, nawet bardzo nietypowe i zamknięte. Wymagane jest wówczas samodzielne oprogramowanie w języku Java pewnych elementów patrz informacje na ten temat podane w rozdziale 4. Na Rysunku 5 pokazano umiejscowienie robota w całym systemie SES. Pojawiające się na rysunku bloki o nazwach Crawler Plug-in oraz Remote Application nie wchodzą w skład instalacyjnej wersji produktu (uŝytkownik musi je sam utworzyć) i będą omówione nieco dokładniej w dalszej części artykułu. Uruchomienie robota moŝe odbywać się ręcznie lub teŝ moŝe być on uruchamiany automatycznie co określony odstęp czasu. Rys. 5. Komponenty systemu SES (rysunek zaczerpnięto z [SESAdmin]) 8 Indeksowaniem zajmuje się moduł Oracle Text, który jest jednym z elementów systemu SES.

5 2.2. Moduł administratora Administrator zarządza systemem SES z poziomu aplikacji, której fragment pokazano na Rysunku 2. Domyślna nazwa uŝytkownika to eqsys. Hasło tego uŝytkownika jest równocześnie hasłem uŝytkownika SYS w bazie danych. Podstawowe czynności, jakie naleŝy wykonać, aby móc rozpocząć indeksowanie danych to: 1. Ustawienie wymaganych wartości parametrów globalnych (zakładka Global Settings). Na początku moŝna rozpocząć pracę korzystając z ustawień domyślnych). Przykładowym parametrem jest głębokość przeszukiwania stron internetowych (ang. Crawling Depth) określający ile poziomów podstron strony startowej ma być zaindeksowanych (uwaga: podanie zbyt duŝej liczby moŝe skutkować próbą zaindeksowania całego światowego interenetu!), 2. Zdefiniowanie źródeł danych (ang. Sources). Zakładka Home Sources. Źródła wybieramy na liście rozwijalnej patrz Rysunek 2. Mogą nimi być: strony WWW, tabele bazy Oracle, pliki dyskowe, poczta elektroniczna (tylko obsługiwana przez serwery IMAP), listy mailowe, zasoby OracleAS Portal, tzw. źródła sfederowane, własne źródła (dowolna ilość; definiowane przez uŝytkowników na bazie samodzielnie napisanych odpowiednich klas Java). 3. Ustalenie harmonogramu indeksowania (np. co tydzień o określonej godzinie lub teŝ ręcznie rozpocząć indeksowanie). Zakładka Home Schedules 9, 4. W przypadku indeksowania danych, do których dostęp wymaga autoryzacji zainstalowanie i skonfigurowanie systemu zarządzania toŝsamością (ang. Identity Management) Oracle Interenet Directory (OID; patrz teŝ niŝej rozdział 3) będący jednym z modułów w Oracle Application Server 10g Release 2 [AS10g, OID] 10. Po prawidłowej instalacji naleŝy podłączyć SES-a do systemu OID (zakładka Global Settings Directory Setup). Przykładowe wpisy wykonane w komputerze autorów pokazano na Rysunku 6. Komunikat w ramce świadczy o poprawnym podłączeniu. Po wykonaniu powyŝszych czynności uŝytkownicy mogą rozpocząć pracę z systemem SES. Rys. 6. Przykładowe parametry połączeniowe do Oracle Internet Directory 9 Aktualna wersja systemu SES (10.1.6) posiada błąd opisany w pliku [SESReadme]. SES nie indeksuje danych (w logach pojawia się błąd "ORA-00933: SQL command not properly ended"), gdy system operacyjny ma ustawienia regionalne inne niŝ domyślne angielskie. Jak na razie jedynym wyjściem jest zmiana tych ustawień (w Windows: Control Panel Regional Options zakładka General ustawić: English (United States). W systemie Linux ustawić zmienne systemowe: setenv LANG en_us oraz setenv LC_ALL en_us). 10 Omawiana wersja systemu SES (10.1.6) wymaga, aby Oracle Interenet Directory był w wersji lub (z ewentualnymi patch-ami). Oracle Application Server 10g Release 3 NIE zawiera wymaganego tu modułu! Musimy więc uŝyć Oracle Application Server 10g Release 2.

6 2.3. Moduł uŝytkownika Przykładowy wygląd strony uŝytkownika pokazano na Rysunku 3. WaŜniejsze elementy zostały ponumerowane i poniŝej, w duŝym skrócie, zostaną opisane: Nr Opis Tabela 1. Opis elementów pokazanych na Rysunku 3 1 UŜytkownik wpisuje poszukiwane hasła w klasyczny sposób, znany z innych popularnych wyszukiwarek. 2 Domyślnie przeszukiwane są wszystkie zaindeksowane zasoby. Administrator moŝe jednak pogrupować je w tzw. grupy źródeł (ang. Source Groups) i wówczas moŝna zawęzić obszar poszukiwania do jednego wybranego źródła. Nie ma ograniczeń tego typu, Ŝe w jednej grupie muszą znajdować się dane tylko z jednego źródła (np. w grupie Dokumenty mogą być dane zarówno ze źródeł internetowych, jak i ze źródeł plikowych). 3 UŜytkownik otrzymuje znalezione dane w formie zbliŝonej do tej, w jakiej wyświetlane są wyniki z innych popularnych wyszukiwarek typu Google. Wszystkie zaindeksowane dane są buforowane w systemie SES. Przykładowy wygląd takich danych pokazano na Rysunku 7 (poszukiwane frazy są pokolorowane). Buforowanie moŝna jednak wyłączyć w zakładce Global Settings a poźniej Crawler Configuration. 4 Administrator ma moŝliwość zdefiniowania synonimów (ang. Alternate Words), które SES będzie podpowiadał. MoŜna ten mechanizm wykorzystać do zaimplementowania czegoś w rodzaju automatycznego korektora pisowni. NaleŜy jednak zauwaŝyć, Ŝe w obecnej wersji SES NIE potrafi importować danych z zewnętrznych źródeł a ręczne tworzenie słowników jest bardzo czasochłonne. Omawiane tu elementy definiuje się w zakładce Search. 5 Administrator ma moŝliwość zdefiniować tzw. łącze sugerowane (ang. Suggested Links). Definiuje się je w zakładce Search. Mogą one mieć charakter pomocy merytorycznej lub teŝ mieć znaczenie marketingowo-reklamowe. Stronę gdzie następuje definiowanie tych łącz pokazano na Rysunku 8. 6 System SES udostępnia moŝliwość doprecyzowania kryterium poszukiwania. 7 SES udostępnia bardzo ciekawą funkcję. Wybierając mianowicie łącze Prześlij adres URL, uŝytkownik moŝe wysłać administratorowi systemu adres strony (stron), którą uwaŝa za wartą do zaindeksowania. Administrator moŝe wówczas zdecydować, czy daną stronę zaindeksować, czy teŝ nie. Wszystkie zasugerowane przez uŝytkowników strony trafiają do załoŝonej w tym celu grupy źródeł (patrz opis punktu 2). 8 Opcja Zaloguj nie pojawia się automatycznie po zainstalowaniu systemu SES. Stanie się ona dostępna dopiero po zainstalować i skonfigurować system zarządzania toŝsamością.. Więcej szczegółów podano niŝej w rozdziale 3. Rys. 7. Przykładowy wygląd okna z wynikami poszukiwań. Szukana fraza jest zaznaczona innym kolorem. Wyniki są wewnętrznie buforowane w systemie

7 Rys. 8. Przykładowe okno do definiowania tzw. łączy sugerowanych 3. Secure w SES 3.1. Uwagi wstępne Jak wspomniano w rozdziale 1 SES stworzony został z myślą o zapewnieniu wygodnych mechanizmów indeksowania zarówno danych o charakterze publicznym jak i danych poufnych. W pierwszym przypadku sprawa wydaje się być dość oczywista naleŝy zapewnić, aby system potrafił szybko i dokładnie indeksować duŝe ilości danych o bardzo róŝnej strukturze. PoniewaŜ SES korzysta ze sprawdzonego i dobrze juŝ dopracowanego modułu Oracle Text [Text], więc indeksowanie danych publicznych nie stanowi tu problemu. W przypadku danych poufnych pojawiają się dwa bardzo waŝne zagadnienia. Po pierwsze robot internetowy musi być zdolny dostać się do chronionych danych. Innymi słowy musi w jakiś sposób potrafić automatycznie uwierzytelnić się (np. podać wymaganą nazwę uŝytkownika i hasło) lub teŝ wejść do chronionych zasobów będąc obdarzonym przez nie odpowiednim zaufaniem (ang. trusted). Wówczas dopiero dane mogą zostać zaindeksowane i udostępnione w module uŝytkownika (patrz podrozdział 2.3). Z drugiej strony zaindeksowanie pewnych danych nie oznacza automatycznie, Ŝe staną się one dostępne dla kaŝdego zainteresowanego. Pojawia się więc kolejne sito, którego zadaniem jest ograniczanie dostępu do zaindeksowanych danych dla nieautoryzowanych uŝytkowników. System SES wspiera powyŝsze działania, jednak nie robi tego samodzielnie. Musi bowiem współpracować z systemem zarządzania toŝsamością (ang. Identity Management) Oracle Interenet Directory (OID) będącym jednym z modułów w Oracle Application Server 10g Release 2. Dopóki administrator nie połączy systemu SES z OID, ten pierwszy moŝe działać tylko w obszarze danych udostępnianych publicznie. Innymi słowy wszystko co SES zdoła zaindeksować, zostanie udostępnione publicznie. Zwróćmy w tym miejscu uwagę na to, Ŝe SES moŝe zaindeksować dane, które same w sobie nie są publiczne (np. jakąś kolumnę w tabeli Oracle) i następnie udostępnić je publicznie. Nie mamy więc na razie do czynienia z autoryzacją (ang. authorization) 11 na poziomie 11 authorization (autoryzacja) - potwierdzenie uprawnień lub uprawnienie kogoś do zrobienia czegoś. Na przykład centra autoryzacji kart kredytowych autoryzują transakcje nimi dokonywane. Słowo "autoryzacja" jest często mylone z authentication, patrz teŝ kolejny przypis. Źródło:

8 poszczególnych uŝytkowników systemu SES a jedynie z uwierzytelnieniem (ang. authentication) 12 na poziomie administratora systemu SES Uwierzytelnianie (ang. authentication) RozwaŜmy przykład, w którym tworzymy źródło danych bazujące na tabeli Oracle (ang. Table Source). Wówczas administrator systemu SES wpisuje dane uwierzytelniające, czyli w tym przypadku parametry dostępowe do tabeli. Pokazano to na Rysunku 9. Po zaindeksowaniu danych stają się one natychmiast dostępne z poziomu modułu uŝytkownika SES. Mówimy wówczas o tzw. uwierzytelnianiu na poziomie administratora (ang. Admin-based Authentication). Rys. 9. Definiowane źródła danych bazującego na tabeli Oracle W przypadku innych źródeł danych (np. stron WWW) bardzo często uwierzytelnianie odbywa się w formularzach HTML, gdzie uŝytkownik wpisuje właściwą nazwę oraz hasło. SES w takich sytuacjach potrafi samodzielnie w czasie indeksowania (bez udziału kogokolwiek) wpisać wymagane dane do pól formularza. Mówimy wówczas o tzw. uwierzytelnianiu na poziomie formularza (ang. Form-based Authentication). Oczywiście administrator w czasie tworzenia tej formy uwierzytelniania musi pierwszy raz ręcznie podać poprawne dane do formularza. Opisane powyŝej metody uwierzytelniania wymagają, aby administrator w czasie ich konfigurowania podał wymagane parametry (najczęściej jest to nazwa uŝytkownika i jego hasło). Oczywiście administrator nie zawsze zna lub moŝe znać te dane. MoŜna wówczas wdroŝyć jeszcze inne rozwiązania. Chodzi tutaj o tzw. uwierzytelnianie samoobsługowe (ang. Self Service Authentication). Wówczas właściciel danych dokonuje ich uwierzytelnienia niejako w imieniu administratora. UŜytkownik obdarzony zaufaniem przez administratora moŝe samodzielnie uwierzytelnić się i tym samym zlecić indeksowanie danych. Po zalogowaniu się do systemu SES z poziomu modułu uŝytkownika w prawym górnym rogu pojawia się dodatkowe łącze o nazwie Dostosuj. Pokazano to na Rysunku 10. Rys. 10. Łącze Dostosuj pojawiające się w module uŝytkownika w wyniku uŝycia Self Service Authentication 12 authentication (uwierzytelnienie) - potwierdzenie swojej toŝsamości, stwierdzenie Ŝe dany podmiot jest tym, za kogo się podaje. A więc: podczas logowania do systemu uwierzytelniamy się przedstawiając mu dowody swojej toŝsamości (ang. credentials) w postaci nazwy uŝytkownika (login) i hasła. Słowo to pochodzi od potwierdzania autentyczności, jednak w języku polskim raczej nie mówi się Ŝe osoba jest autentyczna, stąd problemy z tłumaczeniem. Często spotykany w polskich tekstach potworek stanowiący kalkę z angielskiego to słowo autentykacja, czy jeszcze straszniejszy autentyfikacja. Prosimy unikać. Źródło:

9 Inną metodą uwierzytelniania wspieraną przez SES jest tzw. funkcjonalność jednokrotnego uwierzytelniania (ang. Single Sing-On Authentication). Aby jednak wdroŝyć to rozwiązanie musimy zainstalować oraz skonfigurować serwer aplikacyjny Oracle Application Server Autoryzacja (ang. authorization) Omówione w poprzednim podrozdziale uwierzytelnianie zapewniało tylko (albo aŝ) to, Ŝe SES był w stanie indeksować dane o charakterze poufnym. Jednak po ich zaindeksowaniu stają się one dostępne dla kaŝdego uŝytkownika systemu SES, czyli de facto są ogólnie dostępne. Aby ograniczyć dostęp do poufnych danych tylko dla wybranych uŝytkowników, naleŝy jeszcze dodatkowo skonfigurować uprawnienia do zaindeksowanych zasobów. UŜytkownik w rozumieniu systemu SES to uŝytkownik, który jest zdefiniowany w systemie zarządzania toŝsamością Oracle Interenet Directory. Na Rysunku 11 pokazano przykładowe ekran z modułu administratora, gdzie pokazano, w jaki sposób ustawia się autoryzację w oparciu o tzw. listę kontroli dostępu (ang. Access Control List) do indeksowanych danych. Wpisany uŝytkownik orcladmin jest uŝytkownikiem zdefiniowanym w OID. Na rysunku widać równieŝ pozycję Querytime Filtering. Jest to kolejna moŝliwość autoryzowania uŝytkowników. Wymagane jest tutaj napisanie odpowiedniej klasy w języku Java, która będzie w locie sprawdzała uprawnienia uŝytkowników. Gdy okaŝe się, Ŝe uŝytkownik chce oglądać dokumenty, do których nie ma wystarczających uprawnień, nie zostaną mu one pokazane na stronie WWW. Rys. 11. Ustawianie autoryzacji dla przykładowego źródła danych Dokładniejsze omówienia zagadnień autoryzacji uŝytkowników w systemie SES wymagałoby wcześniejszego omówienia (dość złoŝonych) spraw związanych z działaniem i konfiguracją Oracle Interenet Directory co wykracza poza zakres artykułu. Osoby zainteresowane mogą sięgnąć do dostępnej literatury [AS10g]. 4. Java API System SES, mimo Ŝe bardzo rozbudowany i funkcjonalny, moŝe czasami nie zapewniać wymaganej przez uŝytkownika funkcjonalności. NaleŜy równieŝ spodziewać się, Ŝe przyszli uŝytkownicy będą chcieli zintegrować wizualnie wyszukiwarkę SES z istniejącymi juŝ w przedsiębiorstwie systemami. Do dyspozycji mamy wówczas następujące Java API:

10 Web services API: słuŝy do tworzenia własnych aplikacji klienckich przeszukujących zaindeksowane przez system SES dane, Crawler Plug-in API: daje moŝliwość indeksowania indywidualnych danych uŝytkowników, które nie są rozpoznawane przez SES, Query Time Authorization API: filtrowanie wyników poszukiwać celem sprawdzenia, czy dany uŝytkownik posiada wymagane uprawnienia do oglądania dokumentów. Dokument zostanie umieszczony w wynikach wyszukiwania dopiero po tym, jak zostanie sprawdzony pod kątem uprawnień dostepowych, URL Rewriter API: daje moŝliwość podmiany w locie adresów URL pojawiających się na stronie z wynikami wyszukiwania. PoniŜej opisano dwa pierwsze rodzaje Java API. Opis pozostałych (w praktyce prawdopodobnie rzadziej uŝywanych) moŝna znaleźć w dokumentacji systemu SES Web Services API UŜycie Web Services API ma zastosowanie w sytuacji, gdy uŝytkownik końcowy potrzebuje dopasować interfejs do swoich specyficznych wymagań nie zawsze przecieŝ oracle-owy wygląd aplikacji klienckiej SES będzie współgrał wizualnie z innymi uŝywanymi aplikacjami. Dodatkową zaletą własnej aplikacji dla klienta jest to, Ŝe moŝe być ona osadzona na dowolnym serwerze WWW (wspierającym oczywiście środowisko Javy). Aplikacje taką tworzymy z wykorzystaniem technologii Web Services [Zak06, Moz04]. SES udostępnia odpowiednie komponenty usług sieciowych osadzone w warstwie middle-tire serwera OC4J będącego jednym ze składników SES-a. Wgląd w strukturę poszczególnych funkcji dostępny jest pod adresem gdzie mamy dostęp do dokumentu WSDL, do formularzy do testowania poszczególnych funkcji oraz do gotowej klasy pośrednika (ang. proxy/stub) (w wersji źródłowej i skompilowanej). Stronę główną SES Web Services oraz stronę z formularzem do testowania przykładowej funkcji (tu: dooraclesimplesearch) pokazano na Rysunku 10. Rys. 10. Strona główna SES Web Services oraz strona z formularzem do testowania przykładowej funkcji

11 Rysunek 11 pokazuje architekturę SES Web Services. Aplikacja klienta moŝe wywoływać usługi sieciowe albo poprzez bezpośrednie wysyłanie komunikatów SOAP do serwera lub teŝ korzystać z dostarczonej biblioteki klas proxy (to drugie rozwiązanie jest oczywiście wygodniejsze dla uŝytkownika). Rys. 11. Architektura SES Web Services (rysunek zaczerpnięto z [SESAdmin]) PoniŜej zamieszczono kod prostej strony jsp [2, strona 6-21] uŝywającej wspomnianą wyŝej bibliotekę klas proxy. Demonstruje on podstawową funkcjonalność aplikacji klienckiej SES. WaŜniejsze elementy pogrubiono: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " <%@ page contenttype="text/html; charset=utf-8"%> <%@ page import="java.util.vector"%> <%@ page import="java.net.url"%> <%@ page import="java.util.properties"%> <%@ page import="java.util.hashmap"%> <%@ page import="org.apache.soap.*"%> <%@ page import="oracle.soap.transport.http.oraclesoaphttpconnection"%> <%@ page import="oracle.soap.encoding.soapenc.encutils"%> <%@ page import="oracle.search.query.webservice.client.*"%> <% // Get the search term entered by the user String searchterm = request.getparameter("searchterm"); if (searchterm == null) searchterm = ""; // Define the result element array. ResultElement[] reselemarray = null; // ResultElement is one // of the proxy Java classes int estimatedhitcount = 0; if (searchterm!= null &&!"".equals(searchterm)) { // Create the Oracle SES Web Services client stub OracleSearchService stub = new OracleSearchService(); // Set the Oracle SES Web Services URL.

12 // The URL is stub.setsoapurl(" // Get the search result by calling OracleSearchService.doOracleSearch() OracleSearchResult result = stub.dooraclesimplesearch( searchterm, new Integer(1), new Integer(10), Boolean.TRUE, Boolean.TRUE, Boolean.TRUE); // Get the estimated hit count by calling OracleSearchResult.getEstimatedHitCount() estimatedhitcount = result.getestimatedhitcount().intvalue(); // Get the search results reselemarray = result.getresultelements(); } %> <html><head><title>oracle SES Web Services Demo </title> </head> <body><form name="searchbox" method="post" action="./ses.jsp"> <input id="inputmain" type="text" size="40" name="searchterm" value="<%=searchterm%>"></input> <input type="hidden" name="searchterm" value="<%= searchterm %>"></input> <input type="submit" name="action" value="search"></input> </form><br></br><br></br><br></br> <% // Render the search results if (reselemarray == null reselemarray.length == 0) { %> <h3>there are no matches for the search term</h3> <% } else { %> <h3> There are about <%=estimatedhitcount%> matches </h3> <% for (int i=0; i<reselemarray.length; i++) { String title = reselemarray[i].gettitle(); if (title == null) title = "Untitled Document"; %> <p> <b> <a href="<%=reselemarray[i].geturl()%>"><%=title%></a> </b> <br> <%=reselemarray[i].getsnippet()%> </br> </p> <% }} %> </body></html> Aby skompilować i uruchomić powyŝszą aplikację naleŝy do zmiennej CLASSPATH dołączyć następujące wpisy: $ORACLE_HOME/search/lib/search_query.jar (The proxy Java libraries) $ORACLE_HOME/oc4j/soap/lib/soap.jar

13 $ORACLE_HOME/oc4j/j2ee/home/lib/http_client.jar $ORACLE_HOME/xdk/lib/xmlparserv2.jar $ORACLE_HOME/lib/mail.jar $ORACLE_HOME/lib/activation.jar Dodatkowo moŝna ze strony domowej systemu SES [SESHome] pobrać bardziej rozbudowaną aplikację kliencką 13, mogącą słuŝyć jako materiał wzorcowy przy tworzeniu własnych rozwiązań. Jest ona dostarczana w postaci gotowego do udostępnienia (ang. deploy) pliku ear. Na początku najwygodniej przetestować działanie aplikacji demonstracyjnej po udostępnieniu jej w niezaleŝnym serwerze OC4J w wersji standalone 14 ( wersja 10g Release 3 posiada juŝ wygodną konsolę administracyjną dostępną pod adresem: i deploying w tym środowisku jest banalnie prostym zadaniem). Innym praktycznym przykładem uŝycia SES Web Services jest strona gdzie firma Oracle wykorzystała system SES do zaindeksowania pewnej części swoich zasobów. Więcej szczegółów na temat tego projektu moŝna znaleźć w dokumencie [CSI] Crawler Plug-in API UŜycie Crawler Plug-in API ma zastosowanie w sytuacji, gdy uŝytkownikom nie wystarcza funkcjonalność oferowana przez predefiniowane źródła danych (a więc strony WWW, tabele bazy Oracle, pliki dyskowe, poczta elektroniczna, listy mailowe, zasoby Oracle AS Portal oraz tzw. źródła sfederowane). MoŜe się np. zdarzyć, Ŝe będziemy chcieli indeksować repozytoria o strukturze nieznanej systemowi SES (np. pliki jakiejś specyficznej aplikacji). Wówczas powinniśmy uŝyć dostarczanej z systemem SES biblioteki Java API i napisać odpowiednią tzw. wtyczkę (ang. plugin) do systemu. W praktyce sprowadza się to do utworzenia odpowiedniej klasy Java oraz zarejestrowanie jej jako nowego typu źródła danych (wybieramy z listy rozwijalnej pozycję User-Defined patrz Rysunek 2). Dostarczane wraz z systemem SES Java API zawiera dwa interfejsy (Crawler- PluginManager oraz CrawlerPlugin), które naleŝy zaimplementować. Zadaniem utworzonego pluginu jest pobranie atrybutów oraz zawartości indeksowanych dokumentów i przekazanie ich do robota internetowego celem ich zaindeksowania (patrz Rysunek 11). Pakiet instalacyjny SES-a zawiera trzy przykładowe wtyczki, które mogą słuŝyć jako wzór przy pisaniu własnych kodów. MoŜna je znaleźć w katalogu $ORACLE_HOME/search/sample/agent/. Rys. 11. Działanie Clawler Plug-in API (rysunek zaczerpnięto z [SESAdmin]) 13 W chwili pisania artykułu była ona do pobrania pod adresem: 14 Do pobrania ze strony

14 5. Podsumowanie W artykule omówiono najwaŝniejsze elementy nowego produktu firmy Oracle o nazwie Secure Enterprise Search (SES). Jest to niezwykle interesująca oferta (choć nie naleŝąca do tanich!) dla uŝytkowników, którzy potrzebują wydajnego systemu do indeksowania i udostępniania w internecie duŝych ilości danych o bardzo róŝnej strukturze i pochodzeniu (np. strony interenetowe, plik pdf, doc, zasoby portali korporacyjnych, poufne dane z poczty elektronicznej itd). Wydaje się, Ŝe SES nie ma w tej chwili godnej konkurencji. NaleŜy jednak zauwaŝyć, Ŝe reklamowanie przez firmę Oracle systemu SES jako gotowego natychmiast do uŝycia (out-of-the-box) jest informacją nieco na wyrost. Po zainstalowaniu SES-a administrator musi jeszcze spędzić wiele czasu na właściwym jego skonfigurowaniu. Naprawdę sporo pracy trzeba włoŝyć, aby wykorzystać moŝliwości systemu SES w zakresie indeksowania i udostępniania danych o charakterze poufnym. NaleŜy bowiem, oprócz konfiguracji (wcale nie prostej!) systemu SES, zainstalować serwer aplikacyjny Oracle Application Server 10g Release 2 oraz skonfigurować jego moduł Oracle Interenet Directory. To zadanie teŝ jest raczej trudne i czasochłonne. Zwróćmy równieŝ uwagę na to, Ŝe instalacja Oracle Interenet Directory w praktyce oznacza, Ŝe pojawia nam się nowa instancja bazy danych Oracle, którą trzeba przecieŝ systematycznie administrować. PoniewaŜ SES teŝ osadzony jest na własnej instancji bazy, całość środowiska zaczyna się rozrastać. W praktyce pewnie będzie tak, Ŝe na system SES będą decydować się firmy, które posiadają juŝ na stanie jakąś bazę produkcyjną opartą na serwerze Oracle a dane z tej bazy być moŝe będą indeksowane przez SES-a. Minimalna więc konfiguracja pozwalająca wykorzystać pełne moŝliwości systemu SES to 3 instancje bazy. Bibliografia [SESHome] [SESAdm] Strona domowa systemu Secure Enterprise Search: Dokumentacja systemowa: Oracle Secure Enterprise Search Administrator's Guide 10g Release 1 (10.1.6) B , [USAdm] Dokumentacja systemowa: Oracle Ultra Search Administrator's Guide 10g Release 2 (10.2) B , [Text] Dokumentacja systemowa: Oracle Text Application Developer's Guide 10g Release 2 (10.2) B , [OC4J] Oracle Containers for J2EE: [AS10g] Oracle Application Server 10g Release 2: [OID] [SESReadme] [CSI] [Zak06] [Moz04] Oracle Internet Directory: Dokumentacja systemowa: Oracle Secure Enterprise Search Administrator's Guide 10g Release 1 (10.1.6) B , plik: Oracle Secure Enterprise Search Readme 10g Release 1 (10.1.6) for Linux x86 and Microsoft Windows Implementing a Custom Search Interface with SES - A Case Study with search.oracle.com: Zakrzewicz M.: Wprowadzenie do technologii Web Services: SOAP, WSDL i UDDI, XIII Seminarium PLOUG, Warszawa, kwiecień 2006, Morzy M.: Dostęp do komponentów EJB przez usługi Web Services, III Szkoła PLOUG, Poznań, luty 2004,