Piotr Czapiewski Wydział Informatyki ZUT. Web Services Description Language.

Prezentacja na temat: "Piotr Czapiewski Wydział Informatyki ZUT. Web Services Description Language."— Zapis prezentacji:

1 Piotr Czapiewski Wydział Informatyki ZUT

2 Web Services Description Language

3 Ułatwienie dostępu do usług Automatyczne generowanie koduWsparcie IDE Określenie interfejsu usługi sieciowej Dostępne operacje Wymagane parametry Stosowane typy danych Użyte protokoły Lokalizacja usługi (URI) Format XML Niezależny od platformyŁatwe automatyczne przetwarzanieCzytelny dla maszyny i człowieka

4 1.0 2000r.Microsoft, IBM, Ariba 1.1 2001 r.W3C Note 1.2 2002 r.W3C Draft 2.0 2007 r.W3C Recommendation

5 Usługa (service)Port (port)Wiązanie (binding)Typ portu (port type)Operacja (operation)Wiadomość (message)Element (element)

6

7  Usługa określona jako zbiór punktów końcowych (endpoint, port)  Abstrakcyjna definicja portów i wiadomości jest odseparowana od konkretnej realizacji, co pozwala na powtórne użycie definicji  Port definiowany jest poprzez skojarzenie adresu sieciowego z wiązaniem (binding)  Wiązanie (binding) – konkretny protokół i specyfikacja formatu danych dla określonego typu portu  Operacje i komunikaty są wiązane z konkretnym protokołem sieciowym i formatem wiadomości  Typy portów (port type) – abstrakcyjne kolekcje udostępnianych operacji  Komunikaty (message) – abstrakcyjne definicje przesyłanych danych  Niestandardowe typy danych używane przez usługę są definiowane w WSDL w postaci XML Schema

8  Element główny – definitions  Docelowa przestrzeń nazw – targetNamespace

9  Definicje abstrakcyjne  types  message interfejs programistyczny  portType  Definicje konkretne  binding  service sposób wywołania interfejsu

10

11  Definicje typów w postaci schematów XML  Dowolna liczba elementów schema z przestrzeni nazw http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema  Podstawowa struktura elementu types:  Wewnątrz elementu schema można użyć dowolnej konstrukcji XML Schema (definicji typów prostych, typów złożonych i elementów)

12

13  Definicja abstrakcyjnego komunikatu, służącego jako dane wejściowe lub wyjściowe operacji  Komunikat składa się z co najmniej jednego elementu part  Elementy message oraz part muszą posiadać nazwy (za pomocą nazwy odwołujemy się do nich z innych miejsc definicji WSDL)  Z każdym elementem part związany jest atrybut:  element – gdy komunikat zawiera dokument XML lub  type – gdy komunikat zawiera wywołanie RPC message part...

14  Dla usługi przesyłającej w komunikatach wywołania RPC:  Elementy part reprezentują parametry metody  Atrybut name określa nazwę elementu w konkretnym komunikacie  Atrybut type określa strukturę elementu  Dla usługi przesyłającej dokumenty XML:  Elementy part odwołują się do elementów XML umieszczonych w treści

15  Przykład definicji komunikatów odwołujących się do elementów po ich nazwie

16  Definicja realizowanych operacji portType = interfejs  Element portType zawiera dowolną liczbę elementów operation  Podstawowa struktura elementu portType: portType operation...

17  Każdy element portType musi posiadać unikalną nazwę  Każdy element operation zawiera kombinację elementów input i output, może także zawierać elementy fault  Elementy input, output i fault muszą odwoływać się do definicji komunikatu (przez podanie nazwy)

18

19  Szczegóły dotyczące stosowania konkretnego elementu portType z wybranym protokołem  Za pomocą atrybutu type określamy, który element portType jest opisywany  Jednemu portType może odpowiadać wiele wiązań  Dla każdej operacji element binding zawiera element operation, a także kilka elementów rozszerzenia  Wiązanie musi posiadać unikalną nazwę binding operation...

20

21  Wiązanie SOAP do HTTP dla interfejsu MathInterface

22  Element soap:binding – wiązanie w standardzie SOAP 1.1  Atrybut style – domyślny sposób wykorzystania usługi (document lub rpc)  Atrybut transport – wymagany protokół transportowy (tutaj: HTTP)

23  Element soap:operation definiuje wartość nagłówka HTTP SOAPAction dla danej operacji  Atrybut use elementu soap:body określa sposób kodowania fragmentów komunikatu wewnątrz elementu body (literal lub encoded)

24  Document / literal

25  Rpc/encoded

26

27  Definicja kolekcji elementów port i endpoint, które udostępniają poszczególne wiązania w sieci  Podstawowa struktura elementu service:  Każdemu portowi nadajemy nazwę (atrybut name) i przypisujemy wiązanie (atrybut binding)  Element rozszerzenia definiuje adres wiązania

28  Udostępnienie wiązania MathSoapHttpBinding pod adresem http://localhost/math/math.asmxhttp://localhost/math/math.asmx

29  Dokument WSDL opisuje usługę sieciową za pomocą:  Komunikatów (message)  Operacji (operation)  Interfejsów (portType)  Wiązań (binding)  Punktów końcowych (endpoint)  Dokument WSDL zawiera wszystkie informacje potrzebne do skorzystania z usługi  Definicja WSDL pozwala na generowanie kodu:  Aplikacji serwera  Aplikacji klienta

30  Wsparcie przez narzędzia wciąż ograniczone  Standard bardziej ogólny i uporządkowany  Najważniejsze zmiany  Komunikaty scalone z operacjami  Zmiana terminu Port Type na Interface  Zmiana terminu Port na Endpoint  Operacje rozszerzone o możliwość opcjonalnych odpowiedzi  Szersze wsparcie obsługi błędów  Dopuszczenie wiązania do wszystkich metod HTTP – lepsze wsparcie dla RESTful web services