Samouczek dotyczący usług sieciowych SOAP: Czym jest protokół SOAP?

Co to jest MYDŁO?

SOAP to oparty na XML protokół dostępu do usług sieciowych przez HTTP. Jego specyfikacje mogą być stosowane we wszystkich aplikacjach.

SOAP znany jest jako Simple Object Access Protocol, ale później został skrócony do SOAP v1.2. SOAP to protokół, czyli innymi słowy definicja sposobu, w jaki usługi sieciowe komunikują się ze sobą lub z aplikacjami klienckimi, które je wywołują.

SOAP został opracowany jako język pośredni, aby aplikacje zbudowane w różnych językach programowania mogły łatwo komunikować się ze sobą i unikać ekstremalnego wysiłku programistycznego.

Wprowadzenie do SOAP

W dzisiejszym świecie istnieje ogromna liczba aplikacji tworzonych w różnych językach programowania. Na przykład, może to być aplikacja internetowa zaprojektowana w Java, inny w .Net i inny w PHP.

Wymiana danych między aplikacjami jest kluczowa w dzisiejszym świecie sieciowym. Ale wymiana danych między tymi heterogenicznymi aplikacjami byłaby złożona. Podobnie złożoność kodu do realizacji tej wymiany danych.

Jedną z metod radzenia sobie z tą złożonością jest wykorzystanie XML (Extensible Markup Language) jako języka pośredniczącego do wymiany danych pomiędzy aplikacjami.

Każdy język programowania może zrozumieć język znaczników XML. Dlatego też jako podstawowe medium wymiany danych wykorzystano XML.

Nie ma jednak standardowych specyfikacji dotyczących wykorzystania XML we wszystkich językach programowania do wymiany danych. Właśnie tutaj pojawia się oprogramowanie SOAP.

SOAP został zaprojektowany do pracy z XML przez HTTP i ma pewną specyfikację, która może być używana we wszystkich aplikacjach. Przyjrzymy się bliżej szczegółom protokołu SOAP w kolejnych rozdziałach.

Zalety SOAP-u

SOAP to protokół używany do wymiany danych pomiędzy aplikacjami. Poniżej znajduje się kilka powodów, dla których używa się protokołu SOAP.

• Kiedy się rozwijaping Usługi sieciowe oparte na protokole SOAP wymagają języka, za pomocą którego usługi sieciowe mogą komunikować się z aplikacjami klienckimi. SOAP to idealne medium opracowane w tym celu. Protokół ten jest również rekomendowany przez konsorcjum W3C, które jest organem zarządzającym wszystkimi standardami sieciowymi.
• SOAP to lekki protokół używany do wymiany danych między aplikacjami. Zwróć uwagę na słowo kluczowe „lekki. Ponieważ programowanie SOAP opiera się na języku XML, który sam w sobie jest lekkim językiem wymiany danych, protokół SOAP również należy do tej samej kategorii.
• Protokół SOAP został zaprojektowany tak, aby był niezależny od platformy i systemu operacyjnego. Dzięki temu protokół SOAP może działać z dowolnymi aplikacjami opartymi na języku programowania na obu platformach. Windows oraz Linux platformy.
• Działa w oparciu o protokół HTTP – SOAP działa w oparciu o protokół HTTP, który jest domyślnym protokołem używanym przez wszystkie aplikacje webowe. Dlatego nie ma potrzeby dokonywania żadnych dostosowań, aby usługi webowe zbudowane w oparciu o protokół SOAP działały w sieci WWW.

Bloki konstrukcyjne SOAP

Specyfikacja SOAP definiuje coś, co jest znane jako „komunikat SOAP„, czyli to, co jest wysyłane do usługi sieciowej i aplikacji klienckiej.

Poniższy diagram architektury SOAP przedstawia różne bloki składowe komunikatu SOAP.

Komunikat SOAP to nic innego jak zwykły dokument XML zawierający poniższe komponenty.

• An Koperta Element identyfikujący dokument XML jako komunikat SOAP – jest to część zawierająca komunikat SOAP i służy do hermetyzacji wszystkich szczegółów komunikatu SOAP. Jest to element główny komunikatu SOAP.
• A Nagłówek Element zawierający informacje nagłówkowe – Element nagłówka może zawierać informacje, takie jak dane uwierzytelniające, z których może korzystać aplikacja wywołująca. Może również zawierać definicje typów złożonych, które mogą być używane w komunikacie SOAP. Domyślnie komunikat SOAP może zawierać parametry, które mogą być typami prostymi, takimi jak ciągi znaków i liczby, ale mogą również być złożonymi typami obiektów.

Poniżej przedstawiono prosty przykład usługi SOAP o złożonym typie. Załóżmy, że chcemy wysłać ustrukturyzowany typ danych, który zawiera kombinację „Nazwy samouczka” i „Samouczka”. Description”, wówczas zdefiniowalibyśmy typ złożony, jak pokazano poniżej. Typ złożony jest definiowany przez znacznik elementu Następnie wszystkie wymagane elementy struktury wraz z odpowiadającymi im typami danych są definiowane w kolekcji typów złożonych.

<xsd:complexType>
   <xsd:sequence>
      <xsd:element name="Tutorial Name" type="string"/>
      <xsd:element name="Tutorial Description" type="string"/>
   </xsd:sequence>
</xsd:complexType>

A Ciało Element zawierający informacje o wywołaniu i odpowiedzi – Ten element zawiera rzeczywiste dane, które muszą zostać przesłane między usługą sieciową a aplikacją wywołującą. Poniżej znajduje się przykład usługi sieciowej SOAP z treścią SOAP, która faktycznie działa na typie złożonym zdefiniowanym w sekcji nagłówka. Poniżej znajduje się odpowiedź z samouczka. Nazwa i samouczek. Descriptwysyłany do aplikacji wywołującej, która wywołuje tę usługę sieciową.

<soap:Body>
   <GetTutorialInfo>
      <TutorialName>Web Services</TutorialName>
      <TutorialDescription>All about web services</TutorialDescription>
   </GetTutorialInfo>
</soap:Body>

Struktura komunikatu SOAP

Należy zauważyć, że komunikaty SOAP są zwykle generowane automatycznie przez usługę internetową po jej wywołaniu.

Za każdym razem, gdy aplikacja kliencka wywołuje metodę w usłudze sieciowej, usługa sieciowa automatycznie generuje komunikat SOAP zawierający niezbędne szczegóły danych, które zostaną wysłane z usługi sieciowej do aplikacji klienckiej.

Jak omówiono w poprzednim temacie tego samouczka dotyczącego protokołu SOAP, prosta wiadomość SOAP składa się z następujących elementów:

• Element koperty
• Element nagłówka i
• Element ciała
• Element błędu (opcjonalnie)

Przyjrzyjmy się przykładowi prostej wiadomości SOAP i zobaczmy, co właściwie robi każdy jej element.

1. Jak widać z powyższego komunikatu SOAP, pierwszą częścią komunikatu SOAP jest element koperty używany do hermetyzacji całego komunikatu SOAP.
2. Następnym elementem jest treść protokołu SOAP zawierająca szczegóły faktycznej wiadomości.
3. Nasza wiadomość zawiera usługę internetową o nazwie „Guru„99WebService”.
4. "Guru„99Webservice” akceptuje parametr typu „int” i ma nazwę TutorialID.

Teraz powyższy komunikat SOAP zostanie przekazany pomiędzy usługą internetową a aplikacją kliencką.

Jak przydatne są powyższe informacje dla aplikacji klienckiej, widać na przykładzie komunikatu SOAP. Komunikat SOAP informuje aplikację kliencką o nazwie usługi sieciowej, oczekiwanych parametrach oraz typie każdego parametru przyjmowanego przez usługę sieciową.

Element koperty SOAP

Pierwszym elementem bloku konstrukcyjnego jest koperta SOAP.

Koperta SOAP służy do kapsułkowania wszystkich niezbędnych szczegółów komunikatów SOAP wymienianych pomiędzy usługą internetową a aplikacją kliencką.

Element koperty SOAP służy do wskazania początku i końca komunikatu SOAP. Dzięki temu aplikacja kliencka wywołująca usługę internetową wie, kiedy komunikat SOAP się zakończy.

Poniższe punkty można zauważyć w elemencie koperty SOAP.

• Każda wiadomość SOAP musi mieć element Envelope (koperta) nadrzędny. Element Envelope jest absolutnie obowiązkowy dla wiadomości SOAP.
• Każdy element koperty musi mieć co najmniej jeden element mydła.
• Jeśli element Envelope zawiera element nagłówkowy, nie może zawierać więcej niż jednego elementu i musi występować jako pierwszy element podrzędny Envelope, przed elementem body.
• Koperta zmienia się, gdy zmieniają się wersje protokołu SOAP.
• Procesor SOAP zgodny z wersją 1.1 generuje błąd po odebraniu komunikatu zawierającego przestrzeń nazw koperty w wersji 1.2.
• Procesor SOAP zgodny z wersją 1.2 generuje błąd Niezgodność wersji, jeśli otrzyma komunikat niezawierający przestrzeni nazw koperty wersji 1.2.

Poniżej znajduje się przykład interfejsu API SOAP w wersji 1.2 elementu koperty SOAP.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
   <soap:Body>
      <Guru99WebService xmlns="http://tempuri.org/">
         <TutorialID>int</TutorialID>
      </Guru99WebService>
   </soap:Body>
</SOAP-ENV:Envelope>

Komunikat o usterce

Po wysłaniu żądania do usługi sieciowej SOAP, zwracana odpowiedź może mieć jedną z dwóch form: pomyślną odpowiedź lub odpowiedź z błędem. Po wygenerowaniu pomyślnej odpowiedzi, serwer zawsze będzie wysyłał komunikat SOAP. Jeśli jednak wystąpią błędy SOAP, zostaną one zwrócone jako błędy „HTTP 500”.

Komunikat o błędzie SOAP składa się z następujących elementów.

1. <faultCode> – To kod oznaczający kod błędu. Kod usterki może przyjmować jedną z poniższych wartości:
   1. SOAP-ENV:VersionMismatch – Dzieje się tak, gdy napotkano nieprawidłową przestrzeń nazw dla elementu koperty SOAP.
   2. SOAP-ENV:MustUnderstand — bezpośredni element podrzędny elementu Header z atrybutem mustUnderstand ustawionym na „1” nie został zrozumiany.
   3. SOAP-ENV:Client – ​​Wiadomość została nieprawidłowo utworzona lub zawierała nieprawidłowe informacje.
   4. SOAP-ENV:Server – Wystąpił problem z serwerem, więc wiadomość nie mogła być kontynuowana.
2. – Jest to wiadomość tekstowa zawierająca szczegółowy opis błędu.
3. (Opcjonalny) – Jest to ciąg tekstowy wskazujący, kto spowodował usterkę.
4. (Fakultatywny) – Jest to element komunikatów o błędach specyficznych dla aplikacji. Dlatego aplikacja może wyświetlać konkretny komunikat o błędzie dla różnych scenariuszy logiki biznesowej.

Przykład komunikatu o błędzie

Poniżej podano przykład komunikatu o błędzie. Błąd jest generowany w scenariuszu, w którym klient próbuje użyć metody o nazwie TutorialID w klasie GetTutorial. Poniższy komunikat o błędzie jest generowany w przypadku, gdy metoda nie istnieje w zdefiniowanej klasie.

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
      <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
      <faultstring xsi:type="xsd:string">
         Failed to locate method (GetTutorialID) in class (GetTutorial)
      </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Wyjście:

Po wykonaniu powyższego kodu zostanie wyświetlony błąd: „Nie udało się znaleźć metody (GetTutorialID) w klasie (GetTutorial)”.

Model komunikacji SOAP

Cała komunikacja poprzez SOAP odbywa się poprzez protokół HTTP. Przed SOAP wiele usługi internetowe używał standardowego stylu RPC (Remote Procedury Call) do komunikacji. Był to najprostszy rodzaj komunikacji, jednak miał wiele ograniczeń.

W tym samouczku dotyczącym interfejsu API SOAP, przyjrzyjmy się poniższemu diagramowi, aby zobaczyć, jak działa ta komunikacja. W tym przykładzie załóżmy, że serwer hostuje usługę internetową, która udostępnia 2 metody:

• Pobierz pracownika – Spowoduje to otrzymanie wszystkich danych o pracownikach.
• Ustaw pracownika – Spowoduje to odpowiednie ustawienie wartości szczegółów, takich jak dział pracownika, pensja itp.

W normalnej komunikacji w stylu RPC klient po prostu wywołałby metody w swoim żądaniu i wysłał wymagane parametry do serwera, a serwer następnie wysłałby żądaną odpowiedź.

Powyższy model komunikacji ma następujące poważne ograniczenia:

1. Niezależny od języka – Serwer hostujący metody będzie działał w określonym języku programowania i zazwyczaj wywołania do serwera będą wykonywane wyłącznie w tym języku programowania.
2. Nie standardowy protokół – W przypadku wywołania procedury zdalnej połączenie nie jest realizowane poprzez standardowy protokół. Był to problem, ponieważ przeważnie cała komunikacja w Internecie musiała odbywać się za pośrednictwem protokołu HTTP.
3. Zapory – Ponieważ wywołania RPC nie przechodzą przez normalny protokół, na serwerze muszą być otwarte oddzielne porty, aby umożliwić klientowi komunikację z serwerem. Zwykle wszystkie zapory sieciowe blokują tego rodzaju ruch i zazwyczaj wymagana jest duża ilość konfiguracji, aby zapewnić, że tego rodzaju komunikacja między klientem a serwerem będzie działać.

Aby ominąć wszystkie powyższe ograniczenia, protokół SOAP musiałby użyć poniższego modelu komunikacji.

1. Klient formatował informacje dotyczące wywołania procedury i wszelkich argumentów do komunikatu SOAP i wysyłał go do serwera jako część żądania HTTP. Ten proces enkapsulacji danych w komunikacie SOAP był znany jako Przetaczanie.
2. Serwer następnie rozpakowywał wiadomość wysłaną przez klienta, sprawdzał, o co klient poprosił, a następnie odsyłał odpowiednią odpowiedź do klienta w postaci komunikatu SOAP. Praktyka rozpakowywaniaping żądanie wysłane przez klienta jest znane jako Demarshalling.

Praktyczny przykład SOAP

Teraz w tym SoapUI W tym samouczku pokażemy praktyczny przykład SOAP. Prawdopodobnie jednym z najlepszych sposobów na zobaczenie, jak generowane są komunikaty SOAP, jest zobaczenie usługi sieciowej w działaniu.

W tym temacie omówione zostanie użycie MicrosoftFramework .Net do budowy usługi sieciowej ASMX. Ten typ usługi internetowej obsługuje zarówno wersję SOAP 1.1, jak i wersję 1.2.

Usługi sieciowe ASMX automatycznie generują plik Język definicji usług internetowych (WSDL) dokument. Ten dokument WSDL jest wymagany przez wywołującą aplikację kliencką, aby aplikacja wiedziała, co potrafi usługa internetowa.

W naszym przykładzie utworzymy prostą usługę internetową, która będzie używana do zwracania ciągu znaków do aplikacji wywołującej usługę internetową. Ta usługa internetowa będzie hostowana w Asp.Net Aplikacja internetowa. Następnie wywołamy usługę internetową i zobaczymy wynik zwrócony przez usługę internetową.

Visual Studio pokaże nam również, jaki jest komunikat SOAP przesyłany między usługą sieciową a aplikacją wywołującą. Pierwszy warunek wstępny konfiguracji naszej aplikacji usługi sieciowej można spełnić, wykonując poniższe kroki. Upewnij się, że w tym przykładzie w systemie jest zainstalowany program Visual Studio 2013.

Krok 1) Pierwszym krokiem jest utworzenie pustej aplikacji ASP.Net Web. W Visual Studio 2013 kliknij opcję menu File->New project.

Po kliknięciu opcji Nowy projekt, Visual Studio wyświetli kolejne okno dialogowe do wyboru typu projektu i podania niezbędnych szczegółów projektu. Jest to wyjaśnione w następnym kroku.

Krok 2) W tym etapie,

1. Najpierw wybierz C# Szablon internetowy aplikacji internetowej ASP.NET. Projekt musi być tego typu, aby utworzyć projekt usług SOAP. Po wybraniu tej opcji, program Visual Studio wykona niezbędne kroki w celu dodania wymaganych plików, które są potrzebne dowolnej aplikacji internetowej.
2. Podaj nazwę swojego projektu, która w naszym przypadku to webservice.asmx. Następnie podaj lokalizację, w której będą przechowywane pliki projektu.

Po zakończeniu zobaczysz plik projektu utworzony w eksploratorze rozwiązań w programie Visual Studio 2013.

Krok 3) W tym kroku dodamy plik usługi sieciowej do naszego projektu.

1. Najpierw kliknij prawym przyciskiem myszy plik projektu, jak pokazano poniżej.

2. Po kliknięciu prawym przyciskiem myszy pliku projektu możesz wybrać opcję „Dodaj->Usługa sieciowa (ASMX)”, aby dodać plik usługi sieciowej. Wystarczy podać nazwę usługi samouczka dla pliku usługi sieciowej.

Krok 4) Dodaj poniższy kod do pliku asmx usługi Tutorial Service.

Code Wyjaśnienie:

1. Ten wiersz kodu zawiera nazwę pliku usługi internetowej. Jest to ważny krok, ponieważ umożliwia aplikacji klienckiej wywołanie usługi internetowej za pośrednictwem nazwy usługi internetowej.
2. Zwykle plik klasy jest używany do enkapsulacji funkcjonalności usługi internetowej. Zatem plik klasy będzie zawierał definicję wszystkich metod sieciowych, które zapewnią pewną funkcjonalność aplikacji klienckiej.
3. Tutaj [WebMethod] jest znany jako atrybut opisujący funkcję. Kolejny krok tworzy funkcję o nazwie „Guru99WebService”, ale dzięki dodaniu atrybutu [WebMethod] zapewnia możliwość wywołania tej metody przez aplikację kliencką. Jeśli ten atrybut nie jest obecny, metoda nigdy nie będzie mogła zostać wywołana przez aplikację kliencką.
4. Tutaj definiujemy funkcję o nazwie „Guru99WebService”, która zostanie użyta do zwrócenia ciągu znaków do wywołującej aplikacji klienckiej. Ta funkcja jest usługą sieciową, którą może wywołać dowolna aplikacja kliencka.
5. Używamy instrukcji return, aby zwrócić ciąg „To jest Guru99 Usługa internetowa” dla aplikacji klienckiej.

Jeśli kod zostanie wykonany pomyślnie, po uruchomieniu kodu w przeglądarce zostanie wyświetlony następujący komunikat.

Wyjście:

• Na wyjściu wyraźnie widać, że nazwa naszej usługi sieciowej to „Guru99 Web Service”, co jest wynikiem nadania nazwy naszej usłudze internetowej.
• Widzimy również, że możemy wywołać usługę internetową. Kliknięcie przycisku „Wywołaj” spowoduje wyświetlenie poniższej odpowiedzi w przeglądarce internetowej.

Powyższe dane wyjściowe:

• Wyraźnie widać, że poprzez wywołanie metody sieciowej, ciąg „To jest GuruZwracana jest wartość „99 Web service”.
• Program Visual Studio umożliwia również przeglądanie żądania i odpowiedzi komunikatu SOAP, które są generowane po wywołaniu powyższej usługi sieciowej.

Poniżej pokazano żądanie SOAP generowane podczas wywoływania usługi internetowej.

Code Wyjaśnienie:

1. Pierwszą częścią komunikatu SOAP jest element koperty, omówiony w poprzednich rozdziałach. Jest to element enkapsulujący, obecny w każdym komunikacie SOAP.
2. Następnym elementem jest treść komunikatu SOAP, która zawiera faktyczne szczegóły komunikatu SOAP.
3. Trzecia część to element określający, że chcemy wywołać usługę o nazwie „Guru99Usługa sieciowa'.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <Guru99WebServiceResponse xmlns="http://tempuri.org/">
         <Guru99WebServiceResult>string</Guru99WebServiceResult>
      </Guru99WebServiceResponse>
   </soap:Body>
</soap:Envelope>

Code Wyjaśnienie:

1. Pierwszą częścią komunikatu SOAP jest element koperty, omówiony w poprzednich rozdziałach. Jest to element enkapsulujący, obecny w każdym komunikacie SOAP.
2. Następnym elementem jest treść komunikatu SOAP, która zawiera faktyczne szczegóły komunikatu SOAP.
3. Ciekawą częścią, którą teraz zobaczysz, jest atrybut „string”. Informuje on aplikację kliencką, że wywoływana usługa sieciowa zwraca obiekt typu string. Jest to bardzo przydatne, ponieważ w przeciwnym razie aplikacja kliencka nie wiedziałaby, co zwraca usługa sieciowa.

FAQ