Wiktor RUTKA Wydział Informatyki, Zachodniopomorski Uniwersytet Technologiczny E-mail: wrutka@wi.ps.pl Koncepcja struktury internetowego systemu komunikacji i przetwarzania danych opartego na idei Cloud Computing 1. Wstęp do problemu Niejednokrotnie, zmuszeni do automatyzacji pewnych procesów (czy to zachodzących w korporacji, w badaniach naukowych, itp.) naukowcy oraz pracownicy firm zobligowani są do chwytania się po coraz nowsze i mniej standardowe techniki, technologie i metody. Przykładem takiego podejścia są systemy pobierające oraz wstępnie przetwarzające dane w ściśle określonym celu. Wiele z takich systemów potrafi nadać znaczenie danym, które przetwarza, zmienić nieuporządkowany zbiór liczb/słów w konkretną informację. Systemy, które zajmują się ogromnymi ilościami danych, powinny być zoptymalizowane pod kątem architektury w taki sposób, aby umoŝliwić swobodne działanie poszczególnym modułom nawet przy ekstremalnym obciąŝeniu. Pretekstem do tego typu rozwaŝań niech będzie internetowy system transakcyjny, współpracujący z wieloma platformami brokerskimi (rynki OTC <<Over The Counter>>). Aplikacja owa, musi pobierać surowe dane (instrumenty bazowe) z róŝnych platform brokerskich, na ich podstawie wyliczać instrumenty pochodne, indeksy oraz sugerować działania, które naleŝy podjąć w celu maksymalizacji zysków. Wiedza wykorzystana w tym artykule pochodzi głównie ze specyfikacji protokołów [9] oraz ksiąŝek traktujących w sposób ogólny rozwaŝany temat. Przyczyną takiego stanu rzeczy jest fakt, Ŝe pojęcia takie jak Cloud Computing, Grid Computing, Web2.0 czy WebService stały się wręcz modne i nie trudno trafić na wartościową informację w szeroko rozumianym Internecie. Samo pojęcie przetwarzania w chmurze (Cloud Computing <<CC>>) jest róŝnie definiowane przez osoby zajmujące się tym pojęciem. Autorzy [4] przyrównują CC do Grid Computing (GC), jednak definiując CC jako paradygmat biznesowy podczas gdy GC jako narzędzie naukowe. Rzeczywiście, pojęcia są bardzo zbliŝone do siebie a róŝnią się jedynie modelem rozproszenia. GC stawia na przyśpieszenie obliczeń w rozproszonym środowisku, gdzie kaŝda jednostka powinna zajmować się tymi samymi danymi oraz obliczeniami, podczas gdy CC kładzie nacisk na rozproszenie usług. Wszystkie dane oraz obliczenia traktowane są jako usługi i same w sobie nie muszą być rozproszone/zrównoleglone (choć mogą). NaleŜy zwrócić uwagę, Ŝe pojęcie Cloud Computing odnosi się zarówno do sfery sprzętowej jak i programowej. Serwery w chmurze mogą być fizycznymi maszynami jak i wirtualnymi. Niuans ten został dostrzeŝony w [1], gdzie CC zostało zdefiniowane jako zespół wirtualnych zasobów komputerowych. WaŜnym aspektem w rozpatrywanym problemie jest równieŝ komunikacja pomiędzy poszczególnymi usługami. Wiadomo, Ŝe musi to być jeden ze sposobów komunikacji uŝywany w WebServicach [6] [7], jednak, w odróŝnieniu od standardowych zastoso- 200
wań, w tym przypadku ogromny nacisk został połoŝony na czas komunikacji oraz szybkość reakcji na zdarzenia. XMPP Pub-Sub, bo tak nazywa się protokół, zaproponowany w poniŝszej publikacji, jest protokołem bezpośrednio powiązanym z usługami komunikatorów internetowych wzbogacony o usługę Pub-Sub. Samo rozwiązanie XMPP (Extensible Messaging and Presence Protocol) jest z załoŝenia zaprojektowane do natychmiastowej reakcji na zdarzenia, natomiast podejście Pub-Sub pozwala na subskrypcję do konkretnych tematów (topic). Idea powyŝsza jest zaprezentowana w [10] natomiast szczegółowa specyfika jest zawarta w [9]. 2. Koncepcja struktury systemu Warstwy aplikacji mają na celu wyodrębnienie poziomów logicznych struktury systemu. Dzięki temu moŝna wskazać, który moduł rozpatrywanej aplikacji naleŝy do jakiego poziomu abstrakcji. Tego teŝ naleŝy się trzymać podczas szczegółowego projektowania i realizacji projektu, zachowując logiczne wyodrębnienie struktur naleŝących do danego poziomu abstrakcji [8]. NaleŜy zwrócić uwagę na fakt, Ŝe rozpatrujemy system dalece rozproszony, a co za tym idzie, projekt ten nie obejmuje zagadnień na poziomie pojedynczego modułu (przynajmniej w tym momencie). Abstrakcje, o których mowa była wyŝej, dotyczą całych grup modułów i cześci aplikacji, które wyodrębniają, obliczają, pobierają i publikują dane. W zaleŝności od stopnia przetworzenia danych oraz wymagań funkcjonalnych modułu, zostały wydzielone następujące warstwy abstrakcji (nawiązując do metamodelu architektury SOA <<Service Oriented Architecture>>): Rys. 1. Warstwy aplikacji (opracowanie własne) Fig. 1. The layers of the application KaŜda część składowa rozpatrywanego systemu rozproszonego będzie posiadała powyŝszą budowę warstwową. Moduły w rozproszonym systemie będą musiały wykonywać następujące czynności: zbierać dane bazowe, przetwarzać dane bazowe do instrumentów pochodnych, publikować wyniki dla innych modułów. 201
Idea połączenia wszystkich części rozproszenia została przedstawiona na rysunku 2. NaleŜy pamiętać, Ŝe jest to jedynie wstępna propozycja wykorzystania rozproszonych aspektów omawianego systemu i ma na celu tylko zobrazowanie budowy całości. Wszystkie moduły po przetworzeniu danych łączą się z pojedynczym modułem centralnym, który na podstawie rezultatu działania powyŝszych ma za zadanie podejmować decyzję dotyczącą następnego ruchu na giełdzie. Rys. 2. Koncepcja rozproszonego systemu (opracowanie własne) Fig. 2. Conception of the distributed system Warstwa pobierania, jest odpowiedzialna za wyszukiwanie i pobieranie danych z Internetu. Elementy modułu spełniające powyŝszą funkcjonalność są nazywane pająkami internetowymi (web-spiders) [11], które przeszukają sieć i parsują znalezione informacje. Największym problemem tej warstwy jest fakt, Ŝe niektóre informacje nie są dostępne bezpośrednio w Internecie. Większość giełd internetowych nie pozwala na dostęp do swoich danych kaŝdemu internaucie, przedstawiając je w HTML lub za pomocą dostępnego API (Application Programming Interface). Dlatego najbardziej odpowiednim rozwiązaniem, byłoby zawarcie porozumienia z firmą, która taką funkcjonalność oferuje. Pająki internetowe przeszukują sieć w celu znalezienia konkretnych danych. Gdy znajdą odpowiednie źródło w internecie, parsują stronę i wyciągają odpowiednie/potrzebne dane (rysunek 4). Idealnym stanem było by, gdyby wszystkie źródła internetowe były pisane w zrozumiałym dla maszyn/programów języku (np. Resource Description Framework RDF) [5], natomiast sposób ich wyświetlania był zapisany w innym miejscu. Dzięki temu pająki internetowe nie musiałyby parsować informacji a jedynie ją wyszukiwać. 202
Rys. 3. Pobieranie instrumentów bazowych w obrębie pojedynczego modułu (opracowanie własne) Fig. 3. Getting base instruments within single module Rys. 4. Pobieranie i parsowanie danych (opracowanie własne) Fig. 4. Getting and parsing data Po pobraniu i udostępnieniu danych, moŝna przystąpić do przetwarzania. Kolejna warstwa (przetwarzania) jest odpowiedzialna za wyliczanie odpowiednich statystyk na podstawie zasobu zgromadzonego w wyŝszej warstwie. Moduły na tym poziomie abstrakcji muszą się efektywnie komunikować z warstwą poprzednią (pobierania danych). Wymagane tu jest aby komunikacja inicjowana była w momencie pojawienia się nowych danych bądź aktualizacji wartości danych juŝ znanych. Rozwiązaniem tego problemu moŝe być protokół XMPP Pub-Sub, który powstał z wykorzystaniem idei dwóch protokołów: XMPP oraz Pub-Sub. Pub-Sub jest rozszerzeniem protokołu XMPP wprowadzając do niego dodatkową funkcjonalność (publikacja i subskrypcja). Dzięki temu nadawca (pająk internetowy, który znalazł nowe dane bądź nowe wartości do juŝ istniejących danych) moŝe publikować wiadomości w danym temacie. Odbiorca (część warstwy odpowiedzialna za wylicza- 203
nie konkretnych instrumentów pochodnych), który subskrybuje dany temat jest niezwłocznie informowany o zmianie. Rys. 5. Wyliczanie instrumentów pochodnych w obrębie pojedynczego modułu (opracowanie własne) Fig. 5. Computing derivatives within single module Podejście takie odciąŝa system od ustawicznego odpytywania się (rysunek 6), czy nastąpiła jakaś zmiana na rynku. Oprócz tego, elementy wyliczające instrumenty pochodne mają moŝliwość niezwłocznej reakcji po zaistnieniu takiej zmiany (rysunek 7). Rys. 6. Schemat tradycyjnego podejścia do reakcji na zmiany (opracowane na podstawie [10]) Fig. 6. Scheme of an traditional approach to a reaction on changes 204
Rys. 7. Schemat reakcji na zmiany z wykorzystaniem XMPP Pub-Sub (opracowane na podstawie [10]) Fig. 7. Scheme of a reaction on changes with XMPP Pub-Sub protocol Po przeprowadzeniu odpowiedniej obróbki danych naleŝy je opublikować, tak aby reszta systemu miała do nich dostęp. Pytanie rodzi się, w jaki sposób tego dokonać? Rys. 8. Wykorzystanie Jabber/XMPP do komunikacji między rozproszonymi komponentami (opracowanie własne) Fig. 8. Jabber/XMPP approach in communication between distributed components NaleŜy stworzyć konstrukcje aplikacyjną, naleŝącą do kategorii aplikacji pośredniczących (middleware). Jedne z konstrukcji spełniających oczekiwania rozpatrywanego systemu znane są pod pojęciem Enterprise Service Bus (ESB). Infrastrukturę taką moŝna stworzyć uŝywając dostępnych narzędzi (jak Synapse) lub zaproponować oraz zaimplementować rozwiązanie autorskie od podstaw. Idąc w kierunku takich rozwiązań jak 205
Synapse naleŝało by całość oprzeć na rozwiązaniach ws-* korzystając z protokołu SOAP lub REST. RównieŜ odpowiednim rozwiązaniem wydaje się być zastosowanie (podobnie jak to miało w warstwie poprzedniej) rozwiązań opartych o protokół XMPP (rysunek 8). Serwer taki naleŝy odpowiednio obudować aplikacjami, w taki sposób by spełniał załoŝenia architektury ESB. Rozwiązanie, które proponuje autor jest związane z uŝyciem serwera Jabber/XMPP z wykorzystaniem Pub-Sub, które zaoszczędziło by czasu i mocy obliczeniowej na odpytywanie się poszczególnych modułów. Pomijając powyŝszy fakt, dla chmury rozproszonych modułów nie jest moŝliwe stosowanie podejścia, w którym to moduł wnioskujący odpytuje się wszystkich uczestników o kolejne porcje danych; Nie musi on posiadać informacji o tym gdzie znajdują się moduły odpowiedzialne za konkretny instrument pochodny. 3. Całość w słuŝbie jedności Autor w rozdziale poprzednim zaprezentował architekturę budowy pojedynczego modułu rozpatrywanego systemu rozproszonego. Zostały przedstawione podstawowe problemy występujące podczas realizacji tego zadania, jak równieŝ niektóre (preferowane) sposoby ich rozwiązywania. Rys. 9. Koncepcja systemu pobierania i przetwarzania danych z rynków typu OTC (opracowanie własne) Fig. 9. Conception of getting and computing data from OTC markets śeby cały system spełniał załoŝenia (co do funkcjonalności jak i wydajności) naleŝy, w sposób optymalny, połączyć poszczególne moduły. NaleŜy pamiętać, Ŝe od strony 206
architektury moduł wnioskujący niczym się nie róŝni od pozostałych (poza faktem, Ŝe w warstwie pobierającej dane nie uŝywa pająków internetowych, tylko dowolnego sposobu komunikacji z resztą modułów). Ponadto moŝe być zdecydowanie więcej niŝ tylko jeden moduł wnioskujący. Liczba komponentów pobierających dane moŝe być (a co waŝniejsze, powinna być) duŝa, tworząc tym samym chmurę obliczeniową. Nie moŝliwe jest aby w takim wypadku znany był adres kaŝdego z modułów; ilość taka wyklucza odpytywanie adres po adresie. Dodatkowym utrudnieniem, które występuje w tego typu systemach, jest to, Ŝe moduły mogą być zaleŝne od siebie (wynik działania jednego jest wejściem innego). RównieŜ w tym przypadku autor proponuje uŝycie Jabber/XMPP z rozszerzeniem Pub- Sub (rysunek 9). 4. Wnioski Rozwiązanie proponowane w tym rozdziale eliminuje konieczność zapamiętywania miejsca deploymentu (rozmieszczenia) poszczególnych komponentów, co więcej nie wymaga odpytywania ich o nową porcję danych. Jedynym wymaganiem jest stworzenie tematów (topiców) dzięki wykorzystaniu Pub- Sub, publikowanie tam informacji będących wynikiem działania konkretnych modułów oraz subskrypcja modułów wnioskujących do interesujących ich tematów. Taki sposób rozwiązania tego problemu jest elastyczny oraz skalowalny: nie tylko łatwo modyfikować poszczególne komponenty ale równieŝ bez konieczności specjalnej rejestracji dodawać nowe. Literatura 1. Boss G., Malladi P., Quan D., Legregni L., Hall H.: Cloud Computing. High Performance On Demand Solutions (HiPODS) 2007 2. Cavoukian A.: Privacy in the clouds. Identity Journal Limited 2008 3. Broberg J., Venugopal S., Buyya R.: Market-oriented Grids and Utility Computing: The State-of-the-art and Future Directions. Springer Science + Business Media B.V. 2007 4. Taylor I., Harrison A.: From P2P and Grids to Service on the Web. Springer-Verlag London Limited 2009 5. Broekstra J., Kampmatn A.: Semantic Web and Peer-to-Peer. Springer Berlin Heidelberg 2006 6. Troelsen A.: Pro C# 2005 and the.net 2.0 Platform. Apress 2005, s. 919-954 7. Belussi A., Catania B., Clementini E., Ferrari E.: Spatial Data on the Web. Springer Berlin Heidelberg 2007 8. Freeman Erick, Freeman Elisabeth, Sierra K., Bates B.: Head First. Design Patterns. Helion 2005 9. Singhal A., Winograd T., ScarfoneK.: Guide to Secure Web Services National Institute of Standards and Technology 2007 10. Buschmann F., Henney K., Schmidt D.: Pattern-Oriented Software Architecture. Wiley & Sons 2007 11. Pilone D., Miles R.: Head First. Software Development. Helion 2008 12. Ramsey B., Con Z.: Distribution and Publication Wtih Atom Web Services, Schemantic 2008 13. Booth D., Haas H., McCabe F., 2004. http://www.w3.org/tr/ws-arch/ 207
14. Millard P., Saint-Andre P., Meijer R., 2008. http://xmpp.org/extensions/xep- 0060.html 15. Henshaw-Plath E., McCrea E., 2008 http://www.slideshare.net/kellan/beyond-rest 16. Jones M.T., Build A Web Spider on Linux, 2006 http://www.ibm.com/developerworks/linux/library/l-spider/ Streszczenie Obecny rozwój techniki, technologii oraz metod przetwarzania danych doprowadził do sytuacji, w której firmy, instytucje oraz osoby prywatne mają moŝliwość coraz szybszego i pewniejszego bogacenia się. Niniejsza publikacja przedstawia propozycję struktury rozproszonego systemu komunikacji, ułatwiającego zbieranie danych oraz automatyzującego ich przetwarzanie i podejmowanie decyzji. Podział logiczny oparty został na wzorcach projektowych MVC oraz MTV. Propozycja komunikacji pomiędzy poszczególnymi komponentami dotyczyła protokołu XMPP z wykorzystaniem rozszerzenia Pub-Sub. Conception of the Web communication system and data computing structure based on idea of Cloud Computing Summary Existing developement of techinique, technology and methods of data computing bring to the situation, when companies, institutions and private persons have a possibility to grow rich in quicker and more surely way. Present publication presents a proposition of structure of distributed communication system, who help in collecting and automating of computing data and automating of making decision. Logical division was based on MVC and MTV design patterns. Proposition of communication between particular components apply to XMPP potocol with Pub-Sub extension. 208