Tworzenie elastycznego systemu w dynamicznym

XIV Konferencja PLOUG
Szczyrk
Październik 2008
Tworzenie systemu informatycznego
w dynamicznie zmieniającym się środowisku biznesowym w oparciu o technologie
workflow, usługi sieciowe i ESB
Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz
Uniwersytet im. Adama Mickiewicza, Poznań
e–mail: [email protected], [email protected], [email protected], [email protected]
Abstrakt. W niniejszym artykule przedstawiona zostanie metoda integracji systemu opartego na technologii workflow z zewnętrznymi
komponentami (np. aplikacjami, procesami lub urządzeniami fizycznymi) posiadającymi różne interfejsy Web Service. Opisany sposób
integracji zakłada, że komponenty zewnętrzne posiadają różniące się interfejsy oraz mogą być dynamicznie dodawane do działającego
systemu. Proponowana meto-da opiera się na wykorzystaniu języka BPEL (ang. Business Process Execution Language) w połączeniu
z komponentem ESB (ang. Enterprise Service Bus) w celu dynamicznej integracji zewnętrznych Web Serv-ice'ów. Jako przykład
implementacji przedstawiony zostanie moduł invokeATP stworzony w ramach pro-jektu europejskiego VISP (ang. Virtual Internet
Service Provider).
Informacja o autorach. MARCIN PISANKO jest absolwentem Uniwersytetu Technologiczno-Przemysłowego w Bydgoszczy. W 2007
roku ukończył studia o kierunku Elektronika i Telekomunikacja. Odbył staż zawodowy w firmie Lucent Technologies (obecnie AlcatelLucent), gdzie zajmował się urządzeniami dostępowymi ADSL. Następnie w firmie ITTI Sp. z o.o. zajmował się problematyką automatyzacji procesów biznesowych oraz systemami workflow. Od 2002 roku pracuje w firmie ZP Serwis w Bydgoszczy, obecnie na stanowisku projektanta-programisty, gdzie zajmuje się tworzeniem aplikacji i systemów wykorzystujących przenośne komputery przemysłowe.
Poza pracą w ZP Serwis zaangażowany jest jako pracownik kontraktowy Uniwersytetu im. Adama Mickiewicza w finansowany przez
Unię Europejską projekt europejski VISP, którego celem jest stworzenie platformy umożliwiającej integrację usług internetowych
świadczonych przez różnych dostawców usług.
RAFAŁ KNAPIK ukończył kierunek Informatyka Politechniki Poznańskiej w 2001 roku. Od 1999 do 2001 roku zajmował się tworzeniem aplikacji internetowych w firmie 7bulls.com. Następnie zajmował się administracją serwera internetowego w firmie Syberia,
a przez kolejne 3 lata zatrudniony był na stanowisku programisty-analityka w firmie Polarys, gdzie zajmował się aplikacjami bankowymi
oraz systemami typu firewall. Obecnie pracuje w firmie ITTI na stanowisku starszego konsultanta. Brał udział w takich projektach, jak
system udostępniania informacji przez Internet za pomocą quasi-inteligentnego modułu komunikacyjnego, system archiwizacji plików
historycznych systemu bankowości detalicznej, system wymiany informacji o klientach z centralą grupy bankowej za pomocą kolejek
MQSeries oraz tworzenie strategii informatyzacji dla jednostki administracji publicznej. Poza pracą w ITTI zaangażowany jest jako
pracownik kontraktowy Uniwersytetu im. Adama Mickiewicza w finansowany przez Unię Europejską projekt europejski VISP, którego
celem jest stworzenie platformy umożliwiającej integrację usług internetowych świadczonych przez różnych dostawców usług.
RAFAŁ RENK jest absolwentem Akademii Techniczno-Rolniczej (obecnie Uniwersytet Technologiczno-Przemysłowy) w Bydgoszczy,
którą ukończył w 1998 roku. W ATR pracował nad zagadnieniami związanymi z trójwymiarowymi światami wirtualnymi. Od 1998 roku
jest pracownikiem ITTI, gdzie piastuje obecnie stanowisko dyrektora ds. rozwoju. Rafał Renk wykonywał oraz współkierował szeregiem
projektów poruszających tematykę sieci telekomunikacyjnych w aspekcie technicznym i biznesowym oraz zagadnień informatycznych
związanych z: inżynierią oprogramowania, technologiami internetowymi, aplikacjami i systemami baz danych oraz technologią
i metodyką zdalnego kształcenia multimedialnego z systemami zdalnego nauczania oraz projektowania hurtowni danych. Projekty
o tematyce telekomunikacyjnej dotyczyły zarówno rynku polskiego, jak i międzynarodowego, a ich tematyka obejmowała m.in. analizy
rynkowe (w zakresie telefonii IP, transmisji danych itp.), tworzenie strategii budowy i rozbudowy sieci telekomunikacyjnych zarówno
dostępowych jak i szkieletowych a także zagadnienia techniczne związane z VoIP, sieciami dostępowymi, sieciami szkieletowymi,
protokołami i standardami technologii internetowych, strumieniowania, jakością usług w sieci IP oraz systemów zdalnego nauczania.
Prace związane z systemami zdalnego nauczania obejmowały zagadnienia związane ze standaryzacją tego typu systemów oraz przeprowadzania i automatycznej oceny wyników egzaminów (wykorzystanie języka XML i ontologii). Rafał Renk jest również autorem bądź
współautorem licznych publikacji i wystąpień na krajowych oraz zagranicznych konferencjach.
WITOLD HOŁUBOWICZ jest absolwentem Wydziału Elektrycznego Politechniki Poznańskiej, gdzie uzyskał stopnie doktora i doktora
habilitowanego. W latach 1987-89 był wykładowcą na Politechnice w Nowym Jorku, a w latach 1992-96 we Francusko-Polskiej Wyższej Szkole Nowych Technik Informatycznych i Komunikacyjnych (EFP) w Poznaniu. Od października 1996 r. jest profesorem na
Wydziale Telekomunikacji i Elektrotechniki Uniwersytetu Technologiczno-Przemysłowego (była Akademia Techniczno-Rolnicza)
w Bydgoszczy. Jest również profesorem i kierownikiem Zakładu Informatyki Stosowanej na Uniwersytecie im. A. Mickiewicza (od 2003
roku). Od 1996 r. jest także zawodowo związany z Instytutem Technik Telekomunikacyjnych i Informatycznych (ITTI) w Poznaniu,
gdzie pełni obecnie funkcję prezesa zarządu. Jest również współtwórcą i przewodniczącym Komitetu Programowego Krajowej Konferencji Radiokomunikacji Ruchomej w Poznaniu (KKRR) w latach 1996-2000. Zainteresowania zawodowe Witolda Hołubowicza obejmują m.in. radiokomunikację (w tym technologie transmisji z poszerzonym widmem CDMA), aspekty techniczno-rynkowe sieci komunikacji ruchomej GSM i UMTS, aspekty usługowe sieci komórkowych i konwergentnych. Uczestniczył i kierował wieloma projektami
naukowo-badawczymi i wdrożeniowymi, w tym również realizowanymi pod egidą Komisji Europejskiej. Witold Hołubowicz jest autorem ponad 100 publikacji zamieszczonych w czasopismach naukowych krajowych i zagranicznych oraz w materiałach konferencyjnych.
Jest również współautorem 4 książek z zakresu łączności bezprzewodowej.
Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku...
153
Wprowadzenie
Procesy biznesowe modelowane za pomocą standardu WS-BPEL 2.0 (w dalszej części określany jako BPEL) [BPEL2.0] koordynują przepływ działań i zapewniają odpowiedni przepływ informacji pomiędzy tymi działaniami. Większość działań procesu jest wykonywanych poprzez
zewnętrzne usługi sieciowe (ang. Web Services), jedynie proste działania mogą być implementowane przy użyciu samego języka BPEL. W niektórych sytuacjach to samo działanie procesu może
być wykonywane poprzez różnorodne usługi dostarczane przez różnych dostawców usług. Innymi
słowy w jednym przypadku w procesie można użyć dostawcę usługi A w innym przypadku tego
samego procesu można skorzystać z dostawcy usługi B. W niniejszym artykule termin system
dynamiczny będzie używany na określenie systemu, w którym zachodzi dynamiczny wybór usług.
BPEL posiada podstawowe cechy, które umożliwiają tworzenie procesów dla systemów dynamicznych:
• standardowy mechanizm dla korelacji wiadomości w komunikacji asynchronicznej,
• możliwość ustawienia w sposób dynamiczny partnerskich hiperłączy stanowiących punkty
końcowe – adresy usług, z którymi komunikuje się proces,
• wbudowany procesor XSLT [XSLT].
Wymienione cechy pozwalają na dynamiczny wybór dostawcy oferującego usługę o wcześniej
ustalonym interfejsie, umożliwiają one również dynamiczne przetwarzanie i tworzenie wiadomości przy użyciu np. transformacji XLST stworzonych dla tego dostawcy.
Poniżej przedstawiono model systemu, który komunikuje się z interfejsami usługi sieciowej
różnych urządzeń fizycznych, które mogą dynamicznie zostać dodane do systemu. Schemat takiej
sytuacji jest przedstawiony na Rysunku 1. Reszta systemu komunikuje się z usługami sieciowymi
różnych urządzeń w zależności od informacji dostarczanych przez resztę systemu.
Rys. 1. Komunikacja systemu z zewnętrznymii urządzeniami fizycznymi
Jeśli urządzenia fizyczne przynależą do tej samej klasy, czyli posiadają podobne funkcjonalności, ich interfejsy zwykle są podobne - zawierają podobne operacje, które z kolei wytwarzają podobne informacje. Jednakże interfejsy mogą nie być takie same – operacje mogą np. być różnie
154
Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz
nazwane, posiadać odmienny schemat komunikacyjny i inną strukturę wiadomości. Oczywistym
jest fakt, że różni dostawcy nie implementują w swoich urządzeniach tego samego interfejsu usługi sieciowej.
Proste rozwiązania szerzej użyte w silnikach przepływu pracy, takie jak dynamiczne przydzielanie adresów punktów końcowych usługi sieciowej, są wciąż zbyt ograniczone by rozwiązać
przedstawiony powyżej problem ponieważ w takich przypadkach system ma możliwość komunikacji wyłącznie z określonymi wcześniej interfejsami usług. W dalszej części tego artykułu omówiona zostanie możliwość użycia języka BPEL łącznie z komponentem Enterprise Service Bus
(ESB), brokerem SOAP, w celu integracji nowych usług z ich specyficznymi interfejsami w systemie dynamicznym. Moduł invokeATP aplikacji VISP zostanie przedstawiony jako przykład
takiego rozwiązania.
Projekt i platforma VISP
VISP (z ang. Virtual Internet Service Provider, czyli Wirtualny Dostawca Usług Internetu) to
projekt typu STREP (z ang. Specific Targeted Research Project) realizowany w ramach
6 Programu Ramowego (FP6 IST). Projekt wpisuje się w dział „eBiznes” w ramach programu
badawczo-rozwojowego „Integracja i wzmocnienie obszaru badań europejskich”.
Głównym celem VISP jest zbudowanie platformy oprogramowania dla klastra zrzeszającego
Małe i Średnie Przedsiębiorstwa, który działałby jako samodzielna jednostka biznesowa w różnych dynamicznych modelach biznesowych, tak aby ułatwiać dostarczanie rozwiązań z zakresu
działalności ISP (z ang. Internet Service Provider) zaadoptowanego do lokalnych potrzeb biznesowych.
Podczas realizacji projektu VISP usługi świadczone najczęściej przez ISP rozkładane były na
tzw. bloki składowe, czyli samodzielne usługi wielokrotnego użytku. Bloki te w trakcie pracy
klastra mogłyby być łączone w pakiety rozwiązań dostosowane dla potrzeb klientów. W projekcie
VISP [VISP_D4.4] zostało zidentyfikowanych i opisanych niemal 100 bloków składowych.
Kolejnym celem projektu było zautomatyzowanie procesu dostarczania usług. Zauważono,
że wszystkie działania jakie podejmuje ISP w ramach oferowanych usług mogą być automatycznie
wywoływane poprzez silniki przepływu pracy wykonujące procesy zwane w VISP „procesami
technicznymi”. Dostawca usługi wykonuje dany proces techniczny w celu wykonania operacji
w ramach określonej usługi np. aktywowania lub deaktywowania usługi dla klienta. Procesy techniczne są określone ze względu na usługę, wybraną technologię, użyte urządzenie techniczne
i wewnętrzne procedury ISP.
Dokonano analizy cyklu życia usługi, która wykazała, że (uogólniając) każdy z cykli składa się
z następujących stanów: instalacja, deinstalacja, aktywacja, deaktywacja, aktualizacja, zmiana
lokacji, import, zatrzymanie, wznowienie, resetowanie, naprawianie i testowanie. Naturalne jest
przypisanie każdemu ze stanów cyklu życiowego usługi procesu technicznego.
Procesy techniczne zostały podzielone na trzy grupy:
• procesy administracyjne (ATP, z ang. administrative technical processes) – procesy tech-
niczne, które obejmują jeden ze stanów cyklu życiowego usługi i mogą używać procesów
z grupy TTP oraz HTP,
• procesy narzędziowe (TTP, z ang. toolbox technical processes) – małe podprocesy wielo-
krotnego użytku wykonujące proste modyfikacje ustawień urządzeń sieciowych,
• procesy techniczne z udziałem człowieka (HTP, z ang. human technical processes) – pod-
procesy wymagające interakcji z człowiekiem.
Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku...
155
Platforma VISP komunikuje się bezpośrednio tylko z technicznymi procesami administracyjnymi (ATP).
Procesy techniczne są specyficzne dla danego operatora ISP i będą w przyszłości tworzone
wewnętrznie przez operatorów ISP. W projekcie VISP zostało zaprojektowanych tylko kilka procesów technicznych dla trzech wybranych usług.
Prawdziwym wyzwaniem okazało się zaprojektowanie architektury, która umożliwiłaby operatorowi ISP na tworzenie nowych procesów technicznych i dynamiczne integrowanie ich
z wykorzystywanym systemem. Zaprojektowano i stworzono komponent invokeATP, który odwołuje się do nowych technicznych procesów administracyjnych ATP, których interfejsy były nieznane podczas projektowania systemu.
Więcej informacji o projekcie i platformie VISP jest dostępnych na stronie projektu:
http://www.visp-project.org.
Integracja nowych usług za pośrednictwem brokera SOAP
Model współdziałania procesu komponentu wywołującego usługę, Brokera SOAP i usługi docelowej został zaprezentowany na poniższym diagramie. Dla uproszczenia przyjmuje się, że:
• wszystkie usługi docelowe posiadają taki sam asynchroniczny charakter,
• zagadnienie obsługi błędów zostało pominięte, gdyż może być w łatwy sposób dodane do
rozwiązania ogólnego,
• wybór odpowiednich usług docelowych jako specyficznych dla danego systemu i jego
architektury nie będzie tu omawiany.
156
Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz
Rys. 2. Ogólny schemat współdziałania komponentu wywołującego usługę, brokera SOAP i usługi docelowej
Broker SOAP udostępnia usługę proxy z wcześniej zdefiniowanym interfejsem. Wiadomość
z zapytaniem i odpowiedzią proxy zawiera przynajmniej jeden element xsd:anyType. Komponent
wywołujący usługę uzyskuje wszystkie informacje niezbędne do utworzenia zapytania o usługę
Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku...
157
docelową, potem generuje tę informację do elementu xsd:anyType wiadomości z zapytaniem
proxy. Następnie komponent wywołujący usługę wysyła zapytanie do brokera SOAP z wiadomością z zapytaniem o usługę docelową. Broker SOAP analizuje wiadomość i wysyła ją dalej do
usługi docelowej. Usługa docelowa realizuje odpowiednie działania i wysyła wiadomość z odpowiedzią do brokera SOAP, który umieszcza tą wiadomość we własnej wiadomości z odpowiedzią
i wysyła ją dalej do komponentu wywołującego usługę. Na końcu tego procesu komponent wywołujący usługę odczytuje potrzebne informacje z otrzymanej wiadomości.
Poniżej bardziej szczegółowo opisane zostały główne moduły omawianego rozwiązania:
• komponent wywołujący usługę,
• moduł pośredniczący ESB (broker SOAP),
• moduł usługi docelowej.
3.1. Komponent wywołujący usługę
Na Rysunku 2 przedstawione zostały główne działania, które mogą być realizowane przez
komponent wywołujący usługę. Szczegółowa specyfikacja tego modułu będzie się zmieniała
w zależności od np. specyfikacji systemu, dostępnej technologii oraz zaprojektowanej architektury. Minimum informacji, które powinny być przekazane do komponentu to usługa docelowa
i identyfikacja operacji. Taka identyfikacja jest wystarczająca jeśli system wykorzystuje UDDI lub
inny rodzaj rejestru. Jeśli rejestr nie jest wykorzystywany należy na wejściu dostarczyć więcej
informacji, takich jak:
• identyfikacja i nazwa usługi,
• identyfikacja i nazwa operacji,
• nazwa wiadomości z zapytaniem i odpowiedzią lub definicja ich struktury,
• definicja serwisu WSDL lub adres URL, w którym umieszczony jest WSDL.
Zadanie głównych działań wykonywanych przez komponent wywołujący usługę:
1. Uzyskanie definicji WSDL usługi docelowej – jeśli interfejs WSDL był jednoznacznie podany
wtedy krok ten może być pominięty. Jeśli system wykorzystuje repozytorium UDDI (ang.
Universal Description Discovery and Integration), definicja WSDL może być otrzymana z tego rejestru. Jednakże najprostszym rozwiązaniem jest pobranie jako parametru wejściowego
adresu URL lokalizacji definicji WSDL i pozyskanie go przy użyciu funkcji dokumentu
XSLT.
2. Analiza WSDL – komponent wywołujący usługę może analizować plik WSDL i pozyskiwać
z niego szczegóły dotyczące punktów końcowych i struktury wiadomości. Celem tego kroku
jest umożliwienie:
• generowania określonego zapytania o usługę końcową na podstawie struktury danych sys-
temu (pierwszy generator),
• generowania listy brakujących parametrów (drugi generator),
• uzyskiwanie informacji z określonej odpowiedzi usługi docelowej (ekstraktor).
Dwa generatory i jeden ekstraktor mogą być stworzone dla każdej z usług lub dwa ogólne
generatory i jeden ogólny ekstraktor analizujące WSDL mogą być stworzone dla całego
systemu. Naturalną technologią dla takich generatorów i ekstraktorów jest XSLT.
3. Generowanie listy brakujących parametrów – nie wszystkie parametry potrzebne do wywołania procesu mogą być znane przez moduł wywołujący usługę. Aby pozyskać te brakujące parametry, w tym kroku komponent wywołujący usługę porównuje wszystkie dostępne informa-
158
Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz
cje wymagane przez usługę docelową. Można wykorzystać określony generator usługi lub generator uniwersalny, który wykorzystuje strukturę danych zdefiniowaną w WSDL.
4. Uzyskiwanie zaginionych informacji – jeśli jakieś wymagane informacje nie zostały do tej
pory pozyskane przez system, wtedy muszą zostać dostarczone przez operatorów systemu.
W takim przypadku można wykorzystać technologię BPEL4People.
5. Generowanie wiadomości z zapytaniem dla usługi docelowej – jeśli dostępne są wszystkie
informacje wtedy może zostać wygenerowana wiadomość, a następnie spakowana do postaci
wcześniej zdefiniowanej wiadomości z zapytaniem do Brokera SOAP.
6. Wysłanie spakowanej wiadomości z zapytaniem do Brokera SOAP. Przykładowa wiadomość
z zapytaniem została przedstawiona na Rysunku 5. Pogrubioną czcionką wyróżniono spakowaną wiadomość z zapytaniem o usługę docelową oraz adres zawarty w nagłówku SOAP.
7. Otrzymanie odpowiedzi od brokera SOAP ze umieszczoną w niej odpowiedzią usługi docelowej.
8. Usunięcie informacji z wiadomości z odpowiedzią – jeśli wiadomość z odpowiedzią niesie
pewne informacje wtedy musi zostać przepisana do postaci standardowej struktury danych
o parametrach usług stosowanej w systemie. Podobnie jak w przypadku generatorów – mogą
zostać użyte specyficzne bądź uniwersalne ekstraktory.
9. Zachowywanie informacji do przyszłego wykorzystania – jeśli jakieś informacje będą mają
być użyte w przyszłości zachowywane są w systemie bazy danych.
3.2. Broker SOAP
Główną rolą brokera SOAP jest mediacja pomiędzy komponentem wywołujący usługę i usługą
docelową. Proxy posiada zdefiniowany wcześniej interfejs i wiadomości otrzymane od komponentu wywołującego usługę posiadającą zdefiniowaną wcześniej strukturę. Każda z wiadomości zawiera element, w którym komponent wywołujący usługę umieszcza określoną wiadomość
w formacie akceptowanym przez usługę docelową. Główne czynności są realizowane przez Brokera SOAP są następujące:
1. Wysłanie wiadomości do usługi docelowej – wiadomość z odpowiedzią jest wysyłana do usługi
docelowej. Punkt końcowy usługi docelowej może być przekazany od komponentu wywołującego usługę do proxy realizowanego przez brokera SOAP lub w nagłówku wiadomości SOAP
przy użyciu np. standardu adresowania zgodnego z WS-Addressing [WSAD]. Na Rysunku 5
przedstawiony został przykład wiadomości z zapytaniem.
2. Otrzymanie odpowiedzi od usługi docelowej – broker SOAP otrzymuje odpowiedź od usługi
docelowej.
3. Umieszczenie wiadomości otrzymanej od usługi w odpowiedzi – wiadomość z odpowiedzią
jest konwertowana do wiadomości o zdefiniowanej wcześniej strukturze.
4. Wysłanie spakowanej odpowiedzi do komponentu wywołującego usługę – spakowana wiadomość jest wysyłana do komponentu wywołującego usługę.
3.3. Moduł usługi docelowej
Zakłada się, że usługa docelowa jest niezależna od reszty systemu. Usługa posiada swój własny
interfejs, a zatem w celu integracji usługi z systemem nie powinna zachodzić konieczność jakichkolwiek modyfikacji. Jednakże jeśli istnieje możliwość przyjęcia pewnych założeń podczas konstrukcji interfejsów usług docelowych (np. wykorzystują styl document/literal wrapped oczekiwanych wiadomości ub choćby używają na wejściu wyłącznie parametrów prostego typu) wtedy
o wiele łatwiejsze jest stworzenie uniwersalnych generatorów i ekstraktorów (czyli takich, które
Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku...
159
mogłyby być stosowane dla wszystkich lub znacznej większości usług) dla komponentu wywołującego usługę.
Przykład zastosowania – komponent invokeATP platformy VISP
Platforma VISP to przykład systemu, który wykorzystuje rozwiązanie opisane powyżej. Jednym z wymagań jest umożliwienie operatorowi ISP prostej integracji nowych usług i nowych procesów technicznych dla tych usług. Ponieważ wiele z procesów technicznych może być ponownie
wykorzystanych w różnych systemach lub może być importowanych z innych systemów okazało
się, że każdy z procesów technicznych powinien posiadać swój własny określony interfejs. W platformie VISP procesy techniczne są wywoływane z innych procesów – zaimplementowanych w języku BPEL procesów biznesowych, które to w momencie tworzenia wymagają ścisłego określenia
interfejsów dla każdej z usług, z którymi się komunikują. Takie wymaganie było przyczyną zbudowania opisanego powyżej rozwiązania.
Analiza przedstawiona w [VISP_D6.1.1] sugeruje przyjęcie pewnych założeń w strukturze
wiadomości w celu dopasowania ich charakteru do standardu procesów technicznych ISP oraz
ułatwia techniczną implementację . Przyjęto następujące założenia dla struktury wiadomości:
1. Proces ATP może wykorzystywać pięć rodzajów wiadomości:
• Wiadomość z zapytaniem: AtpProcessName_Request,
• Odpowiedź synchroniczna: AtpProcessName_SyncResponse,
• Synchroniczna wiadomość o błędzie: AtpProcessName_SyncFault,
• Odpowiedź asynchroniczna: AtpProcessName_Response,
• Asynchroniczna wiadomość o błędzie: AtpProcessName_Fault.
2. Proces ATP może używać dwóch typów portów:
• standardowy portType dla wywoływania procesu ATP,
• portType wywołania zwrotnego do wysyłania asynchronicznej odpowiedzi lub błędów.
3. Odpowiedź synchroniczna (lub synchroniczny błąd) jest wysyłana na samym początku do
InvokeAtp jako zawiadomienie o odpowiednim starcie ATP (lub powiadomienie, że ATP nie
rozpoczął właściwie).
4. Można również wykonać pewne krótkotrwałe działania pomiędzy momentem otrzymania
wiadomości z zapytaniem a momentem, gdy zostanie wysłana odpowiedź synchroniczna (lub
synchroniczny błąd). Dla przykładu:
• proces ATP może zweryfikować zgodność formatu wiadomości z definicją XSD,
• proces ATP może wykonywać bardziej zaawansowane rodzaje kontroli parametrów (jak
np. kontrola syntaktyczna, porównania wartości itp.),
• proces ATP może dokonać testu połączeń z bazą danych lub z innymi systemami i zwrócić
błąd, jeśli połączenie nie jest możliwe.
5. Proces ATP może pobrać na wejściu dowolny parametr. Parametr ten musi być przypisany do
jednej z poniższych grup:
• Parametry Techniczne Usługi (ServiceTechnicalCharacteristics) – parametry techniczne
usługi zdefiniowane w deliverable [VISP_D4.2]. Wartości parametrów zostały zdefiniowane przez modelowanie usługi w SKB.
160
Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz
• Identyfikator Instancji Usługi (ServiceTechnicalReference) – podzbiór parametrów, który
w sposób jednoznaczny identyfikuje instancję usługi, np.. SubscriberSipUserinfo i SubscriberSipDomain dla usług Simple Call Service.
• Informacje operacyjne (AdministrativeOperationalInformation) – informacje dodatkowe
niezbędne do realizowania procesu technicznego. Część z tych informacji musi być dostarczona przez użytkownika inicjującego operację administracyjną (np. Opis Problemu – ProblemDescription – do naprawy usługi).
• Parametry Konfiguracyjne Usługi (ServiceConfigurationCharacteristics) – parametry kon-
figuracyjne usługi zdefiniowane zostały w dokumencie D4.2 projektu VISP [VISP_D4.2].
Parametry te mogą być rozmaite i zależą np. od określonej technologii implementacji usługi.
6. W odpowiedzi asynchronicznej proces ATP powinien odesłać informację należącą do jednej
z następujących zdefiniowanych grup:
• Identyfikator Instancji Usługi (ServiceTechnicalReference) – jeśli informacje takie zostały
stworzone podczas procesu technicznego.
• Parametry Konfiguracyjne Usługi (ServiceConfigurationCharacteristics) – jeśli jakieś cechy
uległy zmianie podczas procesu technicznego.
• Identyfikator Grupy ATP (AtpFamilyIdentifier) – identyfikator grupy procesów ATP od-
powiedniej dla danej usługi.
7. Zdefiniowane wcześniej grupy wiadomości wejściowych i wyjściowych, przedstawione
w punkcie 5 i 6, są jedynymi grupami, które może zinterpretować proces InvokeATP. Procesy
ATP mogą wykorzystywać parametry należące do tych grup lub ich nie używać. Innymi słowy
jeśli dany proces ATP wymaga parametrów z danej grupy, wtedy grupa ta musi być zdefiniowana w interfejsie procesu ATP i musi być włączona do zapytania i/lub do wiadomości z odpowiedzią.
8. Założenia przyjęte przy konstrukcji interfejsów WSDL [VISP_D6.1.1] są następujące:
9. Element “wsdl:definition” musi mieć atrybut “name” umieszczony w “AtpProcessName”.
10. Nazwa typu złożonego, który opisuje strukturę wiadomości z odpowiedzią ATP (zapytanie
początkowe), musi być umieszczona w “AtpProcessName”.
11. Nazwa elementu, który został wykorzystany jako część WSDL w wiadomości z zapytaniem
do ATP (zapytanie początkowe), powinna być umieszczona w „AtpProcessName”.
12. Nazwa operacji wywołania procesu ATP musi być umieszczona w „AtpProcessName”.
13. Nazwa elementu używanego jako część WSDL w wiadomości asynchronicznej odpowiedzi
ATP musi być umieszczona w “AtpProcessName_Response”.
14. Parametry zawarte w pięciu zdefiniowanych wcześniej grupach parametrów WSDL mogą
stanowić wyłącznie proste typy lub listę prostych typów.
15. Każdy WSDL musi posiadać jasno zdefiniowane pięć grup. Grupy te nie mogą być zdefiniowane w zewnętrznym schemacie i importowane do WSDL.
16. Wiadomości, elementy, które zostały odnotowane w wiadomościach, typy opisujące wiadomości i grupy muszą być umieszczone w tej samej przestrzeni nazw (ang. namespace) takiej
samej, jak przestrzeń nazw procesu ATP.
Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku...
161
W projekcie VISP jako Broker SOAP został wybrany Apache Synapse [Synapse]1. Silnik Synapse przechowuje konfigurację za pomocą plików XML, posiada również bogaty zestaw gotowych do użycia pośredników.
Diagram BPMN komponentu invokeATP przedstawiony jest na rysunku 3. Główne kroki zostały opisane poniżej.
Odpowiedni proces ATP jest wybierany najpierw przez zewnętrzny podproces wyboru ATP.
Podproces ten na wejściu pobiera informacje opisujące zadania procesu ATP i odsyła informację
z odpowiednio zidentyfikowanym ATP.
Rys. 3. Diagram procesu InvokeATP
Następnie definicja WSDL i informacja o lokalizacji procesu ATP uzyskiwane są za pomocą
podprocesu „wyszukaj szczegóły ATP” (retrieveAtpDetails). Podproces pobiera na wejściu informację zawierającą identyfikację procesu ATP, komunikuje się z wewnętrzną bazą danych VISP
w celu uzyskania adresu URI pod którym dostępny jest WSDL procesu ATP. Następnie retrieveAtpDetails odczytuje zdalny dokument WSDL i pobiera z niego informacje o punkcie końcowym.
Podproces odsyła zarówno dokument WSDL i punkt końcowy procesu.
Następnym krokiem jest wygenerowanie listy parametrów ATP, których wartości nie figurują
w bazie danych VISP i uzyskanie od użytkowników systemu wartości takich parametrów. Lista
jest generowana za pomocą transformacji XSLT, która analizuję WSDL procesu ATP i dane dostępne w bazie danych VISP. Proces invokeATP komunikuje się z użytkownikiem dzięki modułowi zwanemu listą roboczą (Worklist), zbudowanemu specjalnie w tym celu w projekcie VISP.
Nie wykorzystano gotowych rozwiązań z powodu braku otwartych systemów zarządzania zadaniami w chwili projektowania i wstępnej implementacji systemu. Obecnie pojawiło się kilka darmowych narzędzi kompatybilnych ze standardem BPEL4People, które z powodzeniem mogą być
stosowane w sytuacji podobnej do opisanej powyżej.
Gdy wszystkie niezbędne informacje są już dostępne, wiadomość z zapytaniem procesu ATP
jest generowana z wykorzystaniem drugiej transformacji XSLT.
1
Prosty i efektywny Broker zbudowany jako projekt open source przez Fundację Apache Software.
162
Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz
Następnie wiadomość z zapytaniem ATP pakowana jest do struktury wysyłanej do brokera
SOAP. Struktura tej wiadomości przedstawiona jest na Rysunku 4.
<xsd:complexType name="CallATP">
<xsd:sequence>
<xsd:element name="ATPRequest" type="xsd:anyType"/>
<xsd:element name="OperationName" type="xsd:string"/>
<xsd:element name="Namespace" type="xsd:anyURI"/>
<xsd:element name="CorrelationInformation" type="comxsd:ProcessId"/>
</xsd:sequence>
</xsd:complexType>
Rys. 4. Struktura wiadomości wysyłanej do brokera SOAP
Na Rysunku 5 przedstawiony jest przykład takiej wiadomości wraz z nagłówkami SOAP.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsa:To
xmlns:wsa="http://www.w3.org/2005/08/addressing"
soapenv:actor="" soapenv:mustUnderstand="0">
http://localhost:8080/active-bpel/services/activateSimpleCallService
</wsa:To>
<wsa:Action
xmlns:wsa="http://www.w3.org/2005/08/addressing"
soapenv:actor="" soapenv:mustUnderstand="0">
urn:vispproject.org/052007/processes/atp/atp3/wsdl/activateSimpleCallService
</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<broker:callATP
xmlns:broker="urn:vispproject.org/052007/enterpriseServices/atpBroker/wsdl">
<broker:ATPRequest>
<atp3:ActivateSimpleCallService
xmlns:atp3="urn:vispproject.org/052007/processes/atp/atp-3/wsdl">
<atp3:ServiceTechnicalReference>
<atp3:SubscriberSipUserinfo>35559</atp3:SubscriberSipUserinfo>
<atp3:SubscriberSipDomain>domain.net</atp3:SubscriberSipDomain>
</atp3:ServiceTechnicalReference>
<atp3:CorrelationInformation>4</atp3:CorrelationInformation>
</atp3:ActivateSimpleCallService>
</broker:ATPRequest>
<broker:CorrelationInformation>4</broker:CorrelationInformation>
</broker:callATP>
</soapenv:Body>
</soapenv:Envelope>
Rys. 5. Wiadomość z zapytaniem wysyłana od modułu wywołującego proces do brokera SOAP
Broker SOAP rozpakowuje wiadomość z zapytaniem ATP i wysyła ją do punktu końcowego
podanego w nagłówku SOAP otrzymanej wiadomości. Na Rysunku 6 przedstawiono przykład
tego typu wiadomości z zapytaniem.
Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku...
163
Z drugiej strony broker SOAP otrzymuje odpowiedź ATP, pakuje ją do podobnej struktury
i wysyła do procesu invokeATP na adres podany jako parametr konfiguracyjny brokera SOAP.
Gdy proces invokeATP wysyła wiadomość do brokera SOAP, również rozpoczyna oczekiwanie na podobną asynchroniczną odpowiedź. Jeśli proces ATP wykryje błąd, wtedy kod błędu jest
sprawdzany wewnątrz invokeATP. Kody błędu: VER0110 i VER0111 oznaczają, że niektóre parametry posiadają błedne wartości, muszą więc być pozyskane od użytkownika – w takim przypadku nowe zapytanie jest wysyłane do procesu ATP za pośrednictwem Synapse.
Ostatnim krokiem jest pozyskiwanie informacji z wiadomości z odpowiedzią ATP przy użyciu
innej transformacji XSLT i zachowanie w bazie danych do wykorzystania przez kolejne procesy
ATP.
Przedstawione podejście stanowi podstawę dla przyszłych prac. Zdecydowana większość założeń dla usług wywoływanych przez invokeATP, jeśli nie wszystkie z nich, może być w przyszłości usunięta dzięki dodaniu większej możliwości konfigurowania procesu invokeATP.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<atp3:ActivateSimpleCallService
xmlns="urn:vispproject.org/052007/processes/atp/atp-3/wsdl"
xmlns:atp3="urn:vispproject.org/052007/processes/atp/atp3/wsdl">
<atp3:ServiceTechnicalReference>
<atp3:SubscriberSipUserinfo>35559</atp3:SubscriberSipUserinfo>
<atp3:SubscriberSipDomain>domain.net</atp3:SubscriberSipDomain>
</atp3:ServiceTechnicalReference>
<atp3:CorrelationInformation>4</atp3:CorrelationInformation>
</atp3:ActivateSimpleCallService>
</soapenv:Body>
Rys. 6. Przykład wiadomości z zapytaniem wysyłanej od brokera SOAP do usługi docelowej
Podsumowanie
W niniejszym artykule przedstawiono ideę budowy funkcjonującego w bardzo dynamicznym
otoczeniu systemu informatycznego, którego podstawą są: broker SOAP, system zarządzania
przepływem pracy oraz usługi sieciowe. Autorzy przedstawili sposób, w jaki tego typu system
może zostać zaimplementowany bazując na przykładzie systemu budowanego w ramach projektu
IST VISP. Przedstawione rozwiązanie dowodzi, że możliwa jest dynamiczna integracja zewnętrznych usług z systemem informatycznym. Standardy takie jak BPEL lub XSLT oraz komponenty
oprogramowania open source takie jak Synapse lub ActiveBPEL sprawiają, że platforma VISP
może pracować w środowiskach produkcyjnych, może być również w prosty sposób zarządzana i
rozwijana w przyszłości.
Proponowane podejście należy poddać dalszej analizie w celu przyszłej standaryzacji.
164
Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz
Bibliografia
[BPEL2.0]
“OASIS Web Services Business Process Execution Language Version 2.0”; Comitee Specification; Alexandre Alves, Assaf Arkin, Sid Askary, Ben Bloch, Francisco Curbera, Mark
Ford, Yaron Goland, Alejandro Guízar, Neelakantan Kartha, Canyang Kevin Liu, Rania
Khalaf, Dieter König, Mike Marin, Vinkesh Mehta, Satish Thatte, Danny van der Rijn, Prasad Yendluri and Alex Yiu; January 2007; http://docs.oasis-open.org/wsbpel/2.0/wsbpelv2.0.pdf
[Synapse]
Strona projektu; http://synapse.apache.org
[WSDL]
“Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language”; W3C
Recommendation; edit. Roberto Chinnici, Jean-Jacques Moreau, Arthur Ryman, Sanjiva
Weerawarana; June 2007; http://www.w3.org/TR/wsdl20/
[XSLT]
“XSL Transformations (XSLT) Version 1.0“; W3C Recommendation; edit. James Clark;
November 1999; http://www.w3.org/TR/xslt
[VISP_D3.0]
“D3.0 – VISP functional specification”; edit. Eric Mannie-Corbisier; VISP Project FP6-IST2004-027178; February 2007; http://www.visp-project.org
[VISP_D4.2]
“D4.2 – Service Decomposition and Characterization Methodology”; edit. Daniel Pop; VISP
Project FP6-IST-2004-027178; December 2006; http://www.visp-project.org
[VISP_D4.4]
“D4.4 – Building blocks specification”; edit. Eric Mannie-Corbisier; VISP Project FP6-IST2004-027178; June 2007; http://www.visp-project.org
[VISP_D6.1.1]
“D6.1 – VISP technical process textual specification, Part 1 - D6.1.1- Introduction”; edit.
Arek Bekiersz; VISP Project FP6-IST-2004-027178; http://www.visp-project.org
“Web Services Addressing 1.0 – Core”, edit. Martin Gudgin, Marc Hadley, Tony Rogers,
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509
[WSAD]