1.INTEGRACJA SYSTEMÓW W ARCHITEKTURZE ZORIENTOWANEJ NA USŁUGI

Transkrypt

1 INŻYNIERIA OPROGRAMOWANIA W PROCESACH INTEGRACJI SYSTEMÓW INFORMATYCZNYCH Pod redakcją J. Górskiego, C. Orłowskiego, 2010 PWNT Gdańsk 1.INTEGRACJA SYSTEMÓW W ARCHITEKTURZE ZORIENTOWANEJ NA USŁUGI Ilona BLUEMKE, Wojciech KIERMASZ 1. Wprowadzenie Współczesne oprogramowanie musi współpracować z wieloma systemami informatycznymi. Proces integracji systemów informatycznych definiuje się jako łączenie pojedynczych systemów i aplikacji na płaszczyźnie fizycznej lub funkcjonalnej [3]. Od drugiej połowy lat dziewięćdziesiątych obserwujemy znaczący wzrost systemów informatycznych wymagających komunikacji z innymi aplikacjami. Niniejszy rozdział ma charakter przeglądowy. Zawiera analizę użyteczności architektury zorientowanej na usługi dla integracji systemów informatycznych. W pierwszej części rozdziału zaprezentowano technologie integracyjne i stosowane rozwiązania. Omówiono architekturę zorientowaną na usługi w kontekście integracji systemów. Następnie przedstawiono technologię usług sieciowych jako implementację tej architektury. Rozdział kończą wnioski dotyczące zastosowania architektury zorientowanej na usługi a w szczególności wykorzystania usług sieciowych dla integracji systemów informatycznych. 2. Integracja systemów informatycznych Integrowane mogą być systemy informatyczne wewnątrz organizacji lub znajdujące się w różnych organizacjach. Integracja może dotyczyć informacji oraz procesów biznesowych. Integracja informacji koncentruje się na przepływie danych pomiędzy systemami, natomiast dla procesów biznesowych skupia się na koordynacji wykonania kolejnych kroków procesu, gdzie poszczególne kroki mogą być wykonywane przez różne aplikacji. Integracja systemów informatycznych musi obecnie radzić sobie z rozlicznymi problemami [7] np: z zawodnością czy szybkością sieci. Integrowane systemy są często umieszczone na oddzielnych komputerach. Komunikacja między nimi odbywa się za pośrednictwem sieci a dane mogą być przesyłane poprzez linie telefoniczne, sieć LAN, routery, przełączniki, sieci publiczne i satelitarne. Przesyłanie danych poprzez sieć jest wielokrotnie wolniejsze niż wewnątrz jednej maszyny. Innym problemem są różnice integrowanych aplikacji. Rozwiązania integracyjne muszą przekazywać informacje pomiędzy aplikacjami zbudowanymi w różnych językach Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut Informatyki, I.Bluemke@ii.pw.edu.pl.

2 2 I. Bluemke, W. Kiermasz programowania, działającymi na innych systemach operacyjnych i stosującymi odmienne formaty danych. Kolejnym problemem do rozwiązania są ciągłe zmiany jakim podlegają aplikacje. Integracja musi nadążać za tymi zmianami. W wyniku integracji zmiana w jednym systemie może spowodować niepożądane skutki w pozostałych powiązanych systemach. Rozwiązania integratorskie musza minimalizować zależności pomiędzy systemami poprzez stosowanie luźnych powiązań. Wyżej wymienionym problemom starają się sprostać następujące rozwiązania: Transfer plików. Jedna aplikacja zapisuje plik, a inna odczytuje go. Aplikacje muszą uzgodnić między sobą nazwę pliku, jego lokalizację, format oraz czas, kiedy zostanie on zapisany i odczytany, a także która aplikacja go usunie. Współdzielone bazy danych. Wiele aplikacji używa tej samej fizycznie bazy danych. Dane nie są powielane, toteż nie muszą być przesyłane pomiędzy aplikacjami. Zdalne wywoływanie procedur. Jedna z aplikacji udostępnia część swojej funkcjonalności w postaci procedury. Procedura ta może być zdalnie wywołana przez inną aplikację. Komunikacja odbywa się w czasie rzeczywistym i jest synchroniczna. Komunikaty (wiadomości). Jedna z aplikacji publikuje wiadomość w kanale komunikacyjnym (message channel). Inne aplikacje odczytują zapisane tam wiadomości. Wcześniej musi być uzgodniony format wiadomości jak i kanały komunikacyjne. Komunikacja jest asynchroniczna. Każde z wyżej wymienionych rozwiązań ma liczne zalety, ale także i wady. W niniejszym rozdziale przeanalizowane zostaną rozwiązania oparte na wiadomościach, szczególnie te, wykorzystujące usługi sieciowe. Szczegółową analizę pozostałych rozwiązań można znaleźć w [7]. Komunikacja oparta na wiadomościach uważana jest za dobre rozwiązanie dla integracji systemów. Jej zalety są następujące: Zdalna komunikacja. Wiadomości umożliwiają komunikację i transfer informacji pomiędzy dwoma różnymi aplikacjami, znajdującymi się w różnych lokalizacjach. W systemie opartym na komunikatach cała transmisja danych przeprowadzana jest poza aplikacją przez dedykowaną do tego celu platformę integracyjną. Integracja różnych platform/języków. Integracja poprzez komunikaty może być użyta w celu mapowania i transformacji danych do odpowiedniego formatu. Komunikacja asynchroniczna. Nadawca wiadomości nie musi czekać, aż odbiorca ją odbierze. Wystarczy, że umieści ją w kanale komunikacyjnym i może kontynuować swoje działanie. Koordynacja transmisji. Przy zastosowaniu komunikacji synchronicznej nadawca oczekuje na przetworzenie zapytania przez odbiorcę zanim wykona kolejne działania, co jest synchronizowane przez platformę integracyjną. Zapobieganie przeciążeniom. Odbiorca samodzielnie pobiera z kolejki komunikatów kolejne wiadomości, co zapobiega jego przeciążeniu. Niezawodna komunikacja. Podczas komunikacji z użyciem kanałów komunikacyjnych wiadomość jest zapisywana po stronie nadawcy, a następnie po stronie odbiorcy. Dopiero po otrzymaniu potwierdzenia doręczenia wiadomość jest usuwana przez nadawcę. Jeśli nadawca nie otrzyma potwierdzenia doręczenia wiadomości wysyłana jest ona ponownie. Komunikacja rzadka. Niektóre aplikacje nie działają w stałym połączeniu z siecią zapewniającą komunikacje. Mogą one działać na przykład na urządzeniach przenośnych, które podłączane są do sieci raz na pewien czas, w celu pobrania danych. W takim przypadku system oparty na kolejce komunikatów jest idealny. W momencie uzyskania połączenia z siecią, aplikacja pobiera wcześniej nagromadzone w kolejce komunikatów wiadomości. Pośrednictwo. System zajmujący się dostarczaniem wiadomości odgrywa rolę pośrednika pomiędzy nadawcą i odbiorcą. W przypadku, gdy któraś z aplikacji straci połączenie z siecią, po jego odzyskaniu, wystarczy że połączy się z systemem integratorskim. System ten może

3 1. Integracja systemów w architekturze zorientowanej na usługi 3 dostarczać także wiele innych funkcji np. może przekazywać wiadomości do systemów rezerwowych, jeśli któryś z podstawowych jest nieosiągalny czy równoważyć obciążenia systemów. Powyżej wymieniono korzyści wynikające z komunikacji przy użyciu wiadomości. Rozwiązanie to ma także pewne wady wynikające z komunikacji asynchronicznej. Asynchroniczna komunikacja wymaga zastosowania modelu opartego na zdarzeniach (eventdrive). Logika aplikacji nie może być zawarta w ciągu wywołań procedur lecz musi być rozbita na elementy zajmujące się obsługą nadchodzących zdarzeń, które są odpowiedziami na wcześniej wysłane zapytania co skutkuje skomplikowaną architekturą. Wiadomości przekazane jedna po drugiej do różnych kolejek mogą zostać obsłużone w dowolnej kolejności. Jeśli dla logiki aplikacji istotna jest kolejność obsługi zapytań to dodatkowy mechanizm zarządzania wiadomościami musi się tym zajmować. Niektóre zapytania muszą być obsłużone w sposób synchroniczny, dlatego wiele systemów opartych na komunikatach dostarcza taką możliwość. Opakowywanie danych w wiadomość i późniejsze ich rozpakowywanie odbywa w pewnym skończonym czasie zależnym od dostępnych zasobów. Podczas przesyłania dużej ilości danych w krótkim czasie może to być zbyt wolne. Systemy do komunikacji przez komunikaty działają w większości w oparciu o protokół specyficzny dla danego produktu. Nie mogą się one komunikować między sobą lub wymagają specjalnych mostów dla komunikatów (message bridges). Integracja systemów z użyciem komunikatów stała się powszechnie stosowanym rozwiązaniem. Dostępne na rynku rozwiązania możemy podzielić używając następujących kategorii: Systemy operacyjne - wiele systemów operacyjnych zawiera komunikację przy pomocy komunikatów np. Microsoft Message Queuing MSMQ w Microsoft Windows. Serwery aplikacyjne - oparte na J2EE, np. IBM WebSphere i BEA WebLogic, umożliwiają komunikację z użyciem JMS (Java Messaging Service). Narzędzia EAI - specjalistyczne systemy przeznaczone do integracji np.: IBM WebSphere, TIBCO, Microsoft BizTalk, SeeBeyond, Cross Worlds. Narzędzia dla usług sieciowych. Poprzez standaryzację wiadomości, metod ich przesyłania i zarządzania stają się one coraz bardziej popularne i są wspierane przez wszystkie największe firmy dostarczające oprogramowanie integratorskie Rozwiązania integracyjne Stosowane obecnie rozwiązania integratorskie można podzielić [7] na następujące typy: portale informacyjne, replikacje danych, współdzielona logika biznesowa, architektura zorientowana na usługi, rozproszone procesy biznesowe, integracja Business-to-Business. W portalu informacyjnym informacje z wielu źródeł są agregowane i udostępniane przy pomocy jednolitego interfejsu np. strony WWW. Strona może składać się z modułów reprezentujących różne systemy. Z punktu widzenia użytkownika korzysta on z jednego systemu zwłaszcza, jeśli zostało zastosowane zintegrowane logowanie. W przypadku, kiedy dla integracji systemów potrzebna jest synchronizacja danych, stosuje się ich replikacje. Przykładem mogą być np. dane adresowe klienta, które wykorzystywane są w systemie bilingowym i CRM (Client Relationship Management). Przechowywanie danych obydwu aplikacji w jednym miejscu nie jest dobrym rozwiązaniem. Problemem jest między innymi różny model danych w aplikacjach. Może się on również zmieniać w kolejnych wersjach aplikacji, co w przypadku wspólnej składnicy danych spowodowałoby błędne działanie jednego z systemów. Rozwiązaniem są oddzielne, synchronizowane składnice danych. W celu replikacji używa się mechanizmów wbudowanych w niektóre bazy danych. Stosuje się również mechanizm ETL (Extract, Transform, and Load), a także przesyłanie danych w komunikatach.

4 4 I. Bluemke, W. Kiermasz Podobnie jak wiele systemów używa tych samych danych, często aplikacje implementują tę samą logikę biznesową. W ramach integracji systemów zastępuje się redundantne procesy biznesowe przez jeden proces. Wspólne dla integrowanych systemów funkcje biznesowe mogą być wyeksponowane, jako usługi sieciowe. Jest to szczególny przypadek integracji wspólnej logiki biznesowej przy użyciu architektury zorientowanej na usługi (Service Oriented Architecture, SOA). Rys. 1 przedstawia schemat takiej integracji. Wspólne elementy obydwóch systemów wyodrębnione są jako niezależne usługi. Systemy te eksponują także własne interfejsy w postaci usług. Rys. 1 Architektura zorientowana na usługi W przedstawionych powyżej rozwiązaniach integracja opierała się na wywoływaniu udostępnianych przez aplikacje funkcjonalności. 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. Wszystkie wyżej omówione integracje dotyczyły systemów wewnątrz jednej organizacji. Często jednak funkcje biznesowe dostarczane są przez inne organizacje. W takich przypadkach występuje integracja B2B (Business-to Business). Wiele z wyżej wymienionych rozwiązań znajduje swoje zastosowanie także w integracji systemów między organizacjami. Integracja B2B jest jednak wyróżniona, jako oddzielny przypadek, gdyż musi rozwiązywać problemy związane z bezpieczeństwem i różnorodnością protokołów transportowych Integracja aplikacji w przedsiębiorstwie Integracja aplikacji w przedsiębiorstwie - Enterprise Application Integration EAI to rozwiązanie informatyczne integrujące aplikacje i dane w jeden spójny zestaw procesów biznesowych [4]. Umożliwia współdzielenie danych wielu systemów informatycznych oraz automatyzację rozproszonych w ramach firmy procesów biznesowych. Celem EAI jest przekształcenia aplikacji w organizacji w jedną spójną strukturę. EAI przeprowadza integrację poprzez procesy biznesowe. Pojedyncza aplikacja podlegająca integracji przez EAI nazywa się Enterprise Information System (EIS). Rys. 2 przedstawia typowe rozwiązanie EAI w obrębie organizacji. EAI implementuje logikę integracyjną, która określa dynamicznie przepływ na podstawie analizy przesyłanych danych. EAI często opiera się na centralnej platformie integracyjnej, która zawiera broker komunikatów wykonujący zdefiniowaną logikę integracyjną. Inne, często realizowane zadanie EAI to integracja systemów pomiędzy różnymi organizacjami.

5 1. Integracja systemów w architekturze zorientowanej na usługi 5 3. Usługi sieciowe Rys. 2 Typowa architektura EAI Pierwszą technologią umożliwiającą budowanie aplikacji zbudowanej z modułów komunikujących się przez sieć było RPC (Remote Procedure Call). Utworzony w latach osiemdziesiątych protokół RPC umożliwiał rozproszenie systemu pomiędzy różne maszyny i jest uznany, jako podstawa technologiczna dla później zaproponowanej architektury zorientowanej na usługi SOA (Service Oriented Architecture). Kolejnym etapem było wprowadzenie architektury klient-serwer opartej na API (Application Programming Interface) udostępnianym przez serwer. API można określić, jako zbiór usług dostępnych dla klienta poprzez określony protokół. Następnie popularność zdobyło programowanie obiektowe i idea wielokrotnego wykorzystania modułów. Microsoft stworzył architekturę rozproszonych obiektów (komponentów) DCOM (Distributed Component Object Model). Object Management Group (OMG) opracowała architekturę usługową o nazwie CORBA (Common Object Request Broker Architecture) (1991). Pozwalała ona na pełną uniwersalność a jednocześnie wymagała od programisty samodzielnej organizacji struktury rozproszonej. Kolejną architekturą była Java 2 Enterprise Edition (J2EE), która umożliwiała osadzanie modułów w serwerach aplikacyjnych różnych firm. Ważnym momentem było powstanie standardu usług sieciowych WS (Web Services). Dzięki całkowitemu oddzieleniu w nim warstwy transportowej i użyciu protokołu HTTP możliwe jest komunikowanie się pomiędzy implementacjami w różnych technologiach i domenach. WS stworzone zostały w oparciu o ideę SOA. Wówczas też zostały zdefiniowane dokładne wymagania SOA. Szczegółowa historia powstania SOA znajduje się w pracy [6] SOA Architektura zorientowana na usługi 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) [9]. SOA definiuje trzy podstawowe wymagania architektury [1]: zdefiniowanie warstwy transportowej składającej się z opisu formatu danych i protokołu, stworzenie sposobu opisu usług zawierającego informacje między innymi o dostępnych operacjach i parametrach, mechanizm publikowania i wyszukiwania usług. Zdefiniowane standardy mają umożliwić interakcję pomiędzy niezależnymi i luźno powiązanymi usługami w obrębie danej implementacji SOA.

6 6 I. Bluemke, W. Kiermasz 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 [6] to: kontrakt, luźne powiązanie, abstrakcja, ponowne użycie, bezstanowość, odkrywalność oraz możliwość komponowania usług. 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 Usługi sieciowe Standardem starającym się realizować model SOA są usługi sieciowe WS (Web Service) [2,6,10]. Obecnie dostępnych jest wiele standardów rozszerzających WS jak WS-Transaction, WS-Security, WS-Eventing. W podanej definicji WS określone są jako luźno połączone (loosely coupled). Przez połączenie rozumie się stopień zależności pomiędzy dwoma stronami. Jeśli dwie aplikacje są ściśle połączone (tighly coupled) muszą znać np.: protokół w jakim się komunikują, parametry jakie przyjmuje każda metoda, typ rezultatu. Luźne powiązanie pozwala na swobodniejsze łączenie się i interakcje między aplikacjami. Usługi sieciowe stosują luźne łączenie w zakresie tworzenia powiązania pomiędzy usługami. Oznacza to, że klient usługi nie zna technicznych szczegółów implementacji usługi. Klient wywołuje operacje przy użyciu wiadomości i w takiej formie otrzymuje też odpowiedź. Następnie WS są dostępne z poziomu kodu przez inne aplikacje. Umożliwiają interakcje z innymi aplikacjami. WS jest architekturą czysto abstrakcyjną, a przez to uniwersalną. Uniwersalność wynika z wykorzystania języka extensible Markup Language (XML). Może być on użyty do opisu dowolnej abstrakcji: definicji obiektu, jego atrybutów i współzależności, opisu danych i meta danych. XML jest także obsługiwany przez wszystkie platformy. WS są niezależne od platformy systemowej, języka programowania, formatu danych i metody transportu informacji. WS używają standardowego języka opisu usług Web Services Description Language (WSDL) oraz standardową metodę wyszukiwania i katalogowania usług przy użyciu Universal Description, Discovery and Integration protocol (UDDI) SOAP Usługi sieciowe WS do wymiany komunikatów wykorzystują Simple Object Access Protocol SOAP [4, 9] umożliwiający przesyłanie danych tekstowych i binarnych. W odróżnieniu od protokołu transportowego SOAP definiuje format w jakim dane są przesyłane, a nie metodę ich transportu. SOAP jest protokołem dla dwustronnej wymiany informacji pomiędzy różnymi, rozproszonymi środowiskami przez LAN lub Internet. SOAP wysyła i odbiera pakiety protokołu transportowego (np. HTTP) oraz przetwarza wiadomości w formacie XML. SOAP stosuje luźne powiązanie i jest interoperacyjny. Dokument SOAP jest przesyłany przy pomocy dowolnego protokołu transportowego. Może być wykorzystany w tym celu SMTP, FTP, lub RMI, ale najczęściej jest to HTTP dzięki czemu SOAP jest obecnie najbardziej interoperacyjnym (interoperable) ze wszystkich wire protocols [11]. Poprzez wykorzystanie HTTP SOAP może być wykorzystywane do komunikacji pomiędzy różnymi domenami. Dokument SOAP tworzony jest z wykorzystanie XML i tworzy otoczkę dla przesyłanych danych. SOAP może być także

7 1. Integracja systemów w architekturze zorientowanej na usługi 7 wykorzystany do zdalnego wywoływania metod RPC (Remote Procedure Call) [5]. Elementem SOAP, który przysparza problemy są dwie możliwości definiowania typów danych przesyłanych przy jego pomocy za pomocą modelu bazującego na grafach struktur dynamicznych (graphs of untyped structures) encoding style oraz za pomocą XML Schema -literal REST Inną możliwością komunikacji z usługą jest Representational State Transfer (REST) [4, 9]. REST jest koncepcją tworzenia protokołu i umożliwia transmisje danych przy użyciu cech protokołu HTTP. Nie stosuje on dodatkowej warstwy do przesyłania wiadomości takiej jak na przykład SOAP. Używając REST można wykorzystywać SOAP, co jest powszechne. Interfejsy usług udostępnianych przy pomocy REST są ograniczone do metod udostępnianych przez protokół HTTP (POST, GET, PUT, DELETE). Serwis czy też zasoby do których się odwołujemy są wskazane poprzez adres URI. Usługa powinna być opisana za pomocą WSDL WSDL W celu opisu usług został stworzony WSDL język opisu usług sieciowych [10]. Dokument WSDL opisujący usługę sieciową ma za zadanie umożliwić jej zlokalizowanie, skomunikowanie się z nią i skorzystanie z udostępnianych przez nią operacji. Specyfikacja WSDL składa się z dwóch części: opisu interfejsu usługi, czyli jej abstrakcji (abstract interface), oraz opisu elementów istotnych z punktu widzenia danej implementacji i instancji usługi, czyli specyficznego punktu dostępowego (concrete endpoint) UDDI UDDI (Universal Description, Discovery and Integration) spełnia funkcję rejestru usług (service registry) oraz odkrywania usług (service discovery) niezbędnych w SOA. Pierwsza specyfikacja UDDI została opublikowane we wrześniu 2002, obecna wersja 3.0 została wydana w lutym 2005 [5]. Powstało wiele implementacji tej specyfikacji. UDDI umożliwia katalogowanie usług sieciowych, jak również interfejsów innych komponentów. Informacje przechowywane w UDDI są opisane za pomocą specjalnego rejestru biznesowego (business registry), który składa się z trzech części: białe strony (white pages) zawierają informacje adresowe organizacji dostarczającej usługę, żółte strony (yellow pages) zawierają klasyfikacje danej organizacji opartą na taksonomii odpowiadającej jej branży a zielone strony (green pages) zawierają odnośnik do dokładnej specyfikacji usługi. Model danych rejestru UDDI odpowiada strukturze rejestru biznesowego. Jest on zdefiniowany przy pomocy schematu XML. Katalog UDDI udostępnia APIs (Aplication Programming Interfaces) do przeglądana i modyfikowania. Interfejsy te są usługami sieciowymi. UDDI wspiera dwa modele odkrywania usług [10]. W modelu statycznym katalog jest przeglądany podczas tworzenia rozwiązania w poszukiwaniu odpowiedniej usługi. Następnie pobierane są informacje o wybranej usłudze i w tworzonej aplikacji jest zapisywane odwołanie do niej. W podejściu dynamicznym usługa jest odszukiwana przez działający już program, który na podstawie otrzymanej referencji kontaktuje się z nią. W kontekście odkrywania usług w ostatnich latach są prowadzone prace nad semantycznymi usługami sieciowymi (semantic Web services). Celem jest stworzenie takiego modelu opisu usług sieciowych i algorytmów ich wyszukiwania by było możliwe postawienie dowolnego zadania aplikacji, a ona sama na podstawie analizy zadanych danych odnalazła usługi rozwiązujące dany problem [12]. Jedną z idei przyświecających tworzeniu specyfikacji UDDI było stworzenie globalnego katalogu usług dostępnego w sieci Internet na wzór DNS (Domain Name Service). Firmy IBM, SAP, Microsoft i NTT stworzyły taki rejestr pod nazwą UBR (Universal Business Registry). Jest on darmowy i

8 8 I. Bluemke, W. Kiermasz kataloguje usługi sieciowe dostępne w Internecie. UBR nie stał się jednak popularny, a jednym z powodów jest brak zaufania do umieszczanych tam usług [10]. 4. Podsumowanie Liczne systemy informatyczne w organizacjach zostały stworzone przy użyciu różnych języków programowania, odmiennych platform, działają na innym sprzęcie komputerowym, posiadają różne formaty danych i ich typy. Możliwa jest jednak ich integracja, a odpowiednie technologie pełniące tą rolę były i są rozwijane. Nie powstało jednak pojedyncze rozwiązanie przeprowadzające wszystkie rodzaje integracji i za każdym razem odpowiednia technologia musi być dobierana dla danego zadania integracyjnego. W niniejszym rozdziale opisano w skrócie ewolucję metod integracji systemów informatycznych. Omówiono i porównano stosowane rozwiązania integracyjne, przedstawiono mocne oraz słabe strony tych rozwiązań, a także praktyczne aspekty ich wykorzystania. Technologia integracji systemów informatycznych z użyciem SOA ma wiele zalet. Zaletą jest krótki czas tworzenia i instalacji a także łatwość zarządzania. Technologia ta nie wymaga zaawansowanej wiedzy na temat tworzenia oprogramowania i jest niezbyt kosztowna. Pozwala także na integrację procesów biznesowych i zwiększanie ich wydajności. Można także dopatrzyć się wad. Wymaga dość dużego kosztu początkowego oraz umiejętności. Nie jest to rozwiązanie dojrzałe i zwykle musi być tworzone od podstaw dla każdej firmy. Integracja z użyciem usług sieciowych i innych elementów SOA przynosi wiele korzyści w porównaniu z wcześniejszymi rozwiązaniami. Wymaga jednak powszechności dostarczania przez systemy interfejsów w postaci WS. Późniejsze ich tworzenie na potrzeby pojedynczej organizacji znacznie podnosi koszt stosowania rozwiązań opartych na SOA i może okazać się nieopłacalne. W większości organizacji użytkowane są cały czas systemy informatyczne, które nie są już rozwijane i nie wspierają architektury zorientowanej na usługi. W takim przypadku możliwe jest stworzenie dla nich odpowiednich adapterów, a w dalszej perspektywie wymiana na nowsze. Opis rzeczywistej integracji systemów opartej na SOA można znaleźć w [8]. Bibliografia [1] Adamczewski P.: Słownik informatyczny. HELION, [2] Alonso G., Casatil F., Kuno H., Machiraju V.: Web services: concepts, architectures and applications. Springer, [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 , [4] Erl T.: Service-Oriented Architecture (SOA), Prentice Hall, [5] Gudivada V. N., Nandigam J.: Enterprise Application Integration using Extensible Web Services. Proceedings of the IEEE International Conference on Web Services (ICWS,05), [6] Haas H., Brown A.: Web Services Glossary / [7] Hohpe G., Woolf B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solution. Boston, Addison-Wesley Professional, [8] Kiermasz W.: Integracja systemów informatycznych w architekturze zorientowanej na usług, praca dyplomowa magisterska, Instytut Informatyki PW, [9] Krill P.: InfoWorld. (2007). [10] Papazoglou M. P.: Web services principles and technology. Harlow, [11] Stiver M. C., Scribner K.: Understanding SOAP. SAMS Publishing, [12] Studer R., Grimm S., Abecker A.: Semantic Web Services: Concepts, Technologies, and Applications, Springer, 2007.

9 1. Integracja systemów w architekturze zorientowanej na usługi 9 Integracja systemów w architekturze zorientowanej na usługi I. Bluemke*, W. Kiermasz* *Politechnika Warszawska, Instytut Informatyki, I.Bluemke@ii.pw.edu.pl Rozdział 5. Integracja systemów w architekturze zorientowanej na usługi. Celem niniejszego rozdziału jest analiza użyteczności architektury zorientowanej na usługi dla integracji systemów informatycznych. W pierwszej części rozdziału zaprezentowano technologie integracyjne i stosowane rozwiązania. W szczególności omówiono architekturę zorientowaną na usługi w kontekście integracji systemów. Następnie przedstawiono technologię usług sieciowych, jako implementacja powyższej architektury. Na końcu przeprowadzono analizy i przedstawiono wnioski dotyczące zastosowania architektury zorientowanej na usługi, a w szczególności wykorzystania usług sieciowych dla integracji systemów informatycznych. Integration of information systems in Service Oriented Architecture I. Bluemke*, W. Kiermasz* *Warsaw University of Technology, Institute of Computer Science, I.Bluemke@ii.pw.edu.pl Chapter 5. Information systems integration in Service Oriented Architecture. The aim of this chapter is to investigate the usage of Service Oriented Architecture for integration of information systems. The first part contains presentation of integration technologies and applied solutions. Especially the usage and place of the Service Oriented Architecture in this domain is discussed. Further the technology of Web Services is presented as an implementation of this architecture. Finally the analysis and conclusions of the integration using Service Oriented Architecture, particular Web Services are presented.