Przysz³oœæ i ograniczenia us³ug sieciowych

Transkrypt

1 IX Konferencja PLOUG Koœcielisko PaŸdziernik 2003 Przysz³oœæ i ograniczenia us³ug sieciowych prof. Czes³aw Jêdrzejek Instytut Technik Telekomunikacyjnych i Informatycznych Us³ugi sieciowe s¹ jednym z najpopularniejszych obecnie trendów w informatyce. Ich niezaprzeczalnymi zaletami s¹: l Standaryzacja: dostêpu, profili, procesów biznesowych. l Dostosowanie do modelu zorientowanego na us³ugi ( Centric Model) przez co zwiêkszaj¹ siê mo liwoœci integracji i spada jej koszt. Spoœród kilkudziesiêciu standardów zwi¹zanych z us³ugami sieciowymi najwa niejsze to SOAP, WSDL, UDDI oraz WS-Security. UDDI i WS-Security oparte s¹ na pewnych za³o eniach biznesowych, które niekoniecznie musz¹ siê globalnie spe³niæ, bowiem zak³adaj¹ odejœcie od rynku pionowo zintegrowanego. Inne trudnoœci techniczne to skalowalnoœæ i pokonanie technicznych barier œrodowiska: wiele platform, sieci, podmiotów. Dlatego us³ugi sieciowe w skali masowej zaczn¹ siê liczyæ po roku W referacie skupiê siê na rzeczywistym stanie wdro eñ us³ug sieciowych i ilustracji zastosowañ us³ug sieciowych z wykorzystaniem jednej z ich najwa niejszych funkcjonalnoœci: negocjacji i mediacji (funkcja brokera). Zostanie przedstawiona aplikacyjno-sieciowa architektura projektu IST CADENUS w aspekcie skalowalnoœci. Niektóre aplikacje wymagaj¹ce przes³ania kilkudziesiêciu wiadomoœci bardzo trudno skaluj¹ siê na poziomie dynamicznych sesji przy zastosowaniu urz¹dzeñ i systemów obecnie wystêpuj¹cych na rynku. Informacja o autorze: Prof. dr hab. in. Czes³aw Jêdrzejek, w pocz¹tkowym okresie pracy zwi¹zany z AGH i UJ w Krakowie. Przez okres 10 lat odbywa³ sta e naukowe i pracowa³ jako Visiting Professor kolejno na kilku uczelniach w USA. W roku 1994 zwi¹za³ siê Francusko-Polsk¹ Wy sz¹ Szko³¹ Nowych Technik Informatyczno-Komunikacyjnych (EFP) w Poznaniu. Od paÿdziernika 1996 jest profesorem na Wydziale Telekomunikacji i Elektrotechniki Akademii Techniczno-Rolniczej w Bydgoszczy. Pracuje tak e w Instytucie Technik Telekomunikacyjnych i Informatycznych (ITTI) w Poznaniu, gdzie od 1999 roku zajmuje stanowisko Wiceprezesa Zarz¹du. Jest autorem lub wspó³autorem ponad 100 publikacji. Rozwin¹³ grupê software ow¹ w ITTI (systemy informatyczne typu ERP i CRM dla przedsiêbiorstw, systemy zdalnego nauczania wraz z materia³ami). Kierowa³ kilkudziesiêcioma projektami dla wiod¹cych operatorów oraz dostawców sprzêtu telekomunikacyjnego w Polsce w zakresie ewolucji sieci i us³ug, in ynierii ruchu w sieciach teleinformatycznych oraz wykonania, integracji i wdro enia systemów informatycznych. Realizowa³ kilka projektów europejskich dotycz¹cych aplikacji informatycznych.

2 Przyszłość i ograniczenia usług sieciowych Wstęp Wytwarzanie aplikacji internetowych i sieciowych systemów informatycznych wymaga integracji produktów informatycznych na trzech poziomach: komponentów, warstwy pośredniej (ang.middleware), aplikacji. Wzraz ze wzrostem funkcjonalnosci i złożoności sieciowych systemów informatycznych wzrasta koszt integracji. Na kongresie TMF w Nicei w roku 2002 podano, że w przypadku oprogramowania systemów telekomunikacyjnych koszt integracji wynosi 80% inwestycji. W dodatku cykle życia usług stają się porównywalne z czasem wdrożenia (głównie integracji). Ten fakt między innymi był i pozostaje powodem załamania w branży ICT 1. Dlatego poszukiwane są nowe paradygmaty projektowanie i wytwarzanie systemów internetowych. Obecnie głównym trendem w tworzeniu i użytkowaniu komercyjnych aplikacji są usługi sieciowe 2 (ang Web services 3 ). Usługi sieciowe (WS) są aplikacjami identyfikowanymi poprzez URI (Uniform Resource Identifier), których interfejsy i wiązania są zdefiniowane i rozpoznawane przy pomocy artefaktów XML. Sprowadza się to do wysyłania i odbierania komunikatów używając zestandaryzowanych przez World Wide Web Consortium (W3C) formatów i mechanizmów. Usługi sieciowe umożliwają bezpośrednie oddziaływanie komponentów, a komunikaty oparte są na protokołach internetowych. Z perspektywy czasu przesłankami ogromnego zainteresowania i reklamy usług sieciowych były: 1. nadzieja na uniwersalną i globalną wzajemną komunikację, mimo istniejącej wcześniej niekompatybilności oprogramowania,. Istnieje wiele złożonych zagadnień biznesowych i technicznych, które zadecydują, która z tych opcji zostanie zrealizowana. Realizacja pozytywnego pierwszego scenariusza wymaga pokonania wielu barier. W artykule tym zajmę się analizą tych barier, bez zbytniego wchodzenia w szczegóły techniczne protokołów. 2. Architektura usług sieciowych Usługi sieciowe to samodzielne aplikacje oparte na komponentach, które mogą być opisane, opublikowane, zlokalizowane i wywołane w sieci internetowej (praktycznie szerokopasmowej) jak pokazano na rys Information and Communication Technology 2 rzadziej: serwisy sieciowe 3 A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols. (W3C)

3 180 Czesław Jędrzejek Interakcje: SOAP Dane: XML Komunikacja: HTTP Dostawca usług publikacja UDDI wywołanie, powiąanie SOAP Broker usług UDDI/WSDL wyszukanie Użytkownik Rys. 1. Cykl życia usługi sieciowej z architekturą protokołów Uruchomienie usługi sieciowej obejmuje utworzenie usługi oraz zdefiniowanie interfejsów i metod jej wywołania, a jej działanie wymaga co najmniej: opublikowanie usługi w internetowym lub intranetowych katalogach (ang. Serwis directory) należących do brokera usług, stworzenie możliwości odnalezienia jej przez potencjalnych odbiorców klientów (ang. User), zdalne wywołanie serwera dostawcy przez klienta. Nie będę się zajmował szczegółami protokołów ani działania wartwy pośredniej (ang. middleware) [1]. Wymiana komunikatów została przedstawiona na Rys. 2

4 Przyszłość i ograniczenia usług sieciowych 181 Klient usługi sieciowej Znajdź usługę Link do dokumentu katalogu usług Broker (discovery) HTML z linkiem do WSDL Jak się porozumiewamy (WSDL) Specyfikacja usługi (XML) SOAP Zamawiam Potwierdzam zamówienie (XML) UDDI Usługa sieciowa Rys. 2. Wymiana komunikatów w najprostszej wersji komunikacji w ramach usługi sieciowej Aby zapewnić współdziałanie, usługi sieciowe wykorzystują uzgodnione standardy struktury danych (XML), przesyłania komunikatów (SOAP), wyszukiwania usług (UDDI) i opisy interfejsów (WSDL) 4. Komunikaty SOAP w postaci tekstowej są przesyłane za pomocą standardowego protokołu internetowego HTTP. Załączniki są binarne lub w postaci wywołań RPC. Dzięki temu można przejąć większość rozwiązań internetowych. Teoretycznie, aby zapewnić działanie usług sieciowych nie trzeba zmieniać środowiska (Tabela 1) np. narzędzi bezpieczeństwa w postaci ścian ogniowych, ale w praktyce bardzo rozbudowana funkcjonalność spowodowała koniecznośc uzupełnienia podstawowych protokołów o kilkadziesiąt nowych specyfikacji. Usługa sieciowa po odebraniu żądania wykonania interpretuje je i wywołuje odpowiednią, zaimplementowaną metodę po stronie aplikacji biznesowej (w teoretycznie dowolnym języku oprogramowania, o ile istnieje odpowiedni interfejs jak to pokazano w Tabeli 1). W praktyce, jeśli chcemy wzbogacić usługi sieciowe o dodatkowe funkcjonalności nie jest to już tak proste. Np. Microsoft używa usług sieciowych do osiągnięcia przewagi konkurencyjnej platformy.net. Tabela 1. Technologie związane z usługami sieciowymi Funkcjonalność implementacja usługi użycie usługi opis usługi na poziomie interfejsów Technologia teoretycznie dowolna teoretycznie dowolna WSDL 4 XML (Extensible Markup Language) SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web s Description Language), odpowiednik IDL w platformie Corba.

5 182 Czesław Jędrzejek Funkcjonalność wyszukiwanie usług przekazywanie komunikatów Technologia UDDI SOAP 3. Dodatkowe funkcjonalności Usługi sieciowe powstały z zapotrzebowania biznesowego w wyniku coraz szybszego tempa tworzenia usług i koniecznosci tworzenia złożonych łańcuchów wartości. W efekcie podstawowy model WS jest trakcie wzbogacania o kilkadziesiąt dodatkowych specyfikacji (Rys. 3) rozszerzajacych podstawowe funkcjonalności techniczne (tzn. protokoły SOAP, UDDI, WDSL), ale też specyfikujących interfejsy do inteligencji biznesowej i transakcji typu B2B i B2C 5. Stos protokołów ulega wzbogaceniu. Tworzeniem bardziej złożonych protokołów zajmuje się kilka organizacji często ze sobą konkurujących [2]. Zupełnie nowe są nastepujace złożone procesy: Choreografia (ang. Choreography) definicja sekwencji i zależności dla interakcji pomiędzy podmiotami o określonych rolach w realizacji łańcucha wartości (Collaborative Process). Orkiestracja (ang. Orchestration) - definicja sekwencji i zależności dla procesów realizujących jedną rolę, w szczególności realizacja wzajemnych powiązań Konwersacja (ang. Conversation ) - instancja choreografii lub orkiestracji Relacje zaufania (trust relationship) - ochrona danych i zachowanie poufności informacji elektronicznej dotyczącej podmiotów za pośrednictwem rozwiązań proceduralnych wspieranych przez technologie. Jedno z takich rozwiązań, Infrastruktura Klucza Publicznego, nie uzyskało akceptacji rynkowej. Rozproszenie (ang. federation) - rozproszenie procesów i komponentów, tak aby uniknąć systuacji, kiedy awaria pojedynczego elementu (point of a single failure) powoduje awarię systemu. Standardy WS-Security i W-Trust (Rys. 4) realizują model bezpieczeństwa oparty na przydzielaniu tokenów i modelu zaufania w myśl zasady: każdemu według jego potrzeb, od każdego według jego możliwości 6. 5 Aktualny stan prac dotyczacych standardów lub ich draftów znajduje się na index.php/standards 6 Jak wiadomo ten teoretyczny model pochodzący od Marksa nie znalazł pozytywnej implementacji w zakresie działania społeczeństw (co raczej nie zachęca do optymizmu)

6 Przyszłość i ograniczenia usług sieciowych 183 Policy Trust Routing Coordination Federation Inspection Message Encapsulation Other Web s WS-Security SOAP Web s SOAP Transport Layer (HTTP) (HTTP) Rys. 3. Stos protokołów realizujących rozbudowane funkcjonalności usług sieciowych Sender Receiver Trust Engine Trust Engine Security Token Rys. 4. Uproszczona zasada działania zaufanej transmisji w oparciu o Trust Engine i Secure Token Do tej pory rozpatrywano uproszczone relacje biznesowe. W rzeczywistości użytkownik, który chce skorzystać z usługi sieciowej musi wejść do sieci poprzez operatora dostępu (ISP), a usługa np. na portalu musi skorzystać z transportu dostarczanego przez operatora telekomunikacyjnego (Resource Mediator). Funkcje te zostały przedstawione na Rys W tym pzrypadku broker to Access Mediator i Directory. Dostawca to Mediator. Nowym elementami w porównaniu z Rys. 1 to negocjacja oferty i komunikacja specyfikacji SLA ( Level Agreement). Dlatego liczba wiadomości rośnie (także dlatego, że występuje 5 podmiotów).

7 184 Czesław Jędrzejek User 1 Wybór usługi Access Mediator 2 Zapytanie o listę SM oferujących usługę 3 Lista SM oferujących usługę Directory Resource QoS-capable Sieć z funkcjonalnością Networks QoS Rys. 5. Scenariusz Negocjacje usługi (kroki 1-3) User 7Szablon SLA Access Mediator 8Wypełniony 5 szablon SLA 5 4 Zapytanie o informacje szczegółowe o usłudze 4 Directory Informacje szczegółowe o usłudze Zapytanie o informacje szczegółowe o usłudze Informacje szczegółowe o usłudze 6 Budowa szablonu SLA Resource QoS-capable Sieć z funkcjonalnością Networks QoS Rys. 6. Scenariusz Negocjacje usługi (kroki 4-8)

8 Przyszłość i ograniczenia usług sieciowych 185 User Access Mediator Obliczenie funkcji kosztu 12 Sortowanie według kosztu Resource Zapytanie o koszt usługi Directory Informacja o koszcie usługi Zapytanie o koszt usługi Informacja o koszcie usługi QoS-capable Sieć z funkcjonalnością Networks QoS Rys. 7. Scenariusz Negocjacje usługi (kroki 9-12) User 14 Lista proponowanych SLA Access Mediator 16 Wiadomo[ rollback Directory 15Wybrane SLA 16 Wiadomo[ commit 13 Budowa SLA 17Zachowanie Nowe SLA Resource QoS-capable Sie z funkcjonalno[ Networks ci QoS Rys. 8. Scenariusz Negocjacje usługi (kroki 13-17) 4. Problemy we wdrożeniu usług sieciowych Problemy we wdrożeniu usług sieciowych mogą być natury biznesowej lub technicznej. Istnieje ogromna literatura na ten temat. W świecie zdominowanym przez małą liczbę podmiotów idea równych praw nie będzie realizowana. Publiczne katalogi UDDI prowadzą m.in. IBM, Microsoft i SAP. Każdy chciałby być brokerem (tak jak każdy operator ISP zmierza do przyciagnięcia klientów do swojego portalu). Najsilniejsze podmioty na rynku np. telekomunikacyjnym mogą starać się zrealizować cały łańcuch wartości (ale np. postawa British Telecom jest inna). Globalni dostawcy oprogramowania (głównie Microsoft i IBM) starają się zwiekszać pozycję na rynku poprzez korzystne dla siebie rozwiązania w WS-X (X rozszerzone funkcjonalności, a przykładem może być uniwersalny profil użytkownika, dostep do aplikacji z pojedynczym uwierzytelnieniem,

9 186 Czesław Jędrzejek etc.). Może dojść do, że w teorii otwarte usługi zostaną związane z jedną platformą. Załamuje się wtedy cały model opierający się na fakcie, że usługi sieciowe nie stanowiaąsamodzielnie implementacji usług. Powinny być warstwą, pozwalającą wywołać zdalną usługę bez znajomości szczegółów implementacyjnych. Eksponują tylko warstwę biznesową, udostępniając publiczne API dla współpracujących serwisów. W aspekcie technicznym dzielę problemy implementacji WS na trzy klasy zagadnień: skalowalnośc, integracja, oraz model przetwarzania transakcyjnego. Skalowalność Ponieważ komunikacja odbywa się w trybie tekstowym cena za otwartość jest szybkość przetwarzania jest mniejsza wydajność. Typowy wynik przedstawiono na Rys. 9. J2EE Throughput J2EE SQL Tx J2EE DTC1 J2EE DTC2 J2EE SOAP TPS Client threads Rys. 9. Porównanie wydajnosci przetwarzania platformy J2EE z SOAP i binarmymi protokołami [3] Pojawiają się też duże problemy ze skalowalnością na poziomie liczby wiadomości sygnalizacyjnych. Dla scenariusza przedstawionego na Rys. 10 (realizacja aplikacyjno-sieciowa architektury projektu IST CADENUS) mamy do czynienia z 22 wiadomościami. Takie aplikacje wymagające przesłania kilkudziesięciu wiadomości bardzo trudno skalują się na poziomie dynamicznych sesji przy zastosowaniu urządzeń i systemów obecnie występujących na rynku. Nie się obecnie zrealizować masowych usług VoIP z negocjacją na poziomie sesji [4].

10 Przyszłość i ograniczenia usług sieciowych 187 # Name Expected servicetime (msec) Involved tasks 1 NegotiateNewSla 50 User authentication 2 GetAvailables 50 Execution of a query in a DB 3 R GetAvailables 50 Preparation of the answer to the user 4 ShowList 5 Select 50 6 GetDetails 50 Execution of a query in a DB 7 R GetDetails 50 Preparation of the GUI to be sent to the user 8 SendGui 9 Request 50 Storing of the user s request and preparation of the associated request to the Directory 10 GetSMs 50 Execution of a query in a DB 11 R GetSMs Preparation of the request to the service directory RequestAvailability 13 R RequestAvailability 50 Preparation of the requests to the involved SMs 50 Preparation of the answer to the AM Preparation of the request to the SM for a quotation 14 RequestForQuotation 1500 SLA SLS translation 15 SlsQuotation 1000 SLS Splitting 16 NextHopSlsQuotation 1000 SLS Splitting 17 TimeSliceQuotation R TimeSliceQuotation R NextHopSlsQuotation R SlsQuotation R RequestForQuotation R Request Execution of a time-independent Admission Control for a single autonomous system Collection of the responses for each time slice and selection of the best offer Preparation of the overall offer related to the provisioning of the service specified inside the SLS Preparation of the overall offer related to the provisioning of the service requested by the user. Collection of the offers from the involved SMs and merging of such offers into the SLA to be subscribed by the user Rys. 10. Wiadomości aplikacyjno-sieciowej architektury projektu IST CADENUS z podanymi czasami wykonania

11 188 Czesław Jędrzejek Integracja Usługi sieciowe miały być panaceum na problemy z integracją. Niewątpliwie jest to krok w dobrym kierunku, pod warunkiem, że w średnim okresie czasu (np. 5 lat) WS jako technologia zdominuje platformy warstw pośrednich. Rzeczywiście WS usuwaja pewne wady np. platformy Corba (zbytnia sztywność komponentw, trudna obsługa zdarzeń). Jednak np. w systemach zarządzania w telekomunikacji, gdzie dominuje Corba i J2EE, nie należy się spodziewać dramatycznych zmian (np. eleminacji starszych platform) w tym okresie.oznacza to wg autora, że WS będą funkcjonawać jako wyspa w świecie innych platform. Tymczasem konkurujące organizacje standaryzacyjne nie mogą się czasami porozumieć, czego przykładem standard Liberty Alliance vs WS-Federation. W dodatku praktyka integracji jest taka, że do istniejących interfejsów IDL, czy klas Javy dorabia się definicje WSDL. Zbyt to przypomina wdrażanie IPv6. O fakcie, że problem jest widoczny świadczy powstanie w luym 2002 roku organizacji WS-I (Web s Interoperability - grupującej producentów oprogramowania i nastawionej na wspieranie niezależności WS od platform, systemów operacyjnych i języków programowania. Tzw. Basic Profile 1.0 został zatwierdzony w sierpniu 2003 r. Model przetwarzania transakcyjnego. Systemy wielodostępowe umożliwiają, jednoczesne przetwarzanie wielu transakcji (np. systemy rezerwacji miejsc, systemy bankowe, etc.). W systemach SZBD poprawność i kompletność realizacji operacji gwarantuje moduł zarządzania transakcjami opierający się na modelu ACID Cztery zasady ACID (związane z blokadą dostępu do pewnych elementów bazy danych podczas realizacji transakcji) to: 1. Niepodzielność (Atomicity): Wykonywana jest albo cała transakcja od początku do końca, 2. Spójność (Consistency), 3. Izolacja (Isolation), 4. Trwałość (Durability). Dla transakcji B2B zamodelowanych np. w ramach BPEL4WS (warstwa leżąca ponad WS- Transaction i WS-Coordination) nie da się utrzymać własności niepodzielności (oraz całego modelu ATM, Advanced Transaction Model). Zamiast milisekund transakcje trwają o wiele dłużej. Muszą one przejś przez urządzenia sieciowe (np. routery usługowe), których opóźnienie może wynosić nawet 10 ms. A oprócz tego jednoprocesorowe routery generalnie mogą np. wykonywac tylko kilka transakcji AAA na sekundę [5]. Jest to bardzo poważny problem, jeśli usługa ma posiadać gwarantowaną jakość [6]. Standard WS-Transaction [7] wprowadza oprócz pojęcia Atomic Transaction pojęcie procesu biznesowego (business activity). Ten drugi proces zajmuje się obsługą wyjątków. Ale w świecie awarii i nieuczciwych partnerów liczba wyjątków (błędnych procesów) może gwałtownie rosnąć. Ma to szczególne znaczenie dla zarządzania autoryzacją i proponuje się metody usprawniające ten proces, jak: single sign-on.

12 Przyszłość i ograniczenia usług sieciowych Podsumowanie Usługi sieciowe są jednymi z najpopularniejszych, ale i w obecnej chwili najbardziej przereklamowanych trendów w informatyce. Ich niezaprzeczalnymi zaletami są: 1. standaryzacja: dostępu, profili, procesów biznesowych, 2. dostosowanie do modelu zorientowanego na usługi ( Centric Model), przez co zwiększają się możliwości integracji i spada jej koszt. Niestety obecnie usługi sieciowe są wdrażane głównie w dużych globalnych firmach i ich sieci partnerów (wewnętrzne markety elektroniczne), a komunikacja generalnie ma charakter punktpunkt. Techniczne założenia kilkudziesięsiu standardów związanych z usługami sieciowymi oparte są na pewnych przesłankach biznesowych, które niekoniecznie muszą się globalnie spełnić, bowiem zakładają odejście od rynku pionowo zintegrowanego. Inne trudności techniczne to skalowalność i pokonanie technicznych barier środowiska: wiele platform, sieci, podmiotów. Dlatego usługi sieciowe w skali masowej zaczną się liczyć po roku Bibliografia [1] np. seria artykułów czasopisma Oracle'owego PLOUG, Sebastian Wyrwał Projektowanie i wytwarzanie aplikacji internetowych [2] World Wide Web Consorcium - ; Organization for the Advancement of Structured Information Standards, OASIS - Liberty Alliance - integracją zajmuje się OMG - [3] Paul Greenfield, prezentacja Web s (and.net) April 2003; podobne wyniki zostały uzyskane przez M. Litoiu, Migrating to Web s, Latency and Scalability, IEEE Workshop on Web Site Evolution (WSE 2002), Montreal, Canada, October 2002 [4] Raport końcowy projektu IST Cadenus, wrzesień 2003 [5] Testy Network World Global Test Alliance, Filters on routers: The price of performance, Network World, 07/14/03http:// [6] A. Flizikowski, C. Jędrzejek, A model of a software router, to be published [7] Dean Kuo, Alan Fekete, Paul Greenfield, Julian Jang and Doug Palmer, Just What Could Possibly Go Wrong In B2B Integration?. Workshop on Architectures for Complex Application Integration(WACAI'03 - to appear), November 2003, Dallas, USA.