Rozwój repozytorium usług

Rozwój repozytorium usług Michał Nykiel Karol Zalewski 2011-05-01 Streszczenie Zdefiniowano pojęcie usług złożonych realizowanych przez platformę KASKADA, przedstawiono ich konstrukcję wraz ze sposobem zapisu do formatu XML oraz zaprezentowano edytor z graficznym interfejsem użytkownika służący do ich łatwego tworzenia i modyfikowania. Jednocześnie opisano algorytm doboru parametrów usług prostych w celu realizacji usług złożonych na podstawie określonych przez użytkownika kryteriów jakościowych. 1 Tworzenie usług na platformie KASKADA Wraz z rozwojem nowoczesnych technologii rośnie ilość informacji oraz danych multimedialnych, które wymagają przetwarzania i analizy. Źródłami tych danych są różnego rodzaju urządzenia cyfrowe, takie jak kamery, mikrofony i inne urządzenia rejestrujące. Źródłem danych jest również praca ludzka na przykład dokumenty i teksty coraz częściej powstające w postaci elektronicznej. Okazuje się, że nadmierna ilość informacji staje się problemem człowiek nie jest w stanie analizować danych równie szybko, jak szybko są one produkowane. Rozwiązaniem tego problemu jest komputerowa analiza danych, która znajduje zastosowanie w wielu dziedzinach. Scenariusze takiej analizy mogą mieć różny stopień skomplikowania od prostego leksykalnego porównania tekstów do złożonego rozpoznawania obiektów i zdarzeń w strumieniach wideo. Niemniej większość zadań analizy wymaga dużej mocy obliczeniowej, a także innych zasobów, jak np. pamięć dyskowa. Konieczne staje się wykorzystywanie superkomputerów i klastrów obliczeniowych do przetwarzania danych multimedialnych. To rozwiązanie rodzi jednak wiele komplikacji takich, jak np. utrudniona implementacja algorytmów w specyficznym środowisku oraz ograniczona dostępność usług analizy dla potencjalnych odbiorców, instytucji lub firm. Platforma KASKADA wspomaga rozwiązywanie tych problemów oferując zintegrowane środowisko dla zarządzania i udostępniania usług. 1.1 Opis usług Dzięki wykorzystaniu modelu SOA platforma KASKADA może udostępniać rozbudowane repozytorium usług [5]. Usługi są podstawowym elementem dostępnym dla użytkownika zewnętrznego i dzielą się na dwie grupy: 1

usługa prosta usługa, która może być rozumiana jako pojedyncze zadanie obliczeniowe, wraz ze zdefiniowanymi formatami danych wejściowych i wyjściowych, usługa złożona usługa, która jest kompozycją wielu usług prostych, również zawiera zdefiniowane formaty wejścia i wyjścia. Podstawą dla działania usług są algorytmy obliczeniowe [7] dotyczące strumieni multimedialnych lub dokumentów cyfrowych. Każdy algorytm jest zdefiniowany w platformie za pomocą nazwy, opisu, zbioru parametrów oraz formatów danych wejścia/wyjścia. Ponadto wskazuje on na plik wykonywalny, który jest odpowiedzialny za przetwarzanie danych. Algorytmy obliczeniowe są programami w języku C++, skompilowanymi wraz z biblioteką dostarczaną przez platformę (tzw. Ramka KASKADA). Rysunek 1: Proces tworzenia usługi prostej Usługi proste posiadają przypisany jeden lub więcej algorytmów obliczeniowych 1. Decyzja o tym, który algorytm zostanie wybrany do analizy zostaje podjęta w momencie uruchomienia i zależy od parametrów jakościowych podanych przez użytkownika. W związku z tym, że usługa musi posiadać spójny interfejs, wszystkie algorytmy przypisane do jednej usługi muszą mieć takie same formaty danych na wejściu i wyjściu. Użytkownik uruchamiając usługę podaje jeden lub więcej strumieni wejściowych oraz wymagane parametry. Strumienie wejściowe mogą być zarówno plikiem (binarnym lub tekstowym), jak również strumieniem RTSP (ang. Real Time Streaming Protocol). Wyjście z usługi może być dostarczone w ten sam sposób, a ponadto każda usługa może generować strumień zdarzeń. Zdarzenia są dokumentami XML i są przekazywane przez serwer kolejek Apache ActiveMQ [10] do platformy, a następnie mogą być filtrowane i przekazane do użytkownika. Platforma pozwala na kompozycję wielu usług prostych w usługę złożoną. W usłudze złożonej wyjście jednej z usług składowych może być wejściem jednej (lub wielu) innych usług. Takie podejście pozwala na używanie jednej usługi analizy danych w wielu zastosowaniach i zwiększa elastyczność rozwiązań. Dzięki wykorzystaniu gotowych usług tworzenie nowych, zaawansowanych scenariuszy przetwarzania jest możliwie proste. Usługi złożone, analogicznie do usług prostych, mają zdefiniowane formaty danych wejściowych i wyjściowych, a także zbiór parametrów. 2

wejście 1 A 1 S 1 A 3 wyjście wejście 2 A 2 S 3 S 2 zdarzenia Rysunek 2: Usługa złożona składająca się z trzech usług prostych S i wykorzystujących trzy algorytmy obliczeniowe A j 1.2 Definiowanie usług Złożone scenariusze analizy muszą być zdefiniowane w systematyczny sposób przy użyciu strukturalizowanego języka opisu, aby mogły być wykonane przez platformę. Istnieje kilka metod definicji usług złożonych, z których najpopularniejszym podejściem jest BPEL (ang. Business Process Execution Language) oraz jego rozszerzenie przeznaczone do zastosowania w usługach sieciowych WSBPEL (ang. Business Process Execution Language for Web Services) [16]. Rozwiązanie to zostało uznane za standard przez organizację OASIS w 2007 roku. Język ten bazuje na orkiestracji usług, która polega na wykorzystaniu centralnego procesu koordynującego. Zarządza on uruchamianiem odpowiednich usług, a także przepływem sterowania pomiędzy nimi [4]. Innym podejściem jest wykorzystanie choreografii usług oraz języka WS- CDL (ang. Web Services Choreography Language) [20]. Bazuje on, podobnie jak BPEL, na języku XML i został zaproponowany przez organizację W3C. Choreografia jest całościowym opisem wymiany komunikatów i polega na zdefiniowaniu przepływu wiadomości między konkretnymi usługami [8]. W takim podejściu nie korzysta się z centralnego procesu służącego do koordynacji. Mimo odmiennego modelu budowy usług złożonych WS-CDL posiada takie same możliwości projektowania scenariuszy przetwarzania jak BPEL. Pomimo dojrzałości obu rozwiązań, żadne z nich nie spełnia całkowicie wymagań dotyczących definiowania usług na platformie KASKADA. Główną różnicą pomiędzy platformą, a klasycznymi systemami SOA jest ilość i rodzaj analizowanych danych. Strumienie multimedialne wymagają przetwarzania informacji w czasie rzeczywistym. Problemem staje się nie tylko moc obliczeniowa, ale również przepływ danych między usługami. Z tego powodu rozwiązania wykorzystujące centralnego koordynatora, jak BPEL, są nieefektywne. Z kolei języki oparte o choreografię usług nie pozwalają na właściwe zdefiniowanie potokowego modelu przetwarzania danych opartego na strumieniach. Platforma KASKADA korzysta z własnego języka definicji usług złożonych bazującego na języku XML. Opis koncentruje się na zdefiniowaniu współpracujących usług oraz przepływu strumieni między nimi. Z założenia wszystkie 3

usługi składowe również pracują w środowisku KASKADY, dzięki czemu możliwe było przyjęcie pewnych rozwiązań zdecydowanie uproszczających definicję. Każda usług posiada tylko i wyłącznie jedną metodę odpowiedzialną za jej uruchomienie, więc nie ma konieczności jawnego opisywania sposobu wymiany komunikatów lub strumieni, zamiast tego wystarczające jest określenie nadawcy i odbiorcy strumienia. Pozwala to na prostsze i szybsze tworzenie usług złożonych przez użytkowników, a co za tym idzie oferowanie gotowych rozwiązań analizy danych. Listing 1: Przykładowa definicja usługi złożonej 1 <compl exservi ce> 2 <inputstreams> 3 <inputstream> 4 <destination key="s1" /> 5 </ inputstream> 6 </ inputstreams> 7 <s ervices> 8 <service key="s1" name="videoforwarder "> 9 <outputstream> 10 <destination key="s2" /> 11 <destination key="s3" /> 12 </ outputstream> 13 </ service> 14 <service key="s2" name="videolaplacer"> 15 <outputstream> 16 <destination key="s4" order="2"/> 17 </ outputstream> 18 </ service> 19 <service key="s3" name="facedetector"> 20 <outputstream name="marked"> 21 <destination key="s4" order="1"/> 22 </ outputstream> 23 <parameters> 24 <parameter name=" frame. drop"> 25 <mapping from=" facedetector. frame. drop" /> 26 </ parameter> 27 </ parameters> 28 <events serviceoutput="true "/> 29 </ service> 30 <service key="s4" name="videomerger"> 31 <parameters> 32 <parameter name=" alg. boot. merge. horizontal "> 33 2 34 </ parameter> 35 </ parameters> 36 <outputstream serviceoutput="true "/> 37 </ service> 38 </ services> 39 </ compl exservi ce> Podstawowym elementem, korzeniem definicji usługi złożonej, jest complexservice. Następnie opis dzieli się na dwie części: inputstreams oraz services. Pierwsza z nich dotyczy definicji strumieni wejściowych dla usługi, które są reprezentowane przez elementy inputstream. Każdy strumień wejściowy może zostać przekazany do dowolnej liczby usług. Powiązanie to jest realizowane 4

przez element destination oraz klucz usługi zdefiniowany w atrybucie key. Sekcja services wiąże się bezpośrednio z definicją współpracujących usług. Każda z nich określona jest przez element service, który posiada dwa atrybuty: name służący do wskazania konkretnej usługi prostej oraz key określającej identyfikator usługi w ramach definicji. Wartości parametrów usługi prostej (element parameters) mogą być określone na dwa sposoby poprzez jawne podanie wartości w definicji lub mapowanie wartości z parametru usługi złożonej. Obie metody realizowane są przez element parameter, wskazujący na konkretny parametr usługi przez atrybut name. Przypisanie wartości parametru z usługi złożonej odbywa się dzięki dodatkowemu elementowi mapping oraz atrybutowi from. Transport strumieni danych produkowanych przez usługi proste jest opisany w sposób analogiczny do strumieni wejściowych. Element outputstream definiuje strumień wyjściowy oraz jego odbiorców przez element destination. Ponieważ każda z usług może generować wiele strumieni danych, możliwe jest określenie nazwy wyjścia dzięki atrybutowi name. Dodatkowo do definicji każdego z odbiorców strumienia można przypisać indeks wejścia, na które ma zostać przesłany strumień (element order). Pewnym specyficznym przypadkiem strumienia jest strumień zdarzeń. Z tego względu został on wydzielony do osobnego elementu events, ale jego definicji dotyczą takie same zasady jak każdego innego strumienia. Strumienie wyjściowe z poszczególnych usług prostych mogą stać się wyjściem usługi złożonej przez zaznaczenie tego w atrybucie serviceoutput zarówno dla elementu outputstream, jak i events. W przypadku, gdy strumień danych jest rozpoznawalnym formatem multimedialnym, takim jak wideo lub audio, zostanie on udostępniony dla odbiorcy poprzez protokół RTSP. Natomiast zdarzenia generowane przez usługę zostają przekazane w postaci dokumentów XML do platformy KASKADA, gdzie mogą być archiwizowane, filtrowane i przesyłane dalej. 1.3 Graficzny sposób reprezentacji usług Scenariusze złożone z usług często są dość skomplikowane, a opis ich integracji w języku XML jest przeważnie trudny do zrozumienia przez człowieka. W celu graficznego modelowania usług złożonych stosuje się różne metody reprezentacji. Istnieje wiele różnych podejść do tego problemu, różniących się sposobami modelowania, poziomem szczegółowości, a także zastosowaniem. Jednym z graficznych języków reprezentacji architektury zorientowanej na usługi jest SoaML [18]. Jest to standard wprowadzony przez organizację OMG (ang. Object Management Group), odpowiedzialną głównie za tworzenie standardów modelowania obiektowego, z których najbardziej znanym jest UML (ang. Unified Modeling Language). SoaML powstał na bazie języka UML przez zastosowanie mechanizmów rozszerzeń. Szeroko stosowane są tutaj tzw. stereotypy, pozwalające na pewną meta-klasyfikację obiektów. Dzięki takiemu podejściu można korzystać przy modelowaniu z istniejących narzędzi UML, co jest dużą zaletą SoaML. Diagramy w tym języku są bardzo podobne do diagra- 5

mów klas, komponentów oraz interakcji w klasycznym UML. Podstawą całego modelu są udziałowcy (participants), którzy dostarczają usługi przez tzw. ServicePoint oraz korzystają z usług przez RequestPoint. Oba typy portów są zdefiniowane przez interfejsy, nazwane tutaj ServiceInterface. Główny nacisk w języku SoaML położony został na przedstawienie architektury usług. Model skupia się bardziej na technicznej definicji udostępnianych i wymaganych interfejsów, niż na przedstawieniu kompozycji wielu usług w scenariusze przetwarzania. Innym podejściem jest SOMF (ang. Service Oriented Modeling Framework), który został zaprojektowany zarówno jako język modelowania usług, jak również metodyka projektowania architektury zorientowanej na usługi [12]. SOMF oferuje prostą notację graficzną, która może być wykorzystana na różnych etapach rozwoju systemu. Podstawową koncepcją SOMF jest jego uniwersalność może być stosowany do projektowania każdej aplikacji i technologii. Wszystkie byty, obiekty, moduły czy aplikacje są reprezentowane w postaci abstrakcyjnego pojęcia usługi. Wydzielono trzy kategorie takich usług, do których należą: Atomic service niepodzielny, podstawowy element, który nie powinien być dekomponowany na mniejsze składniki, Composite service struktura, która agreguje wiele mniejszych usług, zarówno atomowych (Atomic), jak i złożonych (Composite), Service cluster zbiór usług, które stanowią rozwiązanie wybranego problemu biznesowego. Projektowanie usług w SOMF może odbywać się na jednym z kilku modeli mających zastosowanie na innych etapach rozwoju systemu. Jednym z nich jest logiczna kompozycja (logical design composition), która służy do modelowania integracji wielu usług w usługi złożone. Kompozycja skupia się przede wszystkim na przedstawieniu kanałów i kierunków komunikacji między usługami. Podstawową ideą stojącą za architekturą zorientowaną na usługi jest realizacja zadanych procesów biznesowych. Z tego powodu dobrym językiem graficznego opisu kompozycji usług może być BPMN (ang. Business Process Modeling Notation) [17]. BPMN jest standardem w dziedzinie modelowania procesów biznesowych, rozwijanym aktualnie przez organizację OMG (ang. Object Management Group). Głównym założeniem tej notacji jest prostota opisu język został zaprojektowany tak, aby mógł być zrozumiały zarówno przez użytkowników biznesowych, jak również programistów. Podstawowymi elementami w tym modelu są tzw. obiekty przepływu (flow objects) i połączenia między nimi. Do obiektów przepływu należą zdarzenia, zadania oraz bramki logiczne służące do rozdzielania i łączenia przepływu. Do niewątpliwych zalet BPMN należy przede wszystkim łatwe przejście z graficznego modelu do języka BPEL. Niestety, żaden z wymienionych języków modelowania wizualnego nie spełnia wszystkich wymagań wiążących się z graficzną reprezentacją usług złożonych na platformie KASKADA. Przede wszystkim brak jest podejścia pozwalającego na dobre modelowanie usług przetwarzających ciągłe strumienie danych. 6

VideoLaplacer s2 default VideoForwarder s1 VideoMerger s4 1 default default rtsp FaceDetector s3 marked event queue Rysunek 3: Graficzna reprezentacja usługi złożonej Istniejące graficzne reprezentacje scenariuszy złożonych skupiają się raczej na przedstawieniu sekwencyjnego przepływu sterowania, podczas gdy usługi analizujące strumienie multimedialne wykonują się potokowo i równolegle. Ponadto większość języków nie ma możliwości zobrazowania lub rozróżnienia istotnych elementów z punktu widzenia platformy, takich jak wiele wyjść usługi, czy też strumienie zdarzeń. Z tego względu dla platformy KASKADA wprowadzono własny język graficznej reprezentacji usług złożonych. Przykład zastosowania znajduje się na rysunku 3. Graficzna reprezentacja usługi złożonej [2] wyróżnia następujące elementy: 1. okręgi oznaczają wejścia, 2. koła oznaczają wyjścia, 3. prostokąty oznaczają usługi proste z odpowiednio zaznaczonymi pustymi kwadratami (wejściami) i pełnymi (wyjściami), 4. przerywane linie oznaczają wiadomości/zdarzenia, 5. ciągłe linie oznaczają strumienie danych, 6. ograniczenia i wymagania jakościowe zaznaczone są w dedykowanej przestrzeni w prostokątach oznaczających usługi proste. 2 Graficzny edytor usług Proces tworzenia usługi złożonej może być skomplikowany w przypadku dużych scenariuszy przetwarzania. Platforma KASKADA dostarcza graficzny Edytor 7

Usług, aby maksymalnie uprościć i przyśpieszyć tworzenie usług. Za jego pomocą użytkownik może zaprojektować dowolny scenariusz usług, przepływ strumieni między nimi, zdefiniować wartości parametrów i strumienie wyjściowe. Edytor jest komponentem zintegrowanym z aplikacją przeznaczoną do zarządzania całą platformą zwaną Konsolą Użytkownika. Konsola jest aplikacją webową napisaną w języku Java EE, dostępną przez przeglądarkę internetową, bazującą na podstawowych technologiach internetowych, takich jak HTML, CSS i JavaScript. W związku z tym Edytor musiał zostać zaimplementowany w technologii, która również może być uruchomiona w przeglądarce. Niestety, brak jest zestandaryzowanych rozwiązań, które spełniałyby wymagania dotyczące implementacji Edytora. Metody obsługi grafiki wektorowej istniejące w języku HTML oraz JavaScript nie są obecnie wspierane we wszystkich przeglądarkach. Ponadto konieczna byłaby implementacja od podstaw interaktywnego interfejsu użytkownika umożliwiającego np. przeciąganie elementów. Rysunek 4: Zrzut ekranu z Edytora Usług działającego w przeglądarce 2.1 Sposób implementacji Platforma KASKADA dostarcza Edytor Usług w technologii Microsoft Silverlight [13]. Jest to technologia służąca do tworzenia aplikacji RIA (ang. Rich Internet Application), oparta o zaawansowany i dojrzały język programowania C# oraz platformę.net. Podstawą budowy interfejsu jest tutaj WPF (ang. 8

Windows Presentation Foundation) oraz XAML (ang. Extensible Application Markup Language), które oferują doskonałe wsparcie dla multimediów, grafiki wektorowej, animacji i interaktywnych komponentów [1]. Aplikacje Silverlight uruchamiane są w przeglądarce dzięki dodatkowej wtyczce (ang. plug-in). Dla systemów Windows oraz Mac OS X dostępna jest oficjalna wtyczka, natomiast dla systemów Linux istnieje rozwiązanie Open Source o nazwie Moonlight [14]. Proces tworzenia usługi złożonej rozpoczyna się od zdefiniowania nazwy oraz opisu usługi w Konsoli Użytkownika. Nazwa może być dowolnym ciągiem znaków alfanumerycznych, jednak powinna być niepowtarzalna dla całej platformy. Następnie należy zdefiniować zbiór parametrów uruchomienia oraz parametrów jakościowych, które definiują pewien interfejs dla całej usługi. Zakładając, że istnieje już pewne repozytorium usług prostych, które mają zostać wykorzystane w usłudze złożonej, można przystąpić do definiowania scenariusza przetwarzania w Edytorze. Edytor współpracuje z Konsolą Użytkownika na różnych etapach tworzenia usługi. Przede wszystkim konieczne jest pobranie z Konsoli repozytorium wszystkich usług prostych w postaci ich nazw i opisów. Oprócz tego Edytor musi uzyskać szczegółowe dane dotyczące interfejsu dla wybranych usług parametry oraz formaty wejścia/wyjścia. Jednak najważniejszym miejscem integracji jest odczytanie istniejącej definicji usługi złożonej, jej parametrów, a na końcu zapisanie wprowadzonych zmian. Cała wymiana danych między Edytorem i Konsolą Użytkownika odbywa się przez protokół HTTP w postaci dokumentów XML. Schemat przedstawiający integrację pomiędzy Edytorem i Konsolą Użytkownika został przedstawiony na rysunku 5. 2.2 Tworzenie scenariusza Pierwszym krokiem w tworzeniu scenariusza przetwarzania jest dodanie do diagramu wybranych usług prostych. Odbywa się to przez wybranie odpowiedniej nazwy z listy wszystkich usług. Po dodaniu usługi Edytor wymaga zdefiniowania dla niej podstawowych właściwości. Należą do nich identyfikator usługi, wartości parametrów lub ich mapowania oraz nazwy dla strumieni wyjściowych. Określanie strumieni wyjścia nie jest konieczne, w takim przypadku wykorzystywany będzie domyślny strumień (default). Ważnym elementem scenariusza poza usługami są również strumienie wejściowe. Nie posiadają one żadnych właściwości, a identyfikowane są przez numer wejścia. Po zdefiniowaniu podstawowych obiektów należy określić przepływ danych pomiędzy nimi. Edytor wyróżnia dwa rodzaje kanałów przepływu danych: dla strumieni multimedialnych oraz zdarzeń. Kanał może łączyć dwie usługi lub strumień wejściowy z usługą. Ponadto, w przypadku powiązania dwóch usług istnieje możliwość wyboru nazwy strumienia wyjściowego. Strumień zdarzeń może łączyć wyłącznie dwie usługi. Wszystkie połączenia między usługami przechodzą proces walidacji pod kątem zgodności formatów wyjścia i wejścia. Ostatnią częścią procesu tworzenia scenariusza jest zdefiniowanie wyjść usługi. Mogą to być zarówno strumienie multimedialne udostępniane przez protokół RTSP, jak i strumienie zdarzeń. Określenie strumieni wyjściowych odbywa się 9

Edytor Usług definicja scenariusza przetwarzania definicje usług prostych definicja interfejsu usługi Konsola Użytkownika WPF, XAML istniejący scenariusz usługi złożonej XML HTML Biblioteki.NET zmodyfikowany scenariusz usługi Java EE Baza danych Rysunek 5: Integracja Edytora Usług z Konsolą Użytkownika przez zaznaczenie usługi i wybranie odpowiedniego rodzaju wyjścia. Do diagramu zostanie dodany nowy obiekt wraz z adekwatnym kanałem przepływu danych od usługi. Po zakończeniu definiowania scenariusza przeprowadzony zostaje zapis modyfikacji. Graficzny diagram usługi złożonej musi zostać skonwertowany do postaci wcześniej opisywanego dokumentu XML. Cały proces konwersji zostaje przeprowadzony przez Edytor Usług. Wynikowy dokument XML przesyłany jest do Konsoli Użytkownika, która wykonuje jeszcze dodatkową walidację składniową, a następnie zapisuje scenariusz w bazie danych scenariuszy dostępnych dla całej platformy. 10

Edytor Usług VideoForwarder s1 default VideoLaplacer s2 default FaceDetector s3 marked event VideoMerger s4 default queue rtsp konwersja do XML <complexservice> <inputstreams> <inputstream> <destination key="s1" /> </inputstream> </inputstreams> <services> <service key="s1" name="videoforwarder"> <outputstream> <destination key="s2" /> <destination key="s3" /> </outputstream> </service>... </complexservice> HTTP Konsola Użytkownika Baza danych zapis do bazy walidator składniowy Rysunek 6: Proces zapisu zmian w scenariuszu usługi złożonej 3 Repozytorium i wykonywanie usług Wszystkie usługi platformy KASKADA udostępniane są w postaci repozytorium usług. Użytkownicy platformy i aplikacje zewnętrzne mogą wykorzystywać szeroką gamę algorytmów przeznaczonych do analizy danych multimedialnych oraz uruchamiać je w postaci zadań obliczeniowych w prosty i przystępny sposób. Jest to możliwe dzięki wykorzystaniu architektury SOA oraz pewnych standardów dla usług sieciowych. 3.1 Wykorzystanie technologii SOA Każda z usług udostępnia definicję swojego interfejsu w postaci dokumentu WSDL (ang. Web Services Description Language) [21]. Język WSDL jest oparty o XML i opisuje protokóły wykorzystywane do wołania usług, a także wykorzystywane przez nie formaty danych [3]. Dla każdej usługi na platformie KASKADA jest przypisany konkretny punkt dostępowy (endpoint) w postaci adresu URL (ang. Uniform Resource Locator). Interfejs wszystkich usług jest bardzo podobny i składa się z następujących metod: createtoken metoda generująca token potrzebny do wszystkich wołań usługi, parametrem jest nazwa użytkownika oraz hasło, start metoda uruchamiająca wybraną usługę analizy, konieczne jest podanie poprawnego tokena oraz parametrów uruchomieniowych usług, 11

użytkownik otrzymuje w odpowiedzi unikatowy identyfikator uruchomionej usługi, stop metoda umożliwiająca zatrzymanie działającej usługi przez podanie tokenu oraz identyfikatora usługi, getoutputstreams metoda zwraca listę adresów strumieni wyjściowych (RTSP) dla danej usługi. Wykorzystując dokument WSDL dla danej usługi, programista jest w stanie utworzyć we własnej aplikacji tzw. stuby, czyli klasy umożliwiające wywoływanie metod usługi sieciowej jak zwykłych metod języka. Odpowiednie narzędzia są dostępne dla wszystkich popularnych języków programowania, np. program WSDL2Java dla Javy. Analogiczne sposoby konwersji WSDL istnieją w Microsoft.NET oraz PHP. Aplikacja wyszukiwanie usług WSDL RTSP SOAP Zdarzenia Serwer strumieni Usługa Usługa Usługa Serwer kolejek Rejestr UDDI Platforma Rysunek 7: Architektura repozytorium usług platformy KASKADA Wszystkie wymienione metody wywoływane są poprzez protokół SOAP [19]. Jest to standard W3C wykorzystujący język XML do kodowania wołań oraz 12

HTTP do ich transportu [6]. Dzięki zastosowaniu protokołu SOAP, usługi platformy KASKADA mogą być uruchamiane z praktycznie dowolnej aplikacji istnieją biblioteki obsługujące ten protokół dla każdego popularnego języka programowania. Użycie HTTP jako warstwy transportu komunikatów pozwala np. na zastosowanie szyfrowania transmisji w postaci protokołu HTTPS. Repozytorium usług platformy można przeszukiwać dzięki udostępnianemu rejestrowi UDDI (ang. Universal Description, Discovery and Integration) [15]. Idea uniwersalnego rejestru usług sieciowych początkowo była rozwijana głównie przez IBM i Microsoft, a obecnie UDDI został przekazany organizacji OASIS. UDDI jest oparty o XML i składa się z trzech części. Białe strony służą do opisu firmy lub organizacji dostarczającej usług [9]. Rejestr KASKADY posiada jedną taką stronę opisującą platformę jako usługodawcę. Żółte strony pozwalają na kategoryzację usług oraz instytucji według standardowych taksonomii. W końcu zielone strony zawierają techniczną specyfikację wszystkich usług, w tym adres do dokumentu WSDL. 3.2 Wybór odpowiedniej usługi do scenariusza Zdefiniowane w ramach usługi prostej grafy wykonania posiadają określone wartości dla jakościowych parametrów usługi. Koncepcja wyboru grafu wykonania bazuje na odniesieniu do określonych wartości wybranych parametrów. 1. Użytkownik, korzystając z zestawu parametrów jakościowych usługi, definiuje oczekiwane wartości dla wybranych parametrów oraz jedną z relacji, które wiążą wartość parametru grafu wykonania z wartością oczekiwaną: (a) relacja równości spełniona, gdy dla danego grafu wykonania wartość parametru jest równa wprowadzonej wartości oczekiwanej; (b) relacja różności spełniona, gdy dla danego grafu wykonania wartość parametru jest różna od wprowadzonej wartości oczekiwanej; (c) relacja mniejszości lub równości spełniona, gdy dla danego grafu wykonania wartość parametru jest mniejsza lub równa wartości oczekiwanej; (d) relacja mniejszości spełniona, gdy dla danego grafu wykonania wartość parametru jest mniejsza od wartości oczekiwanej; (e) relacja większości lub równości spełniona, gdy dla danego grafu wykonania wartość parametru jest mniejsza lub równa wartości oczekiwanej. W przypadku wartości numerycznych obowiązuje porównanie liczb, w przypadku wartości innych typów: porównanie łańcuchów znaków reprezentujących daną wartość. 2. System wybiera z zestawu grafów wykonania te, dla których warunki są spełnione. 3. System porządkuje wybrane grafy wykonania według rosnącego całościowego kosztu wykonania grafu (suma kosztów instancji algorytmów wchodzących w skład grafu). 13

4. Do wykonania wybierany jest pierwszy z grafów po uporządkowaniu. 4 Usługi standardowe repozytorium platformy KASKADA W ramach repozytorium platforma KASKADA udostępnia dwie kategorie usług: systemowe oraz użytkowe. Do grona usług systemowych zalicza się takie usługi, jak np.: DataRepositoryMaintainerService umożliwia zarządzanie strumieniami testowymi (ich tworzenie, usuwanie, wyszukiwanie i pobieranie), PlatformMonitorService udostępnia informacje dla administratora o obciążeniu platformy, jej węzłach i uruchomionych usługach, ProfileMaintainerService umożliwia zmianę aktywnego profilu (tj. dostępnych dla usług węzłów obliczeniowych i strumieniujących), RunningServiceMonitorService udostępnia szczegółowe informacje na temat poszczególnych przekaźników, usług i zadań, StreamAdminService pozwala na zarządzanie (aktywacja i dezaktywacja) strumieniami z kamer oraz na pobranie ich pełnej listy, StreamPlayer umożliwia uruchomienie podglądu strumienia (z kamery lub testowego), StreamService pozwala na wyszukiwanie strumieni z kamer na podstawie podanych kryteriów. W ramach usług użytkowych dostępne są zarówno usługi udostępnione wraz z platformą KASKADA, jak i ponad 70 usług stworzonych przez cztery zespoły zajmujące się rozwojem aplikacji. Poniżej wymieniono podstawowe usługi udostępnione wraz z platformą. kaskada_relayer usługa dekoduje strumień multimedialny i przekazuje go do innych usług, video_rotator usługa pozwala na obracanie przesyłanego obrazu (każda kolejna klatka obrazu jest obrócona względem poprzedniej o wybraną liczbę stopni), video_scaler usługa umożliwia zmianę rozmiaru przesyłanego obrazu, video_tagger usługa pozwala na dodanie do każdej z klatek przesyłanego obrazu napisu i/lub czasu, jaki upłynął od początku rozpoczęcia nadawania strumienia, video_laplacer usługa wykrywa krawędzie w przesyłanym obrazie, 14

video_merger usługa realizująca łączenie kilku otrzymywanych strumieni w jeden poprzez umieszczenie poszczególnych klatek obrazu obok siebie, video_cropper usługa pozwalająca na kadrowanie przesyłanego obrazu, bandpass_filter usługa realizująca filtr środkowoprzepustowy dla strumieni audio, event_stepper usługa umożliwiająca wysyłanie do zadań wiadomości o zadanej treści i co zadany okres, event_counter usługa licząca wiadomości odbierane przez nią. Należy podkreślić, że rozwój nowych aplikacji przyczynia się również do rozwoju usług. Dzięki temu przygotowywanie nowych aplikacji sprowadza się często do tworzenia usług złożonych. Literatura [1] Brown P., Silverlight 4 in Action, Manning Publications, 2010 [2] Bobkowska A., Nykiel M., Proficz J., Evaluation of Multimedia Stream Processing Modeling Language from the Perspective of Cognitive Dimensions, Proceedings of PPIG 2011, York, 2011, str. 7. [3] Czarnul P., Język opisu usług sieciowych WSDL, KASKBOOK, 2004 [4] Dziubich K., Metody i języki opisu scenariuszy zachowań aplikacji przetwarzania wszechobecnego, KASKBOOK, 2009 [5] Josuttis N. M., SOA in Practice: The Art of Distributed System Design, O Reily Media, 2007 [6] Kaczmarek P., Protokół SOAP i jego zastosowanie, KASKBOOK, 2004 [7] Krawczyk H., Proficz J., KASKADA Multimedia Processing Platform Architecture, SIGMAP, 2010 [8] Piotrowski M., Web Services Choreography Description Language - WSCDL, KASKBOOK, 2004 [9] Urbaniak A., Wyszukiwanie usług UDDI, KASKBOOK, 2004 [10] ActiveMQ, http://activemq.apache.org/ [11] CI TASK - Galera, http://www.task.gda.pl/kdm/sprzet/galera [12] Methodologies Corporation, SOMF 2.1 Service-Oriented Logical Design Model Specifications, 2011 15

[13] Microsoft Silverlight, http://www.silverlight.net/ [14] Moonlight Mono, http://www.mono-project.com/moonlight [15] OASIS, UDDI Version 2.04 API Specification, 2002 [16] OASIS, Web Services Business Process Execution Language Version 2.0, 2007 [17] Object Management Group, Business Process Model and Notation (BPMN), 2009 [18] Object Management Group, Service oriented architecture. Modeling Language (SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS), 2008 [19] W3C, SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), 2007 [20] W3C, Web Services Choreography Description Language Version 1.0, 2005 [21] W3C, Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, 2007 16