Wiktor RUTKA

Wiktor RUTKA
Wydział Informatyki, Zachodniopomorski Uniwersytet Technologiczny
E-mail: [email protected]
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 wylicza203
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 PubSub (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 PubSub, 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/xep0060.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