Rozdział. Badanie technologii Microsoft.NET Remoting w rozproszonym systemie wspomagajcym publikowanie katalogów reklamowych

Transkrypt

1 Rozdział Badanie technologii Microsoft.NET Remoting w rozproszonym systemie wspomagajcym publikowanie katalogów reklamowych Wojciech STANKO, Bogdan TRAWISKI Politechnika Wrocławska, Instytut Informatyki Stosowanej wstanko@go2.pl, trawinski@pwr.wroc.pl Streszczenie W rozdziale przedstawiono wykorzystanie technologii Microsoft.NET Remoting do budowy systemu wspomagajcego publikowanie katalogów reklamowych, opracowanego w wielowarstwowej architekturze klient serwer. Zbadano rozmiar przesyłanych obiektów w przypadku uycia serializacji do postaci binarnej i do formatu SOAP, a nastpnie porównano wydajno przy wykorzystaniu protokołów HTTP i TCP. Uzyskane wyniki potwierdziły przydatno zastosowania.net Remoting do implementacji systemów tej klasy. 1. Wprowadzenie Wraz z rozwojem sieci komputerowych, a w szczególnoci Internetu, zwikszyło si rozproszenie systemów. W kocu XX wieku powstała architektura wielowarstwowa, opracowano wiele standardów majcych na celu umoliwienie łatwej komunikacji aplikacji znajdujcych si na rónych komputerach połczonych sieci komputerow. Pojawiły si takie standardy, jak: RPC, CORBA, COM, DCOM, które miały ułatwi tworzenie rozwiza typu klient serwer [4, 5]. Jednak wykorzystanie ich było czsto skomplikowane, wymagało dodatkowej wiedzy ze strony programistów na temat zagadnie sieciowych, a czasami take dodatkowej implementacji niskich warstw połczenia sieciowego. W ostatnich latach z powodu silnej rywalizacji dwóch platform programistycznych, czyli platformy.net oraz JAVA, powstały nowe standardy pozwalajce szybko i łatwo realizowa komunikacj aplikacji znajdujcych si na rónych komputerach. Firma Microsoft wraz z.net dostarcza technologi.net Remoting [3, 6], pozwalajc na przezroczyst komunikacj aplikacji połczonych sieci komputerow, a w szczególnoci take sieci Internet.

2 2 W. Stanko, B. Trawiski Konkurencyjna JAVA zapewnia bardzo popularn technologi RMI (Remote Method Invocation) [4]. Pomimo silnej rywalizacji obu technologii, producenci take współpracuj nad stworzeniem jednolitych standardów pozwalajcych na integracj heterogenicznych systemów. Efektem tych działa jest technologia Web Services, która stała si standardem wspieranym przez wikszo platform programistycznych, jak równie wiele systemów baz danych [7]. Celem prezentowanych bada było sprawdzenie moliwoci wykorzystania technologii.net Remoting w rozproszonych systemach opartych na architekturze klient serwer. Przydatno technologii, łatwo i czasochłonno implementacji zweryfikowano w praktyce na przykładzie systemu wspomagajcego publikacj katalogów reklamowych. 2. Architektura Microsoft.NET Remoting.NET Remoting jest technologi, która pozwala na komunikacj pomidzy obiektami rozproszonymi w rónych aplikacjach, które mog znajdowa si na fizycznie innych komputerach [1]. Wielowarstwowa architektura.net Remoting pozwala na przezroczyst komunikacj klienta z obiektem zdalnym, z wykorzystaniem dowolnego kanału komunikacyjnego (np. protokołu TCP/IP). Zdalny obiekt jest cile zwizany z aplikacj, w której został stworzony, czyli serwerem, a klient, który wykorzystuje zdalny obiekt, nie wywołuje jego metod bezporednio, ale za porednictwem obiektu Proksy (ang. Proxy). Obiekt Proksy jest tworzony dynamicznie po stronie klienta i odzwierciedla publiczny interfejs obiektu serwera. Rys. 1. Ogólny schemat funkcjonowania.net Remoting [7] Jak pokazano na Rys. 1, w momencie wywołania metody obiektu zdalnego przez aplikacj klienta, obiekt Proksy przechwytuje wywołanie, nastpnie formatuje wywołanie danej metody za pomoc dostarczonego obiektu kodujcego o nazwie Formater (ang. Formatter) do postaci, w której danie moe zosta przesłane przez wybrany kanał komunikacyjny do serwera. Serwer po otrzymaniu wiadomoci rozkodowuje j, uywajc takiego samego obiektu kodujcego, a nastpnie za pomoc obiektu Dyspozytor (ang. Dispatcher) wywołuje odpowiedni metod w obiekcie zdalnym. Po zakoczeniu wywołania metody wynik jest zwracany w podobny sposób do aplikacji klienta. Obecnie Microsoft dostarcza tylko dwie implementacje obiektów kodujcych: binarn, oznaczon tutaj BIN oraz wykorzystujc format SOAP. SOAP wg definicji podanej przez World Wide Web Consortuim to lekki protokół przeznaczony do

3 Badanie technologii Microsoft.NET Remoting w rozproszonym systemie... 3 wymiany strukturalizowanej informacji w zdecentralizowanym, rozproszonym rodowisku. Ze wzgldu na to, e wszystkie elementy składajce si na technologi.net Remoting zostały zaprojektowane tak, aby były od siebie niezalene, istnieje moliwo dostarczenia własnej implementacji obiektu kodujcego wiadomoci. Zalet architektury stworzonej przez Microsoft jest moliwo wykorzystania dowolnego kanału komunikacyjnego oraz implementacji obiektu kodujcego niezalenie od siebie, co zapewnia du elastyczno oraz umoliwia dostosowanie.net Remoting do okrelonych wymaga. Zamian obiektu do postaci SOAP, binarnej, czyli postaci cigu bajtów, okrela si jako serializacj obiektu, a proces odwrotny zwany jest deserializacj, przy czym wan zasad jest, aby wykorzystywa ten sam rodzaj obiektów serializujacych i deserializujacych po stronie klienta, jak i serwera. 3. System wspomagania publikacji katalogów reklamowych MultiKatalog System wspomagania publikacji katalogów reklamowych MultiKatalog został stworzony z myl o ułatwieniu zarzdzania zawartoci katalogów reklamowych oraz skróceniu czasu przygotowania gotowego katalogu do publikacji. Katalog reklamowy to katalog przedstawiajcy fragment lub cał ofert asortymentu proponowanego przez dan firm. Najlepszym przykładem katalogów reklamowych s katalogi domów wysyłkowych (np. Quelle), koncernu IKEA lub innych firm wydajcych co roku due katalogi zawierajce aktualn ofert dla swoich klientów. W celu zmniejszenia zaangaowania firmy przygotowujcej szat graficzna, stworzono system pozwalajcy klientowi bezporednio za pomoc Internetu zarzdza struktur katalogu, wprowadza nowe dane, wykonywa poprawki i korekty, a take decydowa o formie publikacji danego katalogu. System MultiKatalog zbudowano w architekturze klient serwer, która składa si z nastpujcych podstawowych elementów (Rys. 2): Klient MultiKatalog aplikacja uruchamiana po stronie uytkownika, która oferuje graficzny interfejs oraz pozwala na dokonywanie rónych operacji. Jako klient łczy si ona z serwerem MultiKatalog, wykorzystujc.net Remoting; Serwer MultiKatalog podsystem dostarczajcy zbiór metod, które mog by wywoływane przez aplikacj klienta; Baza danych baza danych słuca do przechowywania wszystkich danych dotyczcych katalogów oraz uytkowników.

4 4 W. Stanko, B. Trawiski Rys. 2. Architektura klient-serwer systemu MultiKatalog System został zaprojektowany zgodnie z wielowarstwow architektur, w której wydzielono podstawowe warstwy przedstawione na Rys. 3. Rys. 3. Architektura klient-serwer systemu MultiKatalog Pierwsze dwie warstwy: prezentacja i logika aplikacji znajduj si po stronie aplikacji klienta i zostały zbudowane zgodnie ze wzorcem Model-View-Controler zaproponowanym przez Martina Fowlera [2]. Pozostałe dwie warstwy zostały zaimplementowane po stronie serwera. Zastosowano tutaj midzy innymi wzorce projektowe Table Module i Table Gateway [2]. Zalet wykorzystania wzorca Table Gateway przy implementacji dostpu do bazy danych jest uzyskanie niezalenoci implementacji systemu od implementacji bazy danych. Warstw realizujc komunikacj pomidzy klientem a serwerem z wykorzystaniem technologii.net Remoting umiejscowiono pomidzy warstwami logiki aplikacji oraz zarzdzania danymi. Na Rys. 3 wyróniono take warstw procedur składowanych, poprzez któr wykonywane s operacje na samych danych znajdujcych si w tabelach bazy danych. Warto zwróci uwag na sposób implementacji bazy danych, poniewa moe ona mie do duy wpływ na wydajno systemu. Jednym z wymaga systemu MultiKatalog było zapewnienie, jak najwikszej elastyczno okrelania budowy poszczególnych dokumentów, a take struktury katalogów, w celu zagwarantowania moliwoci dostosowania produktu do wymaga poszczególnych klientów. Ze wzgldu na to, e nie mona było załoy kocowej struktury poszczególnych dokumentów, zdecydowano si na zapisanie informacji o strukturze dokumentów za

5 Badanie technologii Microsoft.NET Remoting w rozproszonym systemie... 5 pomoc własnego jzyka opartego na XML. Baza danych została zaprojektowana tak, aby mogła przechowywa dokumenty zgodne ze specyfikacj opart na XML. W wyniku takiej decyzji projektowej powstała struktura bazy danych, w której pobranie lub zapisanie jednego dokumentu wymaga wielu niezalenych zapyta, co moe znacznie wydłua czas odpowiedzi systemu. Mona stwierdzi, e została zaimplementowana baza danych XML w relacyjnej bazie danych. 4. Badanie technologii.net Remoting zastosowanej w systemie MultiKatalog 4.1. Cel i zakres bada Celem bada było sprawdzenie wydajnoci technologii.net Remoting w systemie MultiKatalog, a take okrelenie iloci danych przesyłanych pomidzy serwerem a klientem w przypadku uycia serializacji do postaci binarnej (BIN) lub postaci SOAP. Zbadano take szybko serializacji w obu przypadkach, a take zbadano czas potrzebny na deserializacj, czyli ponowne odtworzenie obiektów. Do bada wydajnoci technologii.net Remoting wykorzystano dostarczane przez Microsoft narzdzie o nazwie Apllication Center Test. W tym celu zaimplementowano dodatkowego klienta konsumujcego usługi dostarczane przez serwer MultiKatalog, opartego na technologii ASP.NET i serwerze WWW. Schemat konfiguracji uytej do bada przedstawiono na Rys. 4. % #&!""#$ "'#$ Rys. 4. Konfiguracja uyta do bada wydajnoci.net Remoting Do wszystkich testów uyto tych samych obiektów: Document jest to obiekt o duym rozmiarze, posiadajcy wiele pól oraz referencji do innych obiektów, User obiekt posiadajcy znacznie mniej pól, przechowujcy podstawowe dane o uytkowniku Badanie wielkoci obiektów w postaci binarnej i SOAP Badanie wielkoci obiektów polegało na przekształceniu obiektów do dwóch postaci: binarnej i SOAP oraz pomiarze wielkoci takich postaci. Wyniki zostały

6 6 W. Stanko, B. Trawiski przedstawione w tabeli 1. W ostatniej kolumnie tabeli przedstawiono stosunek wielkoci formy SOAP do binarnej. Posta binarna była ponad trzykrotnie mniejsza od postaci SOAP dla obu obiektów. Tabela 1. Porównanie wielkoci postaci SOAP i binarnej (BIN) SOAP [bajty] BIN [bajty] SOAP/BIN Obiekt Document ,27 Obiekt User , Badanie czasu serializacji i deserializacji obiektów W celu ograniczenia wpływu innych aplikacji i procesów działajcych na testowym komputerze na wyniki, zbadano czas potrzebny na przeprowadzenie 1, 1 oraz 1 serializacji, a nastpnie na podstawie pomiarów wyliczono czas redni. Badania zostały przeprowadzone wielokrotnie, aby unikn błdów pomiaru. a) Serializacja: Document User b) Deserializacja Document User SOAP BIN SOAP BIN Rys. 5. rednie czasy serializacji i deserializacji obiektów Na Rys. 5 przedstawiono zestawienie rednich czasów serializacji i deserializacji. Serializacja binarna jest około 3,5 razy szybsza od serializacji do postaci SOAP. W przypadku deserializacji rónica jest około 6-krotna. Prawdopodobnie gorszy wynik serializacji/deserializacji do formatu SOAP wynika z potrzeby wielokrotnych operacji na cigach tekstowych. Ponadto w wypadku deserializacji dochodzi take potrzeba weryfikacji poprawnoci składni otrzymanej postaci SOAP Testowanie połcze rónych protokołów z formaterami Badania wydajnoci, przedstawione na Rys. 6, pokazały, e liczba obsłuonych zapyta na sekund jest zbliona w przypadku wykorzystania tego samego sposobu formatowania wiadomoci i w niewielkim stopniu zaley od protokołu, którym przesyłane s wiadomoci. Protokół HTTP okazał si nieznacznie mniej efektywny od TCP. W wypadku protokołu HTTP przesyłane dane opatrzone s dodatkowym nagłówkiem, co wymaga nie tylko dodatkowego przetwarzania, ale take zwiksza rozmiar wiadomoci, co moe powodowa zmniejszon efektywno Jednak przy

7 Badanie technologii Microsoft.NET Remoting w rozproszonym systemie... 7 przesyłaniu do duego obiektu, jakim jest obiekt typu Document, wpływ wielkoci nagłówka jest nieznaczny. Najwiksze znaczenie ma wic sposób kodowania obiektów, poniewa przy wykorzystaniu kodowania SOAP czas odpowiedzi jest około trzykrotnie dłuszy od czasu zaobserwowanego dla binarnej postaci. HTTP + SOAP HTTP + BIN TCP + SOAP TCP + BIN HTTP + SOAP HTTP + BIN TCP + SOAP TCP + BIN czas odpowiedzi [ms] liczba zapyta( na sekund) Rys. 6. Wyniki bada wydajnoci systemu czas odpowiedzi [ms] HTTP + SOAP bez bazy HTTP + BIN HTTP + BIN bez bazy liczba zapyta( na sekund) HTTP + SOAP bez bazy HTTP + BIN HTTP + BIN bez bazy Rys. 7. Porównanie wyników po odłczeniu bazy danych 4.5. Badanie wpływu bazy danych na wydajno Z uwagi na specyficzn struktur bazy danych, mona przypuszcza, e jej wpływ na wydajno jest znaczny. Badania pokazały, e czas odpowiedzi systemu, który pomijał pobranie dokumentu z bazy danych, a pobierał go z pamici, jest nawet

8 8 W. Stanko, B. Trawiski kilkanacie razy krótszy. Przepustowo systemu take wzrosła po odłczeniu bazy danych. Na Rys. 7 wida, jak duy wpływ ma baza danych na wydajno. Na wykresach nie uwzgldniono wyników protokołu HTTP i formatowania SOAP z podłczon baz danych, poniewa otrzymane wyniki były gorsze o ponad jeden rzd wielkoci, co spowodowałoby zniekształcenie wykresów z powodu potrzeby zwikszenia skali pionowej 5. Podsumowanie Technologia.NET Remoting dostarcza now jako tworzenia systemów klient serwer. Pozwala na szybk budow komunikacji pomidzy elementami systemu za porednictwem sieci, przy do niskim nakładzie pracy. Realizacja projektu MultiKatalog, potwierdziła praktycznie zalety.tej technologii. Z przeprowadzonych bada wynika wniosek, e najlepszym wyborem implementacyjnym jest protokół TCP oraz formatowanie wiadomoci do postaci binarnej, gdzie nie ma dodatkowych narzutów wielkociowych oraz przetwarzania, tak jak to si dzieje w przypadku protokołu HTTP oraz do mało wydajnego formatowania do postaci SOAP. Bezporednie testy zrealizowanego systemu MulitKatalog pokazały do nisk wydajno aplikacji, jednak jak si okazało, była ona spowodowana bardzo nisk wydajnoci zaimplementowanej bazy danych, która pogarszała wyniki nawet kilkunastokrotnie. Uzasadnione jest przeprowadzenie dalszych bada obejmujcych zachowanie si systemu w wypadku uycia kompresji i szyfrowania przesyłanych danych, porównanie innych ni HTTP i TCP protokołów, na przykład protokołu IPC z.net Framework 2. lub SMTP, a take porównanie wydajnoci z alternatywnymi rozwizaniami, takimi jak Web Services i Java RMI. LITERATURA 1. Conger D.: Remoting with C# and.net: Remote Objects for Distributed Applications, Wiley Fowler M.: Patterns of Enterprise Application Architecture, Addison-Wisley, McLean S., Naftel J., Wiliams K.: Microsoft.NET Remoting, Microsoft Press Raj G. S.: A Detailed Comparison of CORBA, DCOM, and Java/RMI (whitepaper), OMG Schussel G.: Client/Server: Past, Present and Future ( Srinivasan P.: An Introduction to Microsoft.NET Remoting Framework, Microsoft Corporation Thangarathinam T.:.NET Remoting Versus Web Services (whitepaper), ( 23, 8. Voelter M., Kircher M., Zdun U.: Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware, Wiley Software Patterns Series 24.