Referat z programowania systemowego. Przegląd protokołów do realizacji usług sieciowych SOAP, WSDL, UDDI

Akademia Górniczo Hutnicza im. St. Staszica w Krakowie Wydział EAIiE Referat z programowania systemowego Przegląd protokołów do realizacji usług sieciowych SOAP, WSDL, UDDI Jacek Midura Marcin Klimek Studia dzienne Rok 5 Informatyki Rok akademicki 2002/2003

Spis treści 1. Wprowadzenie... 3 1.1. Ogólny opis - webservices...3 1.2. Wstępne zarysowanie obszarów zastosowań SOAP, WSDL i UDDI...3 2. Protokół SOAP... 4 2.1. Ogólna charakterystyka protokołu SOAP, relacja pomiędzy XML a SOAP...4 2.2. Model komunikacji...5 2.3. Struktura komunikatu SOAP...6 2.3.1. Koperta SOAP...6 2.3.2. Nagłówek SOAP...7 2.3.3. Ciało SOAP...7 2.3.4. Kodowanie danych w komunikatach SOAP...8 2.4. Transmisja komunikatów SOAP protokołem HTTP...9 2.5. Użycie protokołu SOAP w celu zdalnego wywoływania procedur (RPC)...10 2.6. Wady i zalety SOAP...10 3. Protokół WSDL... 11 3.1. Do czego służy WSDL...11 3.2. Elementy protokołu WSDL (struktura dokumentu WSDL)...12 3.3. Przykłady praktyczne zastosowania WSDL...15 3.4. Wady i zalety stosowania WSDL...19 4. Protokół UDDI... 20 4.1. Do czego służy UDDI...20 4.2. Elementy protokołu UDDI...21 4.3. Przykład zastosowania UDDI...22 4.4. Wady i zalety stosowania UDDI...22 5. Zakończenie... 22 5.1. Współpraca protokołów SOAP, WSDL i UDDI...22 5.2. Bezpieczeństwo Web Services...23 5.3. Przyszłość Web Services...24

1. Wprowadzenie 1.1. Ogólny opis - webservices Pod terminem Usługi Web należy rozumieć zbiór małych funkcjonalnych klocków pracujących w sieci i udostępniających określone usługi innym systemom czy też innym webservices. Takimi klockami mogą być np. usługi pogodowe, translatory językowe czy mechanizmy przeliczające waluty, a wykorzystywane mogą być przez inne usługi udostępniające usługi bardziej złożone. Należy pamiętać, że webservices zwykle nie będą stanowić samodzielnych aplikacji, a jedynie stanowić interfejs komunikacyjny pomiędzy klientami z sieci a systemami biznesowymi. Tim Bray, współtwórca XML, definiuje usługi sieciowe jako standardowy interfejs, który pozwala jednej aplikacji programowo odkryć, zinterpretować i wykorzystać usługi oferowane przez inne platformy aplikacyjne bądź systemy operacyjne, w sposób niezależny od wykorzystywanego przez nie języka programowania. Wyjątkową siłą webservices jest wykorzystanie istniejących i szeroko stosowanych technologii tj. protokołu HTTP i języka XML. HTTP jest jednym z najbardziej rozpowszechnionych protokołów w sieci WEB, co umożliwia natychmiastowe wykorzystanie tej platformy do przesyłania komunikatów. XML dostarcza metajęzyk za pomocą którego porozumiewają się klienci z usługami oraz poszczególne komponenty. Idąc dalej, przy budowie i wykorzystaniu webservices nie ma znaczenia w jakiej technologii jest napisana usługa, na jakim systemie operacyjnym pracuje. Pełną interoperatywność zapewnia protokół SOAP, który ma aspiracje stać się następcą technik typu CORBA, RMI czy DCOM. Dzięki wykorzystywaniu nowego protokołu SOAP usługa opracowana w technologii Web Services ma możliwość współpracy (wymiany komunikatów) z dowolną inną usługą. Powinny zniknąć problemy występujące przy konwersjach realizowanych pomiędzy protokołami architektur DCOM i CORBA. Web Services mogą być pisane w dowolnych językach programowania, więc twórcy aplikacji będą mogli pisać usługi bez zmiany środowiska tworzenia aplikacji, w którym wcześniej pracowali. Protokół SOAP jest obecnie wspierany przez wszystkich podstawowych dostawców systemów oraz oprogramowania narzędziowego. 1.2. Wstępne zarysowanie obszarów zastosowań SOAP, WSDL i UDDI W celu umożliwienia komunikacji między aplikacjami rozproszonymi w sieci, należy opracować jakiś standard formatowania i przesyłania informacji. Wiele takich protokołów zostało już zaproponowanych w przeszłości, z czego niektóre uzyskały status standardu, a inne były rozwijane

przez pojedyncze firmy dla własnych produktów. Większość z nich ma jednak ograniczone zastosowanie w budowaniu wielkich, rozproszonych aplikacji w skali Internetu, ze względu na ich różne wymogi lub ograniczenia dotyczące platformy, producenta, czy też możliwości komunikacyjnych. Otwartość i rozszerzalność języków opartych na XML została szeroko uznana jako rozwiązanie dla nowoczesnych protokołów komunikacji sieciowej. Nie znaczy to bynajmniej, że XML powinien być stosowany w każdej sytuacji. W rzeczywistości stosowanie XML-a może być niekiedy wykluczone w systemach wymagających maksymalnej wydajności, ponieważ jego składnia jest bardzo 'rozrzutna', gdy porównać objętość właściwej informacji zawartej w dokumencie do jego całej objętości wraz ze znacznikami. Jednak dla wielu aplikacji e-biznesowych otwartość i rozszerzalność dialektów XML-a są ogromnymi zaletami zarówno przy zapisie treści, jak i struktury komunikatów. Wydaje się, że protokoły komunikacji wykorzystujące XML najlepiej sprawdzają się w integracji prowadzonej nie w czasie rzeczywistym, co ma często miejsce w systemach B2B. 2. Protokół SOAP 2.1. Ogólna charakterystyka protokołu SOAP, relacja pomiędzy XML a SOAP SOAP Simple Object Access Protocol (Prosty Protokół Dostępu do Obiektów). Czym jest SOAP: jest protokołem, a zatem mechanizmem transportu informacji; przenoszone informacje są uporządkowane (posiadają strukturę i typy); dane zapisane są w języku rozszerzalnych znaczników (XML); w tym protokole można przenosić wszelkiego rodzaju dane (w razie potrzeby są one kodowane do postaci wyrażalnej w XML); SOAP posiada bardzo szeroki zakres zastosowań: od prostych zastosowań komunikacyjnych po zdalne wywoływanie procedur (RPC). Czym nie jest SOAP: nie jest tym samym, co XML, chociaż jest na nim oparty; nie ma związku z protokołami SMTP czy HTTP, chociaż komunikaty SOAP często są przesyłane z wykorzystaniem mechanizmów typowych dla tych protokołów (np. transmitowane przez TCP/IP na portach 25 lub 80, często spotyka się również enkapsulowanie wewnątrz

komunikatów SMTP lub HTTP); nie jest związany z żadnym konkretnym modelem programowania czy jakąś specyfiką implementacji przeciwnie: jest uniwersalnym sposobem komunikacji w środowiskach rozproszonych oraz heterogenicznych. Organizacja XML Protocol Working Group działająca w ramach W3C opracowała dokument pod tytułem XML Protocol Abstract Model, który zawiera rozważania na temat cech dobrego protokołu komunikacyjnego opartego na XML i może stanowić podstawę oceny jakości konkretnych implementacji. Dokument ten powstał 9 lipca 2001 i ma status W3C Working Draft. Oto podstawowe zalecenia dotyczące budowy protokołu XML-owego zawarte w tej pracy: Należy dopuszczać możliwość wykorzystania różnych protokołów transportu (np. HTTP, SMTP i in.) Komunikacja może zachodzić wedle różnych schematów: wysłanie pojedynczego komunikatu, zapytanie/ odpowiedź, wymiana dłuższej sekwencji komunikatów Pośredniczące hosty mogą zmieniać komunikat API protokołu powinno zapewniać operacje wysłania, odebrania, przesłania dalej i sprawdzenia statusu komunikatu Należy zadbać o obsługę błędów połączenia Trzeba umożliwić transport dowolnych załączników do komunikatów w XML Obecnie trwają prace nad dostosowaniem specyfikacji protokołu SOAP 1.2 do tego modelu abstrakcyjnego (w tej chwili obowiązująca wersja nosi numer 1.1). Jako baza niniejszego opracowania wykorzystana została specyfikacja SOAP wersji 1.1 opracowana przez W3C, znajdująca się pod adresem http://www.w3.org/tr/2000/note-soap-20000508 Wśród wielu opracowywanych aktualnie protokołów bazujących na XML-u, SOAP wyróżnia się najszerszą akceptacją dużych producentów oprogramowania. 2.2. Model komunikacji Komunikacja za pomocą SOAP jest zasadniczo komunikacją jednokierunkową: od nadawcy do odbiorcy. Łatwo sobie jednak wyobrazić inne scenariusze bazujące na tym podstawowym: np. schemat wywołanie odpowiedź (request response) lub dialog dwóch stron. Wybrana do przenoszenia komunikatów warstwa transportowa może ułatwiać budowanie takich bardziej rozbudowanych scenariuszy, np. przy łączeniu za pomocą TCP/IP po przesłaniu komunikatu nadawca z odbiorcą zamieniają się rolami, a odpowiedź jest transmitowana tym samym połączeniem, którym poszło wywołanie.

2.3. Struktura komunikatu SOAP Komunikat SOAP jest dokumentem XML, który składa się z trzech elementów: 1.koperty SOAP (SOAP envelope) obowiązkowo 2.nagłówka SOAP (SOAP header) niekoniecznie 3.ciała SOAP (SOAP body) obowiązkowo Koperta SOAP Nagłówek SOAP wpis1 wpis2 Ciało SOAP element1 element2 Przykład: <env:envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22t14:00:00-05:00</n:expires> </n:alertcontrol> </env:header> <env:body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>pójść na obiad o 14:00</m:msg> </m:alert> </env:body> </env:envelope> 2.3.1. Koperta SOAP Koperta SOAP jest głównym, najbardziej zewnętrznym elementem dokumentu XML, który reprezentuje komunikat. Odnoszą się do niej następujące reguły: nazwa tego elementu musi brzmieć Envelope ;

ten element musi być obecny w komunikacie SOAP; ten element może zawierać deklaracje przestrzeni nazw oraz dodatkowe atrybuty. Specyfikacja SOAP nie zakłada przypisywania kopertom tradycyjnych dużych i małych numerów wersji. Komunikat SOAP musi mieć natomiast element Envelope połączony z przestrzenią nazw "http://schemas.xmlsoap.org/soap/envelope/". Jeśli jakaś aplikacja otrzyma komunikat z inną przestrzenią nazw w kopercie, ma obowiązek zwrócić błąd. 2.3.2. Nagłówek SOAP Jest on elementem nieobowiązkowym. Służy do przekazywania informacji o tym kto i w jaki sposób powinien przetwarzać dane zawarte w ciele komunikatu. Zawartość nagłówka może nieść także informację dla ogniw pośredniczących w transporcie komunikatu (np. serwerów proxy), może być także przez nie zmieniana. Następujące reguły dotyczą nagłówka: nazwa tego elementu musi brzmieć Header ; jeśli ten element występuje w komunikacie SOAP, musi być pierwszym bezpośrednim potomkiem elementu Envelope ; może on zawierać wpisy nagłówka (header entries), każdy będący bezpośrednim potomkiem elementu Header. Każdy wpis musi mieć zdefiniowaną przestrzeń nazw. 2.3.3. Ciało SOAP W tym elemencie przenoszona jest właściwa informacja. Ciało SOAP musi stosować się do następujących reguł: nazwa elementu musi brzmieć Body ; element ten musi wystąpić w komunikacie i musi być bezpośrednim potomkiem elementu Envelope ; jeśli w komunikacie występuje nagłówek, to ciało musi następować bezpośrednio po nim, w przeciwnym wypadku musi być pierwszym potomkiem elementu Envelope ; ten element może zawierać serię wpisów, z których każdy jest jego bezpośrednim potomkiem. Szczególnym rodzajem elementu jest element Fault. Służy on do przenoszenia informacji o błędach. Jeśli występuje w komunikacie SOAP, musi być wpisem ciała komunikatu (body entry) i może wystąpić tylko raz w całym komunikacie. Element Fault posiada cztery podelementy: faultcode kod błędu (obowiązkowy). Schemat kodów jest podobny do użytego w protokole http (1xx, 2xx, 3xx itd.);

faultstring czytelne dla człowieka (nie przeznaczone do przetwarzania maszynowego) objaśnienie istoty błędu (obowiązkowe); faultactor URI obiektu, który spowodował błąd (obowiązkowe, jeśli błąd powstał na którymś z etapów pośrednich uczestniczących w przekazywaniu komunikatu, nieobowiązkowe jeśli błąd powstał u adresata komunikatu); detail specyficzne informacje dotyczące błędu (obowiązkowe, jeśli błąd powstał przy przetwarzaniu ciała komunikatu, zabronione, jeśli błąd nie powstał przy przetwarzaniu ciała komunikatu). 2.3.4. Kodowanie danych w komunikatach SOAP Kodowanie danych w SOAP wykorzystuje hierarchię typów danych, która jest generalizacją podobnych hierarchii spotykanych we współczesnych językach programowania czy bazach danych. Najbardziej podstawowy podział typów to podział na typy proste (skalarne) oraz na typy złożone, które są połączeniem pewnej liczby części, z których każda posiada swój typ. XML dopuszcza bardzo elastyczne kodowanie danych, SOAP w tej dziedzinie jest bardziej ograniczony (ma ściślejsze reguły kodowania). SOAP przejmuje od XML wszystkie typy proste. Są to: string, boolean, decimal, float, double, duration, datetime, time, date, gyearmonth, gyear, gmonthday, gday, gmonth, hexbinary, base64binary, anyuri, QName, NOTATION. Przykład typowania danych: <element name="age" type="int"/> <element name="height" type="float"/> <element name="displacement" type="negativeinteger"/> <element name="color"> <simpletype base="xsd:string"> <enumeration value="green"/> <enumeration value="blue"/> </simpletype> </element> <age>45</age> <height>5.9</height> <displacement>-450</displacement> <color>blue</color> Ponadto w SOAP wspierane są następujące typy złożone: rekordy i tablice. Przykład:

<e:book> <author>henry Ford</author> <preface>prefatory text</preface> <intro>this is a book.</intro> </e:book> <element name="myfavoritenumbers" type="soap-enc:array"/> <myfavoritenumbers SOAP-ENC:arrayType="xsd:int[2]"> <number>3</number> <number>4</number> </myfavoritenumbers> 2.4. Transmisja komunikatów SOAP protokołem HTTP Bardzo często do transportu komunikatów SOAP używany jest protokół HTTP. Przyczyn jest kilka: jest to protokół bardzo elastyczny; jest zarazem pewny posiada mechanizmy raportowania błędów; jest niezwykle rozpowszechniony (co wiąże się z bogactwem narzędzi); umożliwia przekazywanie komunikatów SOAP nawet przez zapory (firewall) analizujące zawartość transmitowanego strumienia danych (ponieważ zazwyczaj zapory takie przepuszczają transmisję HTTP). Ze względu na charakter protokołu HTTP najbardziej naturalne jego wykorzystanie zachodzi podczas scenariusza transmisji wywołanie odpowiedź (request response). Podczas transmisji komunikatów SOAP wewnątrz wywołań/odpowiedzi HTTP należy używać typu text/xml. Pomimo iż SOAP można powiązać z różnymi typami wywołań HTTP, najczęściej jednak jest używane wywołanie POST. Odpowiedzi w protokole HTTP muszą posiadać odpowiedni status (np. 2xx oznaczają poprawne odebranie i przetworzenie wywołania). Jeśli podczas przetwarzania komunikatu wystąpi błąd, musi zostać zwrócona odpowiedź ze statusem 500 (Internal Server Error), a w ciele zwracanego komunikatu SOAP musi się znaleźć element Fault. Przykład dialogu SOAP w HTTP: POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI"

<SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 2.5. Użycie protokołu SOAP w celu zdalnego wywoływania procedur (RPC) Jednym z celów projektowych SOAP było umożliwienie transportowania za jego pomocą wywołań i odpowiedzi RPC. Choć nie jest to jedyne rozwiązanie, jednak naturalne staje się zastosowanie jako protokołu transportującego HTTP, gdzie wywołanie HTTP staje się wywołaniem zdalnej procedury, natomiast odpowiedź HTTP reprezentuje odpowiedź RPC. Reprezentacja RPC opisana w specyfikacji protokołu SOAP zakłada, że dane niezbędne do wywołania procedury (URI obiektu docelowego, nazwa metody, opcjonalna sygnatura metody i parametry metody) przekazywane są jako struktura (złożony typ danych) wewnątrz ciała komunikatu SOAP. Oczywiście nie jest to jedyna możliwość. 2.6. Wady i zalety SOAP Do zalet można zaliczyć: niezwykłą elastyczność protokołu, który pozwala przenosić właściwie dowolne informacje;

możliwość definiowania struktury i semantyki przenoszonych informacji; możliwość łączenia z różnymi protokołami transportowymi (np. HTTP); możliwość realizacji różnych scenariuszy komunikacji; akceptowalność protokołu przez właściwie wszystkie systemy komputerowe i środowiska systemowe; niezawodność protokołu dzięki ścisłemu zdefiniowaniu sytuacji wystąpienia błędu oraz zachowania aplikacji w takich okolicznościach. Niewątpliwe zaś wady to: duży narzut samego języka XML (rozmiar komunikatu jest znacząco większy niż sumaryczny rozmiar danych w nim zawartych); jest jeszcze dość młodym protokołem, podlega rozwojowi i modyfikacjom (chociaż jest już dość dobrze i ściśle zdefiniowany). 3. Protokół WSDL 3.1. Do czego służy WSDL WSDL (Web Services Description Language) to wypromowany przez IBM i Aribę, oparty na XML prosty język pozwalający opisać usługę sieciową - jej sposób wywołania, parametry i formaty wyników, lecz bez żadnych informacji biznesowych czy parametrów dostępności. Dzięki WSDL mamy informacje jakie metody udostępnia Web Service. Do tej pory chcąc skorzystać z komponentów, musieliśmy otrzymać od dostawcy opis techniczny i pliki nagłówkowe, co nie zawsze było możliwe. Rozwiązanie tu zastosowane jest bardzo eleganckie. Usługę można odpytać, jakie funkcje udostępnia. Wystarczy, że w URL wpiszemy: http://localhost/service1.asmx?wsdl W odpowiedzi otrzymamy dokument w formacie WSDL. WSDL jest nadzbiorem języka SDL (i innych), umożliwia twórcom usługi Web opisanie w zrozumiałym formacie co potrafi usługa, gdzie się znajduje i jak ją wywołać. W przeszłości różni producenci wykorzystywali różne schematy. Język WSDL jest standardowym formatem opisu sieciowych usług XML. Język WSDL bazuje na standardzie XML. Jego zadaniem jest tworzenie opisu funkcji usług Web Services oraz sposobu ich wywoływania. Język WSDL jest przydatny przy automatyzacji komunikacji pomiędzy usługami Web Services, umożliwiając współdziałanie usług. Opracowanie dotyczące WSDL oparte jest na informacjach umieszczonych na stronie

http://www.w3.org/. 3.2. Elementy protokołu WSDL (struktura dokumentu WSDL) Dokument WSDL definiuje usługi (services) jako kolekcje punktów końcowych lub portów. Występuje tu abstrakcyjne (niezależne od stosowanej technologii) definiowanie punktów końcowych, przesyłanych wiadomości, formatu danych, operacji. W protokole WSDL można wyróżnić następujące elementy: Komunikat (znacznik <message>) o Abstrakcyjna definicja formatu danych pojedynczej transmisji Typ portu (znacznik <porttype>) o Grupuje komunikaty wg wykonywanych operacji Wiązanie (znacznik <binding>) o Określa konkretny protokół, łączy typ portu z implementacją (zwykle SOAP) Usługa (znacznik <service>) o Definiuje fizyczną lokalizację punktu końcowego Schemat danych (znacznik <types>) o Dostarcza definicji typów danych używanych do opisu wiadomości, opis (niskiego poziomu) parametrów komunikatu WSDL nie wprowadza nowego języka definicji typu. Rozpoznaje jedynie typy w opisywanym formacie wiadomości i wspiera specyfikację XML Schema. WSDL definiuje również wspólny binding mechanism. Jest on używany do dołączania właściwego protokołu lub formatu danych lub struktury do abstrakcyjnej wiadomości, operacji czy punktu końcowego. Struktura dokumentu WSDL jest następująca: Sekcja <definitions> - zawiera definicję usługi (zwykle plik WSDL opisuje jedną usługę). Po znaczniku <definitions> występują następujące deklaracje atrybutów: name: - opcjonalny atrybut informujący w sposób ogólny o przeznaczeniu usługi; targetnamespace: - definiuje logiczną przestrzeń nazw dla informacji o usłudze; xmlns:tns: - jeżeli występuje, to ustawiana jest na wartość targetnamespace; xmlns:soap i xmlns:xsd: - standardowe definicje przestrzeni nazw; xmlns: - domyślna przestrzeń nazw dokumentu WSDL ustawiana jest na http://schemas.xmlsoap.org/wsdl/ Wewnątrz sekcji <definitions> występują trzy sekcje konceptualne (pojęciowe):

<message> i <porttype>: - określają, jakie operacje dostarcza usługa; <binding>: - określa, jak są wywoływane operacje; <service>: - określa, gdzie jest ulokowana usługa. Dodatkowo w opcjonalnej sekcji <types>, położonej bezpośrednio przed sekcją <message>, muszą być zdefiniowane wszystkie typy złożonych danych, wykorzystywanych przez usługę. Można powiedzieć, że usługi są definiowane przy użyciu sześciu sekcji: <types> - opcjonalna sekcja, położona bezpośrednio przed sekcją <message>, tu muszą być zdefiniowane wszystkie typy złożonych danych, wykorzystywanych przez usługę. Składnia: <definitions... > <types> <xsd:schema... />* </types> </definitions> <message> - odnosi się do pojedynczego fragmentu informacji przekazywanego pomiędzy programem wywołującym oraz usługą. Sekcja ta może mieć zero lub więcej części, a każda z nich może mieć nazwę i opcjonalny typ. Te części są wydzielone logicznie każda z nich jest powiązana z typem systemu. Gdy plik WSDL opisuje obiekt, każda z części jest odwzorowywana na argument wywołania metody. Gdy metoda zwraca wartość void - odpowiedzią jest pusty komunikat. Wiadomość może mieć różne atrybuty. Składnia: <definitions... > <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions> <porttype> - grupuje komunikaty według wykonywanych operacji Składnia: <wsdl:definitions... > <wsdl:porttype name="nmtoken"> <wsdl:operation name="nmtoken"... /> * </wsdl:porttype> </wsdl:definitions>

<operation> - definiuje konkretną sekwencję komunikatu wejścia/wyjścia. Atrybut komunikatu każdego wejścia/wyjścia musi odpowiadać nazwie komunikatu <message>, która została zdefiniowana wcześniej. Gdy WSDL opisuje obiekt, każda <operation> jest odwzorowywana na metodę, a każdy <porttype> na interfejs lub klasę Javy. Składnia: <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:porttype > </wsdl:definitions> <binding> - odpowiada zaimplementowanemu <porttype>, wykorzystując indywidualny protokół (np. SOAP lub CORBA). Atrybut typu łączenia musi odpowiadać nazwie wcześniej zdefiniowanego <porttype>. Ponieważ język WSDL jest niezależny od protokołu, można określić połączenia m.in. dla takich standardowych protokołów, jak DCOM, SOAP czy CORBA. Jeżeli usługa wspiera więcej niż jeden protokół, to plik WSDL powinien zawierać konceptualną sekcję <binding> dla każdego z nich. Składnia: <wsdl:definitions... > <wsdl:binding name="nmtoken" type="qname"> * <-- extensibility element (1) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element (2) --> * <wsdl:input name="nmtoken"? >? <-- extensibility element (3) --> </wsdl:input> <wsdl:output name="nmtoken"? >? <-- extensibility element (4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element (5) --> * </wsdl:fault> </wsdl:operation> </wsdl:binding> </wsdl:definitions>

<service> - jest modelowana jako zbiór portów, gdzie <port> reprezentuje dostępność konkretnego połączenia (binding) w określonym punkcie końcowym (węźle). Atrybut połączenia portu musi się odnosić do nazwy wcześniej zdefiniowanego połączenia <binding>. Składnia: <wsdl:definitions... > <wsdl:service... > * <wsdl:port name="nmtoken" binding="qname"> * <-- extensibility element (1) --> </wsdl:port> </wsdl:service> </wsdl:definitions> Każdy element pliku WSDL może deklarować opcjonalny komponent <documentation>, który zawiera przeznaczoną dla użytkownika informację opisową. 3.3. Przykłady praktyczne zastosowania WSDL Komunikaty i typy portów: <message name= Add > <part name= n1 type= short > <part name= n2 type= short > </message> <message name= AddResponse > <part name= n1 type= short > <part name= n2 type= short > <part name= Result type= double > </message> <porttype name= CalcPortType > <operation name= Add parameterorder= AddInOut1 AddInOut2 > <input message= Add /> <output message= AddResponse /> </operation> </porttype> Wiązania i usługi <binding name= CalcBinding type= CalcPortType > <soap:binding style= document transport= http://schemas.xmlsoap.org/soap/http /> <operation name= Add > <soap:operation soapaction= http://localhost/webcalculator.asmx/>

<input> <soap:body.../> </input> <output> <soap:body.../> </output> </operation> </binding> <service name= Calc > <port name= CalcPortType binding= CalcBinding > <soap:address location= http://localhost/webcalculator.asmx /> </port> </service> Metody GET I POST zwracające GIF lub JPG <definitions... > <message name="m1"> <part name="part1" type="xsd:string"/> <part name="part2" type="xsd:int"/> <part name="part3" type="xsd:string"/> </message> <message name="m2"> <part name="image" type="xsd:binary"/> </message> <porttype name="pt1"> <operation name="o1"> <input message="tns:m1"/> <output message="tns:m2"/> </operation> </porttype> <service name="service1"> <port name="port1" binding="tns:b1"> <http:address location="http://example.com/"/> </port> <port name="port2" binding="tns:b2"> <http:address location="http://example.com/"/> </port> <port name="port3" binding="tns:b3">

<http:address location="http://example.com/"/> </port> </service> <binding name="b1" type="pt1"> <http:binding verb="get"/> <operation name="o1"> <http:operation location="o1/a(part1)b(part2)/(part3)"/> <input> <http:urlreplacement/> </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output> </operation> </binding> <binding name="b2" type="pt1"> <http:binding verb="get"/> <operation name="o1"> <http:operation location="o1"/> <input> <http:urlencoded/> </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output> </operation> </binding> <binding name="b3" type="pt1"> <http:binding verb="post"/> <operation name="o1"> <http:operation location="o1"/> <input> <mime:content type="application/x-www-form-urlencoded"/> </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output>

</operation> </binding> </definitions> Żądanie/Odpowiedź w HTML z wykorzystaniem SOAP (usługa wspiera pojedynczą operację GetLastTradePrice) <?xml version="1.0"?> <definitions name="stockquote" targetnamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetnamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/xmlschema"> <element name="tradepricerequest"> <complextype> <all> <element name="tickersymbol" type="string"/> </all> </complextype> </element> <element name="tradeprice"> <complextype> <all> <element name="price" type="float"/> </all> </complextype> </element> </schema> </types> <message name="getlasttradepriceinput"> <part name="body" element="xsd1:tradepricerequest"/> </message> <message name="getlasttradepriceoutput"> <part name="body" element="xsd1:tradeprice"/>

</message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> <input message="tns:getlasttradepriceinput"/> <output message="tns:getlasttradepriceoutput"/> </operation> </porttype> <binding name="stockquotesoapbinding" type="tns:stockquoteporttype"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getlasttradeprice"> <soap:operation soapaction="http://example.com/getlasttradeprice"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="stockquoteservice"> <documentation>my first service</documentation> <port name="stockquoteport" binding="tns:stockquotebinding"> <soap:address location="http://example.com/stockquote"/> </port> </service> </definitions> 3.4. Wady i zalety stosowania WSDL Zalety stosowania WSDL: standardowy format opisu usług możliwość wykorzystania w wielu różnych technologiach i systemach komputerowych zrozumiały interfejs wykorzystywany przy definiowaniu usług

łatwy w użyciu automatyzacja komunikacji między usługami szybsze udostępnianie i aktualizacja oprogramowania W przyszłości narzędzia WSDL umożliwią generowanie kodu w Javie, C/C++, Corba, IDL, EJB, COM, COM, SOAP/HTTP i SOAP przez e-mail i zapewnią realizację dowolnego rodzaju przyłączy. Kod będzie generowany zarówno po stronie serwera, jak i klienta. Serwisy WWW już teraz dają możliwość uaktywnienia przyłącza. Do wad można zaliczyć: problemy z bezpieczeństwem (to dodatkowy protokół obsługi, który trzeba zabezpieczyć) problemy z autoryzacją niezbyt duża wydajność jest jeszcze dość młodym protokołem, podlega rozwojowi i zmianom Problemy związane z zapewnieniem bezpieczeństwa to największa przeszkoda w komercyjnym wykorzystaniu usług sieciowych. WSDL to kolejna warstwa pośrednia, która wymaga odpowiednich zabezpieczeń. Więcej warstw oznacza więcej możliwości dla hakerów. Język WSDL jest przydatny, jeśli wiadomo jaka usługa Web Service jest potrzebna. Nie umożliwia natomiast odnajdowania i przeszukiwania usług. Do tego służą inne protokoły. Nie jest to zbyt wygodne (konieczne zapewnienie współpracy między protokołami). 4. Protokół UDDI 4.1. Do czego służy UDDI Głównym zadaniem UDDI (The Universal Description, Discovery and Integration) jest stworzenie niezależnego od platformy, otwartego rozwiązania do odnajdywania usług sieciowych. UDDI to globalny rejestr usług udostępniający klientom mechanizmy dynamicznego wyszukiwania innych usług Web. UDDI stanowi interfejs umożliwiający dynamiczne połączenie się z usługą udostępnianą przez innego usługodawcę. Projekt UDDI często określany jako DNS dla biznesu. UDDI jest bowiem usługą katalogową przechowującą opisy i lokalizacje Web Services zarejestrowanych przez dostawców. Wyszukiwanie usług jest podobne do działania wyszukiwarek internetowych. UDDI posiadają dwa rodzaje klientów:

usługodawców publikujących swoje usługi klientów pragnących skorzystać z tych usług. Projekt UDDI wykorzystuje standardy W3C (WorldWide Web Consorcium) oraz IETF (Internet Engineering Task Force), takie jak: XML (Extensible Markup Language), protokoły HTTP oraz DNS (Domain Name System). Warstwa UDDI leży nad protokołem SOAP, przez co komunikaty UDDI stanowią obiekty w komunikatach SOAP. Usługi opisywane są przez WSDL. Projekt UDDI promują m.in. Ariba, IBM, Intel, Microsoft, SAP i Sun, lecz nie ma on jeszcze własnej grupy roboczej w W3C (World Wide Web Consorcium). UDDI nie jest związany z WSDL czy ebxml, ale w jego katalogach opisuje się najczęściej usługi oparte na WSDL. Publiczne katalogi UDDI udostępniły m.in. firmy Microsoft, IBM i XMethods. Opracowanie dotyczące UDDI oparte jest na informacjach umieszczonych na stronie http://uddi.org/. 4.2. Elementy protokołu UDDI W UDDI istotna jest kategoryzacja firm - musi ona umożliwiać wyszukanie firmy o ściśle określonym profilu działalności. Specyfikacja UDDI opisuje również sposób wymiany danych pomiędzy serwerami, które mogą tworzyć sieć węzłów. Rejestry UDDI zawierają: informacje o webservices na bazie nazwy usługodawcy, jego adresu, kategorii biznesowej czy informacji technicznej itp., operacje dotyczące usługi Web tj. rejestracji, wyszukiwania i korzystania z usługi szczegóły udostępniane przez niskopoziomowe API W UDDI informacje zawarte są w czterech różnych strukturach, zapewniających funkcjonalność: businessentity struktura umożliwiająca wyszukiwanie według biznesu businessservice struktura umożliwiająca wyszukiwanie według usługi biznesowej bindingtemplate struktura umożliwiająca wyszukiwanie według wiązania tmodel struktura umożliwiająca wyszukiwanie według usługi Web Services W UDDI wykorzystuje się model zapytania drążącego: Wykorzystanie zapytań find_x w celu uzyskania ogólnych informacji xlists Uzyskanie szczegółów przy pomocy zapytania get_xdetail

4.3. Przykład zastosowania UDDI W Polsce testowy katalog UDDI uruchomiła firma T-Systems na wortalu technologicznym http://www.e-kompas.pl/, który udostępnia też testowe usługi sieciowe i aplikacje pokazujące sposób działania tej technologii. Istnieje już kilka rozwiązań, również open source, pozwalających na uruchomienie własnego węzła UDDI. Z reguły implementacje katalogów UDDI oferują dostęp zarówno przez strony WWW, jak i przez protokół SOAP - dzięki temu przyszłe systemy będą mogły automatycznie wyszukiwać potrzebne im usługi. Pojedynczy wpis w repozytorium UDDI dostępnym w wortalu e-kompas.pl zawiera trzy poziomy informacji: nazwę firmy, jej podstawowe dane adresowe kategorię spis usług biznesowych udostępnianych przez jej systemy wraz z ich definicją Dzięki istniejącym już repozytoriom UDDI i Web Services już dziś można uzyskać rozkłady lotów, notowania giełdowe czy najnowsze wiadomości w sposób umożliwiający automatyczne wykorzystywanie przez własne oprogramowanie. Docelowym zastosowaniem UDDI ma być tworzenie otwartych lub zamkniętych e-marketplace, udostępnianie partnerom biznesowym informacji i procesów dla ich systemów czy integracja systemów wewnątrz przedsiębiorstwa. 4.4. Wady i zalety stosowania UDDI UDDI jest rozległą inicjatywą umożliwiającą systemom biznesowym odkrywanie siebie nawzajem oraz definiowanie sposobów interakcji poprzez Internet. Standard UDDI definiuje również sposoby replikacji pomiędzy repozytoriami. Obsługa UDDI powinna być integralną częścią systemów biznesowych, dzięki czemu będą one potrafiły łatwo, w sposób dynamiczny i przede wszystkim szybko, znaleźć inne systemy i współdziałać z nimi. 5. Zakończenie 5.1. Współpraca protokołów SOAP, WSDL i UDDI Protokół SOAP umożliwia wywoływanie i wykonywanie usług Web Services, publikowanych za pomocą WSDL i wyszukiwanych za pośrednictwem rejestru UDDI. Wykorzystywanie protokołu SOAP do wywoływania i wykonywania aplikacji poprzez Internet i korporacyjne zapory ogniowe umożliwia przedsiębiorstwom bezpieczną integrację własnych procesów biznesowych z procesami partnerów i dostawców.

Korzystanie z usług przebiega w następujący sposób: dostarczyciele usług - rejestrują się u pośredników (UDDI). klient - pyta pośrednika, kto mu da daną usługę. (SOAP). pośrednik (broker) - lokalizuje mu tę usługę i podaje opis jej użycia (WSDL). klient podłącza się do dostarczyciela i korzysta z usługi (SOAP) PRZYKŁAD: Wymiana usług WWW pomiędzy dwiema aplikacjami może wyglądać następująco: 1. Przedsiębiorstwo A opisuje swoją usługę WWW poprzez WSDL; usługa jest rejestrowana w UDDI. 2. Przedsiębiorstwo B, chcące skorzystać z usługi, sięga do definicji WSDL, znajduje ją poprzez klienta SOAP w UDDI i pobiera w postaci pliku XML. Na koniec generuje komunikat SOAP. 3. Serwer SOAP przetwarza otrzymany plik XML i kieruje do "zainteresowanej" aplikacji. 5.2. Bezpieczeństwo Web Services Problemy z bezpieczeństwem jest to największa przeszkoda w komercyjnym wykorzystaniu usług sieciowych. Usługi sieciowe wprowadzają bowiem trzy lub cztery dodatkowe warstwy pośrednie, które wymagają odpowiednich zabezpieczeń. Więcej warstw oznacza więcej możliwości dla hakerów. Jako rozwiązanie tego problemu proponuje się stworzenie pojedynczego standardu. Taką próbą jest Microsoft.NET Passport. Najbardziej istotnym elementem bezpieczeństwa jest identyfikacja użytkownika, bowiem

udostępniając usługi w Internecie, zezwalamy na korzystanie z nich w dowolny sposób. Aby ograniczyć dostęp do konkretnych usług, wystarczy zastosować kod (np. w postaci parametru wywołania usługi) umożliwiający dostęp tylko autoryzowanemu użytkownikowi. Bezpieczeństwo transmisji zapewnia SSL użyty w niższych warstwach protokołu. W przypadku powszechnie dostępnych usług, gdy nie ma możliwości przekazania kodu dostępu, konieczne jest zastosowanie innych metod uwierzytelniających. Microsoft stara się narzucić usługę autoryzacyjną MS Passport, która jest kluczowym elementem platformy.net My Services. Zasadność powierzenia bazy informacji o użytkownikach jednej, komercyjnej firmie podważa Sun - firma ta powołała do życia konkurencyjny projekt The Liberty Alliance, zrzeszający: Apache Software Group, NTT DoCoMo, Bank of America, ebay, Real Networks, Nokia i RSA Security. Obie koncepcje dążą do zbudowania bazy informacji o użytkownikach Sieci, ich danych osobowych i preferencjach. Projekty te są jeszcze mało zaawansowane, trudno więc w tej chwili ocenić ich przydatność dla usług sieciowych. Przy nawiązywaniu kontaktów biznesowych ważną rolę spełnią inicjatywy w rodzaju Identrus - organizacji zrzeszającej grupę dużych banków, m.in. Bank of America, Barclays, Chase Manhattan, Citigroup, Deutsche Bank i mającej poparcie wielu producentów oprogramowania. Identyfikator Identrus Global ID umożliwia globalną identyfikację firmy za pomocą klucza publicznego (PKI) i uwiarygodnianie jej jako kontrahenta. Dzięki temu można elektronicznie tworzyć bezpieczne, otwarte rynki i poważnie angażować się w integrację B2B o zasięgu globalnym. Standard ebxml jako podstawa integracji B2B zwiększa bezpieczeństwo takiego rozwiązania, ponieważ wymaga na przykład podpisania przez przedstawicieli firm umowy o integracji systemów. 5.3. Przyszłość Web Services Jeżeli chodzi o przyszłość usług sieciowych, to jest to jedna z metod pozwalająca na szybsze udostępnianie i aktualizację oprogramowania. Web Services komunikują się wykorzystując HTTP oraz XML. Dowolne urządzenie lub system obsługujący te popularne standardy może utrzymywać takie usługi oraz udostępniać je. Można się spodziewać, że już niedługo Web Services będą powszechnie implementowane także w samochodach, automatach ulicznych, czy choćby komórkach. Przy wystąpieniu określonego zdarzenia, np. wyczerpaniu zapasu puszek w automacie z napojami, ulokowana w nim usługa skontaktuje się z usługą czuwającą w firmie odpowiedzialnej za dostarczanie napojów do automatów. Architektura Web Services nie jest jeszcze kompletna. Jednym z istotnych problemów jest potrzeba zwiększenia wydajności tej technologii.

Firmy IBM, Microsoft i Ariba implementują dla usług Web Services publiczny globalny rejestr UBR (Universal Business Registry). Ma on służyć jako centralne repozytorium i obejmować wszystkie (niezależnie od wielkości) firmy, które chcą zarejestrować swoją działalność oraz poszukują produktów lub usług oferowanych przez inne podmioty. UBR umożliwi publikację usług Web Services poprzez proste wypełnienie dostępnego on-line formularza. Po rozpowszechnieniu usług Web Services rejestr UBR ma pomagać przedsiębiorstwom we wzajemnej lokalizacji oraz przekazywaniu informacji o ofertach. W planach firmy IBM jest zbudowanie kompletnego środowiska Application Framework for Web Services. Trwają dalsze prace rozwojowe nad standardem, dotyczące przede wszystkim dynamicznego wyszukiwania usług podczas pracy aplikacji. Inne prace koncentrują się na umożliwieniu wykorzystania w technologii Web Services także języków skryptowych, takich jak JavaScript czy REXX. W tym celu musi być, między innymi, zmodyfikowana specyfikacja SOAP. Na świecie koncepcja usług Web Services jest w ostatnim czasie szeroko promowana i spotyka się z coraz większym zainteresowaniem. Czołowe firmy oferują za darmo zestawy narzędzi, które pozwalają programistom szybko budować oraz implementować Web Services. Możliwe jest też przekształcanie istniejących komponentów (np. COM czy JavaBeans) w usługi Web Services. Na nowej technologii usług internetowych bazuje platforma Microsoft.NET, natomiast IBM rozwija nieodpłatne narzędzia w kategorii Alphaworks. Już teraz komponenty napisane w Visual Basicu mogą być łatwo wdrożone jako Web Services, a następnie bez przeszkód wywoływane przez usługi zbudowane np. z wykorzystaniem technologii VisualAge firmy IBM. W przyszłości usługi Web Services będą zapewne powszechnie stosowane do przekazywania informacji biznesowych (np. wyników notowań giełdowych) partnerom i klientom, integracji z zapewnieniem pracy transakcyjnej w takich zastosowaniach, jak obsługa giełd i systemy rezerwacji, czy nawet do decentralizacji i przenoszenia procesów biznesowych na zewnątrz przedsiębiorstwa. W tym ostatnim wypadku usługi Web Services będą wykorzystywane do swobodnej, dynamicznej integracji między procesami należącymi do różnych podmiotów gospodarczych. Można sobie też wyobrazić, że w przyszłości aplikacje biznesowe klasy B2B, pracujące w Internecie, będą budowane z usług Web Services wybieranych dynamicznie podczas realizacji procedur biznesowych, z uwzględnieniem dostępności, kosztów czy funkcjonalności (jakości). Literatura John Paul Mueller "Poznaj SOAP" Wydawnictwo Mikom 2002 http://www.w3.org/ http://uddi.org/