Co to jest usługa sieciowa...

Jako że najlepiej tłumaczy się na przykładzie, dlatego ja również nim się posłużę. Wyobraźmy sobie taką sytuację, gdzie dokonujemy transakcji płatniczych przy pomocy karty kredytowej. Potrzebna jest metoda sprawdzania tej karty. Oczywiście można taką metodę umieszczać w każdej aplikacji dla każdego sklepu, stacji benzynowej czy restauracji. Jednak aplikacje te nie mają i najprawdopodobniej nigdy nie będą miały ze sobą nic wspólnego, dlatego ten sam algorytm należałoby umieścić w każdej z nich. Kolejny przykład: co jakiś czas Narodowy Bank Polski publikuje kursy walut. Jak w odpowiednim czasie powiadomić wszystkie kantory i inne banki o zmianie ceny waluty? Właśnie tutaj z pomocą przychodzą usługi sieciowe (usługi internetowe). Są to metody udostępniane w sieci, z których mogą korzystać inne aplikacje. W powyższych przykładach usługa taka umieszczona byłaby na serwerze banku.  Wtedy pisząc aplikację kliencką jedyne co musimy zrobić to odwołać się do tej metody. Odwołanie następuje poprzez sieć (Internet). Takie rozwiązanie ma wiele zalet, jedną z nich jest fakt, że wszelkie zmiany (np. zmiana algorytmu walidacji karty) dokonywane będą tylko w jednym miejscu. Drugą zaletą jest to, że programiści aplikacji klienckich nie muszą znać algorytmów wykorzystanych w usłudze.

Jak zacząć

Aby móc korzystać z usług internetowych, należy mieć odpowiednią ilość dostępnego miejsca na dysku jakiegoś serwera WWW, na którym umieścimy naszą aplikację świadczącą usługi poprzez Internet. W artykule zarówno usługa jak i aplikacja kliencka będzie umieszczona na lokalnym komputerze (localhost), na którym wcześniej uruchomiono usługę WWW. W systemie Windows można taką usługę uruchomić instalując Internet Information Services (IIS), Internetowe Usługi Informacyjne. Po skonfigurowaniu i uruchomieniu serwera WWW konieczne jest również zarejestrowanie ASP.NET w wersji 1.1 w usłudze WWW. Jednym ze sposobów jest uruchomienie instalatora znajdującego się w domyślnym katalogu instalacyjnym Microsoft .NET Framework

Technologia
Pierwszym etapem tworzenia usługi internetowej jest wybór sposobu komunikacji pomiędzy serwerem świadczącym tę usługę a klientem. Najlepszym kanałem byłby kanał bezpołączeniowy, stąd też technologie takie jak DCOM, CORBA czy JAVA RMI nie nadają się do tego. Protokołami w pełni dostosowanymi do pracy w sieci są HTTP (Hypertext Transfer Protocol) oraz SMTP (Simple Mail Transfer Protocol). Ten pierwszy działa na zasadzie żądanie/odpowiedź, natomiast drugi zapewnia rutowalny protokół wymiany informacji w ramach komunikacji asynchronicznej. Kolejnym problemem w dzisiejszym Internecie jest problem zabezpieczeń. Oba wspomniane protokoły z reguły są udostępniane w przedsiębiorstwach oraz administratorzy pozostawiają otwarte porty do pracy dla tych protokołów. HTTP zapewnia komunikację bezpołączeniową, tzn. nie korzysta z nieprzerwanego połączenia z klientem. Natomiast SMTP będąc asynchronicznym w przypadku niepowodzenia w transmisji danych dokonuje próby jej wznowienia.

Kolejnym krokiem jest wybór schematu kodowania dla przesyłanych danych. Doskonale nadaje się do tego XML (Extensible Markup Language). Jest on niezależny od platformy, oferuje obsługę wspólnego systemu typów oraz standardowych zbiorów znaków. W XML oferującym kodowanie tekstowe uniknięto problemów z konwencją kodowania liczb na różnych platformach (little endian na Intelu, czy big endian na innych). Z problemami tymi muszą borykać się wspomniane wcześniej technologie DCOM, CORBA czy JAVA RMI. Ponadto niektóre protokoły, jak np.: SMTP korzystają tylko z tekstowych schematów kodowania.

Dalej potrzebna jest jednolita konwencja formatowania. Konieczne stało się uniezależnienie treści wiadomości od zastosowanego protokołu. Jeśli bowiem wysyłając wiadomość do wielu miejsc przeznaczenia, wiadomość ta musiałaby być transportowana przez wiele różnych protokołów, to informacje o routingu, zawarte np.: w nagłówku HTTP musiały by być przetłumaczone do nagłówka SMTP etc. Aby tego uniknąć należy zawrzeć dane o wiadomości razem z jej treścią, w nagłówku wiadomości. Dlatego stworzono protokół SOAP (Simple Object Access Protocol). Wiadomość SOAP zawiera kopertę Envelope, która składa się z sekcji Head będącej nagłówkiem oraz Body zawierającej treść wiadomości.

Na potrzeby opisywania usług sieciowych stworzono specjalny język WSDL (Web Services Description Language). Dokumentacja usługi stworzona w tym języku zapewnia informacje na temat wzorców wiadomości przesyłanych od i do klienta, użytego protokołu, czy w końcu adresu usługi. Dokument WSDL jest zapisany na dysku w formacie XML.

Ostatnim problemem jest lokalizacja usługi. Jeśli jest to sieć lokalna to należy poinformować potencjalnych użytkowników o miejscu jej przechowywania, jeśli usługa ma być udostępniona w Internecie to sprawa wygląda nieco bardziej skomplikowanie. Wykorzystuje się tutaj mechanizm ogłaszania usług zawarty w specyfikacji UDDI (Universal Description, Discovery, and Integration). Tym jednak nie będziemy się tu zajmować.

Testowanie usługi
Dokumentacja WSDL udostępnia nam mechanizmy do testowania usługi. Klikając nazwę metody ValueQuery otwieramy stronę zawierająca pole na wpisanie wartości.