ODCINEK 1 - SDJ nr 11/2006
Sonic ESB – efektywna i bezpieczna architektura SOA
Korporacyjna magistrala usług – teoria i praktyka SOA
W pierwszym temacie nowego klubu technicznego, prezentującego produkty firmy Sonic Software* pojawiają się dwa akronimami – ESB i SOA. Wprawdzie ilość skrótów w branży IT niejednego przyprawiła już o zawrót głowy, a działy marketingu firm IT o kłopoty ze zmieszczeniem się w skończonej liczbie kombinacji trzech liter, jednak terminy takie jak architektura zorientowana na usługi (ang. service-oriented architecture – SOA) oraz korporacyjna magistrala usług (ang. enterprise service bus – ESB) są już dziś powszechnie rozpoznawalne. W kilku najbliższych odcinkach cyklu przedstawimy jedną z najlepszych implementacji rozwiązania typu ESB na rynku. Nim jednak przejdziemy do szczegółów dotyczących wnętrza produktu Sonic ESB, zaprezentujemy koncepcję korporacyjnej magistrali usług, która stała się już standardowym rozwiązaniem w przedsiębiorstwach borykających się z problemem integracji aplikacji.
Czym zatem jest ESB?
Odpowiadając na to pytanie jednym zdaniem, możemy powiedzieć, iż jest to rozwiązanie zapewniające warstwę pośredniczącą (ang.middleware) umożliwiającą integrację zasobów IT danej korporacji zgodnie z paradygmatami architektury zorientowanej na usługi. Rozszyfrowując tę definicję, należy zwrócić uwagę na termin „architektura zorientowana na usługi”, o którym więcej przeczytać można w ramce, a następnie skoncentrować się na pojęciu „integracja”. Z punktu widzenia architekta, projektanta oprogramowania czy też programisty, podejście prezentowane w koncepcji SOA jest bardzo atrakcyjne. Rozwiązanie SOA pociąga za sobą obietnicę idealnie współpracującego zbioru baz danych, serwerów aplikacji i innych rozwiązań stanowiących składniki infrastruktury IT korporacji. Także z punktu widzenia klienta korporacyjnego mającego do czynienia z wieloma systemami informatycznymi (często posiadającymi oprócz wartości biznesowej także wartość historyczną) tego typu podejście, które obiecuje obniżenie kosztów integracji, jest bardzo kuszące.
Jednak SOA, nawet po przełożeniu na zbiór technologii takich jak XML, HTTP, SOAP, WSDL itd., to nic więcej jak tylko koncepcja. To idea, która wymaga implementacji. ESB jest właśnie tego typu rozwiązaniem – silnikiem zapewniającym wykorzystanie potencjału architektury zorientowanej na usługi.
Różnice pomiędzy implementacjami tradycyjnych systemów ESB są dość znaczne, jednak dość łatwo ustalić listę cech, które posiada każda z nich. Implementacje ESB zawierają zbiór kontenerów usług, które stanowią swego rodzaju adaptery pomiędzy różnymi rozwiązaniami IT a samym środowiskiem ESB. Wewnątrz każdego z kontenerów usług zamknięta jest implementacja danego zasobu IT (np. API starego systemu kadrowego) jako klienta i/lub dostawcy konkretnej usługi. Standard WSDL jest zazwyczaj wykorzystywany w celu opisania interfejsu, który stanowi fasadę danego kontenera. Rozwiązania ESB muszą więc zapewnić niezawodną wymianę komunikatów, dlatego korzystają najczęściej z doświadczeń systemów typu Messaging Oriented Middleware, w których to przesłane wiadomości stanowiły podstawę komunikacji pomiędzy integrowanymi rozwiązaniami. Kluczowe jest także dostarczenie funkcjonalności umożliwiającej odpowiednie transformowanie i przekierowywanie komunikatów. Nie wspominając już o tak podstawowych wymogach jak bezpieczeństwo, możliwość administracji systemem ESB oraz zmiany jego konfiguracji w czasie rzeczywistym - bez konieczności przerywania pracy.
Te podstawowe zadania, są w różnym zakresie realizowane przez niemal każdy produkt na rynku. W niniejszym cyklu przedstawiona zostanie jedna z ciekawszych implementacji – Sonic ESB.
Sonic ESB
Nie jest trudno znaleźć argumenty świadczące o tym, że rozwiązanie firmy Sonic Software ustanawia standardy w branży ESB. Raport Gartner Dataquest potwierdza, że rozwiązanie to jest pierwszym wśród systemów służących do integracji aplikacji. Przychód ze sprzedaży rozwiązania Sonic ESB wzrósł z 8,7mln USD w 2004 roku do 18,4mln USD w roku 2005. Sonic Software wyprzedziła w rankingu firmę BEA i jej udział w rynku jest niemal czterokrotnie wyższy niż firmy IBM. Gdy pod koniec 2002 roku analityk tej samej firmy Roy Schulte opublikował raport z prognozami na 2003 rok (po raz pierwszy używając w nim terminu ESB) szacował, że do 2005 roku tego typu systemy zagoszczą w niemal wszystkich korporacjach. Mimo iż swój szacunek zmienił już w następnym roku (aktualna prognoza to 2007 rok) i obecnie coraz częściej mówimy o wirtualizacji usług, nie można podważyć faktu, iż od 2002 roku Sonic ESB został wdrożony w ponad 1000 korporacji i organizacji rządowych na całym świecie. Przykładem nich będzie chociażby wdrożenie na lotnisku w Heathrow, gdzie komunikację pomiędzy około 600 aplikacjami zapewni właśnie Sonic ESB. Rozwiązanie to wygrało bardzo restrykcyjny przetarg - głównie dlatego, że jako jeden z dwóch wybranych do ostatecznych testów systemów potrafiło odzyskać funkcjonalność po błędzie (spowodowanym m.in. problemami sprzętowymi, awarią sieci lub uszkodzeniem danych) w czasie kilku sekund - a nie minut, jak ma to miejsce w przypadku rozwiązań konkurencyjnych.
Jeśli mowa o wartości dodanej rozwiązań ESB, jednym tchem można wymienić: szybszą i tańszą integrację istniejących systemów, większą elastyczność przy dokonywaniu zmian w konfiguracji systemu, bazowanie na sprawdzonych standardach. Korporacyjna magistrala usług pozwala uciec od zmian w kodzie łączącym aplikacje w modelu one-to-one lub w modelu huba integracyjnego pełniącego rolę centralnego brokera i silnika zasad, którymi kieruje się system. Ich miejsce zajmuje w pełni rozproszony i skalowalny system, którego działanie zmieniane jest za pomocą konfiguracji.
Takie bogactwo usług musi się jednak wiązać z dość dużą złożonością systemu. Rzeczywiście, Sonic ESB nie jest rozwiązaniem prostym. Składa się z wielu logicznych modułów, które realizują konkretne funkcje korporacyjnej magistrali usług.
Architektura Sonic ESB
Rysunek 1. Elementy systemu Sonic ESB
Mówiąc o architekturze ESB, będziemy się najczęściej posługiwali zestawem standardowych pojęć i symboli. Zaprezentowana na Rysunku 1. korporacyjna magistrala usług zawiera takie elementy jak:
- Usługi ESB (ESB Services), czyli usługi udostępnione przez aplikacje - czy to bezpośrednio zintegrowane z magistralą, współpracujące z nią za pomocą komponentów proxy, czy wręcz usługi mediacyjne takie jak transformacje lub inteligentne przekierowywanie (routing) danych.
- Kontener ESB (ESB Container), który jest zarządzalnym środowiskiem, zapewniającym kontrolę nad usługami i odpowiednie ich powiązanie z zewnętrznymi usługami. Kontener ESB jest odpowiedzialny między innymi za wspieranie zarządzania czasem życia danej usługi oraz jej dynamiczne umieszczenie w ramach dużego systemu rozproszonego (jakim niewątpliwie jest korporacyjna magistrala usług).
- Broker zapewniający komunikację pomiędzy wieloma protokołami (Multiprotocol Communication Broker) – to element magistrali, który zapewnia bezpieczną i niezawodną warstwę przesyłu danych o wysokiej przepustowości i małych opóźnieniach. Broker ten wykorzystuje usługi webowe lub protokół Java Messaging Service (JMS). Oferuje on także możliwość pracy w klastrach oraz dynamicznego rozmieszczenia. Zapewnia przez to skalowalność i przepustowość niezależną od konkretnych kontenerów korzystających z tego medium transmisji danych. Dodatkowo w systemie Sonic ESB wykorzystano autorską technologię Continuous Availability Architecture (CAA) zapewniającą stałą dostępność oraz transakcje odporne na wystąpienie błędów - bez potrzeby stosowania specjalistycznego oprogramowania lub sprzętu. Kolejnym z zastosowanych w Sonic ESB rozwiązań jest opatentowane rozwiązanie Dynamic Routing Architecture (DRA) oferujące automatyczne przekazywanie informacji pomiędzy segmentami tworzącymi jedną magistralę.
Dzięki tego typu architekturze opartej o doskonałą warstwę transportową, z którą w ustandaryzowany sposób można połączyć aplikacje J2EE, usługi sieciowe i poprzednio stworzone rozwiązania integrujące systemy (EAI), otrzymuje się w pełni funkcjonalny, dowolnie skalowalny system. System, w którym usługi mogą być uaktualniane, dołączane i przenoszone -bez zakłócania pracy innych usług. Dodatkowo konfiguracja usług oraz zależności pomiędzy nimi są przechowywane w centralnym repozytorium oferującym rozproszone buforowanie informacji.
Magistralę Sonic ESB wspiera funkcjonalnie przedstawiona na Rysunku 2 rodzina produktów, którą omówimy dokładniej w kolejnych odcinkach klubu technicznego. Kolejno będziemy przyglądać się jej konkretnym elementom zapewniającym konfigurację i zarządzanie usługami, wspierającym integrację Sonic ESB z istniejącymi systemami oraz pełniącym wiele innych zadań - tak istotnych dla każdego inżyniera, którego zadaniem jest integracja systemów IT korporacji.
Rysunek 2. Sonic ESB oraz rodzina aplikacji powiązanych z systemem
Podsumowanie
Mamy nadzieję, iż w powyższym, pierwszym odcinku klubu technicznego udało się nam zaprezentować niewątpliwie ciekawe rozwiązanie architektoniczne, jakim jest ESB.
Jednocześnie zachęcamy do śledzenia kolejnych odcinków, w których krok po kroku odkrywać będziemy tajniki rozwiązania Sonic ESB. A zaczniemy od zaprezentowania sposobu jak z wykorzystaniem środowiska deweloperskiego Sonic Workbench stworzyć projekt ESB.
Architektura zorientowana na usługi
Wraz z rozwojem sieci Internet oraz krystalizowaniem się standardów m.in. HTTP czy XML pojawiła się kolejna (po technologiach takich jak RPC, COM, czy CORBA) koncepcja integracji systemów informatycznych. Podstawową ideą SOA jest ukrycie skomplikowanych procesów zachodzących wewnątrz danej aplikacji za ogólnie zrozumiałym interfejsem, który w miejsce API oferuje usługi. Zamiast więc w konkretnej kolejności wywoływać metody, ustawiać parametry czy też parsować odpowiedzi zdalnego systemu, w architekturze zorientowanej na usługi komunikaty przesyłane pomiędzy systemami są prośbami o wykonanie konkretnej usługi, odpowiednio zakodowane (np. w postaci wiadomości SOAP). Wspólny interfejs to usługi webowe (ang. Web Services), które są obecnie nie mniej popularne niż sama architektura. Aby ułatwić opracowanie specjalnej warstwy integracji powstały dodatkowe standardy, takie jak: Web Services Description Language (WSDL) stanowiący wizytówkę danego interfejsu w sieci, Universal Description Discovery and Integration (UDDI) pozwalający na odpowiednie zarejestrowanie i odnalezienie danego serwisu w sieci czy też seria specyfikacji WS-*.
Termin SOA pochodzi z artykułu analityków firmy Gartner Roya Schulze i Yefina Natis opublikowanego w 1996 roku. Dekada, która upłynęła od ukonstytuowania koncepcji SOA, to okres, w którym swoje rozwiązania w tym zakresie opracowały niemal wszystkie liczące się firmy z branży IT.
W Sieci
Kontakt z autorem:
Parys Waicis
pwaicis@progress.com
Konkurs dotyczący odcinka 1 Klubu technicznego Progress Software – ogłoszony 22.01.2007, zakończony 13.02.2007
1. Do jakiej kwoty wzrósł przychód ze sprzedaży Progress SonicESB w roku 2005?
- a) 8.7 mln $
- b) 10 mln $
- c) 12 mln $
- d) 18,4 mln $
2. Co w Progress SonicESB zapewnia kontrolę nad usługami?
- a) Dynamic Routing Architecture
- b) Kontener ESB
- c) Broker
3. Który element jest częścią Sonic Orchestration Server?
- a) Process Modeling
- b) Database Query Editor
- c) Worklet Management
Książkę Davida Chappella – Enterprise Service Bus otrzymują:
- Krzysztof Kierys
- Karol Mrozik
- Wojciech Starzec
ODCINEK 2 - SDJ nr 12/2006
Progress Sonic ESB – efektywna i bezpieczna architektura SOA
Korporacyjna magistrala usług –tworzenie projektu w środowisku Progress Sonic Workbench
W poprzednim odcinku klubu technicznego, którego celem jest zaprezentowanie możliwości produktu firmy Progress Software – Progress Sonic ESB, omówiliśmy koncepcję korporacyjnej magistrali usług (ang. enterprise service bus (ESB)). Uważny czytelnik wie już zatem, z jakich elementów składa się rozwiązanie Sonic ESB. W niniejszym odcinku zaprezentujemy podstawowe możliwości zintegrowanego środowiska programistycznego Sonic Workbench, dzięki któremu architekci i programiści mogą tworzyć serwisy, integrować istniejące aplikacje oraz zarządzać i testować procesy biznesowe definiowane przy pomocy tego narzędzia. Wiedza zdobyta w niniejszym odcinku pozwoli czytelnikowi na zapoznanie się ze środowiskiem, opanowanie podstawowych koncepcji oraz przygotowanie do kolejnych odcinków naszego klubu, w których coraz bardziej zagłębiać się będziemy w tajniki środowiska Progress Sonic Workbench i platformy Progress Sonic ESB.
Składniki Progress Sonic Workbench
Podczas pracy z Sonic Workbench najczęściej wykorzystywać będziemy graficzny interfejs, który w wersji Sonic ESB 7.01 bazuje na silniku Eclipse 3.1.1. Narzędzie to oferuje funkcjonalność niezbędną w pracy z różnymi typami plików, jakie możemy spotykać w e-biznesie oraz podczas zadań związanych z integracją aplikacji i pracy z samym środowiskiem Sonic ESB. Znajdziemy w nim edytory XML, XSD (XML Schema), WSDL (Web Services Description Language), XQuery oraz XSLT (Extensible Stylesheet Language Transformations). Przy czym zarówno edytor XQuery, jak i edytor XSLT rozszerzony jest o możliwość definiowania prostych mapowań pomiędzy dokumentami i tworzenia przy ich pomocy interfejsów dla usług pracujących w ramach ESB. Tworzenie samych aplikacji środowiska Sonic, czyli usług, aranżacji i procesów ESB, wspiera zestaw edytorów. Należą do nich:
- edytor procesów ESB,
- edytor umożliwiający tworzenie reguł routingu,
- edytor operacji wykonywanych na bazie danych,
- edytor aranżacji, który pozwala zamodelować wywoływanie operacji z różnych źródeł w postaci UML-owego diagramu aktywności,
- edytor umożliwiający wywoływanie usług sieciowych,
- edytor rozszerzonych typów danych (Java Service Type).
Z myślą o uruchamianiu, testowaniu i debugowaniu elementów platformy, środowisko Sonic Workbench wyposażono w wiele widoków umożliwiających edytowanie wiadomości, dostęp do komponentów takich jak Message Sender i Listener, wartości zmiennych ESB itp. Zatem bez trudu będziemy mogli sprawdzić jak działa nasza platforma, używając np. widoku Debug zamiennie ze specjalnym widokiem ESB Process Tracking.
Same narzędzia programistyczne to jednak nie wszystko. Wraz z Sonic Workbench zainstalowane zostaną: magistrala usług Sonic ESB; usługa Sonic Database, która pozwala na uzyskanie dostępu do baz danych z poziomu ESB; Sonic Orchestration Server, dzięki któremu możemy zarządzać przepływem wiadomości poprzez modelowanie, wykonywanie i zarządzanie skomplikowanymi procesami biznesowymi oraz Sonic XML Server - natywna baza XML wspierającą zadania związane z przetwarzaniem wiadomości i integracją aplikacji podłączonych do magistrali.
Jak stworzyć projekt ESB
Wiedza, która niewątpliwie będzie nam potrzebna podczas kolejnych odcinków klubu technicznego, to umiejętność tworzenia własnego projektu w środowisku Sonic ESB. Zanim uruchomimy aplikację Sonic Workbench, musimy uruchomić proces zarządzający daną domeną (szczegółowe informacje dotyczącego tego ściśle związanego z administracją Sonic ESB zagadnienia zostaną umieszczone w jednym z kolejnych odcinków). W tym celu wybieramy Start > All Programs > Sonic Software > Sonic Workbench 7.0 > Start Domain Manager i dopiero po prawidłowej inicjalizacji procesu Domain Manager uruchamiamy Sonic Workbench, klikając Start > All Programs > Sonic Software > Sonic Workbench 7.0 > Sonic Workbench. Nawet jeśli zapomnieliśmy o wystartowaniu Domain Managera, podczas startu środowiska będziemy mieli jeszcze jedną szansę na uruchomienie tego procesu (bez niego nie będziemy w stanie sprawdzić działania żadnego z elementów ESB).
Domyślnie Sonic Workbench uruchomi perspektywę Sonic Design środowiska Eclipse. To właśnie w tej perspektywie będziemy tworzyć i zarządzać naszymi projektami. Warto zwrócić uwagę na rozszerzoną stronę powitalną (wybierając Sonic Workbench z menu Help>Welcome). Zamieszczone na niej informacje pozwalają lepiej zorientować się w środowisku.
Na Rysunku 1 przedstawiono te aspekty środowiska, które nawet w przypadku braku projektu pozwalają zorientować się osobie niezaznajomionej z Eclipse, iż znajduje się we właściwej perspektywie.
Rysunek 1. Elementy charakterystyczne perspektywy Sonic Workbench
W celu stworzenia nowego projektu ESB należy wybrać File > New > Sonic Development Project (co zaprezentowano na Rysunku 2). Warto zwrócić uwagę na mnogość innych typów obiektów, które będziemy tworzyć w przyszłości. Następnym krokiem będzie wybranie nazwy naszego projektu i kliknięcie przycisku [Finish] Rysunek 3). Gdyby nasz projekt miał wykorzystywać możliwości Orchestration Server, musielibyśmy wybrać [Next] i stworzyć nowy zbiór zasad (Orchestration Process Set), w naszym przypadku nie ma jednak takiej konieczności.
Rysunek 2. Menu podczas tworzenia nowego projektu
Rysunek 3. Okno właściwości nowego projektu
Projekt zostanie stworzony i poprzez dodawanie do niego kolejnych elementów platformy ESB będziemy mogli rozpocząć budowę naszej własnej magistrali zapewniającej sprawną integrację aplikacji. Na opis tych elementów ich zasad działania zapraszamy jednak już do kolejnego odcinka klubu technicznego. Natomiast dla niecierpliwych.
Przykładowe projekty ESB
W przypadku standardowej instalacji można zainstalować także przykładowe aplikacje ESB. W celu zapoznania się z przykładami w środowisku Sonic Workbench, należy wybrać kolejno File > Import > Existing Project into Workspace, następnie w oknie Import należy wskazać ścieżkę do plików z przykładami. Jeśli środowisko Sonic Workbench zostało zainstalowane w domyślnej lokalizacji, przykłady znajdziemy w folderze C:SonicESB7.0samples. Na początek polecamy przykład znajdujący się w podfolderze Sample.SupplyChain7.0. Projekt zostanie załadowany do domyślnej przestrzeni roboczej, a po wybraniu opcji menu Project > Upload all elementy ESB zdefiniowane w tym przykładnie zostaną dodane do domeny opisującej naszą platformę integracyjną.
Podsumowanie
W niniejszym odcinku przedstawiliśmy podstawowe i zarazem kluczowe informacje, które będą wykorzystywane podczas dalszego omawiania aplikacji Sonic Workbench i systemu Progress Sonic ESB. W kolejnym odcinku zaprezentujemy, jak stworzyć własną usługę ESB. Stworzymy tym samym pierwszą aplikację ESB, odpowiednio ją zaprojektujemy, zbudujemy, przetestujemy przy wykorzystaniu Sonic Workbench, następnie zainstalujemy w domenie, aby po rozszerzeniu jej o kilka procesów (np. pobranie danych z bazy i transformację) przejść do omówienia elementów konfiguracji Sonic ESB.
Mamy nadzieję, za zarówno ten jak i kolejne odcinki cyklu prezentowanego w ramach klubu technicznego Progress Software zwiększą zainteresowanie systemami klasy korporacyjnej oraz nowatorskim, zapewniającym sprawną integrację aplikacji rozwiązaniem architektonicznym, jakim jest korporacyjna magistrala usług – ESB.
W Sieci
30-dniową wersję testową Sonic Workbench można pobrać ze strony Progress Software http://www.sonicsoftware.com/products/sonic_esb_family/index.ssp
Kontakt z autorem:
Parys Waicis
pwaicis@progress.com
Konkurs dotyczący odcinka 2 Klubu technicznego Progress Software – ogłoszony 13.02.2007
1. Gdy tworzymy nowy projekt w Progress Sonic Workbench w celu stworzenia nowych usług, to niezbędne jest stworzenie w nim następującego artefaktu:
- a) Source folder dla kodu usług
- b) EJB
- c) Java Service Content
2. Wszystkie usług ESB muszą implementować następujące metody:
- a) contructor(), destruktor()
- b) start(), end()
- c) init(), destroy()
3. Gdy implementujemy własną usługę ESB, to jaki interfejs jest implementowany przez klasę usługi ?
- A) IESBService
- B) XQService
- C) ESBServiceInterface
Odpowiedzi wraz z adresem pocztowym prosimy nadsyłać na adres email: sdj@software.com.pl
do 20.02.07 jako temat prosimy wpisywać “konkurs Progress 2”
3 osoby, które jako pierwsze nadeślą prawidłowe odpowiedzi otrzymają książkę Davida Chappella – Enterprise Service Bus.
ODCINEK 3 - SDJ nr 1/2007
Progress Sonic ESB
Tworzenie usługi w środowisku Progress Sonic Workbench
W poprzednim klubie technicznym, przedstawiliśmy przegląd narzędzi, z których składa się środowisko Sonic Workbench, składnik systemu firmy Progress Software – Sonic ESB. Zaprezentowaliśmy, jak stworzyć swój własny projekt ESB oraz w jaki sposób skorzystać z dostarczanych przez producenta przykładów. Posiadajmy więc wiedzę potrzebną, aby przejść do kolejnego bardzo ważnego zadania związanego z budowaniem infrastruktury ESB. W niniejszym numerze skoncentrujemy się na tworzeniu usług ESB.
Usługi ESB
Usługa w ESB to modularny, wielokrotnie wykorzystywany element funkcjonalności. Realizowane przez usługę zadania, takie jak np. wbudowane operacje transformacji, mogą być związane z zapewnianiem pracy infrastruktury ESB lub bezpośrednio z wykonaniem logiki aplikacji np. obliczeniem wartości podatku. Usługi ESB są uruchamiane w kontenerach, które zapewniają zarządzenie cyklem życia danej funkcjonalności (np. uruchamianiem i wyłączaniem usługi) oraz odpowiadają za połączenie usługi z magistralą komunikatów, co zaprezentowano na Rysunku 1.
Rysunek 1. Schemat relacji pomiędzy usługą ESB, kontenerem i magistralą komunikatów
Aby lepiej zrozumieć, w jaki sposób zachodzi interakcja z wykorzystaniem usługi, prześledźmy poniższy scenariusz. Dane wejściowe danej usługi zostają do niej dostarczone w postaci wiadomości, tzw. XQMessage i w takiej też formie prezentowane są wyniki działania usługi. Każda z wiadomości jest przetwarzana sekwencyjnie wewnątrz logiki usługi realizowanej wewnątrz metody service(). Rysunek 2 jest ilustracją procesu przetwarzania wiadomości wewnątrz każdej z usług (i odpowiadających im kontenerów).
Rysunek 2. Diagram przetwarzania wiadomości przez usługę wewnątrz kontenera
Zgodnie z przedstawionym rysunkiem kolejne etapy procesu przetwarzania wiadomości są następujące:
- Wiadomość w normatywnym formacie dociera do kontenera ESB;
- Nasłuchujący punkt końcowy konwertuje ją do formatu wewnętrznego Sonic ESB XQMessage;
- Wiadomość jest dostarczana do dispatchera;
- Wiadomość zostaje umieszczona na wejściu odpowiedniej usługi, a do jej treści dodawany jest nowy domyślny adresat – wyjście z usługi;
- Usługa otrzymuje wiadomość, wykonuje operacje na wiadomości (np. przekształca jej zawartość, dodając nowe informacje). Może także zmienić kontekst wiadomości;
- Usługa umieszcza wiadomość na wyjściu, ewentualnie przesyła ją do specjalnego wyjścia sygnalizującego błąd w przetwarzaniu;
- Dispatcher sprawdza zawartość wiadomości na wyjściu i przesyła ją do następnego punktu;
- Punkt końcowy konwertuje wiadomość XQMessage do odpowiedniego formatu natywnego;
- I przesyła wiadomość do kolejnego punktu podłączonego do korporacyjnej magistrali usług.
A zatem w kontekście Sonic ESB usługi są zarządzanymi elementami – klientami magistrali komunikatów, które mogą być wykorzystywane pojedynczo lub łączone w procesy ESB (o których więcej w kolejnym odcinku). Właściwie cała logika aplikacji mieści się wewnątrz usług, a wiadomości i kontekst ich przetwarzania jest przekazywany do usługi. Na poziomie usługi można zrealizować obsługę błędów, a samymi usługami można zarządzać (konfigurować je i monitorować) z poziomu menadżera domeny. Ich interfejsy są zdefiniowane przy pomocy technologii XML i WSDL.
W Sonic ESB każda działająca usługa jest instancją pewnego typu usługi. W celu stworzenia usługi należały zaimplementować interfejs XQService, używając prostego API, a następnie dodając odpowiednie klasy i parametry konfiguracyjne stworzyć klasy oczekujące na poszczególnych punktach końcowych.
Gdy tak stworzony fragment kodu otrzyma wiadomość, zostanie ona odpowiednio zwalidowana, a później przesłana do wspomnianej metody service(). Po wykonaniu operacji wiadomość jest wysyłana za pomocą JMS. Wiadomości JMS dostarczane z kolejki komunikatów (SonicMQ) są odpowiednio przetwarzane przez instancję MessageListener, która zapewnia wewnętrzne przetwarzanie wymagane przez platformę i specyficzne operacje realizowane przez daną usługę. Po przetworzeniu nowa lub tylko zmodyfikowana wiadomość jest wysyłana do kolejnego punktu w magistrali. Jednakże usługi ESB nie są klientami JMS w pełnym tego słowa znaczeniu. Ich cykl życia jest sterowany zewnętrznie przy pomocy kontenerów, bezpośrednio nie biorą one udziału w tworzeniu połączeń JMS, sesji, ani instancji MessageListener. Konfigurację oraz tego typu operacje zapewnia kontener. Wiadomości w korporacyjnej magistrali usług posiadają identyfikator i kontekst, który jest przesyłany wraz z wiadomością. W JMS nie ma takich atrybutów jak nagłówek, QoS czy kontekst zawartości, który jest automatycznie przekazywany. Implementacja obsługi przychodzącej wiadomości (za pomocą MessageListener) jest dużo bogatsza niż w przypadku JMS.
Przykładowy kod prostej metody service() zaprezentowano na Listingu 1.
Listing 1. Kod prostej metody service()
Wszystkie usługi ESB muszą implementować także metody init() i destroy() interfejsu XQService. Jak już wspomniano, każda usługa działająca w ESB to instancja pewnego typu, a jej konfiguracja jest przechowywana w postaci pliku XML w Directory Service.
Tworzenie własnego typu usług
W celu stworzenia nowego typu usługi i powiązanego z nią szablonu konfiguracji należy wykonać kilka kroków. W środowisku Sonic Workbench należy stworzyć nowy projekt (co opisano w poprzednim odcinku klubu technicznego), a następnie stworzyć w projekcie nowy folder (np. src), co można wykonać, wybierając opcję File->New->Other, opcję Source Folder w węźle Java i podając nazwę nowego folderu. Następnie wybieramy File->New->Java Service Type, a w oknie dialogowym należy wskazać właśnie stworzony folder i podać unikalną nazwę usługi. Na kolejnym ekranie można zdefiniować parametry pracy usługi, na razie pozostawiamy je bez zmian, przechodząc do kolejnego ekranu pozwalającego określić nazwę klasy, która będzie zawierała implementację usługi. Klikając Finish, spowodujemy utworzenie szkieletu usługi. Efekt powinien przypominać zrzut ekranu z Rysunku 3.
Rysunek 3. Sonic Workbench po stworzeniu usługi
Teraz możemy przystąpić do modyfikacji działania usługi. W tym celu zrealizujemy operację wypisania komunikatu „Hello world” wewnątrz usługi. W metodzie service() dodajmy linię kodu:
msg.SetStringHeader
("MyService","Hello world")
zaraz po pobraniu treści wiadomości i wejściu w sekcję try. Usługę możemy już dowolnie rozszerzać. Niestety scenariusze, takie jak opakowanie istniejącej klasy w celu wykorzystania jej logiki w usłudze, bezpośrednie komunikowanie się pomiędzy usługą a JMS, odczytywanie parametrów konfiguracyjnych i inne, wykraczają poza zakres tego krótkiego przeglądu.
Instalowanie usługi w repozytorium
Po modyfikacji kodu, usługę instalujemy w kontekście Sonic Domain. W tym celu można wykorzystać testowy kontener dev.ESBTest i sprawdzić, jak działa nasza usługa. Instalacja jest bardzo prosta, wystarczy z menu kontekstowego pliku .esbstyp wybrać opcję Upload Service Type. W oknie należy zwrócić uwagę na nazwę usługi, wartości wszystkich parametrów inicjalizacyjnych dla instancji usługi oraz w szczególności na punkty końcowe usługi zaprezentowane w polu Advanced. Można samodzielnie modyfikować wspomniane wartości w celu dostosowania usługi do własnych potrzeb, a następnie, wybierając przycisk OK, zatwierdzić operację. W wyniku uruchomienia usługi środowisko poinformuje nas, że trzeba zrestartować kontener - co też należy uczynić. Po instalacji możemy modyfikować podane wcześniej wartości za pomocą menu kontekstowego pliku .esbstyp definiującego usługę i opcji Configure Service Instance.
Dalsze kroki
Aby wykorzystać wynik przeprowadzenia powyższych operacji, można stworzyć instancje odpowiadające właśnie zainstalowanemu typowi usługi. Do tego celu służy narzędzie Sonic Management Console, które opiszemy w jednym z kolejnych odcinków. Można także zastosować tzw. scenariusze, które służą do testowania konfiguracji magistrali przy pomocy zestawu wiadomości. Wreszcie można rozpocząć pracę z narzędziami, takimi jak debuger i okno śledzenia, które omówimy dokładniej już w następnym klubie technicznym.
Podsumowanie
W tym odcinku przybliżyliśmy pojęcia związane z usługami ESB oraz zaprezentowaliśmy, jak stworzyć nową klasę usług przy użyciu Sonic Workbench. W kolejnym odcinku zaprezentujemy, jak stworzyć własny proces ESB, który będzie składał się operacji wykonywanych przez instancje przedstawionych w niniejszym klubie usług ESB. Przyjrzymy się bliżej definiowaniu i śledzeniu wykonania takiego procesu oraz możliwościom, jakie oferuje w tym zakresie produkt Progress Sonic ESB.
W Sieci
30-dniową wersję testową Sonic Workbench można pobrać ze strony Progress Software http://www.sonicsoftware.com/products/sonic_esb_family/index.ssp
Kontakt z autorem:
Parys Waicis
pwaicis@progress.com
ODCINEK 4 - SDJ nr 2/2007
Progress Sonic ESB – efektywna i bezpieczna architektura SOA
Korporacyjna magistrala usług – tworzenie procesów w środowisku Sonic Workbench
W niniejszym odcinku klubu technicznego przedstawiającego produkt firmy Progress Software – Progress Sonic ESB opiszemy jak za pomocą środowiska Progress Sonic Workbench stworzyć proces ESB. Dowiemy się jaką rolę odgrywa proces w korporacyjnej magistrali usług. Następnie wykorzystując Sonic Workbench spróbujemy stworzyć, sparametryzować i przetestować nowy proces ESB.
Proces ESB
O procesach ESB wspomnieliśmy już poprzednio, opisując funkcjonalność usług ESB. Trudno bowiem przedstawić oba elementy systemu odrębnie, gdyż procesy służą do definiowania sekwencji usług, zagnieżdżonych procesów ESB i punktów końcowych czyli składników systemu ESB, przez które wędrują wiadomości. Definiując nowy proces, każdy z jego kroków definiować będziemy zazwyczaj właśnie jako usługę lub grupę procesów.
Proces ESB jest zorientowany na przetwarzanie wiadomości i może być rozpięty nad grupą wielu kontenerów ESB (a nawet serwerów). Zapewnia on QoS (Qality of Service), obsługę błędów i śledzenie wiadomości we wszystkich usługach, które zawiera. Odwołać się do niego można za pomocą adresu przydzielonego mu w korporacyjnej magistrali usług, wywołania JMS, HTTP lub poprzez interfejs usługi sieciowej.
Chociaż proces może obejmować elementy rozmieszczone w całej strukturze ESB, to jego definicja znajduje się w centralnym rejestrze, dlatego każda usługa lub punkt końcowy może przekierować wiadomość do dowolnego procesu. Co więcej, wiele procesów może wykorzystywać tę samą usługę, przy zapewnieniu unikalnego kontekstu wywołania, parametrów i informacji służących do sterowania ruchem wiadomości.
W ramach systemu Sonic ESB mamy dostęp do narzędzi służących do administrowania i monitorowania procesów ESB. Możemy między innymi śledzić przepływ wiadomości oraz inicjowanie podprocesów i usług w ramach procesu nadrzędnego, a także analizować sytuacje, w których pojawiają się błędy.
Wiedząc już czym teoretycznie jest proces ESB, przejdźmy do omówienia aspektów praktycznych. Pracując z procesami ESB musimy wiedzieć jak odwołać się do kontekstu procesu, do czego służą parametry procesu wędrujące z każdą wiadomością oraz jak zdefiniować kolejne kroki przetwarzania wiadomości w danym „planie podróży” zdefiniowanym dla wiadomości poprzez proces.
Edytor procesów ESB
Aby stworzyć proces ESB w ramach uprzednio stworzonego projektu, wybieramy opcję File > New > ESB Process w Sonic Workbench. Po podaniu nazwy nowego procesu zostanie automatycznie otwarte okno edytora, a proces zostanie zapisany w pliku z rozszerzeniem *esbp. Przy pomocy graficznego interfejsu możemy zdefiniować kolejne kroki przetwarzania wiadomości wykorzystując paletę komponentów reprezentujących usługi, podprocesy, punkty końcowe czy też wywołania usług webowych. Nim jednak przejdziemy do definiowania tych elementów musimy sparametryzować sam proces.
Na zakładce Overview możemy podać nazwę i opis procesu, na następnie określić poziom QoS, czas życia każdej z wiadomości przetwarzanej w ramach procesu bądź adres URL, pod którym znajduje się definicja WSDL opisująca proces jako usługę webową (plik WSDL możemy wygenerować automatycznie). Tutaj też zdefiniujemy punkt wejścia do systemu (jeżeli do systemu odwołujemy się z poziomu klienta JMS albo poprzez wywołanie HTTP), punkt wyjścia, oraz adresy, pod które odeślemy uszkodzone lub odrzucone wiadomości – każdy taki punkt może być innym procesem. Tu także możemy określić poziom śledzenia wiadomości, co jest istotne podczas śledzenia procesu.
Po określeniu parametrów procesu (lub pozostawieniu wartości domyślnych) możemy przystąpić do definiowania kroków przetwarzania. Na okno edytora możemy przeciągnąć już istniejące definicje usług lub posłużyć się paskiem narzędzi w celu określenia nowych elementów.
Jak stworzyć proces i jego elementy zaprezentujemy, posługując się przykładem realizacji procesu łańcucha zamówień (patrz Rysunek 1).
Rysunek 1. Przykładowy proces ESB
Budowanie procesu ESB
Pierwszym krokiem przetwarzania w procesie jest walidacja poprawności wiadomości, która ma zostać przetworzona przez proces. W tym celu wykorzystano usługę typu ValidationServiceType, której kod możemy znaleźć w pliku srccomsonicswesbscserviceValidationService.java po zaimportowaniu przykładu (o tym jak tworzyć usługi była mowa w poprzednim odcinku). W naszym przypadku do usługi nie są przesyłane żadne dodatkowe parametry, ale gdyby usługa ich wymagała, wówczas w oknie specyfikowania szczegółów wywołania usługi moglibyśmy je dodać (w celu przejścia do okna właściwości usługi należy wskazać dany element, kliknąć prawy klawisz myszy i wybrać opcję Open – Rysunek 2).
Rysunek 2. Menu pozwalające na dostęp do właściwości elementu procesu
Kolejnym krokiem jest przetworzenie wiadomości zgodnie z wcześniej zdefiniowaną regułą, co służy przetransformowaniu zewnętrznego formatu danych na postać wewnętrzną wykorzystywaną w ramach procesu. Do tego celu wykorzystana została transformata XSL uruchomiona jako parametr usługi typu XML Transform (jest to typ dostarczany przez środowisko Sonic ESB). Z poziomu okna szczegółów tego elementu procesu (przedstawionego na Rysunku 3) możemy prześledzić dodawanie tego typu kroku do procesu ESB.
Rysunek 3. Szczegóły kroku transformującego wiadomość
W polu Service Name (Rysunek 3 zaznaczenie 1.) wybrana została usługa typu dev.Transform, a w oknie parametrów (zaznaczenie 2.) wskazany został plik transformaty XSL. Jeżeli otworzymy plik TranslateOrder.xsl, zaznaczając pole Stylesheet URL i klikając je dwukrotnie, trzymając jednocześnie wciśnięty klawisz Ctrl, zostaniemy przeniesieni do edytora XSLT. W oknie źródła możemy ręcznie edytować odpowiednie mapowanie wartości pomiędzy wejściowym a wewnętrznym typem danych, wspierani przez szablony funkcji XSLT zamieszczone w panelu narzędzi. Możemy też przenieść się do widoku w zakładce Mapper, w którym zarówno za pomocą kodu jak i interfejsu graficznego możemy stworzyć interesujące nas mapowanie.
Rysunek 4. Zakładka Mapper edytora XSLT
Po stworzeniu mapowania w przykładzie posłużono się dwoma odwołaniami do usług webowych. Okna szczegółów tego typu kroków procesu zawierają trochę więcej szczegółów niż dotychczas zaprezentowane odwołanie do usługi ESB. Potrzebujemy jeszcze specjalnego pliku *.esbws zawierającego definicję wywołania. Natomiast format wiadomości SOAP wywołania i odpowiedzi są mapowane do wewnętrznego formatu danego procesu na dodatkowych zakładkach Request Mapping i Response Mapping. Na zakładce określającej przekształcenie wewnętrznych danych do wywołania usługi webowej można określić mapowanie poprzez filtrowanie zestawu danych, wyliczenie ich wartości za pomocą wyrażenia XPath i wskazanie odpowiadających im pól w interfejsie usługi webowej (Rysunek 5).
Rysunek 5. Zakładka Request Mapping
Natomiast na zakładce Response Mapping można podać odpowiednie mapowanie odpowiedzi uzyskanej z usługi webowej do formatu zdefiniowanego wewnątrz procesu za pomocą kilku z zdefiniowanych typów operacji (patrz Rysunek 6).
Rysunek 6. Zakładka Response Mapping
Sam plik definicji wywołania usługi webowej (typu ESBWS) pozwala na wskazanie definicji WSDL (która może znajdować się w repozytorium Sonic ESB, w lokalnym systemie plików lub w rejestrze UDDI) oraz określenie serwisu, portu i metody, która zostanie wywołana. Na potrzeby wiązania atrybutów pomiędzy interfejsem usługi webowej i wewnętrznie stosowanym interfejsem służącym do budowania mapowania możemy tu także określać dodatkowe właściwości (patrz Rysunek 7).
Rysunek 7. Okno konfiguracji odwołania do usługi webowej
Zaprezentowana na Rysunku 7 konfiguracja opisuje wywołanie usługi webowej. Ten sam ekran może być także wykorzystany do przekierowania informacji o uszkodzonej wiadomości do usługi webowej, czy też odczytania z niej odpowiedzi. Powróćmy jednak do definiowanego procesu. Jednym z jego kolejnych elementów jest odwołanie do podprocesu.
Rysunek 8. Edytor podprocesu z elementem służącym do wartościowania decyzyjnego
Rysunek 9. Okno edytora przekierowań wiadomości
W węźle Approval Sub-Process mamy do czynienia z wywołaniem ciekawego typu procesu, który pozwala na zaobserwowanie popularnego w świecie integracji systemów informatycznych wzorca projektowego Content-Based Router (CBR). W zależności od wartości danego parametru, w odpowiednim pliku (*.cbr) definiujemy regułę, która opisuje warunek. W oknie edytora zaprezentowanym na Rysunku 8 widzimy, jak w przypadku warunku zdefiniowanego za pomocą edytora przekierowań (Rysunek 9) można zarządzać odpowiednim wywołaniem kolejnych kroków w podprocesie: definiując kod JavaScript obliczający konkretne wartości, wykorzystując klasy pomocnicze z repozytorium Sonic ESB, itd.
W przykładzie prezentującym wzorce integracyjne (Sample.ESB7.0) możemy prześledzić często wykorzystywane przy integracji systemów elementy odpowiadające za importowanie i eksportowanie danych znajdujących się w systemie plików. Dodatkowym elementem, którego niestety nie będziemy mogli zaobserwować w przykładach, jest odwołanie się do bazy danych. Za pomocą usługi typu dev.DBService można wskazać plik wywołania polecenia z bazy danych (*.esbdb), które jest wykonywane w kontekście połączenia umożliwiającego dostęp do baz danych DB2, Informix, Progress Open Edge, Oracle, Sybase, SQL Server za pośrednictwem domyślnie zainstalowanych sterowników JDBC (listę tę możemy oczywiście rozszerzyć, dodając dodatkowe sterowniki).
Śledzenie wykonania procesu ESB
Opisane powyżej metody, jak i kilka innych usług związanych z dostępem i przetwarzaniem danych pozwalają na bardzo elastyczne budowanie procesów służących do integrowania zróżnicowanych systemów IT. Przedstawione powyżej możliwości nie wyczerpują funkcjonalności środowiska Sonic Workbench, np. warto zwrócić uwagę także na edytor scenariuszy testowych pozwalających na zdefiniowanie parametrów wejściowych i prześledzenie wykonania danego procesu. Aby stworzyć sesję śledzenia, wystarczy wybrać z menu (Rysunek 10) opcję Create Scenario i zdefiniować parametry wejściowe scenariusza testowego.
W danym kroku procesu możemy zdefiniować punkt przerwania wykonania danego procesu (Toggle Breakpoint - Rysunek 2), a następnie przy pomocy menu uruchomić proces w trybie debugowym i przy pomocy perspektywy Sonic Debug prześledzić wykonanie zadania (Rysunek 11).
Rysunek 10. Menu pozwalające na stworzenie i uruchomienie procesu
Rysunek 11. Perspektywa Sonic Debug
Podsumowanie
Wiemy już, jak zdefiniować nowy proces przy użyciu Progress Sonic Workbench. Zbudowany proces ESB należy oczywiście zapisać w repozytorium, przetestować przy użyciu Sonic Workbench i ewentualnie rozszerzyć tak, aby odzwierciedlał on potrzeby integracyjne danego środowiska IT.
W kolejnym odcinku opiszemy z jakimi operacjami wiąże się instalacja Sonic ESB i innych elementów systemu, czym tak naprawdę jest repozytorium Sonic ESB oraz jak wykorzystać kontrolę administracyjną. Jednym słowem pokażemy, jak stawiać pierwsze kroki w zarządzaniu systemem Progress Sonic ESB. Zapraszamy.
W Sieci
30-dniową wersję testową Sonic Workbench można pobrać ze strony Progress Software http://www.sonicsoftware.com/products/sonic_esb_family/index.ssp
Kontakt:
Parys Waicis
pwaicis@progress.com
ODCINEK 5 - SDJ nr 3/2007
Progress Sonic ESB – instalacja, repozytorium oraz konsola administracyjna (cz 1.)
Cykl poprzednich kilku odcinków klubu technicznego, pozwolił na bliższe zapoznanie się ze środowiskiem deweloperskim Progress Sonic Workbench. Niniejszy odcinek początkuje nową serię, dzięki której zdobędziemy wiedzę potrzebną do wykorzystania potencjału Progress Sonic ESB, w codziennej pracy. Orientując się już w możliwościach programistycznych jakie oferuje ta platforma, przejdziemy do omówienia aspektów związanych z instalacją, konfiguracją, zarządzaniem oraz monitorowaniem pracy korporacyjnej magistrali usług.
Scenariusze instalacji Progress Sonic ESB
W pierwszym odcinku naszego cyklu (SDJ nr 11/2006) wymieniliśmy kilka podstawowych elementów, z których zbudowana jest korporacyjna magistrala usług firmy Progress Software. W przypadku instalacji produktu mamy do czynienia z dwoma scenariuszami, które wpływają na zbiór instalowanego oprogramowania. W przypadku, gdy chcemy stworzyć środowisko programistyczne (najczęściej na jednej maszynie), zainstalować powinniśmy produkt Sonic Workbench, zintegrowany ze środowiskiem Eclipse, zawierający kompletny zestaw aplikacji firmy Progress. Natomiast, gdy planujemy przeprowadzić instalację na potrzeby systemu produkcyjnego, proces instalacji wymaga osadzenia każdego z produktów w zarządzanej domenie, wspierającej przesyłanie wiadomości, dostarczającej narzędzi administracyjnych oraz innych usług zapewniających sprawne działanie systemu (SonicMQ). Przypominamy, iż zestaw narzędzi Progress Sonic to właśnie SonicMQ oraz Sonic ESB, jak i serwery Sonic XML, Sonic Orchestration i Sonic Database.
W niniejszym odcinku skupimy się na prawidłowej instalacji środowiska deweloperskiego Progress Sonic Workbench, ale poruszymy także niektóre aspekty związane z instalowaniem pojedynczych elementów platformy ESB. Ze względu na ograniczoną objętość pominiemy też scenariusze szczegółowo omówione w dokumentacji produktu związane z aktualizacją oprogramowania, instalacją poprawek, czy też wskazówki dotyczące jego usuwania.
Instalacja Sonic Workbench
Po instalacji środowiska Sonic Workbench, w przypadku zachowania domyślnych ustawień, otrzymamy system zawierający wszystkie komponenty platformy Progress Sonic ESB, środowisko uruchomieniowe Java oraz środowisko programistyczne Eclipse. Po instalacji, można rozszerzyć instalację Eclipse o dodatkowe pluginy, istnieje również możliwość zintegrowania aktualnie zainstalowanej wersji Eclipse z pakietem Sonic Workbench (aczkolwiek wykracza poza zakres tego omówienia).
Przed rozpoczęciem instalacji warto odwiedzić stronę http://www.sonicsoftware.com/support/supported_platforms/index.ssp w celu weryfikacji listy systemów wspieranych przez producenta. Sprawdzić także należy: czy na dysku jest co najmniej 1,2 GB wolnej przestrzeni, czy port 2506 jest dostępny (ewentualnie ustalić, który port będzie przydzielony na potrzeby Sonic Workbench) oraz zweryfikować czy nie istnieją aktualnie zainstalowane elementy systemu Sonic (np. Sonic XML Server).
Instalacja w środowisku Windows
W przypadku systemu Windows, wystarczy rozpakować pakiet instalacyjny (lub umieścić płytę CD w nośniku), przejść do głównego katalogu pakietu instalacyjnego oraz dwukrotnie kliknąć plik setup.bat. Następnie należy wybrać opcję Sonic Workbench (patrz Rysunek 1), zapoznać się z warunkami licencji (potwierdzając przejście do kolejnych ekranów przyciskiem Next), a na ekranie zatytułowanym License key (control number) podać odpowiedni klucz licencji produktu Sonic Workbench V7.0.
Rysunek 1. Okno wyboru produktów Sonic
Kolejne ekrany umożliwiają wybór lokalizacji, w której będzie zainstalowany system (domyślnie jest to C:Sonic), port na którym na nasłuchiwać będzie broker, zdecydować czy chcemy instalować domyślnie wspieraną wersję JVM (Rysunek 2.).
Rysunek 2. Okno wyboru wersji środowiska Java.
Na każdym z ekranów swobodnie możemy pozostawić wartości domyślne, potwierdzając wybór kliknięciem przycisku Next. Po dłuższej chwili instalacja zostanie zakończona, a program instalacyjny zamykamy klikając przycisk Finish. System jest gotowy do użycia (nie ma potrzeby restartowania systemu Windows) – można już uruchomić Sonic Workbench (Start > Programs > Sonic Software > Sonic Workbench 7.0 > Sonic Workbench – patrz Rysunek 3.), a w razie potrzeby, podczas uruchamiania kliknąć Start Domain Manager (patrz poniżej Czym jest domena SonicMQ?).
Rysunek 3. Menu aplikacji Sonic Workbench
Instalacja w środowisku Linux
Instalacja na platformie Linux, nie odbiega do scenariusza instalacji w systemie Windows. Należy pamiętać o tym, iż proces instalacyjny powinien być uruchomiony z uprawnieniami użytkownika root. Skrypt instalacyjny (analogicznie do pliku setup.bat) to ./setup.sh, natomiast domyślny katalog instalacyjny to /opt/Sonic. Cały proces instalacji przebiega identycznie.
Jedynie po jej zakończeniu uruchamiamy Sonic Workbench w nieco inny sposób, mianowicie po przejściu do katalogu w którym zainstalowaliśmy pakiet oprogramowania Sonic, wykonujemy polecania:
cd Workbench7.0
./startworkbench.sh
Instalacja produktów Sonic SOA
Gdy chcemy prawidłowo przygotować się do procesu wdrażania systemu ESB, warto zainstalować poszczególne produkty należące do rodziny produktów Progress Sonic ESB (nawet na jednej, fizycznej maszynie). W tym celu instalujemy kolejno produkty, SonicMQ, Sonic ESB, Sonic XML Server, Sonic Orchestration Server i Sonic Database Server.
Pamiętając przedstawione na Rysunku 1. opcje wyboru, nie trudno się domyślić, iż proces instalacji będzie się sprowadzał do kilkukrotnego uruchomienia skryptu instalacyjnego, wyboru odpowiedniego pakietu, oraz, po odpowiedniej konfiguracji, dokonania jego instalacji na danej maszynie. Po zainstalowaniu pakietu SonicMQ, stworzona zostanie domyślna domena SonicMQ (patrz ramka) oraz otrzymamy dostęp do konsoli administracyjnej (o której więcej już w kolejnym odcinku).
Oczywiście proces instalowania każdego z pojedynczych składników może przybrać bardziej skomplikowane scenariusze, np. w przypadku instalacji w środowisku rozproszonym. Jednak taka podstawowa konfiguracja pozwoli na zapoznanie się bez przeszkód z aspektami dotyczącymi konfiguracji oraz administracji korporacyjną magistralą usług, o których więcej już w kolejnych odcinkach.
Podsumowanie
W tym odcinku omówiliśmy podstawy związane z instalacją systemu Progress Sonic ESB, zarówno w przypadku przygotowania środowiska na potrzeby programistów, jak i tworzenia rozwiązań produkcyjnych. Już w kolejnych odcinakach wykorzystamy tę wiedzę wprowadzając elementy związane z administracją i zarządzaniem platformą Progress Sonic ESB.
Czym jest domena SonicMQ?
Domena SonicMQ to grupa administracyjna zawierająca elementy oprogramowania Sonic takie jak zarządzane kontenery i elementy pośredniczące (ang. brokres) administrowane przy użyciu jednego centralnego węzła – tzw. Domain Manager.
Domain Manager to:
- Kontener JVM, świadczący usługi cache, komunikujący się z swoim własnym węzłem zarządczym i zapewniającym działanie innych komponentów Domain Manager.
- Broker odpowiedzialny za zarządzanie komunikacją pomiędzy dwoma głównymi funkcjami Domain Manager – Directory Service i Agent Manager.
- Directory Service, która to usługa zapewnia centralny punkt składowania i operowania na danych konfiguracyjnych oraz zarządzania działającym systemem.
- Agent Manager, z kolei monitoruje stan wszystkich kontenerów zarządzanych w danej domenie.
Dodatkowe informacje
Progress Software Corporation jest dostawcą infrastruktury do rozwoju, wdrażania , integracji i zarządzania aplikacjami biznesowymi.
Więcej informacji: http://www.progress.com
Artykuły z cyklu Progress Sonic ESB
- Progress Sonic ESB – efektywna i bezpieczna architektura SOA (SDJ nr 11/2006),
- Korporacyjna magistrala usług – tworzenie projektu w środowisku Progress Sonic Workbench (SDJ nr 12/2006),
- Progress Sonic ESB – tworzenie usługi w środowisku Progress Sonic Workbench (SDJ nr 1/2007),
- Progress Sonic ESB – tworzenie procesów w środowisku Progress Sonic Workbench (SDJ nr 2/2007).
Wszystkie odcinki klubu dostępne są do pobrania w sekcji download na http://www.sdjournal.org
Kontakt:
Parys Waicis
pwaicis@progress.com
ODCINEK 6 - SDJ nr 4/2007
Progress Sonic ESB – Korporacyjna magistrala usług – instalacja, repozytorium oraz konsola administracyjna (cz. 2)
W poprzedniej części klubu technicznego zainicjowaliśmy cykl zagadnień dotyczących zarządzania platformą Progress Sonic ESB, rozpoczynając od omówienia zagadnień związanych z instalacją produktu. Niniejszy odcinek, kontynuując tematykę, zawiera opis narzędzi służących do konfiguracji i zarządzania korporacyjną magistralą usług. Przedstawimy więc konsolę zarządzania – Sonic Management Console, służącą do konfigurowania kontenerów i brokerów SonicMQ, omówimy sekcję ESB Configured Objects, za pomocą której zarządzamy, z poziomu konsoli, kontenerami ESB, punktami końcowymi, usługami, procesami ESB oraz procesem rejestrowania tych elementów w kontenerze ESB. Omówimy także narzędzie ESB Admin Tool, które pozwala na zarządzanie środowiskiem z poziomu linii poleceń. Nim przejdziemy do szczegółowego przedstawienia poszczególnych narzędzi służących do zarządzania i konfiguracji systemu Sonic ESB, należy przypomnieć, że oprócz prawidłowej ich instalacji podstawowym krokiem jest uruchomienie SonicMQ Domain Manager – centralnego węzła, dzięki któremu możemy zarządzać systemem. Przypomnijmy – kontroler domeny uruchamiamy poleceniem Start>ProgramsSonic Software>SonicMQ 7.0>SonicMQ DomainManager (Windows) lub ./bin/startcontainer.sh (Linux).
Konsola zarządzania
Sonic Management Console to graficzne narzędzie służące do konfiguracji, zarządzania i monitorowania poprzednio skonfigurowanych obiektów w danej domenie. Aby uruchomić Sonic Management Console wybieramy opcję Start>Programs>Sonic Software>Sonic ESB 7.0 > Management Console (Windows) lub ./bin/startmc.sh (Linux). Zostaniemy poproszeni o zdefiniowanie połączenia z kontrolerem domeny (Rysunek 1). W przypadku, gdy korzystamy z lokalnej instalacji większość domyślnych parametrów możemy pozostawić bez zmian i, wykorzystując domyślne hasło (Administrator), możemy spróbować podłączyć się do kontrolera (oczywiście pod warunkiem, że był wcześniej uruchomiony).
Rysunek 1. Okno konfiguracji połączenia z kontrolerem domeny Sonic ESB
Domyślnie po nawiązaniu prawidłowego połączenia zostanie zaprezentowany widok konfiguracji. Na Rysunku 2. został zaprezentowany widok poprzednio dodanych kontenerów ESB - z tego poziomu możemy konfigurować obiekty.
Rysunek 2. Okno konfiguracji obiektów z zaznaczonym węzłem ESB Containers
Po przejściu na zakładkę Manage możemy obserwować i zarządzać stanem poszczególnych obiektów, a po połączeniu się z drugim kontrolerem domeny, możemy zadania te wykonywać z poziomu tej samej konsoli. Rysunek 3 to przykładowy zrzut ekranu konsoli podczas pracy systemu.
Rysunek 3. Panel pozwalający na monitoring dwóch kontrolerów z poziomu jednej konsoli
Z poziomu konsoli mamy dostęp nie tylko do podstawowych informacji o systemie – możemy także bezpośrednio konfigurować elementy infrastruktury ESB. Wykorzystujemy w tym celu grupę opcji dostępnych w węźle ESB Configured Objects, drzewa narzędzi dostępnych na zakładce Configure konsoli zarządzania. Rozwijając węzły drzewa (reprezentujące kolejno: punkty końcowe, kontenery ESB, procesy i usługi ESB) możemy konfigurować parametry każdego pojedynczego elementu. Rysunek 4 przedstawia widok konsoli z rozwiniętym węzłem reprezentującym kontenery ESB (więcej informacji o konfiguracji poszczególnych elementów przedstawimy już w następnym odcinku klubu technicznego, niniejszy odcinek prezentuje tylko możliwości narzędzi konfiguracyjnych.)
Rysunek 4. Sonic Management Console z zaznaczonym kontenerem ESB „VerificationContaniner”.
Z poziomu sekcji narzędzi ESB Configured Objects mamy bardzo łatwy dostęp do większości elementów korporacyjnej magistrali usług i możemy wykonać niemal wszystkie zadania związane z zarządzaniem Sonic ESB.
ESB Admin Tool
Jednak, o ile większość zadań można wykonać z poziomu Sonic Management Console, to niektórzy administratorzy mogą skorzystać z pomocy narzędzia ESB Admin Tool w celu wywoływania poleceń z linii komend. Jest to szczególnie przydatne podczas importowania lub eksportowania typów serwisów, czy też konfiguracji serwisów, punktów końcowych oraz połączeń.
Aby uruchomić narzędzie wybieramy opcję Start > Programs > Sonic Software > Sonic ESB > ESB Admin Tool. W przypadku konsoli polecenie służące do połączenia z kontrolerem domeny to connect Domain1 tcp://localhost:2506 Administrator Administrator, w celu zakończenia pracy z konsolą wystarczy użyć komendy exit.
Podstawowe komendy, którymi możemy posługiwać się z poziomu tej konsoli to wykorzystane już connect, jego odpowiednik – disconnect, exit i bye. Z pewnością też dość często wydamy polecenie help (?). Bardziej zaawansowane komendy pozwalają na interakcje z systemem plików SonicFS (poprzez komendy takiej jak np. add / delete / export file lub directory), zarządzanie kolekcją typów ESB (tu mamy do czynienia z wylistowaniem obiektów (list), ich importem i eksportem etc.), możemy także zarządzać licencjami, zatrzymywać i uruchamiać kontenery. Mamy także dostęp do wielu narzędzi wspomagających tworzenie oprogramowania lub typowo diagnostycznych. Słowem – konsola tekstowa ESB Admin Tool to narzędzie pozwalając na bardzo elastyczną ingerencję w konfigurację systemu.
Podsumowanie
W tym odcinku omówiliśmy zestaw narzędzi, dzięki którym możemy zarządzać oraz odpowiednio skonfigurować platformę Progress Sonic ESB. Opcje przedstawione w niniejszym klubie technicznym nie wyczerpują jednak tematu związanego z konfiguracją platformy. Już w kolejnych odcinkach wykorzystamy przedstawione dziś narzędzia w celu demonstracji zadań związanych bezpośrednio z konfiguracją poszczególnych elementów platformy Progress Sonic ESB.
Dodatkowe informacje
Progress Software Corporation jest dostawcą infrastruktury do rozwoju, wdrażania , integracji i zarządzania aplikacjami biznesowymi.
Więcej informacji: http://www.progress.com
Artykuły z cyklu Progress Sonic ESB
- Progress Sonic ESB – efektywna i bezpieczna architektura SOA (SDJ nr 11/2006),
- Korporacyjna magistrala usług – tworzenie projektu w środowisku Progress Sonic Workbench (SDJ nr 12/2006),
- Progress Sonic ESB – tworzenie usługi w środowisku Progress Sonic Workbench (SDJ nr 1/2007),
- Progress Sonic ESB – tworzenie procesów w środowisku Progress Sonic Workbench (SDJ nr 2/2007),
- Progress Sonic ESB – Korporacyjna magistrala usług – instalacja, repozytorium oraz konsola administracyjna (cz. 1) (SDJ 3/2007).
Wszystkie odcinki klubu dostępne są do pobrania w sekcji download na http://www.sdjournal.org
ODCINEK 7 - SDJ nr 5/2007
Progress Sonic ESB
Korporacyjna magistrala usług – konfiguracja brokerów i akceptorów
Jak już niejednokrotnie wspominaliśmy, nieodłącznym elementem korporacyjnej magistrali usług Progress Sonic ESB jest platforma komunikacyjna SonicMQ. Kontynuując cykl omawiania funkcji związanych z konfiguracją systemu, w niniejszym klubie technicznym omówimy zagadnienia związane z konfiguracją brokerów oraz akceptorów.
Zarządzanie brokerami
W przypadku domyślnej konfiguracji SonicMQ (omówionej w poprzednich odcinkach), w systemie zostaje zainstalowany broker MgmtBroker odpowiedzialny za zarządzanie konfiguracją i kilka dodatkowych brokerów służących do przekazywania wiadomości (nazwy tychże brokerów można odpowiednio skonfigurować w trakcie instalacji).
Tworzenie nowego brokera
Aby stworzyć broker można wykorzystać istniejące w systemie szablony lub po prostu skopiować konfigurację istniejącego brokera. Kolejnym krokiem, w celu zapewnienia pełnej funkcjonalności brokera, jest dodanie go do odpowiedniego kontenera, – w tym celu możemy posłużyć się poprzednio omówionym narzędziem Sonic Management Console. Na zakładce Configure należy wybrać opcję New > Configuration (patrz Rysunek 1).
Rysunek 1. Okno dialogowe Sonic Management Console służące do tworzenia konfiguracji
Następnie na zakładce From Types należy kliknąć Create New Configuration, wybrać opcję Shortcut to Broker i potwierdzić wybór. Pojawi się okno New Broker (Rysunek 2). Posługując się nim, musimy podać unikalną nazwę brokera w danym kontenerze (nie może być dłuższa niż 15 znaków) oraz numer licencji, na podstawie którego system określa, jakie opcje konfiguracyjne są dostępne (np. czy możliwy jest dostęp do replikacji brokerów w celu zapewnienia niezawodności). Dobrą praktyką jest nadawanie unikalnych nazw brokerów, ponieważ gdy definiuje się brokera wspierającego mechanizmy bezpieczeństwa, automatycznie tworzony jest użytkownik z tą samą nazwą -– w ten sposób brokery z taką samą nazwą mogą wykorzystać tego samego użytkownika.
Rysunek 2. Okno konfiguracyjne pozwalające na stworzenie nowego brokera
Po podaniu podstawowych parametrów konfiguracyjnych, możemy wybrać opcję Product Information i w oknie dialogowym Broker Production Information zrewidować opcje dostępne w danym systemie (przykład na Rysunek 3).
Rysunek 3. Lista dostępnych opcji wybranego brokera
Jeżeli wybierzemy opcję Evaluation Mode (dostępną w wersji demo), wydajność systemu wzrośnie w wyniku tego, że operacje dyskowe związane z przekazywaniem wiadomości trwałych oraz objętych transakcjami będą wykonywane szybciej, ponieważ system nie będzie starał się zapewnić pełnego odzyskiwania stanu w przypadku awarii. Chociaż wydajność w przypadku wykorzystania takiego trybu wzrasta, to nie jest on zalecany przez producenta.
Podstawowe opcje konfiguracji brokera
Po stworzeniu nowego wpisu konfiguracyjnego można przystąpić do konfiguracji podstawowych parametrów brokera, przy czym należy pamiętać, że niektóre opcje wymagają jego ponownego uruchomienia. W przypadku gdy zmieniamy dane konfiguracyjne, w systemie musi być zainicjalizowany komponent odpowiadający za ich przechowywanie. Aby uniknąć jego uruchamiania za każdym razem, na zakładce General należy podać nazwę danego brokera, ustawić opcje bezpieczeństwa, QoP Cipher Suite, na zakładce Tubing podać rozmiar log’u odzyskiwania oraz, a na zakładce Storage podać typ bazy danych wykorzystanej do przechowywania danych (może to być komponent wbudowany lub zewnętrzny element).
Przejdziemy teraz do omówienia kroków potrzebnych do skonfigurowania podstawowych parametrów nowo utworzonego lub istniejącego brokera. Opcje te staną się dostępne w oknie dialogowym Edit Broker, gdy po zaznaczeniu interesującego nas brokera wybierzemy ikonę Properties. Jeżeli broker funkcjonuje w ramach środowiska klastrowego, na liście wyboru należy wybrać nazwę danego klastra (tak jak to zaprezentowano na Rysunku 4), a broker stanie się jego składnikiem.
Rysunek 4. Dialog wyboru klastra
Na zakładce Security należy podać opcje dot. bezpieczeństwa (jest to szczególnie ważne w przypadku brokera działającego w ramach klastra). Wybranie opcji Security implikuje konieczność wskazania tzw. Authentication Domain (domeny, która odpowiada za zarządzanie użytkownikami i grupami danego brokera). Podobnie jak w przypadku klastra, domenę uwierzytelniania wybieramy z listy (patrz Rysunek 5).
Rysunek 5. Dialog wyboru domeny uwierzytelnienia
Następnie należy wybrać z listy Authorization Policy (Rysunek 6) zestaw uprawnień, który definiuje ustawienia QoP oraz ACL danego brokera (lub całego klastra).
Rysunek 6. Dialog wyboru grupy uprawnień
Uprawnienia są najczęściej ściśle powiązane z domenami uwierzytelniania, ponieważ są ustawiane w kontekście nazw użytkowników, grup i członków grup. Można w ten sposób stworzyć grupę uprawnień, która może być użyta dla wielu różnych domen, jednak utrzymanie tego typu elastycznej konfiguracji bywa dość kłopotliwe.
W przypadku brokera, który wcześniej nie był uwierzytelniony, należy ustawić hasło dla danego brokera oraz domeny uwierzytelniania. Wykorzystujemy do tego celu okno dialogowe Set Broker Password. W celu wykorzystania możliwości szyfrowania wiadomości należy wybrać opcję Set QoP Cipher Suite i posłużyć się oknem dialogowym Edit Cipher Suite Properties (Rysunek 7) w celu ustawienia odpowiednich opcji.
Rysunek 7. Dialog wyboru opcji szyfrowania
Dostępne szyfry to DES, DESede, Blowfish, AES, CBC, ECB, PCBC, PKCS5 Padding, podpisy MD5 i SHA oraz klucze (odpowiednio dla szyfrów) DES: 56, DESede: 56, 112, Blowfish; 32, 56, 112, 168 i 448, jak i dla szyfru AES: 128, 192 i 256. Możliwość wykorzystania wbudowanych funkcjonalności zapewniających bezpieczeństwo oraz zintegrowania ich z istniejącymi mechanizmami zostanie omówiona w jednym z kolejnych odcinków klubu technicznego.
Jeżeli dany broker wspiera standard WS-Security, kolejnym krokiem podczas definiowania podstawowej konfiguracji będzie wybranie Certificates Store (magazynu certyfikatów) z listy na zakładce WebService. SonicMQ przechowuje certyfikaty w formacie X.509.v3 i wykorzystuje jest w celu przetwarzania weryfikacji danych przychodzących oraz podpisywania danych wychodzących z danego brokera. Okno dialogowe ustawień dotyczących konfiguracji na potrzeby WS-Security zaprezentowano na Rysunku 8.
Rysunek 8. Okno dialogowe ustawień WS-Security
Posługując się tymże panelem, podajemy lokalizację pliku Java Keystore (JKS), który zawiera klucze prywatne oraz ich certyfikaty wykorzystywane do odkodowania wiadomości oraz ich podpisania, a następnie podajemy lokalizację pliku JKS używanego do ustalania wartości haseł wykorzystywanych podczas nawiązywania interakcji z innymi instancjami SonicMQ oraz systemami zewnętrznymi (broker nie będzie ufał wiadomościom przesłanym ze źródła zewnętrznego, jeżeli nie zostanie ono odpowiednio uwierzytelnione). Podajemy także wartości User Name Token i X.509.v3. Token używane w komunikacji polegającej na certyfikatach X.509.v3.
Definiując podstawowe parametry pracy brokera, możemy zakończyć proces jego konfiguracji, – warto jednak odpowiednio skonfigurować także bardziej zaawansowane opcje.
Zaawansowane opcje konfiguracji brokera
Platforma SonicMQ pozwala na ingerowanie w bardziej złożone parametry konfiguracyjne brokera, takie jak ustawienia połączenia SSL, wskazanie lokalizacji, w której będą przechowywane wiadomości, wykrywanie dublujących się brokerów, parametry śledzenia, odzyskiwania itp.
Rysunek 9. Zakładka konfiguracji opcji SSL brokera
Na zakładce SSL (Rysunek 9) podajemy szyfr wykorzystywany do komunikacji. W zależności od wybranej rodziny (RSA, JSSE lub IAIK) będziemy musieli przeprowadzić szereg dodatkowych operacji, takich jak zdefiniowanie lokalizacji zestawów certyfikatów, parametrów pracy cache haseł czy też np. wskazanie adresu URL serwera LDAP przechowującego uprawnienia wykorzystywane podczas komunikacji SSL.
Przechodząc do zakładki Tuning (Rysunek 10.), możemy odpowiednio skonfigurować parametry wpływające bezpośrednio na wydajność pracy danego brokera. Szczególną uwagę należy tutaj zwrócić na bufory, które w ogólności pozwalają na tworzenie większej kolejki wiadomości wysyłanych (dla systemu, który będzie przesyłał wiadomości o dużych rozmiarach, należy ustawić odpowiednio większe wartości). Grupa opcji Recovery log definiuje, w jaki sposób obsługiwane są jeszcze nie przekazane wiadomości, zaś Transactions pozwala na ustalanie transakcyjnych parametrów pracy brokera.
Rysunek 10. Zakładka pozwalająca na odpowiednią optymalizację pracy brokera
Zakładka Storage służy do definiowania parametrów miejsca, w którym będą przechowywane wiadomości adresowane do odłączonych końcówek. Domyślnie jest to wewnętrzna składnica danych, ale może to być zewnętrzna baza zapewniająca komunikację JDBC. W celu odpowiedniego zdefiniowania zachowania brokera w przypadku wykrycia już istniejącej instancji danego brokera, należy podać parametry na zakładce Duplicate. Parametry odpowiedzialne za częstotliwość odświeżania informacji o danym brokerze ustawiamy na zakładce Metrics. Natomiast w przypadku brokerów wykorzystujących zewnętrzne zasoby (np. pakiety zwierające funkcje pomocnicze), musimy podać ich lokalizację, posługując się zakładką Resources.
Przy użyciu zakładki Advanced (Rysunek 11) możemy określić, dla jakich progów mają być wysyłane notyfikacje o przekroczeniu limitu odrzuconych wiadomości (DMQ) lub nadmiernym przyroście log’u odzyskiwania. Posługując się tą zakładką możemy także odpowiednio skonfigurować parametry pracy w środowisku z równoważonym obciążeniem, czy też definicję proxy odpowiedzialnego za przekazywanie wiadomości. Dodatkowa opcja pozwala na bezpośrednie podawanie par typu parametr – wartość, które umożliwiają uzyskanie dostępu do opcji niedostępnych z poziomu interfejsu graficznego.
Rysunek 11. Zaawansowane ustawienia pracy brokera
Wspomniana opcja równoważenia obciążenia (ang. load balancing) pozwala systemowi przekazać wiadomości do innych brokerów w celu rozłożenia obciążenia na kilka brokerów w klastrze, – SonicMQ wykorzystuje w tym celu algorytm karuzelowy (ang. round-robin). Elementem pozwalającym na przekazanie przetwarzania do grupy brokerów są akceptatory, których nazwy są generowane automatycznie dla każdego nowego brokera (ale możemy je także tworzyć własnoręcznie).
Zarządzanie akceptatorami
Domyślnie wszystkie akceptatory odpowiedzialne za obsługę tego samego protokołu są mapowane do tej samej wygenerowanej nazwy. Dopiero w ramach brokerów podpisanych pod ten sam akceptator, algorytm karuzelowy, posługując się wartością wagi (zdefiniowaną w polu Load Balancing Weight zakładki Advanced konfiguracji brokera), stara się odpowiednio wiele razy przekazać wiadomość do danego brokera.
Dla każdego brokera możemy zdefiniować jeden lub więcej akceptatorów, tworząc w ten sposób różne punkty dostępowe (każdy akceptator może definiować inny protokół, nazwę maszyny i port, na którym będzie dostępny dany broker).
Wykorzystując konsolę zarządzania, można zdefiniować domyślną konfigurację dla wszystkich akceptatorów, odpowiednio skonfigurować akceptatory TCP, ich poziom bezpieczeństwa z wykorzystaniem protokołu SSP, tunelowanie HTTP(S) i bezpośrednie przekazywanie ruchu pomiędzy akceptatorami.
W celu konfiguracji parametrów pracy dla wszystkich akceptatorów w systemie, na zakładce Configure konsoli zarządzania, wybieramy opcję Acceptators, a następnie opcję Properties.
Rysunek 12. Wybór domyślnego akceptatora
Na Rysunku 12 widzimy okno, którym posługujemy się w celu wskazania domyślnego akceptatora (w systemie musi być zdefiniowany przynajmniej jeden akceptator). Na zakładce HTTP można odpowiednio skonfigurować parametry odpowiedzialne za przyjmowanie połączeń HTTP.
W celu zapewnienia większej odporności na awarie, dla każdego brokera możemy zdefiniować kilka akceptatorów o tej samej nazwie, ale wskazujących na inne fizyczne lokalizacje (patrz Rysunek 13)
Rysunek 13. Konsola zarządzania prezentująca konfigurację z redundantnymi akceptatorami
Taka konfiguracja jest kopiowana wraz z kopiowaniem ustawień danego brokera (przy jego duplikacji) i odpowiednio wykorzystywana na potrzeby optymalizacji wydajności systemu.
Tworzenie nowego akceptatora
W celu dodania nowego akceptatora, na zakładce Configure w konfiguracji brokera, należy wybrać węzeł Acceptators i wybrać opcję prowadzącą do definiowania nowego akceptatora, np. New > TCP/SSL. Pojawi się okno dialogowe pozwalające na podanie szczegółów pracy danego akceptatora (patrz Rysunek 14).
Rysunek 14. Konfiguracja parametrów pracy akceptatora TCP
Jak widzimy na przykładzie akceptatora TCP, system z poziomu interfejsu użytkownika pozwala na odpowiednie skonfigurowanie opcji takich jak host i port, jak i na zdefiniowanie mapowania w przypadku mapowania NAT, urządzeń optymalizujących ruch SSL (np. zewnętrznych rozwiązań sprzętowo wspomagających kodowanie SSL).
Zabezpieczanie akceptatora
Na zakładce SSL możemy określić konfiguracje odpowiedzialne za zabezpieczenie ruchu wiadomości przechodzących przez akceptator, ustawiając opcje podobne do znanych już opcji konfiguracyjnych SSL brokera, do którego dodajemy akceptator (patrz Rysunek 15)
Rysunek 15. Konfiguracja parametrów zabezpieczeń SSL danego brokera.
Akceptatory HTTP(S)
W celu zapewnienia większej elastyczności pracy systemu, można odpowiednio skonfigurować tunelowanie, można także wykorzystać przekazywanie wiadomości z wykorzystaniem akceptatorów. W tym celu mamy do dyspozycji akceptatory opierające się o proste przekazywanie wiadomości na podstawie protokołu wiadomości odebranej na danym porcie. Przy takiej konfiguracji system pozwala na określenie, jakiego typu wiadomości (XML, tekst, dane binarne itp.) spodziewamy się otrzymywać na danym akceptatorze oraz pozwala na wskazanie punktu docelowego.
W bardziej zaawansowanych scenariuszach, możemy wykorzystać akceptatory bezpośrednio pracujące na wiadomościach protokołu SOAP, JMS oraz specjalny akceptator zapewniający wsparcie dla standardów WS-Security i WS-ReliableMessaging. Niestety, z racji złożoności tematu, szczegółowe poznanie poszczególnych opcji definiowania pracy akceptatorów pozostawiamy zainteresowanym Czytelnikom.
Podsumowanie
W tym odcinku omówiliśmy opcje odpowiedzialne za konfigurację brokerów oraz akceptatorów - – nieodłącznych elementów infrastruktury SonicMQ zapewniającej przesyłanie wiadomości na potrzeby platformy Progress Sonic ESB. Mimo, iż przedstawione informacje jedynie pobieżnie poruszają ten złożony temat, mamy nadzieję, że niniejszy klub techniczny pozwolił na przybliżenie tychże aspektów pracy systemu oraz na zaprezentowanie jego elastyczności w zakresie konfiguracji oraz bezpieczeństwa.
W kolejnym odcinku przejdziemy do omówienia zagadnień związanych z konfiguracją kontenerów i usług ESB. Pozwoli to nam w pełni poznać możliwości konfiguracyjne systemu Progress Sonic ESB (w tym szczególnie ważne elementy związane z zarządzaniem bezpieczeństwem).
Dodatkowe informacje
Progress Software Corporation jest dostawcą infrastruktury do rozwoju, wdrażania , integracji i zarządzania aplikacjami biznesowymi.
Więcej informacji: http://www.progress.com
Artykuły z cyklu Progress Sonic ESB
- Progress Sonic ESB – efektywna i bezpieczna architektura SOA (SDJ nr 11/2006),
- Korporacyjna magistrala usług – tworzenie projektu w środowisku Progress Sonic Workbench (SDJ nr 12/2006),
- Progress Sonic ESB – tworzenie usługi w środowisku Progress Sonic Workbench (SDJ nr 1/2007),
- Progress Sonic ESB – tworzenie procesów w środowisku Progress Sonic Workbench (SDJ nr 2/2007),
- Progress Sonic ESB – korporacyjna magistrala usług - instalacja, repozytorium oraz konsola administracyjna (cz.1) (SDJ nr 3/2007),
- Progress Sonic ESB – korporacyjna magistrala usług – instalacja, repozytorium oraz konsola administracyjna (cz.2) (SDJ nr 4/2007).
Wszystkie odcinki klubu dostępne są do pobrania w sekcji download na http://www.sdjournal.org
 Artykuły do pobrania
|
Artykuł do pobrania
