AAkkaaddeemmiiaa GGrrnniicczzoo HHuuttnniicczzaa

iimm.. SStt.. SSttaasszziiccaa ww KKrraakkoowwiiee

WWyyddzziiaa EEAAIIiiEE

Referat z programowania systemowego

Przegld protokow do realizacji usug sieciowych SOAP, WSDL, UDDI

Jacek Midura

Marcin Klimek Studia dzienne

Rok 5 Informatyki Rok akademicki 2002/2003

Spis treci 1. Wprowadzenie ...................................................................................... 3

1.1. Oglny opis - webservices ...................................................................................................3 1.2. Wstpne zarysowanie obszarw zastosowa SOAP, WSDL i UDDI..................................3

2. Protok SOAP...................................................................................... 4 2.1. Oglna charakterystyka protokou SOAP, relacja pomidzy XML a SOAP.......................4 2.2. Model komunikacji...............................................................................................................5 2.3. Struktura komunikatu SOAP................................................................................................6

2.3.1. Koperta SOAP..............................................................................................................6 2.3.2. Nagwek SOAP ..........................................................................................................7 2.3.3. Ciao SOAP ..................................................................................................................7 2.3.4. Kodowanie danych w komunikatach SOAP ................................................................8

2.4. Transmisja komunikatw SOAP protokoem HTTP............................................................9 2.5. Uycie protokou SOAP w celu zdalnego wywoywania procedur (RPC) ........................10 2.6. Wady i zalety SOAP...........................................................................................................10

3. Protok WSDL ..................................................................................11 3.1. Do czego suy WSDL.......................................................................................................11 3.2. Elementy protokou WSDL (struktura dokumentu WSDL)...............................................12 3.3. Przykady praktyczne zastosowania WSDL.......................................................................15 3.4. Wady i zalety stosowania WSDL.......................................................................................19

4. Protok UDDI .................................................................................... 20 4.1. Do czego suy UDDI ........................................................................................................20 4.2. Elementy protokou UDDI .................................................................................................21 4.3. Przykad zastosowania UDDI ............................................................................................22 4.4. Wady i zalety stosowania UDDI ........................................................................................22

5. Zakoczenie......................................................................................... 22 5.1. Wsppraca protokow SOAP, WSDL i UDDI................................................................22 5.2. Bezpieczestwo Web Services...........................................................................................23 5.3. Przyszo Web Services....................................................................................................24

1. Wprowadzenie

1.1. Oglny opis - webservices

Pod terminem Usugi Web naley rozumie zbir maych funkcjonalnych klockw pracujcych w

sieci i udostpniajcych okrelone usugi innym systemom czy te innym webservices. Takimi

klockami mog by np. usugi pogodowe, translatory jzykowe czy mechanizmy przeliczajce

waluty, a wykorzystywane mog by przez inne usugi udostpniajce usugi bardziej zoone.

Naley pamita, e webservices zwykle nie bd stanowi samodzielnych aplikacji, a jedynie

stanowi interfejs komunikacyjny pomidzy klientami z sieci a systemami biznesowymi.

Tim Bray, wsptwrca XML, definiuje usugi sieciowe jako standardowy interfejs, ktry pozwala

jednej aplikacji programowo odkry, zinterpretowa i wykorzysta usugi oferowane przez inne

platformy aplikacyjne bd systemy operacyjne, w sposb niezaleny od wykorzystywanego przez

nie jzyka programowania.

Wyjtkow si webservices jest wykorzystanie istniejcych i szeroko stosowanych technologii tj.

protokou HTTP i jzyka XML. HTTP jest jednym z najbardziej rozpowszechnionych protokow

w sieci WEB, co umoliwia natychmiastowe wykorzystanie tej platformy do przesyania

komunikatw. XML dostarcza metajzyk za pomoc ktrego porozumiewaj si klienci z usugami

oraz poszczeglne komponenty. Idc dalej, przy budowie i wykorzystaniu webservices nie ma

znaczenia w jakiej technologii jest napisana usuga, na jakim systemie operacyjnym pracuje. Pen

interoperatywno zapewnia protok SOAP, ktry ma aspiracje sta si nastpc technik typu

CORBA, RMI czy DCOM.

Dziki wykorzystywaniu nowego protokou SOAP usuga opracowana w technologii Web Services

ma moliwo wsppracy (wymiany komunikatw) z dowoln inn usug. Powinny znikn

problemy wystpujce przy konwersjach realizowanych pomidzy protokoami architektur DCOM i

CORBA. Web Services mog by pisane w dowolnych jzykach programowania, wic twrcy

aplikacji bd mogli pisa usugi bez zmiany rodowiska tworzenia aplikacji, w ktrym wczeniej

pracowali. Protok SOAP jest obecnie wspierany przez wszystkich podstawowych dostawcw

systemw oraz oprogramowania narzdziowego.

1.2. Wstpne zarysowanie obszarw zastosowa SOAP, WSDL i UDDI

W celu umoliwienia komunikacji midzy aplikacjami rozproszonymi w sieci, naley opracowa

jaki standard formatowania i przesyania informacji. Wiele takich protokow zostao ju

zaproponowanych w przeszoci, z czego niektre uzyskay status standardu, a inne byy rozwijane

przez pojedyncze firmy dla wasnych produktw. Wikszo z nich ma jednak ograniczone

zastosowanie w budowaniu wielkich, rozproszonych aplikacji w skali Internetu, ze wzgldu na ich

rne wymogi lub ograniczenia dotyczce platformy, producenta, czy te moliwoci

komunikacyjnych.

Otwarto i rozszerzalno jzykw opartych na XML zostaa szeroko uznana jako rozwizanie dla

nowoczesnych protokow komunikacji sieciowej. Nie znaczy to bynajmniej, e XML powinien

by stosowany w kadej sytuacji. W rzeczywistoci stosowanie XML-a moe by niekiedy

wykluczone w systemach wymagajcych maksymalnej wydajnoci, poniewa jego skadnia jest

bardzo 'rozrzutna', gdy porwna objto waciwej informacji zawartej w dokumencie do jego

caej objtoci wraz ze znacznikami. Jednak dla wielu aplikacji e-biznesowych otwarto i

rozszerzalno dialektw XML-a s ogromnymi zaletami zarwno przy zapisie treci, jak i

struktury komunikatw. Wydaje si, e protokoy komunikacji wykorzystujce XML najlepiej

sprawdzaj si w integracji prowadzonej nie w czasie rzeczywistym, co ma czsto miejsce w

systemach B2B.

2. Protok SOAP

2.1. Oglna charakterystyka protokou SOAP, relacja pomidzy XML a SOAP

SOAP Simple Object Access Protocol (Prosty Protok Dostpu do Obiektw).

Czym jest SOAP:

jest protokoem, a zatem mechanizmem transportu informacji;

przenoszone informacje s uporzdkowane (posiadaj struktur i typy);

dane zapisane s w jzyku rozszerzalnych znacznikw (XML);

w tym protokole mona przenosi wszelkiego rodzaju dane (w razie potrzeby s one kodowane

do postaci wyraalnej w XML);

SOAP posiada bardzo szeroki zakres zastosowa: od prostych zastosowa komunikacyjnych po

zdalne wywoywanie procedur (RPC).

Czym nie jest SOAP:

nie jest tym samym, co XML, chocia jest na nim oparty;

nie ma zwizku z protokoami SMTP czy HTTP, chocia komunikaty SOAP czsto s

przesyane z wykorzystaniem mechanizmw typowych dla tych protokow (np. transmitowane

przez TCP/IP na portach 25 lub 80, czsto spotyka si rwnie enkapsulowanie wewntrz

komunikatw SMTP lub HTTP);

nie jest zwizany z adnym konkretnym modelem programowania czy jak specyfik

implementacji przeciwnie: jest uniwersalnym sposobem komunikacji w rodowiskach

rozproszonych oraz heterogenicznych.

Organizacja XML Protocol Working Group dziaajca w ramach W3C opracowaa dokument pod

tytuem XML Protocol Abstract Model, ktry zawiera rozwaania na temat cech dobrego protokou

komunikacyjnego opartego na XML i moe stanowi podstaw oceny jakoci konkretnych

implementacji. Dokument ten powsta 9 lipca 2001 i ma status W3C Working Draft.

Oto podstawowe zalecenia dotyczce budowy protokou XML-owego zawarte w tej pracy:

Naley dopuszcza moliwo wykorzystania rnych protokow transportu (np. HTTP,

SMTP i in.)

Komunikacja moe zachodzi wedle rnych schematw: wysanie pojedynczego

komunikatu, zapytanie/ odpowied, wymiana duszej sekwencji komunikatw

Poredniczce hosty mog zmienia komunikat

API protokou powinno zapewnia operacje wysania, odebrania, przesania dalej i

sprawdzenia statusu komunikatu

Naley zadba o obsug bdw poczenia

Trzeba umoliwi transport dowolnych zacznikw do komunikatw w XML

Obecnie trwaj prace nad dostosowaniem specyfikacji protokou SOAP 1.2 do tego modelu

abstrakcyjnego (w tej chwili obowizujca wersja nosi numer 1.1). Jako baza niniejszego

opracowania wykorzystana zostaa specyfikacja SOAP wersji 1.1 opracowana przez W3C,

znajdujca si pod adresem http://www.w3.org/TR/2000/NOTE-SOAP-20000508

Wrd wielu opracowywanych aktualnie protokow bazujcych na XML-u, SOAP wyrnia si

najszersz akceptacj duych producentw oprogramowania.

2.2. Model komunikacji

Komunikacja za pomoc SOAP jest zasadniczo komunikacj jednokierunkow: od nadawcy do

odbiorcy. atwo sobie jednak wyobrazi inne scenariusze bazujce na tym podstawowym: np.

schemat wywoanie odpowied (request response) lub dialog dwch stron.

Wybrana do przenoszenia komunikatw warstwa transportowa moe uatwia budowanie takich

bardziej rozbudowanych scenariuszy, np. przy czeniu za pomoc TCP/IP po przesaniu

komunikatu nadawca z odbiorc zamieniaj si rolami, a odpowied jest transmitowana tym samym

poczeniem, ktrym poszo wywoanie.

http://www.w3.org/2000/xp/Group/http://www.w3.org/http://www.w3.org/TR/xmlp-am/http://www.w3.org/TR/2000/NOTE-SOAP-20000508

2.3. Struktura komunikatu SOAP

Komunikat SOAP jest dokumentem XML, ktry skada si z trzech elementw:

1.koperty SOAP (SOAP envelope) obowizkowo

2.nagwka SOAP (SOAP header) niekoniecznie

3.ciaa SOAP (SOAP body) obowizkowo

Przykad:

1

2001-06-22T14:00:00-05:00

Pj na obiad o 14:00

2.3.1. Koperta SOAP

Koperta SOAP jest gwnym, najbardziej zewntrznym elementem dokumentu XML, ktry

reprezentuje komunikat. Odnosz si do niej nastpujce reguy:

nazwa tego elementu musi brzmie Envelope;

Koperta SOAP

Nagwek SOAP

wpis1 wpis2

Ciao SOAP

element1 element2

ten element musi by obecny w komunikacie SOAP;

ten element moe zawiera deklaracje przestrzeni nazw oraz dodatkowe atrybuty.

Specyfikacja SOAP nie zakada przypisywania kopertom tradycyjnych duych i maych numerw

wersji. Komunikat SOAP musi mie natomiast element Envelope poczony z przestrzeni nazw

"http://schemas.xmlsoap.org/soap/envelope/". Jeli jaka aplikacja otrzyma komunikat z inn

przestrzeni nazw w kopercie, ma obowizek zwrci bd.

2.3.2. Nagwek SOAP

Jest on elementem nieobowizkowym. Suy do przekazywania informacji o tym kto i w jaki

sposb powinien przetwarza dane zawarte w ciele komunikatu. Zawarto nagwka moe nie

take informacj dla ogniw poredniczcych w transporcie komunikatu (np. serwerw proxy), moe

by take przez nie zmieniana.

Nastpujce reguy dotycz nagwka:

nazwa tego elementu musi brzmie Header;

jeli ten element wystpuje w komunikacie SOAP, musi by pierwszym bezporednim

potomkiem elementu Envelope;

moe on zawiera wpisy nagwka (header entries), kady bdcy bezporednim

potomkiem elementu Header. Kady wpis musi mie zdefiniowan przestrze nazw.

2.3.3. Ciao SOAP

W tym elemencie przenoszona jest waciwa informacja. Ciao SOAP musi stosowa si do

nastpujcych regu:

nazwa elementu musi brzmie Body;

element ten musi wystpi w komunikacie i musi by bezporednim potomkiem elementu

Envelope;

jeli w komunikacie wystpuje nagwek, to ciao musi nastpowa bezporednio po nim,

w przeciwnym wypadku musi by pierwszym potomkiem elementu Envelope;

ten element moe zawiera seri wpisw, z ktrych kady jest jego bezporednim

potomkiem.

Szczeglnym rodzajem elementu jest element Fault. Suy on do przenoszenia informacji o

bdach. Jeli wystpuje w komunikacie SOAP, musi by wpisem ciaa komunikatu (body entry) i

moe wystpi tylko raz w caym komunikacie. Element Fault posiada cztery podelementy:

faultcode kod bdu (obowizkowy). Schemat kodw jest podobny do uytego w

protokole http (1xx, 2xx, 3xx itd.);

http://schemas.xmlsoap.org/soap/envelope/

faultstring czytelne dla czowieka (nie przeznaczone do przetwarzania maszynowego)

objanienie istoty bdu (obowizkowe);

faultactor URI obiektu, ktry spowodowa bd (obowizkowe, jeli bd powsta na

ktrym z etapw porednich uczestniczcych w przekazywaniu komunikatu,

nieobowizkowe jeli bd powsta u adresata komunikatu);

detail specyficzne informacje dotyczce bdu (obowizkowe, jeli bd powsta przy

przetwarzaniu ciaa komunikatu, zabronione, jeli bd nie powsta przy przetwarzaniu ciaa

komunikatu).

2.3.4. Kodowanie danych w komunikatach SOAP

Kodowanie danych w SOAP wykorzystuje hierarchi typw danych, ktra jest generalizacj

podobnych hierarchii spotykanych we wspczesnych jzykach programowania czy bazach danych.

Najbardziej podstawowy podzia typw to podzia na typy proste (skalarne) oraz na typy zoone,

ktre s poczeniem pewnej liczby czci, z ktrych kada posiada swj typ.

XML dopuszcza bardzo elastyczne kodowanie danych, SOAP w tej dziedzinie jest bardziej

ograniczony (ma cilejsze reguy 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.

Przykad typowania danych:

45

5.9

-450

Blue

Ponadto w SOAP wspierane s nastpujce typy zoone: rekordy i tablice. Przykad:

http://www.w3.org/TR/xmlschema-2/#stringhttp://www.w3.org/TR/xmlschema-2/#booleanhttp://www.w3.org/TR/xmlschema-2/#decimalhttp://www.w3.org/TR/xmlschema-2/#floathttp://www.w3.org/TR/xmlschema-2/#doublehttp://www.w3.org/TR/xmlschema-2/#durationhttp://www.w3.org/TR/xmlschema-2/#dateTimehttp://www.w3.org/TR/xmlschema-2/#timehttp://www.w3.org/TR/xmlschema-2/#datehttp://www.w3.org/TR/xmlschema-2/#gYearMonthhttp://www.w3.org/TR/xmlschema-2/#gYearhttp://www.w3.org/TR/xmlschema-2/#gMonthDayhttp://www.w3.org/TR/xmlschema-2/#gDayhttp://www.w3.org/TR/xmlschema-2/#gMonthhttp://www.w3.org/TR/xmlschema-2/#hexBinaryhttp://www.w3.org/TR/xmlschema-2/#base64Binaryhttp://www.w3.org/TR/xmlschema-2/#anyURIhttp://www.w3.org/TR/xmlschema-2/#QNamehttp://www.w3.org/TR/xmlschema-2/#NOTATION

Henry Ford

Prefatory text

This is a book.

3

4

2.4. Transmisja komunikatw SOAP protokoem HTTP

Bardzo czsto do transportu komunikatw SOAP uywany jest protok HTTP. Przyczyn jest kilka:

jest to protok bardzo elastyczny;

jest zarazem pewny posiada mechanizmy raportowania bdw;

jest niezwykle rozpowszechniony (co wie si z bogactwem narzdzi);

umoliwia przekazywanie komunikatw SOAP nawet przez zapory (firewall) analizujce

zawarto transmitowanego strumienia danych (poniewa zazwyczaj zapory takie

przepuszczaj transmisj HTTP).

Ze wzgldu na charakter protokou HTTP najbardziej naturalne jego wykorzystanie zachodzi

podczas scenariusza transmisji wywoanie odpowied (request response).

Podczas transmisji komunikatw SOAP wewntrz wywoa/odpowiedzi HTTP naley uywa typu

text/xml. Pomimo i SOAP mona powiza z rnymi typami wywoa HTTP, najczciej

jednak jest uywane wywoanie POST.

Odpowiedzi w protokole HTTP musz posiada odpowiedni status (np. 2xx oznaczaj poprawne

odebranie i przetworzenie wywoania). Jeli podczas przetwarzania komunikatu wystpi bd, musi

zosta zwrcona odpowied ze statusem 500 (Internal Server Error), a w ciele zwracanego

komunikatu SOAP musi si znale element Fault.

Przykad 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"

DIS

HTTP/1.1 200 OK

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

34.5

2.5. Uycie protokou SOAP w celu zdalnego wywoywania procedur (RPC)

Jednym z celw projektowych SOAP byo umoliwienie transportowania za jego pomoc wywoa

i odpowiedzi RPC. Cho nie jest to jedyne rozwizanie, jednak naturalne staje si zastosowanie

jako protokou transportujcego HTTP, gdzie wywoanie HTTP staje si wywoaniem zdalnej

procedury, natomiast odpowied HTTP reprezentuje odpowied RPC.

Reprezentacja RPC opisana w specyfikacji protokou SOAP zakada, e dane niezbdne do

wywoania procedury (URI obiektu docelowego, nazwa metody, opcjonalna sygnatura metody i

parametry metody) przekazywane s jako struktura (zoony typ danych) wewntrz ciaa

komunikatu SOAP. Oczywicie nie jest to jedyna moliwo.

2.6. Wady i zalety SOAP

Do zalet mona zaliczy:

niezwyk elastyczno protokou, ktry pozwala przenosi waciwie dowolne informacje;

moliwo definiowania struktury i semantyki przenoszonych informacji;

moliwo czenia z rnymi protokoami transportowymi (np. HTTP);

moliwo realizacji rnych scenariuszy komunikacji;

akceptowalno protokou przez waciwie wszystkie systemy komputerowe i rodowiska

systemowe;

niezawodno protokou dziki cisemu zdefiniowaniu sytuacji wystpienia bdu oraz

zachowania aplikacji w takich okolicznociach.

Niewtpliwe za wady to:

duy narzut samego jzyka XML (rozmiar komunikatu jest znaczco wikszy ni

sumaryczny rozmiar danych w nim zawartych);

jest jeszcze do modym protokoem, podlega rozwojowi i modyfikacjom (chocia jest ju

do dobrze i cile zdefiniowany).

3. Protok WSDL

3.1. Do czego suy WSDL

WSDL (Web Services Description Language) to wypromowany przez IBM i Arib, oparty na XML

prosty jzyk pozwalajcy opisa usug sieciow - jej sposb wywoania, parametry i formaty

wynikw, lecz bez adnych informacji biznesowych czy parametrw dostpnoci.

Dziki WSDL mamy informacje jakie metody udostpnia Web Service. Do tej pory chcc

skorzysta z komponentw, musielimy otrzyma od dostawcy opis techniczny i pliki nagwkowe,

co nie zawsze byo moliwe. Rozwizanie tu zastosowane jest bardzo eleganckie. Usug mona

odpyta, jakie funkcje udostpnia. Wystarczy, e w URL wpiszemy:

http://localhost/service1.asmx?wsdl

W odpowiedzi otrzymamy dokument w formacie WSDL.

WSDL jest nadzbiorem jzyka SDL (i innych), umoliwia twrcom usugi Web opisanie w

zrozumiaym formacie co potrafi usuga, gdzie si znajduje i jak j wywoa. W przeszoci rni

producenci wykorzystywali rne schematy. Jzyk WSDL jest standardowym formatem opisu

sieciowych usug XML.

Jzyk WSDL bazuje na standardzie XML. Jego zadaniem jest tworzenie opisu funkcji usug Web

Services oraz sposobu ich wywoywania. Jzyk WSDL jest przydatny przy automatyzacji

komunikacji pomidzy usugami Web Services, umoliwiajc wspdziaanie usug.

Opracowanie dotyczce WSDL oparte jest na informacjach umieszczonych na stronie

http://localhost/service1.asmx?wsdl

http://www.w3.org/.

3.2. Elementy protokou WSDL (struktura dokumentu WSDL)

Dokument WSDL definiuje usugi (services) jako kolekcje punktw kocowych lub portw.

Wystpuje tu abstrakcyjne (niezalene od stosowanej technologii) definiowanie punktw

kocowych, przesyanych wiadomoci, formatu danych, operacji.

W protokole WSDL mona wyrni nastpujce elementy:

Komunikat (znacznik )

o Abstrakcyjna definicja formatu danych pojedynczej transmisji

Typ portu (znacznik )

o Grupuje komunikaty wg wykonywanych operacji

Wizanie (znacznik )

o Okrela konkretny protok, czy typ portu z implementacj (zwykle SOAP)

Usuga (znacznik )

o Definiuje fizyczn lokalizacj punktu kocowego

Schemat danych (znacznik )

o Dostarcza definicji typw danych uywanych do opisu wiadomoci, opis (niskiego

poziomu) parametrw komunikatu

WSDL nie wprowadza nowego jzyka definicji typu. Rozpoznaje jedynie typy w opisywanym

formacie wiadomoci i wspiera specyfikacj XML Schema. WSDL definiuje rwnie wsplny

binding mechanism. Jest on uywany do doczania waciwego protokou lub formatu danych

lub struktury do abstrakcyjnej wiadomoci, operacji czy punktu kocowego.

Struktura dokumentu WSDL jest nastpujca:

Sekcja - zawiera definicj usugi (zwykle plik WSDL opisuje jedn usug).

Po znaczniku wystpuj nastpujce deklaracje atrybutw:

name: - opcjonalny atrybut informujcy w sposb oglny o przeznaczeniu usugi;

targetNamespace: - definiuje logiczn przestrze nazw dla informacji o usudze;

xmlns:tns: - jeeli wystpuje, to ustawiana jest na warto targetNamespace;

xmlns:soap i xmlns:xsd: - standardowe definicje przestrzeni nazw;

xmlns: - domylna przestrze nazw dokumentu WSDL ustawiana jest na

http://schemas.xmlsoap.org/wsdl/

Wewntrz sekcji wystpuj trzy sekcje konceptualne (pojciowe):

http://www.w3.org/

i : - okrelaj, jakie operacje dostarcza usuga;

: - okrela, jak s wywoywane operacje;

: - okrela, gdzie jest ulokowana usuga.

Dodatkowo w opcjonalnej sekcji , pooonej bezporednio przed sekcj , musz

by zdefiniowane wszystkie typy zoonych danych, wykorzystywanych przez usug.

Mona powiedzie, e usugi s definiowane przy uyciu szeciu sekcji:

- opcjonalna sekcja, pooona bezporednio przed sekcj , tu musz by

zdefiniowane wszystkie typy zoonych danych, wykorzystywanych przez usug.

Skadnia:

*

- odnosi si do pojedynczego fragmentu informacji przekazywanego pomidzy

programem wywoujcym oraz usug. Sekcja ta moe mie zero lub wicej czci, a kada z nich

moe mie nazw i opcjonalny typ. Te czci s wydzielone logicznie kada z nich jest

powizana z typem systemu. Gdy plik WSDL opisuje obiekt, kada z czci jest odwzorowywana

na argument wywoania metody. Gdy metoda zwraca warto void - odpowiedzi jest pusty

komunikat. Wiadomo moe mie rne atrybuty.

Skadnia:

*

*

- grupuje komunikaty wedug wykonywanych operacji

Skadnia:

*

- definiuje konkretn sekwencj komunikatu wejcia/wyjcia. Atrybut komunikatu

kadego wejcia/wyjcia musi odpowiada nazwie komunikatu , ktra zostaa

zdefiniowana wczeniej.

Gdy WSDL opisuje obiekt, kada jest odwzorowywana na metod, a kady

na interfejs lub klas Javy.

Skadnia: *

- odpowiada zaimplementowanemu , wykorzystujc indywidualny protok

(np. SOAP lub CORBA). Atrybut typu czenia musi odpowiada nazwie wczeniej

zdefiniowanego . Poniewa jzyk WSDL jest niezaleny od protokou, mona okreli

poczenia m.in. dla takich standardowych protokow, jak DCOM, SOAP czy CORBA. Jeeli

usuga wspiera wicej ni jeden protok, to plik WSDL powinien zawiera konceptualn sekcj

dla kadego z nich.

Skadnia:

*

*

*

*

?

?

*

*

*

- jest modelowana jako zbir portw, gdzie reprezentuje dostpno konkretnego

poczenia (binding) w okrelonym punkcie kocowym (wle). Atrybut poczenia portu musi si

odnosi do nazwy wczeniej zdefiniowanego poczenia .

Skadnia:

*

*

Kady element pliku WSDL moe deklarowa opcjonalny komponent , ktry

zawiera przeznaczon dla uytkownika informacj opisow.

3.3. Przykady praktyczne zastosowania WSDL

Komunikaty i typy portw:

Wizania i usugi

Metody GET I POST zwracajce GIF lub JPG

danie/Odpowied w HTML z wykorzystaniem SOAP (usuga wspiera pojedyncz

operacj GetLastTradePrice)

My first service

3.4. Wady i zalety stosowania WSDL

Zalety stosowania WSDL:

standardowy format opisu usug

moliwo wykorzystania w wielu rnych technologiach i systemach komputerowych

zrozumiay interfejs wykorzystywany przy definiowaniu usug

atwy w uyciu

automatyzacja komunikacji midzy usugami

szybsze udostpnianie i aktualizacja oprogramowania

W przyszoci narzdzia WSDL umoliwi generowanie kodu w Javie, C/C++, Corba, IDL, EJB,

COM, COM, SOAP/HTTP i SOAP przez e-mail i zapewni realizacj dowolnego rodzaju

przyczy. Kod bdzie generowany zarwno po stronie serwera, jak i klienta. Serwisy WWW ju

teraz daj moliwo uaktywnienia przycza.

Do wad mona zaliczy:

problemy z bezpieczestwem (to dodatkowy protok obsugi, ktry trzeba zabezpieczy)

problemy z autoryzacj

niezbyt dua wydajno

jest jeszcze do modym protokoem, podlega rozwojowi i zmianom

Problemy zwizane z zapewnieniem bezpieczestwa to najwiksza przeszkoda w komercyjnym

wykorzystaniu usug sieciowych. WSDL to kolejna warstwa porednia, ktra wymaga

odpowiednich zabezpiecze. Wicej warstw oznacza wicej moliwoci dla hakerw.

Jzyk WSDL jest przydatny, jeli wiadomo jaka usuga Web Service jest potrzebna. Nie umoliwia

natomiast odnajdowania i przeszukiwania usug. Do tego su inne protokoy. Nie jest to zbyt

wygodne (konieczne zapewnienie wsppracy midzy protokoami).

4. Protok UDDI

4.1. Do czego suy UDDI

Gwnym zadaniem UDDI (The Universal Description, Discovery and Integration) jest stworzenie

niezalenego od platformy, otwartego rozwizania do odnajdywania usug sieciowych. UDDI to

globalny rejestr usug udostpniajcy klientom mechanizmy dynamicznego wyszukiwania innych

usug Web. UDDI stanowi interfejs umoliwiajcy dynamiczne poczenie si z usug

udostpnian przez innego usugodawc.

Projekt UDDI czsto okrelany jako DNS dla biznesu. UDDI jest bowiem usug katalogow

przechowujc opisy i lokalizacje Web Services zarejestrowanych przez dostawcw. Wyszukiwanie

usug jest podobne do dziaania wyszukiwarek internetowych.

UDDI posiadaj dwa rodzaje klientw:

usugodawcw publikujcych swoje usugi

klientw pragncych skorzysta z tych usug.

Projekt UDDI wykorzystuje standardy W3C (WorldWide Web Consorcium) oraz IETF (Internet

Engineering Task Force), takie jak: XML (Extensible Markup Language), protokoy HTTP oraz

DNS (Domain Name System). Warstwa UDDI ley nad protokoem SOAP, przez co komunikaty

UDDI stanowi obiekty w komunikatach SOAP. Usugi opisywane s przez WSDL.

Projekt UDDI promuj m.in. Ariba, IBM, Intel, Microsoft, SAP i Sun, lecz nie ma on jeszcze

wasnej grupy roboczej w W3C (World Wide Web Consorcium). UDDI nie jest zwizany z WSDL

czy ebXML, ale w jego katalogach opisuje si najczciej usugi oparte na WSDL. Publiczne

katalogi UDDI udostpniy m.in. firmy Microsoft, IBM i XMethods.

Opracowanie dotyczce UDDI oparte jest na informacjach umieszczonych na stronie

http://uddi.org/.

4.2. Elementy protokou UDDI

W UDDI istotna jest kategoryzacja firm - musi ona umoliwia wyszukanie firmy o cile

okrelonym profilu dziaalnoci. Specyfikacja UDDI opisuje rwnie sposb wymiany danych

pomidzy serwerami, ktre mog tworzy sie wzw.

Rejestry UDDI zawieraj:

informacje o webservices na bazie nazwy usugodawcy, jego adresu, kategorii biznesowej

czy informacji technicznej itp.,

operacje dotyczce usugi Web tj. rejestracji, wyszukiwania i korzystania z usugi

szczegy udostpniane przez niskopoziomowe API

W UDDI informacje zawarte s w czterech rnych strukturach, zapewniajcych funkcjonalno:

businessEntity struktura umoliwiajca wyszukiwanie wedug biznesu

businessService struktura umoliwiajca wyszukiwanie wedug usugi biznesowej

bindingTemplate struktura umoliwiajca wyszukiwanie wedug wizania

tModel struktura umoliwiajca wyszukiwanie wedug usugi Web Services

W UDDI wykorzystuje si model zapytania drcego:

Wykorzystanie zapyta find_X w celu uzyskania oglnych informacji xLists

Uzyskanie szczegw przy pomocy zapytania get_xDetail

http://uddi.org/

4.3. Przykad zastosowania UDDI

W Polsce testowy katalog UDDI uruchomia firma T-Systems na wortalu technologicznym

http://www.e-kompas.pl/, ktry udostpnia te testowe usugi sieciowe i aplikacje pokazujce

sposb dziaania tej technologii. Istnieje ju kilka rozwiza, rwnie open source, pozwalajcych

na uruchomienie wasnego wza UDDI. Z reguy implementacje katalogw UDDI oferuj dostp

zarwno przez strony WWW, jak i przez protok SOAP - dziki temu przysze systemy bd

mogy automatycznie wyszukiwa potrzebne im usugi.

Pojedynczy wpis w repozytorium UDDI dostpnym w wortalu e-kompas.pl zawiera trzy poziomy

informacji:

nazw firmy, jej podstawowe dane adresowe

kategori

spis usug biznesowych udostpnianych przez jej systemy wraz z ich definicj

Dziki istniejcym ju repozytoriom UDDI i Web Services ju dzi mona uzyska rozkady

lotw, notowania giedowe czy najnowsze wiadomoci w sposb umoliwiajcy automatyczne

wykorzystywanie przez wasne oprogramowanie. Docelowym zastosowaniem UDDI ma by

tworzenie otwartych lub zamknitych e-marketplace, udostpnianie partnerom biznesowym

informacji i procesw dla ich systemw czy integracja systemw wewntrz przedsibiorstwa.

4.4. Wady i zalety stosowania UDDI

UDDI jest rozleg inicjatyw umoliwiajc systemom biznesowym odkrywanie siebie nawzajem

oraz definiowanie sposobw interakcji poprzez Internet. Standard UDDI definiuje rwnie sposoby

replikacji pomidzy repozytoriami. Obsuga UDDI powinna by integraln czci systemw

biznesowych, dziki czemu bd one potrafiy atwo, w sposb dynamiczny i przede wszystkim

szybko, znale inne systemy i wspdziaa z nimi.

5. Zakoczenie

5.1. Wsppraca protokow SOAP, WSDL i UDDI

Protok SOAP umoliwia wywoywanie i wykonywanie usug Web Services, publikowanych za

pomoc WSDL i wyszukiwanych za porednictwem rejestru UDDI. Wykorzystywanie protokou

SOAP do wywoywania i wykonywania aplikacji poprzez Internet i korporacyjne zapory ogniowe

umoliwia przedsibiorstwom bezpieczn integracj wasnych procesw biznesowych z procesami

partnerw i dostawcw.

http://www.e-kompas.pl/

Korzystanie z usug przebiega w nastpujcy sposb:

dostarczyciele usug - rejestruj si u porednikw (UDDI).

klient - pyta porednika, kto mu da dan usug. (SOAP).

porednik (broker) - lokalizuje mu t usug i podaje opis jej uycia (WSDL).

klient podcza si do dostarczyciela i korzysta z usugi (SOAP)

PRZYKAD:

Wymiana usug WWW pomidzy dwiema aplikacjami moe wyglda nastpujco:

1. Przedsibiorstwo A opisuje swoj usug WWW poprzez WSDL; usuga jest rejestrowana w

UDDI.

2. Przedsibiorstwo B, chcce skorzysta z usugi, siga 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. Bezpieczestwo Web Services

Problemy z bezpieczestwem jest to najwiksza przeszkoda w komercyjnym wykorzystaniu usug

sieciowych. Usugi sieciowe wprowadzaj bowiem trzy lub cztery dodatkowe warstwy porednie,

ktre wymagaj odpowiednich zabezpiecze. Wicej warstw oznacza wicej moliwoci dla

hakerw.

Jako rozwizanie tego problemu proponuje si stworzenie pojedynczego standardu. Tak prb jest

Microsoft .NET Passport.

Najbardziej istotnym elementem bezpieczestwa jest identyfikacja uytkownika, bowiem

udostpniajc usugi w Internecie, zezwalamy na korzystanie z nich w dowolny sposb. Aby

ograniczy dostp do konkretnych usug, wystarczy zastosowa kod (np. w postaci parametru

wywoania usugi) umoliwiajcy dostp tylko autoryzowanemu uytkownikowi. Bezpieczestwo

transmisji zapewnia SSL uyty w niszych warstwach protokou. W przypadku powszechnie

dostpnych usug, gdy nie ma moliwoci przekazania kodu dostpu, konieczne jest zastosowanie

innych metod uwierzytelniajcych.

Microsoft stara si narzuci usug autoryzacyjn MS Passport, ktra jest kluczowym elementem

platformy .NET My Services. Zasadno powierzenia bazy informacji o uytkownikach jednej,

komercyjnej firmie podwaa Sun - firma ta powoaa do ycia konkurencyjny projekt The Liberty

Alliance, zrzeszajcy: Apache Software Group, NTT DoCoMo, Bank of America, eBay, Real

Networks, Nokia i RSA Security. Obie koncepcje d do zbudowania bazy informacji o

uytkownikach Sieci, ich danych osobowych i preferencjach. Projekty te s jeszcze mao

zaawansowane, trudno wic w tej chwili oceni ich przydatno dla usug sieciowych.

Przy nawizywaniu kontaktw biznesowych wan rol speni inicjatywy w rodzaju Identrus -

organizacji zrzeszajcej grup duych bankw, m.in. Bank of America, Barclays, Chase Manhattan,

Citigroup, Deutsche Bank i majcej poparcie wielu producentw oprogramowania. Identyfikator

Identrus Global ID umoliwia globaln identyfikacj firmy za pomoc klucza publicznego (PKI) i

uwiarygodnianie jej jako kontrahenta. Dziki temu mona elektronicznie tworzy bezpieczne,

otwarte rynki i powanie angaowa si w integracj B2B o zasigu globalnym. Standard ebXML

jako podstawa integracji B2B zwiksza bezpieczestwo takiego rozwizania, poniewa wymaga na

przykad podpisania przez przedstawicieli firm umowy o integracji systemw.

5.3. Przyszo Web Services

Jeeli chodzi o przyszo usug sieciowych, to jest to jedna z metod pozwalajca na szybsze

udostpnianie i aktualizacj oprogramowania.

Web Services komunikuj si wykorzystujc HTTP oraz XML. Dowolne urzdzenie lub system

obsugujcy te popularne standardy moe utrzymywa takie usugi oraz udostpnia je. Mona si

spodziewa, e ju niedugo Web Services bd powszechnie implementowane take w

samochodach, automatach ulicznych, czy choby komrkach. Przy wystpieniu okrelonego

zdarzenia, np. wyczerpaniu zapasu puszek w automacie z napojami, ulokowana w nim usuga

skontaktuje si z usug czuwajc w firmie odpowiedzialnej za dostarczanie napojw do

automatw.

Architektura Web Services nie jest jeszcze kompletna. Jednym z istotnych problemw jest potrzeba

zwikszenia wydajnoci tej technologii.

Firmy IBM, Microsoft i Ariba implementuj dla usug Web Services publiczny globalny rejestr

UBR (Universal Business Registry). Ma on suy jako centralne repozytorium i obejmowa

wszystkie (niezalenie od wielkoci) firmy, ktre chc zarejestrowa swoj dziaalno oraz

poszukuj produktw lub usug oferowanych przez inne podmioty. UBR umoliwi publikacj usug

Web Services poprzez proste wypenienie dostpnego on-line formularza. Po rozpowszechnieniu

usug Web Services rejestr UBR ma pomaga przedsibiorstwom 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, dotyczce przede wszystkim dynamicznego

wyszukiwania usug podczas pracy aplikacji. Inne prace koncentruj si na umoliwieniu

wykorzystania w technologii Web Services take jzykw skryptowych, takich jak JavaScript czy

REXX. W tym celu musi by, midzy innymi, zmodyfikowana specyfikacja SOAP.

Na wiecie koncepcja usug Web Services jest w ostatnim czasie szeroko promowana i spotyka si

z coraz wikszym zainteresowaniem. Czoowe firmy oferuj za darmo zestawy narzdzi, ktre

pozwalaj programistom szybko budowa oraz implementowa Web Services. Moliwe jest te

przeksztacanie istniejcych komponentw (np. COM czy JavaBeans) w usugi Web Services. Na

nowej technologii usug internetowych bazuje platforma Microsoft .NET, natomiast IBM rozwija

nieodpatne narzdzia w kategorii Alphaworks. Ju teraz komponenty napisane w Visual Basicu

mog by atwo wdroone jako Web Services, a nastpnie bez przeszkd wywoywane przez usugi

zbudowane np. z wykorzystaniem technologii VisualAge firmy IBM.

W przyszoci usugi Web Services bd zapewne powszechnie stosowane do przekazywania

informacji biznesowych (np. wynikw notowa giedowych) partnerom i klientom, integracji z

zapewnieniem pracy transakcyjnej w takich zastosowaniach, jak obsuga gied i systemy rezerwacji,

czy nawet do decentralizacji i przenoszenia procesw biznesowych na zewntrz przedsibiorstwa.

W tym ostatnim wypadku usugi Web Services bd wykorzystywane do swobodnej, dynamicznej

integracji midzy procesami nalecymi do rnych podmiotw gospodarczych. Mona sobie te

wyobrazi, e w przyszoci aplikacje biznesowe klasy B2B, pracujce w Internecie, bd

budowane z usug Web Services wybieranych dynamicznie podczas realizacji procedur

biznesowych, z uwzgldnieniem dostpnoci, kosztw czy funkcjonalnoci (jakoci).

Literatura

John Paul Mueller "Poznaj SOAP" Wydawnictwo Mikom 2002

http://www.w3.org/

http://uddi.org/

http://www.w3.org/http://uddi.org/