Mydło i spółka Aplikacje rozproszone Serwisy sieciowe

Mydło i spółka Aplikacje rozproszone Serwisy sieciowe

Mydło i spółka ☺
Aplikacje rozproszone
Serwisy sieciowe –
protokół SOAP
(Simple Object Access Protokol)
Po co (ź
(źródło):
rozproszenie przetwarzania dla uniknięcia wąskich gardeł
gardeł
RPC (Remote
(Remote Procedure Call)
Call)
Nowsze: CORBA, RMI, DCOM
odizolowanie interfejsó
interfejsów od szczegó
szczegółów
implementacyjnych poszczegó
poszczególnych platform
Klient i serwer muszą
muszą używać
ywać tej samej technologii
Technologie te zaprojektowano z myś
myślą o
zastosowaniach lokalnych (intranet) co z firwallem ?
Wybrane zagadnienia Systemów Rozproszonych
2
Serwisy sieciowe, WWW
(Web Services)
Broker
usług
dostę
dostępne poprzez sieć
sieć komponenty aplikacyjne
przeznaczonym do wykorzystania przez inne aplikacje,
zwane aplikacjami klienckimi
hermetyzowane, luź
luźno skojarzone “kontraktowane”
kontraktowane”
funkcje, oferowane poprzez standardowe protokoł
protokoły.
Serwisy sieciowe
Wyszukiwanie
Publikowanie
Internet
„Hermetyzowane”
Hermetyzowane”: implementacja nigdy nie jest widoczna z
zewnątrz.
“Luźno skojarzone”
skojarzone”: modyfikowanie danej implementacji nie
generuje problemu propagacji zmiany.
“Kontraktowane”
Kontraktowane” opisy dział
działania funkcji oraz specyfikacja ich
interfejsó
interfejsów jest publicznie dostępna
Żądający
usługi
Komunikaty w XML
3
Połączenie
z usługą
Dostawca
usługi
protokó
protokół nie jest binarny
zakł
zakłada się
się użycie HTTP (ominię
(ominięcie problemu zapó
zapór
ogniowych), choć
ć
mogą
ą
to
być
ć
też
ż
inne
protokoł
cho mog
by te
protokoły
4
Krótka historia standardu SOAP
Technologie serwisów sieciowych
WSWS-Inspection (Web Services
Inspection Language)
Language)
RDF (Resource
(Resource Description
Framework)
Framework)
DAML (DARPA Agent Markup
Language)
Language)
ebXML
UDDI
Microsoft, DevelopMentor i Userland
WSDL
SOAP
XML
Podstawowym zakł
zakładanym zastosowaniem Web Services
był
było B2B.
Praktyka wykazał
wykazała, że obecnie lepiej rozwijają
rozwijają się
się jednak
jako środek integracji informacyjnej przedsię
przedsiębiorstwa
J2EE (przeważ
(przeważa)
.NET
5
6
Co to jest SOAP?
Charakterystyka standardu
jest protokołem przeznaczonym do wymiany
Software(US)
ITEF (Internet Engineering Task Force) oficjalna rekomendacja standardu
1998 Dave Winer z US ogłosił specyfikacje
XML-RPC
IBM, Lotus, Compaq, Intel, IONA Technologies
specyfikacja 1.1 SOAP - opublikowana przez
W3C
struktur informacji w rozproszonym środowisku
zawiera trzy główne składniki:
Envelope (koperta): opisuje co znajduje się w
wysyłanym żądaniu i kto je ma odebrać
reguły kodowania typów danych
SOAP-RPC reprezentacja wywołania zdalnej
procedury i jej wyniku
7
posiada przejrzystą konstrukcję i jest łatwy w
stosowaniu
niezależny od konkretnych języków programowania i
implementacji
używa technologii XML i przestrzenie nazw
wiadomości mogą być wymieniane poprzez szereg
podrzędnych protokołów, najczęściej HTTP
definiuje dwie struktury opracowane przez W3C: sposób
kodowania danych i format komunikatów
może być użyty do przekazywania pomiędzy dwiema
aplikacjami prawie wszystkich rodzajów danych
8
Struktura komunikatu SOAP
Cechy standardu
Składa się z trzech węzłów:
protokół przewiduje działania pośredników,
używanie nazw jest obowiązkowe dla pozycji nagłówka; dla
ciała komunikatu jest nieobowiązkowe
gdzie umieszczać informację
istnieje tu pewna dowolność, pozostawiająca decyzję
projektantowi aplikacji;
dane zawarte w pozycjach nagłówkowych mogą być
przetwarzane i uzupełniane przez pośredników
SOAP envelope:
wersja używanego SOAP,
atrybuty określające
kodowanie przesłanych danych
SOAP header:
dodatkowe informacje
wykorzystywane do przetwarzania
komunikatu
SOAP body: treść komunikatu,
sformatowane dane, nazwę
wywoływanej procedury
Envelope-Element
Header-Element
(opcjonalnie)
Body-Element
9
10
Element Envelope
Element Header
<SOAP-ENV:Envelope
xmlns:SOAP-ENV= „http://www.w3.org/2002/06/soapenvelope”
xmlns:xsi=„http://www.w3.org/2001/XMLSchemainstance”
xmlns:xsd=„http://www.w3.org/2001/XMLSchema”>
<SOAP-ENV:Header>
...
<SOAP-ENV:Header>
<SOAP-ENV:Body>
...
<SOAP-ENV:Body>
<SOAP-ENV:Envelope>
11
bloki nagłówkowe (header blocks) zawierające
informacje potrzebne do przetworzenia komunikatu
pozycja nagłówkowa jest opisywana przez atrybuty:
role - adresat danej pozycji
mustUnderstand - czy pozycja musi zostać
przetworzona przez jej adresata
<SOAP-ENV:Header>
<m:transaction xmlns:m=„soap-transaction”
SOAP-ENV:mustUnderstand=„true”>
<transactionID>1234</transactionID>
< m:transaction>
<SOAP-ENV:Header>
12
Model wymiany komunikatów
RPC
Element Body – kodowanie danych
właściwa treść komunikatu
dane przeznaczone dla ostatecznego odbiorcy
atrybut encodingStyle – sposób kodowania
przesyłanych danych
podstawowy typ kodowania http://www.w3.org/2002/06/soap-encoding
www.w3.org/2001/XMLSchema-instance
www.w3.org/2001/XMLSchema
typy: proste, złożone, referencje
1 Aplikacja A koduje
w komunikacie
protokołu SOAP zdalną
procedurę wywołania (RCP)
SOAP
2 Komunikat protokołu SOAP jest
kapsułkowany w HTTP,
można go wysłać poprzez sieć Internet
3 Aplikacja B dekoduje żądanie
SOAP i działa zgodnie z nim
SOAP
HTTP
INTERNET
SOAP
Aplikacja A
4 Aplikacja B wysyła wynik
do aplikacji A, wykorzystując inny
komunikat protokołu SOAP
Aplikacja B
13
14
SOAP: realizacja modelu RPC
Zasada działania protokołu SOAP
15
wołanie odległej procedury wymaga podania:
adres węzła docelowego
nazwa procedury/metody
wszystkie argumenty przekazywane do metody
wyraźne wyodrębnienie danych służących identyfikacji od
danych przeznaczonych do przetwarzania
dodatkowe informacje w postaci pozycji nagłówkowych
wszystkie przekazane argumenty opatrzone są informacją o
typie, zgodną z systemem typów XML Schema
URI pozwalające zlokalizować właściwą metodę jest
przekazywane w sposób zależny od protokołu
16
Wołanie RPC – ciało komunikatu
Odpowiedź RPC
POST /soap/servlet/rpcrouter HTTP/1.0
Host: localhost:8081
Content-Type: text/xml; charset=utf-8
Content-Length: 451
SOAPAction: ""
<?xml version=’1.0’ encoding=’UTF-8’?>
<SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:add xmlns:ns1="urn:Calculator"
SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<a xsi:type="xsd:float">2.3</a>
<b xsi:type="xsd:float">3.5</b>
</ns1:add>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: 446
Date: Sun, 15 Dec 2002 23:15:58 GMT
Server: Apache Tomcat/4.0.4 (HTTP/1.1 Connector)
<?xml version=’1.0’ encoding=’UTF-8’?>
<SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:addResponse xmlns:ns1="urn:Calculator"
SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:float">5.8</return>
</ns1:addResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
18
17
Sygnalizowanie błędów
przetwarzania
Podsumowanie - ogólne zasady
MUSI być kodowany przy użyciu XML-a
MUSI mieć element Envelope
MOŻE mieć element Header
MUSI mieć element Body
MUSI używać odpowiednich przestrzeni nazw
NIE MOŻE zawierać referencji do DTD
NIE MOŻE zawierać instrukcji procesora XML-a
Standardowe kody błędów:
Sender – komunikat został niewłaściwie
sformułowany
Receiver – błąd po stronie odbiorcy; np. brak
połączenia z wymaganym zasobem lub inną usługą
MustUnderstand – obowiązkowa do przetworzenia
pozycja nagłówkowa nie została zrozumiana
DataEncodingUnknown – węzeł-adresat nie rozumie
zastosowanego kodowania danych
VersionMismatch – przesłany komunikat nie został
zawarty w odpowiednio nazwanej kopercie
19
20
Zalety standardu SOAP
Wady standardu SOAP
opiera się na XML
niezależny zarówno od języka i od platformy
otwartość języka XML oraz ogólna dostępność
kodowanie danych jest mało wydajne,
komunikaty są kodowane w formie tekstu,
wykorzystują więcej pasma niż równoważne
analizatorów jego składni ułatwiają pisanie
aplikacji
dużo łatwiejszy w zastosowaniu
przenika przez „zapory ogniowe”
komunikaty binarne,
muszą być przekształcane do postaci binarnej,
by aplikacja mogła na nich działać.
rozwiązanie - analizatorów składni XML,
rozbudowane aplikacje i zwiększenie obciążenia
CPU
21
22
23
24
SOAP i spółka ☺
Universal Description, Discovery and
Integration Service - UDDI
UDDI
określa wspó
wspólny zbió
zbiór interfejsó
interfejsów programistycznych dla technologii SOAP,
umożliwiając implementację brokeró
brokerów usł
usług
Przedsiębiorstwa prowadzące operacje w Internecie realizują dostęp do
usł
usług sieciowych za pośrednictwem rejestru UDDI,
któ
który ma za zadanie nawiązać kontakt pomiędzy poszukującym usł
usługi a
oferującym ją
Rejestry UDDI zawierają:
informacje o Web Services na bazie nazwy usł
usługodawcy, jego adresu, kategorii
biznesowej, informacji technicznej i tym podobne informacje,
operacje dotyczące usł
usługi, to jest: rejestracji, wyszukiwania i korzystania z
usł
usługi,
szczegó
szczegóły udostępniane przez niskopoziomowy interfejs programistyczny.
UDDI - książ
ka telefoniczna:
książka
yellow pages – umoż
umożliwiają
liwiają wyszukiwanie usł
usług, któ
które
należą
należą do konkretnej kategorii, znajdują
znajdują się
się w danym
regionie geograficznym,
white pages – zawierają
zawierają informacje na temat dostawcy
usł
usługi, wraz z adresem, kontaktem i znanymi
identyfikatorami,
green pages – informacje techniczne na temat usł
usług, na
przykł
przykład jak się
się komunikować
komunikować z Web Services
Tego rodzaju rejestr stanowi niezbę
niezbędną
dną podstawę
podstawę dla
realizacji koncepcji rozwinię
rozwiniętej wspó
współpracy B2B
opartej na Web Services
UDDI posiadają dwa rodzaje klientó
klientów: usł
usługodawcó
ugodawców publikujących swoje
usł
usługi oraz klientó
klientów wyszukujących usł
usług, z któ
których chcą skorzystać.
25
Web Services Description Language
usł
usługi Web Services są publikowane w rejestrze e
biznesowym UDDI.. Istnieją
Istnieją generatory plikó
plików WSDL
na podstawie komponentó
komponentów programowych [27].
Dokument WSDL opisuje, co oferuje usł
usługa, gdzie jest
umieszczona oraz jak z niej skorzystać
skorzystać .
26
Przykłady użycia SOAP
D. Cools
„Applying soft computing
algorithms to e-business using web
services”
WSDL opisuje technikę
technikę wspó
współdział
działania z usł
usługą
ugą. Zakł
Zakłada,
że semantyka usł
usługi jest opisana na zewną
zewnątrz i moż
może być
być
jednoznacznie wskazana poprzez identyfikator. Tym
samym „kontrakt”
kontrakt” dotyczą
dotyczący znaczenia i celu jest
oddzielony od „kontraktu”
kontraktu” okreś
określają
lającego mechanikę
mechanikę
wspó
współdział
działania.
Specyfikacja zatem nie zajmuje się
się problemem
definiowania semantyki usł
usługi.
27
28
JAXB – generuje klasy Javy ze schemató
schematów XML za
pomocą
).
pomocą kompilatora schemató
schematów (xjc
(xjc).
Przykłady cd.
. NET, J2EE
Java API for XMLXML-based RPC (JAX
(JAX--RPC)
RPC)
Java API for XML Registries (JAXR)
Java Architecture for XML Binding (JAXB)
SOAP with Attachments API for Java
DOM, SAX
unmarshalling - zamiana pliku XMLXML-owego na obiekty Javove,
Javove,
modyfikacja dokumentu XMLXML-owego (na kopii z pamię
pamięci),
walidacja - sprawdzenie poprawnoś
poprawności z DTD (takż
(także
dokonywane na dokumencie w pamię
pamięci),
marshalling - zamiana obiektó
obiektów Javowych na dokument XMLXMLowy.
.
owy
JAXP (Java API for XML Processing)
29
JAX-RPC
30
Dodatkowe informacje na temat SOAP
31
http://www.perfectxml.com/Soaparticles.asp
http://www.w3.org/TR/SOAP
http://www.soaprpc.com/
http://www.soapware.org/
32