Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku biznesowym w oparciu o technologie workflow, usługi sieciowe i ESB

Transkrypt

1 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: pisanka@epf.pl, raknapik@gmail.com, rrenk@amu.edu.pl, holub@amu.edu.pl 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 Alcatel- Lucent), 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.

2 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 był wykładowcą na Politechnice w Nowym Jorku, a w latach 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 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.

3 Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku 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

4 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 techniczne, 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 wielokrotnego użytku wykonujące proste modyfikacje ustawień urządzeń sieciowych, procesy techniczne z udziałem człowieka (HTP, z ang. human technical processes) podprocesy wymagające interakcji z człowiekiem.

5 Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku 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: 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.

6 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ę

7 Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku 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 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 systemu (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-

8 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 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ę 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

9 Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku 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.

10 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 konfiguracyjne 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 odpowiedniej 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.

11 Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku 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 retrieve- AtpDetails 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.

12 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=" <soapenv:header> <wsa:to xmlns:wsa=" soapenv:actor="" soapenv:mustunderstand="0"> </wsa:to> <wsa:action xmlns:wsa=" soapenv:actor="" soapenv:mustunderstand="0"> urn:vispproject.org/052007/processes/atp/atp- 3/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.

13 Tworzenie systemu informatycznego w dynamicznie zmieniającym się środowisku 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=" <soapenv:body> <atp3:activatesimplecallservice xmlns="urn:vispproject.org/052007/processes/atp/atp-3/wsdl" 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> </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.

14 164 Marcin Pisanko, Rafał Renk, Rafał Knapik, Witold Hołubowicz Bibliografia [BPEL2.0] [Synapse] [WSDL] [XSLT] [VISP_D3.0] [VISP_D4.2] [VISP_D4.4] [VISP_D6.1.1] [WSAD] 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; Strona projektu; 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; XSL Transformations (XSLT) Version 1.0 ; W3C Recommendation; edit. James Clark; November 1999; D3.0 VISP functional specification ; edit. Eric Mannie-Corbisier; VISP Project FP6-IST ; February 2007; D4.2 Service Decomposition and Characterization Methodology ; edit. Daniel Pop; VISP Project FP6-IST ; December 2006; D4.4 Building blocks specification ; edit. Eric Mannie-Corbisier; VISP Project FP6-IST ; June 2007; D6.1 VISP technical process textual specification, Part 1 - D Introduction ; edit. Arek Bekiersz; VISP Project FP6-IST ; Web Services Addressing 1.0 Core, edit. Martin Gudgin, Marc Hadley, Tony Rogers,