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
Algorytm Liczba
uzyskanych reguł
Czas wykonania usługi w architekturze
Monolityczna SOA
Komputer Sieć
zoo 4895 0,30 5,1 11,2
5054 0,40 32,1 10,6
breast-cancer- wisconsin
822 0,80 3,8 2,3
1535 1,25 4,3 3,7
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.
