1

Technologie Internetu

wykład 13: Web Services: opisy

i rejestry usług

Piotr Habela

Polsko-Japońska Wyższa Szkoła

Technik Komputerowych

2

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.

3

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

4

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.

5

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ń.

6

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.

7

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.

8

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).

9

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.

10

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ąć).

11

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>

12

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>

13

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>

14

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>

15

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.

16

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.

17

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).

18

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.

19

Budowa rejestru UDDI

(2)

•

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ą.

<businessEntity ...>

</businessEntity>

<message> ... </message>

<businessService>

</businessService>

<binding> ... </binding>

<bindingTemplate> ...

</bindingTemplate>

<service> ... </service>

<tModel> ... </tModel>

20

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.

21

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.

22

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).

23

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.

24

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).

25

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.

26

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).

27

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).

28

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.

29

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.

30

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ć.

31

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.

32

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.

33

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.