implementacja aplikacji eksplorującej dane w architekturze

Jarosław Piekarski, Roman Podraza
Politechnika Warszawska, Instytut Informatyki
IMPLEMENTACJA APLIKACJI EKSPLORUJĄCEJ DANE W
ARCHITEKTURZE ZORIENTOWANEJ NA USŁUGI
Streszczenie
Wyraźnym trendem rozwoju systemów informatycznych jest dynamiczny wzrost aplikacji
internetowych udostępnianych przy pomocy przeglądarek internetowych. Dla użytkownika nie ma
znaczenia, w jaki sposób realizowana jest funkcjonalność systemu. W szczególności architektura
zorientowana na usługi (ang. SOA – Service Oriented Architecture) pozwala na niezależne tworzenie
i włączanie funkcjonalności realizowanych przez usługi. System ARES służący do eksploracji danych
powstał jako aplikacja monolityczna. Została podjęta próba zaimplementowania systemu ARES w
architekturze SOA. Niniejsza praca prezentuje motywację podjęcia próby migracji z architektury
monolitycznej do zorientowanej na usługi oraz wstępne analizy i oceny uzyskanego rozwiązania.
1. WSTĘP
Aplikacje odkrywające wiedzę mają szerokie zastosowanie. Są używane przy ocenie
ryzyka ubezpieczeń lub kredytu, w marketingu, diagnostyce medycznej, bankowości i
innych dziedzinach. Ogromna ilość danych i szybkość obliczeniowa komputerów
spowodowały szeroką popularność eksploracji danych.
ARES System jest aplikacją monolityczną napisaną w Javie [1] [2]. Zawiera różne
algorytmy odkrywania wiedzy bazujące na takich metodologiach jak. teoria zbiorów
przybliżonych, wzorce wyłaniające się czy maszyny wektorów podpierających.
Specyficzną cechą systemu ARES jest możliwość wyznaczania współczynników
wiarygodności dla obiektów systemu informacyjnego. Współczynniki te szacują typowość
obiektów przy pomocy różnych algorytmów i pozwalają na automatyczne identyfikowanie
danych niepewnych nietypowych. System ARES początkowo implementował tylko
algorytmy z dziedziny zbiorów przybliżonych a następnie poszerzał swoje możliwości. Ten
rozwój dokonywany latami przez zespół osób szybko zmieniających się od początku
powodował kłopoty z integralnością systemu. Dlatego koncepcja architektury SOA do
wykorzystania w systemie ARES, wydała się wyjątkowo atrakcyjna przede wszystkim
dlatego, że umożliwia jego dalszy rozwój bez ingerencji w istniejący system. Był to
dostateczny powód do podjęcia decyzji o przekształceniu systemu ARES na architekturę
zorientowaną na usługi [3].
Nowa budowa tej aplikacji ma zupełnie inne cechy. Jest silnie zmodularyzowanym i
rozproszonym systemem. Wnosi to wiele zalet, ale rozwiązanie to nie jest wolne od wad.
Praca ta ma na celu zanalizowania bilansu zysków i strat w przypadku implementacji
systemu odkrywającego wiedzę wykonanego w architekturze SOA.
2. SYSTEM ARES
System ARES w swej pierwotnej wersji służył do eksploracji danych przy pomocy
algorytmów działających w oparciu o teorię zbiorów przybliżonych [4]. Rezultaty
kolejnych kroków mogły być reprezentowane w wielu oknach systemu (Rys. 1).
Równolegle można było przetwarzać wiele systemów informacyjnych i porównywać
uzyskiwane rezultaty bądź dostrajać parametry stosowanych algorytmów. W szczególności
system umożliwiał przeprowadzanie dyskretyzacji danych, wyszukiwanie zbiorów
częstych, znajdowanie reduktów, odkrywanie reguł oraz obliczanie współczynników
wiarygodności obiektów systemu informacyjnego.
Rys. 1. ARES System – graficzny interfejs użytkownika.
Rozwój systemu zaowocował dołączeniem funkcjonalności wykorzystującej wzorce
wyłaniające się [5] i maszyny wektorów podpierających [6]. W wielu przypadkach formaty
danych i rezultatów dla dodawanych funkcji były takie same (np. do obliczania
współczynników wiarygodności.
Problemy z utrzymywaniem integralności systemu przy permanentnym jego rozwoju
zwróciły uwagę na architekturę SOA, gdzie poszczególne usługi mogą być
implementowane zupełnie niezależnie, bez ingerencji w działający system. Zdecydowano
się więc na podjecie próby migracji architektury monolitycznej do architektury SOA.
3. ARCHITEKTURA SOA
Technologie informatyczne cechuje bardzo szybki postęp. Nowe wyzwania to coraz
większe rozmiary implementowanych systemów oraz oczekiwany od nich poziom
niezawodności. Kolejne istotne wymaganie to możliwość modyfikacji i rozszerzania
funkcjonalności systemu wraz ze zmianami ich otoczenia (biznesowego, prawnego, itd.).
Coraz częściej nowo tworzone aplikacje są systemami rozproszonymi realizującymi jakiś
złożony proces biznesowy w kilkunastu rozłącznych fragmentach.
Zestaw reguł, metodologii oraz narzędzi do tworzenia tego rodzaju oprogramowania
jest określany mianem architektury zorientowanej na usługi. Dostosowanie się do zasad tej
architektury ułatwia możliwość tworzenia rozproszonych, łatwo rozwijalnych systemów.
Dalej zostały przedstawione podstawowe elementy architektury SOA wykorzystane w
nowej wersji systemu ARES.
3.1. USŁUGA
Usługa to wydzielony element oprogramowania, który odpowiada jakiejś
funkcjonalności. Użytkownik chcąc dokonać jakiejś biznesowej operacji wywołuje
odpowiednią usługę realizującą tą operację.
Usługa zawsze realizuje konkretny kontrakt. Określa on sposób wywołania usługi,
format danych wejściowych usługi, format danych wyjściowych oraz być może inne
warunki niezbędne do prawidłowego skorzystania z usługi. Istotna jest niezmienność
kontraktu. Implementacja usługi może się zmieniać, ale nie sam sposób wywołania usługi
definiowany przez kontrakt. Modyfikacja dostępu do usługi powoduje wyodrębnienie
nowego kontraktu. Dzięki temu implementacja usługi jest ukryta (w szczególności nie ma
znaczenia język programowania ani technologia użyte do implementacji) i jej zmiana nie
ma wpływu na pozostałe moduły architektury.
Dodatkowo, usługa musi mieć zdefiniowany sposób komunikacji. Może to być sposób
związany z określonym językiem programowania (np. RMI - ang. Remote Method
Invocation, to zdalne wywoływanie metod w Javie). Bardziej uniwersalna jest komunikacja
niezależna od języków programowania (jak np. CORBA, RPC SOAP, XML-RPC). Jednak
najpopularniejszym medium komunikacyjnym są usługi sieciowe. Jest to rozwiązanie,
otwarte, wykorzystywane w praktyce od wielu lat (gwarantuje to poprawność działania), a
co najważniejsze, istnieją biblioteki realizujące usługi sieciowe w wielu językach
programowania.
3.2. USŁUGODAWCA
Ten element architektury SOA jest odpowiedzialny za dostarczenie usług.
Usługodawca jest kontenerem usług. Implementacje kontraktów realizują jakąś
funkcjonalność, a usługodawca udostępnia je dla potencjalnych użytkowników.
Usługodawca może posiadać własne repozytorium usług, gdzie użytkownicy mogliby
dowiedzieć się, jakie funkcje są dostępne i jak można z nich skorzystać. Innym
rozwiązaniem jest ogólne repozytorium usług, gdzie różni usługodawcy umieszczają
informację o realizowanych usługach. Wpisy do takich rejestrów dokonywane są za
pomocą UDDI (ang. Universal Description Discovery and Integration – uniwersalny opis,
odkrywanie i integracja), co pozwala przeglądać zestawy dostępnych usług, w tym
automatycznie wykrywać i integrować usługi sieciowe.
3.3. USŁUGOBIORCA
Usługobiorca to element SOA, który przypomina program kliencki w architekturze
klient - serwer. Jest to aplikacja, która korzysta z usług oferowanych przez usługodawcę.
Zamiast funkcji implementowanych w architekturze monolitycznej wywołuje się usługi
implementujące tą samą funkcjonalność. Następuje wówczas uruchomienie procesu
związanego z wywołaniem danej usługi – przygotowanie danych wejściowych, wywołanie
usługi, zwrócenie wyników działania. Proces ten może być dość złożony i wprowadzać
dodatkowe narzuty czasu wykonania. Z drugiej strony łatwo jest zorganizować równoległe
wywoływanie wielu usług (wykonywanych zapewne także równolegle). Można też w wielu
przypadkach oczekiwać, że czas wykonania usługi na serwerze o dużej mocy obliczeniowej
może być istotnie krótszy od realizacji analogicznej funkcji na stacji roboczej.
3.4. OCENA PRZYDATNOŚCI ARCHITEKTURY SOA
Podstawową zaletą architektury SOA jest rozdzielenie aplikacji na niezależne moduły,
które mogą być implementowane w różnych językach programowania. Jeżeli interfejsy
modułów są niezmienne, to zmiany implementacji fragmentów aplikacji nie wymuszają
zmian w pozostałych modułach. W systemie ARES można łatwo wydzielić usługi
realizujące różne algorytmy eksploracji danych. Migracja systemu do architektury SOA
umożliwi swobodny rozwój systemu. Rozwój ten może przebiegać równolegle dla różnych
metodologii eksploracji i analizy danych nie powodując wzajemnych kolizji oraz ingerencji
w część już wykorzystywaną.
Niezależne usługi mogą być wywoływane i wykonywane równolegle przez wielu
rozproszonych usługodawców. W przypadku intensywnego zapotrzebowania na usługi
mogą być one umiejscawiane na wydajnych serwerach i/lub multiplikowane, aby
zwiększyć wydajność systemu.
W systemie ARES występuje wiele funkcji realizujących ten sam cel przy pomocy
różnych podejść. Kontrakty dla usług je zastępujących są bardzo podobne (lub takie same).
Powoduje to, że komunikacja między usługobiorcą realizującą m. in. graficzny interfejs
użytkownika a usługodawcami tworzącymi wirtualny serwer usług jest stosunkowo prosta.
Wprowadzenie architektury SOA umożliwia też łatwe wytwarzanie oprogramowania
dostosowanego do wymagań funkcjonalnych użytkownika. W szczególności użytkownik
może być zainteresowany wykorzystywaniem funkcjonalności bazującej tylko np. n teorii
zbiorów przybliżonych. Może wówczas otrzymać „skrojoną na miarę” aplikację
(usługobiorcę) nie obarczoną niepotrzebnymi elementami całego systemu.
Z drugiej strony architektura SOA wprowadza dodatkowe przetwarzanie w procesie
organizacji współpracy między usługobiorcę a usługodawcami. Usługobiorca musi przesłać
dane do usługobiorcy, a następnie wyniki są przesyłane z powrotem do usługobiorcy.
Dodatkowo, komunikaty między modułami przesyłane są jako dokumenty XML.
Utworzenie komunikatów i ich odczytanie też wymaga czasu. Może to spowodować, że
całkowity czas wykonania algorytmu eksploracji danych zwiększy się znacząco.
Nieoczekiwaną niedogodnością przy migracji systemu ARES do architektury SOA
okazały się ograniczenia w przekazywaniu dwuwymiarowych tablic przez narzędzia
realizujące SOA. Dlatego też trzeba było wykonać pilotażową implementacje systemu
ARES w architekturze SOA.
4. SYSTEM ARES W PILOTAŻOWEJ WERSJI SOA
W pilotażowej wersji systemu ARES w architekturze SOA zostały zaimplementowane
usługi będące reprezentatywne dla całego ich zbioru o takim samym interfejsie
programistycznym. W związku z tym usługobiorca ma ograniczone możliwości
wywoływania usług, co jednak w żadnym stopniu nie ogranicza badania wydajności
testowanej wersji w architekturze SOA. Wykonano wstępne porównania wydajności
architektury monolitycznej z architekturą SOA przy ograniczonej funkcjonalności systemu
ARES. Porównywano całkowity czas wykonania algorytmu. Wstępne testy zostały
przeprowadzone dla dwóch różnych plików danych wejściowych [7].
— zoo.csv - 101 elementów posiadających 17 atrybutów (5 kB),
— breast-cancer-wisconsin(EP).csv - 675 elementów posiadających 10 atrybutów (20 kB)
Testy wykonano na usłudze odkrywania reguł wykorzystującej algorytm Apriori.
Usługa ta przyjmuje dwa parametry – minimalne wsparcie i minimalne zaufanie, które
decydują o liczbie reguł wynikowych a zatem wpływają na czas potrzebny na przesłanie
reguł z usługodawcy do usługobiorcy. Testy dla architektury SOA przeprowadzono w
dwóch konfiguracjach – usługodawca i usługobiorca uruchomieni na jednej maszynie oraz
usługodawca i usługobiorca uruchomieni na różnych maszynach w tej samej sieci lokalnej.
Tablica 4.1
Czas wykonania funkcji (usługi) odkrywania reguł z wykorzystaniem algorytmu Apriori
Czas wykonania usługi w architekturze
Algorytm
zoo
breast-cancerwisconsin
Liczba
uzyskanych reguł
Monolityczna
Komputer
Sieć
4895
0,30
5,1
11,2
5054
0,40
32,1
10,6
822
0,80
3,8
2,3
1535
1,25
4,3
3,7
SOA
5. WNIOSKI
Jak widać w wynikach porównania czasów wykonania przykładowej funkcji (usługi)
systemu ARES, zgodnie z przewidywaniami, dla nowej architektury są większe. Jednak
większość czasu potrzebna jest na przesłanie wyników do usługobiorcy – np. ze 101
obiektów z 17 atrybutami wyznaczono 4895 reguł. Zbiór danych testowych nie był na tyle
duży, by zaobserwować większy czas wykonywania samego algorytmu. Dla większej
liczby obiektów, gdzie czas wykonania może trwać kilka godzin, to czas przesłania kilku
tysięcy reguł (od 5 do 40 sekund) jest niezauważalnie małym okresem. Co więcej, widać
już zmniejszenie czasu wykonania operacji, jeśli usługobiorca i usługodawca działają na
różnych komputerach. Do testów zostały użyte maszyny o zbliżonych parametrach.
Różnica ta byłaby większa w przypadku uruchomienia usługodawcy na dedykowanym
komputerze o wysokich parametrach. Warto zauważyć, że przy rozproszonym modelu
przetwarzania przez czas wykonywania algorytmu usługi użytkownik może pracować na
swoim komputerze. Zasoby jego maszyny nie uczestniczą w wyznaczaniu wiedzy. Z
drugiej strony mechanizm przesyłania komunikacji usługobiorcy z usługodawcami przy
pomocy plików w formacie XML jest niewydajny. Prawdopodobnie wydajniejszym
rozwiązaniem byłoby przesłanie danych jako wartości jednego znacznika XML, aniżeli w
obiektowej strukturze znaczników XML, jednak to już zmieniłoby kontrakt lub szczegóły
komunikacji i obecne usługi nie pozbyłyby się tej wady.
6. ZAKOŃCZENIE
System ARES służący do odkrywania wiedzy może być wykonany w architekturze
SOA. Niestety narzut czasowy związany z komunikacją pomiędzy modułami zwiększa czas
wykonania całej operacji. Zauważono zmniejszenie dodatkowego czasu w przypadku
fizycznego umieszczenia usługobiorcy i usługodawcy na różnych maszynach. Jeśli usługi
będą wykonywane na dedykowanym komputerze o dużej mocy obliczeniowej, to być może
różnica czasu zmniejszy się. Z drugiej strony korzyści wynikające z SOA (dalszy rozwój
systemu łatwiejszy niż w przypadku architektury monolitycznej, usługobiorca może być
realizowany jako aplikacja uruchamiana w przeglądarce internetowej) przesądziły o
kontynuowaniu migracji do architektury SOA.
BIBLIOGRAFIA
[1] Podraza R.: Credibility Coefficients in Hybrid Artificial Intelligence Systems, In E. Corchado et
al. (Eds.), Hybrid Artificial Intelligence Systems, Lecture Notes in Artificial Intelligence LNAI
5572, Springer-Verlag, Berlin, Heidelberg 2009, s. 187-194, (Proc. 4th International Conference,
HAIS 2009, Salamanca, Spain, June 2009).
[2] Podraza R., Kalinowski M.: ARES Systems - Integration of Analysis Methodologies, in G. Setlak,
K. Markov (Eds.), Intelligent Information and Engineering Systems, International Book Series
“Information Science and Computing”, No. 13, ITHEA, 2009, s. 49-56.
[3] Woods D., Mattern Th.: Enterprise SOA, O'Reilly Media, 2006.
[4] Pawlak Z.: Rough Sets. Theoretical Aspects of Reasoning about Data, Kluwer, 1991.
[5] Dong G., Li J.: Efficient Mining of Emerging Patterns: Discovering Trends and Differences,
Proc. of the SIGKDD (5th ACM Int. Conf. on Knowledge Discovery and Data Mining), 1999.
[6] Schmilovici A.: Support Vector Machines, in Data Mining and Knowledge Discovery Handbook.
Maimon O., Rokach L. (Eds.), Springer Science + Business Media Inc., 2005, s. 257-274.
[7] UCI Machine Learning Repository, School of Information and Computer Science, University of
California, USA, (http://www.ics.uci.edu/~mlearn/MLRepository).
IMPLEMENTATION OF DATA MINING APPLICATION IN SOA
ON EXAMPLE OF SPRING ON MARS APPLICATION
Summary
Contemporary software systems are developed as distributed net applications, which are accessed by
internet browsers performing specialized code. Service Oriented Architecture (SOA) rules define
independent development and maintenance of functionalities implemented as services. ARES System
has been implemented as a stand-alone application. There was an attempt to migrate the system to
SOA. The paper presents motivations of the attempt as well as preliminary analysis and evaluation of
the resulting solution.