AAkkaaddeemmiiaa GGóórrnniicczzoo �� HHuuttnniicczzaa

iimm.. SStt.. SSttaasszziiccaa ww KKrraakkoowwiiee

WWyyddzziiaałł EEAAIIiiEE

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

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�;

Koperta SOAP

Nagłówek SOAP

wpis1 wpis2

�

Ciało SOAP

element1 element2

�

• 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/