Integracja usług z wykorzystaniem architektury ESB

Transkrypt

1 Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki Akademii Górniczo Hutniczej w Krakowie Praca magisterska Integracja usług z wykorzystaniem architektury ESB Wacław Borowiec, Wojciech Górski wyborowiec@gmail.com, wojtek.gorski@gmail.com Promotor: dr inż. Dominik Radziszowski Kraków, 2008

2 Spis treści 1 Wstęp Standaryzacja Integracja Kompozycja Cele pracy Struktura pracy Wkład własny autorów Opis wykorzystanych technologii SOA Wykorzystywane technologie Service Data Objects SCA - Service Component Architecture ESB Mediacja wiadomości Workflowy i procesy biznesowe BPEL WebSphere ESB WebSphere Process Server WebSphere Integration Developer Opis problemu Serwisy Amazon ebay Allegro Sklepy internetowe NotificationService Integracja Przygotowanie serwisów do integracji Implementacja EShopService Implementacja NotificationService Integracja klasyczna

3 4.2.1 Integracja Amazon Integracja ebay Integracja Allegro Integracja sklepu internetowego Apollo Integracja za pomocą ESB Moduł mediacyjny Amazon Moduł mediacyjny ebay Moduł mediacyjny Allegro Moduł mediacyjny ApolloEShop Moduł biznesowy Wizualizacja Porównanie zrealizowanych rozwiązań Faza budowy aplikacji Faza reorganizacji Wnioski i podsumowanie Przydatność ESB w świetle zagadnień związanych z integracją aplikacji Niedostatki istniejących implementacji jako praktyczna trudność we wdrażaniu ESB Koszty zakupu komercyjnych implementacji jako czynnik spowalniający rozwój ESB Aplikacje sieciowe niezgodne ze standardami SOA Podsumowanie Bibliografia 74 8 Dodatek A: Indeks terminów 81 3

4 1 Wstęp Dobre zrozumienie problematyki integracji usług wymaga znajomości trendów w łączeniu systemów komputerowych jakie naprzemiennie pojawiały się i znikały w przeszłości. Dzięki temu możliwe jest sprecyzowanie wymagań stawianych współczesnym architekturom systemów rozproszonych oraz zrozumienie genezy i oczekiwań stawianych systemom o architekturze ESB, których niniejsza praca dotyczy. 1.1 Standaryzacja Pojęcie integracji programów komputerowych pojawiło się już prawie trzydzieści lat temu, w latach 80, gdy informatyka była coraz powszechniej stosowana w szeroko pojętym biznesie. Korporacje decydujące się na rozwiązanie określonego problemu za pomocą systemu komputerowego zamawiały i otrzymywały dedykowany produkt, ściśle do danego problemu dopasowany. Zwiększanie ilości działających systemów powodowało nadmierne gromadzenie się odmiennych, niezależnych od siebie aplikacji. Korzystanie z nich, modyfikacja i utrzymanie stawały się coraz trudniejsze i coraz bardziej kosztowne. W fizycznie odrębnych systemach pojawiały się logiczne zależności lub powtórzenia funkcjonalne. Problematyczne było również łączenie systemów w skali makro, a więc pomiędzy instytucjami. Właściwe połączenie współistniejących produktów stawało się w wielu przypadkach niezbędne [24]. Łączenie takie, polegające na umożliwieniu współpracy i/lub współdzielenia zasobów, jest nazywane integracją [13]. Z drugiej strony niezmiennym wymaganiem stawianym branży IT jest możliwość szybkiego reagowania na zmieniające się wymagania, przy czym nakłady poniesione na modyfikację istniejących rozwiązań lub wdrażanie nowych muszą pozostawać mniejsze od uzyskiwanych dzięki temu korzyściom. Istnienie w ramach przedsiębiorstwa wielu zależnych od siebie logicznie, a niepowiązanych systemów, powoduje, że wprowadzanie zmian jest bardzo skomplikowane, a co za tym idzie kosztowne i długotrwałe [25]. Potrzeba integracji aplikacji była podstawową przyczyną początków standaryzacji w informatyce. Standaryzacja (zwana również normalizacją) jest próbą ujęcia technologii, protokołów, formatów używanych w produktach IT w pewne ramy pozwalające na ograniczenie dowolności w tworzeniu rozwiązań systemowych, a więc również na ułatwienie ich współpracy ze sobą [26]. Pojawienie się standardów nie spowodowało, że problemy związane z integracją aplikacji przestały istnieć. Stosowanie się do nich przez korporacje było niejednokrotnie różnie rozumiane. W ten sposób powstawały produkty spełniające standardy tylko do pewnego stopnia, lub interpretujące je inaczej niż konkurencja (co mo- 4

5 że również świadczyć o złej jakości samej specyfikacji standardu), albo wręcz specjalnie unikające stosowania się do nich, np. ze względów ekonomicznych [3]. Chociaż definiowanie standardów było znaczącym krokiem ułatwiającym integrację systemów, w niektórych sytuacjach okazywały się one albo zbyt wąskie, albo nie było możliwości ich praktycznego zastosowania. Takimi zagadnieniami są na przykład przenośność aplikacji pomiędzy różnymi architekturami sprzętowymi czy systemami operacyjnymi. Częściowym rozwiązaniem tych problemów okazały się języki programowania wysokiego poziomu, które z jednej strony umożliwiały uruchamianie stworzonych z ich użyciem programów bez modyfikacji na różnych platformach sprzętowych i systemowych, a z drugiej strony ułatwiały i przyspieszały pracę programistów poprzez np. automatyczne zarządzanie pamięcią. Typowym przykładem jest tutaj język programowania Java. Nie sposób pominąć również ogromnej roli jaką dzięki swej przenośności odegrał język XML, który ma zastosowanie w innej niż Java domenie jaką jest opis struktur danych [3]. 1.2 Integracja Zagadnienie integracji aplikacji może być postrzegane na dwa sposoby. Pierwsze osiągnięcia w łączeniu ze sobą programów komputerowych polegały na komunikacji pomiędzy nimi na poziomie rozumienia przesyłanych bitów danych. Z biegiem czasu pojawiały się standardy dotyczące coraz wyższych poziomów modelu komunikacji znanego obecnie jako stos OSI/ISO. Dotyczyły one kolejno warstw łącza danych (Ethernet), sieciowej (IP), transportowej (TCP, UDP), a następnie wyższych. Pozwoliło to programistom na stopniowe uniezależnienie się od szczegółów komunikacji pomiędzy systemami, dzięki czemu mogli koncentrować się na semantyce danych wymienianych pomiędzy integrowanymi systemami. Równolegle pojawiały się zbiory reguł opisujące zagadnienia współpracy aplikacji; początkowo na bardzo wysokim poziomie abstrakcji, następnie były one precyzowane jako wciąż ogólne paradygmaty, które z kolei stawały się podstawą dla bardziej konkretnych wzorców architektonicznych [27]. Enterprise Application Integration (EAI) jest takim właśnie zbiorem ogólnych reguł dotyczącym integracji heterogenicznych systemów [29]. Na jego podstawie określony został paradygmat Service Oriented Architecture określający integrowane systemy jako niezależne, współpracujące ze sobą serwisy [27]. Próby realizacji architektur opartych o SOA były podejmowane już w przeszłości. Do najszerzej stosowanych należą DCOM firmy Microsoft oraz CORBA stworzona przez konsorcjum OMG. Chociaż te i inne podobne produkty wciąż są z powodzeniem wykorzystywane w wielu zastosowaniach, ze względu jednak na pewne ich cechy, jak uzależnienie od 5

6 konkretnej platformy (DCOM) czy wysoka złożoność (CORBA), wdrażanie z ich pomocą paradygmatu SOA było zniechęcające i niepraktyczne [3]. Dopiero pojawienie się technologii web serwis umożliwiło realizację koncepcji SOA w praktyce. Dobrze określona, a przy tym konkretna specyfikacja web serwisów zawierająca w sobie m.in. opis protokołu komunikacji SOAP oraz język opisu interfejsu WSDL oparty na języku XML, mechanizmy semantycznego katalogowania i wyszukiwania dostawców usług sprawiły, że standard ten szybko zyskuje popularność i jest obecnie szeroko stosowany w aplikacjach rozproszonych. Równocześnie dzięki wsparciu dla web serwisów w językach programowania możliwe stało się także udostępnienie usług systemów niezgodnych z SOA poprzez stworzenie odpowiednich adapterów [3]. Dzięki niezależności specyfikacji usług web serwisów od implementacji powstała możliwość ich wielokrotnego wykorzystania w ramach różnych systemów. Jest to przyczyną odchodzenia od modelu klasycznej integracji aplikacji na rzecz komponowania istniejących serwisów w procesy i ich modelowania w zależności od zmieniających się potrzeb [3]. 1.3 Kompozycja Kompozycja w architekturze SOA może być realizowana na dwa sposoby: poprzez choreografię i orkiestrację. Orkiestracja jest modelem współpracy serwisów nadzorowanym przez nadrzędny proces, określający sposób i kolejność interakcji z serwisami. Proces ten ma określoną lokalizację, tzn. jest kontrolowany przez jeden, określony podmiot. Choreografia natomiast jest ukierunkowana na współpracę serwisów ze sobą. Każdy z usług sama określa rolę jaką pełni w interakcji z innymi. Nie ma w tym przypadku centralnego zarządcy, czy właściciela [28]. Chociaż SOA definiuje pojęcia orkiestracji i choreografii, to nie precyzuje metody ich realizacji w praktyce [30]. Architektura Enterprise Service Bus (ESB) jest właśnie specyfikacją struktury warstwy pośredniej dla systemów opartych o SOA bazującej na orkiestracji. W bardzo ogólnym ujęciu ESB dostarcza usług ogólnego przeznaczenia umożliwiających zapewnienie m.in. odpowiedniej jakości działania integrowanych serwisów, możliwości ich komponowania w konfigurowalne procesy biznesowe poprzez orkiestrację, a także bezpiecznej i łatwej komunikacji pomiędzy nimi. Dzięki takiemu podejściu systemy zbudowane w oparciu o ESB mają być łatwe w konfiguracji, zarządzaniu i rozbudowie [21]. Architektura ESB jest wyłącznie propozycją realizacji szerszej koncepcji jaką jest SOA, jednak zdobywa ona coraz większą popularność i jest coraz częściej stosowana w projektowaniu systemów rozproszonych. Istnieją konkretne implementacje gotowe do wdrożenia 6

7 tam, gdzie pojawia się potrzeba integracji wielu zróżnicowanych usług. 1.4 Cele pracy W związku z rosnącym zainteresowaniem wzorcem architektonicznym Enterprise Service Bus, pojawiła się potrzeba sprawdzenia jak wygląda praktyczna strona tworzenia systemów zgodnych z architekturą SOA zawierających jako warstwę pośrednią ESB. Każde nowe rozwiązanie wymaga weryfikacji i testów, wypracowania dobrych praktyk związanych z jego wykorzystaniem i oceny rzeczywistych kosztów jego zastosowania i utrzymania. Ważne jest określenie na ile da się teoretyczne założenia zrealizować w istniejących produktach. Celem autorów jest właśnie przetestowanie wybranej implementacji ESB, zweryfikowanie na ile teoretyczne założenia architektury znajdują swoje odzwierciedlenie w rzeczywistym produkcie. Ponadto zostanie pokazane, jakie ryzyko może nieść ze sobą wdrożenie ESB przy obecnym rozwoju tej technologii. Powyższe cele zostaną osiągnięte poprzez implementację konkretnego przypadku zastosowania ESB do integracji usług sieciowych. Taki scenariusz biznesowy musi być wystarczająco reprezentatywny, aby łatwo dało się go uogólnić na inne zastosowania. Ze względu na obszerność zagadnienia nie sposób omówić i sprawdzić dokładnie chociaż części najpopularniejszych zastosowań, dlatego wybrano jedno z nich. Zostanie ono rozwinięte i omówione w taki sposób by łatwo dało się je odnieść do innych przykładów. Celem niniejszej pracy jest również zbadanie faktycznej jakości integracji wybranego produktu ESB z realnymi, funkcjonującymi w rzeczywistym świecie aplikacjami rozproszonymi. Aby osiągnąć ten cel, wybór integrowanych usług obejmuje kilka istniejących obecnie rozwiązań pod kątem jakości integracji z ESB. Zweryfikowane zostaną zarówno serwisy zgodne z architekturą SOA, a więc np. udostępnione w internecie za pomocą web serwisów, umożliwiające dzięki temu potencjalnie najłatwiejszą współpracę z innymi tego typu serwisami, jak również aplikacje niezgodne z tym wzorcem. Istnieje również trzecia możliwość: integracja z ESB serwisów projektowanych z myślą o takim zastosowaniu. Również i ten przypadek zostanie przeanalizowany. Autorzy porównają wybrany scenariusz oparty o ESB z analogiczną pod względem dostarczanej funkcjonalności realizacją opartą o integrację klasyczną. Porównane zostaną zarówno szybkość konstrukcji obu rozwiązań, ich niezawodność i możliwości reakcji na ewentualne błędy (diagnostyka), a także czas potrzebny na modyfikację lub reorganizację procesu biznesowego. 7

8 1.5 Struktura pracy Praca składa się z dwóch zasadniczych części. Pierwsza z nich, teoretyczna, wprowadza czytelnika w podstawowe zagadnienia związane z integracją serwisów. Druga ukazuje szczegółowo praktyczny przykład jej realizacji. Rozdział 2 zawiera opis kluczowych architektur jak SOA, ESB, procesy workflow, a także opis wybranej implementacji ESB. W rozdziale 3 czytelnik zapozna się z implementowanym problemem oraz integrowanymi serwisami. W kolejnym rozdziale opisany jest szczegółowo sposób realizacji postawionego problemu zarówno poprzez klasyczną integrację serwisów jak i z użyciem wybranego narzędzia ESB. W rozdziale 5 oba sposoby rozwiązania problemu są ze sobą porównane. W ostatnim rozdziale 6 autorzy formułują wnioski wynikające z przeprowadzonych badań. 1.6 Wkład własny autorów Rozdziały 1 i 6 zawierające wstęp oraz wnioski zostały przez obu autorów przygotowane w ścisłej współpracy. W rozdziale 2 Wojciech Górski opisał paradygmat SOA oraz procesy workflow, natomiast Wacław Borowiec - ESB i produkty z rodziny WebSphere. Rozdział 3 jest w całości autorstwa Wacława Borowca, podobnie jak podrozdział 4.3 dotyczący integracji z użyciem ESB. Autorem podrozdziałów 4.2 i 4.1 oraz rozdziału 5 jest Wojciech Górski. 8

9 2 Opis wykorzystanych technologii W rozdziale tym przybliżone zostaną architektury i związane z nimi technologie wykorzystywane w ramach opracowania. 2.1 SOA SOA (Service Oriented Architecture architektura zorientowana na serwisy 1 ) to nowoczesna architektura oprogramowania, w której główny nacisk stawia się na definiowanie serwisów oraz ich łączenie. Podstawową częścią każdego systemu SOA są usługi, które dostarczają pewną funkcjonalność za pomocą dobrze zdefiniowanego interfejsu. Są one niezależne zarówno od systemu operacyjnego, jak i języka programowania, co powoduje, że mogą być stosowane w heterogenicznym środowisku. W klasycznej architekturze SOA, serwisy powinny przejawiać następujące własności, chociaż w praktyce nie zawsze wszystkie one są spełnione: 1. Usługa stanowi całość samą w sobie i może być używana niezależnie od innych, 2. Usługi są dostępne w sieci, 3. Każda usługa posiada zdefiniowany interfejs. Do korzystania nie potrzebna jest wiedza na temat implementacji usługi, wyłącznie znajomość interfejsu, 4. Klient usługi jest niezależny od platformy, tzn. korzystanie z usługi może być realizowane na różnych systemach operacyjnym i językach programowania, 5. Usługi mogą być zapisane w rejestrach, które pozwalają przeglądać listę usług, 6. Usługa jest wywoływana za pomocą wiązania późnego (ang. late binding), z czego wynika, że decyzja o jej wyborze jest dokonywana na etapie wykonania Wykorzystywane technologie Jako przykład realizacji własności usług przedstawionych w poprzednim punkcie można przytoczyć standard web serwis (ang. WebServices): 1. Usługa webserwisowa jest osadzana na serwerze i działa niezależnie od innych jego usług (o ile implementacja web serwisu z nich nie korzysta), 1 W pracy naprzemiennie używa się terminu serwis i usługa. 9

10 2. Web serwis dostępny jest przez protokoły sieciowe takie jak HTTP, SMTP, FTP, 3. Interfejs usługi jest udostępniany za pomocą języka definicji serwisu WSDL. Posiadając definicję usługi możemy korzystać z niej, nie znając jej implementacji, 4. Implementacje web serwisów istnieją dla większości używanych systemów operacyjnych (Windows, Linux, Solaris i inne), oraz języków programowania (Java, C/C++, C i inne), 5. Usługi są zapisywane w rejestrze UDDI (Universal Description, Discovery and Integration). Korzystając z niego, można uzyskać informacje o usługach dostępnych w sieci, 6. Posiadając opis interfejsu web serwisu (WSDL), można stworzyć kod odwołujący się do usługi. Usługa nie musi być jednak dostępna w czasie tworzenia klienta, ponieważ wyszukiwanie serwisu odbywa się dopiero w czasie wykonywania aplikacji Service Data Objects Service Data Objects jest specyfikacją umożliwiającą jednolity dostęp do zróżnicowanych danych, stworzoną w 2004 roku przez firmy IBM i BEA. Specyfikacja ta definiuje struktury danych. Posiadają one własności (ang. properties), które mogą mieć określony typ podstawowy (np. liczba całkowita, typ łańcuchowy), lub być referencjami do innych struktur. Struktury te wspierają dziedziczenie, w tym dziedziczenie wielokrotne. Posiadają także możliwość reprezentowania kolekcji w postaci tzw. wielowartościowych własności (ang. multi-valued properties). [20] Obiekty SDO w kodzie konkretnego języka programowania są reprezentowane przez ogólny interfejs dostarczający metod manipulacji własnościami dowolnego obiektu SDO (w przypadku języka Java jest to interfejs commonj.sdo.dataobject). Dzieje się tak dlatego, że SDO reprezentuje wyższy poziom abstrakcji w reprezentacji danych niż zwykłe obiekty i mimo podobieństw wymaga innego podejścia przy programowaniu. Fragment kodu nr 1 ukazuje ideę pracy z obiektami SDO. // utworzenie obiektów SDO reprezentowanych przez i n t e r f e j s // DataObject DataObject customer =... DataObject order =... // u s t a w i e n i e w ł a s n o ś c i obiektów SDO customer. s e t S t r i n g ( firstname, John ) ; 10

11 customer. s e t S t r i n g ( lastname, Doe ) ; customer. s e t I n t ( customerid, 123) ; order. setdataobject ( customer, customer ) ; // pobranie w a r t o ś c i w ł a s n o ś c i obiektu SDO int id = order. getdataobject ( customer ). g e t I n t ( customerid ) ; Fragment kodu 1: Kod ukazujący sposób programowania obiektów SDO [1] Z obiektami SDO wiąże się jeszcze jeden mechanizm - grafy danych (ang. data graphs). Graf taki jest zbudowany z obiektu bazowego (ang. root object) oraz listy zmian odnoszących się do tego obiektu. Mechanizm ten jest szczególnie przydatny wówczas, gdy persystentne obiekty SDO są modyfikowane poza zakresem działania mechanizmu persystencji (przy braku synchronizacji z bazą danych). Gdy obiekt taki po zmianach dokonanych w aplikacji ma być uaktualniony w bazie, jest do tego celu wykorzystywany właśnie obiekt bazowy oraz lista przeprowadzonych zmian SCA - Service Component Architecture W celu stworzenia standardu architektonicznego dla aplikacji budowanych według zasad SOA, korporacje (m.in. BEA, IBM, IONA, Oracle) podjęły inicjatywę, w wyniku której powstała wczesna, pierwsza wersja specyfikacji SCA(V1.0). Jej kluczowym elementem są elementy formujące model danych - obiekty SDO. Jest to podstawowy sposób wymiany danych pomiędzy komponentami i modułami SCA [31]. Architektura SCA jest oparta o koncepcję komponentów. Aplikacja napisana zgodnie z jej wytycznymi powinna spełniać poniższe wymagania: 1. rozdzielenie logiki biznesowej od implementacji warstw niższych, związanych z wywoływanymi serwisami, 2. możliwość współpracy z serwisami zaimplementowanymi w wielu różnych językach jak np. C++, Java, PHP, COBOL, BPEL, XSLT, XML, 3. możliwość bezproblemowej komunikacji według różnych schematów (jednokierunkowy, asynchroniczny, dwukierunkowy, messaging), 4. możliwość połączenia z typowymi komponentami lub usługami dostępnymi zazwyczaj poprzez takie technologie jak web serwisy, EJB, JCA, RMI, RPC, JMS itp. 5. możliwość deklarowania (poza logiką biznesową) wymagań Quality of Service, 11

12 6. dane mogą być reprezentowane jako Service Data Objects. Rysunek 1 [1] przedstawia schemat ilustrujący koncepcję SCA. Pokazano na nim elementy wchodzące w skład architektury, a także powiązania między nimi. Zostaną one teraz pokrótce omówione. Rysunek 1: Schemat architektury SCA Komponent zamyka w sobie usługę oferując ją poprzez pewien interfejs określający parametry potrzebne do realizacji zadania. Komponenty mogą wymagać też referencji do innych interfejsów (serwisów), jakie wykorzystują przy realizacji własnej usługi. Implementacje oddzielnych komponentów są zupełnie niezależne od siebie, stanowią one tzw. czarne skrzynki (ang. black boxes), gdzie szczegóły dotyczące implementacji są całkowicie zakryte dla świata zewnętrznego. Komponenty SCA mogą dostarczać operacji o następujących typach: jednokierunkowe (ang. one-way) - zwane również fire-and-forget; dane są wysyłane tylko od wywołującego operację do komponentu (brak wartości zwracanej), dwukierunkowe (ang. two-way) - zwane również request/reply; dane są przesyłane do komponentu w momencie wykonania metody, wówczas komponent może wykonywać dowolne operacje, po zakończeniu których wysyła rezultat do wywołującego. 12

13 Rysunek 2: Schemat implementacji komponentu SCA Sposób definiowania typów parametrów również jest dwojaki: mogą to być typy języka Java lub obiekty definiowane za pomocą języka XML. Komponenty SCA nie są związane z konkretną technologią implementacji, co schematycznie ukazuje rysunek 2 [1]. Komponenty są zwykle połączone ze sobą - referencje z wymaganymi interfejsami. Kilka połączonych komponentów tworzy moduł, dla którego konfiguracja (łączenie komponentów) jest koncepcyjnie odrębnym zadaniem od implementacji poszczególnych komponentów. Dzięki temu - teoretycznie, zgodnie z założeniami architektur komponentowych - komponenty mogą dostarczać różni, niezależni podwykonawcy (lub programiści), natomiast ich integracją w moduł może się zajmować niezależny podmiot. Cechą charakterystyczną SCA jest to, iż moduły mają ściśle określoną strukturę wewnętrzną - komponenty oraz powiązania między nimi są dobrze znane już na etapie projektowania modułu. Zewnętrzne powiązania między modułami mają natomiast charakter luźny: mogą one być łączone na różne sposoby określane dopiero w czasie wykonania programu (ang. runtime). Do takiego luźnego łączenia modułów z innymi modułami wykorzystywane są tzw. eksporty (ang. exports) i importy (ang. imports). Eksporty udostępniają funkcjonalność modułu na zewnątrz, dla innych modułów. Oferują one taki interfejs jaki powinien udostępniać na zewnątrz moduł, który reprezentują. Istnieje możliwość adaptacji eksportu w innym module poprzez powiązany z nim import. Import jest wówczas uchwytem, referencją do skojarzonego z nim eksportu i umożliwia korzystanie z funkcjonalności reprezentowanej przez ten eksport w swoim macierzystym module. Importowane w ten sposób 13

14 Rysunek 3: Sposoby łączenia serwisów w SOA mogą być również inne zasoby, zewnętrzne w stosunku do danego modułu. Aby moduł mógł być wykorzystany poza modelem SCA, musi udostępniać referencję statyczną (ang. stand-alone references), która jest koncepcyjnie podobna do eksportu. Pomiędzy importami i eksportami występują powiązania transportowe (ang. transport bindings), które określają fizyczny mechanizm komunikacji pomiędzy modułami (np. lokalna - poprzez referencje, powiązanie za pomocą web serwisu, kolejki JMS). Architektura SCA dzięki swej elastyczności i przenośności znalazła wiele zastosowań, między innymi w systemach ESB. 2.2 ESB ESB (Enterprise Service Bus) jest realizacją warstwy pośredniej zgodnej z paradygmatem SOA [3]. Głównym elementem budowy systemu zgodnego z ESB są usługi, szczególny nacisk położony jest na sposoby łączenia serwisów i mediacji wiadomości. Architektura ESB zakłada model centralnej szyny danych jako model połączeń między serwisami. Do szyny ESB podłączane są wszystkie serwisy związane z systemem i wszelkie wiadomości przesyłane od i do serwisów przekazywane są za jej pośrednictwem. Zaletą tego rozwiązania w stosunku do rozwiązań alternatywnych (np. bezpośrednie połączenia między serwisami) jest mała ilość połączeń między usługami. W przypadku n usług, liczba połączeń z wykorzystaniem ESB wynosi n, w porównaniu z n(n 1) 2 w przypadku połączeń bezpośrednich. Jest to zilustrowane na rysunku 3. ESB zakłada jeden, spójny model dla danych wewnątrz szyny. Nie wynika z tego jednak, że zewnętrzne serwisy integrujące się z nią też muszą mieć taki sam model danych. Wymaganie takie byłoby trudne do spełnienia i często uniemożliwiałoby integrację dwóch serwisów o różnych modelach danych. Architektura ESB rozwiązuje ten problem za pomocą adapterów, które umieszczane są na styku pomiędzy szyną a serwisami i służą do konwersji danych pomiędzy poszczególnymi modelami danych. Jest to zobrazowane na 14

15 Rysunek 4: Wspólny model danych w ESB rysunku 4. Zastosowanie wzorca ESB do integracji aplikacji daje m.in. następujące korzyści [2]: Uniezależnienie od lokalizacji usług. Strona korzystająca z danej usługi nie musi znać jej konkretnej lokalizacji, w szczególności każdorazowo usługa może być dostarczana przez inny podmiot, Uniezależnienie od protokołu interakcji. Usługi potrafiące komunikować się za pomocą jednego protokołu (np. HTTP/SOAP) mogą współpracować z serwisem używającym zupełnie innego protokołu (np. RMI), Uniezależnienie od zgodności interfejsów. Wywołujący nie jest zobligowany do dostosowania parametrów wywołania do wymagań serwisu, z którego korzysta, ale odpowiednia konwersja wywołania może zostać dokonana w ramach szyny ESB. Zastosowanie ESB nie ma (a przynajmniej nie powinno mieć) wpływu na sposób budowy komunikujących się z jego pomocą serwisów. Z tego powodu w szczególności znajduje zastosowanie tam, gdzie nie ma możliwości ingerencji w kod źródłowy aplikacji (np. w przypadku systemów zastanych, które są kosztowne w modyfikacji lub systemów o nieznanym kodzie źródłowym), która jednak musi zostać przystosowana do współpracy z innym modułem. Wprowadzenie ESB jest decyzją na poziomie integracji poszczególnych części systemu rozproszonego (ang. deployment), a nie ich projektowania. Sam proces dostosowania szczegółów integracji usługobiorców i usługodawców, polegający na zmianie fizycznej reprezentacji wywołania w locie (ang. in-flight), zwany jest mediacją wiadomości. 15

16 2.2.1 Mediacja wiadomości Szyna ESB nie jest tylko warstwą transportową dla wiadomości wysyłanych między serwisami. Oprócz zwykłego łączenia usług, posiada jeszcze następujące funkcje: 1. Mapowanie żądań usług z konkretnego protokołu i adresu na inny protokół/adres, 2. Transformacja danych na inny format, 3. Zarządzanie wieloma modelami transakcji i bezpieczeństwa i łączy różne modele integrowanych serwisów, 4. Agregacja żądań do serwisów, 5. Obsługa protokołów sieciowych między różnymi platformami z zachowaniem jakości usług (QoS). Oprócz wyżej wymienionych własności, szyna ESB musi posiadać wiele sposobów integracji zewnętrznych aplikacji, które często posiadają własny, unikalny sposób dostępu, własne protokoły, modele bezpieczeństwa itd. Szyna powinna dostarczać w tym celu różne rodzaje adapterów, obsługujące wymagane protokoły komunikacji i formaty danych. Adaptery takie ukrywają detale związane z wykorzystaniem wymaganych rodzajów zasobów udostępniając interfejsy umożliwiające korzystanie z zasobów w jednolity sposób w ramach ESB. Stopień skomplikowania nie powinien być widoczny dla użytkownika serwisów, szczegóły implementacji powinny być zasłonięte za dobrze zdefiniowanym interfejsem adapteru. W ten sposób, przy wykorzystaniu szyny ESB, można skupić się na integracji serwisów na poziomie logicznym, pomijając szczegóły niskopoziomowego połączenia. Zewnętrzne serwisy mogą posiadać różne sposoby interakcji. Większość z nich wykorzystuje wzorzec request/response (wzorzec polegający na wysłaniu żądania oraz otrzymywanie odpowiedzi), niektóre korzystają jednak z takich wzorców jak publish/subscribe (wzorzec zakłada jednorazową subskrypcję, za pomocą której otrzymujemy dane opublikowane przez serwis) oraz modelu zdarzeniowego. ESB powinien dostarczać infrastrukturę do integracji systemów wykorzystujących wszystkie trzy główne wzorce integracji: 1. Aplikacje, które wykorzystują serwisy z dobrze zdefiniowanym interfejsem. Aby zapewnić komunikację z takim systemem, szyna może wykorzystywać niższą warstwę, 2. Aplikacje bazujące na wiadomościach, które przesyłane są przez szynę ESB, 3. Aplikacje wykorzystujące model zdarzeniowy, w którym niezależnie od siebie generują oraz odbierają zdarzenia. 16

17 Wzorce mediacyjne Wyróżnia się kilka wzorców, według których dokonywana jest transformacja komunikatów przesyłanych poprzez ESB [2]: 1. Wzbogacenie (ang. enrich) - wzbogacenie zawartości wiadomości poprzez dołączenie dodatkowych parametrów pochodzących z mediacji lub np. z bazy danych, 2. Przełączenie protokołu (ang. protocol switch) - zmiana protokołu komunikacji pomiędzy usługodawcą a usługobiorcą, może mieć miejsce w dowolnym punkcie na drodze pomiędzy współpracującymi stronami, 3. Transformacja - zmiana formatu wiadomości z postaci rozumianej przez usługobiorcę do formatu akceptowanego przez usługodawcę; może mieć postać enkapsulacji, dekapsulacji, szyfrowania itp. 4. Przekierowanie (ang. routing) - Wybór usługodawcy na podstawie określonych kryteriów. Mogą być one rozpatrywane na podstawie zawartości komunikatu, jego kontekstu, ale także na podstawie cech dostępnych usługodawców, 5. Dystrybucja (ang. distribute) - rozsyła wiadomość do wielu zainteresowanych stron, rejestrujących się zwykle na zasadzie subskrypcji, 6. Monitoring - umożliwia szeroko pojętą obserwację przepływających wiadomości w celach logowania, rozwiązywania problemów, pomiaru wykorzystania zasobów, w celach billingowych i innych, 7. Korelacja - łączy komunikaty lub strumienie zdarzeń; zawiera reguły identyfikacji i rozpoznawania wzorców w komunikatach. Powyższe wzorce można zestawiać w dowolne konfiguracje tworząc złożone łańcuchy dokonujące pożądanej mediacji. Wzorce rozlokowania (ang. deployment patterns) Szyna ESB nie musi w systemie występować jako pojedynczy, centralny punkt. Idea tego wzorca projektowego pozwala na łączenie ich w różnego rodzaju konfiguracje, z których typowe zostaną poniżej omówione[2]: 1. Global ESB - wszystkie serwisy dzielą pojedynczą przestrzeń nazw, każdy dostawca usług jest widoczny dla każdego klienta poprzez heterogeniczne, centralnie zarządzane, rozproszone geograficznie środowisko; używany zwykle w małych przedsiębiorstwach lub oddziałach, gdzie wszystkie dostępne serwisy są użytkowane, 17

18 Rysunek 5: Schematy wzorców rozlokowania ESB [2] 2. Directly connected ESB - wspólny rejestr serwisów sprawia, że są one widoczne w kilku niezależnych instalacjach ESB; możliwy do zastosowania w oddziałach, gdzie każdy serwis jest udostępniany dla innych, 3. Brokered ESB - niezależne instalacje ESB, które samodzielnie zarządzają swoimi przestrzeniami nazw, a udostępniają jedynie pewien podzbiór przyłączonych do nich usługodawców i usługobiorców na zewnątrz, są ze sobą kojarzone za pomocą wspólnego brokera (również ESB); przydatny w oddziałach, które udostępniają tylko część ze swoich serwisów dla innych, 4. Federated ESB - jedno nadrzędne ESB łączy zależne od niego instalacje ESB; usługodawcy i usługobiorcy łączą się do nadrzędnego lub podległego ESB w celu uzyskania dostępu do usług; ten wzorzec ma zastosowanie w przedsiębiorstwach, gdzie nadrzędny dział sprawuje kontrolę nad podległymi mu. Schematy omówionych wzorców są przedstawione na rysunku Procesy Workflow Według konsorcjum WfMC (Workflow Management Coalition), grupy określającej standardy workflow, definicja pojęcia workflow jest następująca: 18

19 Workflow: Automatyzacja procesów biznesowych, w całości lub w części, podczas której dokumenty, informacje lub zadania są przekazywane od jednego uczestnika do następnego, według odpowiednich procedur zarządczych. [14] Workflow opisuje sposób przepływu informacji pomiędzy kolejnymi etapami w procesie biznesowym. Opisy takich procesów można łatwo dostosować tak, aby odzwierciedlały strukturę i organizację prac w firmie, przez co są mogą służyć do automatyzacji różnych, powtarzających się zadań biznesowych. Konsorcjum WfMC stworzyło formalny język opisujący procesy biznesowe, XPDL (XML Process Definition Language). Jest to język oparty na XML, opisujący diagram procesu. W porównaniu do języków takich jak BPEL, nie jest on wykonywalny, ponieważ operuje na innym poziomie abstrakcji, opisując wygląd diagramu procesu (częścią opisu są koordynaty wektorowe XY) BPEL BPEL (Business Process Execution Language) to język stworzony do specyfikowania procesów biznesowych. Pełna nazwa to Web Services Business Process Execution Language (WS-BPEL), zgodnie ze standardem OASIS [16]. Procesy zdefiniowane za pomocą BPEL używają wyłącznie serwisów typu web serwis do zapewnienia funkcjonalności importu oraz eksportu. Istnieją dwa typy procesów biznesowych: 1. Procesy wykonywalne Procesy wykonywalne są kompletnymi procesami, które mogą zostać użyte bez żadnej modyfikacji, 2. Procesy abstrakcyjne Procesy abstrakcyjne to częściowo zdefiniowane procesy, które nie mogą być wykonane bezpośrednio. Ukrywają zamkniętą w sobie część procesu, który może być wykorzystany w wielu przypadkach użycia. Może to służyć także do ukrycia procesu, którego implementacja nie powinna być publicznie dostępna. Struktura języka Do interakcji z serwisami używany jest standard opisu serwisów WSDL w wersji 1.1. Sam język ma ustruktualizowaną formę dzięki wykorzystaniu standardu XML. Forma ta powoduje, że implementacja edytorów graficznych do tworzenia procesów BPEL jest 19

20 bardzo ułatwiona, dzięki temu powstało wiele takich narzędzi (np. edytor zintegrowany z Websphere Integration Developer lub NetBeans). Strukturalnie proces BPEL można rozłożyć na pojedyńcze bloki. Bloki określają zasięg (scope), który może być powiązany z obiektami obsługi błędów (Fault Handlers) i zdarzeń (Event Handlers). Manipulacja danymi Specyfikacja BPEL opisuje także sposoby manipulacji danych w celu łączenia serwisów z różnymi modelami danych. Podobnie jak sam opis języka, dane też są przechowywane za pomocą XML. Dzięki temu można w łatwy sposób wskazywać oraz zmieniać dowolne miejsce w danych za pomocą języka XPath, który służy do adresacji części dokumentów XML. Prosta modyfikacja polega na określeniu miejsca za pomocą XPath, z którego chcemy skopiować dane oraz miejsca docelowego, do którego te dane będą zapisane. Dzięki wykorzystaniu języka XPath możliwości są ogromne, ponieważ dostarcza on, oprócz zwykłej funkcjonalności adresacji danych, także funkcje ich manipulacji, jak np. concat (Funkcja łącząca dwa łańcuchy znaków w jeden), oraz umożliwia definiowanie własnych funkcji. Prostym przykładem skopiowania części danych może być poniższy fragment kodu BPEL: <a s s i g n> <copy> <from e x p r e s s i o n= xns:getcurrentdate ( ) /> <to v a r i a b l e= output part= payload query= / event / eventdate /> </ copy> </ a s s i g n> Fragment kodu 2: Przykładowy kod BPEL Powyższy kod pobiera bieżącą datę oraz przypisuje ją do zmiennej output pod adresem wskazanym przez XQuery ( /event/eventdate ). Obsługa transakcji BPEL pozwala na tworzenie transakcji, czyli zbioru operacji stanowiących niepodzielną całość. Operacje powinny wykonać się wszystkie lub, w przypadku niepowodzenia jednej z nich, nie powinna się wykonać żadna. Rozróżnia się pomiędzy dwoma typami transakcji, które zdefiniowane są w dwóch różnych standardach, tworzących specyfikację WS-Transaction: 20

21 1. WS-AtomicTransaction Specyfikacja WS-AtomicTransaction definiuje transakcje spełniające warunki ACID (atomicity, consistency, isolation, durability) znane z dziedziny baz danych. Własności te są realizowane za pomocą protokołu dwustopniowego zatwierdzania, w którym najpierw transakcja jest przygotowywana. W drugim kroku dane są zatwierdzane, pod warunkiem braku błędów w pierwszym kroku. Rozwiązanie to może być dość kosztowne ze względu na potrzebę zablokowania zasobów na czas transakcji, 2. WS-BusinessActivity Specyfikacja WS-BusinessActivity zapewnia wlaśności transakcji w inny sposób. Dla każdej operacji definiowana jest operacja kompensacji (compensation activity), która jest funkcją odwrotną dla danej operacji, przez co możliwe jest cofnięcie wywołanej metody. W przypadku, gdy jakaś część transakcji zgłasza błąd, na reszcie poprzednio aktywnych serwisów związanych z transakcją wywoływane są operacje kompensacji, które przywracają stan z przed rozpoczęcia transakcji. Dużą zaletą tego podejścia jest brak konieczności blokowania zasobów na czas transakcji. Niestety nie zawsze możliwe jest jej stosowanie z powodu trudności zdefiniowania funkcji kompensacji. BPEL jest językiem nadającym się do opisywania nawet bardzo skomplikowanych procesów biznesowych. Jest on wspierany przez wiele dużych firm (między innymi IBM, BEA, Micorosft, SAP). Dzięki istnieniu edytorów graficznych jego użycie stało się prostsze, co jeszcze bardziej przyczyniło się do jego popularności. Aktualnie jest to standard w dziedzinie opisywania procesów w technologii ESB. 2.4 WebSphere ESB WebSphere ESB to linia produktów firmy IBM pozwalająca na budowanie systemów klasy ESB. Pełna lista produktów z tej rodziny przedstawia się następująco: 1. WebSphere Application Server, 2. WebSphere Enterprise Service Bus, 3. WebSphere Process Server, 4. WebSphere MQ, 5. WebSphere Message Broker, 21

22 6. WebSphere Adapters, 7. Rational Application Developer, 8. WebSphere Integration Developer. Wszystkie produkty uzupełniają się nawzajem i za pomocą nich można stworzyć referencyjną architekturę systemu ESB według firmy IBM: Rysunek 6: Architektura referencyjna IBM SOA Centralnym punktem architektury jest szyna ESB (WebSphere Enterprise Service Bus i WebSphere Message Broker), która służy do mediacji wiadomości pomiędzy serwisami do niej podpiętej. Ponadto pozwala na zapewnienie jakości w komunikacji na szynie (QoS). Serwisy, które dołączane są do szyny ESB, dostarczane są za pomocą Websphere Application Server, który może służyć także do osadzania zwykłych aplikacji webowych, jak np. klienta dla całego systemu. Do tworzenia serwisów można wykorzystać aplikacje Rational Application Developer. Jest to środowisko oparte na szkielecie aplikacji Eclipse, bardzo dobrze zintegrowane z serwerem aplikacji z rodziny WebSphere. Websphere Application Server może być zastępiony dowolnym serwerem aplikacji, który pozwala na osadzanie aplikacji napisanych w języku Java. Elementem architektury, który łączy serwisy w logiczną całość jest WebSphere Process Server. Posiada on silnik BPEL, dzięki któremu możliwe jest układanie serwisów w proces biznesowy. Tworzenie procesu biznesowego w postaci BPEL jest bardzo ułatwione dzięki WebSphere Integration Developer, środowisku do integracji serwisów. 22

23 Nad wszystkimi elementami architektury może znajdywać się WebSphere Business Monitor, który pozwala na stworzenie modelu monitoringu, dzięki czemu można śledzić procesy zachodzące w systemie ESB. Z rodziny oprogramowania WebSphere zostały wybrane WebSphere Process Server oraz Websphere Integration Developer, które są wystarczające do stworzenia systemu ESB WebSphere Process Server Websphere Process Server, w skrócie WPS, jest produktem rozszerzającym funkcjonalnie Websphere Eterprise Service Bus (WESB), natomiast z technicznego punktu widzenia, jest zbudowany na bazie Websphere Application Servera. W związku z tym oferuje praktycznie kompletny zestaw cech opisanych przez wzorzec projektowy ESB, m.in. [10]: Wsparcie rozmaitych protokołów i technik komunikacyjnych takich jak różni providerzy JMS, Websphere MQ, TCP/IP, SSL, HTTP(S), multicast, Różne rodzaje modeli interakcji (request/reply, point-to-point, publish/subscribe oraz multicast), Wsparcie dla web serwisów: SOAP/HTTP, SOAP/JMS, WSDL, XSD, Web Services Gateway, a także WS-Security, WS-Atomic Transactions i UDDI, Dostępność dużej ilości gotowych adapterów opartych o JCA, Wiele wbudowanych schematów mediacji komunikatów. Poza funkcjonalnością WESB, WPS oferuje również inne funkcje, bardzo istotne przy integracji usług biznesowych, m.in. [8] [9]: Biznesowa Maszyna Stanów - projektowanie procesu biznesowego jako sekwencji stanów i zdarzeń, Procesy Biznesowe - silnik oparty o WS-BPEL służący do uruchamiania krótko- i długotrwałych procesów biznesowych, Zadania Realizowane przez Ludzi (ang. human tasks) - projektowanie i włączanie do procesu biznesowego zadań, które muszą zostać wykonane przez człowieka, razem z odpowiednim interfejsem do nich i integracją z innymi aplikacjami, Zasady Biznesowe (ang. business rules) - wprowadzanie zasad wymuszających określoną politykę biznesową. 23

24 2.4.2 WebSphere Integration Developer Websphere Integration Developer, zwany czasem również po prostu WID, jest zaawansowanym środowiskiem programistycznym do integracji aplikacji w środowisku SOA. Jest to narzędzie służące do projektowania aplikacji uruchamianych na WESB i WPS. Jest ono zbudowane na bazie IBM Rational Aplication Developer, który z kolei opiera się na Eclipse IDE. Oto najciekawsze z jego możliwości [11] [12]: Upraszcza integrację adaptowanych serwisów dzięki ich graficznej reprezentacji jako komponenty, ułatwiając w ten sposób ponowne wykorzystanie istniejących fragmentów, Umożliwia integratorom projektowanie złożonych rozwiązań biznesowych - procesów, mediacji, adapterów - wymagając zarazem minimalnych umiejętności programistycznych, Umożliwia konstrukcję procesów i rozwiązań integracyjnych za pomocą techniki przenieś i upuść (ang. drag-and-drop). Teoretycznie więc nie jest wymagana znajomość języka Java, Umożliwia szybkie tworzenie projektów dzięki graficznemu łączeniu komponentów, Umożliwia zintegrowane testowanie, debuggowanie i deployment aplikacji. Jak się okaże w dalszej części pracy, nie wszystko jednak da się zrealizować za pomocą WIDa łatwo, bezproblemowo i unikając samodzielnego tworzenia kodu. 24

25 3 Opis problemu W rozdziale tym został opisany konkretny przypadek biznesowy, który będzie następnie implementowany w oparciu o ESB oraz w modelu integracji statycznej. Dotyczy on łączenia w jeden system rozproszonych aplikacji dostępnych poprzez sieć komputerową. Aby pokazać szerokie spektrum integracji serwisów internetowych zostały wykorzystane zarówno serwisy dostarczające klientom interfejs web serwis jak i takie, które go nie dostarczają. Coraz więcej serwisów internetowych nie ogranicza się jedynie do świadczenia usług poprzez aplikację webową, której użytkownik może używać za pomocą przeglądarki internetowej, ale dostarczają również API dla programistów. Takie rozwiązanie pozwala niezależnym programistom lub firmom na tworzenie innych aplikacji korzystających z danego serwisu. Dlaczego zwykła aplikacja webowa może się okazać niewystarczająca? Z dwóch powodów. Po pierwsze niektórzy klienci mogą mieć potrzebę korzystania z danej usługi w inny sposób, np. używając aplikacji stacjonarnej (tzw. gruby klient), albo dedykowanego klienta w urządzeniu mobilnym (gdzie korzystanie z przeglądarki internetowej jest utrudnione przez wzgląd na niewielkie rozmiary wyświetlacza). Drugim powodem tworzenia dodatkowych programów wykorzystujących API dla programistów jest chęć zaspokojenia konkretnych wymagań funkcjonalnych wąskiej, specyficznej grupy użytkowników. Przykładem mogą być tutaj serwisy aukcyjne i potrzeby sprzedawców, którzy nieraz potrzebują wystawić na sprzedaż kilkaset produktów o minimalnie różniących się cechach. Łatwo wyobrazić sobie jak nużącym zajęciem musiałoby to być bez pomocy wyspecjalizowanego programu. Podobnych grup użytkowników i ich specyficznych wymagań można oczywiście wskazać znacznie więcej. Rozważona została również sytuacja, gdy autor serwisu nie dostarcza wsparcia dla programistów, a integracja takiej aplikacji internetowej (dynamicznej strony internetowej) z innymi serwisami jest również z jakichś przyczyn konieczna. Celem aplikacji projektowanej w ramach niniejszej pracy jest wyszukiwanie informacji dotyczących produktów interesujących użytkownika w wybranych serwisach internetowych. Wszystkie serwisy wykorzystywane w aplikacji są odpytywane pod kątem ustalonego kryterium, w tym przypadku słów kluczowych. Użytkownikowi są dostarczane pełne nazwy produktów spełniających zadane kryterium, ich ceny oraz adresy stron internetowych. Dzięki temu użytkownik ma możliwość porównać oferty serwisów oraz skierować się bezpośrednio do lokalizacji umożliwiającej zakup, a nie musi osobno przeglądać każdego 25

26 serwisu. Przykład Potencjalny kupujący jest zainteresowany pamięcią RAM do swojego laptopa. W tym celu musiałby przeszukać popularne sklepy internetowe i serwisy aukcyjne pod katem słów kluczowych ram sodimm 1gb. Oczywiście zrobienie tego ręcznie jest dość kłopotliwe, natomiast stworzona aplikacja po podaniu wcześniej wymienionej frazy mogłaby zwrócić wynik jak ten przedstawiony w tabeli poniżej: Nazwa produktu Cena PLN Adres internetowy produktu SODIMM RAM Samsung 1GB item html Pamiec SODIMM Kingston 1gb item html Memory SODIMM Kingston 1gb (2x512) item html GOODRAM sodimm 1gb sodimm 32.html Tabela 1: Przykładowy wynik działania aplikacji Domeną, jaka została wybrana do realizacji naszych badań, został obszar handlu internetowego, a więc potencjalnymi usługodawcami były serwisy aukcyjne oraz różnego rodzaju sklepy internetowe. Do integracji z szyną ESB wybrano trzy popularne serwisy: Amazon sklep internetowy dostępny pod adresem ebay serwis aukcyjny dostępny pod adresem Allegro serwis aukcyjny dostępny pod adresem Pokrywają one pewien podzbiór funkcjonalności ściśle związanej z e-commerce, a przy tym różnią się między sobą ze względu na wykorzystaną technologię, lokalizację czy funkcjonalność. Dzięki tej różnorodności spojrzenie na zagadnienia związane z integracją aplikacji jest pełniejsze. Ponadto podjęta została próba podłączenia sklepów internetowych oferujących swoje usługi jedynie przez serwis www. Poniżej zostają omówione wszystkie z integrowanych serwisów z punktu widzenia ich zastosowania w tworzonym systemie. 26

27 3.1 Amazon Ten popularny sklep internetowy, prócz strony internetowej, oferuje swoim klientom dostęp do wielu funkcji poprzez web serwis. Najciekawsze z nich zostały pokrótce omówione w tabeli 2. Nazwa Amazon Associates Amazon DevPay Amazon Elastic Compute Cloud Amazon Flexible Payments Service Amazon Fulfillment Web Service Amazon Mechanical Turk Amazon SimpleDB Alexa Site Thumbnail Alexa Top Sites Alexa Web Information Service Alexa Web Search Zastosowanie Udostępnia dane produktów Amazon a także funkcjonalność związaną z e-commerce. Służy do tworzenia billingów i zarządzania kontem dla programistów. Ułatwia skalowanie aplikacji. Umożliwia dokonywanie płatności. Umożliwia handlarzom dostęp do usługi Fulfillment by Amazon (FBA). Udostępnia zasoby ludzkie. Można z niego korzystać tam, gdzie wykorzystanie ludzkiej inteligencji jest niezbędne do osiągnięcia celów biznesowych. Umożliwia uruchamianie zapytań na ustrukturyzowanych danych w czasie rzeczywistym. Działa w ścisłej współpracy z serwisami umożliwiającymi skalowanie. Dostęp do kolekcji ikon produktów. Statystyki popularności stron internetowych. Dane dotyczące ruchu oraz struktury w sieci. Wyszukiwarka internetowa. Tabela 2: Web serwisy dostępne w Amazon Dla celów pracy został wybrany Amazon Associates Web Service, ze względu na to, że jest bezpłatny. Umożliwia on także zaawansowane wyszukiwanie produktów, udostępnia szczegółowe informacje o nich, dostęp do zdjęć produktów, koszyka kupującego Amazon co w zupełności wystarcza do celów realizowanej aplikacji. Spis oferowanych przez ten 27

28 web serwis metod znajduje się w tabeli 3. Nazwa metody Przeznaczenie BrowseNodeLookup Zwraca nazwę kategorii danej jako ID. CartAdd Dodanie produktu do zdalnego koszyka. CartClear Usunięcie wszystkich produktów ze zdalnego koszyka. CartCreate Utworzenie zdalnego koszyka. CartGet Sprawdzenie zawartości zdalnego koszyka. CartModify Edycja zawartości zdalnego koszyka. CustomerContentLookup Pobranie wszelkich upublicznionych danych dotyczących klienta. CustomerContentSearch Wyszukiwanie klientów. Help Pomoc dotycząca Amazon Associates Web Service. ItemLookup Informacje dotyczące danego produktu. ItemSearch Wyszukiwanie produktów. ListLookup Pobieranie szczegółów dotyczących danej listy produktów. ListSearch Wyszukiwanie listy produktów zdefiniowanych przez podanego uzytkownika. SellerListingLookup Pobieranie szczegółów dotyczących danej listy produktów sprzedawcy. SellerListingSearch Wyszukiwanie listy produktów zdefiniowanych przez podanego sprzedawcę. SellerLookup Zwraca informacje dotyczące konkretnego sprzedawcy. SimilarityLookup Wyszukiwanie podobnych produktów. TagLookup Wyszukiwanie produktów po etykietkach. TransactionLookup Wyszukiwanie zawartych transakcji. Tabela 3: Metody serwisu Amazon Associates Web Service Autoryzacja i autentykacja w Amazon bazuje na generowanych dla każdego użytkownika klucze alfanumeryczne Access Key ID oraz Secret Access Key (ten ostatni tylko dla 28

29 niektórych metod). Access key ID jest przekazywany jako parametr wywoływanej metody. Możliwe jest również wykorzystanie w tym celu certyfikatów. 3.2 ebay Jest to bardzo popularny i rozbudowany serwis posiadający oddziały w wielu krajach (również w Polsce). Portal ten udostępnia 3 rodzaje web serwisów, są one opisane w tabeli 4. Nazwa Shopping Trading Research Zastosowanie Wyszukiwanie produktów, uzyskiwanie szczegółowych danych dotyczących produktów. Udostępnia zaawansowane funkcje związane z prowadzeniem sprzedaży. Uzyskiwanie historycznych danych dotyczących sprzedaży. Tabela 4: Web serwisy udostępnione przez ebay Serwis Shopping umożliwia wyszukiwanie produktów w zupełności wystarczające dla potrzeb aplikacji, poza tym jest dostępny nieodpłatnie. Dlatego też został on wytypowany jako jeden z serwisów działających w ramach tworzonej aplikacji. Jego metody są opisane w tabeli 5. 29

30 Nazwa metody FindHalfProducts FindItems FindItemsAdvanced FindPopularItems FindPopularSearches FindProducts FindReviewsAndGuides GetCategoryInfo GeteBayTime GetItemStatus GetMultipleItems GetShippingCosts GetSingleItem GetUserProfile Przeznaczenie Przeszukuje serwis Half.com w celu uzyskania informacji dotyczących danego produktu. Wyszukuje produkty na podstawie odpowiednich kryteriów. Zaawansowane wyszukiwanie produktów. Wyszukiwanie popularnych produktów. Zwraca najczęściej używane przez kupujących frazy przy wyszukiwaniu produktów. Dostarcza informacji związanych ze szczególnym produktem. Wyszukuje recenzje i poradniki. Zwraca informacje dotyczące danej kategorii. Zwraca oficjalny czas ebay w GMT Umożliwia uzyskanie statusu grupy produktów. Pobiera publicznie dostępne dane dotyczące jednego lub większej ilości produktów. Pobiera cenę przesyłki dla produktu. Pobiera publicznie dostępne dane dla jednego produktu. Umożliwia pobranie profilu użytkownika. Tabela 5: Metody udostępniane przez web serwis ebay Shopping Do autoryzacji użytkowników wykorzystywane jest duża liczba identyfikatorów: AppID, CertID, DevID i inne. Są one przekazywane w nagłówku (ang. header) komunikatu SOAP, a także jako parametr HTTP w adresie URL. 3.3 Allegro Allegro jest polskim serwisem aukcyjnym, chociaż istnieją również jego wersje w innych krajach. Posiada jeden web serwis, jednak dostępna funkcjonalność podzielona jest na kilka kategorii (tzw. pakiety). Są nimi: pakiet podstawowy, pakiet osobisty, pakiet profesjonalny, pakiet pełny. Najuboższy podzbiór funkcjonalności jest dostępny bezpłatnie, natomiast bardziej zaawansowane funkcje mogą być wykorzystywane za dodatkowa opłatą. 30

31 Dla potrzeb rozważanego problemu informatycznego w zupełności wystarcza pakiet podstawowy i osobisty, które też są wykorzystywane w implementacji. Opis ich najważniejszych metod znajduje się w tabeli 6. Nazwa metody dogetcountries dogetitemsinfo dogetpaymentdata dogetserviceinfo dogetserviceinfocategories dogetsystemtime dogetuserid dogetuseritems dologin donewauction dosearch Przeznaczenie Zwraca wszystkie kody krajów dostępne w serwisie. Udostępnia informacje dotyczące produktów. Zwraca akceptowalne formy płatności. Zwraca informacje o serwisie. Zwraca kategorie dostępne w serwisie. Zwraca czas serwera. Zwraca identyfikator użytkownika. Zwraca wszystkie aukcje należące do danego użytkownika. Umożliwia zalogowanie się w serwisie. Umożliwia utworzenie nowej aukcji. Umożliwia przeszukiwanie aukcji. Tabela 6: Niektóre metody udostępniane przez web serwis Allegro, pakiet podstawowy i osobisty Aby móc korzystać z serwisu trzeba wystąpić do Allegro o przyznanie specjalnego klucza specyficznego dla użytkownika, tzw. webapi-key, dołączanego do wywołań większości metod. Jest to sposób uwierzytelniania i autoryzacji użytkowników. 3.4 Sklepy internetowe Innym typem serwisów udostępniających informacje o dostępnych produktach są sklepy internetowe. Przedstawiają one oferty kupna przy wykorzystaniu stron WWW, co czyni je proste w użyciu dla zwykłych użytkowników komputera. Typowe sklepy internetowe umożliwiają wyszukiwanie produktów według nazwy, kategorii oraz przeszukiwanie całego katalogu produktów. Zazwyczaj nie posiadają one jednak wspólnego, dobrze opisanego interfejsu który byłby wymagany w przypadku integracji takich sklepów z innymi systemami. Czasami taki interfejs jest dostępny, ale nie jest publicznie udostępniony wszystkim użytkownikom. 31

32 Napisany został ogólny serwis umożliwiający podłączenie się do większości sklepów internetowych. Posiada on jeden wspólny interfejs dla wszystkich obsługiwanych serwisów, w wyniku czego łatwo jest obsłużyć dużą ilość sklepów internetowych na raz - pobranie danych z różnych serwisów różni się wyłącznie zestawem parametrów podanych do serwisu. 3.5 Serwis powiadomień Serwis ten został stworzony przez autorów niniejszej pracy jako przykład aplikacji projektowanej pod kątem przyszłej integracji z ESB. Stanowi on uzupełnienie wcześniej opisanych serwisów wyróżniające się właśnie tym, że nie jest ono zastaną aplikacją wymagającą zespolenia z tworzonym systemem, ale że od samego początku twórcom przyświecał cel udostępnienia jego funkcjonalności w środowisku SOA. Serwis może służyć do powiadamiania użytkowników o dowolnych zdarzeniach za pomocą dwóch różnych kanałów komunikacji: poczty elektronicznej i komunikatora internetowego Jabber. 32

33 4 Integracja Rozdział ten przybliża elementy implementacyjne związane z tworzeniem aplikacji. Przedstawione zostały wszystkie etapy jej powstawania wraz z napotykanymi przez twórców komplikacjami. Prócz zasadniczego tematu jakim jest konstrukcja oprogramowania przy pomocy szyny ESB, opisana została również wersja zrealizowana w oparciu o integrację klasyczną. 4.1 Przygotowanie serwisów do integracji Stworzenie aplikacji wyszukującej produkty w serwisach internetowych wymagało pewnych kroków przygotowawczych. W szczególności chodzi tutaj o przygotowanie adaptera EShopService pozwalającego na integrację ze sklepami internetowymi nie udostępniającymi interfejsów programistycznych oraz implementację serwisu powiadomień Notification- Service. Oba projekty zostały omówione w tej sekcji Implementacja EShopService EShopService to serwis stworzony w celu dostarczenia wspólnego interfejsu dla sklepów internetowych, które same w sobie nie posiadają interfejsu umożliwiającego programistom łatwą integrację z nimi. Definicja serwisu Serwis ten ma na celu połączenie się do wybranego sklepu internetowego oraz pobranie listy konkretnych produktów, które spełniają dane kryterium wyszukiwania. Pożądana jest wysoka konfigurowalność serwisu EShopService, tzn. możliwe powinno być podłączenie się do jak największej liczby sklepów internetowych. Niektóre sklepy posiadają gotowy interfejs za pomocą którego można pobrać ofertę, ale nie zawsze jest możliwość wykorzystania go z różnych powodów nietechnicznych (np. sklepy boją się, że ich dane zostaną użyte w niewłaściwy sposób). Z tego powodu, serwis EShopService korzysta z publicznie dostępnych dla każdego użytkownika sposobów pobierania danych (za pomocą protokołu HTTP) oraz służy jako adapter, dokonujący mediacji między protokołem HTTP/HTML a interfejsem serwisu (rysunek 10). Ogólny schemat działania EShopService pokazany jest na rysunku 7 Interfejs serwisu EShopService przedstawia się następująco: 33

34 Rysunek 7: Ogólny schemat działania EShopService public interface EshopService { public S t r i n g getxhtml ( S t r i n g productname, HttpConfiguration httpconfig ) ; } public Product [ ] getproducts ( S t r i n g productname, HttpConfiguration httpconfig, X s l t C o n f i g u r a t i o n x s l t C o n f i g ) ; Fragment kodu 3: Interfejs EShopService Metoda getxhtml zwraca pobraną stronę w postaci ciągu znaków. Metoda getproducts zwraca listę obiektów klasy Product, która zawiera w sobie nazwę oraz cenę produktu. public class Product { private S t r i n g name ; private S t r i n g p r i c e ; private S t r i n g u r l ; } Fragment kodu 4: Klasa Product Implementacja serwisu Pobranie danych Do pobierania danych z sklepu internetowego, zostało wykorzystane zwykłe żądanie HTTP, za pomocą którego każdy użytkownik jest w stanie wyszukać konkretny produktu z poziomu przeglądarki. Informacje o strukturze mogą zostać pobrane ze strony sklepu internetowego za pomocą analizy kodu HTML. Serwis posiada mechanizm 34