WSDL — omówienie

Aaron Skonnard
Northface University

październik 2003 roku

Dotyczy:
   usługi XML Web Service
   język Web Services Description Language (WSDL) 1.1
   WS-I Basic Profile w wersji 1.0
   przesyłanie komunikatów XML
   schematy XML

Streszczenie:
WSDL jest bardzo ważny w całej architekturze usług XML Web Service, ponieważ opisuje pełny kontrakt komunikacji aplikacji. Definicje WSDL znacznie ułatwiają dostęp do usług XML Web Service, pozwalając na generowanie kodu, który umożliwia współpracę aplikacji z opisywaną usługą bez szczegółowego wnikania w odbywający się za pośrednictwem różnych protokołów proces wysyłania i odbierania komunikatów SOAP. Długość dokumentu — około 18 stron drukowanych.

Spis treści

Wprowadzenie
Podstawy WSDL
Element types
Elementy message
Interfejsy (elementy portType)
Elementy binding
Elementy service
Edytory WSDL
Gdzie jesteśmy?
Bibliografia
Dodatek A — WSDL

Wprowadzenie

XML umożliwia programistom udostępnienie cennych zasobów w sposób wysoce interoperacyjny, przy czym zasobem może być dowolny typ aplikacji lub magazyn danych wykorzystywany w firmie. Architektura usług XML Web Service definiuje standardowy mechanizm udostępniania zasobów za pośrednictwem komunikatów XML. Możliwość uzyskania dostępu do zasobów poprzez przesyłanie komunikatów XML za pomocą jednego ze standardowych protokołów transportowych (takich jak TCP, HTTP lub SMTP) znacznie obniża poprzeczkę dla potencjalnych klientów. Termin „usługa XML Web Service” (lub po prostu „usługa”) zazwyczaj odnosi się do kodu implementującego interfejs XML dla zasobu, do którego może być trudno uzyskać dostęp w inny sposób (ilustracja 1).

Ilustracja 1. Zasoby i usługi

Dzięki takiej architekturze dowolny klient, obsługujący XML, może zostać zintegrowany z aplikacją udostępniającą usługę XML Web Service. Aby to osiągnąć, klienci muszą z góry precyzyjnie ustalić interfejs XML wraz z różnymi szczegółami komunikatów. Schematy XML częściowo zaspokajają tę potrzebę, ponieważ pozwalają programistom opisać strukturę komunikatu XML. Sam schemat XML nie może jednak posłużyć do opisania dodatkowych szczegółów dotyczących komunikacji z tą usługą.

Definicja schematu określa, jakie komunikaty XML mogą być użyte, ale nie mówi nic o tym, jaki mają ze sobą związek. Jeśli na przykład istnieje element XML o nazwie Add oraz element o nazwie AddResponse, prawdopodobnie elementy te są ze sobą jakoś związane, ale nie ma możliwości zaznaczenia tego w schemacie. Dlatego klient nie tylko powinien znać szczegóły dotyczące komunikatów, ale powinien również znać możliwe metody komunikacji, obsługiwane przez daną usługę XML Web Service (np. jeśli wysłany zostanie komunikat Add, to w odpowiedzi otrzymany zostanie komunikat AddResponse).

Wymiana komunikatów jest nazywana operacją. Operacje leżą w centrum zainteresowania klientów, ponieważ to one służą do interakcji z usługą (ilustracja 2). Ilekroć korzystam z nowej usługi XML Web Service, najpierw zapoznaję się z listą obsługiwanych operacji aby dowiedzieć się, jaką funkcjonalność ma ta usługa.

Ilustracja 2. Komunikaty i operacje

Programiści są przyzwyczajeni do grupowania powiązanych ze sobą operacji w interfejsy. Klienci muszą zdawać sobie sprawę z takiego grupowania, ponieważ wpływa ono na sposób, w jaki tworzą aplikacje. Jest to przede wszystkim ważne dla programistów pracujących z usługami XML Web Service w środowisku zorientowanym obiektowo, ponieważ interfejsy XML mogą być łączone z interfejsami programistycznymi (lub klasami abstrakcyjnymi), napisanymi w wybranym języku programowania.

Klienci muszą także wiedzieć, jaki protokół komunikacyjny należy stosować do komunikacji z usługą oraz powinni znać mechanizmy związane z danym protokołem — stosowane polecenia, nagłówki i kody błędów. Wiązanie do protokołu szczegółowo określa transmisję poprzez opisanie sposobu korzystania z interfejsu w połączeniu z konkretnym protokołem komunikacyjnym. Wiązanie wpływa także na sposób kodowania abstrakcyjnych komunikatów, ponieważ określa typ zawartości komunikatu (dokument XML lub wywołanie RPC) oraz mechanizmy kodowania (na podstawie schematu XML lub reguł kodowania). Więcej informacji na ten temat można znaleźć w artykule SOAP — omówienie.

Usługa może obsługiwać kilka wiązań dla jednego interfejsu, ale każde wiązanie powinno być dostępne pod unikalnym, identyfikowanym za pomocą URI adresem, nazywanym także punktem końcowym usługi XML Web Service (ilustracja 3).

Ilustracja 3. Interfejsy i wiązania

Klienci muszą znać wszystkie opisane powyżej szczegóły, zanim zaczną korzystać z usługi XML Web Service. Język Web Services Description Language (WSDL) zapewnia gramatykę XML do opisywania tych szczegółów. Tam, gdzie kończy się funkcjonalność schematów XML, zaczyna się funkcjonalność WSDL, zapewniając możliwość grupowania komunikatów w operacje, a operacji w interfejsy. Zapewnia także sposób definiowania wiązań interfejsów do protokołów i przypisywania im adresów punktów końcowych. Pełna definicja WSDL zawiera wszystkie informacje niezbędne do korzystania z usługi XML Web Service. Programiści, którzy chcą ułatwić dostęp do swoich usług, powinni udostępnić definicje WSDL tych usług.

WSDL odgrywa ważną rolę w całej architekturze usług XML Web Service, ponieważ opisuje pełny kontrakt komunikacji aplikacji (ma podobne znaczenie jak IDL dla architektury DCOM). Chociaż istnieją inne techniki opisywania usług XML Web Service, specyfikacja WS-I Basic Profile Version 1.0 wymaga zastosowania w tym celu WSDL oraz schematów XML (ilustracja 4). Ułatwia to zachowanie interoperacyjności w warstwie opisu usługi.

Ilustracja 4. Technologie składające się na podstawowy profil usług XML Web Service — WS-I Basic Profile 1.0

Ponieważ WSDL jest językiem czytelnym dla urządzeń (jest to plik XML), można w łatwy sposób zbudować dla niego narzędzia i infrastrukturę. Programiści mogą wykorzystać definicje WSDL do wygenerowania kodu komunikującego się z usługą opisywaną przez dany plik WSDL. Generowanie kodu pozwala uniknąć trudnej implementacji wysyłania i otrzymywania komunikatów SOAP za pośrednictwem różnych protokołów, co zwiększa dostępność usługi XML Web Service.

W środowisku Microsoft® .NET Framework dostępne jest narzędzie wiersza polecenia o nazwie wsdl.exe, które służy do generowania klas na podstawie definicji WSDL. Narzędzie wsdl.exe może wygenerować klasę umożliwiającą dostęp do usługi oraz klasę implementującą usługę. Środowisko Apache Axis zawiera podobne narzędzie o nazwie WSDL2Java, które przeprowadza takie same operacje, tyle że dla klas Java. Klasy wygenerowane z tej samej definicji WSDL powinny być zdolne do komunikowania się ze sobą za pośrednictwem interfejsów zapewnionych przez WSDL — bez względu na zastosowany język programowania (ilustracja 5).

Ilustracja 5. WSDL i generowanie kodu

Język WSDL 1.1 uważany jest de facto za standard ze względu na szerokie wsparcie. Większość narzędzi do tworzenia usług XML Web Service obsługuje WSDL 1.1, ale stwierdzono pewne problemy ze współpracą pomiędzy różnymi implementacjami. Wielu programistów uważa, że duża elastyczność WSDL (i wynikająca z niej złożoność) jest podstawowym źródłem tych problemów. WS-I pomogło rozwiązać kilka problemów, zachęcając programistów do wykorzystania pewnych fragmentów specyfikacji i zniechęcając ich do korzystania z innych fragmentów.

Konsorcjum W3C aktywnie pracuje nad następną „oficjalną” wersją WSDL — WSDL 1.2, ale obecnie jest to tylko wstępny projekt, nieobsługiwany przez żaden z głównych zestawów narzędzi. W pozostałej części tego artykułu omówiono definicję WSDL 1.1 oraz niektóre propozycje dotyczące podstawowego profilu usług XML Web Service.

Podstawy WSDL

Definicja WSDL to dokument XML, którego główny element definitions jest definiowany przez przestrzeń nazw http://schemas.xmlsoap.org/wsdl/. Cały schemat WSDL jest dostępny pod adresem http://schemas.xmlsoap.org/wsdl/. Element definitions może zawierać kilka innych elementów — w tym types, message, portType, binding, service — pochodzących z przestrzeni nazw http://schemas.xmlsoap.org/wsdl/. W poniższym przykładzie zilustrowano podstawową strukturę definicji WSDL:

<!-- struktura definicji WSDL -->

<definitions

    name="MathService"

targetNamespace="http://example.org/math/"

xmlns="http://schemas.xmlsoap.or...