Praca magisterska Badanie wydajności systemów o ... · Akademia Górniczo - Hutnicza im....

Akademia Górniczo - Hutnicza im. Stanisława Staszica w KrakowieWydział Elektrotechniki, Automatyki, Informatyki i Elektroniki

Katedra Informatyki

Praca magisterska

Badanie wydajności systemówo architekturze SOA

Tomasz Duszka, Jakub [email protected], [email protected]

Promotor: dr inż. Dominik Radziszowski

Kraków, 2008

Spis treści

1 Wstęp 41.1 Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Struktura pracy . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Technologie 82.1 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.1 Kluczowe elementy . . . . . . . . . . . . . . . . . . . . 102.1.2 Kontrakt . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Webservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 ESB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.1 Historia ESB . . . . . . . . . . . . . . . . . . . . . . . 182.3.2 Założenia i cechy ESB . . . . . . . . . . . . . . . . . . 202.3.3 Istniejące implementacje ESB . . . . . . . . . . . . . . 222.3.4 Wdrożenia ESB . . . . . . . . . . . . . . . . . . . . . . 222.3.5 JBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.1 Wersje BPEL . . . . . . . . . . . . . . . . . . . . . . . 282.4.2 Dostępne implementacje BPEL . . . . . . . . . . . . . 30

3 System badania wydajności 333.1 Wymagania . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.1 Wymagania w stosunku do konsoli . . . . . . . . . . . 353.1.2 Wymagania w stosunku do sensora wydajności . . . . . 35

3.2 Koncepcje rozwiązań . . . . . . . . . . . . . . . . . . . . . . . 363.2.1 Koncepcje nie wymagające modyfikacji kodu BPEL . . 363.2.2 Obserwator zdarzeń silnika BPEL . . . . . . . . . . . . 413.2.3 Koncepcje wymagające instrumentacji kodu BPEL . . 42

3.3 Wybrane podejście . . . . . . . . . . . . . . . . . . . . . . . . 45

2

4 Implementacja 464.1 Opis wybranych problemów implementacyjnych . . . . . . . . 464.1.1 Wstrzykiwanie sensora wydajności . . . . . . . . . . . 474.1.2 Format komunikatu z danymi o wydajności . . . . . . . 494.1.3 Przekazywanie wiadomości od sensora do konsoli . . . . 524.1.4 Wizualizacja zebranych danych w konsoli . . . . . . . . 53

4.2 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Testy 575.1 Testowane oprogramowanie . . . . . . . . . . . . . . . . . . . 575.2 Opis procedury testowania . . . . . . . . . . . . . . . . . . . . 645.3 Konfiguracja infrastruktury . . . . . . . . . . . . . . . . . . . 655.4 Dynamiczna prezentacja wyników . . . . . . . . . . . . . . . . 665.5 Wyniki testów . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Wnioski z pracy i możliwości dalszego rozwoju systemu 786.1 Możliwości zastosowania stworzonego oprogramowania . . . . 796.2 Dalszy rozwój systemu . . . . . . . . . . . . . . . . . . . . . . 79

7 Akronimy 82

8 Bibliografia 84

9 Spis rysunków 89

A Podręcznik użytkownika 91A.1 Instrumentacja bibliotek kontenera oraz konfiguracja aplikacji 91A.2 Sposób wizualizacji danych wydajnościowych . . . . . . . . . . 93

3

Rozdział 1

Wstęp

SOA (Service Oriented Architecture) to największe osiągnięcie informatycz-nej myśli architektonicznej ostatnich lat1. Ten wprowadzony w 1996 rokuprzez Gartnera[51] paradygmat stanowi obecnie dominujący nurt w projek-towaniu systemów informatycznych2 i jest ukoronowaniem wysiłków mają-cych na celu uproszczenie oprogramowania rozproszonego. Jego powstaniema ścisły związek z dynamiczną ewolucją architektur oprogramowania (por.rysunek 1.1).

Rysunek 1.1: Ewolucja architektur oprogramowania [25]

Rosnące wymagania odnośnie możliwości, jak i prostoty obsługi aplika-cji, nieuchronnie prowadzą do wzrostu ich złożoności. Aktualny model two-rzenia oprogramowania powoli osiąga kres swoich możliwości - obserwowa-ny jest znaczny wzrost kosztów związanych z rozwiązywaniem problemów

1“My thought was, this change has to be compared to the switch from Newtonianphysics to relativistic physics.”[26]2Ocenia się, że w ciągu najbliższych dwóch lat znajomość technologii wspierających

tworzenie aplikacji o architekturze SOA podwoi się z 25 do 50%[27]

4

czysto technologicznych, np. integracją systemów zbudowanych w oparciu oróżne platformy pośredniczące (z ang. middleware). Inżynierowie muszą rów-nież radzić sobie z ciągłymi naciskami organizacyjnymi i biznesowymi takimijak: ograniczanie kosztów wytwarzanego oprogramowania, potrzeba szybkiejodpowiedzi na zmieniające się wymagania, możliwość łatwej integracji i ab-sorpcji nowych partnerów biznesowych. W celu zniwelowania wymienionychtrudności powstało szereg rozwiązań, np. architektury przeznaczone do two-rzenia systemów rozproszonych, przenośne języki programowania, środowiskawspierające integrację systemów itp. Nie rozwiązują one jednak współcze-snych problemów - na przeszkodzie staje duża różnorodność platform pro-gramistycznych, stosowanych technologii oraz rosnąca potrzeba integracjisystemów. Brak uniwersalnego i powszechnie stosowanego, a jednocześnieodpowiadającego obecnym potrzebom rozwiązania cząstkowego, przyczyniłsię do powstania koncepcji SOA - architektury zorientowanej na usługi (Se-rvice Oriented Architecture). Podstawową zasadą rządzącą tym podejściemjest luźne powiązanie (z ang. loose coupling) pomiędzy elementami systemu,pozwalające na proste komponowanie go jako całości (zmianę w sposobieprojektowania oprogramowania obrazuje rysunek 1).

Rysunek 1.2: Zmiana w podejściu do projektowaniu oprogramowania

Logiczną konsekwencją takiego podejścia jest zastosowanie szeregu do-brych konwencji inżynierskich, takich jak ukrycie implementacji3 czy ponow-ne użycie (z ang. software reuse), przy jednoczesnym wzroście elastyczności,przejrzystości, łatwości wprowadzania zmian oraz prostocie zarządzania.Powszechne uznanie SOA, spowodowało zmianę w kierunku rozwoju tech-

nologii z zakresu wymiany danych i integracji oprogramowania. Coraz więk-szy udział w rynku mają te rozwiązania, które większą uwagę przywiązują dowspółdziałania różnych platform i przenośności. Chcąc realizować ideę SOA,

3zwane też autonomicznością

5

użyte technologie muszą dawać jak największą swobodę w zakresie komuni-kacji. Ich bazą przestaje być interfejs programistyczny konkretnego języka, azaczyna format wymienianych danych. Dodatkowo chcąc zapewnić jak naj-większą niezależność poszczególnych części systemów, coraz większy naciskkładzie się na ukrywanie szczegółów implementacji.Od czasu opublikowania paradygmatu SOA w 1996 roku, powstał szereg

koncepcji (np. technologia webservice) mających na celu praktyczną realiza-cję SOA. W oparciu o nie, korzystając jednocześnie z idei ESB (EnterpriseService Bus) oraz języka BPEL (Business Process Execution Language), fir-my informatyczne są w stanie stworzyć oprogramowanie spełniające założeniatej architektury, obniżające jednocześnie koszty rozwoju i utrzymania, jakienależałoby ponieść przy zastosowaniu tradycyjnego podejścia.Budowa oprogramowania w oparciu o technologie realizujące SOA, wią-

że się z narzutami natury wydajnościowej. Jednocześnie, brak powszechnejwiedzy na temat SOA i utartych dobrych wzorców wytwarzania powoduje,że często oprogramowanie tworzone w tej architekturze, nie jest napisanew sposób optymalny, bez wykorzystania jej podstawowych zalet. Poważnymwyzwaniem staje się zatem kwestia pomiaru wydajności tworzonych aplika-cji4.Do tej pory świat informatyczny nie dopracował się jednolitej metodolo-

gii pomiarów wydajności systemów o architekturze SOA. Z punktu widzeniainżynierów oprogramowania - niemożliwe jest obecnie przeprowadzenie anali-zy porównawczej takiego oprogramowania. Istniejące rozwiązania pozwalająna pomiary wydajności poszczególnych elementów systemu o architekturzeSOA5, jednakże tematyka kompleksowego rozwiązania tego problemu, niespotkała się dotychczas z dużym zainteresowaniem, zarówno ze strony świa-ta komercyjnego, jak i naukowego.

1.1 Cel pracy

Celem pracy jest analiza problemu pomiaru wydajności aplikacji zbudowa-nych w oparciu o paradygmat SOA. Rozważonych zostanie kilka potencjal-nych rozwiązań oraz przeanalizowane zostaną zalety i wady każdego z nich.W oparciu o postawiony w pracy zestaw wymagań zostanie wybrane i zaim-plementowane najlepsze. Stworzona implementacja zostanie sprawdzona wśrodowisku testowym na zestawie przykładowych aplikacji. Proces testowa-

4Brak zrozumienia kryteriów wydajnościowych jest uznawany za jedno z pięciu naj-większych zagrożeń SOA [5]5Na rynku istnieje szczególnie dużo rozwiązań do testowania wydajności oprogramo-

wania opartego na technologii webservice

6

nia i wyniki będą podstawą do wyciągnięcia wniosków na temat przydatnościwybranego rozwiązania w analizie wydajności aplikacji opartych o SOA.

1.2 Struktura pracy

Niniejsza praca rozpoczyna się opisem technologii wykorzystywanych w two-rzeniu aplikacji opartych o SOA. W rozdziale 3 szczegółowo sformułowanoproblem oraz zbiór wymagań stawianych poszukiwanemu rozwiązaniu. Roz-dział zawiera ponadto dyskusję potencjalnych rozwiązań wraz z ich wadami izaletami. Wybrane jest jedno, które najlepiej spełnia postawione wymagania.W rozdziale 4 omawiane są szczegóły technologiczne implementacji wybrane-go rozwiązania, natomiast w rozdziale 5 wyniki analizy przykładowej aplikacjiw środowisku testowym. Pracę kończy rozdział 6 zawierający zbiór konkluzjiodnośnie możliwości zastosowania i dalszego rozwoju zaimplementowanegosystemu do badania wydajności aplikacji o architekturze SOA.Rozdziały 2.1, 2.2, 3.1, 4, 5.1, 5.5 oraz dodatek A zostały napisane przez

Tomasza Duszkę. Rozdziały 1, 2.3, 2.4, 3.2, 3.3, 3.4, 5.1, 5.2 zostały napisaneprzez Jakuba Janczaka. Pozostałe rozdziały: 6, 7 oraz 8 zostały napisaneprzez autorów pracy wspólnie.

7

Rozdział 2

Technologie

W rozdziale tym zaprezentowano przegląd najważnieszych technologii uży-wanych do realizacji paradygmatu SOA.

2.1 SOA

Zwiększone zainteresowanie SOA związane jest z rozpowszechnianiem siętechnologii webservice i dyskusjami na temat zysków, które można dziękiich wdrożeniu osiągnąć. Problemy poruszane w tych dyskusjach nie są nowe,pojawiały się już od czasu gdy technologia CORBA umożliwiła integracjęheterogenicznych aplikacji z różnych środowisk. Do problemów tych - zwią-zanych z integracją aplikacji - można zaliczyć np:

• niezgodność danych na poziomie binarnym (np. jeden komputer używakodowania Big Endian a inny Little Endian)

• konieczność obsługi rozproszonych mechanizmów transakcyjnych, au-toryzacji i uwierzytelniania

• różnice koncepcyjne pomiędzy użytymi platformami pośredniczącymi(np. RMI operuje na poziomie wywołania metody interfejsu, Sun RPCna poziomie wywołania funkcji)

Technologie obiektowe stworzone w latach 90 XX wieku (CORBA, DCOM,RMI itp.) pozwalają na integrację aplikacji oraz zmniejszają koniecznośćnadmiernego skupiania się inżynierów nad kwestiami technologicznymi tegoprocesu. Dla przykładu obiekty w technologii CORBA (wykorzystującej dotransportu protokół IIOP) mogą komunikować się nie tylko z innymi obiek-tami CORBA, ale także np. z RMI. Technologie te nie rozwiązały wszystkich

8

problemów integracyjnych, a oprócz nich zaczęły pojawiać się nowe utrud-nienia:

• statyczność obiektów, brak możliwości wymiany wadliwych w trakciedziałania systemu

• ścisłe powiązanie elementów systemu (z ang. tight coupling)

• redundantność oprogramowania (np. implementacja tej samej funkcjo-nalności w kilku systemach)

• brak ponownego użytkowania już stworzonych podsystemów

• integracja N podsystemów (z których każdy może używać każdego inne-go) wymagała ilości połączeń proporcjonalnej do kwadratu ilości pod-systemów (por. rysunek 2.1)

Rysunek 2.1: Schemat integracji 4 podsystemów (każdy-z-każdym)

Na przełomie XX i XXI wieku pojawiły się technologie, których uży-cie pozwoliło rozwiązać część wspomnianych problemów. Najpopularniejszez nich to technologia webservice. Jednak oprócz technologii potrzebny byłrównież ogólny opis architektury. Architektury, w której aplikacje mogły byćtworzone, integrowane i powtórnie użytkowane; która umożliwiłaby składa-nie aplikacji z gotowych elementów w celu szybkiego dostarczania rozwiązań.Próbą odpowiedzi na te potrzeby było zaproponowanie SOA.

SOA (Service Oriented Architecture) [9] - architekturazorientowana na luźno powiązane usługi.

Usługa - logiczna reprezentacja powtarzalnej czynności biz-nesowej mająca oczekiwany rezultat (np. pobierz prognozę pogo-dy, sprawdź czy osoba figuruje w krajowym rejestrze długów)[9].

9

Podkreślenia wymaga fakt, że SOA i webservice nie są pojęciami równo-znacznymi. Usługi webservice są dowodem i przykładem na istnienie techno-logii, która umożliwia konstrukcję systemu zgodnego z SOA.Na rysunku 2.2 znajduje się przykładowy schemat funkcjonowania apli-

kacji opartej o SOA. Pierwszym etapem jej działania jest wyszukanie wy-maganej usługi w rejestrze (uzyskuje się w ten sposób m.in. informację olokalizacji usługi). Następnie do usługi wysłane zostaje żądanie wykonaniaoperacji, które jest przez nią przetwarzane a rezultat odesłany z powrotem doaplikacji. Schemat ten jest powielany dla każdej z usług, a cały ciąg wywołańjest sterowany kodem aplikacji SOA.

Rysunek 2.2: Przykładowy schemat funkcjonowania aplikacji opartej o SOA

2.1.1 Kluczowe elementy

Wybrane elementy funkcjonowania systemu opartego o SOA:

1. Wszystkie operacje systemu są zdefiniowane jako usługi. Mogą to byćzarówno proste operacje biznesowe (pobierz stan konta), operacje trans-akcyjne zbudowane z innych usług (przelew między rachunkami) jak ifunkcje systemowe (np. wyślij e-mail). Do inżynierów należy decyzja opoziomie ziarnistości oferowanych usług.

10

2. Interfejs usługi jest odseparowany od implementacji. Konsumenciusługi nie znają dokładnego sposobu realizacji operacji, znają jedyniesemantykę i syntaktykę tej operacji.

3. Prawidłowe funkcjonowanie systemu przy zachowaniu luźnego wiązania(ang. loose coupling) między usługami uzyskuje się dzięki wprowadze-niu kontraktów.

4. System jest systemem dynamicznym. W trakcie jego działania moż-na dodawać nowe usługi oraz wymieniać stare (np. poprawiać znalezio-ne w nich błędy, konstruować efektywniejsze wersje usługi).

5. Istnieje możliwość wielokrotnej implementacji tej samej usługi wróżnych wersjach (np. za pomocą różnych algorytmów, różnych dostaw-ców). Użytkownik decyduje której instancji usługi chce użyć (np. tejktóra w danej chwili jest najmniej obciążona lub tej która jest najtań-sza).

6. Budowanie systemu odbywa się na zasadzie kompozycji z istnieją-cych już usług. Poprzednio systemy były tworzone poprzez integracjęelementów, co powodowało konieczność pisania kodu dostosowującegomechanizmy tych elementów (np. sposobu komunikacji, obsługi trans-akcji, kontroli dostępu).

7. Występuje całkowita transparentność lokalizacji. Konsument usługinie jest świadomy gdzie fizycznie operacje danej usługi są wykonywane.Usługa może w sposób niezauważalny dla konsumenta migrować pomię-dzy maszynami w trakcie działania systemu albo być zreplikowana nakilka maszyn w celu zmniejszenia czasu wykonywania operacji.

Dodatkowej uwagi wymaga pojęcie kontraktów, będących podstawą prawi-dłowej konstrukcji oprogramowania opartego o SOA.

2.1.2 Kontrakt

Kontrakty są zawierane każdorazowo pomiędzy usługą a jej konsumentem(którym może być także inna usługa). Umożliwiają separację interfejsów odimplementacji oraz realizację luźnych powiązań pomiędzy usługami (mody-fikacja szczegółów implementacji usługi nie powoduje zmian w kontrakcie, awięc jest transparentna dla konsumentów danej usługi). Zawierają opis in-formacji oferowanych i oczekiwanych przez usługę. Dobry kontrakt powinienzawierać następujące pozycje [52]:

11

• ogólne informacje o usłudze

– nazwa kontraktu, wersja

– właściciel (osoba/organizacja)

– rodzaj usługi (np. integracyjna, prezentacyjna, biznesowa)

• opis funkcjonalny operacji zawartych w usłudze

– semantyka operacji (wymagania funkcjonalne w stosunku do usłu-gi)

– syntaktyka operacji (typy argumentów i rezultatów, wyjątki)

– szczegóły sposobu wywołania operacji (adres URL usługi oraz ro-dzaj protokołu transportu np. SOAP)

• opis niefunkcjonalny

– transakcyjność operacji

– QoS (Quality of Service)

– SLA (Service Level Agreement) np. dozwolone opóźnienie w wy-konywaniu usługi

– autoryzacja, ograniczenie dostępu do operacji serwisu określonejgrupie konsumentów

Podkreślenia wymaga fakt, że nie istnieje sformalizowana postać kontrak-tu SOA. Powyższe informacje są jedynie proponowaną zawartością kontraktu.Rzeczywista zawartość kontraktu będzie miała różną postać w zależności odużytej technologii.

Paradygmat SOA w praktyce może zostać zrealizowany na różne sposoby.Najpopularniejszym z nich jest użycie technologii webservice.

2.2 Webservice

Międzynarodowa organizacja W3C [19] zajmująca się ustanawianiem stan-dardów dotyczących Internetu zdefiniowała webservice w sposób następujący[22]:

Webservice - oprogramowanie wspierające wymianę danychmiędzy maszynami poprzez sieć, wykorzystujące w tym celu zbiórustandaryzowanych technologii (WSDL, XML, SOAP, UDDI)[22].

12

Webservice nie jest synonimem SOA. SOA jest to architektura zoriento-wana na luźno powiązane usługi, podczas gdy webservice jest to zbiór kon-kretnych technologii (WSDL, XML, SOAP, UDDI), użytych do realizacjiSOA. Technologia webservice jest więc przykładowym sposobem realizacjiSOA, nie jedynym, ale w dotychczasowej praktyce jednym z najpopularniej-szych.Przykładowy scenariusz użycia webservice zaprezentowany został na ry-

sunku 2.3. Składa się on z następujących etapów:

• wyszukanie konkretnej usługi w rejestrze UDDI

• uzyskanie dokumentu WSDL usługi

• wysłanie zapytania zgodnego z protokołem SOAP do usługi

• przetworzenie zapytania przez usługę

• odebranie odpowiedzi zgodnej z protokołem SOAP od usługi

Rysunek 2.3: Przykład funkcjonowania aplikacji opartej o usługi webservice

Implementacja usług webservice odbywa się z wykorzystaniem ustanda-ryzowanych technologii:

13

• WSDL (Web Service Definition Language) - opis usługi w postaci XML

• SOAP - protokół wymiany danych z usługami

• UDDI (Universal Description, Discovery and Integration) - obsługa re-jestru usług.

2.2.1 WSDL

WSDL (Web Service Definition Language) jest to dokument XML opisującywebservice. Może przechowywać zarówno ogólną informację o usłudze (opera-cje i ich argumenty) jak również szczegółowe informacje (powiązanie usług zprotokołami i adresami pod którymi usługi te są dostępne). Plik WSDL skła-da się z definicji następujących elementów (w nawiasach podano oryginalneangielskie nazwy)[23]:

• typ (type) - definicja typu danych

• komunikat (message) - złożony typ danych

• operacja (operation) - definicja operacji wraz z komunikatami zawiera-jącymi argumenty oraz rezultat operacji

• typ portu (port type) - zbiór operacji

• wiązanie (binding) - typ portu powiązany z konkretnym protokołem(np. SOAP+HTTP)

• port (port) - wiązanie wraz z adresem (np. URL dla HTTP, e-mail dlaSMTP)

• usługa (service)- zbiór portów

Dokument WSDL nie jest obowiązkowym elementem każdego webservice.Jeśli jednak występuje to jest on realizacją kontraktu SOA pomiędzy usługąa jej konsumentem. Zawiera opis parametrów oczekiwanych przez usługę orazoferowanych (typ rezultatu, nazwy operacji określające ich semantykę). Nieodwołuje się w żaden sposób do implementacji usługi, dzięki czemu występu-je separacja pomiędzy interfejsem usługi (opisywanym wWSDL i kontrakcie)a jej implementacją. Zmiany w implementacji usługi - nie powodujące zmianw semantyce ani syntaktyce operacji - nie zmieniają dokumentu WSDL tejusługi. Tym samym nie naruszają kontraktu i nie wymagają zmian u konsu-mentów usługi.

14

2.2.2 SOAP

SOAP (dawniej Simple Object Access Protocol, później Service Oriented Ar-chitecture Protocol, obecnie brak oficjalnego rozwinięcia tego akronimu[20])jest to protokół opisujący sposób kodowania i wymiany wiadomości w for-macie XML. Do przesyłania wiadomości zakodowanej zgodnie z SOAP naj-częściej wykorzystuje się protokół HTTP/HTTPS (ze względu na jego po-pularność w internecie), ale możliwe jest też wykorzystanie np. SMTP, FTP,RMI/IIOP. Protokół SOAP może być użyty w realizacji różnych wzorcówwymiany wiadomości (MEP - Message Exchange Pattern), ale dla potrzebwebservice używa się go w RPC (RPC - Remote Procedure Call)[21].Wiadomość SOAP z załącznikami składa się z:

• właściwej wiadomości SOAP w formacie XML

– elementów nagłówka (opcjonalne)

– treści wiadomości

• załączników przechowujących dane binarne

Rysunek 2.4: Postać wiadomości SOAP z załącznikami [24]

Proces wykonania operacji danego webservice rozpoczyna się od stwo-rzenia odpowiedniej wiadomości w formacie SOAP. Format tej wiadomości

15

został przedstawiony na rysunku 2.4. W jej treści przesyłane są informacje ożądanej operacji oraz wartościach jej parametrów. Dodatkowo (w nagłówku)mogą być przekazane np. parametry do autoryzacji (nazwa użytkownika ihasło), identyfikator sesji. Po wysłaniu wiadomości do usługi (np. na adresuzyskany z pliku WSDL) następuje wykonanie żądanej operacji i odesłanieodpowiedzi do nadawcy. Odpowiedź jest również zakodowana w formacie SO-AP i zawiera informacje o rezultacie wykonania operacji (lub ewentualnychwyjątkach).

2.2.3 UDDI

UDDI (Universal Description, Discovery and Integration)[63] - technologiapozwalająca na publikację i wyszukiwanie informacji o usługach webservi-ce. Jest to otwarty standard zarządzany przez organizację OASIS [7]. Spo-sób wykorzystania UDDI opiera się na mechanizmie publikacja-wyszukanie-powiązanie (z ang. publish-find-bind) przedstawionym na rysunku 2.5:

• użycie usługi musi być poprzedzone opublikowaniem jej w rejestrze

• konsument wyszukuje interesujące go usługi w rejestrze

• po znalezieniu usługi następuje powiązanie jej z konsumentem, któryuzyskuje możliwość wykonywania operacji tej usługi

Rysunek 2.5: Schemat wykorzystania UDDI [24]

UDDI przechowuje informację o zbiorze podmiotów biznesowych. Poje-dyńczy wpis o podmiocie biznesowym podzielony jest na następujące grupy:

• “white pages” - adres, dane kontaktowe

• “yellow pages” - kategorie do jakich należy biznes i jego usługi

16

• “green pages” - techniczne informacje o udostępnianych usługach (m.in.adresy URL plików WSDL)

W roku 2000 wraz ze specyfikacją standardu UDDI powstał publicznyrejestr usług UDDI stworzony przez firmę IBM, Microsoft oraz SAP [14]. Wrejestrze tym, do momentu jego wyłączenia w roku 2006, zgromadzono ponad50000 wpisów o usługach [14]. Wyłączenie publicznego rejestru było efektemzwiększającego się zainteresowania podmiotów biznesowych prywatnymi re-jestrami UDDI.

Oprócz technologii webservice możliwość realizacji paradygmatu SOA da-je również platforma integracyjna ESB.

2.3 Enterprise Service Bus

ESB (Enterprise Service Bus) to jedno z podejść które ułatwia tworzenieoprogramowania o architekturze SOA. Zakłada ono tworzenie sterowanegozdarzeniami systemu opartego o luźno powiązane usługi. Wymiana danychjest dokonywana przez szynę, której zadaniem jest wyznaczanie tras wiado-mości, na podstawie dostarczonej konfiguracji. Głównym zamiarem jej twór-ców było rozluźnienie powiązania pomiędzy wykorzystywanymi usługami, amedium transportowym, co przedstawia rysunek 2.6.

Rysunek 2.6: Zasada działania ESB [1]

17

2.3.1 Historia ESB

ESB powstało na bazie scharakteryzowanych poniżej, bardzo obecnie popu-larnych koncepcji MOM i EAI.

Message Oriented Middleware to architektura której rozwój rozpocząłsię na początku lat 80 i trwa do dziś. Opiera się ona na koncepcji asyn-chronicznej wymiany jednostek danych (wiadomości) za pomocą jednolitychprotokołów komunikacyjnych. Podstawowymi trybami komunikacji MOM są:

• Point-to-Point (punkt-punkt) - tryb w którym istnieje tylko jeden pro-ducent i jeden konsument wiadomości

• Publish/Subscribe (publikuj/zapisz się) - tryb w którym istnieje jedenproducent, a odbiorców może być dowolna ilość.

Użycie rozwiązań MOM stało się standardem obsługi asynchronicznychzdarzeń w dużych aplikacjach biznesowych, stymulując jednocześnie ich roz-wój. Wiele z nich posiada tak zaawansowane właściwości jak: niezawodnośćdostarczania, kolejkowanie i filtrowanie wiadomości, transakcyjność, możli-wość klastrowania, czy zaawansowane mechanizmy bezpieczeństwa.Do standardów realizujących ideę MOM należą między innymi:JMS (Ja-

va Messaging System) [15], IceStorm [45], CORBA Notification Service [8],Microsoft MSQM [13] oraz specyfikacje WS-Events [65] i WS-Notifications[66].

Rysunek 2.7: Zasada działania MOM

EAI Enterprise Application Integration, to idea która pojawiła się w po-łowie lat 90. Celem jaki przyświecał jej twórcom była redukcja ilości ko-niecznych połączeń w systemie rozproszonym poprzez wprowadzenie jednegocentralnego punktu tzw. hub-and-spoke broker (pol. pośrednik w strukturze

18

gwiaździstej). Na punkcie tym spoczywa zadanie zawiadywania całą komuni-kacją w obrębie systemu - to on decyduje o tym gdzie ma trafić dana wiado-mość. Architektura ta separuje aplikację od właściwego kodu integrującegopoprzez użycie oprogramowania BPM (Business Process Management)[68].

Rysunek 2.8: Zasada działania EAI [4]

W założeniach EAI miała być stosowana w następujących przypadkach:

• Integracja procesów biznesowych - zapewnienie łączności pomiędzy pro-cesami biznesowymi aplikacji istniejących w dużych systemach

• Zapewnianie integralności danych w różnych częściach systemu1

• Uniezależnienie implementacji od systemów zewnętrznych - przeniesie-nie reguł i polityk biznesowych do EAI, tak aby zmiany dostawców niewpływały na inne części systemu

• Udostępnienie ujednoliconego interfejsu dla złożonych aplikacji

Istnieje wiele implementacji EAI, wśród najbardziej znanych znajdują się:Microsoft BizTalk ServerTM, SAP Exchange Infrastructure (SAP XI) TMorazwebMethods Integration Server TM.

19

Rysunek 2.9: ESB jako pochodna EAI i MOM

ESB jest pochodną obu technologii Rysunek 2.3.1 obrazuje sposób wjaki ESB czerpało swoje cechy z obu podejść. Korzysta z charakterystycznejdla MOM rozproszonej infrastruktury dostarczania wiadomości oraz oddzielalogikę dostarczania od ich właściwego przetwarzania, co jest specyficzne dlaEAI.

2.3.2 Założenia i cechy ESB

Jednym z najważniejszych zamierzeń twórców ESB było osiągniecie możliwo-ści zastosowania tego rozwiązania w największej liczbie przypadków. Dlategoteż idea ESB opiera się na następujących założeniach:

• adaptowalność niezależna od warunków wdrożenia - skali, technologiiuczestniczących czy sposobu modelowania aplikacji

• zunifikowane podejście do połączenia poszczególnych elementów opro-gramowania

• łatwość integracji z oprogramowaniem zarówno wewnątrz, jak i na ze-wnątrz korporacji

• prostota tworzenia aplikacji i dodawania do już istniejącego rozwiązania

• zdecentralizowanie działania usług integracyjnych

• zwiększona przejrzystość systemu1Znane również pod terminem EII (Enterprise Information Integration)

20

• duża elastyczność i łatwość reagowania na zmieniające się wymagania

• zapewnienie dużej skalowalności tworzonych rozwiązań.

Cechy ESB Z uwagi na fakt, iż koncepcja ESB nie jest poparta żadnymstandardem, nie da się wyróżnić możliwości jakich takie oprogramowanie win-no dostarczać. Istnieje jednak pewien ustalony zakres funkcjonalności i cech,które takie rozwiązanie zwykło spełniać. Do takich należą [4]:

• Autonomiczność z możliwością dostępu z zewnątrz

• Bezpieczeństwo i niezawodność

• Integracja oparta o uznane standardy - do tych standardów należą

– XML - najpowszechniej używany obecnie język opisu danych, wrazz językami wspomagającymi jego użycie, tj. XSD, XPath czy XSLT

– WSDL - zwyczajowo stosowany do opisu interfejsów usług

– Standardy dostępu do danych tj. LDAP, SQL czy RSS

– Standardy wymiany danych tj. SOAP, REST, DCOM czy XMPP

– Standardy transformacji danych tj. XSLT czy stosowany w hur-towniach danych (ang. data warehouses) ETL

• Dostarczenie ustalonego zestawu funkcjonalności, w który zwy-czajowo wchodzą:

– Możliwość sterowania procesem wykonania - z użyciem ta-kich standardów jak WS-BPEL, WS-Choreography czy (mniej po-pularnego) ebXML BPSS.

– Rozproszone transformacje danych

– Przetwarzanie danych w czasie rzeczywistym - możliwośćdefiniowania reakcji na konkretne wartości lub trendy danych

– Zdalna konfiguracja

– Zdalne zarządzanie

– Monitorowanie.

21

2.3.3 Istniejące implementacje ESB

Na rynku istnieje wiele implementacji ESB. Do najbardziej znanych należą:

• Sonic ESB - najstarsza implementacja ESB [61]

• OpenESB (Glassfish) [59]

• JBoss ESB [56]

• WebSphere ESB [10]

• MULE [57]

• Apache ServiceMix [60]

• BEA Aqualogic Service Bus [3]

Autorzy przeanalizowali powyższe rozwiązania pod kątem wymagań pra-cy, zwracając największą uwagę na otwartość kodu i prostotę tworzenia apli-kacji. Do realizacji pracy wybrano środowisko OpenESB.

2.3.4 Wdrożenia ESB

Mimo swojej krótkiej historii, wiele firm zaadaptowało już lub też jest wtrakcie adaptowania rozwiązań integracyjnych w oparciu o ESB. Do godnychuwagi należą:

• Wdrożenie ESB w infrastrukturze jednego z wiodących pożyczkodaw-ców w Stanach Zjednoczonych, pozwoliło na obniżenie kosztów prze-twarzania danych o 60%. Dokonano tego poprzez oparcie o ESB jed-nolitego systemu informacji o klientach spinającego rozsiane po całymkraju biura kredytowe oraz system eCredit. [4]

• Trwające 3 tygodnie wdrożenie ESB w jednej z największych sieci dys-trybucji żywności w Europie, pozwoliło na zaoszczędzenie 3 milionówdolarów. Rolą ESB było zintegrowanie systemów trzech różnych syste-mów informatycznych, celem automatyzacji zakupu, sprzedaży i zarzą-dzania logistyką.

• Jedna z największych firm energetycznych w Stanach Zjednoczonych(10 miliardów dolarów obrotu rocznie), używa ESB w rachunkowości,zarządzaniu systemem i raportowaniu. Dodatkowo na ESB oparta jestrealizacja regulowanej prawnie komunikacji z rządem. [4]

22

• Udział ESB w integracji systemów komórek rządowych Stanów Zjedno-czonych celem walki z terroryzmem w ramach dokumentu “USA PatriotAct”. [4]

Istnienie wdrożeń o znaczeniu krytycznym świadczy, o dużych możliwo-ściach koncepcji ESB, w kontekście rozwiązań tego typu.

Problemy ESB

Zaawansowanie koncepcji ESB pociąga za sobą szereg problemów wśród któ-rych najbardziej znaczące to:

• Spowodowany krótką historią technologii, brak odpowiedniej ilości eks-pertów dysponujących wiedzą wystarczającą do zarządzania i konfigu-racji ESB

• Ważny w kontekście tej pracy, duży narzut technologiczny - biorącpod uwagę użycie takich koncepcji jak orchiestracja, czy transformacjeXSLT, przy dodatkowym wykorzystaniu usług webservice zbudowa-nych w oparciu technologię SOAP, istnieje duża obawa, że obciążeniegenerowane przez samo oprogramowanie warstwy pośredniczącej, możebyć znaczące.

2.3.5 JBI

JBI (Java Business Integration) - to specyfikacja JCP2(Java Community Pro-cess), która pozwala na stworzenie środowiska realizującego założenia ESBw technologiach związanych z językiem Java. Definiuje on środowisko kom-ponentów realizujących model wymiany danych oparty o specyfikację WSDL2.0[23]. Specyfikacja stanowi, iż komponenty JBI muszą posiadać następującetrzy cechy:

• Przenośność pomiędzy różnymi implementacjami kontenera JBI

• Scentralizowane zarządzanie

• Współpraca z innymi komponentami w obrębie kontenera, nieza-leżnie od tego skąd pochodzą

Każdy z komponentów realizuje funkcję dostawcy i/lub konsumenta usługi[28][42].Podstawową nomenklaturę JBI przedstawia rysunek 2.10; wyróżnia ona

następujące elementy:2JSR-208 (Java Specification Request) tworzony przez takie firmy jak Syn Microsys-

tems, BEA, Borland, Nokia, Novell czy Oracle[46]

23

Rysunek 2.10: Nomenklatura JBI[28]

Jednostka usługowa (SU) (org. service unit) - to jednostka programo-wa dostarczająca konkretnej implementacji usług korzystająca z właściwościkontenera w którym została umieszczona. Aplikacje składają się ze skompo-nowanych SU umieszczonych w kontenerach środowiska JBI.

Silniki usługowe (SE) (org. service engine) - to komponenty wykonawczeumieszczane w kontenerze JBI, których zadaniem jest dostarczanie lub ko-rzystanie z usług w jego obrębie. Komponenty te dostarczają właściwej logikitakiej jak obsługa transformacji, reguł biznesowych czy języków skryptowych.SE pełnią rolę kontenerów dla SU.

Komponenty wiążące (BC) (org. binding component) - to komponentyzapewniające łączność kontenera ze światem zewnętrznym w obu kierunkach- każdy z nich realizuje określony protokół komunikacyjny. Wiadomości sątransformowane i przekazywane z i do NMR, który decyduje o jej dalszejdrodze. Takie podejście, pozwala każdemy SE komunikować się ze światemzewnętrznym z pomocą dowolnego obsługiwanego przez kontener protokołu.Podobnie jak SE, BC również pełnią rolę kontenerów dla SU.

Router wiadomości o jednolitym formacie (NMR) (org. Normali-zed Message Router) - najważniejsza część środowiska JBI - stanowi element

24

który zajmuje się sterowaniem przepływem wiadomości z punktów źródło-wych do punktów docelowych, na podstawie określonego z góry kontraktu.NMR może również realizować pewne funkcje QoS dotyczące dostarczaniawiadomości w obrębie kontenera.

Kontener JBI (org. JBI Container) - środowisko wykonawcze komponen-tów JBI - zarówno BC jak i SE.

Kontrakt

Implementując komponent JBI, realizujemy pewien kontrakt, który obejmujezagadnienia instalacji, pakowania, zarządzania cyklem życia, publikacji ofe-rowanych usługi i przetwarzania wiadomości bazujące na jednym z czterechMEP (Message Exchange Pattern)3.

MEP - wzorce wymiany wiadomości NMR dostarcza wiadomości re-alizując jeden z czterech wzorców wymiany wiadomości będących częścią spe-cyfikacji WSDL 2.0[23][1]:

• In-Only - standardowy sposób przesyłania w jedną stronę, w którymkonsument wysyła wiadomość do dostawcy usługi, który odpowiadastatusem

• Robust In-Only - niezawodny sposób przesyłania jednokierunkowego,w którym konsument wysyła wiadomość do dostawcy, który odpowiadastatusem, i jeśli jest to błąd (fault), odesłane zostaje potwierdzenie

• In-Out - dwukierunkowy sposób wymiany wiadomości w którym nawiadomość konsumenta, dostawca usługi wysyła odpowiedź która jestnastępnie potwierdzana

• In Optional-Out - dwukierunkowy sposób wymiany wiadomości, wktórym wiadomość będąca odpowiedzią na żądanie konsumenta jestopcjonalna

Implementacje JBI

Najszerzej znane implementacje kontenera JBI to:

• ServiceMix (FUSE ESB) [60]3opcjonalnie do kontraktu może należeć również zarządzanie jednostką usługową (SU -

z ang. service unit)

25

• OpenJBI (OpenESB) [59]

• JBossESB [56]

• ObjectWeb2 PEtALS [58]

zgodny z JBI jest również MULE [57].Do celów pracy wybrano implementację OpenJBI firmy Sun MicrosystemsTM.

2.4 BPEL

Aby w pełni korzystać z zalet SOA, konieczne jest osiągniecie niezależnościkompozycji usług, od ich implementacji.[12]Istnieją dwa podejścia do tego zagadnienia [34]:

• Orchiestracja - w której jeden centralny komponent przejmuje kon-trolę nad usługami będącymi uczestnikami procesu biznesowego, ko-ordynując ich współpracę. Usługi nie są świadome bycia uczestnikamiprocesu biznesowego (przykład ilustruje rys 2.11).

Rysunek 2.11: Orchiestracja

• Choreografia - podejście w którym zamiast jednego centralnego punk-tu, każda usługa wie kiedy i z jakimi usługami ma się komunikować.

26

Usługi muszą być świadome uczestniczenia w procesie biznesowym (przy-kład ilustruje rysunek 2.12).

Rysunek 2.12: Choreografia

BPEL[6] (Business Process Execution Language) jest to zdefiniowanyprzez organizację OASIS język orchiestracji procesów biznesowych opartycho usługi zdefiniowane w języku WSDL.Język ten pozwala na modelowanie na dwóch poziomach abstrakcji: opi-

sowym poziomie abstrakcyjnym(z ang. Abstract Business Process)4 i dokład-niejszym poziomie wykonania(z ang. Executable Business Process)[6].Interakcja z usługami w języku BPEL odbywa się na dwa sposoby:

• eksport funkcjonalności, wykonanie procesu BPEL jest zwykle wyzwa-lane poprzez żądanie wykonania operacji webservice

• import funkcjonalności, proces BPEL umożliwia wykonanie operacji nausługach webservice

4modele takie nie mają być wykonywane, a są jedynie tworzone celem zobrazowaniapewnego konkretnego procesu

27

2.4.1 Wersje BPEL

Wersje 1.0 i 1.1 BPEL,a w zasadzie BPEL4WS (Business Process Exe-cution Language for Web Services) powstał w 2002 jako efekt współpra-cy firm BEA, IBM i Microsoft. W roku 2003 do organizacji specyfikującejBPEL dołączyły firmy SAP oraz Siebel Systems, a język ewoluował do wer-sji 1.1. Wersja ta została zaaprobowana przez organizację OASIS (Organiza-tion for the Advancement of Structured Information Standards), i od tam-tego czasu język ten stał się standardem w dziedzinie kompozycji procesówbiznesowych[11][34][41][39].

Możliwości języka BPEL w wersji 1.1 Specyfikacja języka BPELprzewiduje następujące możliwości:

• definiowanie typowanych zmiennych i synchronizowany dostęp do nich

• wykonywanie operacji webservice

• równoległe wykonywanie operacji

• definiowanie zasięgów (scope) dla zmiennych

• rzucanie i obsługiwanie wyjątków

• dostęp do zmiennych za pomocą wyrażeń XPath

• manipulacja zmiennymi

Dostępne konstrukcje BPEL w wersji 1.1 oferuje następujące kon-strukcje:

• Proste

– Assign przypisanie wartości zmiennej

– Wait oczekiwanie określony okres czasu

– Empty instrukcja pusta

– Throw rzucenie wyjątku

– ReThrow ponowne rzucenie złapanego wyjątku

– Exit zakończenie procesu

28

– Compensate pozwalające na zdefiniowanie zachowania procesuw obrębie transakcji, w przypadku, gdy jedna z jego składowychzawiedzie (próba odwrócenia efektów działania elementów już wy-konanych5)

• Strukturalne

– Sequence wydzielony blok strukturalny

– Scope zasięg zmiennej

– If instrukcja warunkowa

– While pętla z warunkiem ewaluowanym na jej początku

– Pick oczekiwanie na jedno z zadeklarowanych zdarzeń

– Flow wykonanie równoległe

• Operacje na usługach webservice

– Receive odebranie wiadomości z usługi dostarczanej przez pro-ces6

– Reply odpowiedź na odebraną wiadomość7

– Invoke wykonanie operacji na usłudze webservice.

Wersja 2.0

Opracowana w roku 2004 nowa wersja języka BPEL wprowadziła takie uspraw-nienia jak możliwość rozszerzania języka, czy uproszczenia w przypisywaniui inicjalizacji zmiennych. Pojawiły się nowe pętle: RepeatUntil8 i wykonywa-na zarówno równolegle, jak i sekwencyjnie ForEach9. Uproszczono równieżobsługę błędów oraz inicjalizację tzw. Partner Link10. Zmieniono również ofi-cjalną nazwę języka - obecnie oficjalną nazwą jest WS-BPEL (Web Service -Business Process Execution Language)11[11][34][41][64].

5analogiczne do zachowania transakcyjności w bazach danych, tzw. ACID (skrót tenpochodzi z terminologii baz danych, i oznacza cztery warunki jakie muszą spełniać trans-akcje: atomowość, spójność, izolacja i trwałość (z ang. Atomicity, Consistency, Isolation,Durability)[35])6operacja ta jest najczęściej operacją wyzwalającą proces7analogicznie operacja taka najczęściej kończy wyzwolony proces8pętla z warunkiem ewaluowanym na jej końcu9pętla dokonująca pewnych operacji na zbiorze danych10odniesień do usług w obrębie procesów11uczyniono tak celem dopasowania się do pozostałych nazw standardów z zakresu tech-nologii webservice których nazwy zwyczajowo zaczynają się od “WS-”

29

Wszystkie dostępne obecnie konstrukcje języka BPEL, wraz z ich graficzny-mi reprezentacjami przedstawia rysunek 2.13(należy mieć jednak na uwadzefakt, iż reprezentacje te nie stanowią części standardu).

Rysunek 2.13: Elementy konstrukcyjne języka BPEL

2.4.2 Dostępne implementacje BPEL

Język BPEL jest obsługiwany w wielu środowiskach integracyjnych, zarównojako komponenty, jak i samodzielne rozwiązania. Do najbardziej rozwiniętychkomercyjnych rozwiązań należą[12]:

• IBM Websphere Business Integration FoundationTM[10]

30

• Oracle BPEL Process ManagerTM[50]

• Microsoft BizTalkTM[47]

• BEA AqualogicTM[3]

Istnieje również kilka rozwiązań niekomercyjnych takich jak:

• OpenESB BPEL JBI Component[59]

• ActiveBPEL Engine[36]

• Apache ODE[37]

Rysunek 2.14: Pakiet Netbeans - wizualny edytor procesu BPEL

Istnieje również szereg narzędzi ułatwiających modelowanie procesów wjęzyku BPEL, takich jak oparte na platformie Eclipse Oracle BPEL Designer[49]i IBM Websphere Application Developer Integration Edition[44], czy wybra-ny przez autorów, oparty o platformę Netbeans BPEL Designer[48] (przedsta-wiony na rys. 2.14). Wybór ten został podyktowany dojrzałością i otwartościąrozwiązania, oraz zaawansowaną integracją z wybranym wcześniej środowi-skiem OpenESB.

31

Wysoka innowacyjność opisanych w niniejszym rozdziale koncepcji i tech-nologii, sprawia że nie są one obecnie w powszechnym użyciu. Wydajnośćaplikacji zrealizowanych z ich użyciem, może być badana z użyciem oprogra-mowania stworzonego w ramach niniejszej pracy.

32

Rozdział 3

System badania wydajności

W rozdziale tym opisane zostały kryteria jakie powinien spełniać systemwspomagający badanie wydajności systemów o architekturze SOA. W kolej-nych punktach rozdziału przedstawiono analizę w kontekście tych kryterióworaz uzasadnienie ostatecznego wyboru.W celu zbadania wydajności aplikacji zbudowanej zgodnie z paradygma-

tem SOA potrzebne są dodatkowe dane zbierane w trakcie działania takiejaplikacji. Dane te opisują jednostkowe operacje wykonywane przez aplikację(np. wywołanie usługi webservice, sekwencje wywołań operacji, pętle, in-strukcje warunkowe, bloki obsługi wyjątków) i zawierają m.in. informację oczasie trwania danej operacji, dodatkowych parametrach (np. adres i operacjaprzy usłudze webservice), statusie (np. zakończenie poprawne, zakończenie zpowodu wyjątku) itp. Po zebraniu pomiary mogą zostać przedstawione użyt-kownikowi w czytelny sposób, np. jako diagramy Gantta[43], model BPEL,wykresy, itp.W systemach badających wydajność za zbieranie danych odpowiada sen-

sor wydajności. Można wyróżnić dwa podejścia do kwestii jego lokalizacji:

• Umieszczenie sensora wydajności w obrębie usług. Takie podejściewymaga modyfikacji każdej z usług, co powoduje, że usługi muszą byćświadome brania udziału w badaniu wydajności. W przypadku posia-dania kodu źródłowego usług konieczna jest jego analiza i odpowiedniamodyfikacja, co czyni ten proces czasochłonnym; przy braku kodu źró-dłowego usług odpowiednia modyfikacja jest już często niewykonalnaw rozsądnych granicach czasowych.

• Umieszczenie sensora wydajności w obrębie kontenera. Zaletą tegopodejścia jest fakt, że modyfikacje środowiska w którym działają usłu-gi należy wykonać tylko raz, niezależnie od ilości wykorzystywanychusług.

33

Rysunek 3.1: Architektura używana do badania wydajności aplikacji

Wariant z sensorem wydajności w usługach jest niepraktyczny w realizacji ijako taki został odrzucony. Podjęto decyzję o umieszczeniu sensora wydaj-ności w obrębie kontenera szyny łączącej usługi. Zarys koncepcji badaniawydajności aplikacji został przedstawiony na rysunku 3.1.Przedstawiona ogólna architektura systemu badania wydajności aplikacji

opartych o paradygmat SOA ukrywa w sobie szereg problemów i decyzji, za-równo koncepcyjnych (np. sposób działania sensora wydajności, sposób iden-tyfikacji procesów i aktywności badanej usługi) jak i technologicznych (np.rodzaj rozwiązania MOM używanego do przesyłania danych o wydajności).Prowadzi to do istnienia wielu możliwych sposobów realizacji takiej aplikacji.Przed wybraniem jednego sposobu należało zdefiniować kryteria różnicującepotencjalne rozwiązania. Kryteriami tymi są wymagania funkcjonalne i nie-funkcjonalne w stosunku do elementów architektury zawartych na rysunku3.1.

34

3.1 Wymagania

Zestaw wymagań został podzielony na dwie grupy, pierwsza dotyczy konsoliwizualizacyjnej, a druga sensora wydajności.

3.1.1 Wymagania w stosunku do konsoli

W stosunku do konsoli wizualizacyjnej postawiono następujące wymagania:

• przygotowanie środowiska poprzez dodanie sensora wydajności (możesię to wiązać z np. instrumentacją bibliotek serwera, modyfikacją je-go plików startowych lub rozmieszczeniem (ang. deploy) w serwerzespecjalnej aplikacji monitorującej wydajność)

• odbieranie informacji o wydajności z wykorzystaniemMessage OrientedMiddleware (np. JMS)

• obrazowanie na bieżąco (ang. online) wyników badania wydajności apli-kacji

• prezentacja wyników w postaci sekwencji języka BPEL (np. wykonanieoperacji usługi webservice, przypisanie wartości do zmiennej)

• równoczesna obsługa kilku instancji środowiska ESB

Uzyskiwane dane o wydajności aplikacji powinny być przedstawiane wsposób przejrzysty dla użytkownika w postaci diagramu z modelem BPEL.Dla każdej operacji przedstawionej na diagramie powinny być dostępne in-formacje:

• średni, minimalny, maksymalny oraz sumaryczny czas trwania operacji

• czas rozpoczęcia i zakończenia, parametry, rezultat (np. zakończenieprzez rzucenie wyjątku) każdego wywołania operacji.

3.1.2 Wymagania w stosunku do sensora wydajności

Typowa metryka uzyskiwana z procesu mierzenia wydajności - czas wyko-nania operacji - może mieć różną wartość w zależności od warstwy na któ-rej działa sensor wydajności. Sytuację tę przedstawiono na rysunku 3.2, naktórym znajduje się przykładowy schemat wywołania usługi webservice zpoziomu języka BPEL w OpenESB. Przykładowo, jeśli sensor umieścimy wobrębie JBI, to w zmierzonym czasie wykonania operacji webservice będzie

35

zawarta tylko część 4 i 5 sekwencji rzeczywistego wywołania operacji (por.rysunek 3.2). Pominięty zostanie wówczas wpływ adaptera JBI oraz silnikaBPEL na czas wykonania operacji, a tym samym zaburzony zostanie wynikbadania wydajności aplikacji. W celu zniwelowania skutków niewłaściwegozbierania wyników wydajności, należy sensor wydajności umieścić w obrębiesilnika BPEL.Wymagania w stosunku do sensora wydajności:

• działanie możliwie blisko silnika BPEL, w celu uzyskania dokładnychwyników

• brak ingerencji w zewnętrzne usługi (sensor nie może modyfikować spo-sobu ich działania)

• minimalny wpływ na działanie aplikacji (najważniejsze jest ogranicze-nie narzutów czasowych związanych ze zbieraniem danych o wydajno-ści)

• możliwość implementacji w najpopularniejszych serwerach aplikacji (sa-ma implementacja sensora wydajności będzie różniła się szczegółami wzależności od serwera aplikacji)

• zautomatyzowany proces dołączania sensora wydajności, z minimalnąingerencją użytkownika.

3.2 Koncepcje rozwiązań

W trakcie analizy możliwości podejścia do postawionego wcześniej problemu,rozróżnione zostały dwie grupy rozwiązań:

• Nie wymagające modyfikacji kodu - koncepcje opierające się na wyko-rzystaniu już istniejących możliwości pobrania informacji pomiarowychze środowiska ESB

• Wymagające modyfikacji środowiska testowego - koncepcje, którychwykorzystanie opiera się na zmianach w kodzie aplikacji, bądź środo-wiska

3.2.1 Koncepcje nie wymagające modyfikacji kodu BPEL

Interfejs monitorowania BPEL OpenESB

Silnik usługowy BPEL zastosowany w implementacji OpenESB udostępniainterfejs programistyczny pozwalający na monitorowanie i zarządzanie pro-

36

Rysunek 3.2: Schemat wywołania usługi webservice w OpenESB

37

cesami wykonywanymi w jego obrębie. Do jego możliwości należą międzyinnymi:

• Udostępnianie identyfikatorów procesów oraz ich instancji

• Zarządzanie cyklem życia procesów oraz ich instancji

• Udostępnianie informacji o błędach, które wystąpiły w instancjach pro-cesów

• Dostęp i zmiana zmiennych instancji

• Dostęp do informacji na temat procesów, instancji, a także aktywnościinstancji (activity)

Wymieniony jako ostatni dostęp do informacji na temat aktywności in-stancji pozwala na sprawdzenie takich danych jak:

• Status aktywności

• Znacznik czasowy początku i końca aktywności

• Czas trwania

• Numer iteracji (pętli)

Sposób dostępu Rysunek 3.3 przedstawia ideę rozwiązania. Bazuje onana aktywnym, synchronicznym odpytywaniu o dane pomiarowe.

Analiza trafności rozwiązania Odpowiednie użycie i agregacja danychpozwalałoby na stworzenie zakładanego systemu do pomiarów wydajności.Rozwiązanie to ma jednak jedną zasadniczą wadę - dane z interfejsu zbiera-ne są synchronicznie1, co pociąga za sobą konsekwencje w postaci możliwościutraty części danych - problem ten dotyczy przede wszystkim konstrukcjipętli. Problemem byłaby również agregacja otrzymanych w taki sposób da-nych oraz dobór częstości próbkowania (w zależności od dobranej wartościstworzone narzędzie byłoby albo narażone na utratę danych, albo na dużynakład obliczeń potrzebny do agregacji).

1użyty został tutaj wzorzec Wizytora[30]

38

Rysunek 3.3: Koncepcja rozwiązania w oparciu o interfejs monitorowaniasilnika BPEL

HULP

HULP to biblioteka dla języka JavaTMpozwalająca na zinstrumentowanie ko-du celem dokonywania pomiarów czasu wykonania obszarów kodu. Oferujeona prosty interfejs programistyczny, z którego użyciem możliwe jest zazna-czanie początku i końca wykonania obszaru kodu. Wykonane w taki sposóbpomiary są następnie zbierane, agregowane i prezentowane z pomocą aplikacjiWWW.

Cechy rozwiązania

• Prosta w realizacji instrumentacja. Przykładowo:1 . . .2 public void komenda ( St r ing parameter ) {3 Measurement m = Measurement . begin ( ”komenda” , parameter ) ;4 try {5 . . . badany obszar kodu6 } f ina l ly {7 m. end ( ) ;8 }9 }

39

• Niski narzut czasowy zinstrumentowanego kodu przy wyłączonym zbie-raniu danych

• Nieskomplikowana budowa - HULP składa się z trzech komponentów:interfejs instrumentacji, klasy agregacji i servlet odpowiedzialny za pre-zentacje wyników

• Zagregowane wyniki zwracane są w postaci zestawu następujących da-nych:

– ilości wywołań

– czas trwania pomiarów2

– sumy oraz średniej czasu spędzonego w zinstrumentowanych ob-szarach kodu

– przepustowości3 pomiaru

– obciążenia4 generowanego podczas pomiaru

Idea rozwiązania z użyciem HULP Rozważanie użycia HULP opierasię na fakcie, iż kod OpenESB już został zinstrumentowany z pomocą tejbiblioteki. Idea rozwiązania opiera się na pobieraniu danych z warstwy pre-zentacji HULP (servletu), dla ich dalszej analizy (ogólny schemat koncepcjiprzedstawia rys. 3.4).

Rysunek 3.4: Koncepcja rozwiązania z użyciem HULP

2od pierwszego begin() do ostatniego end()3ilość wywołań podzielona przez czas trwania pomiarów4suma czasu spędzonego w zinstrumentowanych obszarach kodu podzielona przez czas

trwania pomiarów

40

Analiza trafności rozwiązania Pomimo szeregu zalet tego rozwiązanianie spełnia ono założeń postawionych na początku tego rozdziału. Do naj-ważniejszych problemów związanych z użyciem HULP należą:

• konieczność modyfikacji kodu OpenESB (ponieważ nie wszystkie inte-resujące z punktu widzenia pracy obszary kodu zostały zinstrumento-wane)

• brak znaczników czasowych

• trudności w identyfikacji badanych procesów biznesowych5

• niepełność zagregowanych danych

• trudny do interpretacji maszynowej format dostarczanych danych.

3.2.2 Obserwator zdarzeń silnika BPEL

Silnik BPEL OpenESB udostępnia interfejs (BPEL SE Events Listener) po-zwalający na zarejestrowanie obserwatorów[30] zachodzących w nim zdarzeń.Pozwala to na odbieranie informacji dotyczących procesów oraz ich aktyw-ności i wartości zadeklarowanych w nich zmiennych.[40]Do monitorowanych zdarzeń należą:

• początek, koniec, uśpienie i wybudzenie procesu

• początek, koniec i błąd składowej procesu

• zmiany wartości zmiennych procesu

Każde otrzymywane zdarzenie jest opatrzone identyfikatorem procesu iinstancji oraz znacznikiem czasowym. Zdarzenia dotyczące aktywności pro-cesu zawierają wyrażenie XPath prowadzące do tej aktywności.Klasa obserwatora powinna implementować następujący interfejs:

1 interface EventLis tener {2 void processEvent ( Event event ) ;3 }

Idea rozwiązania Rysunek 3.5 przedstawia ideę rozwiązania opartego oBPEL SE Events Listener. Logika przetwarzania danych pomiarowych otrzy-mywałaby dane po uprzednim zarejestrowaniu obserwatora zdarzeń w silnikuBPEL.5trudności w odróżnieniu kilku działających jednocześnie procesów biznesowych

41

Rysunek 3.5: Koncepcja rozwiązania z użyciem BPEL SE Events Listener

Analiza trafności rozwiązania Rozwiązanie oparte o BPEL SE EventsListener posiada wiele zalet, takich jak prostota, asynchroniczny model dzia-łania oraz duży zakres dostarczanych danych. Ważna właściwością jest rów-nież oparty o pulę wątków nieblokujący model rozsyłania zdarzeń do obserwa-torów, znacznie zmniejszający narzuty czasowe z nim związane. Rozwiązanienie spełnia postawionych założeń pracy: do jego pełnego działania koniecz-na jest instrumentacja aplikacji umieszczanej na serwerze6. Niewątpliwymproblemem jest również brak przenośności tego rozwiązania7 do innych śro-dowisk ESB.

3.2.3 Koncepcje wymagające instrumentacji kodu BPEL

Modyfikacja kodu aplikacji

Najprostszym rozważanym rozwiązaniem jest zmodyfikowanie kodu testowa-nej aplikacji w taki sposób aby sama dostarczała informacji pomiarowych.Modyfikacja taka opierałaby się na dodaniu takiej logiki do kodu BPEL wformie odpowiednio umieszczonych operacji Invoke, przed każdą możliwą ope-racją. Operacje te wysyłałyby informacje pomiarowe do uprzednio stworzonejusługi monitorującej. Koncepcję tę ukazuje rysunek 3.6.Trudności w realizacji tego rozwiązania, konieczność modyfikacji już zbu-

dowanej aplikacji oraz niska wiarygodność dostarczanych znaczników czaso-wych wyklucza jego praktyczne zastosowanie.

6konieczne jest dodanie do niej implementacji obserwa-tora oraz dopisanie nazwy jego klasy w pliku META-INF/services/com.sun.jbi.engine.bpel.core.bpel.event.BPELEventListener7Pozwalałoby ono na monitorowanie jedynie tego konkretnego silnika BPEL

42

Rysunek 3.6: Koncepcja instrumentacji kodu BPEL aplikacji

Modyfikacja kodu środowiska wykonawczego

Skomplikowanym, ale jednocześnie posiadającym najwięcej możliwości roz-wiązaniem jest zmodyfikowanie środowiska wykonawczego w taki sposób, abygenerowało ono zdarzenia i przekazywało je asynchronicznie do zbiorczegopunktu celem dalszej analizy. Zdarzenia te przenosiłyby ze sobą następująceinformacje:

• znaczniki czasowe operacji

• szereg jednoznacznych identyfikatorów pozwalających określić pocho-dzenie danych

– identyfikator procesu BPEL

– identyfikator instancji procesu

– identyfikator aktywności procesu

– identyfikator wątku

• typ aktywności i informacje jej dotyczące (tj. np. identyfikator wywo-ływanej usługi w aktywności Invoke)

43

Generowanie byłoby wyzwalane następującymi zdarzeniami:

• rozpoczęcie procesu biznesowego,

• rozpoczęcie aktywności procesu,

• rzucenie wyjątku w aktywności,

• zakończenie aktywności procesu,

• zakończenie procesu biznesowego.

Asynchronicznie generowane zdarzenia mogą być przekazywane bezpo-średnio do punktu zbiorczego. Celem polepszenia skalowalności rozwiązaniamożna publikować zdarzenia z użyciem oprogramowania realizującego kon-cepcję MOM (np. JMS).Rysunek 3.7 przedstawia zarys tej koncepcji. Wynika z niego, że aby do-

konać takiej instrumentacji konieczna jest statyczna modyfikacja kodu silnikaBPEL. Można tego dokonać albo modyfikując jego otwarty kod źródłowy, lubużyć narzędzia do instrumentacji kodu wykonawczego.

Rysunek 3.7: Koncepcja instrumentacji środowiska wykonania

44

Analiza trafności rozwiązania

Brak konieczności modyfikacji kodu źródłowego zarówno aplikacji, jak i śro-dowiska, jest bardzo dużą zaletą tego rozwiązania. Drugą zaletą jest wia-rygodność dostarczanych danych - instrumentacja kodu w odpowiednio do-branych punktach niweluje problem niemiarodajnych znaczników czasowych.Dekompozycja oprogramowania na część generującą zdarzenia oraz część od-powiedzialną za ich wysyłanie znacznie ogranicza ilość czasu potrzebną doimplementacji rozwiązania pod kątem konkretnej architektury środowiskawykonawczego.

3.3 Wybrane podejście

Biorąc pod uwagę kryterium przenośności, którego spełnienie jest konieczne,w celu stworzenia rozwiązania, stosowalnego w różnych realizacjach ESB, niemożna skorzystać z wymienionych wyżej rozwiązań nie wymagających mody-fikacji kodu. Wszystkie one są charakterystyczne dla środowiska OpenESB ijest bardzo mało prawdopodobne, że będzie możliwa ich realizacja na innychplatformach.Koncepcja modyfikacji procesów biznesowych, jest bardzo prosta, a stwo-

rzenie oprogramowania automatyzującego ten proces jest możliwe do wy-konania. Nie pozwala ona jednak na wygenerowanie zdarzeń opatrzonychjednoznacznymi znacznikami czasowymi, co dyskwalifikuje to rozwiązanie.Ostatnie z przedstawionych rozwiązań, mimo konieczności implementacji

charakterystycznego dla każdego środowiska ESB kodu generującego zdarze-nia pozwala na stworzenie najbardziej elastycznego rozwiązania . Przy odpo-wiedniej dekompozycji stworzonego oprogramowania, i zastosowaniu techniknieintruzywnej instrumentacji, stanowi podstawę do stworzenia rozwiązanianajbardziej uniwersalnego. Adaptacja stworzonego oprogramowania będziewymagała umiarkowanego nakładu pracy. Koncepcja ta została wybrana dorealizacji w ramach niniejszej pracy.

45

Rozdział 4

Implementacja

Stworzone oprogramowanie do badania wydajności aplikacji zgodnych z pa-radygmatem SOA składa się z następujących modułów funkcjonalnych:

• sensor wydajności - element umieszczony w kontenerze, zbiera daneo wydajności i wysyła je do kolejki JMS

– część charakterystyczna dla konkretnego kontenera - wstrzyk-nięta bezpośrednio w kod kontenera i odpowiedzialna za zbieraniedanych o wydajności

– część wspólna dla wszystkich kontenerów - konstruuje ko-munikat i wysyła go asynchronicznie do kolejki JMS

• moduł umieszczający sensor wydajności w kontenerze - doko-nuje instrumentacji bibliotek wchodzących w skład kontenera umiesz-czając w nich sensor wydajności

• konsola wizualizacyjna - odbiera wiadomości z kolejki JMS i wy-świetla zebrane dane

Poszczególne moduły są od siebie niezależne, co ułatwia ich implementa-cje i testowanie.

4.1 Opis wybranych problemów implementa-cyjnych

Najtrudniejszym elementem do realizacji jest moduł umieszczający sensorwydajności w kontenerze. Realizacja tego modułu wymaga wykorzystaniasilnika do instrumentacji (modyfikacji skompilowanego kodu kontenera, bezdostępności jego źródeł) programów napisanych w języku Java.

46

4.1.1 Wstrzykiwanie sensora wydajności

Sensor wydajności może zostać wstrzyknięty do bibliotek kontenera za pomo-cą jednej z dostępnych bezpłatnie bibliotek wspomagających programowanieaspektowe (AOP[33]), np. AspectJ[53] lub Aspectwerkz[54]. Instrumentacjakodu jest realizowana w jednym z dwóch trybów[62]:

• Online - instrumentacja w trakcie działania aplikacji. Zmodyfikowaneklasy (wraz ze wstrzykniętym kodem) mogą być ładowane w momen-cie ich pierwszego użycia lub podmieniane w dowolnym momencie wczasie działania aplikacji. Praktyczna realizacja trybu online wymagaczęsto modyfikacji maszyny wirtualnej (JVM) w której uruchomionajest aplikacja (dodatkowe parametry dla maszyny wirtualnej, modyfi-kacja klas systemowych maszyny wirtualnej[16] (ang. bootstrap classes)itp). Modyfikacje są charakterystyczne dla konkretnej wersji maszynywirtualnej.

• Offline - instrumentacja przed pierwszym uruchomieniem aplikacji.Modyfikacja kodu aplikacji wykonywana jest jednorazowo poprzez sil-nik instrumentacji. Nie ma konieczności wprowadzania żadnych zmiando maszyny wirtualnej w której uruchomiona będzie aplikacja. Jedynązmianą w aplikacji jest podmiana bibliotek na ich zinstrumentowanąwersję.

Sensor wydajności może zostać wstrzyknięty w dowolnym z tych dwóchtrybów pracy. Należy jednak zauważyć, że sensor jest elementem który jestobecny cały czas w kontenerze. Mamy również możliwość przygotowania kon-tenera (jego instrumentacji) przed rozpoczęciem badania wydajności usług.Do realizacji wstrzyknięcia sensora wystarcza więc tryb “offline”. Jego zaletąjest większa prostota użycia w porównaniu do trybu “online” (nie wymagamodyfikacji maszyny wirtualnej na której będzie działać aplikacja ani skryp-tów startowych aplikacji). Po przeprowadzeniu analizy znanych nam bibliotekprogramowania aspektowego (np. AspectJ, Aspectwerkz) pod kątem użyciaich w trybie “offline” można zauważyć nastepujące wady:

• wymagane jest podanie definicji dodatkowych zmiennych (poprzez pa-rameter -D przy poleceniu “java”) w skryptach startowych, np. podanialokalizacji pliku XML z definicją aspektów

• wymagane jest dodanie do listy bibliotek JAR aplikacji dodatkowychplików z kodem specyficznym dla danej biblioteki programowania aspek-towego

47

• używanie biblioteki programowania aspektowego w niepoprawnej wer-sji może powodować konflikty z bibliotekami aspektowymi używanymiprzez kontener (większość kontenerów udostępnia wsparcie dla AOP),jeszcze większe prawdopodobieństwo konfliktów wersji występuje dlabibliotek zależnych wymaganych przez bibliotekę AOP (ang. third-party libraries) np. Apache Commons[38]

Część z przedstawionych wad (modyfikacji listy bibliotek JAR aplikacji,dodatkowe definicje zmiennych) teoretycznie można rozwiązać poprzez mo-dyfikację odpowiednich skryptów startowych kontenera. W praktyce jednakpojawiają się problemy z dużą ilością skryptów w nieznanych lokalizacjach(np. w kontenerze GlassFish każda domena ma własne skrypty) oraz z uru-chamianem kontenera z pominięciem skryptów startowych. Problem konfliktuwersji nie ma prostego rozwiązania. Jednym z potencjalnych rozwiązań (aleniepraktycznych) jest np. zmiana biblioteki AOP w zależności od docelowegokontenera.Z uwagi na przedstawione problemy została podjęta decyzja o stworzeniu

własnej biblioteki instrumentującej kod. Podstawowe założenia takiej biblio-teki to:

• instrumentowanie kodu jedynie w trybie offline

• brak konieczności modyfikacji skryptów startowych aplikacji, maszynwirtualnych itp.

• brak dodatkowych bibliotek, które muszą być dołączane do zinstrumen-towanego kodu

• specyficzna i minimalna funkcjonalność w porównaniu z ogólnymi bi-bliotekami programowania aspektowego, pozwalająca jedynie na wstrzy-kiwanie wywołań metod w dowolne miejsca instrumentowanego kodu

Należy podkreślić fakt, iż biblioteka instrumentująca kod ma bardzo spe-cyficzną funkcjonalność i nie jest równoważna bibliotece wspierającej pro-gramowanie aspektowe (ma nieporównywalnie mniejszą złożoność). Do jejkonstrukcji zostały użyte gotowe moduły (np. biblioteka CGLIB[55] do mani-pulowania skompilowanym kodem Java (ang. bytecode)[29]). Implementacjabiblioteki instrumentującej kod nie była więc zajęciem bardzo czasochłonnymi nie przysłoniła głównego tematu niniejszej pracy.Przykład użycia biblioteki instrumentującej kod znajduje się na rysunku

4.1. W górnej części znajduje się przykładowa aplikacja do której wstrzyk-nięty zostanie dodatkowy kod widoczny w dolnej części. Sterowanie sposo-bem instrumentacji odbywa się poprzez adnotacje obecne we wstrzykiwanym

48

kodzie. Dostępne adnotacje umożliwiają wyznaczenie miejsca wstrzyknięciakodu (np. @BeforeMethodStart oznacza, że kod musi być wstrzyknięty na po-czątek metody określonej przez @InstrumentMethod). Możliwe jest równieżpobieranie parametrów przekazywanych do instrumentowanej metody (np.@LinkParameter(i) przekazuje do danej zmiennej i-ty parametr instrumen-towanej metody).

Rysunek 4.1: Przykład użycia biblioteki instrumentującej kod

Adnotacje dla biblioteki instrumentującej kod umieszczone są w częścisensora wydajności charakterystycznej dla danego kontenera. Pozwalają sen-sorowi zbierać dane w trakcie działania usług (np. rozpoczęto wykonywanieoperacji webservice, zakończono wykonywanie operacji webservice). Dane tetworzą komunikat w zestandaryzowanej postaci, który jest przekazywany doczęści sensora niezależnej od konkretnego kontenera.

4.1.2 Format komunikatu z danymi o wydajności

Format komunikatu z danymi o wydajności został przedstawiony na rysun-ku 4.2.

49

Rysunek 4.2: Postać komunikatu z danymi o wydajności w postaci diagramuklas UML

50

Główna klasa komunikatu (Event) może przenosić jeden z dwóch rodza-jów zdarzeń:

• ActivityUnit - jeśli zdarzenie dotyczy aktywności procesu BPEL (np.invoke, assign). Możliwe zdarzenia określone są wówczas przez wartośćEventType:

– START - rozpoczęto wykonywanie aktywności.

– COMPLETE - poprawnie wykonano aktywność.

– FAULT - wykonywanie aktywności zakończyło się wyjątkiem.

– TERMINATE - wykonywanie aktywności zostało przerwane (np.z powodu wyjątku w podwykonywanej aktywności).

• CatchUnit - jeśli zdarzenie dotyczy obsługi sytuacji wyjątkowej.

W miarę otrzymywania kolejnych danych od sensora wydajności w kon-soli budowany jest model zachodzącego procesu. Konsola nie ma dostępudo oryginalnych modeli procesów przechowywanych w kontenerach aplikacji,dlatego do zbudowania modelu procesu muszą jej wystarczyć dane otrzymy-wane z sensora wydajności. Powoduje to konieczność sformułowania dodatko-wych założeń dotyczących identyfikatorów otrzymywanych w wiadomościachz rysunku 4.2:

• identyfikator modelu procesu (unikalny globalnie)

• identyfikator procesu - wskazuje konkretne wywołanie procesu wedługdanego modelu (unikalny globalnie)

• identyfikator aktywności - wyrażenie XPATH[31] wskazujące na aktyw-ność z modelu procesu (unikalny w obrębie modelu)

• identyfikator wątku (unikalny w obrębie procesu)

• identyfikator wątku-rodzica (unikalny w obrębie procesu)

Komunikat w formacie zgodnym z rysunkiem 4.1 jest przekazywany doczęści sensora niezależnej od używanego kontenera. Odpowiada ona za prze-kazywanie komunikatów do konsoli prezentującej wyniki.

51

4.1.3 Przekazywanie wiadomości od sensora do konsoli

Komunikaty wysyłane są z sensora do serwera JMS, skąd mogą być pobieraneprzez konsolę prezentującą wyniki. Proces wysyłania komunikatów odbywasię niezależnie od ich generowania, utworzone przez sensor komunikaty sąumieszczane w kolejce, z której okresowo są pobierane i przekazywane do ser-wera JMS przez osobny wątek. Pozwala to zminimalizować wpływ sensora nadziałanie badanych usług - jedyny dodatkowy narzut związany z umieszcza-niem komunikatów w kolejce jest bardzo mały. Użycie serwera JMS zapewniaprosty i pewny sposób na dostarczenie danych do konsoli. W praktyce prze-kazywanie wiadomości do serwerów JMS wymaga dodania dodatkowej grupybibliotek (np. bibliotek Service Provider dla JNDI [17]). Biblioteki te musząbyć dodane do kontenera, ponieważ kontener został zinstrumentowany przezsensor wydajności wysyłający komunikaty JMS. Powoduje to możliwość po-wstawania konfliktów wersji z istniejącymi już bibliotekami wchodzącymi wskład kontenerów (wsparcie dla serwerów JMS jest powszechne w kontene-rach). Problem ten można rozwiązać stosując koncepcję podobną do tzw.sandbox[32]. Biblioteki serwera JMS nie są bezpośrednio dołączane do kon-tenera, tylko do izolowanego środowiska (sandbox) działającego w obrębiekontenera. W środowisku tym działa kod odpowiedzialny za wysyłanie ko-munikatów do serwera JMS. Poza izolowanym środowiskiem nie są widocznebiblioteki serwera JMS dlatego nie powodują one interakcji z kontenerem.Przedstawioną koncepcję sposobu przekazywania wiadomości od sensora dokonsoli ilustruje rysunek 4.3.

Rysunek 4.3: Przepływ komunikatów z danymi o wydajności

52

4.1.4 Wizualizacja zebranych danych w konsoli

Część prezentacyjna projektu została wykonana z użyciem komponentów zmodułu BPEL Designer pakietu NetBeans 6.0. Komponenty te nie są dostęp-ne jako oddzielna biblioteka, lecz stanowią integralną część tego środowiska.Chcąc je wykorzystać w innej aplikacji konieczne było zamknięcie ich w kon-tenerze symulującym oryginalne środowisko (sytuacja przedstawiona na rys.4.4).

Rysunek 4.4: Emulacja środowiska NetBeans 6.0 w bibliotece wizualizacyjnej

Aby emulować środowisko NetBeans w satysfakcjonującym stopniu ko-nieczne było podjęcie następujących kroków:

• implementacja własnej klasy realizującej rejestr obiektów środowiska(realizacja interfejsu org.openide.util.Lookup) i zapełnienie go wyma-ganymi wartościami

• stworzenie własnej klasy realizującej interfejs org.openide.loaders.DataObjectreprezentującej obiekt z danymi w NetBeans

• stworzenie szkieletu obiektu reprezentującego pusty dokument procesuBPEL

• zarządzanie skomplikowanym cyklem życia obiektu reprezentującegomodel procesu BPEL

Efektem tych działań jest kompletna biblioteka pozwalająca na przedsta-wianie procesu BPEL w efektownej formie graficznej. Komponent wizuali-zacyjny został zrealizowany jako obiekt rozszerzający znany ze środowiskaSwing JPanel1, co pozwala na jego proste użycie. Przykładowy kod realizu-jący wyświetlenie prostego procesu BPEL wygląda następująco:

1org. javax.swing.JPanel

53

1 // i n i c j a l i z a c j a głównego ob i e k t u widoku2 BPELVisualisationView view =3 BPELVisualisationView . createViewWithEmptyModel ( ”anyDesign” ,4 ”anyNS” ) ;5 // pobranie r e f e r e n c j i do modelu procesu BPEL6 BpelModel model = view . getBPELModel ( ) ;7 // pobranie r e f e r e n c j i do ob i e k t u budującego elementy procesu8 BPELElementsBuilder bu i l d e r = model . g e tBu i lde r ( ) ;9

10 // zbudowanie sekwenc j i11 Sequence sequence = bu i l d e r . c reateSequence ( ) ;12 // us taw ien i e sekwenc j i jako głównej aktywnośc i procesu13 model . ge tProce s s ( ) . s e tAc t i v i t y ( sequence ) ;14

15 // s twor zen i e aktywnośc i p r z yp i s an i a zmiennej16 Assign a s s i gn = bu i l d e r . c r ea t eAss i gn ( ) ;17 // dodanie aktywnośc i do sekwenc j i18 sequence . addAct iv i ty ( a s s i gn ) ;19

20 // poinformowanie o b i e k t u widoku o zmianach21 view . commitChanges ( ) ;

Przykładowy wynik działania, dla bardziej skomplikowanego przypadkujest przedstawiony na rysunku 4.5

54

Rysunek 4.5: Przykładowy wynik działania części wizualizacyjnej

Rozszerzenia Z uwagi na zastosowanie biblioteki, została ona rozszerzonao dwie dodatkowe funkcjonalności

• możliwość etykietowania aktywności procesu BPEL - celem dodawaniainformacji odnośnie dokonanych pomiarów

• możliwość zmiany koloru połączeń między aktywnościami - celem uka-zania częstości wykorzystania poszczególnych ścieżek w procesie (np.na rysunku 4.6 połączenie wychodzące od INVOKE nie było używane,więc ma inny kolor niż reszta połączeń)

Co istotne, zmiany te zostały dokonane bez ingerencji w oryginalny kodBPEL Designer.Biblioteka została przygotowana jako niezależna część i może z powodze-

niem być wykorzystywana w innych rozwiązaniach.

55

Rysunek 4.6: Fragment wizualizacji procesu BPEL wykorzystujący zmianękoloru danego połączenia w celu pokazania częstości jego użycia

4.2 Podsumowanie

Po rozwiązaniu wszystkich (m.in. przedstawionych w niniejszym rozdziale)problemów udało się stworzyć aplikację do badania wydajności usług zre-alizowanych w architekturze SOA zgodnie z założeniami przedstawionymi wrozdziale 3 i 4. Aplikacja otrzymała roboczą nazwę BPEL Profiler, którejautorzy używają w dalszej części pracy.Przykładowe reguły instrumentacji zostały opracowane dla kontenerów

usług obsługujących OpenESB. Praktyczne sprawdzenie zrealizowanej apli-kacji w środowisku testowym zostało przedstawione w kolejnym rozdziale.

56

Rozdział 5

Testy

W niniejszym rozdziale opisana została procedura testowania z użyciem na-rzędzia BPEL Profiler. Przedstawiono sposób konfiguracji sprzętu i oprogra-mowania środowiska testowego, oraz opisano aplikacje będące materiałem dotestów. Rozdział zawiera również wyniki działania stworzonego narzędzia.

5.1 Testowane oprogramowanie

Testy zostały przeprowadzone na przykładowych aplikacjach BPEL dostar-czanych przez firmę Sun TM- BPEL Blueprints. Są to proste, wzorcowe roz-wiązania problemów integracyjnych z użyciem języka BPEL[18]. Poniżej przed-stawiono krótki opis każdego z nich.

Aplikacja realizująca synchroniczne wywołanie usługi Jest to pro-sty proces realizujący integrację sklepu z magazynem. Graficzna prezentacjaprocesu BPEL jest przedstawiona na rysunku 5.1.Na podstawie przychodzących do interfejsu sklepu (POServicePlink) żą-

dań następuje synchroniczne odpytanie usługi magazynu (requestInventory-Plink) o dostępność produktu. W zależności od odpowiedzi magazynu, usługasklepu potwierdza lub odmawia złożenia zamówienia.

Aplikacja realizująca asynchroniczne wywołanie usługi Proces re-alizujący taką samą funkcjonalność jak poprzedni. Różnią się one jedyniesposobem komunikacji z magazynem - w tym przypadku, wywołanie usługimagazynu jest jednokierunkowe. Następnie proces oczekuje na jedno ze zda-rzeń z bloku EventBasedDecision - nadejście odpowiedzi lub upłynięcie limituczasowego. Odpowiedź wysyłana do klienta jest zależna od tej odpowiedzi.Prezentacja graficzna procesu znajduje się na rysunku 5.2.

57

Rysunek 5.1: Aplikacja realizująca synchroniczne wywołanie usługi

58

Rysunek 5.2: Aplikacja realizująca asynchroniczne wywołanie usługi

59

Aplikacja realizująca synchroniczne wywołanie usługi z obsługą wy-jątków Rozszerzenie pierwszego procesu o mechanizm obsługi wyjątków -proces początkowo sprawdza poprawność przychodzącego zamówienia, w wy-padku błędu rzuca wyjątek. Drugim obsługiwanym wyjątkiem jest sygnali-zowany przez magazyn brak zamawianego produktu. Graficzna prezentacjaprocesu znajduje się na rysunku 5.3.

Aplikacja korelująca kilka wywołań Proces będący rozszerzeniem pierw-szego wariantu, o możliwość potwierdzenia lub anulowania zamówienia. Pozłożeniu zamówienia, aplikacja czeka na dalsze instrukcje, lub upłynięcie limi-tu czasowego, po czym podejmuje stosowne do zdarzenia akcje. Korelacja jestrealizowana poprzez zawarcie w przesyłanych wiadomościach parametrów po-zwalających na zidentyfikowanie instancji procesu dla którego przeznaczonajest dana wiadomość. Graficzna prezentacja procesu znajduje się na rysunku5.4.

Aplikacja realizująca równoległe asynchroniczne wywołanie kilkuusług Proces realizujący wycinek funkcjonalności biura turystycznego, po-zwalającego na jednoczesną rezerwację biletu lotniczego, hotelu i samochodu.Realizuje on równoległe wykonanie trzech asynchronicznych wywołań usługrezerwacji, których wynik jest zwracany do klienta. Reprezentacja graficznaprocesu znajduje się na rysunku 5.5.

60

Rysunek 5.3: Aplikacja realizująca obsługę wyjątków rzucanych z procesu orazwykorzystywanych usług

61

Rysunek 5.4: Aplikacja korelująca kilka wywołań dotyczących tej samej in-stancji procesu

62

Rysunek 5.5: Aplikacja realizująca równoległe asynchroniczne wywołanieusług

63

5.2 Opis procedury testowania

Procedurę testowania realizowano według następującego schematu:

• Instalacja testowanej aplikacji w środowisku OpenESB

• Wyzwolenie procesu testowanej usługi

• Obserwacja wyników na konsoli wizualizacyjnej

Wyzwalanie procesu powtarzano dla różnych danych celem ukazania moż-liwości budowania procesu w locie oraz agregowania wyników końcowych.

Analiza intruzywności pomiaru Zaburzenie zbieranych wyników możezostać przeanalizowane w dwóch aspektach:

• Modyfikacja infrastruktury spowodowana wysyłaniem dodatkowych ko-munikatów z danymi o wydajności. Serwer JMS oraz konsola wizuali-zacyjna znajdują się zwykle na osobnej maszynie, celem zniwelowaniaich wpływu na badane usługi. Stosowane łącza pomiędzy maszynamimają zwykle bardzo dużą przepustowość (np. 1 Gbps w izolowanymśrodowisku testowym) co przy małym rozmiarze komunikatów o wy-dajności powoduje, że wpływ dodatkowych komunikatów z danymi owydajności na badane usługi jest pomijalny.

• Zbieranie dodatkowych danych o wydajności zaburza naturę badanychusług. Wybrany sposób instrumentacji i zbierania danych nie powo-duje dużych narzutów czasowych. Proces wysyłania danych do kolejkiJMS odbywa się asynchronicznie, co również nie zaburza wyników wznacznym stopniu.

Zastosowany sposób zbierania danych nie ma znaczącego wpływu na bada-ne usługi. Dokładne badania są trudne do przeprowadzenia z uwagi na brakporównywalnego narzędzia do badania wydajności usług opartych o paradyg-mat SOA.

Weryfikacja wyników Weryfikacja zebranych wyników może zostać do-konana w dwóch aspektach:

• Zgodność pomiędzy oryginalnym modelem biznesowym a wygenerowa-nym modelem w konsoli wizualizacyjnej. Zgodność stwierdzana jest napodstawie wizualnego porównaniu obu modeli.

64

• Poprawność zebranych danych (statystyk czasowych). Weryfikacja ze-branych danych liczbowych jest trudna do przeprowadzenia, z powodubraku porównywalnych narzędzi do badania wydajności usług opartycho paradygmat SOA. Jedynym wyznacznikiem poprawności zebranychdanych może być ich zgodność z wartościami szacunkowymi dla danegomodelu (np. przy zastosowaniu konstrukcji WAIT z parametrem 2 se-kundy, czas wykonania takiej aktywności powinien wynosić co najmniej2 sekundy).

Weryfikacja otrzymanych wyników jest bardzo trudna do przeprowadzenia.Można jedynie wizualnie ocenić otrzymane wartości.

5.3 Konfiguracja infrastruktury

Konfigurację infrastruktury przedstawia rysunek 5.6. Na Serwerze 1 zain-stalowano zinstrumentowane środowisko wykonawcze, i umieszczano na nimkolejne testowana aplikacje. Serwer JMS i konsola wizualizacyjna (na Serwrze2) zostały odizolowane od środowiska wykonawczego, celem zminimalizowa-nia ich wpływu na wyniki testów.Podczas konfiguracji zwrócono szczególną uwagę na oddzielenie medium

komunikacyjnego od środowiska zewnętrznego. Zostało ona całkowicie od-izolowane, celem zniwelowania opóźnień i zakłoceń pracy ze strony innychkomputerów.

Konfiguracja oprogramowania Została zainstalowana standardowa dys-trybucja OpenESB w wersji v2-ur2-b04-patch-20080603, uruchamiana na ma-szynie wirtualnej Java 1.6.0 03. Konfiguracja sensora wydajności oraz kon-soli wizualizacyjnej została wykonana zgodnie z instrukcjami zawartymi wdodatku A.

65

Rysunek 5.6: Diagram konfiguracji infrastruktury testowej

5.4 Dynamiczna prezentacja wyników

Konsola wizualizacyjna nie posiada informacji o oryginalnym modelu bada-nego procesu biznesowego. Model w konsoli jest budowany w sposób dyna-miczny, w miarę otrzymywania nowych informacji od sensora wydajności.Przykład działania mechanizmu dynamicznego budowania modelu procesuznajduje się na rysunku 5.7. Rysunek ilustruje badanie prostego procesubiznesowego, który składa się z wywołania operacji webservice (INVOKE)i ewentualnie obsłużenia rzuconego wyjątku. Na kolejnych fragmentach ry-sunku pokazono coraz bardziej uszczegółowiony model procesu, który corazlepiej przybliża oryginalny model.

66

Rysunek 5.7: Dynamiczne budowanie modelu w trakcie zbierania danych

67

5.5 Wyniki testów

Każda z aplikacji zaprezentowanych w rozdziale 5.1 została umieszczona wkontenerze. Procesy biznesowe oferowane przez aplikacje zostały kilkukrot-nie wykonane (w miarę możliwości starano się pokazać różne ścieżki w proce-sach). Wizualna weryfikacja otrzymanych rysunków pozwala stwierdzić, że sąone zgodne z oryginalnymi modelami procesów biznesowych przedstawionymiw rozdziale 5.1. Otrzymane wartości liczbowe są wartościami realistycznymi(brak konkurencyjnych narzędzi uniemożliwia przeprowadzenie testów po-równawczych). Dodatkowo w celu ułatwienia interpretacji otrzymanych wy-ników, na rysunku 5.8 zamieszczono układ i oznaczenie elementów głównegookna konsoli wizualizacyjnej.

Rysunek 5.8: Układ głównego okna aplikacji

Zebrane dane zostały zaprezentowane na kolejnych stronach. Poniżej znaj-duje się krótki komentarz do każdego badanego procesu biznesowego.

Aplikacja realizująca synchroniczne wywołanie usługi Na rysunku5.9 przedstawiono zagregowany widok modelu procesu po siedmiokrotnymwykonaniu procesu biznesowego. Zagregowany widok modelu pokazuje in-formację uzyskaną ze wszystkich wykonań procesu, dlatego w instrukcji IFpokazane zostały obie możliwości wykonania (lewa gałąź wykonywana przyspełnieniu warunku z instrukcji IF, prawa gałąź w przeciwnym razie).

Aplikacja realizująca asynchroniczne wywołanie usługi Rysunek 5.10przedstawia fragment modelu demonstrujący użycie instrukcji IF. Analizu-

68

jąc ścieżkę wykonania można zauważyć, że została wykonana prawa częśćinstrukcji warunkowej odpowiadająca za klauzulę ELSE.

Aplikacja realizująca synchroniczne wywołanie usługi z obsługą wy-jątków Rysunek 5.11 przedstawia proces realizacji błędnego zamówienia.Instrukcja IF (por. rysunek) odpowiada za zweryfikowanie typu zamówie-nia. Ponieważ użyty typ zamówienia był niepoprawny następuje przejściedo instrukcji THROW, która generuje wyjątek typu CannotCompleteOrder(prawy dolny róg rysunku). Warto zauważyć, że ścieżka wychodząca z in-strukcji THROW nie ma koloru oznaczającego aktywność (zielonego), ponie-waż sterowanie wskutek wyjątku zostaje przeniesione bezpośrednio do blokuobsługi wyjątku CATCH. Obsługa wyjątku poprzez instrukcję REPLY usta-wia odpowiedni rezultat procesu biznesowego informujący o nieprawidłowymzamówieniu.Rysunek 5.12 przedstawia proces realizacji zamówienia niedostępnego w

magazynie. Typ zamówienia został pozytywnie zweryfikowany z użyciem in-strukcji warunkowej IF. Sterowanie zostało następnie przekazane do instruk-cji INVOKE, która wykonuje operacje webservice odpowiadającą za spraw-dzenie stanu magazynowego pod kątem złożonego zamówienia. Ponieważ wmagazynie brakuje zamawianych towarów, wywołanie operacji kończy się wy-jątkiem InventoryFaultType (prawy dolny róg rysunku).Przykładowe statystyki wykonania operacji INVOKE pokazano na rysun-

ku 5.13. W drugim wierszu można zauważyć niepoprawne zakończenie ope-racji INVOKE wskutek wystąpienia wyjątku InventoryFaultType (wyjątekten oznaczał brak zamawianych towarów w magazynie).

Aplikacja korelująca kilka wywołań Rysunek 5.14 przedstawia frag-ment modelu demonstrujący użycie instrukcji PICK. Analizując ścieżkę wy-konania można zauważyć, że proces po napotkaniu instrukcji PICK zatrzy-mał się w oczekiwaniu na dowolny z dwóch typów komunikatów (obszaryOnMessage). Funkcjonalność ta jest wykorzystywana do zrealizowania moż-liwości anulowania lub potwierdzania złożonego zamówienia. Po otrzymaniukomunikatu z potwierdzeniem zamówienia nastąpiło dalsze wykonanie pro-cesu.

Aplikacja realizująca równoległe asynchroniczne wywołanie kilkuusług Rysunek 5.15 przedstawia wykonywanie równoległej rezerwacji bile-tu lotniczego, hotelu oraz samochodu. Fragmenty odpowiadające za obsługęrezerwacji hotelu oraz samochodu zostały zwinięte, wskutek czego zajmująmniej miejsca oraz uwydatniają pozostałą część modelu.

69

Rysunek 5.9: Aplikacja realizująca synchroniczne wywołanie usług (por. ry-sunek 5.1).

70

Rysunek 5.10: Aplikacja realizująca asynchroniczne wywołanie usługi (por.rysunek 5.2).

71

Rysunek 5.11: Aplikacja realizująca synchroniczne wywołanie usługi z obsługąwyjątków (por. rysunek 5.3).

72

Rysunek 5.12: Aplikacja realizująca synchroniczne wywołanie usługi z obsługąwyjątków (por. rysunek 5.3).

73

Rysunek 5.13: Szczegóły działania aktywności INVOKE z rysunku 5.10.

74

Rysunek 5.14: Aplikacja korelująca kilka wywołań (por. rysunek 5.4).

75

Rysunek 5.15: Aplikacja realizująca równoległe asynchroniczne wywołanie kil-ku usług (por. rysunek 5.5).

76

Wykazano przydatność stworzonego narzędzia w pomiarach wydajnościaplikacji o architekturze SOA. Oprogramowanie działało poprawnie - prezen-towane przejścia w procesach biznesowych pokrywały się z rzeczywistością.Wyniki testów wydajnościowych były zgodne z oczekiwaniami, co oznacza,że narzędzie może być z powodzeniem użyte w analizie wydajności aplikacji.

77

Rozdział 6

Wnioski z pracy i możliwościdalszego rozwoju systemu

SOA to wciąż innowacyjny paradygmat tworzenia oprogramowania. Już terazmożna jednak zaobserwować tendencję do zwiększania się jego udziału wśródaktualnie dominujących technologii IT. Coraz więcej systemów opartych jesto paradygmat SOA, co przynosi wymierne korzyści w postaci np. luźnychpowiązań pomiędzy usługami, ich ułatwionej integracji oraz konieczności sto-sowania kontraktów. Badanie wydajności usług realizujących procesy bizne-sowe z użyciem języka BPEL jest bardzo przydatne, ponieważ pozwala m.in.znaleźć słabe punkty tworzonej aplikacji (ang. bottlenecks), analizować za-chowanie się konkretnych wywołań procesów biznesowych oraz wyszukiwaćbłędy i niepoprawnie działające procesy. Autorom niniejszej pracy w trak-cie jej tworzenia nie udało się znaleźć aplikacji wspierających takie badaniaoraz spełniających jednocześnie zbiór wymagań zawartych w rozdziale 3.1.Autorzy zaproponowali modularną architekturę aplikacji pozwalającą anali-zować procesy biznesowe zachodzące w dowolnym kontenerze aplikacji orazobrazować je w czytelny sposób z użyciem centralnej konsoli wizualizacyjnej.W ramach pracy autorzy zapoznali się z możliwościami technologii wspo-

magających budowanie aplikacji o architekturze SOA. Pogłębiona zostaławiedza na temat języka BPEL i rozwiązań realizujących koncepcję ESB. Wy-niki analizy możliwości oprogramowania wspierającego tworzenie rozwiązańo architekturze SOA, zostały wykorzystane do wybrania przykładowego, te-stowanego środowiska.Postawione zostały wymagania jakie powinien spełniać system badania

wydajności, ze szczególnym naciskiem na sposób umieszczenia sensora w ob-rębie środowiska wykonawczego. Za zbioru rozważanych koncepcji, do imple-mentacji wybrano najlepiej pasującą w kontekście postawionych wymagań.Stworzone zostało zarówno narzędzie do automatycznej instrumentacji

78

środowiska wykonawczego, jak i obserwacji otrzymywanych parametrów wy-dajnościowych aplikacji. Zostało ono wzbogacone o możliwość przedstawianiawyników obserwacji w postaci samobudującego się procesu biznesowego.W celu prezentacji osiągnięć przygotowane zostało środowisko testowe.

Do testowania wybrano kilka przykładowych aplikacji, realizujących typoweprzypadki użycia w aplikacjach opartych o język BPEL. Przypadki te byłypodstawą do przeprowadzenia procedur testowych, oraz źródłem zamieszczo-nych w pracy wyników.

6.1 Możliwości zastosowania stworzonego opro-gramowania

Stworzone oprogramowanie w pełni spełnia postawione w pracy wymagania.Narzędzie pozwala na wykonanie pomiarów działającej aplikacji, bez znacznejingerencji w środowisko wykonawcze. Dostarczane statystyki są zbierane wlocie z dowolnej liczby kontenerów i wysyłane w ogólnie znanym formaciedo serwera JMS, dzięki czemu możliwa jest ich jednoczesna analiza w kilkulokalizacjach.Narzędzie wizualizacyjne pozwala na prezentację wyników analizy w trak-

cie działania aplikacji, pozwalając jednocześnie na szybkie odnalezienie “wą-skich gardeł” systemów. Zbierane statystyki można poddawać dalszej obrób-ce, celem dalszej agregacji, tworzeniu wykresów itp. Z uwagi na niski narzutczasowy wprowadzany instrumentacją środowiska wykonawczego, narzędziemoże być z powodzeniem stosowane w działających aplikacjach m.in. do śle-dzenia częstości przejść poszczególnych ścieżek w procesie biznesowym.Dzięki intuicyjnemu interfejsowi użytkownika, narzędzie może być uży-

wane nawet przez programistów o niewielkiej wiedzy w dziedzinie problemu.Nieskomplikowana forma prezentacji graficznej wyników pomiarów, pozwalana przedstawianie ich osobom nie posiadającym szczegółowej wiedzy tech-nicznej.

6.2 Dalszy rozwój systemu

Zrealizowana aplikacja ma służyć jako przykładowe rozwiązanie problemubadania wydajności usług zgodnych z paradygmatem SOA. Aplikacja nie po-winna być więc traktowana jako kompletny program, lecz jako punkt wyjściado dalszych prac i udoskonaleń.

79

Zwiększenie ilości obsługiwanych implementacji Aplikacja zostaławyposażona w reguły instrumentacji kontenerów OpenESB. Ponieważ samaaplikacja ma jedynie demonstrować sposób badania wydajności, więc ogra-niczenie wbudowanej obsługi kontenerów tylko do OpenESB nie ma wpływuna testy opisane w rozdziale 5. Modułowa budowa sensora wydajności umoż-liwia proste dopisanie reguł instrumentacji dla dowolnego kontenera ESB.Reguły te są podstawą do dokonania instrumentacji przez bibliotekę wstrzy-kującą kod (por. rozdział 4.1.1). Biblioteka ta zapewnia podstawowy zestawadnotacji dla pisania reguł (np. wykonaj podany kod przed startem okre-ślonej metody). Zestaw ten może być poszerzony w przypadku braku odpo-wiedniej adnotacji. W szczególnych przypadkach istnieje możliwość wymianycałego silnika instrumentującego kod, bez zmiany pozostałej części systemu(konsoli, sensorów, formatu wiadomości JMS itp). Kolejnym etapem pracynad aplikacją powinno być napisanie reguł instrumentacji dla najpopular-niejszych kontenerów obecnych na rynku. W przypadku używania platformyOSGi[2] (system modułów dla języka Java) bezpośrednie wsparcie dla językaBPEL będzie umożliwiała nowa wersja serwera GlassFish 3.0[67]. Ponieważreguły instrumentacji OpenESB są już utworzone, mamy możliwość badaniai analizowania wydajności usług zrealizowanych z użyciem języka BPEL wdowolnym środowisku OSGi.

Rozszerzenie możliwości wizualizacyjnych konsoli Obecnie konsolawizualizacyjna jest w stanie przedstawić badany proces w postaci diagramuBPEL. Posiada również możliwość wyświetlania informacji statystycznych(np. statystyki czasowe czyli minimalny, średni i maksymalny czas trwaniaaktywności) o dowolnym elemencie procesu. Otrzymywane od sensorów danepozwalają jednak na prezentację większej ilości informacji. Pozwalają onenp. na wykreślanie diagramów Gantta[43] zachodzącego procesu. Obrazujeon podział procesu na poszczególne zadania oraz rozmieszczenie ich w czasie.Dodatkowo obecną wersję aplikacji można rozszerzyć o możliwość rysowaniawykresów (np. koszt wywołania operacji webservice w czasie).

Integracja prezentacji wyników z modułem NetBeans BPEL De-signer Środowisko programowania NetBeans udostępnia wbudowany mo-duł BPEL Designer umożliwiający graficzną edycję i modelowanie procesówBPEL. Fragmenty tego modułu zostały użyte w stworzonej przez autorówaplikacji do prezentowania procesu BPEL w konsoli wizualizacyjnej. Docelo-wo należałoby również zrealizować integrację w drugą stronę, czyli wbudo-wać w edytor Netbeans BPEL Designer możliwości konsoli wizualizacyjnejprocesów BPEL. Posiadanie danych o wydajności budowanego procesu bez-

80

pośrednio w edytorze, usprawniłoby modelowanie procesów, oraz umożliwiłoefektywniejsze i szybsze poprawianie błędów w ich modelach.

Niniejsza praca magisterska wpisuje się w aktualne światowe trendy two-rzenia aplikacji opartych o usługi i stara się wypełnić lukę w badaniu ichwydajności. Stworzone oprogramowanie stanowi solidne narzędzie niezbędnedo produkcyjnego zastosowania procedur biznesowych implementowanych woparciu o język BPEL. Mnogość postawionych w pracy problemów oraz moż-liwości rozwoju stworzonego oprogramowania, świadczy o szerokim spektrummożliwych kontynuacji badań w tej dziedzinie.

81

Rozdział 7

Akronimy

• AOP - Aspect Oriented Programming

• BC - Binding Component (JBI)

• BPEL4WS - Bussiness Process Execution Language for WebServices

• BPEL - Business Process Execution Language

• BPEL - Business Process Execution Language

• BPM - Business Process Management

• CORBA - Common Request Object Broker Architecture

• DCOM - Distributed Component Object Model

• EAI - Enterprise Application Integration

• EII - Enterprise Information Integration

• ESB - Enterprise Service Bus

• ETL - Extract, Transform and Load

• IIOP - Internet Inter Orb Protocol

• JBI - Java Business Integration

• JCP - Java Community Process

• JMS - Java Message Service

• JSR - Java Specification Request

82

• JVM - Java Virtual Machine

• MOM - Message Oriented Middleware

• NMR - Normalized Message Router

• p2p - peer to peer

• QoS - Quality of Service

• REST - Representational State Transfer

• RMI - Remote Method Invocation

• RPC - Remote Procedure Call

• SE - Service Engine (JBI)

• SLA - Service Level Agreement

• SOAP - Service Oriented Architecture Protocol

• SOA - Service Oriented Architecture

• SU - Service Unit (JBI)

• UDDI - Universal Description, Discovery and Integration

• WS-BPEL - WebServices - Bussiness Process Execution Language

• WSDL - Web Service Definition Language

• WS - WebService

• XML - eXtensible Markup Language

• XMPP - Extensible Messaging and Presence Protocol

• XSLT - eXtensible Stylesheet Language Tranformations

83

Rozdział 8

Bibliografia

[1] Binildas C. A. Service Oriented Java Business Integration. PacktPublishing, 2008.

[2] OSGi Alliance. Strona domowa OSGi.http://www.osgi.org/Main/HomePage.

[3] BEA. Strona domowa BEA Aqualogic ESB.http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products /aqualogic/service bus/.

[4] Dave Chapell. Enterprise Service Bus. O’Reilly, 2004.

[5] Thomas Erl. 5 największych zagrożeń SOA, 2006.http://searchsoa.techtarget.com/tip/0,289483,sid26 gci1195738,00.html.

[6] Organization for the Advancement of StructuredInformation Standards. BPEL OASIS Specification.http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf.

[7] Organization for the Advancement of StructuredInformation Standards. Strona domowa organizacji OASIS.http://www.oasis-open.org/home/index.php.

[8] Object Management Group. CORBA Notification Service.http://www.omg.org/technology/documents/corbaservices spec catalog.htm.

[9] Open Group. Service Oriented Architecture definition.http://opengroup.org/projects/soa/doc.tpl?gdid=10632.

84

[10] IBM. Strona domowa IBM Websphere.http://www.ibm.com/software/integration/wsesb/.

[11] Matjaz B. Juric. BPEL and Java.http://www.theserverside.com/tt/articles/content/BPELJava/article.html.

[12] Matjaz B. Juric. Business Process Execution Language for WebServices, Second Edition. Packt Publishing, 2006.

[13] Microsoft. MSMQ. http://www.microsoft.com/windowsserver2003/technologies/msmq/default.mspx.

[14] Microsoft. UDDI Business Registry Shutdown FAQ.http://uddi.microsoft.com/about/FAQshutdown.htm.

[15] Sun Microsystems. JMS API. http://java.sun.com/jms.

[16] SUN Microsystems. Lokalizacja klas systemowych maszyny wirtualnejJava. http://java.sun.com/j2se/1.4.2/docs/tooldocs/findingclasses.html#bootclass.

[17] Sun MicrosystemsTM. Service Provider Interface w JNDI.http://java.sun.com/products/jndi/serviceproviders.html.

[18] Sun MicrosystemsTM. Sun’s BPEL Blueprints.https://blueprints.dev.java.net/bpcatalog/ee5/soa/.

[19] W3C Organization. W3C. http://www.w3.org.

[20] W3C Organization. W3C SOAP.http://www.w3.org/TR/2003/REC-soap12-part1-20030624.

[21] W3C Organization. W3C SOAP RPC.http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapforrpc.

[22] W3C Organization. W3C Webservice.http://www.w3.org/TR/ws-arch/#whatis.

[23] W3C Organization. WSDL 2.0 Specification.http://www.w3.org/TR/wsdl20/.

[24] Sang Shin. SUN TECH DAYS, A Developer Conference 2001-2002.http://www.sun.com/developers/EvangCentral.

85

[25] IBM Polska sp. z o.o. Projektowanie Modeli Usług dla rozwiązań typuSOA.http://www-05.ibm.com/pl/gbs/pdf/IBM GBS SOMA offering.pdf.

[26] Ralf Suderbucher. “My thought was, this change has to be comparedto the switch from Newtonian physics to relativistic physics.” -http://weblogs.asp.net/ralfw/archive/2005/07/03/417507.aspx.

[27] Darryl K. Taft. Enterprise SOA Adoption to Double in Next TwoYears. http://www.eweek.com/c/a/Application-Development/Enterprise-SOA-Adoption- to-Double-in-Next-Two-Years/.

[28] Ron Ten-Hove. JBI Components (Theory). https://open-esb.dev.java.net/public/pdf/JBI-Components-Theory.pdf.

[29] Frank Yellin Tim Lindholm. Specyfikacja maszyny wirtualnej Java.http://java.sun.com/docs/books/jvms/second edition/html/VMSpecTOC.doc.html.

[30] Gamma Helm Johnson Vlissides. Design Patterns: Elements ofReusable Object-Oriented Software. Pearson, 1994.

[31] W3C. Specyfikacja XPATH. http://www.w3.org/TR/xpath.

[32] Wikipedia. Koncepcja sandbox.http://en.wikipedia.org/wiki/Sandbox (computer security).

[33] Wikipedia. Programowanie aspektowe.http://en.wikipedia.org/wiki/Aspect-oriented programming.

[34] Yuli Vasiliev. SOA and WS-BPEL. Packt Publishing, 2007.

[35] Praca zbiorowa. ACID w Polskiej Wikipedii.http://pl.wikipedia.org/ACID.

[36] Praca zbiorowa. ActiveBPEL Engine. http://www.activebpel.com.

[37] Praca zbiorowa. Apache ODE. http://ode.apache.org.

[38] Praca zbiorowa. Biblioteka Apache Commons.http://commons.apache.org/.

[39] Praca zbiorowa. BPEL4WS 1.1 Specification. http://www-128.ibm.com/developerworks/library/specification/ws-bpel/.

86

[40] Praca zbiorowa. BPELSE Event Dispatching and Listener Framework.http://wiki.open-esb.java.net/Wiki.jsp?page=BPELSEEventListener.

[41] Praca zbiorowa. Business Process Execution Language.http://en.wikipedia.org/BPEL.

[42] Praca zbiorowa. Developing JBI Components.https://open-esb.dev.java.net/public/jbi-comp-examples/Developing JBI Components.html.

[43] Praca zbiorowa. Diagram Gantt’a w Polskiej Wikipedii.http://pl.wikipedia.org/wiki/Diagram Gantta.

[44] Praca zbiorowa. IBM Websphere Studio Application DeveloperIntegration Edition.http://www.ibm.com/software/integration/wsadie.

[45] Praca zbiorowa. ICEStorm.http://www.zeroc.com/doc/Ice-3.2b/manual/IceStorm.html.

[46] Praca zbiorowa. JSR-208 - java business integration.http://www.jcp.org/en/jsr/detail?id=208.

[47] Praca zbiorowa. Microsoft BizTalk.http://www.microsoft.com/biztalk.

[48] Praca zbiorowa. Netbeans’ BPEL Designer. http://soa.netbeans.org.

[49] Praca zbiorowa. Oracle BPEL Designer for Eclipse.http://www.oracle.com/technology/products/as/bpel/index.html.

[50] Praca zbiorowa. Oracle BPEL Process Manager.http://www.oracle.com/technology/products/ias/bpel/index.html.

[51] Praca zbiorowa. Service Oriented Architectures part 1.http://www.gartner.com/DisplayDocument?doc cd=29201.

[52] Praca zbiorowa. SOA Wikipedia.http://en.wikipedia.org/wiki/Service-oriented architecture#Service contract.

[53] Praca zbiorowa. Strona domowa AspectJ.http://www.eclipse.org/aspectj/.

[54] Praca zbiorowa. Strona domowa AspectWerkz.http://aspectwerkz.codehaus.org/.

87

[55] Praca zbiorowa. Strona domowa Code Generation Library.http://cglib.sourceforge.net.

[56] Praca zbiorowa. Strona domowa JBoss ESB.http://www.jboss.org/jbossesb/.

[57] Praca zbiorowa. Strona domowa MULE ESB.http://mule.mulesource.org/.

[58] Praca zbiorowa. Strona domowa ObjectWeb PEtALS.http://petals.objectweb.org/.

[59] Praca zbiorowa. Strona domowa OpenESB.https://open-esb.dev.java.net/.

[60] Praca zbiorowa. Strona domowa ServiceMix.http://servicemix.apache.org/.

[61] Praca zbiorowa. Strona domowa SONIC ESB.http://www.sonicsoftware.com/products/sonic esb.

[62] Praca zbiorowa. Tryby instrumentacji w AspectWerkz.http://aspectwerkz.codehaus.org/weaving.html.

[63] Praca zbiorowa. UDDI. http://uddi.xml.org.

[64] Praca zbiorowa. WS-BPEL 2.0 Specification.http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf.

[65] Praca zbiorowa. WS-Events.http://xml.coverpages.org/WS-Events20030721.pdf.

[66] Praca zbiorowa. WS-Notifications.http://www.informit.com/guides/content.aspx?g=xml&seqNum=285.

[67] Praca zbiorowa. Założenia projektu GlassFish w wersji 3.0.http://wiki.glassfish.java.net/Wiki.jsp?page=PlanForGlassFishV3.

[68] Praca zbiorowa OMG. BPM Specification.http://www.bpmn.org/Documents/OMG-02-01.pdf.

88

Rozdział 9

Spis rysunków

1.1 Ewolucja architektur oprogramowania [25] . . . . . . . . . . . 41.2 Zmiana w podejściu do projektowaniu oprogramowania . . . . 5

2.1 Schemat integracji 4 podsystemów (każdy-z-każdym) . . . . . 92.2 Przykładowy schemat funkcjonowania aplikacji opartej o SOA 102.3 Przykład funkcjonowania aplikacji opartej o usługi webservice 132.4 Postać wiadomości SOAP z załącznikami [24] . . . . . . . . . 152.5 Schemat wykorzystania UDDI [24] . . . . . . . . . . . . . . . . 162.6 Zasada działania ESB [1] . . . . . . . . . . . . . . . . . . . . . 172.7 Zasada działania MOM . . . . . . . . . . . . . . . . . . . . . . 182.8 Zasada działania EAI [4] . . . . . . . . . . . . . . . . . . . . . 192.9 ESB jako pochodna EAI i MOM . . . . . . . . . . . . . . . . . 202.10 Nomenklatura JBI[28] . . . . . . . . . . . . . . . . . . . . . . 242.11 Orchiestracja . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.12 Choreografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.13 Elementy konstrukcyjne języka BPEL . . . . . . . . . . . . . . 302.14 Pakiet Netbeans - wizualny edytor procesu BPEL . . . . . . . 31

3.1 Architektura używana do badania wydajności aplikacji . . . . 343.2 Schemat wywołania usługi webservice w OpenESB . . . . . . 373.3 Koncepcja rozwiązania w oparciu o interfejs monitorowaniasilnika BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Koncepcja rozwiązania z użyciem HULP . . . . . . . . . . . . 403.5 Koncepcja rozwiązania z użyciem BPEL SE Events Listener . 423.6 Koncepcja instrumentacji kodu BPEL aplikacji . . . . . . . . . 433.7 Koncepcja instrumentacji środowiska wykonania . . . . . . . . 44

4.1 Przykład użycia biblioteki instrumentującej kod . . . . . . . . 49

89

4.2 Postać komunikatu z danymi o wydajności w postaci diagramuklas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Przepływ komunikatów z danymi o wydajności . . . . . . . . . 524.4 Emulacja środowiska NetBeans 6.0 w bibliotece wizualizacyjnej 534.5 Przykładowy wynik działania części wizualizacyjnej . . . . . . 554.6 Fragment wizualizacji procesu BPEL wykorzystujący zmianękoloru danego połączenia w celu pokazania częstości jego użycia 56

5.1 Aplikacja realizująca synchroniczne wywołanie usługi . . . . . 585.2 Aplikacja realizująca asynchroniczne wywołanie usługi . . . . . 595.3 Aplikacja realizująca obsługę wyjątków rzucanych z procesuoraz wykorzystywanych usług . . . . . . . . . . . . . . . . . . 61

5.4 Aplikacja korelująca kilka wywołań dotyczących tej samej in-stancji procesu . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.5 Aplikacja realizująca równoległe asynchroniczne wywołanie usług 635.6 Diagram konfiguracji infrastruktury testowej . . . . . . . . . . 665.7 Dynamiczne budowanie modelu w trakcie zbierania danych . . 675.8 Układ głównego okna aplikacji . . . . . . . . . . . . . . . . . . 685.9 Aplikacja realizująca synchroniczne wywołanie usług (por. ry-sunek 5.1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.10 Aplikacja realizująca asynchroniczne wywołanie usługi (por.rysunek 5.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.11 Aplikacja realizująca synchroniczne wywołanie usługi z obsłu-gą wyjątków (por. rysunek 5.3). . . . . . . . . . . . . . . . . . 72

5.12 Aplikacja realizująca synchroniczne wywołanie usługi z obsłu-gą wyjątków (por. rysunek 5.3). . . . . . . . . . . . . . . . . . 73

5.13 Szczegóły działania aktywności INVOKE z rysunku 5.10. . . . 745.14 Aplikacja korelująca kilka wywołań (por. rysunek 5.4). . . . . 755.15 Aplikacja realizująca równoległe asynchroniczne wywołanie kil-ku usług (por. rysunek 5.5). . . . . . . . . . . . . . . . . . . . 76

A.1 Konfiguracja konsoli . . . . . . . . . . . . . . . . . . . . . . . 93A.2 Szczegółowe informacje o wywołaniach . . . . . . . . . . . . . 94A.3 Układ głównego okna aplikacji . . . . . . . . . . . . . . . . . . 95

90

Dodatek A

Podręcznik użytkownika

W niniejszym dodatku przedstawiony został krótki opis konfiguracji oraz ob-sługi aplikacji. Opis został przygotowany do użycia w systemach z rodzinyLinux, jednak w analogiczny sposób przebiega konfiguracja i obsługa apli-kacji w systemie Windows. Aplikacja została napisana i przetestowana wśrodowisku maszyny wirtualnej Java 1.6.0.Pierwszym krokiem który należy wykonać przed użytkowaniem niniejszej

aplikacji jest odpowiednie zinstrumentowanie bibliotek kontenera oraz konfi-guracja aplikacji.

A.1 Instrumentacja bibliotek kontenera orazkonfiguracja aplikacji

W ogólnym przypadku komputery użyte w badaniu wydajności usług mająnastępujące nazwy symboliczne i przeznaczenie:

• host1 - serwer JMS

• host2 - konsola wizualizacyjna z aplikacją dostępną w katalogu /app

• host3..hostN - kontenery usług z zainstalowanym GlassFish w kata-logu /opt/glassfish

Możliwy jest też wariant prostszy, w którym host1 oraz host2 oznaczająten sam komputer.Aby zbadać wydajność usług przechowywanych w kontenerach, należy

wykonać następujące kroki:

1. Uruchomienie serwera JMS

91

Na komputerze host1 powinien zostać uruchomiony serwer JMS. Słu-ży on do przesyłania wiadomości pomiędzy sensorami wydajności orazkonsolą. Adres IP komputera host1 powinien być widoczny dla konsolioraz wszystkich komputerów na których zostaną umieszczone konte-nery usług. Należy pamiętać o ustawieniu w polu ServerConfigurationadresu IP komputera host1 w pliku openjms.xml z katalogu openjm-s/config. Serwer JMS uruchamiany jest skryptem startup.sh z kataloguopenjms/bin.

2. Instrumentacja bibliotek serwera

Krok opcjonalny - wykonywany jedynie w przypadku zmiany adresuserwera JMS (lub przy pierwszym użyciu). Z używanego konteneraGlassFish należy uzyskać oryginalny plik bpelcore.jar :

[host2] ~/app$ cp /opt/glassfish/domains/domain1/jbi/\components/sun-bpel-engine/install_root/lib/\bpelcore.jar .

Następnie należy uruchomić konsolę:

[host2] ~/app$ cd analyzer[host2] ~/app/analyzer$ ./run.sh

Spowoduje to pojawienie się okna dialogowe (por. rysunek A.1) z kon-figuracją instrumentacji. W polu JMS provider URL należy wpisaćadres uruchomionego serwera JMS w postaci: rmi://host1:1099. Na-stępnie należy wybrać operację Instrument. Spowoduje to pojawieniesię okna wyboru pliku źródłowego do instrumentacji, w którym nale-ży wybrać oryginalny plik bpelcore.jar. W kolejnym oknie dialogowymnależy podać nazwę pliku docelowego (np. bpelcore2.jar w tym samymkatalogu co bpelcore.jar). Następnie zostanie wykonana instrumentacjai wygenerowany komunikat o jej rezultacie. Na końcu należy podmienićzinstrumentowany plik bpelcore.jar we wszystkich używanych kontene-rach GlassFish:

[host2] ~/app$ cp bpelcore2.jar /opt/glassfish/domains/\domain1/jbi/components/sun-bpel-engine/\install_root/lib/bpelcore.jar

3. Uruchomienie konsoli

92

Rysunek A.1: Konfiguracja konsoli

[host2] ~/app$ cd analyzer[host2] ~/app/analyzer$ ./run.sh

Pojawi się okno dialogowe w którym należy wpisać adres uruchomione-go serwera JMS w postaci rmi://host1:1099 w polu JMS providerURL. Po wybraniu przycisku Run visualisation konsola zostanieuruchomiona i przygotowana do analizowania zbieranych danych o wy-dajności usług.

4. Uruchomienie kontenerów i usług

Należy uruchomić zinstrumentowane kontenery GlassFish wraz z apli-kacjami.

W trakcie wykonywania operacji na usługach przechowywanych w konte-nerach można obserwować zbierane dane wydajnościowe na konsoli wizuali-zacyjnej.

A.2 Sposób wizualizacji danych wydajnościo-wych

Główne okno aplikacji (przedstawione na rysunku A.3) składa się z nastepu-jących obszarów:

• Modele BPEL - każda zakładka prezentuje osobny model BPEL

• Procesy BPEL - lista procesów (pojedyńczych wywołań modelu BPEL)

93

• Wybrany proces - informacje o wybranym procesie (m.in. identyfi-kator procesu, czas trwania)

• Elementy modelu - graf elementów modelu, dowolny element możezostać wybrany po kliknięciu na niego

• Wybrany element - informacje o wybranym elemencie modelu (m.in.identyfikator oraz rodzaj elementu, statystyka czasowa, ilość wywołań),dostępny jest również przycisk pokazujący szczegółowe informacje okażdym pojedyńczym wywołaniu (por.rysunek A.2).

• Tryb ścieżek - tryb rysowania scieżek pomiędzy elementami (umożli-wia np. kolorowanie scieżek według intensywności ich użycia)

Rysunek A.2: Szczegółowe informacje o wywołaniach

94

Rysunek A.3: Układ głównego okna aplikacji

95

Aplikacja ma również możliwość włączenia trybu logowania w sensorzewydajności. Opcja taka może być pomocna w przypadku problemów z dzia-łaniem sensora lub niepoprawnym dostarczaniem danych o wydajności dokolejki JMS. Logowanie sensora wydajności ustawia się w oknie konfiguracjikonsoli (por. rysunek A.1). W konfiguracji należy ustawić opcję Logging typena FILE, oraz podać nazwę pliku do którego będą zapisywane logi w poluLogging file name. Plik o podanej nazwie pojawi się na każdym komputerzena którym uruchomiony zostanie kontener wraz z sensorem wydajności. Poustawieniu odpowiedniego logowania w konfiguracji należy dokonać ponow-nej instrumentacji bibliotek kontenera.

96

Praca magisterska Badanie wydajności systemów o ... · Akademia Górniczo - Hutnicza im....

Documents

Transcript of Praca magisterska Badanie wydajności systemów o ... · Akademia Górniczo - Hutnicza im....