Labirynt do przejścia

Integracja usług

Wymienione metody nie wyczerpują wszystkich opcji integracji. Oprócz danych w bazie czy informacji, w portalu można współdzielić usługi. W praktyce jeden system udostępnia innemu systemowi wachlarz metod, za pomocą których można realizować pewne funkcje biznesowe. W takim modelu bardzo ważnym elementem jest dokładne oddzielenie logiki aplikacji od innych warstw. Najlepiej do tego celu nadają się serwery aplikacji, które uruchamianym w ich środowisku systemom automatycznie zapewniają skalowanie wydajności, funkcje związane z bezpieczeństwem, obsługę transakcji, a także udostępnianie usług na zewnątrz.

Na rynku serwerów aplikacji walczą o dominację dwie koncepcje: wspierana m.in. przez Bea Systems, IBM i Sun Microsystems, oparta na języku Java specyfikacja J2EE i konkurencyjna wobec niej platforma .Net firmy Microsoft. O podobieństwie i różnicach między nimi napisano już tomy. Skupmy się na metodach publikacji usług, strategicznych z punktu widzenia integracji.

Rozproszenie logiki biznesowej można wykonać za pomocą wielu technologii, począwszy od konkurujących pionierów, czyli technologii CORBA (Common Object Request Broker Architecture) i COM+ (Component Object Model) Microsoftu. Użyteczność każdej z tych koncepcji w kontekście integracji systemów nie podlega dyskusji. Ich największym mankamentem jest jednak brak pomostu między nimi - Microsoft nie wspiera standardu CORBA, Java zaś, poza małymi wyjątkami, nie obsługuje modelu COM+. Sytuacja zmieniła się diametralnie, gdy na scenie pojawiły się usługi sieciowe - koncepcja po raz pierwszy wspierana przez wszystkich liczących się dostawców technologii.

Gdzie tkwi fenomen usług sieciowych? Przede wszystkim w prostocie koncepcji. Wykorzystywany przez usługi sieciowe protokół SOAP (Simple Object Access Protocol) jest standardem umożliwiającym łatwe wywołanie zdalnej metody (funkcji) i sformułowanie odpowiedzi na takie żądanie przy użyciu komunikatu w formacie XML. Do wysyłania komunikatów usługi sieciowe wykorzystują protokół HTTP, ale można użyć dowolnego protokołu komunikacyjnego, np. SMTP czy FTP.

Wszystkie metody publikowanych usług są dokładnie opisane w pliku WSDL (również XML). Wczytanie takiego pliku do nowoczesnego środowiska programistycznego pozwala traktować usługi sieciowe jak "zwykłe" obiekty. Nie ma przy tym znaczenia, czy usługi sieciowe działają wewnątrz firmy czy na zewnątrz. Co więcej, usługi sieciowe mogą być wywoływane przez komponenty stworzone przy użyciu różnych technologii - komponenty platformy .Net mogą wywoływać komponenty J2EE/EJB i na odwrót.

Możliwość automatycznego - praktycznie bez udziału programisty - korzystania przez systemy firmowe z funkcji udostępnianych "gdzieś w sieci" to prawdziwy przełom w integracji. Nic zatem dziwnego, że usługi sieciowe doczekały się implementacji we wszystkich językach programowania. Sztandarowym przykładem praktycznych zastosowań usług sieciowych są udostępniane w Internecie komponenty do komercyjnego rozsyłania wiadomości SMS, zamawiania biletów lotniczych czy wyszukiwania informacji.

Pomimo oczywistych zalet, usługi sieciowe na razie nie nadają się do budowy dużych środowisk integracyjnych. Technologia ta wciąż szybko się rozwija, powstają nowe specyfikacje szczegółowe, z których część ma status otwartych standardów, część zaś to tylko propozycje. Ponadto usługi sieciowe muszą dojrzeć nawet w warstwie koncepcji, chodzi m.in. o bezpieczeństwo, zarządzanie ruchem komunikatów pomiędzy systemami (XML routing) czy choćby wydajność przetwarzania i przesyłania dużej liczby komunikatów tekstowych. Jest jeszcze wiele do zrobienia.

Specjalne narzędzia

Chcąc stworzyć sieć połączeń między wieloma systemami wykorzystującymi różnorakie technologie, chciałoby się zachować ich niezależność, a jednocześnie uczynić je możliwie jak najbardziej otwartymi. Tam, gdzie jest duża liczba integrowanych systemów, częstotliwość wymiany danych i duża liczba osób potencjalnie korzystających z dobrodziejstw integracji, potrzebne są specjalizowane narzędzia w postaci korporacyjnych systemów integracji aplikacji (EAI - Enterprise Application Integration).

Systemy EAI to zestawy narzędzi do projektowania, wdrażania i zarządzania procesami integracyjnymi. Centralnym elementem takiego środowiska jest mechanizm zarządzający przekazywaniem komunikatów, tzw. broker komunikatów. Jego rolą jest nadzorowanie komunikatów, zarządzanie kolejkami i priorytetami, zapewnianie pewności dostarczenia itd. Oprócz pośrednictwa w wymianie danych między systemami, broker komunikatów może równolegle wykonywać wiele innych pożytecznych czynności, m.in. dostosowywać format napływających komunikatów do formatu systemu docelowego lub sprawdzać ich poprawność, szyfrować itd.

Środowiska tego typu z reguły zawierają gotowe "ogólne" interfejsy do wielu systemów, baz danych i aplikacji, które można stosunkowo łatwo dostosować do konkretnego przypadku. Wraz z nimi są zwykle oferowane także narzędzia do modelowania przepływu danych, a nawet kompletne środowisko programistyczne do tworzenia nowych komponentów integracyjnych i skryptów. Z reguły udostępniają także własne interfejsy API, dzięki którym do środowiska integracyjnego można podłączać systemy monitorujące czy zarządcze. Taka mieszanka nowoczesnych technologii integracyjnych nie jest najtańsza i może być brana pod uwagę przede wszystkim przez firmy duże. Umiejętne wdrożenie systemu EAI może jednak bardzo szybko przynieść znaczne oszczędności zarówno po stronie kosztów operacyjnych, jak i kosztów informatyki.


TOP 200