IIC MAGAZINE. OPERATOR PANEL VALUE 553 str. 3. GOOGLE DLA BIZNESU str. 5

Transkrypt

1 IIC MAGAZINE III kwartał 2005 nr 6 OPERATOR PANEL VALUE 553 str. 3 GOOGLE DLA BIZNESU str. 5 AUTOMATYCZNE URUCHAMIANIE APLIKACJI Z WEBSPHERE RAPID DEPLOYMENT (WAS v6.0) str. 10

2 OD REDAKCJI Drodzy Deweloperzy, jak zapewne zauważyliście bieżący numer kwartalnika warszawskiego IBM Innovation Center trafia do Waszych rąk w zupełnie odmienionej szacie graficznej oraz pod nowym tytułem, do którego, mamy nadzieję, szybko się przyzwyczaicie. Nie poprzestaliśmy jednak na zmianach kosmetycznych, lecz zdecydowaliśmy się całkowicie zmienić również formułę magazynu, przekształcając go w pismo techniczne, czyli takie, w którym mówimy językiem środowiska inżynierskiego o sprawach, które Was naprawdę interesują. W bieżącym numerze w artykule Operator Panel Value 533 dowiecie się zatem, jak zaradzić problemom występującym przy uruchamianiu systemu AIX. Maciej Przepiórka wyjaśni natomiast, w jaki sposób stworzyć wyszukiwarkę zasobów intranetowych za pomocą WebSphere Information Integrator OmniFind. Jeżeli zaś macie wątpliwości, czy można szybko uruchamiać aplikacje J2EE na serwerze WebSphere tylko za pomocą wgrania pliku.war/.ear do odpowiedniego katalogu, koniecznie przeczytajcie artykuł pod tytułem Automatyczne uruchamianie aplikacji z WebSphere Rapid Deployment. Zachęcam do lektury i jednocześnie zapraszam do współtworzenia kolejnych wydań IIC Magazine. Mam nadzieję, że również Wy jako inżynierowie z firm partnerskich IBM zechcecie gościnnie zabierać głos na łamach naszego pisma, aby stało się ono forum dyskusyjnym, w którym będziemy dzielić się najnowszą wiedzą w dziedzinie technologii i rozwiązywać problemy techniczne, z jakimi stykacie się na co dzień. Czekamy na Wasze uwagi, komentarze i propozycje artykułów. Piszcie do nas. Aneta Dąbrowska Redaktor prowadząca aneta.dabrowska@pl.ibm.com

3 IGOR ZACHARJASZ OPERATOR PANEL VALUE 553 Poniższy artykuł rozpoczyna trzyczęściową serię, poświęconą najczęstszym problemom występującym przy uruchamianiu systemu operacyjnego AIX, ich genezie oraz możliwym rozwiązaniom. Najbardziej typowymi objawami problemów związanych ze startem systemu są następujące kody LED (lub kody Operator Panel Value widziane z ekranu zarządzania serwerami w konsoli HMC): 553, 581, oraz grupa kodów o numerach: 552, 554, 556. W pierwszej części artykułu opisany zostanie kod Następnie należy wybrać kolejno opcje: a. Access a Root Volume Group KOD 553 Proces startu systemu operacyjnego AIX może zatrzymać się na kodzie 553 w dwóch przypadkach: 1. plik /etc/inittab jest uszkodzony, nie ma go lub przy edycji ww. pliku popełniono błąd składni; 2. logiczne wolumeny /dev/hd4 ( / ) lub /dev/hd3 ( /tmp ) są przepełnione. b. Access this volume group and start a shell before mounting file systems ROZWIĄZANIE PROBLEMU: 1. Aby poradzić sobie z ww. problemami należy przygotować bootowalne medium z systemem operacyjnym z zachowaniem wersji oraz poziomu (maintenance level) identycznych z naszym system operacyjnym (można to sprawdzić komendą oslevel r). Może to być instalacyjny CD ROM lub taśma AIX-a oraz obraz mksysb. 2. Następnie w SMS serwera wybieramy nasze medium jako to, z którego system ma wystartować. 5. Następnie w celu sprawdzenia, czy nie są uszkodzone logiczne wolumeny, należy użyć komendy fsck. Możemy skorzystać z opcji p w celu automatycznego naprawienia mniejszych błędów lub z opcji y w celu automatycznego naprawienia wszystkich błędów. Poniżej przykłady użycia: fsck y /dev/hd1 fsck y /dev/hd2 fsck y /dev/hd3 fsck y /dev/hd4 fsck y /dev/hd9var 6. Następnie dla grupy rootvg warto przeformatować log systemu plików. Do tego celu służy komenda logform: /usr/sbin/logform /dev/hd8 3. Po wystartowaniu systemu z żądanego medium wybieramy opcję numer 3 Start Maintenance Mode for System Recovery. 7. Kolejnym krokiem będzie zamontowanie systemów plików. Możemy to zrobić ręcznie przy użyciu komendy mount lub poprzez wyjście z aktualnej powłoki (komenda exit lub kombinacja klawiszy ctrl+d), co spowoduje automatyczne zamontowanie wszystkich systemów plików. 8. Teraz komendą df należy sprawdzić zajętość systemów plików / oraz /tmp : df m / df m /tmp 9. W przypadku gdy któryś z nich okaże się zajęty w 100%, należy usunąć z niego niepotrzebne pliki lub zwiększyć ich rozmiar: chfs a size=+xm / chfs a size=+xm /tmp 3

4 IIC MAGAZINE III kwartał 2005 (6) O ile w grupie wolumenów rootvg pozostanie wolne miejsce, powyższe komendy spowodują rozszerzenie rozmiaru systemów plików o zadany rozmiar (x megabajtów). 10. Następnie należy sprawdzić, czy plik /etc/inittab istnieje, czy nie jest uszkodzony lub pusty, oraz czy któryś z wpisów nie jest błędny. Poniżej znajduje się przykładowy plik /etc/inittab: init:2:initdefault: brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 # Phase 3 of system boot powerfail::powerfail:/etc/rc.powerfail 2>&1 alog -tboot > /dev/console # Power Failure Detection rc: :wait:/etc/rc 2>&1 alog -tboot > /dev/console # Multi-User checks fbcheck: :wait:/usr/sbin/fbcheck 2>&1 alog -tboot > /dev/console # run /etc/firstboot srcmstr: :respawn:/usr/sbin/srcmstr # System Resource Controller rctcpip: :wait:/etc/rc.tcpip > /dev/console 2>&1 # Start TCP/IP daemons rcnfs: :wait:/etc/rc.nfs > /dev/console 2>&1 # Start NFS Daemons rchttpd: :wait:/etc/rc.httpd > /dev/console 2>&1 # Start HTTP daemon cron: :respawn:/usr/sbin/cron piobe:2:wait:/usr/lib/lpd/pio/etc/pioinit >/dev/null 2>&1 # pb cleanup qdaemon: :wait:/usr/bin/startsrc -sqdaemon writesrv: :wait:/usr/bin/startsrc -swritesrv uprintfd: :respawn:/usr/sbin/uprintfd shdaemon:2:off:/usr/sbin/shdaemon >/dev/console 2>&1 l2:2:wait:/etc/rc.d/rc 2 l2:3:wait:/etc/rc.d/rc 3 tty0:2:respawn:/usr/sbin/getty /dev/tty0 ctrmc:2:once:/usr/bin/startsrc -s ctrmc > /dev/console 2>&1 cons: :respawn:/usr/sbin/getty /dev/console Składnia pliku /etc/inittab jest następująca: Identyfikator:runelevel:akcja:komenda Plik składa się z wpisów. Każdy wpis znajduje się w oddzielnej linii i składa się z 4 pól. Każde pole oddzielone jest od następnego dwukropkiem ( : ). Identyfikator jest umowną nazwą (do 14 znaków) procesu Runlevel definiuje, w którym z runleveli dany wpis jest uruchamiany (np.:234567: uruchomi dany proces w runlevelach 2, 3, 4, 5, 6 i 7, a wpis:2: tylko w drugim). Akcja definiuje sposób, w jaki dany proces będzie traktowany: respawn uruchamia proces, jeżeli nie jest on jeszcze uruchomiony; once uruchamia proces tylko raz. Jeżeli proces się zakończy, nie uruchamia go ponownie; wait uruchamia proces i czeka na jego zakończenie przed przejściem do następnej linii w pliku /etc/inittab; off nie uruchamia procesu; sysinit komenda zostanie uruchomiona, zanim zostanie przyznany dostęp do konsoli. 11. Jeżeli w pliku zostały dokonane błędne wpisy, należy je poprawić. 12. Jeżeli pliku nie ma, jest uszkodzony lub pusty, należy go utworzyć. Aby system poprawnie wystartował, w pliku /etc/inittab wymagane są tylko trzy wpisy. Ponadto plik musi mieć uprawnienia 544 oraz należeć do użytkownika root i grupy system. Procedura założenia pliku może wyglądać następująco: export TERM=vt100 touch /etc/inittab chmod 544 /etc/inittab chown root:system /etc/inittab vi /etc/inintab 13. Teraz należy uzupełnić plik o /etc/inittab następujące linie: init:2:initdefault: brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 cons: :respawn:/usr/sbin/getty /dev/console 14. Po skorygowaniu pliku /etc/inittab, należy jeszcze sprawdzić, gdzie znajduje się urządzenie bootujące (/dev/hd5) oraz dokonać update u boot image. lslv m hd5 Wynik komendy może wyglądać następująco: Wynik tej komendy oznacza, że logiczny wolumen bootujący (hd5) znajduje się na fizycznym dysku hdisk Teraz przy użyciu komendy bosboot należy na dysku hdisk0 utworzyć/odświeżyć boot image: bosboot ad /dev/hdisk0 16. Kolejnym krokiem będzie ustawienie listy bootowania tak, aby pierwszym urządzeniem, na którym poszukiwany będzie boot image, był hdisk0 bootlist m norma hdisk0 17. Ostatnią rzeczą, którą warto wykonać, jest uruchomienie managera konfiguracji (cfgmgr) w celu sprawdzenia, czy nie wystąpią inne problemy z bootowaniem systemu: cfgmgr vp2 18. Teraz można już dokonać restartu serwera i sprawdzić, czy problem z kodem 553 został rozwiązany: sync;sync;sync;reboot Igor Zacharjasz w IBM Polska pracuje od 5 lat. Od 2 lat pełni rolę koordynatora zespołu technicznego IBM Innovation Center. Jest certyfikowanym specjalistą w zakresie sewerów pseries i systemu operacyjnego AIX. Współpracuje z firmami partnerskimi o profilu ISV. W centrum zajmuje się rozwiązaniami klastrowymi, testami wydajnościowymi aplikacji oraz rozwiązaniami IBM TotalStorage. Kontakt: igor.zacharjasz@pl.ibm.com 4

5 IBM CONTENT MANAGEMENT ZAPRASZA NA WALKĘ: TY KONTRA GL / ÓWNE ATRAKCJE: STARE MATERIAL / Y STARE ROZWIA ZANIA I CORAZ MOCNIEJ STARGANE NERWY DOKUMENTY, KATALOGI DANYCH, WIDEO, AUDIO - WSPÓL / PRACUJA RAMIĘ W RAMIĘ. MODUL / OWA BUDOWA - MOC WZRASTA PRZYSTĘPNA CENA, OTWARTE STANDARDY, WRAZ ZE WZROSTEM BIZNESU. WL / AŚCIWA INFORMACJA WE WL / AŚCIWYM CZASIE. KOLEJNY POKAZ SIL / Y DRUŻYNY IBM INFROMATION MANAGEMENT. IBM MIDDLEWARE. SKUTECZNOŚĆ. WYDAJNOŚĆ. IDZIESZ ZA CIOSEM. NASTĘPNA RUNDA NA IBM.COM/MIDDLEWARE/CONTENT/CC

6 MACIEJ PRZEPIÓRKA GOOGLE DLA BIZNESU Większość z nas już dawno nauczyła się przechowywać dane. Dokumenty przechowujemy w wielu repozytoriach, nie tylko w systemach plików na zdalnych serwerach, również w relacyjnych bazach danych, na stronach intranetowych, w systemach content management, czy nawet w poczcie elektronicznej. Ilość gromadzonych przez nas informacji rośnie w lawinowym tempie, a dodatkowym utrudnieniem w ich organizacji jest stale zwiększająca się liczba lokalizacji, w których je przechowujemy. Jak zatem radzić sobie z odnalezieniem danych w takim gąszczu? Czy nie byłoby wygodne przeszukiwanie firmowych zasobów podobnie, jak przeszukujemy strony internetowe? Codziennie korzystamy z wyszukiwarek internetowych, takich jak np. Google, w celu znalezienia adresów firm, danych na temat produktów czy informacji o seansach filmowych. Z reguły już pierwsza strona wyników wyszukiwania przedstawia interesujące nas informacje, mimo że pochodzą one z milionów stron o niejednolitej strukturze. IBM wprowadził produkt, który pozwoli na sprawne wyszukiwanie danych wewnątrz firmy WebSphere Information Integrator OmniFind Edition. Działa on w podobny sposób, jak popularne wyszukiwarki internetowe. Czym więc różni się OmniFind od dobrze znanego Google? Znalezienie informacji w zasobach intranetowych stawia większe wymagania niż przeszukiwanie Internetu. Dzieje się tak z kilku powodów: protokołem komunikacji w Internecie jest HTTP, ewentualnie NNTP, a zasoby firmy to również relacyjne bazy danych, systemy content management, poczta korporacyjna, sieciowe systemy plików niedostępne przez HTTP; w publicznych stronach internetowych nie ma mechanizmów bezpieczeństwa. To, co znalazła wyszukiwarka, będzie mogła odczytać każda osoba przeglądająca strony WWW. Dokumenty wewnątrz intranetu są dostępne tylko dla uwierzytelnionych użytkowników, więc dodatkowym utrudnieniem jest implementacja mechanizmów bezpieczeństwa na poziomie serwera wyszukującego i indeksującego dokumenty. W przeciwnym wypadku nieupoważnione osoby widziałyby w wynikach wyszukiwań zawartość dokumentów, do których sami nie mają dostępu; jakość wyszukiwania w dużym stopniu zależy od sposobu oceny (rankingu) dokumentu. Internetowe strony są połączone wzajemnie linkami, a ich nagłówki zawierają słowa kluczowe, które są brane pod uwagę podczas sortowania wyników. Dodatkowym ułatwieniem jest duża ilość podobnych stron, a więc duża ilość trafnych wyników wyszukiwania. Intranet to często zbiór danych różnego typu, które nie są połączone ze sobą w żaden sposób. Określenie stopnia ważności dokumentów jest dużo trudniejsze. Z drugiej strony dysponujemy takimi informacjami, jak metadane, co przy umiejętnym ich użyciu może znacznie przyspieszyć wyszukiwanie i zawęzić wyniki poszukiwań. WebSphere Information Integrator OmniFind Edition w pierwszej fazie działania pobiera dokumenty z repozytoriów, a następnie parsuje je, odrzucając dane, które nie mają znaczenia podczas wyszukiwania. Następnie buduje indeks, który od początku jest optymalizowany pod kątem szybkości i jakości wyszukiwania. Indeks zawiera także informacje o tym, które osoby mają dostęp (listy dostępu) do poszczególnych dokumentów. Wszystko zostało zaprojektowane tak, aby użytkownicy wpisujący słowa kluczowe w oknie wyszukiwarki mogli wygodnie przeszukiwać lokalne oraz zdalne bazy danych, systemy content management, wewnętrzne oraz zewnętrzne strony WWW, systemy plików i systemy pracy grupowej, a wyniki żeby pojawiały się w spójnym formacie na tej samej stronie. ARCHITEKTURA OMNIFIND Zrozumienie procesów zachodzących wewnątrz OmniFind oraz przepływu danych między poszczególnymi komponentami pozwala na poznanie możliwości tego produktu. Pięć głównych komponentów WebSphere Information Integrator OmniFind Edition to: crawler, parser, indexer, search runtime oraz admin console. Rysunek 1 przedstawia, w jaki sposób są one ze sobą połączone, oraz jakie inne elementy architektury OmniFind zawiera każdy z nich. CRAWLER Ten komponent pobiera dane z zewnętrznych źródeł w interwałach, jakie zdefiniował administrator, a następnie umieszcza je w bazie danych DB2, która pełni funkcje zbiornika danych surowych (Raw Data Store RDS). OmniFind udostepnia sześć typów crawlerów: web crawler wspierający protokoły HTTP/HTTPS oraz NNTP, enterprise data source crawler, który pobiera dane przez DB2 Content Manager oraz Lotus Web Content Management, collaboratoin crawler czytający dane z serwerów Domino, crawlery systemów plików unixowych oraz windowsowych, crawlery WebSphere Information Integrator, które umożliwiają sięgnięcie do danych poprzez wrappery relacyjne oraz nierelacyjne, crawlery napisane przez nas przy użyciu Data Listener API, które mogą czytać źródła nieobsługiwane domyślnie przez OmniFind. W praktyce oznacza to, że crawlery dostępne w OmniFind pozwalają na pobieranie danych ze stron internetowych oraz intranetowych, grup dyskusyjnych, relacyjnych baz danych (wszelkich odmian DB2, Informix, Oracle, SQL Server), systemów plików, publicznych folderów Microsoft Exchange, systemów DB2 Content Manager oraz serwisów EMC Documentum i FileNet Panagon Content. W przypadku gdy firma dysponuje źródłami danych innych typów, OmniFind udostępnia API, które pozwala na napisanie nowego typu crawlera. 6

7 GOOGLE DLA BIZNESU Rysunek 1 Każdy z takich crawlerów może skanować wiele źródeł danych jednocześnie, pracując wtedy w trybie wielowątkowym, a każdy wątek crawlera jest niezależnie konfigurowalny. Działaniem crawlera możemy sterować ręcznie, uruchamiając go na żądanie z konsoli administratora lub automatycznie, ustawiając częstotliwość, z jaką będzie uruchamiany przez proces nadrzędny. Każde kolejne uruchomienie będzie skutkowało pobraniem do Raw Data Store jedynie nowych dokumentów lub dokumentów, które uległy zmianie od ostatniej wizyty crawlera w źródle danych. W przypadku gdy dokument został usunięty ze źródła, informacje o tym będą również zapisane w RDS. PARSER Parser przygotowuje dane pobrane przez crawlery do ich indeksowania. W tym celu analizuje nie tylko dane zawarte wewnątrz każdego z dokumentów, ale również metadane. Oznacza to, że informacje, takie jak data utworzenia lub modyfikacji pliku oraz jego typ i wielkość (jeśli dokument był pobrany z systemu plików), informacje o autorze, tytule (w przypadku gdy dane pochodzą z systemu CM), czy inne dane skojarzone z dokumentem będą użyte podczas fazy wyszukiwania w celu oceny ważności takiego dokumentu bądź będą mogły zostać jawnie użyte przez osobę wyszukującą, która przykładowo zawęzi wyniki wyszukiwań do dokumentów typu PDF o wielkości powyżej 1MB utworzonych lub zmodyfikowanych w ostatnim miesiącu. Analiza, jaką przeprowadza parser, polega na wyekstrahowaniu z każdego pobranego z Raw Data Store dokumentu tekstu. W przypadku plików HTML i XML będzie to jedynie odrzucenie zbędnych tagów. W przypadku dokumentów Microsoft Word, Excel, Power Point i plików PDF jego praca będzie polegać na konwersji pliku binarnego do postaci podobnej do tekstowej, zapisanej w formacie UNICODE (parser pozostawi informacje takie, jak wielkość czcionek czy tytuły rozdziałów, ponieważ mogą mieć zasadniczy wpływ na ranking, a więc na jakość wyników wyszukiwania). Następną czynnością jest wykrycie strony kodowej oraz języka parsowanego dokumentu. Później parser analizuje strukturę paragrafów, zdań, poszczególnych słów (normalizuje wielkość liter i znaki diakrytyczne) oraz znaków białych. Poprzez analizę leksykalną, słowa złożone są dekomponowane na tokeny (Rysunek 2). Zanalizowane dokumenty są zapisywane w głównym zbiorniku danych (Main store), który nie jest przechowywany jak Raw Data Store w strukturach DB2, ale jest zbiorem plików umieszczonych na serwerze OmniFind. W praktyce pliki te podzielone są na dwie grupy: Main store, Delta store, który zawiera ostatnio parsowane dane, jeszcze nie połączone z danymi znajdującymi się w Main store. Parser działa w trybie jednowątkowym i może być uruchomiony i zatrzymany przez administratora, ale w praktyce zostaje uruchomiony po starcie serwera OmniFind i pozostawiony w takim trybie. W momencie gdy crawler pobierze dokument do Raw Data Store, parser sam się uruchomi i rozpocznie jego analizę. 7

8 IIC MAGAZINE III kwartał 2005 (6) Rysunek 2 INDEXER Indexer może być uruchamiany z regularnymi interwałami lub na żądanie administratora, w taki sam sposób, jak procesy crawlera. Struktura indeksu przechowywana jest w systemie plików jako Main index oraz Delta index. Proces indeksowania może być uruchomiony jako reorganizacja lub jako odświeżenie, a różnice są następujące: reorganizacja polega na przebudowie całego indeksu i zoptymalizowaniu jego struktury. Indexer czyta wówczas wszystkie dane wyprodukowane przez parser, które tamten zapisał w Main store oraz Delta store. Main store i Delta store są łączone, co powoduje opróżnienie Delta store. Podobnie dzieje się z Main index oraz Delta index; odświeżenie polega na zindeksowaniu jedynie tych informacji, które uległy zmianie od ostatniej reorganizacji indeksu. Indeksowanie jest procesem wymagającym dużej ilości zasobów. Częstotliwość reorganizacji i odświeżania indeksu jest determinowana wolnymi zasobami systemowymi oraz tym, czy indeksowane źródła danych są statyczne czy dynamiczne i w jakim stopniu. Aby szybko zmieniające się informacje były widoczne w wynikach wyszukiwania, należy często odświeżać indeks. SEARCH RUNTIME Komponent ten procesuje zapytania użytkownika wpisane w oknie aplikacji wyszukującej, przeszukuje indeks oraz zwraca wyniki wyszukiwań z Main store i Delta store do okna przeglądarki, odpowiednio je formatując i dodając informacje o predefiniowanych wynikach wyszukiwania (tzw. Quick links). Przepływ danych podczas wyszukiwania przedstawia rysunek 3. WebSphere Information Integrator OmniFind Edition zawiera przykładową aplikację J2EE (ESSearchApplication), która wykorzystuje Search and Index API (SIAPI) jako interfejs wyszukiwarki. Jest ona także dostarczona jako portlet dla serwera WebSphere Portal i udostępnia większość funkcji oferowanych przez OmniFind. ADMIN CONSOLE Administrowanie serwerem OmniFind jest możliwe tylko dzięki tej aplikacji J2EE. Umożliwia ona tworzenie kolekcji, czyli niezależnych od siebie zbiorów danych. Dopiero utworzenie kolekcji pozwoli na zdefiniowanie i uruchomienie crawlera i pozostałych procesów serwera. Warto zauważyć, że procesy OmniFind działają zupełnie niezależnie. Każdy z nich może być uruchomiony lub zatrzymany bez wpływu na pracę pozostałych. Jeśli przykładowo procesy crawlera, parsera oraz indexera zostaną zatrzymane, search runtime będzie mógł nadal działać i procesować zapytania. Konsola administracyjna (rysunek 4) pozwala także na monitorowanie aktywności systemu, przeglądanie logów, konfigurację użytkowników oraz ich uprawnień i dołączanie nowych aplikacji wyszukujących. To interfejs, z którego wykonujemy praktycznie wszystkie czynności poza wyszukiwaniem. KATEGORYZACJE OmniFind pozwala na definiowanie kategorii dokumentów wewnątrz każdej z kolekcji. Kategorie umożliwiają grupowanie dokumentów o podobnej charakterystyce, co w efekcie przekłada się na zawężanie wyników poszukiwań. Kategorie mogą być definiowane wielopoziomowo (powstaje wtedy drzewo kategorii), a każdy z parsowanych dokumentów może należeć do kilku z nich. WebSphere Information Integrator OmniFind Edition pozwala definiować kategorie regułowo (rule-based categorization) lub modelowo (model-based categorization). Drugi sposób dostępny jest jedynie, gdy aplikacja wyszukująca działa jako portlet WebSphere Portal. Kategoryzacja regułowa opiera się na zasadach definiowanych przez administratora. Reguły mogą opierać się na identyfikatorze URI oznaczającym pełną ścieżkę dostępu (wraz z typem źródła danych) do danego dokumentu lub na zawartości parsowanego dokumentu. Drzewo kategorii wraz z przykładowymi regułami przedstawia rysunek 5. 8

9 GOOGLE DLA BIZNESU Rysunek 3 TOPOLOGIE I WYMAGANIA SPRZĘTOWE WebSphere Information Integrator OmniFind Edition wspiera dwie topologie, jedno- i czterowęzłową. Jednowęzłowa to serwer, na którym zainstalowane są wszystkie komponenty OmniFind wraz z wymaganym przez niego oprogramowaniem: WebSphere Application Server v5.1 FixPack 1, IBM HTTP Server, WebSphere Application Server Deployment Manager v5.1 FixPack 1, DB2 UDB Enterprise Edition v8.2, oraz opcjonalnie DB2 Information Center for DB2 UDB v8.2, Lotus Domino (w przypadku architektury Windows 2000 wystarczy Lotus Notes), WebSphere Information Integrator Content Manager i WebSphere Information Integrator Content Edition. Topologia czterowęzłowa (rysunek 6) pozwala na indeksowanie znacznie większej liczby dokumentów (do kilkudziesięciu milionów) oraz zapewnia wysoką dostepność i load balancing dla serwerów wyszukiwania. Na jednym z serwerów działa moduł crawlera, na drugim komponenty parsera i indexera, a na pozostałych dwóch moduły search runtime. Wymagane oprogramowanie jest identyczne jak dla topologii jednowęzłowej. OmniFind działa na platformach Intel Linux, Windows 2000 oraz AIX 5L. Minimalne wymagania to 4 GB pamięci RAM i jeden procesor oraz około 20 GB przestrzeni dyskowej, zakładając, że średnia wielkość indeksowanego dokumentu to 20 kb, a źródła danych zawierają ich około 100 tysięcy. DLA KOGO JEST OMNIFIND? Niektórzy mogą znać inne produkty IBM, realizujące wyszukiwanie tekstowe, np. Net Search Extender oraz Text Information Extender. Choć częściowo przypominają one OmniFind, tak na prawdę różnic jest tyle samo, ile podobieństw. Poprzednie produkty działały na poziomie relacyjnej bazy danych i pozwalały na wyszukiwanie informacji zawartych w kolumnach typu CHAR, VARCHAR i CLOB, a więc budowały indeks również w tej samej bazie danych. Z wielu przyczyn rozwiązanie takie nie zawsze jest słuszne, a często wręcz niemożliwe w implementacji. OmniFind pozwala na indeksowanie dokumentów Worda i plików PDF leżących nie tylko w bazach danych w postaci kolumn BLOB, ale również w zdalnych źródłach, takich jak systemy plików, foldery Microsoft Exchange. Indeks buduje we własnych, szybszych strukturach na własnym serwerze i nie obciąża źródła danych ani podczas indeksowania ani wyszukiwania informacji. 9

10 IIC MAGAZINE III kwartał 2005 (6) Rysunek 4 Kiedy warto używać OmniFinda? Na pewno nie jest to produkt przeznaczony dla małych firm. Swoje możliwości pokaże dopiero, gdy będzie indeksował setki tysięcy, czy nawet miliony dokumentów znajdujących się w wielu lokalizacjach. Dzięki własnej strukturze indeksu szybkość wyszukiwania pozostanie bardzo duża nawet, gdy z OmniFinda będą korzystać jednocześnie tysiące osób. Więcej technicznych informacji o samym produkcie można znaleźć w RedBooku WebShpere Information Integrator OmniFind Edition: Fast Track Implementation, w którym szczegółowo omówiono proces instalacji oraz konfiguracji produktu (w architekturze jedno- i czterowęzłowej), tworzenie kolekcji, podłączanie się do wszystkich predefiniowanych typów źródeł danych, tworzenie kategorii oraz implementację mechanizmów bezpieczeństwa. editions_womnifind.html Rysunek 5 Rysunek 6 Maciej Przepiórka specjalizuje się w zagadnieniach związanych z zarządzaniem informacją od 5 lat. W IBM Innovation Center odpowiada za testy, migrację i strojenie platform relacyjnych baz danych jak również technologie Enterprise Search. Posiada doświadczenie we wdrażaniu systemów CRM i ERP oraz migracjach produkcyjnych baz danych na platformie AIX. W swojej karierze zawodowej zajmował się róznież administracją systemów UNIX i Linux oraz zaawansowanymi systemami multimedialnymi. Kontakt: maciej.przepiorka@pl.ibm.com 10

11 TOMASZ MIELNIK AUTOMATYCZNE URUCHAMIANIE APLIKACJI Z WEBSPHERE RAPID DEPLOYMENT (WAS v6.0) W IBM Innovation Center mamy okazję często testować i uruchamiać aplikacje firm partnerskich IBM tworzonych jako aplikacje J2EE uruchamiane na różnych serwerach aplikacyjnych. Bardzo często padają pytania, jak dany mechanizm, np. z Apache Tomcat lub JBoss Application Serwer, jest zaimplementowany w WebSphere. Jednym z takich pytań było szybkie uruchamianie aplikacji w WebSphere. w niniejszym artykule chciałbym przedstawić mechanizm WebSphere Rapid Deployment (WRD) służący do szybkiego uruchamiania i testowania aplikacji bez konieczności restartowania serwera WebSphere. CO TO JEST WEBSPHERE RAPID DEPLOYMENT? Wiele serwerów aplikacyjnych open source posiada możliwość szybkiego uruchamiania aplikacji poprzez przegranie plików.war/.ear (aplikacji J2EE) do odpowiednich katalogów. Serwer aplikacyjny rozpoznaje takie pliki, po czym automatycznie uruchamia aplikację w środowisku. Taka funkcjonalność może być bardzo przydatna w procesie prototypowania, tworzenia lub testowania aplikacji. WebSphere Rapid Deployment to zestaw narzędzi i technologia w WebSphere Application Serwer V6, który pozwala uruchamiać aplikacje J2EE poprzez umieszczenie plików w odpowiednio przygotowanych katalogach. WebSphere Rapid Deployment składa się z dwóch mechanizmów: AuotAppInstall uruchamianie całych modułów J2EE w serwerze aplikacyjnym poprzez umieszczenie plików (pliki.war i.ear) w odpowiednio przygotowanych katalogach Free Form uruchamianie swobodne klas Java i stron JSP z odpowiednio przygotowanymi przypisami w komentarzach (ang. annotations). Do skorzystania z metod AutoAppInstall oraz FreeForm uruchamiany jest specjalny proces, niezależny od WebSphere, który odpowiada za monitorowanie zmian w katalogach z aplikacjami. W dalszej części artykułu opisany zostanie sposób skonfigurowania WRD dla serwera WebSphere V6 działającego w systemie RedHat Enterprise Linux 4.0. PRZYGOTOWANIE KATALOGU DLA WRD W odróżnieniu np. od Apache Tomcat, WebSphere pozwala nam stworzyć dowolny katalog w systemie plików, do którego będziemy wrzucać pliki aplikacji. Na taki katalog musi jedynie wskazywać zmienna środowiskowa WORKSPACE. $ mkdir $HOME/wrd $ export WORKSPACE=$HOME/wrd Rys. 1. Konsola Administracyjna WebSphere w widoczną aplikacją AlbumCatalog uruchomioną metodą WRD. 11

12 IIC MAGAZINE III kwartał 2005 (6) METODA AUTOAPPINSTALL Po stworzeniu katalogu do wrzucania aplikacji należy go odpowiednio skonfigurować. w zależności od tego, który z mechanizmów planujemy użyć, katalog WRD będzie konfigurowany inną komendą. Skonfigurowanie polega na utworzeniu w katalogu aplikacji specjalnych plików (XML), zrozumiałych dla procesu monitorującego. $ WAS_HOME/bin/wrd-config.sh project TestProject style AutoAppInstall runtime was60 runtimepath /opt/ibm/websphere/appserver monitor Launching WebSphere Rapid Deployment configuration. Please wait Starting Workbench W odróżnieniu od Tomcata czy JBossa, proces monitorujący jest uruchamiany na zewnątrz serwera aplikacji i działa niezależnie od niego. Proces ten komunikuje się z serwerem aplikacji, używając mechanizmu i protokołu JMX (domyślnie na port 8880). Informuje go o zmianach, jakie zaszły w monitorowanym katalogu. Proces monitora WRD uruchamia się następująco: $WAS_HOME/bin/wrd.sh monitor Launching WebSphere Rapid Deployment. Please wait Starting Workbench WebSphere Rapid Deployment ready for e-business Type q, quit, or exit to shut down WebSphere Rapid Deployment processes. Od tego momentu w oknie terminala logowane będą wszystkie działania, jakie WRD podejmuje. Jest to niezwykle pomocne, zwłaszcza gdy stosowane jest podejście Free Form opisywane dalej. Aby przetestować działanie WRD, należy skopiować plik aplikacji.war, lub.ear (np. przykładowe Aplikacje dostępne wraz z WebSphere) do katalogu monitorowanego projektu $HOME/wrd/TestProject: $ cd /opt/ibm/websphere/appserver/samples/lib $ cp AlbumCatalog.ear $HOME/wrd/TestProject/ Po skopiowaniu w logach monitora WRD pojawią się następujące wpisy: [02:52:08 PM] [/TestProject/AlbumCatalog.ear] Added [02:52:08 PM]!INSTALL_EAR_FILE AlbumCatalog.ear! [02:52:08 PM] Publishing AlbumCatalog to server_ [02:52:11 PM] Installing New Application: AlbumCatalog [02:52:15 PM] ADMA5016I: Installation of AlbumCatalog started. [02:52:15 PM] ADMA5058I: Application and module versions validated with versions of deployment targets. [02:52:15 PM] ADMA5005I: The application AlbumCatalog is configured in the WebSphere Application Server repository. [02:52:15 PM] ADMA5053I: The library references for the installed optional package are created. [02:52:15 PM] ADMA5005I: The application AlbumCatalog is configured in the WebSphere Application Server repository. [02:52:17 PM] ADMA5001I: The application binaries are saved in /opt/ibm/websphere/appserver/profiles/default/wst emp/105e /workspace/cells/devel1node01cell/ applications/albumcatalog.ear/albumcatalog.ear [02:52:17 PM] ADMA5005I: The application AlbumCatalog is configured in the WebSphere Application Server repository. [02:52:17 PM] SECJ0400I: Successfuly updated the application AlbumCatalog with the appcontextidforsecurity information. [02:52:17 PM] ADMA5011I: The cleanup of the temp directory for application AlbumCatalog is complete. [02:52:17 PM] Installation Completed Sucessfully: AlbumCatalog [02:52:18 PM] Starting Application: AlbumCatalog [02:52:19 PM] Application Started Sucessfully: AlbumCatalog Aplikacja uruchomiona w ten sposób jest dostępna pod adresem Jest też widoczna w konsoli administracyjnej serwera WebSphere. METODA FREE FORM Istota metody Free Form jest nieco inna niż metody AutoAppInstall. o ile w AutoAppInstall instalowane były pełne aplikacje spakowane w pliku archiwum aplikacji (.ear), o tyle Free Form pozwala instalować ( wrzucać ) pojedyncze pliki do monitorowanego katalogu. Pliki takie jak JSP, servlety, czy klasy EJB wrzuca się dowolnie do monitorowanego katalogu, przy czym nie wymagana jest struktura katalogów, jak dla aplikacji J2EE (np. nie wymagany jest katalog WEB-INF). WebSphere rozpoznaje format pliku, który się pojawił w katalogu i automatycznie uruchamia go w sposób właściwy temu plikowi. Należy zaznaczyć, że dynamicznie tworzone są pliki web.xml, gdzie znajdują się informacje o uruchomionych servletach. Klasy EJB są automatycznie uruchamiane i dostępne w drzewie JNDI, a strony JSP są kompilowane i dostępne przez przeglądarkę. Konfiguracja WRD w trybie Free Form przebiega następująco: $ mkdir $HOME/wrd $ export WORKSPACE=$HOME/wrd $ $WAS_HOME/bin/wrd-config.sh -project TestProject - style freeform -runtime was60 -runtimepath /opt/ibm/websphere/appserver monitor Podczas konfigurowania WRD skrypt zapyta o kilka podstawowych informacji, jak np. adres serwera, port TCP do połączeń JMX oraz dane użytkownika potrzebne do autoryzacji, jeśli ta jest włączona w WebSphere. Monitorowanie WRD uruchamiamy podobnie jak w przypadku AutoAppInstall komendą: $./wrd.sh -monitor Aby sprawdzić działanie mechanizmu Free Form, można w monitorowanym katalogu $HOME/wrd/TestProject stworzyć plik przykładowej strony JSP. 12

13 AUTOMATYCZNE URUCHAMIANIE APLIKACJI Z WEBSPHERE RAPID DEPLOYMENT (WAS V6.0) <html> <h1>foo Bar</h1> </html> Rys 2. Przykład prostej strony index.jsp testującej konfigurację WRD Jeśli strona JSP nie zawiera błędów i jej kompilacja przebiegnie pomyślenie (co w powyższym przykładzie jest oczywiste), monitor WRD zanotuje następujące działania w logu: [02:21:56 PM] [/TestProject/index.jsp] Added [02:22:00 PM] [/TestProject/index.jsp] copied to project [TestProjectWeb] [02:22:02 PM] JSP entry added to web.xml: index [02:22:02 PM] Servlet mapping added. URL is: [TestProjectWeb/index] [02:22:03 PM] Publish requested for this change... [02:23:14 PM] Installing New Application: TestProjectApp [02:23:19 PM] ADMA5016I: Installation of TestProjectApp started... [02:23:42 PM] Installation Completed Sucessfully: TestProjectApp [02:23:45 PM] Starting Application: TestProjectApp [02:23:45 PM] Application Started Sucessfully: TestProjectApp Widać, że strona index.jsp otrzymała swój URL, pod którym jest dostępna z poziomu przeglądarki WWW. Dokonany został także wpis do pliku konfiguracyjnego web.xml. W odróżnieniu od metody AutoAppInstall, WRD wykonał także kilka dodatkowych czynności: stworzone zostały pomocnicze katalogi TestProjectApp i testprojectweb wykorzystywane przez WRD do budowania pliku EAR, tymczasowy plik EAR TestProjectApp.ear został utworzony w katalogu /tmp, plik TestProjectApp.ear faktycznie posłużył do uruchomienia na serwerze WebSphere, co widać w końcowych zapisach na powyższym logu. Rys.3. Strona JSP uruchomiona w przeglądarce Warto zauważyć, że katalogi pomocnicze TestProjectApp i TestProjectWeb zawierają pełną strukturę katalogów dla aplikacji webowej włącznie z potrzebnymi plikami konfiguracyjnymi. Zwykłe klasy Java lub servlety uruchamia się we Free Form podobnie jak strony JSP, poprzez przegranie ich do katalogu projektu $HOME/wrd/TestProject. w przypadku klas EJB, WebSphere Rapid Deployment korzysta z adnotacji (specjalnych tagów) umieszczanych w komentarzach (ang.: annotation based programming). Przykładowy servlet i klasę EJB z adnotacjami umieszczono poniżej. HelloServlet.java import java.io.*; import javax.naming.initialcontext; import javax.servlet.http.*; import javax.servlet.*; public class HelloServlet extends HttpServlet { public void doget (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { PrintWriter out = res.getwriter(); try { InitialContext ctx = new InitialContext(); HelloHome hellohome = (HelloHome)ctx.lookup( ejb/hello ); HelloRemote hello = hellohome.create(); out.println( Hello, world! ); out.println(hello.getmessage()); out.close(); } catch (Exception e) { e.printstacktrace(out); out.close(); } } } HelloService.java /** *@ejb.session name= Hello type= Stateless *jndi-name= ejb/hello * local-jndi-name= ejb/hello */ public class HelloService { /** symbol StockException view-type= both type= Required */ public String getmessage() { return Hello EJB ; } } Rys.4. Przykładowy servlet HelloServlet.java i klasa Session EJB HelloService.java 13

14 IIC MAGAZINE III kwartał 2005 (6) Umieszczenie tych klas w monitorowanym katalogu skutkuje ich uruchomieniem w serwerze aplikacji. Każda zmiana w monitorowanych plikach wywołuje odpowiednie reakcje Serwera Aplikacji. Np. zmiany w serwlecie powodują ponowne jego uruchomienie i poprawienie wpisu w web.xml. będzie katalog na jednej maszynie fizycznej, lecz aplikacje będę uruchamiane na zdalnym serwerze WebSphere. Taka konfiguracja WRD szczególnie przyda się do testowania aplikacji w rozproszonym środowisku. Szczegółowe informacje, takie jak dokładny opis działania WRD czy opisy tagów dla adnotacji znajdują się w wielu materiałach dostępnych w sieci. Adresy dodatkowych materiałów umieszczono na końcu artykułu. DODATKOWE MATERIAŁY W SIECI Rys.6. Efekt działania serwleta wywołującego klasę EJB PODSUMOWANIE Jak widać z powyższych przykładów, WebSphere Rapid Deployment dzięki wprowadzeniu adnotacji w kodzie pozwala szybko uruchamiać i testować klasy EJB czy servlety (w podobny sposób, jak EJB, można także testować Web serwisy). Metoda Free Form pozwala szybko i bez konieczności używania dużych środowisk programistycznych programować, prototypować i testować małe aplikacje. z pewnością nie będzie ona użyta do rozwoju dużych aplikacji tworzonych w dużych grupach programistów z wykorzystaniem skomplikowanego procesu wytwórczego. Metoda AutoAppInstall z kolei może być z powodzeniem używana w skomplikowanych procesach wytwórczych do testowania tworzonego kodu aplikacji. Ponieważ WRD pozwala podczas konfiguracji katalogu podać adres serwera WebSphere (np. zdalnego), można sobie wyobrazić scenariusz, kiedy monitorowany Biblioteka dokumentacji dla WebSphere Opis tagów do adnotacji EJB: com.ibm.etools.wrd.annotation.doc/topics/tejbtags.html Administracja WebSphere RedBook Tomasz Mielnik jest projektantem rozwiązań softwarowych w IBM Innovation Center. Zajmuje się tematyką związaną z Java, WebSphere, Rational oraz inżynierią oprogramowania. Współpracuje z firmami partnerskimi typu ISV, wspierając je w migracji i portowaniu aplikacji J2EE do otwartych standardów. Ponadto przygotowuje i przeprowadza dla firm partnerskich IBM testy obciążeniowe aplikacji J2EE. Kontakt: tomasz.mielnik@pl.ibm.com IBM eserver pseries, AIX and Linux Technical Conference Barcelona 7 10 Listopada 2005 Poznaj rzeczywistość z POWER 5! IBM p5, AIX & Linux Technical Conference stanowi niepowtarzalną okazję poznania nowej wersji AIX 5L V5.3 jak również oferty serwerów UNIX i LINUX nowej generacji opartych na procesorach o architekturze Power. Odkryj, jakie możliwości stwarzają nowe produkty Power5 w zakresie wirtualizacji za pomocą IVM, pracy w otwartych systemach AIX 5L i OpenPower Linux, oraz zintegrowanych i sprawdzonych rozwiązań System p5 i TotalStorage. Bloki tematyczne: Technologia POWER5, AIX, HACMP (HighAvailability Cluster Multi-Processing), Linux oraz Linux on POWER. Warsztaty typu hands-on: teoria utrwalona w praktyce. Testy certyfikacyjne: bezpłatny certyfikat dla pierwszych 50 osób, dla kolejnych atrakcyjne rabaty. Nie zwlekaj. Zarejestruj się! 14

15 IBM RATIONAL ZAPRASZA NA WALKĘ: TY KONTRA POWALAJA CE ROZWIA ZANIE GL / ÓWNE ATRAKCJE: NIESAMOWICIE KURCZA CE SIĘ TERMINY ZINTEGROWANE NARZE DZIA PROGRAMISTYCZNE WSPIERAJA CE ASSET-BASED DEVELOPMENT, BAZUJA CE NA ECLIPSE, DZIAL / AJA CE NA WIELU PLATFORMACH, WL / A CZNIE Z SYSTEMEM LINUX. POTE GA POZWALAJA CA TWORZYĆ LEPSZE OPROGRAMOWANIE, SZYBCIEJ. IBM MIDDLEWARE. SKUTECZNOŚĆ. WYDAJNOŚĆ. UDERZ NA IBM.COM/MIDDLEWARE/TOOLS/CC I POBIERZ WERSJE TESTOWE RATIONAL SOFTWARE MODELER ORAZ RATIONAL SOTFWARE ARCHITECT

16 Podstawowa oferta usług IBM Innovation Center obejmuje projekty migracyjne i portingowe, testy wydajnościowe, demonstracje i strojenie aplikacji, jak również szkolenia i seminaria techniczne. Więcej informacji na stronie: ibm.com/pl. Jeśli jesteś zainteresowany skorzystaniem z naszego centrum, już teraz skontaktuj się z opiekunem dedykowanym do Twojej firmy lub dzwoń pod numer: (+48 22) *. Najbliższe szkolenia prowadzone lub rekomendowane przez IIC: 24 października Eclipse tworzenie aplikacji dla Windows i Linux z wykorzystaniem platformy Eclipse. Zapisy: tel ; grazyna.glodz@pl.ibm.com 28 października partycjonowanie serwerów p5, i5 and Zapisy: tel ; grazyna.glodz@pl.ibm.com 3 listopada warsztaty IBM Rational Portfolio Manager Zapisy: tel ; michal.bugowski@pl.ibm.com 7 listopada AIX dla Linuxowców wprowadzenie do systemu Zapisy: tel ; grazyna.glodz@pl.ibm.com 17 listopada Tech enablement dla BP. Zapisy: tel , michal.bugowski@pl.ibm.com 8 9 grudnia Wprowadzenie do systemu operacyjnego Linux (skierowane do administratorów Windows). Zapisy: tel ; grazyna.glodz@pl.ibm.com Wydarzenia, w których warto wziąć udział: 13 października polska premiera nowego oprogramowania Lotus Notes Domino 7, hotel Novotel, Warszawa. Szczegóły: października IBM Rational European Technical Conference, Düsseldorf, Niemcy. Szczegóły: Kontakt: skt376@be.ibm.com 7 9 listopada konferencja Software Quality Assurance Management, hotel Sheraton, Kraków. Szczegóły: Poszukujesz niezawodnego źródła informacji i zasobów dla dewelopera, wejdź na stronę: lub Więcej informacji o produktach, o których mowa w IIC Magazine, na stronach: AIX 5L dział websphere na developerworks dział produktu websphere na ibm.com dział produktu websphere na polskiej stronie ibm.pl * Opłata wg jednostki taryfikacyjnej TP S.A.