Transcript Document

Technologie Internetu
wykład 13: Web Services: opisy
i rejestry usług
Piotr Habela
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych
1
W poprzednim odcinku…
• Web Services stanowią rozwinięcie koncepcji technologii
rozproszonych obiektów.
• Wysoki stopień ich niezależności od platformy stwarza realne
szanse na wyjście z systemami rozproszonymi poza granice
danej firmy.
• Kluczem do współdziałania jest XML jako język wymiany
danych. Oparto na nim protokół SOAP, służący komunikacji z
usługami Webu. Umożliwia on współdziałanie przy zachowaniu
niezależności od języka programowania i infrastruktury
rozproszonych obiektów.
• SOAP umożliwia realizację różnego stylu interakcji, włącznie z
komunikatami asynchronicznymi i modelem RPC. SOAP nie
determinuje protokołu transportowego – przewidziane są różne
wiązania. Z drugiej strony nie określa też semantyki interakcji.
2
Plan wykładu
•
•
•
•
•
Architektura Web Services
Problem opisu usług
Charakterystyka języka WSDL
Rejestry opisów usług – specyfikacja UDDI
ebXML – nowa technologia elektronicznej
wymiany dokumentów
• Podsumowanie architektury Web Services
3
Właściwości Web Services
• Usługi mogą być różnorodne – zarówno czysto
niematerialne (udostępnianie informacji), jak i mające
skutki w świecie materialnym. Np.:
– autoryzacja kart kredytowych;
– wyliczenia należnych opłat/podatków;
– usługa wydruku (dla urządzeń przenośnych).
• Zależnie od okoliczności, różnią się też scenariusze budowy
usług:
– Usługa jest projektowana, tworzony jest jej opis a następnie
generuje się odpowiedni kod („pieńki” i „szkielety”) i
implementuje jej funkcjonalność;
– Usługa powstaje poprzez obudowanie odpowiednim interfejsem
istniejących już komponentów aplikacji.
• Aby powstała funkcjonalność była użyteczna, usługa
wymaga precyzyjnego opisania.
4
Opis usługi Webu
• Współdziałanie klienta z usługą wymaga uzgodnienia celu i
mechanizmu interakcji.
• Następujące motywy przemawiają za tym, aby te informacje
były dostępne w maszynowo przetwarzalnej postaci:
–
–
–
–
precyzja opisu;
możliwość automatycznego generowania kodu dostępowego;
dynamiczne wyszukiwanie i użycie;
możliwość kontroli zgodności działania usługi z jej opisem.
• W opisie takiej interakcji można wyróżnić oczekiwania
(informacje wejściowe) oraz funkcjonalność (informacje
wyjściowe) zarówno po stronie klienta jak i serwera.
Warunkiem pomyślnej interakcji jest spełnienie przez obie
strony swoistego kontraktu, polegającego na dopasowaniu
oferowanych danych do wymagań.
5
Semantyka interakcji
• Określa cel i znaczenie elementów interakcji.
• W szczególności chodzi tu o określenie zewnętrznych w stosunku do
danej interakcji efektów (np. przelew środków, dokonanie rezerwacji,
sporządzenie wydruku);
• Drugim istotnym zagadnieniem jest kontekst, czyli umiejscowienie
danej operacji w szerszym procesie: zarówno w części realizowanej w
postaci elektronicznej jak i w pozostałych fragmentach.
• Jeśli działania nie są podejmowane przez człowieka, informacje te
wymagają jawnego i jednoznacznego sformułowania.
• Jeśli wymagana jest po prostu jednoznaczna identyfikacja jakiegoś
pojęcia czy procesu, to opis może pozostać wręcz w postaci języka
naturalnego, o ile zostanie z nim skojarzona jednoznaczna
identyfikacja (np. poprzez URL jak w wypadku przestrzeni
nazwowych).
• Z drugiej strony dla umożliwienia wyszukiwania usług, potrzebny jest
opis ich istotnych właściwości w postaci przetwarzalnej maszynowo.
6
Język WSDL (Web Services Description Language)
• Specyfikacja W3C, zgodnie z nazwą służąca czytelnemu
maszynowo opisowi usług Webu, opartemu na XML.
• Ponieważ opisuje usługę, nie zaś wymagania klienta, stąd
budowa swoistej giełdy, gdzie zarówno usługi jak i
zapotrzebowania byłyby przedmiotem wyszukiwania i ew.
kojarzenia przez odrębnego brokera, wymaga dodatkowo
określenia sposobów opisu takich zapotrzebowań.
• WSDL opisuje technikę współdziałania z usługą. Zakłada, że
semantyka usługi jest opisana na zewnątrz i może być
jednoznacznie wskazana poprzez identyfikator. Tym samym
„kontrakt” dotyczący znaczenia i celu jest oddzielony od
„kontraktu” określającego mechanikę współdziałania.
• Specyfikacja zatem nie zajmuje się problemem definiowania
semantyki usługi.
7
Zawartość dokumentu WSDL
• Jest to opis abstrakcyjnego interfejsu, tj. niezależnego od protokołu
transportowego oraz od języka programowania.
• Struktura pliku WSDL jest zdefiniowana w specyfikacji w postaci
schematów XML Schema.
• Typy danych używanych w opisywanych przez dokument WSDL
interfejsach mogą być zdefiniowane w dowolnym systemie typów,
choć domyślnie stosuje się właśnie XML Schema.
• Funkcjonalność odpowiada np. IDL ze standardu OMG CORBA.
• Jak zobaczymy, opis usługi jest jednak znacznie bardziej
rozbudowany. Wynika to z dwóch faktów:
– większa niezależność i różnorodność możliwych do zastosowania w
Web Services protokołów;
– konieczność określenia wszelkich informacji konfiguracyjnych
explicite (a nie jak w lokalnie tworzonych systemach, gdzie szereg
ustawień może mieć charakter umowny).
8
Struktura dokumentu definicji
• Element-korzeń nosi nazwę
definitions. Zawiera atrybut
name określający nazwę danej
usługi. Pozostałe jego atrybuty
definiują odwołania do przestrzeni
nazwowych: standardowych –
XML Schema, SOAP, WSDL,
oraz docelowej przestrzeni
nazwowej danej usługi
„targetNamespace”.
• Definicje mogą zawierać
deklaracje importu: <import
namespace= ”…” location=”…” />,
służącą dekompozycji dużego
opisu pomiędzy kilka plików.
<definitions ...>
<import />
<types />
<message> ... </message>
<message> ... </message>
<portType> ... </portType>
<binding> ... </binding>
<binding> ... </binding>
<service> ... </service>
</definitions>
9
Składniki dokumentu WSDL – cz. abstrakcyjna (1)
• Zawartość definicji składa się z części abstrakcyjnej:
– Definicje typów danych;
– Definicje komunikatów;
– Definicje typów portów;
• …oraz części konkretnej:
– Definicje wiązań;
– Definicja usługi.
1. Element types: Zawiera definicje typów danych
wykorzystywanych w komunikatach opisywanej usługi.
Typy te mogą być zdefiniowane w dowolnym systemie
typów, choć domyślnie stosuje się XML Schema (wówczas
dla typów wbudowanych, deklarację types możemy
pominąć).
10
Składniki dokumentu WSDL – cz. abstrakcyjna (2)
2. Elementy message. Każdy z nich definiuje pojedynczy
komunikat przesyłany podczas realizacji usługi.
Komunikat posiada nazwę (atrybut name) oraz jeden lub
więcej podelementów part, odwołujących się do
wbudowanych typów XML Schema albo do typów
zdefiniowanych w elemencie types.
Np.
<message name="wePodajTemperature">
<part name="miasto" type="xs:string"/>
</message>
<message name="wyPodajTemerature">
<part name="temp" type="xs:float"/>
</message>
11
Składniki dokumentu WSDL – cz. abstrakcyjna (3)
3. Element portType: definiuje abstrakcyjne operacje w oparciu
o wcześniej opisane komunikaty. Element taki posiada nazwę
oraz podelementy „input”, „output”, „fault”. Posiadają one
atrybut message, odwołujący się do nazwy zdefiniowanego
wcześniej komunikatu.
• Dopuszczalne rodzaje komunikatów zależą od rodzaj transmisji:
– request/response: wejście i wyjście (+ ew. komunikat błędu);
– one-way: tylko dane wejściowe;
– solicit response (żądanie odpowiedzi): najpierw dane wyjściowe,
potem wejściowe (+ ew. komunikat błędu);
– notification: tylko dane wyjściowe;
<portType name="TemperaturyPortType">
<operation name="PodajTemperature">
<input message="tns:wePodajTemperature"/>
<output message="tns:wyPodajTemperature"/>
</operation> </portType>
12
Składniki dokumentu WSDL – cz. konkretna (1)
4. Element binding: dla każdego portType oferuje przynajmniej
jedno wiązanie do konkretnego protokołu. Posiada nazwę (atrybut
name) i następującą zawartość:
– Element soap:binding: określa styl interakcji (rpc lub document)
oraz określa rodzaj transportu (np. SOAP poprzez HTTP).
– Element operation: zawiera podelementy odpowiadające danym
wejściowym i wyjściowym i określa dla nich sposób kodowania
ciała komunikatu SOAP. Zawiera również specyfikację nagłówka
HTTP, jaki klient przesyła przy wywołaniu usługi.
<binding name=”TemperaturyBinding”
type=”tns:PodajTemperaturePortType”>
<soap:binding style=”rpc”
transport=”http://schemas.xmlsoap.org/soap/http” />
<operation name=”PodajTemperature”>
<soap:operation soapAction=”” />
<input> <soap:body use=”encoding” encodingStyle=
”http://schemas.xmlsoap.org/soap/encoding/”/> </input>
<output>… j.w. …</output> </operation> </binding>
13
Składniki dokumentu WSDL – cz. konkretna (2)
5. Element service: stanowi zbiór portów (ports),
tworzących usługę. Zdefiniowany poprzez odwołania do
konkretnych ich wiązań, jak określono powyżej. Określa,
pod jakim adresem usługa o zdefiniowanym wcześniej
wiązaniu będzie dostępna.
<service name=”Temperatury”>
<port name=”TemperaturyPort”
bindings=”tns:TemperaturyBinding”>
<soap:address
location=”http://uslugi.przyklad.com:80/soap/” />
</port>
</service>
14
Opis usług - podsumowanie
• Problem niezależnego od implementacji opisu
funkcjonalności elementów systemu rozproszonego
znany jest już z wcześniejszych technologii jak choćby
CORBA. Już w tamtej technologii zadbano o
udostępnienie poprzez interfejs programistyczny tych
opisów, celem umożliwienia dynamicznej konstrukcji
żądań.
• Aktualnie specyfikacje służące opisowi usług poprzestają
na definiowaniu interfejsów dla wymiany komunikatów.
Jest możliwe, że podjęte zostaną próby wprowadzenia do
tej specyfikacji systemu opisu dla samej semantyki usług.
15
UDDI (Universal Description, Discovery and Identification)
• Specyfikacja, tworzona przez konsorcjum OASIS, określa
rozproszony katalog, zawierający zarówno informacje o samych
firmach jak i o udostępnianych przez nie usługach Webu, czyli
swoistą „książkę telefoniczną”. Rozwijając tę metaforę,
specyfikacja wyróżnia:
– „zielone strony”: techniczny opis usług wraz z odnośnikami URL
(w założeniach nie muszą to być koniecznie usługi Webu);
– „białe strony”: identyfikacja, adresy i inne dane kontaktowe firm;
– „żółte strony”: wykaz firm ułożony według klasyfikacji
przemysłowej;
• Rejestr zaprojektowano jako logicznie scentralizowany, zaś
fizycznie rozproszony i replikowany. Może być dostępny
zarówno tradycyjnie (interfejs WWW), jak i programowo (jak
usługi Webu).
• Interfejs programistyczny wyróżnia część służącą formułowaniu
zapytań oraz część służącą publikowaniu opisów.
16
UDDI - zastosowanie
• Tego rodzaj rejestr stanowi niezbędną podstawę dla realizacji
koncepcji rozwiniętej współpracy B2B opartej na Web Services.
• Z rozwojem rejestrów usług wiązane są duże nadzieje. Oczekuje
się, że pojawienie się ustandaryzowanych rejestrów spowoduje
taki rozwój usług Webu w zastosowaniach B2B, jaki nastąpił w
przypadku WWW po wprowadzeniu HTML.
• Realnym celem nie jest tu zastąpienie człowieka w
wyszukiwaniu usług, ale raczej podniesienie efektywności
wyszukiwania (być może wspieranego przez specjalizowane
wyszukiwarki), poprzez umieszczenie w jednym logicznym
rejestrze jednolicie uformowanych opisów.
• Oczywiście możliwe jest automatyzowanie np. konfigurowania
współpracy z określonymi usługami na podstawie ich opisów w
rejestrze UDDI.
• Specyfikacja dostarcza podstawowych mechanizmów, stanowiąc
tym samym jedynie ramę dla nadbudowy wyrafinowanych
mechanizmów wyszukiwawczych (np. według ceny usług).
17
Budowa rejestru UDDI
(1)
• Specyfikacja zawiera schematy XML dla komunikatów
SOAP oraz opis interejsów programistycznych rejestru.
• Schematy XML (wybrane jako postać opisu z uwagi na
niezależność od platformy, rozbudowany system typów
oraz naturalność odwzorowania hierarchicznej informacji)
definiują następujące zasadnicze typy informacji stosowane
w wymianie opisów usług:
– Informacja biznesowa;
– Informacja o usłudze;
– Specyfikacja usługi.
• Informacja biznesowa: opisywana w elemencie
businessEntity. Zawiera podstawowe informacje
identyfikujące firmę, w tym wsparcie dla systemów
klasyfikacji branżowej i geograficznej.
18
Budowa rejestru UDDI
• Informacja o usłudze: Informacja
ta znajduje się wewnątrz elementu
zawierającego informacje
biznesowe. Składa się z elementów
businessService (opis usługi)
oraz bindingTemplate (informacja
niezbędna dla wywołania usługi):
informacje techniczne niezbędne do
połączenia się z usługą; m.in. czy
jest samodzielna, jej URL itp.
• Specyfikacja usługi: Element
bindingTemplate zawiera zbiór
odnośników do specyfikacji
(zawartych w elementach tModel).
Każdy element tModel stanowi
opis pewnej specyfikacji, na której
oparta jest usługa. Komplet takich
specyfikacji określa wzorzec
zgodności z daną usługą.
(2)
<businessEntity ...>
<businessService>
<message>
</message>
<binding> ......</binding>
<bindingTemplate>
...
</bindingTemplate>
</businessService>
</businessEntity>
<service> ... </service>
<tModel> ... </tModel>
19
API rejestru UDDI
(1)
• Umożliwia programistyczny dostęp do informacji
zawartych w rejestrze. Wyróżniono części: Inquiry API
(część służąca pobieraniu informacji z rejestru oraz część
służąca obsłudze błędów wywołań usług) i Publisher API.
• Sam rejestr UDDI jest oparty na protokole usług Webu:
SOAP. Wszystkie wołania zdefiniowano jako
synchroniczne.
• Interfejs zapytań:
– Posiada metody find_xx – umożliwiające wyszukiwanie według
różnych kryteriów;
– Dla opisu o znanym kluczu, która go identyfikuje, można posłużyć
się metodą get_xx celem pobrania całej struktury businessEntity,
businessService, bindingTemplate lub tModel.
20
API rejestru UDDI
(2)
• Scenariusz dostępu do usługi:
(Każdej udostępnianej usłudze odpowiada element bindingTemplate.)
1. Wyszukanie podmiotu biznesowego (businessEntity), oferującego
usługę.
2. Nawigacja lub pobranie całego elementu businessEntity.
3. Zachowanie informacji z wybranego bindingTemplate.
4. Przygotowanie programu w oparciu o dane z bindingTemplate i
zawarte w nim informacje u zastosowanych specyfikacjach
(umieszczonych w tModel).
5. Wywoływanie usługi.
• Obsługa błędu wołania usług:
– Dodatkową zaletą dostępności rejestru usług jest umożliwienie
reagowania na błędy wołania usług. Po wykryciu błędu
oprogramowanie jest w stanie zaktualizować przechowywaną kopię
wpisu dotyczącą danej usługi i ponowić żądanie. Podejście to jest zwane
„retry on failure”.
– Pozwala np. uniknąć zakłóceń po wprowadzeniu przekierowania.
21
ebXML
• Działalność gospodarcza wiąże się z intensywną komunikacją
pomiędzy firmami. Jest rzeczą bezsporną, że przeniesienie tej
wymiany do postaci elektronicznej stwarza szanse na uczynienie
jej szybszą i mniej pracochłonną.
• Tradycyjne rozwiązanie powstałe w tym celu: EDI (Electronic
Document Interchange) stanowi jednak technologię złożoną i
bardzo kosztowną. Ogranicza to jej zastosowanie do dużych
korporacji.
• Zastosowaniem tej specyfikacji jest zatem stworzenie ram dla
prostszego, tańszego i powszechniejszego zamiennika
technologii EDI.
• ebXML stanowi grupę specyfikacji rozwijanych przez ONZ
(United Nations Centre for Trade Facilitation and Electronic
Business): UN/CEFACT, zajmującą się również specyfikacją
EDI, oraz OASIS (Organization for the Advancement of
Structured Information Standards).
22
Niezbędne rozszerzenia XML
• Ów bardziej produktywny zamiennik dla EDI postanowiono
oprzeć na XML, co jest motywowane następującymi
czynnikami:
– popularność i prostota składni;
– niezależność od platformy;
– szerokie wsparcie dla przetwarzania dokumentów XML.
• Niezbędne jest jednak określenie, jakie dane i w jakiej
postaci mają być wymieniane.
• Zadanie skonstruowania elektronicznej wymiany danych
wykracza znacznie poza sformułowanie składni i gramatyki
wymienianych komunikatów. Potrzebne jest określenie:
–
–
–
–
opisów procesów biznesowych (Business Process Specification);
definicji i budowy wymienianych dokumentów;
formatu i protokołów wymiany danych;
udostępniania tych informacji w standardowych rejestrach.
23
ebXML – współdziałanie z partnerami biznesowymi
• Rejestry przechowują dla danej firmy specyfikację
określającą oczekiwania wobec partnerów biznesowych.
Zapisy te określane są jako CPPs (Collaboration Protocol
Profiles). Określają: w jakich procesach biznesowych
firma jest skłonna uczestniczyć, w jakiej roli i przy jakich
technicznych ograniczeniach. Np.: że świadczy usługi
udostępniania określonych danych za pośrednictwem HTTP,
z możliwością przyjęcia zapłaty on-line.
• Kolejnym istotnym krokiem jest zestawienie określonej
współpracy. Niezbędna informacja występuje w postaci
CPA (Collaboration Protocol Agreement), i składa się ze
skojarzonych zapisów CPP obydwu stron. Informacja ta jest
uzupełniona o zagadnienia techniczne jak protokół,
wymagania autentykacji itp. i pozwala zbudować i
skonfigurować po obu stronach współpracujące aplikacje,
zwane tu BSI (Business System Interfaces).
24
CPA i CPP nieco dokładniej
• CPP są identyfikowane poprzez GUID (Globally Unique
Identifier) i zawierają:
– identyfikację firmy lub jej części;
– realizowane procesy biznesowe oraz role pełnione w nich przez
firmę;
– informację o wykorzystywanych certyfikatach bezpieczeństwa;
– określenie kanałów komunikacyjnych (bezpieczeństwo,
autentykacja, protokół transportowy);
– informację o sposobie konstruowania komunikatów.
• CPA (Collaboration Protocol Agreement) stanowi
zasadniczo przecięcie CPP współpracujących firm,
precyzujące wymagane szczegóły.
• Zwykle tworzone jest przez jedną z firm i przedkładane
drugiej do akceptacji. Może mieć określony okres
obowiązywania.
25
ebXML - architektura
• Interakcja partnerów biznesowych jest oparta na Schemacie
Specyfikacji Procesów Biznesowych (BPSS), złożonego z:
– specyfikacji procesów;
– specyfikacji stosowanych dokumentów.
• Obydwie specyfikacje skonstruowane są ze zdefiniowanych
wcześniej komponentów podstawowych i umieszczone w
rejestrze ebXML. - Głównym motywem dla takiego
rozwiązania jest efektywne realizacja postulatu wielokrotnego
użycia komponentów.
• W tworzeniu BPSS stosuje się język UML. Powstałe modele
są następnie translowane do schematów XML Schema lub
DTD.
• Całą zawartość rejestru określa Registry Information Model.
Nie przewiduje przechowywania konkretnych dokumentów, a
jedynie ich opisów (metadanych).
26
Modelowanie procesów biznesowych
• Współpraca elektroniczna wymaga precyzyjnego opisania
swoich procesów biznesowych.
• Modelowanie procesów biznesowych, podobnie jak
metodyki tworzenia oprogramowania stanowi samo w sobie
rozległą i stosunkowo dojrzałą dziedzinę.
• Pominięcie rzetelnej analizy i modelowania procesów niesie
też podobne zagrożenia, jak w wypadku tworzenia
oprogramowania.
• Specyfikacja ebXML proponuje w tym celu metodykę
UMM (Unified Modeling Methodology).
27
Współdziałanie biznesowe (business collaboration)
• Na najniższym poziomie składa się z elementarnych kroków
zwanych transakcjami biznesowymi: wiążą się one z
przesłaniem dokumentu. Mogą stanowić żądania
(oczekiwana odpowiedź) lub powiadomienia. Zależnie od
charakteru interakcji sterowanie jest odpowiednio
przekazywane pomiędzy stronami.
• Typowym modelem jest współdziałanie binarne
(obejmujące dwie strony);
• Mogą istnieć bardziej rozbudowane – wielostronne
współdziałania.
• Współdziałania biznesowe posiadają swój stan oraz
nałożone reguły określające, kiedy możliwe są przejścia
pomiędzy stanami.
28
ebXML Message Service
• Określa sposób wymiany komunikatów w ebXML.
• Komunikaty oparte są na protokole SOAP z załącznikami.
– Ciało komunikatu zawiera identyfikator przesyłanej wiadomości;
– Właściwy dokument znajduje się w załączniku.
• Stanowi warstwę aplikacji, odpowiedzialną za tworzenie i
odczyt komunikatów ebXML, zgodnych z opisem w
odpowiednim CPA.
• Niezbędne dane opisowe (np. identyfikator CPA, z którym
związany jest komunikat czy identyfikatory firm adresata i
nadawcy) występują jako bloki nagłówkowe SOAP.
• Komunikat identyfikuje odpowiedni proces biznesowy,
konwersację, jak również sam przesyłany dokument.
• Zawartość komunikatu może być wskazana jako odnośnik
do zewnętrznego zasobu.
29
ebXML - podsumowanie
• Specyfikacja obejmuje trzy główne części:
– analiza procesów i dokumentów biznesowych;
– opis sposobów współdziałania uczestniczących firm;
– wymiana komunikatów.
• Reprezentuje nieco inne niż w wypadku UDDI podejście do
problemu dostępności usług Webu.
• Posiada poparcie znaczących instytucji i firm – często
zaangażowanych również w UDDI, toteż można się
spodziewać że ebXML i UDDI będą współistnieć.
30
Architektura Web Services - Podsumowanie
• Usługa Webu jest abstrakcyjnym zbiorem funkcjonalności,
implementowanym przez konkretnego agenta (element
oprogramowania zdolny wysyłać i przyjmować
komunikaty).
• Istnieje wobec tego szeroki zakres różnorodności i
zmienności agentów, realizujących taką samą nie zmienioną
usługę (co realizuje postulat luźnego skojarzenia).
Niezależnie od scenariusza, uzgodnienie semantyki usługi
pośrednio lub bezpośrednio należy do ludzi z inicjatywy
których działają agent żądający usługi oraz agent dostawca.
• Poza ograniczeniami nakładanymi na postać i sposób
wymiany komunikatów warto jeszcze raz podkreślić, że
koncepcja Web Services obejmuje również działania
wykraczające poza wymianę informacji – tj. różnego
rodzaju czynności i zdarzenia w świecie materialnym
będące skutkiem wykonania usługi.
31
Architektura Zorientowana na Usługi (SOA)
• Usługi Webu stanowią wystąpienie tzw. Service Oriented
Architecture (SOA). SOA zaś jest szczególnym rodzajem systemu
rozproszonego, toteż musi uwzględniać typowe dla takich
systemów problemy, jak mniejsza niezawodność oraz opóźnienia
komunikacyjne.
• SOA zakłada, że wyodrębnione jej ramach usługi mogą być
wywoływane niezależnie od kontekstu większej aplikacji i
posiadają adresowalne w sieci interfejsy stosujące standardowe
protokoły i formaty danych. Ponadto publiczna architektura SOA
wymaga istnienia opisu usług i wymienianych w ramach nich
komunikatów.
• W ten sposób również same takie opisy stają się przedmiotem
wymiany i udostępniania w tej architekturze.
• Dodatkowo, środowisko Webu precyzuje następujące ograniczenia:
– zasoby dostępne agentom są identyfikowane poprzez URI;
– zasoby posiadają reprezentację w jednym z szeroko stosowanych
formatów.
32
Fundamenty technologii Web Services
• W istocie do roli najbardziej nieodłącznego składnika usług Webu
pretenduje XML. Jest obecny w niemal wszystkich używanych tam
technologiach. Bardziej adekwatne byłoby zatem uwidocznienie XML
i XML Schema jako „tła” niż jako dolnej warstwy stosu protokołów.
• Z założenia architektura usług Webu nie umieszcza się jako konkretna
warstwa np. w modelu OSI. Zamiast tego zakłada niezależność i
możliwość wykorzystania różnych protokołów zbudowanych w
innych celach jako nośników komunikatów.
• Wyróżnikiem architektury Web Services jest jej oparcie na
„przejrzystym” protokole, umożliwiającym zweryfikowanie
zawartości komunikatu – np. przez wspierające XML i jego protokoły
zapory ogniowe.
• Protokół SOAP, jakkolwiek nie jest niezbędny dla zrealizowania
wymiany komunikatów, stwarza niezbędną standardową podstawę dla
realizacji takich zadań jak ochrona danych, autentykacja, kodowanie,
kontrola dostępu czy transakcje.
33