Badanie wydajności systemów o architekturze SOA

Wielkość: px
Rozpocząć pokaz od strony:

Download "Badanie wydajności systemów o architekturze SOA"

Transkrypt

1 Akademia Górniczo - Hutnicza im. Stanisława Staszica w Krakowie Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki Katedra Informatyki Praca magisterska Badanie wydajności systemów o architekturze SOA Tomasz Duszka, Jakub Janczak Promotor: dr inż. Dominik Radziszowski Kraków, 2008

2 Spis treści 1 Wstęp Cel pracy Struktura pracy Technologie SOA Kluczowe elementy Kontrakt Webservice WSDL SOAP UDDI ESB Historia ESB Założenia i cechy ESB Istniejące implementacje ESB Wdrożenia ESB JBI BPEL Wersje BPEL Dostępne implementacje BPEL System badania wydajności Wymagania Wymagania w stosunku do konsoli Wymagania w stosunku do sensora wydajności Koncepcje rozwiązań Koncepcje nie wymagające modyfikacji kodu BPEL Obserwator zdarzeń silnika BPEL Koncepcje wymagające instrumentacji kodu BPEL Wybrane podejście

3 4 Implementacja Opis wybranych problemów implementacyjnych Wstrzykiwanie sensora wydajności Format komunikatu z danymi o wydajności Przekazywanie wiadomości od sensora do konsoli Wizualizacja zebranych danych w konsoli Podsumowanie Testy Testowane oprogramowanie Opis procedury testowania Konfiguracja infrastruktury Dynamiczna prezentacja wyników Wyniki testów Wnioski z pracy i możliwości dalszego rozwoju systemu Możliwości zastosowania stworzonego oprogramowania Dalszy rozwój systemu Akronimy 82 8 Bibliografia 84 9 Spis rysunków 89 A Podręcznik użytkownika 91 A.1 Instrumentacja bibliotek kontenera oraz konfiguracja aplikacji 91 A.2 Sposób wizualizacji danych wydajnościowych

4 Rozdział 1 Wstęp SOA (Service Oriented Architecture) to największe osiągnięcie informatycznej myśli architektonicznej ostatnich lat 1. Ten wprowadzony w 1996 roku przez Gartnera[51] paradygmat stanowi obecnie dominujący nurt w projektowaniu systemów informatycznych 2 i jest ukoronowaniem wysiłków mających na celu uproszczenie oprogramowania rozproszonego. Jego powstanie ma ś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 aplikacji, nieuchronnie prowadzą do wzrostu ich złożoności. Aktualny model tworzenia oprogramowania powoli osiąga kres swoich możliwości - obserwowany 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 Newtonian physics to relativistic physics. [26] 2 Ocenia 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

5 czysto technologicznych, np. integracją systemów zbudowanych w oparciu o różne platformy pośredniczące (z ang. middleware). Inżynierowie muszą również radzić sobie z ciągłymi naciskami organizacyjnymi i biznesowymi takimi jak: ograniczanie kosztów wytwarzanego oprogramowania, potrzeba szybkiej odpowiedzi na zmieniające się wymagania, możliwość łatwej integracji i absorpcji nowych partnerów biznesowych. W celu zniwelowania wymienionych trudności powstało szereg rozwiązań, np. architektury przeznaczone do tworzenia systemów rozproszonych, przenośne języki programowania, środowiska wspierające integrację systemów itp. Nie rozwiązują one jednak współczesnych problemów - na przeszkodzie staje duża różnorodność platform programistycznych, stosowanych technologii oraz rosnąca potrzeba integracji systemów. Brak uniwersalnego i powszechnie stosowanego, a jednocześnie odpowiadającego obecnym potrzebom rozwiązania cząstkowego, przyczynił się do powstania koncepcji SOA - architektury zorientowanej na usługi (Service Oriented Architecture). Podstawową zasadą rządzącą tym podejściem jest luźne powiązanie (z ang. loose coupling) pomiędzy elementami systemu, pozwalające na proste komponowanie go jako całości (zmianę w sposobie projektowania oprogramowania obrazuje rysunek 1). Rysunek 1.2: Zmiana w podejściu do projektowaniu oprogramowania Logiczną konsekwencją takiego podejścia jest zastosowanie szeregu dobrych konwencji inżynierskich, takich jak ukrycie implementacji 3 czy ponowne 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 technologii z zakresu wymiany danych i integracji oprogramowania. Coraz większy udział w rynku mają te rozwiązania, które większą uwagę przywiązują do współdziałania różnych platform i przenośności. Chcąc realizować ideę SOA, 3 zwane też autonomicznością 5

6 użyte technologie muszą dawać jak największą swobodę w zakresie komunikacji. Ich bazą przestaje być interfejs programistyczny konkretnego języka, a zaczyna format wymienianych danych. Dodatkowo chcąc zapewnić jak największą niezależność poszczególnych części systemów, coraz większy nacisk kł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ą realizację SOA. W oparciu o nie, korzystając jednocześnie z idei ESB (Enterprise Service Bus) oraz języka BPEL (Business Process Execution Language), firmy informatyczne są w stanie stworzyć oprogramowanie spełniające założenia tej architektury, obniżające jednocześnie koszty rozwoju i utrzymania, jakie należ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 powszechnej wiedzy na temat SOA i utartych dobrych wzorców wytwarzania powoduje, że często oprogramowanie tworzone w tej architekturze, nie jest napisane w sposób optymalny, bez wykorzystania jej podstawowych zalet. Poważnym wyzwaniem staje się zatem kwestia pomiaru wydajności tworzonych aplikacji 4. Do tej pory świat informatyczny nie dopracował się jednolitej metodologii pomiarów wydajności systemów o architekturze SOA. Z punktu widzenia inżynierów oprogramowania - niemożliwe jest obecnie przeprowadzenie analizy porównawczej takiego oprogramowania. Istniejące rozwiązania pozwalają na pomiary wydajności poszczególnych elementów systemu o architekturze SOA 5, jednakże tematyka kompleksowego rozwiązania tego problemu, nie spotkała się dotychczas z dużym zainteresowaniem, zarówno ze strony świata komercyjnego, jak i naukowego. 1.1 Cel pracy Celem pracy jest analiza problemu pomiaru wydajności aplikacji zbudowanych w oparciu o paradygmat SOA. Rozważonych zostanie kilka potencjalnych rozwiązań oraz przeanalizowane zostaną zalety i wady każdego z nich. W oparciu o postawiony w pracy zestaw wymagań zostanie wybrane i zaimplementowane najlepsze. Stworzona implementacja zostanie sprawdzona w środowisku testowym na zestawie przykładowych aplikacji. Proces testowa- 4 Brak zrozumienia kryteriów wydajnościowych jest uznawany za jedno z pięciu największych zagrożeń SOA [5] 5 Na rynku istnieje szczególnie dużo rozwiązań do testowania wydajności oprogramowania opartego na technologii webservice 6

7 nia i wyniki będą podstawą do wyciągnięcia wniosków na temat przydatności wybranego rozwiązania w analizie wydajności aplikacji opartych o SOA. 1.2 Struktura pracy Niniejsza praca rozpoczyna się opisem technologii wykorzystywanych w tworzeniu aplikacji opartych o SOA. W rozdziale 3 szczegółowo sformułowano problem oraz zbiór wymagań stawianych poszukiwanemu rozwiązaniu. Rozdział zawiera ponadto dyskusję potencjalnych rozwiązań wraz z ich wadami i zaletami. Wybrane jest jedno, które najlepiej spełnia postawione wymagania. W rozdziale 4 omawiane są szczegóły technologiczne implementacji wybranego rozwiązania, natomiast w rozdziale 5 wyniki analizy przykładowej aplikacji w środowisku testowym. Pracę kończy rozdział 6 zawierający zbiór konkluzji odnośnie możliwości zastosowania i dalszego rozwoju zaimplementowanego systemu 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 napisane przez Jakuba Janczaka. Pozostałe rozdziały: 6, 7 oraz 8 zostały napisane przez autorów pracy wspólnie. 7

8 Rozdział 2 Technologie W rozdziale tym zaprezentowano przegląd najważnieszych technologii używanych 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ęki ich 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żywa kodowania Big Endian a inny Little Endian) konieczność obsługi rozproszonych mechanizmów transakcyjnych, autoryzacji i uwierzytelniania różnice koncepcyjne pomiędzy użytymi platformami pośredniczącymi (np. RMI operuje na poziomie wywołania metody interfejsu, Sun RPC na 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 tego procesu. Dla przykładu obiekty w technologii CORBA (wykorzystującej do transportu protokół IIOP) mogą komunikować się nie tylko z innymi obiektami CORBA, ale także np. z RMI. Technologie te nie rozwiązały wszystkich 8

9 problemów integracyjnych, a oprócz nich zaczęły pojawiać się nowe utrudnienia: statyczność obiektów, brak możliwości wymiany wadliwych w trakcie działania systemu ścisłe powiązanie elementów systemu (z ang. tight coupling) redundantność oprogramowania (np. implementacja tej samej funkcjonalnoś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 innego) wymagała ilości połączeń proporcjonalnej do kwadratu ilości podsystemó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życie pozwoliło rozwiązać część wspomnianych problemów. Najpopularniejsze z 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ładanie 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] - architektura zorientowana na luźno powiązane usługi. Usługa - logiczna reprezentacja powtarzalnej czynności biznesowej mająca oczekiwany rezultat (np. pobierz prognozę pogody, sprawdź czy osoba figuruje w krajowym rejestrze długów)[9]. 9

10 Podkreślenia wymaga fakt, że SOA i webservice nie są pojęciami równoznacznymi. Usługi webservice są dowodem i przykładem na istnienie technologii, która umożliwia konstrukcję systemu zgodnego z SOA. Na rysunku 2.2 znajduje się przykładowy schemat funkcjonowania aplikacji opartej o SOA. Pierwszym etapem jej działania jest wyszukanie wymaganej usługi w rejestrze (uzyskuje się w ten sposób m.in. informację o lokalizacji usługi). Następnie do usługi wysłane zostaje żądanie wykonania operacji, które jest przez nią przetwarzane a rezultat odesłany z powrotem do aplikacji. 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 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 transakcyjne zbudowane z innych usług (przelew między rachunkami) jak i funkcje systemowe (np. wyślij ). Do inżynierów należy decyzja o poziomie ziarnistości oferowanych usług. 10

11 2. Interfejs usługi jest odseparowany od implementacji. Konsumenci usługi nie znają dokładnego sposobu realizacji operacji, znają jedynie semantykę 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 wprowadzeniu kontraktów. 4. System jest systemem dynamicznym. W trakcie jego działania można dodawać nowe usługi oraz wymieniać stare (np. poprawiać znalezione w nich błędy, konstruować efektywniejsze wersje usługi). 5. Istnieje możliwość wielokrotnej implementacji tej samej usługi w różnych wersjach (np. za pomocą różnych algorytmów, różnych dostawców). Użytkownik decyduje której instancji usługi chce użyć (np. tej któ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ącego mechanizmy tych elementów (np. sposobu komunikacji, obsługi transakcji, kontroli dostępu). 7. Występuje całkowita transparentność lokalizacji. Konsument usługi nie 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 na kilka maszyn w celu zmniejszenia czasu wykonywania operacji. Dodatkowej uwagi wymaga pojęcie kontraktów, będących podstawą prawidłowej konstrukcji oprogramowania opartego o SOA 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 od implementacji oraz realizację luźnych powiązań pomiędzy usługami (modyfikacja szczegółów implementacji usługi nie powoduje zmian w kontrakcie, a więc jest transparentna dla konsumentów danej usługi). Zawierają opis informacji oferowanych i oczekiwanych przez usługę. Dobry kontrakt powinien zawierać następujące pozycje [52]: 11

12 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ługi) syntaktyka operacji (typy argumentów i rezultatów, wyjątki) szczegóły sposobu wywołania operacji (adres URL usługi oraz rodzaj protokołu transportu np. SOAP) opis niefunkcjonalny transakcyjność operacji QoS (Quality of Service) SLA (Service Level Agreement) np. dozwolone opóźnienie w wykonywaniu usługi autoryzacja, ograniczenie dostępu do operacji serwisu określonej grupie konsumentów Podkreślenia wymaga fakt, że nie istnieje sformalizowana postać kontraktu SOA. Powyższe informacje są jedynie proponowaną zawartością kontraktu. Rzeczywista zawartość kontraktu będzie miała różną postać w zależności od uż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 standardów dotyczących Internetu zdefiniowała webservice w sposób następujący[22]: Webservice - oprogramowanie wspierające wymianę danych między maszynami poprzez sieć, wykorzystujące w tym celu zbiór ustandaryzowanych technologii (WSDL, XML, SOAP, UDDI)[22]. 12

13 Webservice nie jest synonimem SOA. SOA jest to architektura zorientowana na luźno powiązane usługi, podczas gdy webservice jest to zbiór konkretnych technologii (WSDL, XML, SOAP, UDDI), użytych do realizacji SOA. Technologia webservice jest więc przykładowym sposobem realizacji SOA, nie jedynym, ale w dotychczasowej praktyce jednym z najpopularniejszych. Przykładowy scenariusz użycia webservice zaprezentowany został na rysunku 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 ustandaryzowanych technologii: 13

14 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 rejestru usług WSDL WSDL (Web Service Definition Language) jest to dokument XML opisujący webservice. Może przechowywać zarówno ogólną informację o usłudze (operacje i ich argumenty) jak również szczegółowe informacje (powiązanie usług z protokołami i adresami pod którymi usługi te są dostępne). Plik WSDL składa się z definicji następujących elementów (w nawiasach podano oryginalne angielskie nazwy)[23]: typ (type) - definicja typu danych komunikat (message) - złożony typ danych operacja (operation) - definicja operacji wraz z komunikatami zawierają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, dla SMTP) 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ę oraz oferowanych (typ rezultatu, nazwy operacji określające ich semantykę). Nie odwołuje się w żaden sposób do implementacji usługi, dzięki czemu występuje separacja pomiędzy interfejsem usługi (opisywanym w WSDL i kontrakcie) a jej implementacją. Zmiany w implementacji usługi - nie powodujące zmian w semantyce ani syntaktyce operacji - nie zmieniają dokumentu WSDL tej usługi. Tym samym nie naruszają kontraktu i nie wymagają zmian u konsumentów usługi. 14

15 2.2.2 SOAP SOAP (dawniej Simple Object Access Protocol, później Service Oriented Architecture Protocol, obecnie brak oficjalnego rozwinięcia tego akronimu[20]) jest to protokół opisujący sposób kodowania i wymiany wiadomości w formacie XML. Do przesyłania wiadomości zakodowanej zgodnie z SOAP najczęściej wykorzystuje się protokół HTTP/HTTPS (ze względu na jego popularność 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ów wymiany wiadomości (MEP - Message Exchange Pattern), ale dla potrzeb webservice 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 stworzenia odpowiedniej wiadomości w formacie SOAP. Format tej wiadomości 15

16 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 i hasło), identyfikator sesji. Po wysłaniu wiadomości do usługi (np. na adres uzyskany z pliku WSDL) następuje wykonanie żądanej operacji i odesłanie odpowiedzi do nadawcy. Odpowiedź jest również zakodowana w formacie SO- AP i zawiera informacje o rezultacie wykonania operacji (lub ewentualnych wyjątkach) UDDI UDDI (Universal Description, Discovery and Integration)[63] - technologia pozwalająca na publikację i wyszukiwanie informacji o usługach webservice. Jest to otwarty standard zarządzany przez organizację OASIS [7]. Sposób wykorzystania UDDI opiera się na mechanizmie publikacja-wyszukaniepowią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óry uzyskuje możliwość wykonywania operacji tej usługi Rysunek 2.5: Schemat wykorzystania UDDI [24] UDDI przechowuje informację o zbiorze podmiotów biznesowych. Pojedyń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

17 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ł publiczny rejestr usług UDDI stworzony przez firmę IBM, Microsoft oraz SAP [14]. W rejestrze tym, do momentu jego wyłączenia w roku 2006, zgromadzono ponad wpisów o usługach [14]. Wyłączenie publicznego rejestru było efektem zwiększającego się zainteresowania podmiotów biznesowych prywatnymi rejestrami UDDI. Oprócz technologii webservice możliwość realizacji paradygmatu SOA daje również platforma integracyjna ESB. 2.3 Enterprise Service Bus ESB (Enterprise Service Bus) to jedno z podejść które ułatwia tworzenie oprogramowania o architekturze SOA. Zakłada ono tworzenie sterowanego zdarzeniami systemu opartego o luźno powiązane usługi. Wymiana danych jest dokonywana przez szynę, której zadaniem jest wyznaczanie tras wiadomości, na podstawie dostarczonej konfiguracji. Głównym zamiarem jej twórców było rozluźnienie powiązania pomiędzy wykorzystywanymi usługami, a medium transportowym, co przedstawia rysunek 2.6. Rysunek 2.6: Zasada działania ESB [1] 17

18 2.3.1 Historia ESB ESB powstało na bazie scharakteryzowanych poniżej, bardzo obecnie popularnych 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 asynchronicznej wymiany jednostek danych (wiadomości) za pomocą jednolitych protokołów komunikacyjnych. Podstawowymi trybami komunikacji MOM są: Point-to-Point (punkt-punkt) - tryb w którym istnieje tylko jeden producent i jeden konsument wiadomości Publish/Subscribe (publikuj/zapisz się) - tryb w którym istnieje jeden producent, a odbiorców może być dowolna ilość. Użycie rozwiązań MOM stało się standardem obsługi asynchronicznych zdarzeń w dużych aplikacjach biznesowych, stymulując jednocześnie ich rozwój. Wiele z nich posiada tak zaawansowane właściwości jak: niezawodność dostarczania, kolejkowanie i filtrowanie wiadomości, transakcyjność, możliwość klastrowania, czy zaawansowane mechanizmy bezpieczeństwa. Do standardów realizujących ideę MOM należą między innymi:jms (Java 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 koniecznych połączeń w systemie rozproszonym poprzez wprowadzenie jednego centralnego punktu tzw. hub-and-spoke broker (pol. pośrednik w strukturze 18

19 gwiaździstej). Na punkcie tym spoczywa zadanie zawiadywania całą komunikacją w obrębie systemu - to on decyduje o tym gdzie ma trafić dana wiadomość. Architektura ta separuje aplikację od właściwego kodu integrującego poprzez 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 procesami biznesowymi aplikacji istniejących w dużych systemach Zapewnianie integralności danych w różnych częściach systemu 1 Uniezależnienie implementacji od systemów zewnętrznych - przeniesienie reguł i polityk biznesowych do EAI, tak aby zmiany dostawców nie wpł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 Server TM, SAP Exchange Infrastructure (SAP XI) TM oraz webmethods Integration Server TM. 19

20 Rysunek 2.9: ESB jako pochodna EAI i MOM ESB jest pochodną obu technologii Rysunek obrazuje sposób w jaki ESB czerpało swoje cechy z obu podejść. Korzysta z charakterystycznej dla MOM rozproszonej infrastruktury dostarczania wiadomości oraz oddziela logikę dostarczania od ich właściwego przetwarzania, co jest specyficzne dla EAI 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. Dlatego też idea ESB opiera się na następujących założeniach: adaptowalność niezależna od warunków wdrożenia - skali, technologii uczestniczących czy sposobu modelowania aplikacji zunifikowane podejście do połączenia poszczególnych elementów oprogramowania łatwość integracji z oprogramowaniem zarówno wewnątrz, jak i na zewnątrz korporacji prostota tworzenia aplikacji i dodawania do już istniejącego rozwiązania zdecentralizowanie działania usług integracyjnych zwiększona przejrzystość systemu 1 Znane również pod terminem EII (Enterprise Information Integration) 20

21 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 żadnym standardem, nie da się wyróżnić możliwości jakich takie oprogramowanie winno 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, wraz z 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 hurtowniach danych (ang. data warehouses) ETL Dostarczenie ustalonego zestawu funkcjonalności, w który zwyczajowo wchodzą: Możliwość sterowania procesem wykonania - z użyciem takich standardów jak WS-BPEL, WS-Choreography czy (mniej popularnego) 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

22 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ń pracy, zwracając największą uwagę na otwartość kodu i prostotę tworzenia aplikacji. Do realizacji pracy wybrano środowisko OpenESB Wdrożenia ESB Mimo swojej krótkiej historii, wiele firm zaadaptowało już lub też jest w trakcie adaptowania rozwiązań integracyjnych w oparciu o ESB. Do godnych uwagi należą: Wdrożenie ESB w infrastrukturze jednego z wiodących pożyczkodawców w Stanach Zjednoczonych, pozwoliło na obniżenie kosztów przetwarzania danych o 60%. Dokonano tego poprzez oparcie o ESB jednolitego systemu informacji o klientach spinającego rozsiane po całym kraju biura kredytowe oraz system ecredit. [4] Trwające 3 tygodnie wdrożenie ESB w jednej z największych sieci dystrybucji żywności w Europie, pozwoliło na zaoszczędzenie 3 milionów dolarów. Rolą ESB było zintegrowanie systemów trzech różnych systemó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 jest realizacja regulowanej prawnie komunikacji z rządem. [4] 22

23 Udział ESB w integracji systemów komórek rządowych Stanów Zjednoczonych celem walki z terroryzmem w ramach dokumentu USA Patriot Act. [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 ekspertów dysponujących wiedzą wystarczającą do zarządzania i konfiguracji ESB Ważny w kontekście tej pracy, duży narzut technologiczny - biorąc pod uwagę użycie takich koncepcji jak orchiestracja, czy transformacje XSLT, przy dodatkowym wykorzystaniu usług webservice zbudowanych w oparciu technologię SOAP, istnieje duża obawa, że obciążenie generowane przez samo oprogramowanie warstwy pośredniczącej, może być znaczące JBI JBI (Java Business Integration) - to specyfikacja JCP 2 (Java Community Process), która pozwala na stworzenie środowiska realizującego założenia ESB w technologiach związanych z językiem Java. Definiuje on środowisko komponentów realizujących model wymiany danych oparty o specyfikację WSDL 2.0[23]. Specyfikacja stanowi, iż komponenty JBI muszą posiadać następujące trzy cechy: Przenośność pomiędzy różnymi implementacjami kontenera JBI Scentralizowane zarządzanie Współpraca z innymi komponentami w obrębie kontenera, niezależ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: 2 JSR-208 (Java Specification Request) tworzony przez takie firmy jak Syn Microsystems, BEA, Borland, Nokia, Novell czy Oracle[46] 23

24 Rysunek 2.10: Nomenklatura JBI[28] Jednostka usługowa (SU) (org. service unit) - to jednostka programowa dostarczająca konkretnej implementacji usług korzystająca z właściwości kontenera w którym została umieszczona. Aplikacje składają się ze skomponowanych SU umieszczonych w kontenerach środowiska JBI. Silniki usługowe (SE) (org. service engine) - to komponenty wykonawcze umieszczane w kontenerze JBI, których zadaniem jest dostarczanie lub korzystanie z usług w jego obrębie. Komponenty te dostarczają właściwej logiki takiej 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 komponenty zapewniają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 dalszej drodze. Takie podejście, pozwala każdemy SE komunikować się ze światem zewnę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. Normalized Message Router) - najważniejsza część środowiska JBI - stanowi element 24

25 który zajmuje się sterowaniem przepływem wiadomości z punktów źródłowych do punktów docelowych, na podstawie określonego z góry kontraktu. NMR może również realizować pewne funkcje QoS dotyczące dostarczania wiadomości w obrębie kontenera. Kontener JBI (org. JBI Container) - środowisko wykonawcze komponentów JBI - zarówno BC jak i SE. Kontrakt Implementując komponent JBI, realizujemy pewien kontrakt, który obejmuje zagadnienia instalacji, pakowania, zarządzania cyklem życia, publikacji oferowanych usługi i przetwarzania wiadomości bazujące na jednym z czterech MEP (Message Exchange Pattern) 3. MEP - wzorce wymiany wiadomości NMR dostarcza wiadomości realizując jeden z czterech wzorców wymiany wiadomości będących częścią specyfikacji WSDL 2.0[23][1]: In-Only - standardowy sposób przesyłania w jedną stronę, w którym konsument wysyła wiadomość do dostawcy usługi, który odpowiada statusem Robust In-Only - niezawodny sposób przesyłania jednokierunkowego, w którym konsument wysyła wiadomość do dostawcy, który odpowiada statusem, i jeśli jest to błąd (fault), odesłane zostaje potwierdzenie In-Out - dwukierunkowy sposób wymiany wiadomości w którym na wiadomość konsumenta, dostawca usługi wysyła odpowiedź która jest następnie potwierdzana In Optional-Out - dwukierunkowy sposób wymiany wiadomości, w którym wiadomość będąca odpowiedzią na żądanie konsumenta jest opcjonalna Implementacje JBI Najszerzej znane implementacje kontenera JBI to: ServiceMix (FUSE ESB) [60] 3 opcjonalnie do kontraktu może należeć również zarządzanie jednostką usługową (SU - z ang. service unit) 25

26 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 Microsystems TM. 2.4 BPEL Aby w pełni korzystać z zalet SOA, konieczne jest osiągniecie niezależności kompozycji usług, od ich implementacji.[12] Istnieją dwa podejścia do tego zagadnienia [34]: Orchiestracja - w której jeden centralny komponent przejmuje kontrolę nad usługami będącymi uczestnikami procesu biznesowego, koordynując ich współpracę. Usługi nie są świadome bycia uczestnikami procesu biznesowego (przykład ilustruje rys 2.11). Rysunek 2.11: Orchiestracja Choreografia - podejście w którym zamiast jednego centralnego punktu, każda usługa wie kiedy i z jakimi usługami ma się komunikować. 26

27 Usługi muszą być świadome uczestniczenia w procesie biznesowym (przykład ilustruje rysunek 2.12). Rysunek 2.12: Choreografia BPEL[6] (Business Process Execution Language) jest to zdefiniowany przez organizację OASIS język orchiestracji procesów biznesowych opartych o usługi zdefiniowane w języku WSDL. Język ten pozwala na modelowanie na dwóch poziomach abstrakcji: opisowym poziomie abstrakcyjnym(z ang. Abstract Business Process) 4 i dokładniejszym 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 wyzwalane poprzez żądanie wykonania operacji webservice import funkcjonalności, proces BPEL umożliwia wykonanie operacji na usługach webservice 4 modele takie nie mają być wykonywane, a są jedynie tworzone celem zobrazowania pewnego konkretnego procesu 27

28 2.4.1 Wersje BPEL Wersje 1.0 i 1.1 BPEL,a w zasadzie BPEL4WS (Business Process Execution Language for Web Services) powstał w 2002 jako efekt współpracy firm BEA, IBM i Microsoft. W roku 2003 do organizacji specyfikującej BPEL dołączyły firmy SAP oraz Siebel Systems, a język ewoluował do wersji 1.1. Wersja ta została zaaprobowana przez organizację OASIS (Organization for the Advancement of Structured Information Standards), i od tamtego czasu język ten stał się standardem w dziedzinie kompozycji procesów biznesowych[11][34][41][39]. Możliwości języka BPEL w wersji 1.1 przewiduje następujące możliwości: Specyfikacja języka BPEL 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 BPEL w wersji 1.1 oferuje następujące kon- Dostępne konstrukcje 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

29 Compensate pozwalające na zdefiniowanie zachowania procesu w obrębie transakcji, w przypadku, gdy jedna z jego składowych zawiedzie (próba odwrócenia efektów działania elementów już wykonanych 5 ) 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 Wersja 2.0 Receive odebranie wiadomości z usługi dostarczanej przez proces 6 Reply odpowiedź na odebraną wiadomość 7 Invoke wykonanie operacji na usłudze webservice. Opracowana w roku 2004 nowa wersja języka BPEL wprowadziła takie usprawnienia jak możliwość rozszerzania języka, czy uproszczenia w przypisywaniu i inicjalizacji zmiennych. Pojawiły się nowe pętle: RepeatUntil 8 i wykonywana zarówno równolegle, jak i sekwencyjnie ForEach 9. Uproszczono również obsługę błędów oraz inicjalizację tzw. Partner Link 10. Zmieniono również oficjalną nazwę języka - obecnie oficjalną nazwą jest WS-BPEL (Web Service - Business Process Execution Language) 11 [11][34][41][64]. 5 analogiczne do zachowania transakcyjności w bazach danych, tzw. ACID (skrót ten pochodzi z terminologii baz danych, i oznacza cztery warunki jakie muszą spełniać transakcje: atomowość, spójność, izolacja i trwałość (z ang. Atomicity, Consistency, Isolation, Durability)[35]) 6 operacja ta jest najczęściej operacją wyzwalającą proces 7 analogicznie operacja taka najczęściej kończy wyzwolony proces 8 pętla z warunkiem ewaluowanym na jej końcu 9 pętla dokonująca pewnych operacji na zbiorze danych 10 odniesień do usług w obrębie procesów 11 uczyniono tak celem dopasowania się do pozostałych nazw standardów z zakresu technologii webservice których nazwy zwyczajowo zaczynają się od WS- 29

30 Wszystkie dostępne obecnie konstrukcje języka BPEL, wraz z ich graficznymi reprezentacjami przedstawia rysunek 2.13(należy mieć jednak na uwadze fakt, iż reprezentacje te nie stanowią części standardu). Rysunek 2.13: Elementy konstrukcyjne języka BPEL Dostępne implementacje BPEL Język BPEL jest obsługiwany w wielu środowiskach integracyjnych, zarówno jako komponenty, jak i samodzielne rozwiązania. Do najbardziej rozwiniętych komercyjnych rozwiązań należą[12]: IBM Websphere Business Integration Foundation TM [10] 30

31 Oracle BPEL Process Manager TM [50] Microsoft BizTalk TM [47] BEA Aqualogic TM [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 w języku BPEL, takich jak oparte na platformie Eclipse Oracle BPEL Designer[49] i IBM Websphere Application Developer Integration Edition[44], czy wybrany przez autorów, oparty o platformę Netbeans BPEL Designer[48] (przedstawiony na rys. 2.14). Wybór ten został podyktowany dojrzałością i otwartością rozwiązania, oraz zaawansowaną integracją z wybranym wcześniej środowiskiem OpenESB. 31

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

33 Rozdział 3 System badania wydajności W rozdziale tym opisane zostały kryteria jakie powinien spełniać system wspomagający badanie wydajności systemów o architekturze SOA. W kolejnych punktach rozdziału przedstawiono analizę w kontekście tych kryteriów oraz uzasadnienie ostatecznego wyboru. W celu zbadania wydajności aplikacji zbudowanej zgodnie z paradygmatem SOA potrzebne są dodatkowe dane zbierane w trakcie działania takiej aplikacji. Dane te opisują jednostkowe operacje wykonywane przez aplikację (np. wywołanie usługi webservice, sekwencje wywołań operacji, pętle, instrukcje warunkowe, bloki obsługi wyjątków) i zawierają m.in. informację o czasie trwania danej operacji, dodatkowych parametrach (np. adres i operacja przy usłudze webservice), statusie (np. zakończenie poprawne, zakończenie z powodu wyjątku) itp. Po zebraniu pomiary mogą zostać przedstawione użytkownikowi w czytelny sposób, np. jako diagramy Gantta[43], model BPEL, wykresy, itp. W systemach badających wydajność za zbieranie danych odpowiada sensor wydajności. Można wyróżnić dwa podejścia do kwestii jego lokalizacji: Umieszczenie sensora wydajności w obrębie usług. Takie podejście wymaga modyfikacji każdej z usług, co powoduje, że usługi muszą być świadome brania udziału w badaniu wydajności. W przypadku posiadania kodu źródłowego usług konieczna jest jego analiza i odpowiednia modyfikacja, co czyni ten proces czasochłonnym; przy braku kodu źródłowego usług odpowiednia modyfikacja jest już często niewykonalna w rozsądnych granicach czasowych. Umieszczenie sensora wydajności w obrębie kontenera. Zaletą tego podejścia jest fakt, że modyfikacje środowiska w którym działają usługi należy wykonać tylko raz, niezależnie od ilości wykorzystywanych usług. 33

34 Rysunek 3.1: Architektura używana do badania wydajności aplikacji Wariant z sensorem wydajności w usługach jest niepraktyczny w realizacji i jako taki został odrzucony. Podjęto decyzję o umieszczeniu sensora wydajności w obrębie kontenera szyny łączącej usługi. Zarys koncepcji badania wydajnoś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, zarówno koncepcyjnych (np. sposób działania sensora wydajności, sposób identyfikacji 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ące potencjalne rozwiązania. Kryteriami tymi są wymagania funkcjonalne i niefunkcjonalne w stosunku do elementów architektury zawartych na rysunku

35 3.1 Wymagania Zestaw wymagań został podzielony na dwie grupy, pierwsza dotyczy konsoli wizualizacyjnej, a druga sensora wydajności Wymagania w stosunku do konsoli W stosunku do konsoli wizualizacyjnej postawiono następujące wymagania: przygotowanie środowiska poprzez dodanie sensora wydajności (może się to wiązać z np. instrumentacją bibliotek serwera, modyfikacją jego plików startowych lub rozmieszczeniem (ang. deploy) w serwerze specjalnej aplikacji monitorującej wydajność) odbieranie informacji o wydajności z wykorzystaniem Message Oriented Middleware (np. JMS) obrazowanie na bieżąco (ang. online) wyników badania wydajności aplikacji prezentacja wyników w postaci sekwencji języka BPEL (np. wykonanie operacji 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 w sposób przejrzysty dla użytkownika w postaci diagramu z modelem BPEL. Dla każdej operacji przedstawionej na diagramie powinny być dostępne informacje: średni, minimalny, maksymalny oraz sumaryczny czas trwania operacji czas rozpoczęcia i zakończenia, parametry, rezultat (np. zakończenie przez rzucenie wyjątku) każdego wywołania operacji Wymagania w stosunku do sensora wydajności Typowa metryka uzyskiwana z procesu mierzenia wydajności - czas wykonania 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, na którym znajduje się przykładowy schemat wywołania usługi webservice z poziomu języka BPEL w OpenESB. Przykładowo, jeśli sensor umieścimy w obrębie JBI, to w zmierzonym czasie wykonania operacji webservice będzie 35

36 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 silnika BPEL na czas wykonania operacji, a tym samym zaburzony zostanie wynik badania wydajności aplikacji. W celu zniwelowania skutków niewłaściwego zbierania wyników wydajności, należy sensor wydajności umieścić w obrębie silnika BPEL. Wymagania w stosunku do sensora wydajności: działanie możliwie blisko silnika BPEL, w celu uzyskania dokładnych wyników brak ingerencji w zewnętrzne usługi (sensor nie może modyfikować sposobu ich działania) minimalny wpływ na działanie aplikacji (najważniejsze jest ograniczenie narzutów czasowych związanych ze zbieraniem danych o wydajności) możliwość implementacji w najpopularniejszych serwerach aplikacji (sama implementacja sensora wydajności będzie różniła się szczegółami w zależ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 wykorzystaniu już istniejących możliwości pobrania informacji pomiarowych ze środowiska ESB Wymagające modyfikacji środowiska testowego - koncepcje, których wykorzystanie opiera się na zmianach w kodzie aplikacji, bądź środowiska Koncepcje nie wymagające modyfikacji kodu BPEL Interfejs monitorowania BPEL OpenESB Silnik usługowy BPEL zastosowany w implementacji OpenESB udostępnia interfejs programistyczny pozwalający na monitorowanie i zarządzanie pro- 36

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

38 cesami wykonywanymi w jego obrębie. Do jego możliwości należą między innymi: 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 procesów Dostęp i zmiana zmiennych instancji Dostęp do informacji na temat procesów, instancji, a także aktywności instancji (activity) Wymieniony jako ostatni dostęp do informacji na temat aktywności instancji 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 ona na aktywnym, synchronicznym odpytywaniu o dane pomiarowe. Analiza trafności rozwiązania Odpowiednie użycie i agregacja danych pozwalałoby na stworzenie zakładanego systemu do pomiarów wydajności. Rozwiązanie to ma jednak jedną zasadniczą wadę - dane z interfejsu zbierane są synchronicznie 1, co pociąga za sobą konsekwencje w postaci możliwości utraty części danych - problem ten dotyczy przede wszystkim konstrukcji pętli. Problemem byłaby również agregacja otrzymanych w taki sposób danych oraz dobór częstości próbkowania (w zależności od dobranej wartości stworzone narzędzie byłoby albo narażone na utratę danych, albo na duży nakład obliczeń potrzebny do agregacji). 1 użyty został tutaj wzorzec Wizytora[30] 38

39 Rysunek 3.3: Koncepcja rozwiązania w oparciu o interfejs monitorowania silnika BPEL HULP HULP to biblioteka dla języka Java TM pozwalająca na zinstrumentowanie kodu celem dokonywania pomiarów czasu wykonania obszarów kodu. Oferuje ona prosty interfejs programistyczny, z którego użyciem możliwe jest zaznaczanie początku i końca wykonania obszaru kodu. Wykonane w taki sposób pomiary są następnie zbierane, agregowane i prezentowane z pomocą aplikacji WWW. Cechy rozwiązania Prosta w realizacji instrumentacja. Przykładowo: public void komenda ( S t r i n g parameter ) { 3 Measurement m = Measurement. begin ( komenda, parameter ) ; 4 try { 5... badany obszar kodu 6 } f i n a l l y { 7 m. end ( ) ; 8 } 9 } 39

40 Niski narzut czasowy zinstrumentowanego kodu przy wyłączonym zbieraniu danych Nieskomplikowana budowa - HULP składa się z trzech komponentów: interfejs instrumentacji, klasy agregacji i servlet odpowiedzialny za prezentacje wyników Zagregowane wyniki zwracane są w postaci zestawu następujących danych: ilości wywołań czas trwania pomiarów 2 sumy oraz średniej czasu spędzonego w zinstrumentowanych obszarach kodu przepustowości 3 pomiaru obciążenia 4 generowanego podczas pomiaru Idea rozwiązania z użyciem HULP Rozważanie użycia HULP opiera się na fakcie, iż kod OpenESB już został zinstrumentowany z pomocą tej biblioteki. Idea rozwiązania opiera się na pobieraniu danych z warstwy prezentacji HULP (servletu), dla ich dalszej analizy (ogólny schemat koncepcji przedstawia rys. 3.4). Rysunek 3.4: Koncepcja rozwiązania z użyciem HULP 2 od pierwszego begin() do ostatniego end() 3 ilość wywołań podzielona przez czas trwania pomiarów 4 suma czasu spędzonego w zinstrumentowanych obszarach kodu podzielona przez czas trwania pomiarów 40

41 Analiza trafności rozwiązania Pomimo szeregu zalet tego rozwiązania nie spełnia ono założeń postawionych na początku tego rozdziału. Do najważniejszych problemów związanych z użyciem HULP należą: konieczność modyfikacji kodu OpenESB (ponieważ nie wszystkie interesujące z punktu widzenia pracy obszary kodu zostały zinstrumentowane) brak znaczników czasowych trudności w identyfikacji badanych procesów biznesowych 5 niepełność zagregowanych danych trudny do interpretacji maszynowej format dostarczanych danych Obserwator zdarzeń silnika BPEL Silnik BPEL OpenESB udostępnia interfejs (BPEL SE Events Listener) pozwalający na zarejestrowanie obserwatorów[30] zachodzących w nim zdarzeń. Pozwala to na odbieranie informacji dotyczących procesów oraz ich aktywnoś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 i instancji oraz znacznikiem czasowym. Zdarzenia dotyczące aktywności procesu zawierają wyrażenie XPath prowadzące do tej aktywności. Klasa obserwatora powinna implementować następujący interfejs: 1 interface EventListener { 2 void processevent ( Event event ) ; 3 } Idea rozwiązania Rysunek 3.5 przedstawia ideę rozwiązania opartego o BPEL SE Events Listener. Logika przetwarzania danych pomiarowych otrzymywałaby dane po uprzednim zarejestrowaniu obserwatora zdarzeń w silniku BPEL. 5 trudności w odróżnieniu kilku działających jednocześnie procesów biznesowych 41

42 Rysunek 3.5: Koncepcja rozwiązania z użyciem BPEL SE Events Listener Analiza trafności rozwiązania Rozwiązanie oparte o BPEL SE Events Listener posiada wiele zalet, takich jak prostota, asynchroniczny model działania oraz duży zakres dostarczanych danych. Ważna właściwością jest również oparty o pulę wątków nieblokujący model rozsyłania zdarzeń do obserwatorów, znacznie zmniejszający narzuty czasowe z nim związane. Rozwiązanie nie spełnia postawionych założeń pracy: do jego pełnego działania konieczna jest instrumentacja aplikacji umieszczanej na serwerze 6. Niewątpliwym problemem jest również brak przenośności tego rozwiązania 7 do innych środowisk ESB Koncepcje wymagające instrumentacji kodu BPEL Modyfikacja kodu aplikacji Najprostszym rozważanym rozwiązaniem jest zmodyfikowanie kodu testowanej aplikacji w taki sposób aby sama dostarczała informacji pomiarowych. Modyfikacja taka opierałaby się na dodaniu takiej logiki do kodu BPEL w formie odpowiednio umieszczonych operacji Invoke, przed każdą możliwą operacją. Operacje te wysyłałyby informacje pomiarowe do uprzednio stworzonej usługi monitorującej. Koncepcję tę ukazuje rysunek 3.6. Trudności w realizacji tego rozwiązania, konieczność modyfikacji już zbudowanej aplikacji oraz niska wiarygodność dostarczanych znaczników czasowych wyklucza jego praktyczne zastosowanie. 6 konieczne jest dodanie do niej implementacji obserwatora oraz dopisanie nazwy jego klasy w pliku META- INF/services/com.sun.jbi.engine.bpel.core.bpel.event.BPELEventListener 7 Pozwalałoby ono na monitorowanie jedynie tego konkretnego silnika BPEL 42

43 Rysunek 3.6: Koncepcja instrumentacji kodu BPEL aplikacji Modyfikacja kodu środowiska wykonawczego Skomplikowanym, ale jednocześnie posiadającym najwięcej możliwości rozwiązaniem jest zmodyfikowanie środowiska wykonawczego w taki sposób, aby generowało ono zdarzenia i przekazywało je asynchronicznie do zbiorczego punktu celem dalszej analizy. Zdarzenia te przenosiłyby ze sobą następujące informacje: znaczniki czasowe operacji szereg jednoznacznych identyfikatorów pozwalających określić pochodzenie 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

44 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ązania można publikować zdarzenia z użyciem oprogramowania realizującego koncepcję MOM (np. JMS). Rysunek 3.7 przedstawia zarys tej koncepcji. Wynika z niego, że aby dokonać takiej instrumentacji konieczna jest statyczna modyfikacja kodu silnika BPEL. Można tego dokonać albo modyfikując jego otwarty kod źródłowy, lub użyć narzędzia do instrumentacji kodu wykonawczego. Rysunek 3.7: Koncepcja instrumentacji środowiska wykonania 44

45 Analiza trafności rozwiązania Brak konieczności modyfikacji kodu źródłowego zarówno aplikacji, jak i środowiska, jest bardzo dużą zaletą tego rozwiązania. Drugą zaletą jest wiarygodność dostarczanych danych - instrumentacja kodu w odpowiednio dobranych punktach niweluje problem niemiarodajnych znaczników czasowych. Dekompozycja oprogramowania na część generującą zdarzenia oraz część odpowiedzialną za ich wysyłanie znacznie ogranicza ilość czasu potrzebną do implementacji rozwiązania pod kątem konkretnej architektury środowiska wykonawczego. 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, nie można skorzystać z wymienionych wyżej rozwiązań nie wymagających modyfikacji kodu. Wszystkie one są charakterystyczne dla środowiska OpenESB i jest bardzo mało prawdopodobne, że będzie możliwa ich realizacja na innych platformach. Koncepcja modyfikacji procesów biznesowych, jest bardzo prosta, a stworzenie oprogramowania automatyzującego ten proces jest możliwe do wykonania. Nie pozwala ona jednak na wygenerowanie zdarzeń opatrzonych jednoznacznymi 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 zdarzenia pozwala na stworzenie najbardziej elastycznego rozwiązania. Przy odpowiedniej dekompozycji stworzonego oprogramowania, i zastosowaniu technik nieintruzywnej instrumentacji, stanowi podstawę do stworzenia rozwiązania najbardziej uniwersalnego. Adaptacja stworzonego oprogramowania będzie wymagała umiarkowanego nakładu pracy. Koncepcja ta została wybrana do realizacji w ramach niniejszej pracy. 45

46 Rozdział 4 Implementacja Stworzone oprogramowanie do badania wydajności aplikacji zgodnych z paradygmatem SOA składa się z następujących modułów funkcjonalnych: sensor wydajności - element umieszczony w kontenerze, zbiera dane o wydajności i wysyła je do kolejki JMS część charakterystyczna dla konkretnego kontenera - wstrzyknięta bezpośrednio w kod kontenera i odpowiedzialna za zbieranie danych o wydajności część wspólna dla wszystkich kontenerów - konstruuje komunikat i wysyła go asynchronicznie do kolejki JMS moduł umieszczający sensor wydajności w kontenerze - dokonuje instrumentacji bibliotek wchodzących w skład kontenera umieszczają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 implementacje i testowanie. 4.1 Opis wybranych problemów implementacyjnych Najtrudniejszym elementem do realizacji jest moduł umieszczający sensor wydajności w kontenerze. Realizacja tego modułu wymaga wykorzystania silnika do instrumentacji (modyfikacji skompilowanego kodu kontenera, bez dostępności jego źródeł) programów napisanych w języku Java. 46

47 4.1.1 Wstrzykiwanie sensora wydajności Sensor wydajności może zostać wstrzyknięty do bibliotek kontenera za pomocą jednej z dostępnych bezpłatnie bibliotek wspomagających programowanie aspektowe (AOP[33]), np. AspectJ[53] lub Aspectwerkz[54]. Instrumentacja kodu jest realizowana w jednym z dwóch trybów[62]: Online - instrumentacja w trakcie działania aplikacji. Zmodyfikowane klasy (wraz ze wstrzykniętym kodem) mogą być ładowane w momencie ich pierwszego użycia lub podmieniane w dowolnym momencie w czasie działania aplikacji. Praktyczna realizacja trybu online wymaga często modyfikacji maszyny wirtualnej (JVM) w której uruchomiona jest aplikacja (dodatkowe parametry dla maszyny wirtualnej, modyfikacja klas systemowych maszyny wirtualnej[16] (ang. bootstrap classes) itp). Modyfikacje są charakterystyczne dla konkretnej wersji maszyny wirtualnej. Offline - instrumentacja przed pierwszym uruchomieniem aplikacji. Modyfikacja kodu aplikacji wykonywana jest jednorazowo poprzez silnik instrumentacji. Nie ma konieczności wprowadzania żadnych zmian do 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óch trybów pracy. Należy jednak zauważyć, że sensor jest elementem który jest obecny cały czas w kontenerze. Mamy również możliwość przygotowania kontenera (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 wymaga modyfikacji maszyny wirtualnej na której będzie działać aplikacja ani skryptów startowych aplikacji). Po przeprowadzeniu analizy znanych nam bibliotek programowania aspektowego (np. AspectJ, Aspectwerkz) pod kątem użycia ich w trybie offline można zauważyć nastepujące wady: wymagane jest podanie definicji dodatkowych zmiennych (poprzez parameter -D przy poleceniu java ) w skryptach startowych, np. podania lokalizacji pliku XML z definicją aspektów wymagane jest dodanie do listy bibliotek JAR aplikacji dodatkowych plików z kodem specyficznym dla danej biblioteki programowania aspektowego 47

48 używanie biblioteki programowania aspektowego w niepoprawnej wersji może powodować konflikty z bibliotekami aspektowymi używanymi przez kontener (większość kontenerów udostępnia wsparcie dla AOP), jeszcze większe prawdopodobieństwo konfliktów wersji występuje dla bibliotek zależnych wymaganych przez bibliotekę AOP (ang. thirdparty libraries) np. Apache Commons[38] Część z przedstawionych wad (modyfikacji listy bibliotek JAR aplikacji, dodatkowe definicje zmiennych) teoretycznie można rozwiązać poprzez modyfikację odpowiednich skryptów startowych kontenera. W praktyce jednak pojawiają się problemy z dużą ilością skryptów w nieznanych lokalizacjach (np. w kontenerze GlassFish każda domena ma własne skrypty) oraz z uruchamianem kontenera z pominięciem skryptów startowych. Problem konfliktu wersji nie ma prostego rozwiązania. Jednym z potencjalnych rozwiązań (ale niepraktycznych) jest np. zmiana biblioteki AOP w zależności od docelowego kontenera. Z uwagi na przedstawione problemy została podjęta decyzja o stworzeniu własnej biblioteki instrumentującej kod. Podstawowe założenia takiej biblioteki to: instrumentowanie kodu jedynie w trybie offline brak konieczności modyfikacji skryptów startowych aplikacji, maszyn wirtualnych itp. brak dodatkowych bibliotek, które muszą być dołączane do zinstrumentowanego kodu specyficzna i minimalna funkcjonalność w porównaniu z ogólnymi bibliotekami programowania aspektowego, pozwalająca jedynie na wstrzykiwanie wywołań metod w dowolne miejsca instrumentowanego kodu Należy podkreślić fakt, iż biblioteka instrumentująca kod ma bardzo specyficzną funkcjonalność i nie jest równoważna bibliotece wspierającej programowanie aspektowe (ma nieporównywalnie mniejszą złożoność). Do jej konstrukcji zostały użyte gotowe moduły (np. biblioteka CGLIB[55] do manipulowania skompilowanym kodem Java (ang. bytecode)[29]). Implementacja biblioteki instrumentującej kod nie była więc zajęciem bardzo czasochłonnym i 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 wstrzyknięty zostanie dodatkowy kod widoczny w dolnej części. Sterowanie sposobem instrumentacji odbywa się poprzez adnotacje obecne we wstrzykiwanym 48

49 kodzie. Dostępne adnotacje umożliwiają wyznaczenie miejsca wstrzyknięcia kodu oznacza, że kod musi być wstrzyknięty na początek metody określonej Możliwe jest również pobieranie parametrów przekazywanych do instrumentowanej metody przekazuje do danej zmiennej i-ty parametr instrumentowanej metody). Rysunek 4.1: Przykład użycia biblioteki instrumentującej kod Adnotacje dla biblioteki instrumentującej kod umieszczone są w części sensora wydajności charakterystycznej dla danego kontenera. Pozwalają sensorowi zbierać dane w trakcie działania usług (np. rozpoczęto wykonywanie operacji webservice, zakończono wykonywanie operacji webservice). Dane te tworzą komunikat w zestandaryzowanej postaci, który jest przekazywany do części sensora niezależnej od konkretnego kontenera Format komunikatu z danymi o wydajności Format komunikatu z danymi o wydajności został przedstawiony na rysunku

50 Rysunek 4.2: Postać komunikatu z danymi o wydajności w postaci diagramu klas UML 50

51 Główna klasa komunikatu (Event) może przenosić jeden z dwóch rodzajó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 konsoli budowany jest model zachodzącego procesu. Konsola nie ma dostępu do oryginalnych modeli procesów przechowywanych w kontenerach aplikacji, dlatego do zbudowania modelu procesu muszą jej wystarczyć dane otrzymywane z sensora wydajności. Powoduje to konieczność sformułowania dodatkowych założeń dotyczących identyfikatorów otrzymywanych w wiadomościach z rysunku 4.2: identyfikator modelu procesu (unikalny globalnie) identyfikator procesu - wskazuje konkretne wywołanie procesu według danego modelu (unikalny globalnie) identyfikator aktywności - wyrażenie XPATH[31] wskazujące na aktywność 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 do części sensora niezależnej od używanego kontenera. Odpowiada ona za przekazywanie komunikatów do konsoli prezentującej wyniki. 51

52 4.1.3 Przekazywanie wiadomości od sensora do konsoli Komunikaty wysyłane są z sensora do serwera JMS, skąd mogą być pobierane przez konsolę prezentującą wyniki. Proces wysyłania komunikatów odbywa się niezależnie od ich generowania, utworzone przez sensor komunikaty są umieszczane w kolejce, z której okresowo są pobierane i przekazywane do serwera JMS przez osobny wątek. Pozwala to zminimalizować wpływ sensora na działanie badanych usług - jedyny dodatkowy narzut związany z umieszczaniem komunikatów w kolejce jest bardzo mały. Użycie serwera JMS zapewnia prosty i pewny sposób na dostarczenie danych do konsoli. W praktyce przekazywanie wiadomości do serwerów JMS wymaga dodania dodatkowej grupy bibliotek (np. bibliotek Service Provider dla JNDI [17]). Biblioteki te muszą być dodane do kontenera, ponieważ kontener został zinstrumentowany przez sensor wydajności wysyłający komunikaty JMS. Powoduje to możliwość powstawania konfliktów wersji z istniejącymi już bibliotekami wchodzącymi w skład kontenerów (wsparcie dla serwerów JMS jest powszechne w kontenerach). Problem ten można rozwiązać stosując koncepcję podobną do tzw. sandbox[32]. Biblioteki serwera JMS nie są bezpośrednio dołączane do kontenera, tylko do izolowanego środowiska (sandbox) działającego w obrębie kontenera. W środowisku tym działa kod odpowiedzialny za wysyłanie komunikatów do serwera JMS. Poza izolowanym środowiskiem nie są widoczne biblioteki serwera JMS dlatego nie powodują one interakcji z kontenerem. Przedstawioną koncepcję sposobu przekazywania wiadomości od sensora do konsoli ilustruje rysunek 4.3. Rysunek 4.3: Przepływ komunikatów z danymi o wydajności 52

53 4.1.4 Wizualizacja zebranych danych w konsoli Część prezentacyjna projektu została wykonana z użyciem komponentów z modułu BPEL Designer pakietu NetBeans 6.0. Komponenty te nie są dostępne jako oddzielna biblioteka, lecz stanowią integralną część tego środowiska. Chcąc je wykorzystać w innej aplikacji konieczne było zamknięcie ich w kontenerze 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 konieczne 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 wymaganymi wartościami stworzenie własnej klasy realizującej interfejs org.openide.loaders.dataobject reprezentującej obiekt z danymi w NetBeans stworzenie szkieletu obiektu reprezentującego pusty dokument procesu BPEL zarządzanie skomplikowanym cyklem życia obiektu reprezentującego model procesu BPEL Efektem tych działań jest kompletna biblioteka pozwalająca na przedstawianie procesu BPEL w efektownej formie graficznej. Komponent wizualizacyjny został zrealizowany jako obiekt rozszerzający znany ze środowiska Swing JPanel 1, co pozwala na jego proste użycie. Przykładowy kod realizujący wyświetlenie prostego procesu BPEL wygląda następująco: 1 org. javax.swing.jpanel 53

54 1 // i n i c j a l i z a c j a głównego o b i e k t u widoku 2 BPELVisualisationView view = 3 BPELVisualisationView. createviewwithemptymodel ( anydesign, 4 anyns ) ; 5 // pobranie r e f e r e n c j i do modelu procesu BPEL 6 BpelModel model = view. getbpelmodel ( ) ; 7 // pobranie r e f e r e n c j i do o b i e k t u budującego elementy procesu 8 BPELElementsBuilder b u i l d e r = model. g e t B u i l d e r ( ) ; 9 10 // zbudowanie s e k w e n c j i 11 Sequence sequence = b u i l d e r. createsequence ( ) ; 12 // u s t a w i e n i e s e k w e n c j i jako głównej aktywności procesu 13 model. g e t P r o c e s s ( ). s e t A c t i v i t y ( sequence ) ; // s t w o r z e n i e aktywności p r z y p i s a n i a zmiennej 16 Assign a s s i g n = b u i l d e r. c r e a t e A s s i g n ( ) ; 17 // dodanie aktywności do s e k w e n c j i 18 sequence. addactivity ( a s s i g n ) ; // poinformowanie o b i e k t u widoku o zmianach 21 view. commitchanges ( ) ; Przykładowy wynik działania, dla bardziej skomplikowanego przypadku jest przedstawiony na rysunku

55 Rysunek 4.5: Przykładowy wynik działania części wizualizacyjnej Rozszerzenia Z uwagi na zastosowanie biblioteki, została ona rozszerzona o dwie dodatkowe funkcjonalności możliwość etykietowania aktywności procesu BPEL - celem dodawania informacji odnośnie dokonanych pomiarów możliwość zmiany koloru połączeń między aktywnościami - celem ukazania 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 kod BPEL Designer. Biblioteka została przygotowana jako niezależna część i może z powodzeniem być wykorzystywana w innych rozwiązaniach. 55

56 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 zrealizowanych w architekturze SOA zgodnie z założeniami przedstawionymi w rozdziale 3 i 4. Aplikacja otrzymała roboczą nazwę BPEL Profiler, której autorzy 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 aplikacji w środowisku testowym zostało przedstawione w kolejnym rozdziale. 56

57 Rozdział 5 Testy W niniejszym rozdziale opisana została procedura testowania z użyciem narzędzia BPEL Profiler. Przedstawiono sposób konfiguracji sprzętu i oprogramowania środowiska testowego, oraz opisano aplikacje będące materiałem do testów. Rozdział zawiera również wyniki działania stworzonego narzędzia. 5.1 Testowane oprogramowanie Testy zostały przeprowadzone na przykładowych aplikacjach BPEL dostarczanych przez firmę Sun TM - BPEL Blueprints. Są to proste, wzorcowe rozwiązania problemów integracyjnych z użyciem języka BPEL[18]. Poniżej przedstawiono krótki opis każdego z nich. Aplikacja realizująca synchroniczne wywołanie usługi Jest to prosty proces realizujący integrację sklepu z magazynem. Graficzna prezentacja procesu 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ługa sklepu potwierdza lub odmawia złożenia zamówienia. Aplikacja realizująca asynchroniczne wywołanie usługi Proces realizujący taką samą funkcjonalność jak poprzedni. Różnią się one jedynie sposobem komunikacji z magazynem - w tym przypadku, wywołanie usługi magazynu jest jednokierunkowe. Następnie proces oczekuje na jedno ze zdarzeń z bloku EventBasedDecision - nadejście odpowiedzi lub upłynięcie limitu czasowego. Odpowiedź wysyłana do klienta jest zależna od tej odpowiedzi. Prezentacja graficzna procesu znajduje się na rysunku

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

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

60 Aplikacja realizująca synchroniczne wywołanie usługi z obsługą wyjątków Rozszerzenie pierwszego procesu o mechanizm obsługi wyjątków - proces początkowo sprawdza poprawność przychodzącego zamówienia, w wypadku błędu rzuca wyjątek. Drugim obsługiwanym wyjątkiem jest sygnalizowany przez magazyn brak zamawianego produktu. Graficzna prezentacja procesu znajduje się na rysunku 5.3. Aplikacja korelująca kilka wywołań Proces będący rozszerzeniem pierwszego wariantu, o możliwość potwierdzenia lub anulowania zamówienia. Po złożeniu zamówienia, aplikacja czeka na dalsze instrukcje, lub upłynięcie limitu czasowego, po czym podejmuje stosowne do zdarzenia akcje. Korelacja jest realizowana poprzez zawarcie w przesyłanych wiadomościach parametrów pozwalających na zidentyfikowanie instancji procesu dla którego przeznaczona jest dana wiadomość. Graficzna prezentacja procesu znajduje się na rysunku 5.4. Aplikacja realizująca równoległe asynchroniczne wywołanie kilku usług Proces realizujący wycinek funkcjonalności biura turystycznego, pozwalającego na jednoczesną rezerwację biletu lotniczego, hotelu i samochodu. Realizuje on równoległe wykonanie trzech asynchronicznych wywołań usług rezerwacji, których wynik jest zwracany do klienta. Reprezentacja graficzna procesu znajduje się na rysunku

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

62 Rysunek 5.4: Aplikacja korelująca kilka wywołań dotyczących tej samej instancji procesu 62

63 Rysunek 5.5: Aplikacja realizująca równoległe asynchroniczne wywołanie usług 63

64 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że zostać przeanalizowane w dwóch aspektach: Modyfikacja infrastruktury spowodowana wysyłaniem dodatkowych komunikatów z danymi o wydajności. Serwer JMS oraz konsola wizualizacyjna znajdują się zwykle na osobnej maszynie, celem zniwelowania ich wpływu na badane usługi. Stosowane łącza pomiędzy maszynami mają zwykle bardzo dużą przepustowość (np. 1 Gbps w izolowanym środowisku testowym) co przy małym rozmiarze komunikatów o wydajności powoduje, że wpływ dodatkowych komunikatów z danymi o wydajności na badane usługi jest pomijalny. Zbieranie dodatkowych danych o wydajności zaburza naturę badanych usług. Wybrany sposób instrumentacji i zbierania danych nie powoduje dużych narzutów czasowych. Proces wysyłania danych do kolejki JMS odbywa się asynchronicznie, co również nie zaburza wyników w znacznym stopniu. Zastosowany sposób zbierania danych nie ma znaczącego wpływu na badane usługi. Dokładne badania są trudne do przeprowadzenia z uwagi na brak porównywalnego narzędzia do badania wydajności usług opartych o paradygmat SOA. Weryfikacja wyników Weryfikacja zebranych wyników może zostać dokonana w dwóch aspektach: Zgodność pomiędzy oryginalnym modelem biznesowym a wygenerowanym modelem w konsoli wizualizacyjnej. Zgodność stwierdzana jest na podstawie wizualnego porównaniu obu modeli. 64

65 Poprawność zebranych danych (statystyk czasowych). Weryfikacja zebranych danych liczbowych jest trudna do przeprowadzenia, z powodu braku porównywalnych narzędzi do badania wydajności usług opartych o paradygmat SOA. Jedynym wyznacznikiem poprawności zebranych danych może być ich zgodność z wartościami szacunkowymi dla danego modelu (np. przy zastosowaniu konstrukcji WAIT z parametrem 2 sekundy, czas wykonania takiej aktywności powinien wynosić co najmniej 2 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 zainstalowano zinstrumentowane środowisko wykonawcze, i umieszczano na nim kolejne testowana aplikacje. Serwer JMS i konsola wizualizacyjna (na Serwrze 2) zostały odizolowane od środowiska wykonawczego, celem zminimalizowania 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 odizolowane, celem zniwelowania opóźnień i zakłoceń pracy ze strony innych komputerów. Konfiguracja oprogramowania Została zainstalowana standardowa dystrybucja OpenESB w wersji v2-ur2-b04-patch , uruchamiana na maszynie wirtualnej Java Konfiguracja sensora wydajności oraz konsoli wizualizacyjnej została wykonana zgodnie z instrukcjami zawartymi w dodatku A. 65

66 Rysunek 5.6: Diagram konfiguracji infrastruktury testowej 5.4 Dynamiczna prezentacja wyników Konsola wizualizacyjna nie posiada informacji o oryginalnym modelu badanego procesu biznesowego. Model w konsoli jest budowany w sposób dynamiczny, w miarę otrzymywania nowych informacji od sensora wydajności. Przykład działania mechanizmu dynamicznego budowania modelu procesu znajduje się na rysunku 5.7. Rysunek ilustruje badanie prostego procesu biznesowego, który składa się z wywołania operacji webservice (INVOKE) i ewentualnie obsłużenia rzuconego wyjątku. Na kolejnych fragmentach rysunku pokazono coraz bardziej uszczegółowiony model procesu, który coraz lepiej przybliża oryginalny model. 66

67 Rysunek 5.7: Dynamiczne budowanie modelu w trakcie zbierania danych 67

68 5.5 Wyniki testów Każda z aplikacji zaprezentowanych w rozdziale 5.1 została umieszczona w kontenerze. Procesy biznesowe oferowane przez aplikacje zostały kilkukrotnie wykonane (w miarę możliwości starano się pokazać różne ścieżki w procesach). Wizualna weryfikacja otrzymanych rysunków pozwala stwierdzić, że są one zgodne z oryginalnymi modelami procesów biznesowych przedstawionymi w rozdziale 5.1. Otrzymane wartości liczbowe są wartościami realistycznymi (brak konkurencyjnych narzędzi uniemożliwia przeprowadzenie testów porównawczych). Dodatkowo w celu ułatwienia interpretacji otrzymanych wyników, na rysunku 5.8 zamieszczono układ i oznaczenie elementów głównego okna konsoli wizualizacyjnej. Rysunek 5.8: Układ głównego okna aplikacji Zebrane dane zostały zaprezentowane na kolejnych stronach. Poniżej znajduje się krótki komentarz do każdego badanego procesu biznesowego. Aplikacja realizująca synchroniczne wywołanie usługi Na rysunku 5.9 przedstawiono zagregowany widok modelu procesu po siedmiokrotnym wykonaniu procesu biznesowego. Zagregowany widok modelu pokazuje informację uzyskaną ze wszystkich wykonań procesu, dlatego w instrukcji IF pokazane zostały obie możliwości wykonania (lewa gałąź wykonywana przy spełnieniu warunku z instrukcji IF, prawa gałąź w przeciwnym razie). Aplikacja realizująca asynchroniczne wywołanie usługi Rysunek 5.10 przedstawia fragment modelu demonstrujący użycie instrukcji IF. Analizu- 68

69 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ą wyjątków Rysunek 5.11 przedstawia proces realizacji błędnego zamówienia. Instrukcja IF (por. rysunek) odpowiada za zweryfikowanie typu zamówienia. Ponieważ użyty typ zamówienia był niepoprawny następuje przejście do instrukcji THROW, która generuje wyjątek typu CannotCompleteOrder (prawy dolny róg rysunku). Warto zauważyć, że ścieżka wychodząca z instrukcji THROW nie ma koloru oznaczającego aktywność (zielonego), ponieważ sterowanie wskutek wyjątku zostaje przeniesione bezpośrednio do bloku obsługi wyjątku CATCH. Obsługa wyjątku poprzez instrukcję REPLY ustawia odpowiedni rezultat procesu biznesowego informujący o nieprawidłowym zamówieniu. Rysunek 5.12 przedstawia proces realizacji zamówienia niedostępnego w magazynie. Typ zamówienia został pozytywnie zweryfikowany z użyciem instrukcji warunkowej IF. Sterowanie zostało następnie przekazane do instrukcji INVOKE, która wykonuje operacje webservice odpowiadającą za sprawdzenie stanu magazynowego pod kątem złożonego zamówienia. Ponieważ w magazynie brakuje zamawianych towarów, wywołanie operacji kończy się wyjątkiem InventoryFaultType (prawy dolny róg rysunku). Przykładowe statystyki wykonania operacji INVOKE pokazano na rysunku W drugim wierszu można zauważyć niepoprawne zakończenie operacji INVOKE wskutek wystąpienia wyjątku InventoryFaultType (wyjątek ten oznaczał brak zamawianych towarów w magazynie). Aplikacja korelująca kilka wywołań Rysunek 5.14 przedstawia fragment modelu demonstrujący użycie instrukcji PICK. Analizując ścieżkę wykonania można zauważyć, że proces po napotkaniu instrukcji PICK zatrzymał się w oczekiwaniu na dowolny z dwóch typów komunikatów (obszary OnMessage). Funkcjonalność ta jest wykorzystywana do zrealizowania możliwości anulowania lub potwierdzania złożonego zamówienia. Po otrzymaniu komunikatu z potwierdzeniem zamówienia nastąpiło dalsze wykonanie procesu. Aplikacja realizująca równoległe asynchroniczne wywołanie kilku usług Rysunek 5.15 przedstawia wykonywanie równoległej rezerwacji biletu 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

70 Rysunek 5.9: Aplikacja realizująca synchroniczne wywołanie usług (por. rysunek 5.1). 70

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

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

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

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

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

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

77 Wykazano przydatność stworzonego narzędzia w pomiarach wydajności aplikacji o architekturze SOA. Oprogramowanie działało poprawnie - prezentowane 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

78 Rozdział 6 Wnioski z pracy i możliwości dalszego rozwoju systemu SOA to wciąż innowacyjny paradygmat tworzenia oprogramowania. Już teraz można jednak zaobserwować tendencję do zwiększania się jego udziału wśród aktualnie dominujących technologii IT. Coraz więcej systemów opartych jest o paradygmat SOA, co przynosi wymierne korzyści w postaci np. luźnych powiązań pomiędzy usługami, ich ułatwionej integracji oraz konieczności stosowania kontraktów. Badanie wydajności usług realizujących procesy biznesowe z użyciem języka BPEL jest bardzo przydatne, ponieważ pozwala m.in. znaleźć słabe punkty tworzonej aplikacji (ang. bottlenecks), analizować zachowanie się konkretnych wywołań procesów biznesowych oraz wyszukiwać błędy i niepoprawnie działające procesy. Autorom niniejszej pracy w trakcie jej tworzenia nie udało się znaleźć aplikacji wspierających takie badania oraz spełniających jednocześnie zbiór wymagań zawartych w rozdziale 3.1. Autorzy zaproponowali modularną architekturę aplikacji pozwalającą analizować procesy biznesowe zachodzące w dowolnym kontenerze aplikacji oraz obrazować je w czytelny sposób z użyciem centralnej konsoli wizualizacyjnej. W ramach pracy autorzy zapoznali się z możliwościami technologii wspomagających budowanie aplikacji o architekturze SOA. Pogłębiona została wiedza na temat języka BPEL i rozwiązań realizujących koncepcję ESB. Wyniki analizy możliwości oprogramowania wspierającego tworzenie rozwiązań o architekturze SOA, zostały wykorzystane do wybrania przykładowego, testowanego środowiska. Postawione zostały wymagania jakie powinien spełniać system badania wydajności, ze szczególnym naciskiem na sposób umieszczenia sensora w obrębie środowiska wykonawczego. Za zbioru rozważanych koncepcji, do implementacji wybrano najlepiej pasującą w kontekście postawionych wymagań. Stworzone zostało zarówno narzędzie do automatycznej instrumentacji 78

79 środowiska wykonawczego, jak i obserwacji otrzymywanych parametrów wydajnościowych aplikacji. Zostało ono wzbogacone o możliwość przedstawiania wynikó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 typowe przypadki użycia w aplikacjach opartych o język BPEL. Przypadki te były podstawą do przeprowadzenia procedur testowych, oraz źródłem zamieszczonych w pracy wyników. 6.1 Możliwości zastosowania stworzonego oprogramowania Stworzone oprogramowanie w pełni spełnia postawione w pracy wymagania. Narzędzie pozwala na wykonanie pomiarów działającej aplikacji, bez znacznej ingerencji w środowisko wykonawcze. Dostarczane statystyki są zbierane w locie z dowolnej liczby kontenerów i wysyłane w ogólnie znanym formacie do serwera JMS, dzięki czemu możliwa jest ich jednoczesna analiza w kilku lokalizacjach. Narzędzie wizualizacyjne pozwala na prezentację wyników analizy w trakcie działania aplikacji, pozwalając jednocześnie na szybkie odnalezienie wąskich gardeł systemów. Zbierane statystyki można poddawać dalszej obróbce, celem dalszej agregacji, tworzeniu wykresów itp. Z uwagi na niski narzut czasowy wprowadzany instrumentacją środowiska wykonawczego, narzędzie może być z powodzeniem stosowane w działających aplikacjach m.in. do śledzenia częstości przejść poszczególnych ścieżek w procesie biznesowym. Dzięki intuicyjnemu interfejsowi użytkownika, narzędzie może być używane nawet przez programistów o niewielkiej wiedzy w dziedzinie problemu. Nieskomplikowana forma prezentacji graficznej wyników pomiarów, pozwala na przedstawianie ich osobom nie posiadającym szczegółowej wiedzy technicznej. 6.2 Dalszy rozwój systemu Zrealizowana aplikacja ma służyć jako przykładowe rozwiązanie problemu badania wydajności usług zgodnych z paradygmatem SOA. Aplikacja nie powinna być więc traktowana jako kompletny program, lecz jako punkt wyjścia do dalszych prac i udoskonaleń. 79

80 Zwiększenie ilości obsługiwanych implementacji Aplikacja została wyposażona w reguły instrumentacji kontenerów OpenESB. Ponieważ sama aplikacja ma jedynie demonstrować sposób badania wydajności, więc ograniczenie wbudowanej obsługi kontenerów tylko do OpenESB nie ma wpływu na 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ę wstrzykującą kod (por. rozdział 4.1.1). Biblioteka ta zapewnia podstawowy zestaw adnotacji dla pisania reguł (np. wykonaj podany kod przed startem określonej metody). Zestaw ten może być poszerzony w przypadku braku odpowiedniej adnotacji. W szczególnych przypadkach istnieje możliwość wymiany całego silnika instrumentującego kod, bez zmiany pozostałej części systemu (konsoli, sensorów, formatu wiadomości JMS itp). Kolejnym etapem pracy nad aplikacją powinno być napisanie reguł instrumentacji dla najpopularniejszych kontenerów obecnych na rynku. W przypadku używania platformy OSGi[2] (system modułów dla języka Java) bezpośrednie wsparcie dla języka BPEL będzie umożliwiała nowa wersja serwera GlassFish 3.0[67]. Ponieważ reguły instrumentacji OpenESB są już utworzone, mamy możliwość badania i analizowania wydajności usług zrealizowanych z użyciem języka BPEL w dowolnym środowisku OSGi. Rozszerzenie możliwości wizualizacyjnych konsoli Obecnie konsola wizualizacyjna jest w stanie przedstawić badany proces w postaci diagramu BPEL. Posiada również możliwość wyświetlania informacji statystycznych (np. statystyki czasowe czyli minimalny, średni i maksymalny czas trwania aktywności) o dowolnym elemencie procesu. Otrzymywane od sensorów dane pozwalają jednak na prezentację większej ilości informacji. Pozwalają one np. na wykreślanie diagramów Gantta[43] zachodzącego procesu. Obrazuje on podział procesu na poszczególne zadania oraz rozmieszczenie ich w czasie. Dodatkowo obecną wersję aplikacji można rozszerzyć o możliwość rysowania wykresów (np. koszt wywołania operacji webservice w czasie). Integracja prezentacji wyników z modułem NetBeans BPEL Designer Środowisko programowania NetBeans udostępnia wbudowany moduł BPEL Designer umożliwiający graficzną edycję i modelowanie procesów BPEL. Fragmenty tego modułu zostały użyte w stworzonej przez autorów aplikacji do prezentowania procesu BPEL w konsoli wizualizacyjnej. Docelowo należałoby również zrealizować integrację w drugą stronę, czyli wbudować w edytor Netbeans BPEL Designer możliwości konsoli wizualizacyjnej procesów BPEL. Posiadanie danych o wydajności budowanego procesu bez- 80

81 pośrednio w edytorze, usprawniłoby modelowanie procesów, oraz umożliwiło efektywniejsze i szybsze poprawianie błędów w ich modelach. Niniejsza praca magisterska wpisuje się w aktualne światowe trendy tworzenia aplikacji opartych o usługi i stara się wypełnić lukę w badaniu ich wydajności. Stworzone oprogramowanie stanowi solidne narzędzie niezbędne do produkcyjnego zastosowania procedur biznesowych implementowanych w oparciu o język BPEL. Mnogość postawionych w pracy problemów oraz możliwości rozwoju stworzonego oprogramowania, świadczy o szerokim spektrum możliwych kontynuacji badań w tej dziedzinie. 81

82 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

83 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

84 Rozdział 8 Bibliografia [1] Binildas C. A. Service Oriented Java Business Integration. Packt Publishing, [2] OSGi Alliance. Strona domowa OSGi. [3] BEA. Strona domowa BEA Aqualogic ESB. /products /aqualogic/service bus/. [4] Dave Chapell. Enterprise Service Bus. O Reilly, [5] Thomas Erl. 5 największych zagrożeń SOA, tip/0,289483,sid26 gci ,00.html. [6] Organization for the Advancement of Structured Information Standards. BPEL OASIS Specification. [7] Organization for the Advancement of Structured Information Standards. Strona domowa organizacji OASIS. [8] Object Management Group. CORBA Notification Service. corbaservices spec catalog.htm. [9] Open Group. Service Oriented Architecture definition. 84

85 [10] IBM. Strona domowa IBM Websphere. [11] Matjaz B. Juric. BPEL and Java. /BPELJava/article.html. [12] Matjaz B. Juric. Business Process Execution Language for Web Services, Second Edition. Packt Publishing, [13] Microsoft. MSMQ. /technologies/msmq/default.mspx. [14] Microsoft. UDDI Business Registry Shutdown FAQ. [15] Sun Microsystems. JMS API. [16] SUN Microsystems. Lokalizacja klas systemowych maszyny wirtualnej Java. /findingclasses.html#bootclass. [17] Sun Microsystems TM. Service Provider Interface w JNDI. [18] Sun Microsystems TM. Sun s BPEL Blueprints. https://blueprints.dev.java.net/bpcatalog/ee5/soa/. [19] W3C Organization. W3C. [20] W3C Organization. W3C SOAP. [21] W3C Organization. W3C SOAP RPC. [22] W3C Organization. W3C Webservice. [23] W3C Organization. WSDL 2.0 Specification. [24] Sang Shin. SUN TECH DAYS, A Developer Conference

86 [25] IBM Polska sp. z o.o. Projektowanie Modeli Usług dla rozwiązań typu SOA. GBS SOMA offering.pdf. [26] Ralf Suderbücher. My thought was, this change has to be compared to the switch from Newtonian physics to relativistic physics. - [27] Darryl K. Taft. Enterprise SOA Adoption to Double in Next Two Years. Enterprise-SOA-Adoption- to-double-in-next-two-years/. [28] Ron Ten-Hove. JBI Components (Theory). https://openesb.dev.java.net/public/pdf/jbi-components-theory.pdf. [29] Frank Yellin Tim Lindholm. Specyfikacja maszyny wirtualnej Java. edition /html/vmspectoc.doc.html. [30] Gamma Helm Johnson Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Pearson, [31] W3C. Specyfikacja XPATH. [32] Wikipedia. Koncepcja sandbox. (computer security). [33] Wikipedia. Programowanie aspektowe. programming. [34] Yuli Vasiliev. SOA and WS-BPEL. Packt Publishing, [35] Praca zbiorowa. ACID w Polskiej Wikipedii. [36] Praca zbiorowa. ActiveBPEL Engine. [37] Praca zbiorowa. Apache ODE. [38] Praca zbiorowa. Biblioteka Apache Commons. [39] Praca zbiorowa. BPEL4WS 1.1 Specification ibm.com/developerworks/library/specification/ws-bpel/. 86

87 [40] Praca zbiorowa. BPELSE Event Dispatching and Listener Framework. [41] Praca zbiorowa. Business Process Execution Language. [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. Gantta. [44] Praca zbiorowa. IBM Websphere Studio Application Developer Integration Edition. [45] Praca zbiorowa. ICEStorm. [46] Praca zbiorowa. JSR java business integration. [47] Praca zbiorowa. Microsoft BizTalk. [48] Praca zbiorowa. Netbeans BPEL Designer. [49] Praca zbiorowa. Oracle BPEL Designer for Eclipse. [50] Praca zbiorowa. Oracle BPEL Process Manager. [51] Praca zbiorowa. Service Oriented Architectures part 1. cd= [52] Praca zbiorowa. SOA Wikipedia. architecture #Service contract. [53] Praca zbiorowa. Strona domowa AspectJ. [54] Praca zbiorowa. Strona domowa AspectWerkz. 87

88 [55] Praca zbiorowa. Strona domowa Code Generation Library. [56] Praca zbiorowa. Strona domowa JBoss ESB. [57] Praca zbiorowa. Strona domowa MULE ESB. [58] Praca zbiorowa. Strona domowa ObjectWeb PEtALS. [59] Praca zbiorowa. Strona domowa OpenESB. https://open-esb.dev.java.net/. [60] Praca zbiorowa. Strona domowa ServiceMix. [61] Praca zbiorowa. Strona domowa SONIC ESB. esb. [62] Praca zbiorowa. Tryby instrumentacji w AspectWerkz. [63] Praca zbiorowa. UDDI. [64] Praca zbiorowa. WS-BPEL 2.0 Specification. [65] Praca zbiorowa. WS-Events. [66] Praca zbiorowa. WS-Notifications. [67] Praca zbiorowa. Założenia projektu GlassFish w wersji [68] Praca zbiorowa OMG. BPM Specification. 88

89 Rozdział 9 Spis rysunków 1.1 Ewolucja architektur oprogramowania [25] Zmiana w podejściu do projektowaniu oprogramowania Schemat integracji 4 podsystemów (każdy-z-każdym) Przykładowy schemat funkcjonowania aplikacji opartej o SOA Przykład funkcjonowania aplikacji opartej o usługi webservice Postać wiadomości SOAP z załącznikami [24] Schemat wykorzystania UDDI [24] Zasada działania ESB [1] Zasada działania MOM Zasada działania EAI [4] ESB jako pochodna EAI i MOM Nomenklatura JBI[28] Orchiestracja Choreografia Elementy konstrukcyjne języka BPEL Pakiet Netbeans - wizualny edytor procesu BPEL Architektura używana do badania wydajności aplikacji Schemat wywołania usługi webservice w OpenESB Koncepcja rozwiązania w oparciu o interfejs monitorowania silnika BPEL Koncepcja rozwiązania z użyciem HULP Koncepcja rozwiązania z użyciem BPEL SE Events Listener Koncepcja instrumentacji kodu BPEL aplikacji Koncepcja instrumentacji środowiska wykonania Przykład użycia biblioteki instrumentującej kod

90 4.2 Postać komunikatu z danymi o wydajności w postaci diagramu klas UML Przepływ komunikatów z danymi o wydajności Emulacja środowiska NetBeans 6.0 w bibliotece wizualizacyjnej Przykładowy wynik działania części wizualizacyjnej Fragment wizualizacji procesu BPEL wykorzystujący zmianę koloru danego połączenia w celu pokazania częstości jego użycia Aplikacja realizująca synchroniczne wywołanie usługi Aplikacja realizująca asynchroniczne wywołanie usługi Aplikacja realizująca obsługę wyjątków rzucanych z procesu oraz wykorzystywanych usług Aplikacja korelująca kilka wywołań dotyczących tej samej instancji procesu Aplikacja realizująca równoległe asynchroniczne wywołanie usług Diagram konfiguracji infrastruktury testowej Dynamiczne budowanie modelu w trakcie zbierania danych Układ głównego okna aplikacji Aplikacja realizująca synchroniczne wywołanie usług (por. rysunek 5.1) Aplikacja realizująca asynchroniczne wywołanie usługi (por. rysunek 5.2) Aplikacja realizująca synchroniczne wywołanie usługi z obsługą wyjątków (por. rysunek 5.3) Aplikacja realizująca synchroniczne wywołanie usługi z obsługą wyjątków (por. rysunek 5.3) Szczegóły działania aktywności INVOKE z rysunku Aplikacja korelująca kilka wywołań (por. rysunek 5.4) Aplikacja realizująca równoległe asynchroniczne wywołanie kilku usług (por. rysunek 5.5) A.1 Konfiguracja konsoli A.2 Szczegółowe informacje o wywołaniach A.3 Układ głównego okna aplikacji

91 Dodatek A Podręcznik użytkownika W niniejszym dodatku przedstawiony został krótki opis konfiguracji oraz obsługi aplikacji. Opis został przygotowany do użycia w systemach z rodziny Linux, jednak w analogiczny sposób przebiega konfiguracja i obsługa aplikacji w systemie Windows. Aplikacja została napisana i przetestowana w środowisku maszyny wirtualnej Java Pierwszym krokiem który należy wykonać przed użytkowaniem niniejszej aplikacji jest odpowiednie zinstrumentowanie bibliotek kontenera oraz konfiguracja aplikacji. A.1 Instrumentacja bibliotek kontenera oraz konfiguracja 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 katalogu /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

92 Na komputerze host1 powinien zostać uruchomiony serwer JMS. Służy on do przesyłania wiadomości pomiędzy sensorami wydajności oraz konsolą. Adres IP komputera host1 powinien być widoczny dla konsoli oraz wszystkich komputerów na których zostaną umieszczone kontenery usług. Należy pamiętać o ustawieniu w polu ServerConfiguration adresu IP komputera host1 w pliku openjms.xml z katalogu openjms/config. Serwer JMS uruchamiany jest skryptem startup.sh z katalogu openjms/bin. 2. Instrumentacja bibliotek serwera Krok opcjonalny - wykonywany jedynie w przypadku zmiany adresu serwera JMS (lub przy pierwszym użyciu). Z używanego kontenera GlassFish 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 konfiguracją instrumentacji. W polu JMS provider URL należy wpisać adres uruchomionego serwera JMS w postaci: rmi://host1:1099. Następnie należy wybrać operację Instrument. Spowoduje to pojawienie się okna wyboru pliku źródłowego do instrumentacji, w którym należy wybrać oryginalny plik bpelcore.jar. W kolejnym oknie dialogowym należy podać nazwę pliku docelowego (np. bpelcore2.jar w tym samym katalogu co bpelcore.jar). Następnie zostanie wykonana instrumentacja i wygenerowany komunikat o jej rezultacie. Na końcu należy podmienić zinstrumentowany plik bpelcore.jar we wszystkich używanych kontenerach GlassFish: [host2] ~/app$ cp bpelcore2.jar /opt/glassfish/domains/\ domain1/jbi/components/sun-bpel-engine/\ install_root/lib/bpelcore.jar 3. Uruchomienie konsoli 92

93 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 uruchomionego serwera JMS w postaci rmi://host1:1099 w polu JMS provider URL. Po wybraniu przycisku Run visualisation konsola zostanie uruchomiona i przygotowana do analizowania zbieranych danych o wydajności usług. 4. Uruchomienie kontenerów i usług Należy uruchomić zinstrumentowane kontenery GlassFish wraz z aplikacjami. W trakcie wykonywania operacji na usługach przechowywanych w kontenerach można obserwować zbierane dane wydajnościowe na konsoli wizualizacyjnej. A.2 Sposób wizualizacji danych wydajnościowych Główne okno aplikacji (przedstawione na rysunku A.3) składa się z nastepują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

94 Wybrany proces - informacje o wybranym procesie (m.in. identyfikator procesu, czas trwania) Elementy modelu - graf elementów modelu, dowolny element może zostać 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 o każdym pojedyńczym wywołaniu (por.rysunek A.2). Tryb ścieżek - tryb rysowania scieżek pomiędzy elementami (umożliwia np. kolorowanie scieżek według intensywności ich użycia) Rysunek A.2: Szczegółowe informacje o wywołaniach 94

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

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

Bardziej szczegółowo

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Narzędzia i aplikacje Java EE Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Niniejsze opracowanie wprowadza w technologię usług sieciowych i implementację usługi na platformie Java EE (JAX-WS) z

Bardziej szczegółowo

Web Services. Wojciech Mazur. 17 marca 2009. Politechnika Wrocławska Wydział Informatyki i Zarządzania

Web Services. Wojciech Mazur. 17 marca 2009. Politechnika Wrocławska Wydział Informatyki i Zarządzania Standardy w Rodzaje Przykłady Politechnika Wrocławska Wydział Informatyki i Zarządzania 17 marca 2009 Standardy w Rodzaje Przykłady Plan prezentacji 1 Wstęp 2 Standardy w 3 4 Rodzaje 5 Przykłady 6 Standardy

Bardziej szczegółowo

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI Instrukcja użytkownika Narzędzie do modelowania procesów BPEL Warszawa, lipiec 2009 r. UNIA EUROPEJSKA EUROPEJSKI FUNDUSZ

Bardziej szczegółowo

Zaawansowane narzędzia programowania rozproszonego

Zaawansowane narzędzia programowania rozproszonego Zaawansowane narzędzia programowania rozproszonego Karol Gołąb karol.golab@tls-technologies.com 28 listopada 2001 1 Streszczenie Omówienie i porównanie popularnych standardów mechanizmów komunikacyjnych:

Bardziej szczegółowo

Web Services. Bartłomiej Świercz. Łódź, 2 grudnia 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz Web Services

Web Services. Bartłomiej Świercz. Łódź, 2 grudnia 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz Web Services Web Services Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź, 2 grudnia 2005 roku Wstęp Oprogramowanie napisane w różnych językach i uruchomione na różnych platformach może wykorzystać

Bardziej szczegółowo

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz Część I -ebxml Po zrealizowaniu materiału student będzie w stanie omówić potrzeby rynku B2B w zakresie przeprowadzania transakcji przez Internet zaprezentować architekturę ebxml wskazać na wady i zalety

Bardziej szczegółowo

SIMON SAYS ARCHITECTURE! Usługi zdalne. Technologie, techniki i praktyki implementacji

SIMON SAYS ARCHITECTURE! Usługi zdalne. Technologie, techniki i praktyki implementacji SIMON SAYS ARCHITECTURE! Usługi zdalne Technologie, techniki i praktyki implementacji O mnie Bloguję: SIMON-SAYS-ARCHITECTURE.COM Twittuję: www.twitter.com/szymonpobiega Koduję: DDDSample.Net, NetMX, WS-Man.Net

Bardziej szczegółowo

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1 Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących

Bardziej szczegółowo

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7 I Wprowadzenie (wersja 0906) Kurs OPC S7 Spis treści Dzień 1 I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami automatyki I-6 Cechy podejścia dedykowanego

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Analiza i projektowanie aplikacji Java

Analiza i projektowanie aplikacji Java Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

1 Wprowadzenie do J2EE

1 Wprowadzenie do J2EE Wprowadzenie do J2EE 1 Plan prezentacji 2 Wprowadzenie do Java 2 Enterprise Edition Aplikacje J2EE Serwer aplikacji J2EE Główne cele V Szkoły PLOUG - nowe podejścia do konstrukcji aplikacji J2EE Java 2

Bardziej szczegółowo

Systemy obiegu informacji i Protokół SWAP "CC"

Systemy obiegu informacji i Protokół SWAP CC Systemy obiegu informacji i Protokół SWAP Grzegorz Blinowski "CC" Grzegorz.Blinowski@cc.com.pl http://www.cc.com.pl/ tel (22) 646-68-73; faks (22) 606-37-80 Problemy Integracja procesów zachodzących w

Bardziej szczegółowo

Wymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum

Wymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum Wymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Systemy CMS (Content

Bardziej szczegółowo

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Małgorzata Barańska Wydział Informatyki i Zarządzania, Politechnika Wrocławska Beata Laszkiewicz Wydział

Bardziej szczegółowo

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna

Bardziej szczegółowo

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Programowanie obiektowe Wykład 13 Marcin Młotkowski 27 maja 2015 Plan wykładu Trwałość obiektów 1 Trwałość obiektów 2 Marcin Młotkowski Programowanie obiektowe 2 / 29 Trwałość (persistence) Definicja Cecha

Bardziej szczegółowo

Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g

Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g Opis szkolenia: Termin SOA, czyli Service Oriented Architecture, oznacza architekturę systemów informatycznych opartą o usługi. Za

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

Usługi sieciowe (Web Services)

Usługi sieciowe (Web Services) Usługi sieciowe (Web Services) Karol Kański Seminarium Systemy Rozproszone 14 października 2010 Agenda 1. Idea i historia usług sieciowych 2. Różne podejścia do tworzenia usług sieciowych 3. Języki opisu

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

Wprowadzenie do technologii Web Services: SOAP, WSDL i UDDI

Wprowadzenie do technologii Web Services: SOAP, WSDL i UDDI Wprowadzenie do technologii Web Services: SOAP, WSDL i UDDI Maciej Zakrzewicz PLOUG mzakrz@cs.put.poznan.pl Plan prezentacji Wprowadzenie do architektury zorientowanej na usługi Charakterystyka technologii

Bardziej szczegółowo

Instytut Technik Innowacyjnych Semantyczna integracja danych - metody, technologie, przykłady, wyzwania

Instytut Technik Innowacyjnych Semantyczna integracja danych - metody, technologie, przykłady, wyzwania Instytut Technik Innowacyjnych Semantyczna integracja danych - metody, technologie, przykłady, wyzwania Michał Socha, Wojciech Górka Integracja danych Prosty export/import Integracja 1:1 łączenie baz danych

Bardziej szczegółowo

Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje w roku akademickim 2011/2012. Architektura zorientowana na usługi

Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje w roku akademickim 2011/2012. Architektura zorientowana na usługi Politechnika Krakowska im. Tadeusza Kościuszki Karta przedmiotu Wydział Fizyki, Matematyki i Informatyki obowiązuje w roku akademickim 2011/2012 Kierunek studiów: Informatyka Forma studiów: Stacjonarne

Bardziej szczegółowo

System zarządzający grami programistycznymi Meridius

System zarządzający grami programistycznymi Meridius System zarządzający grami programistycznymi Meridius Instytut Informatyki, Uniwersytet Wrocławski 20 września 2011 Promotor: prof. Krzysztof Loryś Gry komputerowe a programistyczne Gry komputerowe Z punktu

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy aplikacji zgodnych z J2EE Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

Część I Dostęp do danych oraz moŝliwości programowe (silnik bazy danych)

Część I Dostęp do danych oraz moŝliwości programowe (silnik bazy danych) Spis treści Wstęp... xi Część I Dostęp do danych oraz moŝliwości programowe (silnik bazy danych) 1 Program SQL Server Management Studio oraz język Transact SQL... 3 Omówienie programu SQL Server Management

Bardziej szczegółowo

Web Services. Technologie Biznesu Elektronicznego. Konrad Kunicki. Politechnika Wrocławska, Wydział Informatyki i Zarządzania

Web Services. Technologie Biznesu Elektronicznego. Konrad Kunicki. Politechnika Wrocławska, Wydział Informatyki i Zarządzania Standardy Technologie Biznesu Elektronicznego Politechnika Wrocławska, Wydział Informatyki i Zarządzania Wrocław, 26 kwiecień 2005 Standardy Plan prezentacji 1 Wprowadzenie 2 Standardy 3 4 5 Standardy

Bardziej szczegółowo

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone Typy przetwarzania Przetwarzanie zcentralizowane Systemy typu mainfame Przetwarzanie rozproszone Architektura klient serwer Architektura jednowarstwowa Architektura dwuwarstwowa Architektura trójwarstwowa

Bardziej szczegółowo

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE]

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] Parę słów o mnie 2 Nauczyciel akademicki od 2000 roku Od 2002 współpracuję z firmami jako programista i projektant aplikacji Od 2006 roku właściciel firmy

Bardziej szczegółowo

Dostęp do komponentów EJB przez usługi Web Services

Dostęp do komponentów EJB przez usługi Web Services 243 Dostęp do komponentów EJB przez usługi Web Services Mikołaj Morzy Mikolaj.Morzy@cs.put.poznan.pl http://www.cs.put.poznan.pl/mmorzy/ Plan rozdziału 244 Wprowadzenie do usług sieciowych Architektura

Bardziej szczegółowo

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia ZP/ITS/11/2012 Załącznik nr 1a do SIWZ ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia Przedmiotem zamówienia jest: Przygotowanie zajęć dydaktycznych w postaci kursów e-learningowych przeznaczonych

Bardziej szczegółowo

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK

Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK Paweł Lenkiewicz Polsko Japońska Wyższa Szkoła Technik Komputerowych Plan prezentacji PJWSTK

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

Simple Object Access Protocol

Simple Object Access Protocol Simple Object Access Protocol Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź, 11 grudnia 2005 roku Czym jest SOAP? Akronim SOAP oznacza Simple Object Access Protocol. SOAP jest

Bardziej szczegółowo

Zintegrowany System Informatyczny (ZSI)

Zintegrowany System Informatyczny (ZSI) Zintegrowany System Informatyczny (ZSI) ZSI MARKETING Modułowo zorganizowany system informatyczny, obsługujący wszystkie sfery działalności przedsiębiorstwa PLANOWANIE ZAOPATRZENIE TECHNICZNE PRZYGOTOWANIE

Bardziej szczegółowo

Zaawansowane aplikacje internetowe. Wykład 7. Implementacja procesów biznesowych w języku BPEL. wykład prowadzi: Maciej Zakrzewicz BPEL.

Zaawansowane aplikacje internetowe. Wykład 7. Implementacja procesów biznesowych w języku BPEL. wykład prowadzi: Maciej Zakrzewicz BPEL. Wykład 7 Implementacja procesów biznesowych w języku BPEL wykład prowadzi: Maciej Zakrzewicz BPEL Wymagania: 1 Plan wykładu Wprowadzenie do języka BPEL Definicja procesów BPEL z użyciem narzędzia Oracle

Bardziej szczegółowo

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

INFORMATYKA Pytania ogólne na egzamin dyplomowy

INFORMATYKA Pytania ogólne na egzamin dyplomowy INFORMATYKA Pytania ogólne na egzamin dyplomowy 1. Wyjaśnić pojęcia problem, algorytm. 2. Podać definicję złożoności czasowej. 3. Podać definicję złożoności pamięciowej. 4. Typy danych w języku C. 5. Instrukcja

Bardziej szczegółowo

Szczegółowy opis przedmiotu zamówienia

Szczegółowy opis przedmiotu zamówienia Załącznik nr 2 do Zapytania Ofertowego nr 07/04/IT/2016 Szczegółowy opis przedmiotu zamówienia Utrzymanie i rozwój systemów GREX, SPIN, TK, AMOC, Obsługa Rewidentów 1 SPIS TREŚCI Wprowadzenie... 3 1. Specyfikacja

Bardziej szczegółowo

4 Web Forms i ASP.NET...149 Web Forms...150 Programowanie Web Forms...150 Możliwości Web Forms...151 Przetwarzanie Web Forms...152

4 Web Forms i ASP.NET...149 Web Forms...150 Programowanie Web Forms...150 Możliwości Web Forms...151 Przetwarzanie Web Forms...152 Wstęp...xv 1 Rozpoczynamy...1 Co to jest ASP.NET?...3 W jaki sposób ASP.NET pasuje do.net Framework...4 Co to jest.net Framework?...4 Czym są Active Server Pages (ASP)?...5 Ustawienia dla ASP.NET...7 Systemy

Bardziej szczegółowo

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski 26.05.2011

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski 26.05.2011 Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF Tomasz Turski 26.05.2011 Plan prezentacji Architektura korporacyjna Frameworki Pryncypia Metodyka TOGAF

Bardziej szczegółowo

Java Developers Day. Implementacja ESB przy użyciu Mule. ESB Mule Obsługa zamówień DEMO

Java Developers Day. Implementacja ESB przy użyciu Mule. ESB Mule Obsługa zamówień DEMO Java Developers Day Implementacja ESB przy użyciu Mule Michał Majcher michal.majcher@altkom.pl Łukasz Krawczyk lukasz.krawczyk@altkom.pl slide 1 Tematy ESB Mule Obsługa zamówień DEMO Opis problemu Przepływ

Bardziej szczegółowo

Część I Rozpoczęcie pracy z usługami Reporting Services

Część I Rozpoczęcie pracy z usługami Reporting Services Spis treści Podziękowania... xi Wprowadzenie... xiii Część I Rozpoczęcie pracy z usługami Reporting Services 1 Wprowadzenie do usług Reporting Services... 3 Platforma raportowania... 3 Cykl życia raportu...

Bardziej szczegółowo

OSGi Agata Hejmej 4.05.2009

OSGi Agata Hejmej 4.05.2009 OSGi Agata Hejmej 4.05.2009 Plan prezentacji Co to jest OSGi Jakie problemy rozwiązuje Opis standardu Przykładowa aplikacja Podsumowanie korzyści Co to jest OSGi? Standard, który pozwala na tworzenie wysoce

Bardziej szczegółowo

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci UNIX: architektura i implementacja mechanizmów bezpieczeństwa Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci Plan prezentacji: Wprowadzenie do struktury systemów rodziny UNIX

Bardziej szczegółowo

Virtual Grid Resource Management System with Virtualization Technology

Virtual Grid Resource Management System with Virtualization Technology Virtual Grid Resource Management System with Virtualization Technology System zarządzania zasobami wirtualnego Gridu z wykorzystaniem technik wirtualizacji Joanna Kosińska Jacek Kosiński Krzysztof Zieliński

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski. Bazy danych ITA-101. Wersja 1

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski. Bazy danych ITA-101. Wersja 1 Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski Bazy danych ITA-101 Wersja 1 Warszawa, wrzesień 2009 Wprowadzenie Informacje o kursie Opis kursu We współczesnej informatyce coraz większą

Bardziej szczegółowo

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4 Procesy biznesowe w praktyce Przykłady użycia z wykorzystaniem jbpm 4.4 1 Agenda Definicja i zastosowanie procesu biznesowego Języki dziedzinowe (DSL) a rozwiązania BPM JBPM: jbpm 4.4 krótka charakterystyka

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo

InPro BMS InPro BMS SIEMENS

InPro BMS InPro BMS SIEMENS InPro Siemens OPC InPro BMS Produkt InPro BMS jest w sprzedaży od 2000 roku. W ostatnich kilku latach staliśmy się liderem wśród dostawców informatycznych rozwiązań dla systemów bezpieczeństwa. Oferowane

Bardziej szczegółowo

Istnieje możliwość prezentacji systemu informatycznego MonZa w siedzibie Państwa firmy.

Istnieje możliwość prezentacji systemu informatycznego MonZa w siedzibie Państwa firmy. system informatyczny wspomagający monitorowanie i planowanie zapasów w przedsiębiorstwie System informatyczny MonZa do wspomagania decyzji managerskich w obszarze zarządzania zapasami jest odpowiedzią

Bardziej szczegółowo

Zaawansowane aplikacje internetowe. Wykład 6. Wprowadzenie do Web Services. wykład prowadzi: Maciej Zakrzewicz. Web Services

Zaawansowane aplikacje internetowe. Wykład 6. Wprowadzenie do Web Services. wykład prowadzi: Maciej Zakrzewicz. Web Services Wykład 6 Wprowadzenie do Web Services wykład prowadzi: Maciej Zakrzewicz Web Services 1 Plan wykładu Wprowadzenie do technologii Web Services Architektura Web Services Protokół komunikacyjny SOAP Język

Bardziej szczegółowo

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU Projekt Rozwój elektronicznej administracji w samorządach województwa mazowieckiego wspomagającej niwelowanie dwudzielności potencjału województwa ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO

Bardziej szczegółowo

Tworzenie i obsługa wirtualnego laboratorium komputerowego

Tworzenie i obsługa wirtualnego laboratorium komputerowego Uniwersytet Mikołaja Kopernika Wydział Fizyki, Astronomii i Informatyki Stosowanej Michał Ochociński nr albumu: 236401 Praca magisterska na kierunku informatyka stosowana Tworzenie i obsługa wirtualnego

Bardziej szczegółowo

Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki. Paweł Parys. Nr albumu: 209216. Aukcjomat

Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki. Paweł Parys. Nr albumu: 209216. Aukcjomat Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki Paweł Parys Nr albumu: 209216 Aukcjomat Praca licencjacka na kierunku INFORMATYKA w zakresie INFORMATYKA Praca wykonana pod kierunkiem

Bardziej szczegółowo

Rozproszone systemy internetowe

Rozproszone systemy internetowe Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego Rozproszone systemy internetowe Wprowadzenie do usług WWW (Web Services) Podniesienie potencjału uczelni

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne

Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne Rafał Czubik Krzysztof Komorowski IBM 2008 IBM Corporation Metodyka jest ważna Procesy i moduły Obszary decyzyjne

Bardziej szczegółowo

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy

Bardziej szczegółowo

Serwery. Autorzy: Karol Czosnowski Mateusz Kaźmierczak

Serwery. Autorzy: Karol Czosnowski Mateusz Kaźmierczak Serwery Autorzy: Karol Czosnowski Mateusz Kaźmierczak Czym jest XMPP? XMPP (Extensible Messaging and Presence Protocol), zbiór otwartych technologii do komunikacji, czatu wieloosobowego, rozmów wideo i

Bardziej szczegółowo

Zagadnienia projektowania aplikacji J2EE

Zagadnienia projektowania aplikacji J2EE 211 Zagadnienia projektowania aplikacji J2EE Maciej Zakrzewicz Maciej.Zakrzewicz@cs.put.poznan.pl http://www.cs.put.poznan.pl/mzakrzewicz/ Plan rozdziału 212 Wstęp Techniki projektowe: Wprowadzenie modułu

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor Koszalin, 15.06.2012 r. Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor Zespół projektowy: Daniel Czyczyn-Egird Wojciech Gołuchowski Michał Durkowski Kamil Gawroński Prowadzący: Dr inż.

Bardziej szczegółowo

Uniwersytet Mikołaja Kopernika w Toruniu. Profilowanie ruchu sieciowego w systemie GNU/Linux

Uniwersytet Mikołaja Kopernika w Toruniu. Profilowanie ruchu sieciowego w systemie GNU/Linux Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Michał Ferliński Nr albumu: 187386 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

ActiveXperts SMS Messaging Server

ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server to oprogramowanie typu framework dedykowane wysyłaniu, odbieraniu oraz przetwarzaniu wiadomości SMS i e-mail, a także tworzeniu własnych

Bardziej szczegółowo

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych

Bardziej szczegółowo

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Studia podyplomowe dla nauczycieli INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Przedmiot JĘZYKI PROGRAMOWANIA DEFINICJE I PODSTAWOWE POJĘCIA Autor mgr Sławomir Ciernicki 1/7 Aby

Bardziej szczegółowo

Usługi analityczne budowa kostki analitycznej Część pierwsza.

Usługi analityczne budowa kostki analitycznej Część pierwsza. Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.

Bardziej szczegółowo

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

Wstęp Budowa Serwlety JSP Podsumowanie. Tomcat. Kotwasiński. 1 grudnia 2008

Wstęp Budowa Serwlety JSP Podsumowanie. Tomcat. Kotwasiński. 1 grudnia 2008 Adam 1 grudnia 2008 Wstęp Opis Historia Apache kontener serwletów rozwijany w ramach projektu Apache jeden z bardziej popularnych kontenerów Web open source, Apache Software License rozwijany przez ASF

Bardziej szczegółowo

Rozproszone systemy Internetowe

Rozproszone systemy Internetowe Rozproszone systemy Internetowe Transport komunikatów WS: protokół SOAP RSI Oskar Świda 1 Simple Object Access Protocol Bezstanowy protokół komunikacyjny, oparty na standardzie XML Prosty i elastyczny,

Bardziej szczegółowo

Wprowadzenie do usług internetowych

Wprowadzenie do usług internetowych Wprowadzenie do usług internetowych Tomasz Pawlak 2 Plan prezentacji Wprowadzenie do usług internetowych Technologie usług internetowych Architektura usług internetowych Statystyki 3 Usługa internetowa

Bardziej szczegółowo

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML Jakub Morkis, Piotr Chmielewski BPMN - Historia Formowanie grumy tworzącej notację Sierpień 2001, 58 członków reprezentujących 35 firm,

Bardziej szczegółowo

Wdrożenie technologii procesowej IBM BPM w EFL

Wdrożenie technologii procesowej IBM BPM w EFL Wdrożenie technologii procesowej IBM BPM w EFL Marcin Naliwajko Z-ca dyrektora Departamentu Technologii Dominik Lisowski Starszy Architekt Systemów IT Grupy EFL WebSphere Message Broker 2008 r. Wdrożenie

Bardziej szczegółowo

Platforma Informatyczna Wdrażania Oprogramowania Dedykowanego w PL-Grid

Platforma Informatyczna Wdrażania Oprogramowania Dedykowanego w PL-Grid 1 Platforma Informatyczna Wdrażania Oprogramowania Dedykowanego w PL-Grid Grzegorz Banach Wrocławskie Centrum Sieciowo-Superkomputerowe, Politechnika Wrocławska, Instytut Niskich Temperatur i Badań Strukturalnych

Bardziej szczegółowo

Dokumentacja projektu QUAIKE Architektura oprogramowania

Dokumentacja projektu QUAIKE Architektura oprogramowania Licencjacka Pracownia Oprogramowania Instytut Informatyki Uniwersytetu Wrocławskiego Jakub Kowalski, Andrzej Pilarczyk, Marek Kembrowski, Bartłomiej Gałkowski Dokumentacja projektu QUAIKE Architektura

Bardziej szczegółowo