[ Pobierz całość w formacie PDF ]
razem stanowi opartą na standardach, solidną podstawę architektury usług sieciowych.
KolejnÄ… warstwÄ… umieszczonÄ… koncepcyjnie jeden poziom ponad mechanizmem SOAP
opakowywania komunikatów jest mechanizm wprowadzający rozszerzenia do zwykłych
kopert pod nazwą nagłówków SOAP (SOAP headers) . Dzięki nagłówkom SOAP orto-
gonalne rozszerzenia, jak np. podpis elektroniczny, można związać z treścią komunikatu
przenoszonego w kopercie SOAP. W rozdziale 3. szczegółowo omawiamy mechanizm
SOAP oraz funkcjonalność nagłówków.
36 Java. Usługi WWW. Vademecum profesjonalisty
Warstwy tego stosu są dobrze zdefiniowane, czy to przez standardowe protokoły sieciowe,
czy też przez samą specyfikację SOAP. Stos ten grupuje zbiór najszerzej akceptowa-
nych i najlepiej rozwiniętych technologii związanych z usługami sieciowymi.
Po prawej stronie rysunku 1.2 znajdujÄ… siÄ™ trzy pionowe kolumny reprezentujÄ…ce stowarzy-
szone technologie mające wpływ na różne warstwy stosu połączenia. Na przykład bezpie-
czeństwo może się pojawiać na każdym poziomie, np. SSL na poziomie protokołu siecio-
wego oraz podpis elektroniczny na poziomie rozszerzeń SOAP. Pojawienie się jednego
standardu obejmującego wszystkie kwestie bezpieczeństwa usług sieciowych jest wątpliwe.
Rozdział 5. zawiera szczegółowe informacje w kontekście obecnych technologii związa-
nych z usługami sieciowymi, a dotyczące podpisów elektronicznych w formacie XML
oraz kryptografii XML. Pozostałe kolumny zostały opisane jako Jakość usług oraz Zarzą-
dzanie. Jest to tylko garść aspektów, które mogą się pojawiać na różnych poziomach stosu
połączenia. Jeszcze nie ma dla nich ustalonych standardów, ale prace trwają.
Stos połączenie dotyka tylko podstawowych możliwości usług sieciowych. Nawet w naj-
prostszych przypadkach użycia usług sieciowych widać potrzebę możliwości współpracy
na wyższym poziomie.
Rozważmy następującą sytuację (dokładnie prześledzimy ten przykład w rozdziale 3.).
Firma dostarczyła usługi sprawdzania zaopatrzenia, dzięki czemu klienci mogą sprawdzać,
czy w magazynie znajduje się określona liczba produktów o danym numerze. Parame-
trami wywołania usługi sieciowej są napis reprezentujący numer urządzenia oraz liczba
całkowita oznaczająca liczbę sztuk, na jakie jest zapotrzebowanie. Jeżeli firma dyspo-
nuje pożądaną liczbą produktów, usługa zwraca wartość logiczną ; w przeciwnym
przypadku wynikiem jest .
Z punktu widzenia protokołu SOAP interakcja z usługą jest łatwa, jednak sprawy się
komplikują, gdy wezmiemy pod uwagę liczbę informacji, jaka musi być dzielona przez
klienta i dostawcę usługi. Minimalny zasób danych, którymi musi dysponować klient
usługi, to:
Adres usługi sieciowej.
Wiedza o tym, że komunikaty będą przekazywane po HTTP.
Wiedza o tym, że należy korzystać z SOAP 1.1.
Wiedza o tym, że dane powinny być kodowane w standardzie SOAP.
Informacja, że żądania powinny mieć postać wywołań RPC z dwoma parametrami
typu napisowego i liczbowego oznaczajÄ…cymi odpowiednio numer produktu
i liczbÄ™ sztuk.
Informacja, że odpowiedzi będą efektem wywołań RPC o typie logicznym i będą
oznaczały wynik sprawdzenia podanego warunku.
Dodajmy do tego bezpieczeństwo, opłaty, obsługę błędów oraz inne funkcje konieczne
do budowy poważnych systemów opartych na usługach sieciowych, a zobaczymy, że wy-
magany zasób wspólnych informacji jest jeszcze większy. W jaki sposób klient usługi
Rozdział 1. Wprowadzenie do usług sieciowych 37
może zdobyć te informacje? Tradycyjnie, usługi sieciowe publikowały opis swoich moż-
liwości w formie dokumentów czytelnych dla człowieka. Projektanci systemów czytali te
opisy i konfigurowali aplikacje klienckie pod kątem komunikacji ze wskazanymi usługami.
Takie rozwiązanie może działać, ale z wielu powodów nie jest skalowalne:
Wymaga kosztownej (pod względem czasowym i pieniężnym), ręcznej konfiguracji
przez wyszkolony, a więc nieliczny personel.
Jest narażone na błędy, ponieważ nie wykorzystuje formalnych specyfikacji usług.
Wyklucza automatyczne wyszukiwanie i korzystanie z usług sieciowych
konfiguracja aplikacji klienckiej wymaga a priori wiedzy o dostępnych usługach.
Nie istnieją żadne mechanizmy informowania o zmianach oraz odtwarzania po
awarii; za każdym razem, gdy usługa się w jakiś sposób zmienia, istnieje ryzyko,
że w aplikacjach klienckich pojawią się błędy.
Z tych właśnie powodów liderzy przemysłu IT opracowują standardy wchodzące w skład
stosu opisu. Rysunek 1.3 przedstawia stos opisu usługi.
. .
Stos opisu usługi
Kluczowym elementem architektury zorientowanej na usługi jest sam opis usługi. Publi-
[ Pobierz całość w formacie PDF ]