INŻYNIERIA OPROGRAMOWANIA W PROCESACH INTEGRACJI SYSTEMÓW INFORMATYCZNYCH Pod redakcją J. Górskiego, C. Orłowskiego, 2011 PWNT Gdańsk 1.KOMPOZYCJA I INTEGRACJA USŁUG W ARCHITEKTURZE SOA Ilona BLUEMKE, Wojciech KIERMASZ 1. Wprowadzenie Proces integracji systemów informatycznych polega na łączeniu pojedynczych systemów i aplikacji na płaszczyźnie fizycznej lub funkcjonalnej [3]. Od drugiej połowy lat dziewięćdziesiątych obserwujemy wzrost liczby systemów informatycznych wymagających komunikacji z innymi aplikacjami. W pracy [2] przedstawiono analizę użyteczności architektury zorientowanej na usługi SOA (ang. Service Oriented Architecture) podczas integracji systemów informatycznych. Zaprezentowano technologie integracyjne i stosowane rozwiązania oraz omówiono architekturę zorientowaną na usługi w kontekście integracji systemów. Przedstawiono także technologię usług sieciowych, jako implementację architektury, oraz wnioski dotyczące wykorzystania usług sieciowych przy integracji systemów informatycznych. Celem niniejszego rozdziału jest przestawienie kompozycji i integracji usług sieciowych w architekturze zorientowanej na usługi. Początkowa części rozdziału zawiera krótki opis architektury zorientowanej na usługi (SOA). Następnie przedstawiono kompozycję usług sieciowych: omówiono pojęcia orkiestracji i choreografii usług sieciowych. W dalszej części rozdziału krótko opisano szynę usług przedsiębiorstwa (ang. Enterprise Service Bus) ESB pozwalającą na integracje dostępnych usług. Niniejszy rozdział ma charakter przeglądowy. 2. SOA Architektura zorientowana na usługi SOA (Service Oriented Architecture).wprowadza koncepcje tworzenia systemów informatycznych w oparciu o interakcję pomiędzy odseparowanymi usługami. Usługą jest element oprogramowania działający niezależnie od innych, posiadający dobrze zdefiniowany interfejs, implementację oraz adres sieciowy (o ile została opublikowana) [5,9]. SOA definiuje trzy podstawowe wymagania architektury [1]: 1. zdefiniowanie warstwy transportowej składającej się z opisu formatu danych i protokołu, 2. stworzenie sposobu opisu usług zawierającego informacje między innymi o dostępnych operacjach i parametrach, 3. mechanizm publikowania i wyszukiwania usług. Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut Informatyki, e-mail: I.Bluemke@ii.pw.edu.pl.
2 I. Bluemke, W. Kiermasz Zdefiniowane standardy mają umożliwić interakcję pomiędzy niezależnymi i luźno powiązanymi usługami w obrębie danej implementacji SOA (Rys.1). Budując aplikacje rozproszone wyodrębniamy poszczególne zadania programu i rozdzielamy je na odrębne moduły. Następnie moduły te scalamy tworząc spójną i rozproszoną aplikację. SOA proponuje wytyczne, którym mają podlegać tworzone moduły. Podstawowe wymagania dla SOA wg [5] to: kontrakt, luźne powiązanie, abstrakcja, ponowne użycie, bezstanowość, odkrywalność oraz możliwość komponowania usług. Rys. 1 Architektura zorientowana na usługi Początkowe wykorzystanie architektury SOA przy tworzeniu aplikacji wiąże się ze zwiększonym nakładem pracy. Moduły wykorzystywane z poprzednich aplikacji muszą być przerobione na usługi. Implementacja nowej funkcjonalności też odbywa się w postaci usług. Istotne jest także prawidłowe zaprojektowanie usług tak, by można je było wykorzystać w przyszłości, czyli ich odpowiednia granulacja. Usługi nie powinny być zbyt małe, co skutkowałoby ich częstym wywołaniem i kłopotami z wydajnością systemu. Zbyt złożone usługi mogą się okazać nieprzydatne w przyszłości z uwagi na ich dużą specjalizację. Korzyścią SOA dla klientów jest możliwość zamawiania fragmentów systemu u różnych dostawców. Przy pomocy SOA łatwiejsze staje się modelowanie procesów biznesowych przez podział na usługi.. 3. Kompozycja usług sieciowych Wywoływanie udostępnionych usług może być koordynowane za pomocą mechanizmu kompozycji usług. Mechanizm ten zarządza wykonywaniem procesów biznesowych opartych na usługach z różnych systemów a całość jest udostępniona jako nowa usługa. Poniżej opisano budowę nowych, złożonych usług sieciowych za pomocą orkiestracji i choreografii. 3.1. Orkiestracja usług sieciowych Orkiestracja (ang. orchestration) zajmuje się modelowaniem interakcji pomiędzy usługami wewnątrz pojedynczego procesu biznesowego. Orkiestrację definiujemy następująco: An executable business process describing a flow from the perspective and under control of a single endpoint (commonly: Workflow) [6]. Orkiestracja dla kompozycji usług w danym procesie biznesowym wykorzystuje centralny komponent pełniący rolę koordynatora (Rys. 2).
1. Integracja systemów w architekturze zorientowanej na usługi 3 Rys. 2 Orkiestracja usług sieciowych - źródło [14] Orkiestracja umożliwia synchroniczne i asynchroniczne wywoływanie usług, przesyłanie wiadomości pomiędzy usługami z jednoczesną ich modyfikacją, obsługę błędów, sekwencyjne i równoległe wywoływanie usług. Orkiestracja jest rozwiązaniem analogicznym do diagramów przepływów z tą różnicą, że korzysta z usług sieciowych. W celu uproszczenia implementacji procesów biznesowych stworzono wysokopoziomowe języki modelowania procesów np. BPEL (Business Process Execution Language) [10]. Programista w języku opisuje mechanizmy koordynacji, interakcji i integracji funkcji biznesowych. Język BPEL powstał na podstawie dwóch wcześniejszych języków opisu systemów przepływu pracy: Web Services Flow Languages (WSFL) - języka grafowego opracowanego przez IBM, oraz XLANG - języka blokowego zaprojektowanego przez Microsoft. Najnowszy standard WS-BPEL 2.0 języka BPEL został oficjalnie przedstawiony w kwietniu 2007 roku. BPEL jest deklaratywnym językiem znaczników XML i umożliwia opis procesów biznesowych z wykorzystaniem Web Services (WS) [2,11,12]. Dzięki użyciu języka BPEL, proste usługi WS mogą być wykorzystane do zbudowania złożonej usługi, prezentowanej, jako usługa wyższego poziomu (Rys. 3) [12]. Technika ta nazywa się Business Proces as Web Service (proces biznesowy, jako usługa sieciowa). Rys. 3 Business Process as Web Service - źródło [12] Definicja procesu biznesowego w języku BPEL określa kolejność, w jakiej wykonywane są usługi WS. Usługi te mogą być wywoływane asynchronicznie i synchronicznie w zdefiniowanej kolejności. Opisany jest także przepływ danych między usługami wraz z ich manipulacją. Wiadomości wymieniane pomiędzy usługami mogą być skorelowane z pojedynczą instancją procesu biznesowego. Możliwe jest także definiowanie długotrwałych, stanowych procesów biznesowych. Istnieje również możliwość definiowania zachowań warunkowych. BPEL oferuje także tradycyjne konstrukcje pętli, deklaracje zmiennych, operacje podstawienia, obsługę wyjątków i inne. W narzędziach wspomagających tworzenie procesów biznesowych w języku BPEL procesy biznesowe wizualizowane są najczęściej w formie diagramów (Rys. 4).
4 I. Bluemke, W. Kiermasz Rys. 4 Diagram procesu biznesowego w języku BPEL BPEL pozwala na definicje dwóch rodzajów procesów biznesowych [10,11]: 1. Abstrakcyjne. Zawierają informacje, jakie wiadomości są wymieniane pomiędzy usługami, a procesem biznesowym. Nie definiuje jednak logiki biznesowej procesu. 2. Wykonywalne. W pełnie definiuje wymianę wiadomości, a także logikę biznesową procesu i jego działanie. Język BPEL składa się z pięciu głównych sekcji i odpowiednich elementów w nich: 1. Przepływ wiadomości (message flow): Invoke, Receive, Reply 2. Przepływ sterowania (control flow): Sequence, If-else, While, Pick, Flow 3. Przepływ danych (data flow): Variable, Assign 4. Orkiestracja procesów: PartnerLink 5. Obsługa błędów i wyjątków: Compensate, Throw, Rethrow, FaultHendlers Proces biznesowy BPEL jest zapisany w języku XML. Jego wykonanie wymaga umieszczenia go na odpowiedniej platformie uruchomieniowej, która dokona interpretacji dokumentu XML i przeprowadzi zapisane w nim czynności łącznie z komunikacją z odpowiednimi usługami sieciowymi. Takimi platformami są na przykład: Oracle BPEL Process Manager, Microsoft BizTalk, IBM BPWS4J, Apache Axis. Rozpoczęcie wykonywanie procesu BPEL może nastąpić w wyniku wywołania usługi pod postacią której eksponowany jest dany proces biznesowy. Wyzwalaczem może być również znacznik czasowy wewnątrz procesu.
3.2. Choreografia usług sieciowych 1. Integracja systemów w architekturze zorientowanej na usługi 5 Kolejną koncepcją kompozycji usług sieciowych i tworzenie procesów biznesowych jest choreografia (ang. choreography). Choreografia nie wykorzystuje centralnego koordynatora tylko zakłada, że każda usługa posiada wiedzę o jej roli w procesie biznesowym i w oparciu o nią komunikuje się z innymi usługami (Rys.5). Rys. 5 Choreografia usług sieciowych - źródło [14] W modelu tym każda usługa posiada fragment wiedzy o procesie biznesowym i według posiadanego schematu wywołuje kolejne usługi sieciowe tworząc ich kompozycje. W odróżnieniu od orkiestracji, choreografia umożliwia wyeksponowanie fragmentu procesu biznesowego opisującego interakcje z daną usługą na zewnątrz organizacji. W oparciu o otrzymany opis choreografii zewnętrzny podmiot może dokonać kompozycji usług sieciowych z usługami danej organizacji. Mechanizm choreografii usług sieciowych został opisany w specyfikacji WS-CDL (Web Service Choreography Description Language) [13] stworzonej przez W3C. Rys. 6 Orkiestracja i choreografia - źródło [12] Przedstawiona technologia kompozycji usług sieciowych przez orkiestrację dobrze sprawdza się wewnątrz organizacji, natomiast choreografia staje się użyteczna dla kompozycji WS pomiędzy różnymi organizacjami. Na tej podstawie można przedstawić model interakcji Rys. 6. 4. Szyna usług przedsiębiorstwa Tworząc systemy oparte na architekturze zorientowanej na usługi (SOA) pojawia się problem integracji. Dotyczy on najczęściej włączenia do nowo projektowanego systemu istniejących komponentów. Jednak nawet podczas tworzenia systemu od podstaw, problem integracji pojawia się w kontekście niezgodności produktów różnych dystrybutorów oraz możliwości przyszłego
6 I. Bluemke, W. Kiermasz rozszerzenia funkcjonalności. Rozwiązaniem jest zastosowanie jednego z gotowych wzorców dla architektur oprogramowania, które ułatwiają integrację komponentów. Jedną z pierwszych koncepcji było użycie jednostki centralnej, która nadzoruje przepływ i konwersję danych pomiędzy poszczególnymi modułami w systemie. Rozwinięciem tego rozwiązania jest zastosowanie wirtualnej szyny, która pozbawiona jest rdzenia będącego najsłabszym ogniwem systemu podatnym na awarie paraliżujące cały system i będącym często wąskim gardłem dla przepływu informacji. Takim rozwiązaniem jest Enterprise Service Bus (szyna usług przedsiębiorstwa) ESB (Rys.7). Termin szyna (ang. bus) nawiązuje do fizycznej szyny w architekturze komputera, która służy do komunikacji pomiędzy poszczególnymi urządzeniami. Korporacyjna szyna ma podobną funkcję, tylko na wyższym poziomie abstrakcji. Architektura SOA bazująca na ESB korzysta z warstwy pośredniej (ang. middleware) szyny, która jest nośnikiem komunikatów pomiędzy usługami tworzącymi system. Główną zaletą tego rozwiązania jest zredukowanie liczby bezpośrednich połączeń pomiędzy usługami potrzebnymi do poprawnego funkcjonowania systemu. ESB odpowiada za następujące funkcje [7]: wyznaczanie tras (ang. routing) dla wiadomości pomiędzy usługami, konwersję pomiędzy protokołami transportowymi, konwersję formatów wiadomości pomiędzy jednostkami, obsługę zdarzeń pochodzących od różnych uczestników systemu, utrzymanie jakości połączeń (ang. Quality of Service QoS) m.in. gwarancja dostarczenia wiadomości, zapewnienie bezpieczeństwa, transakcyjność, kolejkowanie wiadomości i ich przechowywanie w razie tymczasowej niedostępności modułu. Rys.7 Schemat koncepcyjny ESB źródło [7] ESB jest często przedstawiana jako infrastruktura rozproszona i przeciwieństwo struktury z jednostką centralną. Jak pokazano na Rys. 7 centrum ESB jest szyna, do której podłączeni są korzystający i oferujący usługi. Zazwyczaj ESB jest realizowana, jako szereg pomniejszych lokalnych jednostek współpracujących ze sobą. Jednostki te są połączone w klastry lub farmy serwerów [4], które są koordynowane przez inną jednostkę centralną. Tak więc różnica pomiędzy infrastrukturami sprowadza się do dodania pośredniej warstwy pomiędzy klientami a jednostką centralną kontrolującą przepływ informacji. Sama szyna stanowi jedynie szkielet infrastruktury. Do elementów, które odpowiadają za jej konfigurację i funkcjonowanie należą [7]: katalog usług (ang. Business Service Directory) zawierający listę i opis usług wchodzących w skład systemu, kompozycja procesów biznesowych opis sekwencji i elementów biorących udział w różnych procesach biznesowych, brama (ang. gateway) punkt dostępu zewnętrznego, który oprócz dostępu do oferowanych usług umożliwia łączenie większej ilości szyn w złożonych architekturach.
1. Integracja systemów w architekturze zorientowanej na usługi 7 W celu zapewnienia komunikacji pomiędzy usługami, ESB wymaga elementu odpowiedzialnego za ich lokalizację odpowiednik tablicy trasowania (ang. routing) w sieciach. Role tę pełni katalog usług. Katalog, oprócz lokalizacji, powinien zawierać opis, przeznaczenie i funkcje usług w ramach procesów biznesowych. Dynamiczna lokalizacja usług wchodzących w skład systemu sprawia, że podmiana poszczególnych elementów procesów biznesowych nie wymaga żadnej ingerencji w kompozycję usług, co znacznie redukuje koszty ewentualnej modyfikacji systemu. Katalog zapewnia także przyporządkowanie usług wchodzących w skład szyny do przestrzeni nazw tworząc ich hierarchizację. Tą funkcjonalność daje komponent nazywany ESB Namespace Directory (Rys. 8). Rys. 8 Elementy architektury ESB - źródło [7] Usługi są samodzielnymi jednostkami w systemie z interfejsem do komunikacji zewnętrznej. Mogą one pełnić funkcje techniczne, biznesowe, transakcyjne czy procesów wymagających ingerencji człowieka. Choreografia, czyli kompozycją, odpowiada za współpracę poszczególnych usług w celu wykonania pewnego procesu biznesowego. Jest ona wielopoziomowa proces składający się z kilku modułów sam może być częścią procesu na wyższym poziomie abstrakcji. Rolą Business Service Choreography (BSC) w ESB jest przechowywanie definicji i wykonywanie procesów biznesowych, których konfiguracja, przepływ danych i sekwencja wykonań są określone przez logikę biznesową [4]. Logika ta jest zamodelowana przy pomocy jednego z języków przeznaczonych do tego celu np. BPEL. BSC odpowiada za wywołanie zdefiniowanej sekwencji, określonych agregacji czy zapewnienie sprawnej komunikacji poprzez podział i ponowne składanie wiadomości, zapewnienie połączenia pomiędzy poszczególnymi usługami. Rolą bramy (ESB Gateway) jest zapewnienie zewnętrznego dostępu do funkcji biznesowych w korporacji oraz kontaktu usług wewnątrz ESB ze światem zewnętrznym. Komunikacja ta musi być kontrolowana i zabezpieczona poprzez zapewnienie logowania, zastosowanie ról, szyfrowania, itp. Brama jest interfejsem, który umożliwia przejście na wyższy poziom abstrakcji i traktowanie infrastruktury opartej na ESB jako pojedynczego elementu (Rys. 8). Pozwala to na kompozycję wielu szyn w ramach złożonych architektur. W prostszych rozwiązaniach, lub początkowej fazie implementacji szyny, obecność bramy nie jest konieczna dla funkcjonowania systemu. Wdrożenie infrastruktury ESB w organizacji jest związane z wieloma zaletami, a najważniejsze z nich to: możliwość szybkiego i relatywnie taniego wdrożenia istniejących systemów, duża elastyczność systemu przy wprowadzaniu zmian funkcjonalnych, rozwiązanie oparte jest na standardach, jest stale ulepszane, bardzo dobra skalowalność systemu,
8 I. Bluemke, W. Kiermasz zastosowanie jednego z istniejących rozwiązań ESB sprowadza wdrożenie szyny głównie do konfiguracji, przy znacznej redukcji programowania, brak jednostki centralnej zwiększa stabilność systemu, dodawanie nowych modułów do systemu nie wymaga wyłączenia/ponownego uruchamiania systemu. Do wad rozwiązań opartych na szynie usług przedsiębiorstwa należą: jeden format wiadomości (tzw. Enterprise Message Model), większa niż w architekturach z jednostką centralną ilość sprzętu, dodatkowa warstwa pośrednia zwiększająca opóźnienia w transmisji wiadomości z powodu konieczności zmian formatów i odszukania celu w szynie, znaczny nakładu środków do implementacji. 5. Podsumowanie Często stosuje się integrację systemów informatycznych w oparciu o SOA. W [2] omówiono i porównano stosowane rozwiązania integracyjne, przedstawiono wady i zalety tych rozwiązań, a także praktyczne aspekty ich wykorzystania. Integracja z użyciem usług sieciowych wymaga powszechności dostarczania przez systemy interfejsów w postaci WS. Powyżej przestawiono kompozycję i integrację usług sieciowych w SOA. Omówiono pojęcia orkiestracji i choreografii usług sieciowych oraz przestawiono różnice miedzy nimi. Zaprezentowano także szynę usług przedsiębiorstwa (ESB) stosowaną do integracji dostępnych usług. Orkiestracja dobrze sprawdza się wewnątrz organizacji, natomiast choreografia staje się użyteczna dla kompozycji WS pomiędzy różnymi organizacjami. Opis rzeczywistej integracji systemów opartej na SOA można znaleźć w [8]. Bibliografia [1] Adamczewski P.: Słownik informatyczny. HELION, 2005. [2] Bluemke I., Kiermasz W.: Integracja Systemów w architekturze zorientowanej na usługi, w Górski J., Orłowski C. (Eds.), Inżynieria oprogramowania w procesach integracji systemów informatycznych, PWNT, Gdańsk, str. 33-40, 2010. [3] Chandrasekaran A., Elias G., Cloutier R., Jain R.: Exploring the Impact of Systems Architecture and Systems Requirements on Systems Integration Complexity. IEEE SYSTEMS JOURNAL, ss. 209 224, 2008. [4] Chappell D.: Enterprise Service Bus, Reilly, 2004. [5] Erl T.: Service-Oriented Architecture (SOA), Prentice Hall, 2008. [6] Haas H., Brown A.: Web Services Glossary: http://www.w3.org/tr/2004/note-ws-gloss- 20040211/ [7] Keen M. et al.: Patterns: Implementing an SOA Using an Enterprise Service Bus.: International Business Machines Corporation, 2004 [8] Kiermasz W.: Integracja systemów informatycznych w architekturze zorientowanej na usług, praca dyplomowa magisterska, Instytut Informatyki PW, 2009. [9] Krill P.: InfoWorld. http://www.infoworld.com/article/06/05/17/78420_hnsoa20_1.html. (2007). [10] OASIS: Web Services Business Process Execution Language Version 2.0 - OASIS Standard, http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html, (2011, lipiec). [11] Papazoglou M. P.: Web services principles and technology, Harlow, 2008. [12] Pires L.F., et all. : Materiały do wykładu Business integration with web services, University of Twente, 2007. [13] W3C Web Services Choreography Working Group: http://www.w3.org/tr/ws-cdl-10/, (2011, lipiec). [14] Zakrzewicz M.: Implementacja aplikacji biznesowych w technologii WS-BPEL, w "Web Services: Projektowanie i implementacja architektur zorientowanych na usługi", Warszawa, 2006.
1. Integracja systemów w architekturze zorientowanej na usługi 9 Kompozycja i integracja usług w architekturze zorientowanej na usługi I. Bluemke*, W. Kiermasz* *Politechnika Warszawska, Instytut Informatyki, e-mail: I.Bluemke@ii.pw.edu.pl Rozdział 5. Kompozycja i integracja usług w architekturze zorientowanej usługi. Celem niniejszego rozdziału jest przedstawienie kompozycji i integracji usług sieciowych w architekturze zorientowanej na usługi która bardzo często jest wykorzystywana do integracji systemów informacyjnych. W pierwszej części rozdziału w skrócie opisano SOA. Następnie przedstawiono kompozycję usług sieciowych: omówiono pojęcia orkiestracji i choreografii usług sieciowych. Przestawiono różnice miedzy orkiestracją i choreografią usług. W dalszej części rozdziału krótko opisano szynę usług przedsiębiorstwa (ang. Enterprise Service Bus) ESB pozwalającą na integracje dostępnych usług. Composition and integration of services in Service Oriented Architecture I. Bluemke*, W. Kiermasz* *Warsaw University of Technology, Institute of Computer Science, e-mail: I.Bluemke@ii.pw.edu.pl Chapter 5. Composition and integration of services in Service Oriented Architecture. The aim of this chapter is to present the composition and the integration of services in Service Oriented Architecture, which is widely used for the integration of information systems. The first part contains a brief description of the Service Oriented Architecture. Further the composition of services is presented. The orchestration and choreography of web services are discussed. The differences are pointed out. Next the Enterprise Service Bus is presented as a means to integrate all available services. Finally some conclusions are given.