NOWE TECHNOLOGIE INFORMACYJNE DLA ELEKTRONICZNEJ GOSPODARKI I SPOŁECZEŃSTWA INFORMACYJNEGO OPARTE NA PARADYGMACIE SOA POIG 1.3.1

Transkrypt

1 NOWE TECHNOLOGIE INFORMACYJNE DLA ELEKTRONICZNEJ GOSPODARKI I SPOŁECZEŃSTWA INFORMACYJNEGO OPARTE NA PARADYGMACIE SOA POIG INNOWACYJNA GOSPODARKA Omówienie Projektu Krzysztof Zieliński Katedra Informatyki AGH

2 Plan prezentacji Wprowadzenie do SOA Struktura projektu Zadania badawcze Przykłady realizowanych zadań Zadania aplikacyjne Spodziewane rezultaty INNOWACYJNA GOSPODARKA

3 Partnerzy Projektu Katedra Informatyki Akademia Górniczo-Hutnicza Katera Informatyki Uniwersytet Ekonomiczny INNOWACYJNA GOSPODARKA Instytut Podstaw Informatyki PAN Instytut Informatyki Politechniki Poznańskiej Instytut Informatyki Politechniki Wrocławskiej

4 Znaczenie systemów SOA Service Oriented Architecture SOA nie jest technologią, lecz paradygmatem budowy systemów informatycznych przystosowanych do zmian i optymalizacji swoich usług, które są implementowane z uŝyciem aktualnie dostępnych róŝnorodnych technologii IT. INNOWACYJNA GOSPODARKA Podstawę tego paradygmatu stanowi luźna integracja komponentów o dobrze zdefiniowanej funkcjonalności bazujące na semantyce ich powiązanie w aplikacje biznesowe oraz zarządzana ewolucja.

5 Zorientowanie na usługi Zasady zorientowania na sługi: Dobrze zdefiniowany kontrakt usługi Luźne powiązanie na poziomie wykorzystania Abstrakcyjność funkcjonalności MoŜliwość ponownego uŝycia Autonomiczność Bezstanowość MoŜliwość wyszukania Zdolność do kompozycji INNOWACYJNA GOSPODARKA

6 SOA Nowej Generacji Next Generation SOA Budowa infrastruktury dla wykonania i zarządzania aplikacjami zbudowanymi zgodnie z paradygmatem SOA INNOWACYJNA GOSPODARKA Zwirtualizowane środowisko wykonawcze Modern ESB Monitorowanie i zarządzanie cyklem Ŝycia usług Nowoczesne narzędzia specyfikacji procesów biznesowych Wirtualizacja + SOA = Cloud Computing

7 Struktura projektu Jesteśmy tutaj INNOWACYJNA GOSPODARKA

8 Etap I ( ) Badania w zakresie opracowania metod i rozwoju narzędzi na potrzeby budowy systemów opartych na paradygmacie SOA Obszary Tematyczne: 1. Konstrukcja uniwersalnych skalowalnych technologii integracji/kompozycji usług (ESB). 2. Opracowanie infrastruktury SOA, w tym: technik zapewniania bezpieczeństwa, zwiększania niezawodności, personalizacji oraz dostarczenie wspólnych, dzielonych serwisów (np. replikacji, przetwarzania transakcyjnego itd.). 3. Opracowanie metod automatyzacji kompozycji aplikacji i procesów biznesowych (BPM, BPEL, Business Rules) oraz wzorców procesów. 4. Opracowanie reprezentacji środowiska wykonania usługi oraz języka opisu usług. 5. Konstrukcja metryk dla SOA, klasyfikacja usług, opracowanie metod zarządzania SOA, technik gwarancji jakości usług (ang. Quality of Servicei Service Level Agreement), monitorowania aplikacji SOA oraz technik migracji istniejących aplikacji do SOA. 6. Opracowanie technologii optymalizacji systemów SOA, sprzętowej implementacji serwisów SOA (HSOA) oraz metod integracji z sieciami sensorowymi. 7. Zaproponowanie metod i narzędzi tworzenia SOKU (ang. Service Oriented Knowledge Utility) dla potrzeb systemów SOA. INNOWACYJNA GOSPODARKA

9 Warstwy logiczne modelu S3 INNOWACYJNA GOSPODARKA Service-Oriented Solution Stack lub SOA Solution Stack

10 Stan aktualny projektu I Etap (zakończony): Badanie technologii opracowanie koncepcji i wykonanie projektów metod i narzędzi II Etap (w realizacji): Opracowanie eksperymentalnych metod i narzędzi INNOWACYJNA GOSPODARKA

11 AGH Sieć powiązań narzędzi OB1-1 Zwirtualizowane ESB BAM INNOWACYJNA GOSPODARKA OB1-3 Adaptowalne ESB OB1-2 Monitor ESB

12 AGH Sieć powiązań narzędzi OB1-1 Zwirtualizowane ESB BAM INNOWACYJNA GOSPODARKA OB1-3 Adaptowalne ESB OB1-2 Monitor ESB warstwa middleware SOA OB5-2 Moduł Interfejsów Sensorów HSOA OB5-1 Moduł HSOA OB5-3 Moduł Mobilnych Serwisów Infrastruktura sprzętowa

13 AGH Sieć powiązań narzędzi OB7-2 Monitor BPEL OB1-1 Zwirtualizowane ESB BAM INNOWACYJNA GOSPODARKA OB7-1 Moduł Obliczeń Metryk OB1-2 Monitor ESB OB1-3 Adaptowalne ESB warstwa middleware SOA OB5-2 Moduł Interfejsów Sensorów HSOA OB5-1 Moduł HSOA OB5-3 Moduł Mobilnych Serwisów OB7-3 Zwirtualizowane SOI Xen/Solaris Containers Infrastruktura sprzętowa

14 AGH Sieć powiązań narzędzi OB4-3 Moduł Wyszukiwania Serwisów OB7-1 Moduł Obliczeń Metryk OB4-4 Adaptowalne SCA OB1-2 Monitor ESB OB7-2 Monitor BPEL OB1-3 Adaptowalne ESB OB1-1 Zwirtualizowane ESB BAM warstwa middleware SOA INNOWACYJNA GOSPODARKA OB5-2 Moduł Interfejsów Sensorów HSOA OB5-1 Moduł HSOA OB5-3 Moduł Mobilnych Serwisów Spójna technologia i filozofia budowy OB7-3 Zwirtualizowane SOI Xen/Solaris Containers Infrastruktura sprzętowa

15 AGH Sieć powiązań narzędzi OB6-4 Zarządzanie Ontologiami OB4-3 Moduł Wyszukiwania Serwisów OB7-1 Moduł Obliczeń Metryk OB3-2 Budowa VO OB6-5 Zarządzanie VO Integracja przez repozytorium OB4-4 Adaptowalne SCA OB1-2 Monitor ESB OB7-2 Monitor BPEL OB1-3 Adaptowalne ESB OB1-1 Zwirtualizowane ESB BAM warstwa middleware SOA INNOWACYJNA GOSPODARKA OB5-2 Moduł Interfejsów Sensorów HSOA OB5-1 Moduł HSOA OB5-3 Moduł Mobilnych Serwisów OB7-3 Zwirtualizowane SOI Xen/Solaris Containers Infrastruktura sprzętowa

16 INNOWACYJNA GOSPODARKA Wbudowane SOA

17 [OB5-1] Badanie technologii sprzętowej realizacji systemowych elementów SOA Altium Designer Oprogramowanie do projektowania obwodów drukowanych opartych na układach programowalnych FPGA. INNOWACYJNA GOSPODARKA Altera Quartus II O programowaniem służącym do tworzenia, kompilacji i symulacji projektów FPGA napisanych w języku VHDL oraz do fizycznego programowania matryc FPGA i uruchamiania na nich gotowych skompilowanych projektów. Wykonanie wstępnych projektów.

18 Mobile Robots INNOWACYJNA GOSPODARKA HSOA = FPGA based services Wiz830MJ Altera DE2.

19 MII ARP Layer Hardwar e Embedded Protocols MAC Layer IP Layer TC P Lay er MII ARP Layer Hardware Embedded Protocols MA C Layer IP Layer MII ARP Layer Hardware Embedded Protocols WEB SERVICE Layer HTTP Layer TCP/ IP Parser TCP Layer MA C Layer IP Layer TTL I 2C 1-W ire TCP Layer W EB S ERVI CE Lay er HTTP Layer TCP/I P Pars er W EB S ERVI CE Lay er HTTP Layer TCP/I P Pars er TTL I 2C 1-W ire TTL I 2C 1-W ire MII ARP Layer Hardwar e Embedded Protocols MAC Layer IP Layer TC P Lay er WEB SERVICE Layer HTTP Layer TCP/ IP Parser TTL I 2C 1-W ire [OB5-2] Badanie metod sprzętowej realizacji usług i ich integracji z otoczeniem Sensory i kontrolowane urządzenia w otoczeniu INNOWACYJNA GOSPODARKA Ethernet PHY HSOA Board FPGA Control HSOA Ethernet PHY Board FPGA Wstępna koncepcja modułu HSOA HSOA Ethernet PHY Board FPGA Ethernet PHY HSOA Board FPGA Koncepcja topologii łączenia modułów HSOA

20 [OB5-3] Technologie mobilne w SOA Analiza możliwości uruchomienia serwisów na urządzeniach mobilnych (z obsługą Java Micro Edition) Sprawdzenie możliwości wykorzystania serwerów LDAP jako repozytoriów serwisów dla urządzeń mobilnych (koncepcja proxy: Service <-> LDAP) Analiza możliwości urządzeń mobilnych oraz sensorów medycznych mogących być odbiorcami lub dostarczycielami serwisów ERA G1 (system operacyjny Android) Neo FreeRunner (system operacyjny Linux Openmoko) Sensor medyczny - ciśnieniomierz (BP Pro) z komunikacją Bluetooth INNOWACYJNA GOSPODARKA

21 [OB5-3] Mobilne usługi SOA INNOWACYJNA GOSPODARKA

22 SUN -SPOT The radio is a TI CC2420 (formerly ChipCon) IEEE compliant. 1.3-axis accelerometer 2. temperature sensor, 3. light sensor, 4. 8 tri-color LEDs, 5. 6 analog inputs readable by an ADC, 6. 2 momentary switches, 7. 5 general purpose I/O pins and 4 high current output pins. INNOWACYJNA GOSPODARKA Mobile Ad-Hoc Network Our goal: Integration with SCA FPGA based extensions

23 Etap II ( ) Budowę pilotaŝowych implementacji i ich wdroŝenie w obszarach: Systemów telemedycznych Systemów informatycznych słuŝby zdrowia Systemów administracji publicznej Organizacji procesów inwestycyjnych w budownictwie Telekomunikacji Rynku elektronicznego Doskonalenie metod i narzędzi w zakresie: usług infrastrukturalnych i mechanizmów integracji systemów SOA realizowanych z wykorzystaniem SOKU, technik wspomagania automatyzacji kompozycji aplikacji i procesów biznesowych, technologii optymalizacji systemów SOA zwiększających ich niezawodność. INNOWACYJNA GOSPODARKA

24 INNOWACYJNA GOSPODARKA Dziękuję za uwagę

25 SOA w medycznych systemach INNOWACYJNA GOSPODARKA telekonsultacyjnych Łukasz Czekierda Tomasz Masternak Krzysztof Zieliński

26 Wprowadzenie Plan prezentacji Dotychczasowe doświadczenie i osiągnięcia Założenia paradygmatu SOA Zalety realizacji systemu telekonsultacyjnego w oparciu o podejście SOA Realizacja technologiczna INNOWACYJNA GOSPODARKA

27 Jak rozumiemy telemedycynę? Telemedycyna jest wynikiem naturalnego procesu wykorzystania technologii informatycznych i telekomunikacyjnych dla celów diagnostyki medycznej i opieki nad chorymi Zakres telemedycyny obejmuje zdalnie wykonywane procesy konsultowania terapii i wykonywania zabiegów monitorowania i rehabilitacji pacjentów profilaktyki i edukacji pacjentów oraz edukacji lekarzy i studentów medycyny INNOWACYJNA GOSPODARKA

28 Telemedycyna w kardiologii polskie osiągnięcia Operacje kardiochirurgiczne z wykorzystaniem robotów Prace zespołu dra Zbigniewa Nawrata z FRK Konsultacje prowadzone zdalnie pomiędzy lekarzami Zespół Systemów Rozproszonych Katedry Informatyki AGH (aplikacja TeleDICOM) Centrum Kardiochirurgii w Aninie (system Tekomed) Zdalne monitorowanie pacjenta Systemy teleekg, przesył sygnału EKG z karetki Zdalnie prowadzona rehabilitacja pacjenta Prace zespołu prof. Ryszarda Piotrowicza INNOWACYJNA GOSPODARKA

29 Rozwój telemedycyny INNOWACYJNA GOSPODARKA

30 Medyczny kontekst telekonsultacji kompetencje wiedza medyczna, dokumentacja medyczna, złożoność aparatury INNOWACYJNA GOSPODARKA specjalizacja czas Narzędzia telekonsultacyjne mogą wpłynąć na lepsze wykorzystanie wiedzy ekspertów nie wymagając od nich pełnienia dyżurów w wielu ośrodkach medycznych oraz przewożenia pacjentów

31 TeleDICOM System do zdalnych, interaktywnych telekonsultacji medycznych Wdrożony w KSS im. Jana Pawła II oraz 12 współpracujących szpitalach z południowej Polski W latach przeprowadzono ponad 2000 konsultacji angiograficznych Wielokrotnie używany w czasie Małopolskich Warsztatów Echokardiograficznych Telekonsultacje są potrzebne Zgromadzone bardzo duże doświadczenie INNOWACYJNA GOSPODARKA

32 Zalety i wady obecnej wersji Zalety: funkcjonalność Zaawansowanie komunikacyjne i diagnostyczne Bardzo wysokie oceny użytkowników-lekarzy Wadywynikają z monolitycznejbudowy aplikacji Monolityczność aplikacji klienta: trudność przygotowywania dedykowanych wersji aplikacji Trudność wdrażania, utrzymania (rekonfiguracji) i modernizacji systemu INNOWACYJNA GOSPODARKA

33 Nowa wersja systemu: wymagania Podstawowe wymogi: pełna zgodność z obowiązującymi standardami i normami Reprezentacja obrazowych danych medycznych: DICOM Komunikacja z archiwami medycznymi PACS: DICOM Raportowanie: DICOM SR Współpraca z systemami HIS: HL7 Pełne bezpieczeństwo danych medycznych Efektywniejsza dystrybucja danych medycznych Modularna budowa aplikacji klienckiej Łatwiejszy proces wdrażania systemu i zarządzania nim System realizowany w oparciu o paradygmat SOA INNOWACYJNA GOSPODARKA

34 INNOWACYJNA GOSPODARKA Założenia paradygmatu SOA

35 Co oferuje paradygmat SOA? Zorientowanie na usługi (xaas) Usługa jest jednostkąfunkcjonalną udostępnianą przez dostawcęw celu osiągnięcia przez konsumenta pożądanego efektu(ifead) Łatwość integracji z zastanymi systemami informatycznymi Łatwość konstruowania usług złożonych na drodze kompozycji opis usług, kontrakt Łatwość doboru i dynamicznej podmiany instancji usługi luźne powiązanie INNOWACYJNA GOSPODARKA

36 Komunikacja w podejściu usługowym Komunikacja asynchroniczna MoM Enterprise Service Bus Eliminacja bezpośrednich połączeń między instancjami usług Łatwość nadzorowania i utrzymania systemu Zapewnienie cech pozafunkcjonalnych (QoS, bezpieczeństwo) INNOWACYJNA GOSPODARKA

37 Repozytoria katalogi usług Umożliwiają wyszukanie potrzebnych usług w oparciu o zadane kryteria Zawierają opis sposobu użycia usługi Zawierają lokalizację instancji usługi INNOWACYJNA GOSPODARKA

38 Realizacja systemu INNOWACYJNA GOSPODARKA telekonsultacji w podejściu SOA

39 Zorientowanie na usługi Usługa konsultacji: świadczona przez lekarza lub system automatycznej diagnozy Usługa dystrybucji danych medycznych: dostarczenie ich do właściwych węzłów systemu Usługa anonimizacji danych medycznych Usługa doboru instancji usługi konsultacji Usługa organizacji interaktywnej sesji konsultacyjnej Usługa realizacji interaktywnej sesji konsultacyjnej... INNOWACYJNA GOSPODARKA

40 Zorientowanie na usługi Zasoby zastane udostępniane jako usługi: Oprogramowanie (PACS, HIS) Konsultanci Nowe usługi: Korzystają z już istniejących Usługi złożone tworzone przez kompozycję usług prostych INNOWACYJNA GOSPODARKA

41 Struktura sieci telekonsultacyjnej Zbiór autonomicznych jednostek medycznych Hierarchiczna struktura każdej z jednostek Szpital-oddział-pododdział-...-użytkownicy Współpraca między jednostkami regulowana przez kontrakt Definiuje warunki świadczenia usług Umożliwia udostępnianie danych medycznych poza jednostkę W wyniku zawarcia kontraktu powstaje tzw. wirtualna organizacja INNOWACYJNA GOSPODARKA

42 Aktorzy: Proces konsultacyjny (1/2) Zlecający, Konsultant (-ci), Diagnoza: Zapis sesji konsultacyjnej, Dokument podpisany przez konsultanta INNOWACYJNA GOSPODARKA

43 Proces konsultacyjny (2/2) Faza przygotowania: Dobór konsultanta, Ustalenie terminu i trybu, Transfer danych diagnostycznych, Sesja konsultacyjna: Konfiguracja usług sesyjnych, Dokonanie ekspertyzy, Kanały komunikacyjne: synchronizacja widoków, komunikacja głosowa (może także obrazowa) INNOWACYJNA GOSPODARKA

44 Jednostka medyczna elementy zastane Medical Site INNOWACYJNA GOSPODARKA

45 Integracja jednostek w modelu SOA INNOWACYJNA GOSPODARKA

46 Integracja jednostek w modelu SOA Warstwa usług związanych z danymi medycznymi: Dystrybucja Anonimizacja Konwersja INNOWACYJNA GOSPODARKA

47 Integracja jednostek w modelu SOA Warstwa usług konsultacyjnych: Organizacja sesji Prowadzenie sesji INNOWACYJNA GOSPODARKA

48 Realizacja technologiczna Infrastruktura systemu: zgodność z JBI Technologia budowy aplikacji klienckiej:.net Repozytorium usług: LDAP Uruchamianie instancji usług w środowisku zwirtualizowanym Zaawansowane mechanizmy monitorowania systemu INNOWACYJNA GOSPODARKA

49 Realizacja technologiczna INNOWACYJNA GOSPODARKA

50 INNOWACYJNA GOSPODARKA Komunikacja pomiędzy ośrodkami Consultation Router CXF Broker AMQ CXF Data Distribution Service BC Anonimization CXF CXF Directory Service BC Consultation Router CXF Broker AMQ CXF BC Anonimization CXF CXF Directory Service BC LDAP Broker AMQ Broker AMQ Consultation Service WCF WCF WCF Data Distribution Service WCF Consultation Service WCF WCF PACS PACS DICOM DICOM

51 Aktualny stan prac Ocena wydajności i stabilności wykorzystywanych technologii Prototyp systemu monitorowania infrastruktury komunikacyjnej Badanie technologii wirtualizacji Prototypowy system dystrybucji danych Prototyp aplikacji klienckiej INNOWACYJNA GOSPODARKA

52 INNOWACYJNA GOSPODARKA Dziękuję za uwagę

53 Usługi sieciowe REST Jerzy Brzeziński Cezary Sobaniec Instytut Informatyki Politechnika Poznańska

54 Wprowadzenie Service Oriented Architecture nie zakłada stosowania technologii Web Services... J. Brzeziński, C. Sobaniec Usługi sieciowe REST [1/20]

55 Wprowadzenie Service Oriented Architecture nie zakłada stosowania technologii Web Services więc porozmawiajmy o alternatywie J. Brzeziński, C. Sobaniec Usługi sieciowe REST [1/20]

56 1 Representational State Transfer 2 Modele usług sieciowych 3 Wybrane aspekty funkcjonowania usług sieciowych

57 Krytyka (Big) WebServices Dominująca technlogia realizacji usług sieciowych Szerokie wsparcie ze strony dostawców oprogramowania J. Brzeziński, C. Sobaniec Usługi sieciowe REST [2/20]

58 Krytyka (Big) WebServices Dominująca technlogia realizacji usług sieciowych Szerokie wsparcie ze strony dostawców oprogramowania Ale: złożoność mnogość standardów WS-* powielanie istniejących standardów ignorowanie dostępnych technologii/standardów sieci Web problemy ze współoperacyjnością (działania WS-I) problemy z wydajnością J. Brzeziński, C. Sobaniec Usługi sieciowe REST [2/20]

59 REpresentational State Transfer REST Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, PhD Thesis, jeden z kluczowych autorów protokołu HTTP (RFC 2616) rozwijał HTML tworzył koncepcję URI współzałożyciel projektu Apache HTTP Server członek OpenSolaris Boards J. Brzeziński, C. Sobaniec Usługi sieciowe REST [3/20]

60 REST Representational State Trasfer styl architektoniczny, metaarchitektura, metodologia J. Brzeziński, C. Sobaniec Usługi sieciowe REST [4/20]

61 REST Representational State Trasfer styl architektoniczny, metaarchitektura, metodologia Założenia: architektura klient-serwer bezstanowość (cache) buforowanie podręczne jednolity interfejs dostępu J. Brzeziński, C. Sobaniec Usługi sieciowe REST [4/20]

62 REST Representational State Trasfer styl architektoniczny, metaarchitektura, metodologia Założenia: architektura klient-serwer bezstanowość (cache) buforowanie podręczne jednolity interfejs dostępu Jednolity interfejs jednolita identyfikacja/adresacja zasobów manipulacja zasobami poprzez ich reprezentacje samoopisujące się wiadomości (bezstanowość) powiązania między zasobami (wyrażone w reprezentacjach) J. Brzeziński, C. Sobaniec Usługi sieciowe REST [4/20]

63 Cele REST Skalowalność interakcji komponentów Ogólność interfejsów Niezależność wdrażania komponentów loose coupling możliwość aktualizacji/rozszerzania protokołu Możliwość wprowadzania usług pośredniczących redukcja opóźnień zwiększanie bezpieczeństwa opakowywanie zastanych systemów (gateways) J. Brzeziński, C. Sobaniec Usługi sieciowe REST [5/20]

64 REST w kontekście HTTP RESTful web services usługi sieciowe REST J. Brzeziński, C. Sobaniec Usługi sieciowe REST [6/20]

65 REST w kontekście HTTP RESTful web services usługi sieciowe REST Resource Oriented Architecture J. Brzeziński, C. Sobaniec Usługi sieciowe REST [6/20]

66 REST w kontekście HTTP RESTful web services usługi sieciowe REST Resource Oriented Architecture Założenia ROA Wykorzystanie URI do identyfikacji zasobów Wykorzystanie metod protokołu HTTP do manipulacji zasobami (model CRUD): POST tworzenie GET odczyt PUT aktualizacja DELETE usuwanie Reprezentacja zasobów: typy MIME J. Brzeziński, C. Sobaniec Usługi sieciowe REST [6/20]

67 Zalety usług sieciowych REST Prostota J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

68 Zalety usług sieciowych REST Prostota Mniejszy narzut obliczeniowy brak dodatkowego opakowania zleceń (koperta SOAP) brak konieczności przetwarzania dokumentów XML J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

69 Zalety usług sieciowych REST Prostota Mniejszy narzut obliczeniowy brak dodatkowego opakowania zleceń (koperta SOAP) brak konieczności przetwarzania dokumentów XML Wykorzystanie znanej i przetestowanej infrastruktury: Web J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

70 Zalety usług sieciowych REST Prostota Mniejszy narzut obliczeniowy brak dodatkowego opakowania zleceń (koperta SOAP) brak konieczności przetwarzania dokumentów XML Wykorzystanie znanej i przetestowanej infrastruktury: Web Możliwość stosowania serwerów pośredniczących J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

71 Zalety usług sieciowych REST Prostota Mniejszy narzut obliczeniowy brak dodatkowego opakowania zleceń (koperta SOAP) brak konieczności przetwarzania dokumentów XML Wykorzystanie znanej i przetestowanej infrastruktury: Web Możliwość stosowania serwerów pośredniczących Semantyka operacji charakter zlecanego przetwarzania (odczyt, modyfikacja) optymalizacja buforowania podręcznego i replikacji J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

72 Zalety usług sieciowych REST Prostota Mniejszy narzut obliczeniowy brak dodatkowego opakowania zleceń (koperta SOAP) brak konieczności przetwarzania dokumentów XML Wykorzystanie znanej i przetestowanej infrastruktury: Web Możliwość stosowania serwerów pośredniczących Semantyka operacji charakter zlecanego przetwarzania (odczyt, modyfikacja) optymalizacja buforowania podręcznego i replikacji Mniej problemów ze współoperacyjnością (jednolity interfejs) J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

73 Zalety usług sieciowych REST Prostota Mniejszy narzut obliczeniowy brak dodatkowego opakowania zleceń (koperta SOAP) brak konieczności przetwarzania dokumentów XML Wykorzystanie znanej i przetestowanej infrastruktury: Web Możliwość stosowania serwerów pośredniczących Semantyka operacji charakter zlecanego przetwarzania (odczyt, modyfikacja) optymalizacja buforowania podręcznego i replikacji Mniej problemów ze współoperacyjnością (jednolity interfejs) Minimum narzędzi potrzebnych do implementacji J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

74 Zalety usług sieciowych REST Prostota Mniejszy narzut obliczeniowy brak dodatkowego opakowania zleceń (koperta SOAP) brak konieczności przetwarzania dokumentów XML Wykorzystanie znanej i przetestowanej infrastruktury: Web Możliwość stosowania serwerów pośredniczących Semantyka operacji charakter zlecanego przetwarzania (odczyt, modyfikacja) optymalizacja buforowania podręcznego i replikacji Mniej problemów ze współoperacyjnością (jednolity interfejs) Minimum narzędzi potrzebnych do implementacji Szeroka akceptacja wśród programistów J. Brzeziński, C. Sobaniec Usługi sieciowe REST [7/20]

75 Usługi sieciowe a architektura Web (1) SOAP traktuje Web jako mechanizm transportowy do przesyłania wiadomości interpretowanych przez aplikacje spoza Web tunelowanie wiadomości przez Web nie po to był tworzony Web nie za bardzo nadaje się do tego celu SOAP korzysta tylko z (rozmytej semantycznie) metody POST protokołu HTTP pomijając najsilniejsze strony Web J. Brzeziński, C. Sobaniec Usługi sieciowe REST [8/20]

76 Usługi sieciowe a architektura Web (1) SOAP traktuje Web jako mechanizm transportowy do przesyłania wiadomości interpretowanych przez aplikacje spoza Web tunelowanie wiadomości przez Web nie po to był tworzony Web nie za bardzo nadaje się do tego celu SOAP korzysta tylko z (rozmytej semantycznie) metody POST protokołu HTTP pomijając najsilniejsze strony Web Web jest już integrującą szyną komunikacyjną (cf. ESB) wyposażoną w: predefiniowaną semantykę operacji predefiniowany model adresowania J. Brzeziński, C. Sobaniec Usługi sieciowe REST [8/20]

77 Usługi sieciowe a architektura Web (2) Fundamentem dla Web są identyfikatory URI (Uniform Resource Identifier) Web Services pozostawiają zarządzanie nazwami aplikacjom SOAP stosuje URI tylko do wskazywania punktu dostępu do usługi, która zarządza wszystkimi wewnętrznymi zasobami, np.: bank = new SOAPProxy(" bank.addmoneytoaccount(" ", 540.5); brak bezpośredniego dostępu do konta (tylko bank) nowa przestrzeń nazw dla numeracji kont J. Brzeziński, C. Sobaniec Usługi sieciowe REST [9/20]

78 SOAP a inne technologie Web/XML Wiele protokołów/technologii zakłada wykorzystanie URI do adresacji zasobów: Resource Description Framework XLinks odwołania w dokumentach XML RSS Really Simple Syndication XPointer uogólnienie XPath XInclude załączanie zewnętrznych dokumentów SOAP wymusza tworzenie nowych standardów zastępujących wymienione. J. Brzeziński, C. Sobaniec Usługi sieciowe REST [10/20]

79 1 Representational State Transfer 2 Modele usług sieciowych 3 Wybrane aspekty funkcjonowania usług sieciowych

80 Modele usług sieciowych Zdalne wywołania procedur Java RMI, CORBA, Web Services J. Brzeziński, C. Sobaniec Usługi sieciowe REST [11/20]

81 Modele usług sieciowych Zdalne wywołania procedur Java RMI, CORBA, Web Services Architektura zorientowana na zasoby usługi sieciowe REST J. Brzeziński, C. Sobaniec Usługi sieciowe REST [11/20]

82 Modele usług sieciowych Zdalne wywołania procedur Java RMI, CORBA, Web Services Architektura zorientowana na zasoby usługi sieciowe REST Podejścia hybrydowe J. Brzeziński, C. Sobaniec Usługi sieciowe REST [11/20]

83 Klasyfikacja usług sieciowych (1) Podstawowe pojęcia używane przy opisie usługi: operacje wykonywane/oferowane przez usługę zasoby udostępniane przez usługę J. Brzeziński, C. Sobaniec Usługi sieciowe REST [12/20]

84 Klasyfikacja usług sieciowych (1) Podstawowe pojęcia używane przy opisie usługi: operacje wykonywane/oferowane przez usługę zasoby udostępniane przez usługę Wybór determinuje sposób modelowania i projektowania usługi J. Brzeziński, C. Sobaniec Usługi sieciowe REST [12/20]

85 Klasyfikacja usług sieciowych (1) Podstawowe pojęcia używane przy opisie usługi: operacje wykonywane/oferowane przez usługę zasoby udostępniane przez usługę Wybór determinuje sposób modelowania i projektowania usługi Usługa może udostępniać oba interfejsy J. Brzeziński, C. Sobaniec Usługi sieciowe REST [12/20]

86 Klasyfikacja usług sieciowych (1) Podstawowe pojęcia używane przy opisie usługi: operacje wykonywane/oferowane przez usługę zasoby udostępniane przez usługę Wybór determinuje sposób modelowania i projektowania usługi Usługa może udostępniać oba interfejsy Nie ma możliwości automatyzacji translacji odwołań do usług pomiędzy modelami specyfika usługi J. Brzeziński, C. Sobaniec Usługi sieciowe REST [12/20]

87 Klasyfikacja usług sieciowych (2) Zakładając wykorzystanie protokołu HTTP do komunikacji Gdzie jest nazwa metody? Gdzie jest wskazanie na zakres przetwarzanych danych? (ang. scoping) J. Brzeziński, C. Sobaniec Usługi sieciowe REST [13/20]

88 Klasyfikacja usług sieciowych (3) RPC metoda i argument zapisane w wiadomości SOAP POST /ws HTTP/1.1 Host: books.example.com Content-Type: application/soap+xml Content-Length: 165 <?xml version="1.0" encoding="utf-8"?> <soap:envelope> <soap:body> <m:lookupbook> <m:id>12345</m:id> </m:lookupbook> </soap:body> </soap:envelope> J. Brzeziński, C. Sobaniec Usługi sieciowe REST [14/20]

89 Klasyfikacja usług sieciowych (4) Model zasobowy metoda protokołu HTTP, argument w URI Usługa sieciowa REST GET /books/12345 HTTP/1.1 Host: books.example.com Istotne różnice: wykorzystanie metody GET zamiast POST jawna reprezentacja zasobu /books/12345 brak dodatkowej koperty J. Brzeziński, C. Sobaniec Usługi sieciowe REST [15/20]

90 Klasyfikacja usług sieciowych (5) Usługa hybrydowa metody i argument w URI: Usługa hybydowa GET /service?method=lookupbook&id=12345 HTTP/1.1 Host: books.example.com Uwagi: ograniczenie się do protokołu HTTP metody modyfikujące wywoływane metodą GET J. Brzeziński, C. Sobaniec Usługi sieciowe REST [16/20]

91 1 Representational State Transfer 2 Modele usług sieciowych 3 Wybrane aspekty funkcjonowania usług sieciowych

92 Opis usługi Przetwarzalny maszynowo opis interfejsu usług J. Brzeziński, C. Sobaniec Usługi sieciowe REST [17/20]

93 Opis usługi Przetwarzalny maszynowo opis interfejsu usług WS-*: WSDL + XML Schema silne typowanie możliwość automatycznego generowania kodu J. Brzeziński, C. Sobaniec Usługi sieciowe REST [17/20]

94 Opis usługi Przetwarzalny maszynowo opis interfejsu usług WS-*: WSDL + XML Schema REST: silne typowanie możliwość automatycznego generowania kodu WADL Web Application Description Language modelowanie zasobów i relacji pomiędzy nimi URI + metoda + arg. we wynik J. Brzeziński, C. Sobaniec Usługi sieciowe REST [17/20]

95 Opis usługi Przetwarzalny maszynowo opis interfejsu usług WS-*: WSDL + XML Schema REST: silne typowanie możliwość automatycznego generowania kodu WADL Web Application Description Language modelowanie zasobów i relacji pomiędzy nimi URI + metoda + arg. we wynik WSDL 2.0 J. Brzeziński, C. Sobaniec Usługi sieciowe REST [17/20]

96 Opis usługi Przetwarzalny maszynowo opis interfejsu usług WS-*: WSDL + XML Schema REST: silne typowanie możliwość automatycznego generowania kodu WADL Web Application Description Language modelowanie zasobów i relacji pomiędzy nimi URI + metoda + arg. we wynik WSDL 2.0 odkrywanie usługi (calling navigation) J. Brzeziński, C. Sobaniec Usługi sieciowe REST [17/20]

97 Kompozycja usług WS-* Business Process Execution Language JOpera, XL J. Brzeziński, C. Sobaniec Usługi sieciowe REST [18/20]

98 Kompozycja usług WS-* Business Process Execution Language JOpera, XL REST Web 2.0 mashups J. Brzeziński, C. Sobaniec Usługi sieciowe REST [18/20]

99 Repozytoria usług WS-*: UDDI standard okrzepły, ale mała liczba publicznych, otwartych repozytoriów usług J. Brzeziński, C. Sobaniec Usługi sieciowe REST [19/20]

100 Repozytoria usług WS-*: UDDI standard okrzepły, ale mała liczba publicznych, otwartych repozytoriów usług REST: po prostu Web wyszukiwarki internetowe microformats J. Brzeziński, C. Sobaniec Usługi sieciowe REST [19/20]

101 Podsumowanie Obszary zastosowań usług sieciowych (architektury SOA): J. Brzeziński, C. Sobaniec Usługi sieciowe REST [20/20]

102 Podsumowanie Obszary zastosowań usług sieciowych (architektury SOA): Zastosowania przemysłowe (enterprise) preferencja WebServices szerokie wsparcie ze strony producentów oprogramowania dostępność standardów uzupełniających J. Brzeziński, C. Sobaniec Usługi sieciowe REST [20/20]

103 Podsumowanie Obszary zastosowań usług sieciowych (architektury SOA): Zastosowania przemysłowe (enterprise) preferencja WebServices szerokie wsparcie ze strony producentów oprogramowania dostępność standardów uzupełniających Zastosowania webowe preferencja usług REST (Google Data API, Amazon WS) usługi sieciowe REST są de facto rozszerzeniem Web priorytet: integracja z istniejącą siecią Web J. Brzeziński, C. Sobaniec Usługi sieciowe REST [20/20]

104 Zarządzanie w systemach SOA Dariusz Dwornikowski Michał Sajkowski Instytut Informatyki Politechnika Poznańska

105 Plan prezentacji 1 Motywacja zarządzania 2 Problematyka zarządzania w SOA 3 Przegląd istniejących standardów i podejść 4 Nowe podejścia w zarządzaniu 1 systemy autonomiczne 2 zarządzanie i monitoring proaktywny 3 analiza strumieni zdarzeń 5 Wnioski 6 Zarządzanie w projekcie IT-SOA D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [1/18]

106 Zarządzanie w SOA Motywacja Motywacja zarządzania w systemach SOA jest analogiczna do tej w innego typu architekturach: 1 Biznesowa zapewnienie QoS, zapewnienie QoE, gwarancja ustalonego SLA. 2 Infrastrukturalna niezawodność, wydajność, dostępność, łatwość zarządzania wersjami. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [2/18]

107 Zarządzanie w SOA Problematyka w SOA Systemy SOA cechują się: rozległością geograficzną, Trudność w zarządzaniu, różne lokalizacje, organizacje. luźnym powiązaniem, Nie ma jasno sprecyzowanych związków pomiędzy usługami, topologia przetwarzania zmienia się. ukierunkowaniem na procesy biznesowe, Usługi uczestniczące w realizacji procesu biznesowego mogą się zmieniać. autonomicznością podsystemów, Zarządzane przez różne organizacje. w przypadku WS-* mnogością standardów, wielowarstwową natura. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [3/18]

108 Zarządzanie w SOA Wielowarstwowa natura zarządzania Systemy SOA cechują się wielowarstwową naturą, zatem zarządzanie powinno być do niej dostosowane: organizacje wirtualne (VO), procesy biznesowe (język BPEL, szyna ESB), pojedyncze aplikacje realizujące usługi atomowe, system operacyjny, sieć, systemy wirtualizacji. Tradycyjne metody i mechanizmy zarządzania nie wpisują się dobrze w ten schemat. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [4/18]

109 Zarządzanie w SOA Podejścia monitorowanie i zarządzanie na poziomie orkiestracji usług, języka BPEL, monitorowanie i adaptacja na poziomie szyny ESB, WS-Management, Web Based Enterprise Management, Web Services Distributed Management: Monitoring using Web Services i Monitoring of Web Services, systemy dostawców, np. rodzina produktów IBM Tivoli. To wszystko mechanizmy i metody skupione wokół, lub używające standardów WS-*, a co z REST? D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [5/18]

110 Zarządzanie w modelu REST Analogia do WWW zorientowanie na zasoby, podobnie jak zarządzanie, HTTP jako główny protokół łatwość integracji z aplikacjami WWW, infrastruktura identyczna z WWW, zatem zarządzanie analogiczne, czytelne komunikaty (GET łatwa adaptacja poprzez sterowanie ruchem, replikacje, równoważenie obciążeń, BPEL4REST. możliwość integracji ze standardami wymienionymi wcześniej. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [6/18]

111 Zarządzanie w SOA Problematyka W złożonych systemach SOA, opartych na modelu WS-*, jak i REST nadal występują problemy: Pytanie złożoności standardów oraz ich mnogości (WS-*), wyboru warstwy, w której się zarządza, monitoruje, kosztu wytworzenia lub dostosowania systemu zarządzania (WS-* i REST), wielkości zespołu potrzebnego do zarządzania, organizacji pracy. Czy zatem pewnych zadań nie da się zautomatyzować? Sprawić, żeby części systemu zarządzały się same? D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [7/18]

112 Nowe podejścia w zarządzaniu Autonomic Computing Systemy autonomiczne to jednostki samozarządzające się, tzn. takie, które posiadają własności: samokonfiguracji, samonaprawy, samooptymalizacji, samoobrony. Rys.: Menedżer autonomiczny (źródło Understanding Autonomic Manager Concept, Jason Bell, IBM) D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [8/18]

113 Nowe podejścia w zarządzaniu Zarządzanie proaktywne wykrywanie problemów zanim się zdarzą i zapobieganie im, planowanie pojemnościowe i wydajnościowe, predykcja zdarzeń (analiza szeregów czasowych, procesy Markova), wydajne uczenie maszynowe (rozpoznawanie wzorców, indukcja reguł), detekcja anomalii, diagnostyka (analiza Bayesowska). D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [9/18]

114 Nowe podejścia w zarządzaniu Analiza strumieni zdarzeń Przy złożoności systemów SOA, tradycyjne odpytywanie lub otrzymywanie danych z systemu monitorowania przestaje być wydajne, a przez to skuteczne. Dane z systemów monitorowania lepiej traktować jak strumienie zdarzeń, które następnie można efektywnie przetwarzać, analizować i korelować. Wykorzystanie silników inteligentnego (IEP) oraz złożonego przetwarzania zdarzeń (CEP). Przykład: Esper. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [10/18]

115 Nowe podejścia w zarządzaniu Wnioski Stworzenie w pełni autonomicznego systemu SOA na dzisiejszy dzień jest skrajnie trudne, jeśli w ogóle możliwe. Rozwiązaniem mogą być lekkie menedżery autonomiczne, które zarządzają małymi fragmentami systemu, korzystają z metod zarządzania proaktywnego, uczenia maszynowego i analizy strumieni danych, aby w końcu efektywnie i samodzielnie zarządzać całym systemem. Większe zadania realizowane mogą być przez grupy menedżerów autonomicznych, komunikujących się ze sobą w celu realizacji jednego celu. Wykorzystanie uczenia maszynowego oraz menedżerów autonomicznych nie jest alternatywą dla istniejących podejść, a jedynie ich rozszerzeniem. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [11/18]

116 Zarządzanie w projekcie IT-SOA OB7-1: Metryki oceny systemów SOA Wybór metryk dla systemów SOA, propozycja nowych metryk. OB7-2: Monitorowanie usług w systemach SOA Opracowanie koncepcji i metod monitorowania w systemach SOA. OB7-3: Zarządzanie usługami w systemach SOA Opracowanie systemu zarządzania dla systemów SOA. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [12/18]

117 Zarządzanie w projekcie IT-SOA System monitorowania i zarządzania W ramach obszarów z OB7 powstaje system zarządzania i monitorowania dla systemów SOA. nacisk na metryki niezawodności, wydajności, replikacji, monitorowanie z użyciem analizy strumieni zdarzeń, moduł detekcji anomalii, predykcji zdarzeń, integracja z innymi systemami z OB2, elementy autonomiczne, ujednolicony język definiowania celu monitorowania oraz metryk. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [13/18]

118 Zarządzanie w projekcie IT-SOA Moduł monitorowania Moduł monitorowania: adaptery dla REST, SNMP, Zabbix, Nagios poprzez modularne adaptery, silnik przetwarzania i korelacji zdarzeń, agenci, samokonfiguracja przez zdalną dystrybucję kodu, auto odkrywanie. monitorowanie na poziomie serwerów proxy HTTP, moduł detekcji anomalii, predykcji zdarzeń, język definiowania metryk, integracja z systemem replikacji, wsparcie dla metryk globalnych i złożonych, integracja z systemem detekcji awarii. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [14/18]

119 Zarządzanie w projekcie IT-SOA Moduł zarządzania Moduł zarządzania: integracja z modułem monitorowania (sensory) i systemem replikacji, monitorowanie umów SLA założonych dla metryk, moduł QoS Proxy adaptacyjnego równoważenia obciążeń ruchu HTTP dla aktywnych replik usług RESTful, interfejs REST, WWW, urządzenia mobilne z systemem Android, rozbudowany system notyfikacji, autonomiczne sterowanie migracją systemów zwirtualizowanych (KVM/kQEMU). D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [15/18]

120 Zarządzanie w projekcie IT-SOA Założenia projektowe i technologie wydajność ( zdarzeń na sekundę na pentium4, 2GB ram), niezawodność (replikacja, skalowalność), rozszerzalność (modułowa budowa, architektura OSGi), nacisk na wsparcie administratorów w ich pracy, pewien stopień niezależności w podejmowaniu decyzji, wsparcie dla podsystemów. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [16/18]

121 Zarządzanie w projekcie IT-SOA Architektura D. Dwornikowski, M. Sajkowski Rys.: Zarządzanie Architektura w systemachsystemu SOA [17/18]

122 Zarządzanie w projekcie IT-SOA Badania i dalsze prace Dalsze prace i badania obejmują: pełna implementacja lekkich menedżerów autonomicznych komunikujących się ze sobą, badania nad wydajną predykcją zdarzeń, detekcją anomalii, uczeniem maszynowym, badania nad algorytmami strumieniowymi, pełna integracja z klastrami wirtualizacji, zastosowanie w systemach medycznych. D. Dwornikowski, M. Sajkowski Zarządzanie w systemach SOA [18/18]

123 Problemy bezpieczeństwa w architekturze SOA Michał Szychowiak Politechnika Poznańska Michal.Szychowiak@put.poznan.pl

124 Plan 1. Specyfika SOA 2. Przegląd standardów 3. Rozproszona polityka bezpieczeństwa 4. Języki polityki bezpieczeństwa 5. Język ORCA Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [2]

125 Specyfika SOA m.in. luźne powiązania usług (ang. loose coupling) orkiestracja i choreografia procesów biznesowych poprzez wiele platform i środowisk operowanie w środowisku obejmującym wiele odrębnych domen administracyjnych kompozycjausług (zagnieżdżenie) wsparcie dla automatyzacji tego procesu wymagana wysoka współoperatywnośćmimo różnorodności technologii Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [3]

126 Specyfika SOA Różnorodność koncepcji: Transport-level security C sieć publiczna S tunel Message-level security C M 1 M 6 sieć S M 5 M 4 M 3 M 2 Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [4]

127 Standardy WS- (W3C, WS-I, OASIS) XML DSIG, XML Encryption, XKMS WS-Security, WS-SecureConversations WS-Trust, WS-Federation WS-Policy, WS-SecurityPolicy, WS-PolicyAttachment SAML, XACML WS-I Basic Security Profile Web Services Enhancements profiles... Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [5]

128 Standardy WS- (W3C, WS-I, OASIS)... <wsse:security xmlns:wsse=" WS-Security (SOAP Message Security) <ds:signature> <ds:signedinfo> XML Signature <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod <soap:envelope> XML EncryptionAlgorithm=" <ds:reference URI="#MsgBody"> <soap:header> <wsse:security> <ds:digestmethod tokeny bezpieczeństwa Algorithm=" </ds:reference> </ds:signedinfo> załączniki Security Header <ds:signaturevalue>d$b&m\5gk...</ds:signaturevalue> <ds:keyinfo> <wsse:securitytokenreference> </soap:header> XKMS <wsse:reference = XML Key URI="#SenderID"/> Management Specification <soap:body> </wsse:securitytokenreference>... Dane </ds:keyinfo> w tym zawartość </wsse:security> WS-SecureConversations </ds:signature> chroniona </wsse:security>... wielokrotne uŝycie klucza </soap:body> certyfikat X.509 XML DSIG zaszyfrowany klucz asercja SAML Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [6]

129 Standardy WS- (W3C, WS-I, OASIS) WS-Trust poświadczenia międzydomenowe Security Token Service WS-Federation toŝsamość sfederowana WS-I Basic Security Profile rekomendacje uŝycia tokenów bezpieczeństwa (X.509, Kerberos, SAML) Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [7]

130 Standardy WS- (W3C, WS-I, OASIS) WS-Policy / WS-PolicyAttachment model i składnia XML do przekazywania pojedynczych asercji bądź całych plików WS-SecurityPolicy Web Services Security Policy Language SAML Security Assertion Markup Language Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [8]

131 Polityka bezpieczeństwa element polityki biznesowej w uproszczeniu zbiór nakazów i zakazów określających bezpieczne korzystanie z systemu obejmuje m.in. definicję kont/ról i autoryzację specyfikację metod uwierzytelniania mechanizmy kontroli dostępu wymagania ochrony poufności, integralności,... Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [9]

132 Polityka bezpieczeństwa Specyfika SOA: musisz podpisywać Restrictions Obligations Capabilities C S mogę szyfrowaćdeszyfrować Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [10]

133 Języki definicji polityki bezpieczeństwa UMLsec, SecureUML XACML, PERMIS Ponder/Ponder2 SecPAL, OASIS, Cassandra KeyNote XPOLA Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [11]

134 Architektura środowiska Model podstawowy PEP PAP rule definition ISO/IEC IETF RFC 3198 XACML PIB repozytorium PDP PEP S policy requests and decision propagation PEP C Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [12]

135 Architektura środowiska Rozszerzony model dla SOA: PAP distributed trust federations PIP PIP PDP PDP... PEP PIB PIB PAL PAL PDP PDP PDP cache PDP cache logging PEP PEP S C Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [13]

136 ORCA(Obligations-Requirements-Capabilities-Audit) Reguły polityki ORCA składnia reguły Restriction: <Subject> X can access <Target> Y for{<action>}, <condition>. nazwa, rola, invocation, IP, URI, UDDI read, modify, append, create, delete, full access, any access nazwa, rola, IP, URI, UDDI predykaty wbudowane lub własne Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [14]

137 ORCA(Obligations-Requirements-Capabilities-Audit) Reguły polityki ORCA przykład reguły Restriction : User Xcan accessservice Y for{invocation}, if Role(X)="secret_agent" and iflocation(y)=" " and if access="get,post" and not on Holidays. Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [15]

138 ORCA (Obligations-Requirements-Capabilities-Audit) Przykładowa polityka Service requires to authenticate with {X.509certificate}. Service can encrypt with {xmlenc#tripledes-cbc, xmlenc#aes128-cbc}. Service can sign with {xmlsig#hmac-sha1}. User j_bond can access for invocation. User j_bond can authenticate with {username, X.509certificate}. User j_bond requires to sign with {xmlsig#hmac-sha1}. Michał Szychowiak Problemy bezpieczeństwa w architekturze SOA [16]