Mydło i spółka Serwisy sieciowe Wybrane zagadnienia Systemów protokół Rozproszonych (Simple Object Access Protokol) Aplikacje rozproszone Po co (Aplikacje o): Po co (źródło): rozproszenie przetwarzania dla uniknięcia wąskich w gardeł RPC (Remote( Procedure Call) Nowsze: CORBA, RMI, DCOM odizolowanie interfejsów w od szczegółów implementacyjnych poszczególnych platform Klient i serwer muszą używać tej samej technologii Technologie te zaprojektowano z myślą o zastosowaniach lokalnych (intranet) co z firwallem? 2 Serwisy sieciowe, WWW (Web Services) dostępne poprzez sieć komponenty aplikacyjne przeznaczonym do wykorzystania przez inne aplikacje, zwane aplikacjami klienckimi hermetyzowane, luźno skojarzone kontraktowane funkcje, oferowane poprzez standardowe protokoły. Hermetyzowane : : implementacja nigdy nie jest widoczna z zewnątrz. Luźno skojarzone : : modyfikowanie danej implementacji nie generuje problemu propagacji zmiany. Kontraktowane opisy działania ania funkcji oraz specyfikacja ich interfejsów w jest publicznie dostępna Komunikaty w XML Serwisy sieciowe Broker usług Wyszukiwanie Publikowanie Internet Żądający Połączenie Dostawca usługi z usługą usługi protokół nie jest binarny zakłada ada się użycie HTTP (ominięcie problemu zapór ogniowych), choć mogą to być też inne protokoły 3 4
Technologie serwisów w sieciowych WS-Inspection (Web Services Inspection Language) RDF (Resource( Description Framework) DAML (DARPA Agent Markup Language) ebxml UDDI WSDL XML Podstawowym zakładanym adanym zastosowaniem Web Services było o B2B. Praktyka wykazała, a, że e obecnie lepiej rozwijają się jednak jako środek integracji informacyjnej przedsiębiorstwa J2EE (przeważa) a).net 5 Krótka historia standardu Microsoft, DevelopMentor i Userland Software(US) ITEF (Internet Engineering Task Force) - oficjalna rekomendacja standardu 1998 Dave Winer z US ogłosił specyfikacje XML-RPC IBM, Lotus, Compaq, Intel, IONA Technologies specyfikacja 1.1 - opublikowana przez W3C 6 Co to jest? jest protokołem przeznaczonym do wymiany struktur informacji w rozproszonym środowisku zawiera trzy główne składniki: Envelope (koperta): opisuje co znajduje się w wysyłanym żądaniu i kto je ma odebrać reguły kodowania typów danych -RPC reprezentacja wywołania zdalnej procedury i jej wyniku Charakterystyka standardu posiada przejrzystą konstrukcję i jest łatwy w stosowaniu niezależny od konkretnych języków programowania i implementacji używa technologii XML i przestrzenie nazw wiadomości mogą być wymieniane poprzez szereg podrzędnych protokołów, najczęściej HTTP definiuje dwie struktury opracowane przez W3C: sposób kodowania danych i format komunikatów może być użyty do przekazywania pomiędzy dwiema aplikacjami prawie wszystkich rodzajów danych 7 8
Cechy standardu protokół przewiduje działania pośredników, używanie nazw jest obowiązkowe dla pozycji nagłówka; dla ciała komunikatu jest nieobowiązkowe umieszczaćinformację gdzie istnieje tu pewna dowolność, pozostawiająca decyzję projektantowi aplikacji; dane zawarte w pozycjach nagłówkowych mogąbyć przetwarzane i uzupełniane przez pośredników Struktura komunikatu Składa sięz trzech węzłów: envelope: wersja używanego, atrybuty określające kodowanie przesłanych danych header: dodatkowe informacje wykorzystywane do przetwarzania komunikatu body: treśćkomunikatu, sformatowane dane, nazwę wywoływanej procedury Envelope-Element Header-Element (opcjonalnie) Body-Element 9 10 Element Envelope Element Header <-ENV:Envelope xmlns:-env= http://www.w3.org/2002/06/soapenvelope xmlns:xsi= http://www.w3.org/2001/xmlschemainstance xmlns:xsd= http://www.w3.org/2001/xmlschema > <-ENV:Header>... <-ENV:Header> <-ENV:Body>... <-ENV:Body> <-ENV:Envelope> 11 bloki nagłówkowe (header blocks) zawierające informacje potrzebne do przetworzenia komunikatu pozycja nagłówkowa jest opisywana przez atrybuty: role - adresat danej pozycji mustunderstand - czy pozycja musi zostać przetworzona przez jej adresata <-ENV:Header> <m:transaction xmlns:m= soap-transaction -ENV:mustUnderstand= true > <transactionid>1234</transactionid> < m:transaction> <-ENV:Header> 12
Element Body kodowanie danych właściwa treść komunikatu dane przeznaczone dla ostatecznego odbiorcy atrybut encodingstyle sposób kodowania przesyłanych danych podstawowy typ kodowania - http://www.w3.org/2002/06/soap-encoding www.w3.org/2001/xmlschema-instance www.w3.org/2001/xmlschema typy: proste, złożone, referencje Model wymiany komunikatów RPC 1 Aplikacja A koduje w komunikacie protokołu zdalną proceduręwywołania (RCP) Aplikacja A 2 Komunikat protokołu jest kapsułkowany w HTTP, można go wysłaćpoprzez siećinternet HTTP INTERNET 4 Aplikacja B wysyła wynik do aplikacji A, wykorzystując inny komunikat protokołu 3 Aplikacja B dekoduje żądanie i działa zgodnie z nim Aplikacja B 13 14 Zasada działania ania protokołu u : realizacja modelu RPC wołanie odległej procedury wymaga podania: adres węzła docelowego nazwa procedury/metody wszystkie argumenty przekazywane do metody wyraźne wyodrębnienie danych służących identyfikacji od danych przeznaczonych do przetwarzania dodatkowe informacje w postaci pozycji nagłówkowych wszystkie przekazane argumenty opatrzone sąinformacjąo typie, zgodnąz systemem typów XML Schema URI pozwalające zlokalizowaćwłaściwąmetodęjest przekazywane w sposób zależny od protokołu 15 16
Wołanie RPC ciało komunikatu POST /soap/servlet/rpcrouter HTTP/1.0 Host: localhost:8081 Content-Type: text/xml; charset=utf-8 Content-Length: 451 Action: "" <?xml version= 1.0 encoding= UTF-8?> <-ENV:Envelope xmlns:- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <-ENV:Body> <ns1:add xmlns:ns1="urn:calculator" - ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <a xsi:type="xsd:float">2.3</a> <b xsi:type="xsd:float">3.5</b> </ns1:add> </-ENV:Body> </-ENV:Envelope> 17 Odpowiedź RPC HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: 446 Date: Sun, 15 Dec 2002 23:15:58 GMT Server: Apache Tomcat/4.0.4 (HTTP/1.1 Connector) <?xml version= 1.0 encoding= UTF-8?> <-ENV:Envelope xmlns:- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <-ENV:Body> <ns1:addresponse xmlns:ns1="urn:calculator" - ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="xsd:float">5.8</return> </ns1:addresponse> </-ENV:Body> </-ENV:Envelope> 18 Sygnalizowanie błędów przetwarzania Standardowe kody błędów: Sender komunikat został niewłaściwie sformułowany Receiver błąd po stronie odbiorcy; np. brak połączenia z wymaganym zasobem lub inną usługą MustUnderstand obowiązkowa do przetworzenia pozycja nagłówkowa nie została zrozumiana DataEncodingUnknown węzeł-adresat nie rozumie zastosowanego kodowania danych VersionMismatch przesłany komunikat nie został zawarty w odpowiednio nazwanej kopercie Podsumowanie - ogólne zasady MUSI być kodowany przy użyciu XML-a MUSI mieć element Envelope MOŻE mieć element Header MUSI mieć element Body MUSI używać odpowiednich przestrzeni nazw NIE MOŻE zawierać referencji do DTD NIE MOŻE zawierać instrukcji procesora XML-a 19 20
Zalety standardu Wady standardu opiera się na XML niezależny zarówno od języka i od platformy otwartość języka XML oraz ogólna dostępność analizatorów jego składni ułatwiają pisanie aplikacji dużo łatwiejszy w zastosowaniu przenika przez zapory ogniowe kodowanie danych jest mało wydajne, komunikaty są kodowane w formie tekstu, wykorzystują więcej pasma niż równoważne komunikaty binarne, muszą być przekształcane do postaci binarnej, by aplikacja mogła na nich działać. rozwiązanie - analizatorów składni XML, rozbudowane aplikacje i zwiększenie obciążenia CPU 21 22 i spółka 23 24
Universal Description, Discovery and Integration Service - UDDI ją określa wspólny zbiór interfejsów programistycznych dla technologii, umożliwiaj liwiając implementacjębroker brokerów usług ug Przedsiębiorstwa prowadzące operacje w Internecie realizujądost dostęp p do usług ug sieciowych za pośrednictwem rejestru UDDI, który ma za zadanie nawiąza zaćkontakt pomiędzy poszukującym usługi ugi a oferującym j Rejestry UDDI zawierają: informacje o Web Services na bazie nazwy usługodawcy, ugodawcy, jego adresu, kategorii biznesowej, informacji technicznej i tym podobne informacje, operacje dotyczące ce usługi, ugi, to jest: rejestracji, wyszukiwania i korzystania z usługi, ugi, szczegóły y udostępniane przez niskopoziomowy interfejs programistyczny. UDDI posiadajądwa dwa rodzaje klientów: usługodawc ugodawców w publikujących swoje usługi ugi oraz klientów w wyszukujących usług, ug, z których chcąskorzysta skorzystać. UDDI UDDI - książ ążka telefoniczna: yellow pages umożliwiaj liwiają wyszukiwanie usług, ug, które należą do konkretnej kategorii, znajdują się w danym regionie geograficznym, white pages zawierają informacje na temat dostawcy usługi, ugi, wraz z adresem, kontaktem i znanymi identyfikatorami, green pages informacje techniczne na temat usług, ug, na przykład jak się komunikować z Web Services Tego rodzaju rejestr stanowi niezbędn dną podstawę dla realizacji koncepcji rozwiniętej współpracy pracy B2B opartej na Web Services 25 26 Web Services Description Language usługi ugi Web Services są publikowane w rejestrze e- biznesowym UDDI.. Istnieją generatory plików w WSDL na podstawie komponentów w programowych [27]. Dokument WSDL opisuje, co oferuje usługa, uga, gdzie jest umieszczona oraz jak z niej skorzystać. WSDL opisuje technikę współdzia działaniaania z usług ugą.. Zakłada, ada, że e semantyka usługi ugi jest opisana na zewnątrz i może e być jednoznacznie wskazana poprzez identyfikator. Tym samym kontrakt dotyczący cy znaczenia i celu jest oddzielony od kontraktu określaj lającego mechanikę współdzia działania. ania. Specyfikacja zatem nie zajmuje się problemem definiowania semantyki usługi. Przykłady użycia u D. Cools Applying soft computing algorithms to e-business using web services ugi. 27 28
Przykłady cd.. NET, J2EE Java API for XML-based RPC (JAX( JAX-RPC) Java API for XML Registries (JAXR) Java Architecture for XML Binding (JAXB) with Attachments API for Java JAXP (Java API for XML Processing) DOM, SAX JAXB generuje klasy Javy ze schematów w XML za pomocą kompilatora schematów w (xjc( xjc). unmarshalling - zamiana pliku XML-owego na obiekty Javove, modyfikacja dokumentu XML-owego (na kopii z pamięci), walidacja - sprawdzenie poprawności z DTD (także dokonywane na dokumencie w pamięci), marshalling - zamiana obiektów Javowych na dokument XML- owy. 29 30 JAX-RPC Dodatkowe informacje na temat http://www.perfectxml.com/soaparticles.asp http://www.w3.org/tr/ http://www.soaprpc.com/ http://www.soapware.org/ 31 32