Java 1 - Kolos

Transkrypt

Java 1 - Kolos

Uniwersytet Łódzki
Wydział Matematyki i Informatyki,
Katedra Analizy Nieliniowej
Web Services
wykład 9
Programowanie w Javie 2
mgr inż. Michał Misiak
Agenda






Ewolucja sieci komputerowych
Co to jest Web Service
Dlaczego i do czego można użyć WS
Architektura i standardy dla WS
API dla WS w Javie oraz J2EE dla WS
Narzędzia dla WS
Wydział Matematyki i Informatyki UŁ, Katedra Analizy Nieliniowej, M.Misiak © 2008

Coraz większe przepływności


Koncepcja zaadresowania wszystkich urządzeń:



możliwa z użyciem protokołu IPv6
Adresy będą posiadać: samochody, urządzenia domowe, etc …
Architektura rozproszona aplikacji


Technologie transmisji danych: WDM, DWDM,
Nowe protokoły: HTTP, SMTP, LDAP, SOAP, UDDI,
Powstanie koncepcji Software as a Service

Możliwość zakupu dostępu do aplikacji w trybie
abonamentowym, a nie konkretnego pliku wykonawczego

Ewolucja platform
 Protokoły
pomiędzy platformami
 Ilość urządzeń w sieci

Ewolucja wzorców komunikacji:
 Klient-Serwer
3
warstwowy model
 Aplikacje Webowe
 Web Services
 Sieć P2P
Definicja usługi sieciowej W3C






Usługa sieciowa jest aplikacją
Aplikacja identyfikowana poprzez URI
Interfejsy WS są definiowane, opisane i odkrywane za pomocą
języka XML
Umożliwia interakcję pomiędzy innymi aplikacjami
Wykorzystuje XML do budowy wiadomości
Transportem mogą być znane protokoły internetowe
“A Web service is a software application identified by a URI, whose interfaces and
binding are capable of being defined, described and discovered by XML
artifacts and supports direct interactions with other software applications
using XML based messages via internet-based protocols” (definicja W3C)
RPC vs WS






Wewnątrz przedsiębiorstw
Związany z określonym
zbiorem języków
programowania
Proceduralny
Związany z określonym
protokołem transportowym
Komponenty ściśle powiązane
Wydajne przetwarzanie






Wykracza poza granice
przedsiębiorstwa
Niezależny od języku
programowania
Asynchroniczny, komunikacja
za pomocą wiadomości
Niezależny od protokołu
(standardowo używany jednak
z HTTP)
Komponenty luźno powiązane
(loosly copuled)
Niewydajne przetwarzanie
Aplikacja Web vs WS


Interakcja pomiędzy
użytkownikiem, a
programem
Z góry założona struktura
kompletów widziana
przez użytkownika



Komunikacja pomiędzy
programami
Możliwość dynamicznej
integracji różnych
komponentów
Możliwość
integracji/agregacji wielu
usług w jednym miejscu
Cechy WS








Bazuje na XML (format danych definiowany przez XML, opis WS w
XML, etc…)
Opiera się na komunikacji asynchronicznej – przesyłanie
wiadomości
Niezależna od języka programowania (istotne jedynie poprawne
generowanie wiadomości pod kątem semantycznym i
syntaktycznym)
Może być dynamicznie rozmieszczana
Możliwość dynamicznego składania lub agregacji
Dostęp w sieci internet
Charakter pozwalający stosować w sieciach rozproszonych
Bazuje na standardzie zaakceptowanym przez przemysł
Przykład architektury WS
Rejestr Usług Siecowych
UDDI
Definicja Usługi Sieciowej
Web Services Broker
WSDL
WSDL
ZNAJDŹ
REJESTRUJ
Serwer Aplikacyjny Parlay
Brama Parlay Web Services
PRZYWIĄŻ
Logika
usługi
KOMUNIKACJA
Usługa Sieciowa
Framework
Aplikacje Parlay
Interfejs
Aplikacyjny
Parlay X
SOAP
Web Services Requestor
Web Services Provider
Możliwość asemblacji WS
użytkownik
WS1
Zagregowana WS
wspierająca
proces biznesowy
WS2
WS3
WS…N
Dlaczego WS?





Umożliwiają współpracę pomiędzy różnymi
technologiami po przez sieć Internet
Możliwość wielokrotnego wykorzystania komponentów
Automatyczna komunikacja bez konieczności ingerencji
człowieka
Dostępne niezależnie od urządzenia, miejsca i czasu
Brak ograniczeń jeśli chodzi o stosowanie oraz
możliwość wykorzystania w różnych heterogenicznych
środowiskach i aplikacjach
Przykład WS
Możliwość realizacji transakcji pomiędzy przedsiębiorcami
bez koniczności inwestycji w infrastrukturę IT
Łatwość integracji rozwiązań przedsiębiorców
Możliwość częstej zmiany potencjalnych dostawców
Dystrybutor
soap
Dostawca
Internet
Wytwórca
Ewolucja aplikacji z wykorzystaniem WS





WS jest to pewna funkcjonalność (logika biznesowa) wystawiona w
sieci Internet dla innych podmiotów
Aplikacje monolityczne zostają rozłożone na komponenty, z których
można korzystać poprzez sieć
WS nie są czytane bezpośrednio przez człowieka
WS posiadają budowę modularną
Przykład: międzynarodowy system transakcji giełdowych:
Możliwość obserwacji wybranych walorów (WS dla instytucji w każdym
kraju dostarczające takie informacje)
 Możliwość założenia konta oraz przeprowadzania transakcji (WS dla
biura maklerskiego obsługującego daną giełdę)
 Możliwość zapoznania się z komunikatami giełdowymi (WS dla
dostawców wiadomości)

Network Effect



Network Effect jest prawem
odkrytym/wymyślonym przez Metclafe
Wartość sieci jest proporcjonalna do kwadratu
liczby użytkowników sieci
Przykład ilustrujący
Mity związane z WS




WS musi być transportowany z wykorzystaniem
protokołu HTTP (NIE)
WS bazuje na paradygmacie RPC (NIE)
WS wymaga jedynie bazowych komponentów:
SOAP, WSDL, UDDI (NIE)
WS jest nową koncepcją wykorzystywaną w
aplikacjach rozproszonych (NIE)
Rozwój WS


Ciągły rozwój standardu WS w zakresie: SOAP,
WSDL, UDDI
Konieczność rozbudowy architektury o funkcje
wspierające zastosowania biznesowe WS:
 QoS
 Bezpieczeństwo,
transakcje
 Udostępnianie, rozliczanie
Elementy architektury WS




Opis usługi sieciowej (service description) – opis
rozumiany globalnie
Rejestracja usługi sieciowej (service registration)
Odkrywanie usługi sieciowej (service discovery)
Wywoływanie usługi sieciowej (service
invocation)
Architektura WS
Registry
Publish
Find
Rejestracja usługi
Web service
Żądanie odszukania
lokalizacji usług
Bind
Service client
Klient woła usługę
SOAP


Simple Object Access Protocol
Protokół połączeniowy bardzo podobny do:

IIOP dla CORBA
 JRMP dla RMI

XML wykorzystywany do kodowania informacji
Protokół czytelny dla człowieka, potencjalny problem z efektywnym
przetwarzaniem
 Określa zasady opakowywania danych



Wspiera XML-RPC
Specyfikacja SOAP 1.2 w ramach zaleceń W3C
Część 1: definiuje kopertę oraz szkielet powiązania z protokołem
 Część 2: określa model danych oraz powiązanie z HTTP

Definicja SOAP zgodnie z W3C



SOAP jest lekkim protokołem zaprojektowanym
w celu wymiany strukturalizowanej informacji w
decentralizowanym rozproszonym środowisku
SOAP wykorzystuje XML jako narzędzie do
tworzenia wiadomości, które mogą być
przenoszone na różnego rodzaju protokołach
SOAP jest niezależny od konkretnego modelu
programistycznego
Cechy SOAP




Prosty
Roszerzalny
Bezstanowy
Paradygmat jednokierunkowej wymiany wiadomości:


Oczywiście aplikacje mogą tworzyć bardziej złożone wzorce wymiany
wiadomości (req/resp,…) w zależności od potrzeb
SOAP nie mówi nic na temat


Semantyki przenoszonych danych
Routing wiadomości SOAP
 Niezawodność
 Trawersowanie NAT

SOAP określa zestaw akcji jakie węzeł może wykonać na
wiadomości
Dodatkowe specyfikacje WS





WS-Security – określa wykorzystanie szyfrowania XML oraz
podpisu XML w ramach SOAP w celu zabezpieczenia wymiany
wiadomości. Jako alternatywę podaje się HTTPS
WS-Reliability – Standard protokołu przygotowany przez OASIS dla
niezawodnego przekazywania wiadomości
WS-ReliableMessaging – protokół dla niezawodnego przekazywania
wiadomości przygotowany przez MS, BEA, IBM i aktualnie
standaryzowany przez OASIS
WS-Addressing – sposób opisu adresu odbiorcy i nadawcy
wiadomości w ramach wiadomości SOAP
WS-Transaction – sposób w jaki będą zapewnione transakcje
Struktura wiadomości SOAP
Koperta wiadomości SOAP

Informacje zagnieżdżone



Nagłówek




Przestrzenie nazw
Informacja na temat kodowania
Opcjonalny
Może być przetwarzany przez węzły pośredniczące
Zawiera informacje na temat: bezpieczeństwa, transakcji
Ciało



Obowiązkowy
Obrabiany wyłącznie przez końcowego odbiorcę
Zawiera: dane aplikacji bądź wywołania metod RPC
Nagłówek wiadomości SOAP

Wykorzystywany do tworzenia rozszerzeń
 Autentykacja
 Transakcje
 Zarządzanie
 Kontekst

wiadomości
Zbudowana z bloków nagłówków
Bloki nagłówka SOAP


Elementy będące dziećmi nagłówka SOAP (env:Header)
Wykorzystywane do przenoszenia różnych informacji
wymaganych węzłów pośredniczących



Może być obsługiwany przez wskazany węzeł
Pozwala na realizację węzłom pośredniczącym dodatkowych
usług
Elementy nagłówka mogą być:

Przeglądane, kasowane, wstawiane, przekazywane dalej w
ramach ścieżki wiadomości SOAP
Ciało wiadomości SOAP <env:Body>



Składa się z bloków ciała (body blocks, body
entries)
Przetwarzana/odczytywana wyłączenie przez
użytkownika końcowego
Przenosi informacje koniec-koniec
 Dane
aplikacji
 Wywołania metod RPC i ich parametrów
 Błędy SOAP
Obsługa błędów SOAP


Wykorzystywane do przenoszenia informacji o
błędach bądź statusach
Zbudowany z 4 elementów:
 Faultcode
 Faultstring
 Faultactor
 Detail

Informacja o błędach jest w postaci czytelnej dla
człowieka
Predefiniowane błędy SOAP

VesionMismatch


MustUnderstand


Odbiorca nie może przetworzyć bloku nagłówka
MustUnderstand
Client


W kopercie SOAP został użyty błędny namespace
Wskazuje błąd po stronie klienta np. niepoprawnie
sformatowana wiadomość, brak jakieś części
Server

Wskazuje błąd po stronie serwera, np. informacja o brak
możliwości przetworzenia wiadomości
Jakie dane w nagłówku jakie w
ciele wiadomości?


Decyzja w kwestii, które dane umieścić, w której
części powinny być podjęte w trakcie
projektowania aplikacji
Dane przenoszone w ramach nagłówka mogą
być przeznaczone dla różnych węzłów
pośredniczących
Terminologia protokołu SOAP







Węzeł SOAP (SOAP node) – element odpowiedzialny za
przetworzenie wiadomości zgodnie z założonymi regułami
Rola SOAP (SOAP role) – odbiorca SOAP oczekuje w trakcie
przetwarzania wiadomości.
Przywiązanie SOAP (SOAP Binding) – zbiór reguł na jakich będzie
przenoszona wiadomość SOAP w ramach innego protokołu np. w
ramach entity body protokołu HTTP
Cechy SOAP (SOAP Features) – rozszerzenie środowiska SOAP
zapewniającego: niezawodność, bezpieczeństwo, transakcje
Moduł SOAP (SOAP Module)
Wzorzec wymiany wiadomości SOAP – określa w jaki sposób będą
przesyłane wiadomości pomiędzy węzłami w ramach danego
protokołu transportu
Aplikacja SOAP
Odbiorcy i nadawcy wiadomości





Nadawca SOAP
Odbiorca SOAP
Ścieżka wiadomości SOAP
Początkowy nadawca SOAP
Pośrednik SOAP



Jednocześnie nadawca i odbiorca SOAP
Przetwarza bloki nagłówka SOAP
Końcowy odbiorca SOAP


Końcowe przeznaczenie wiadomości SOAP
Odpowiedzialny za przetworzenie treści wiadomości
Model wymiany wiadomości SOAP


SOAP jest prostym środowiskiem do wymiany informacji
wyspecyfikowanej w języku XML pomiędzy końcowym
odbiorcą i początkowym nadawcą
Typowy scenariusz zawiera serie wymienionych
wiadomości



Np. dla wzorca żądanie – odpowiedź
Model konwersacyjny request-response, w którym
wymieniane są dokumenty XML
Model RPC
RPC

Elementy wymagane przy RPC
 Adres
docelowego węzła SOAP
 Procedura lub nazwa metody
 Informacja na temat argumentów i rezultatów
 Separacja argumentów wykorzystywanych do
identyfikacji zasobów oraz argumentów
przenoszonych jako dane lub informacje sterujące
Załączniki w SOAP

Wykorzystanie MIME jako kontener dla:
 Koperty
SOAP
 Dodatkowych załączników

Koperta SOAP oraz zawartość SOAP może
wskazywać na załączniki za pomocą URL

Java 1 - Kolos

Transkrypt

Podobne dokumenty

Programowanie w środowisku sieciowym B. Informacje szczegółowe

Programowanie w środowisku sieciowym

Ulotka - MEDI-line