Samouczek dotyczący usług sieciowych SOAP: Co to jest protokół SOAP? PRZYKŁAD

Co to jest MYDŁO?

SOAP to protokół oparty na języku XML umożliwiający dostęp do usług internetowych za pośrednictwem protokołu HTTP. Ma pewne specyfikacje, które można wykorzystać we wszystkich zastosowaniach.

SOAP jest znany 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 zbudowanych w różnych językach programowania. Na przykład może istnieć aplikacja internetowa zaprojektowana w Java, kolejny w .Net i kolejny 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 stosowania XML we wszystkich językach programowania do wymiany danych. I tu z pomocą przychodzi 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.

• Tworząc usługi internetowe oparte na protokole SOAP, musisz znać język, którego można używać, aby usługi sieciowe mogły komunikować się z aplikacjami klienckimi. SOAP jest idealnym medium, które zostało opracowane w tym celu. Protokół ten jest również zalecany 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, stąd SOAP jako protokół również należy do tej samej kategorii.
• SOAP jest zaprojektowany tak, aby był niezależny od platformy i systemu operacyjnego. Tak więc protokół SOAP może obsługiwać dowolne aplikacje oparte na języku programowania na obu Windows oraz Linux Platforma.
• Działa na protokole HTTP – SOAP działa na protokole HTTP, który jest domyślnym protokołem używanym przez wszystkie aplikacje internetowe. Dlatego też, aby usługi sieciowe zbudowane na protokole SOAP działały w sieci WWW, nie jest wymagane żadne dostosowywanie.

Bloki konstrukcyjne SOAP

Specyfikacja SOAP definiuje coś, co jest znane jako „komunikat SOAP”, co jest wysyłane do usługi internetowej 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.

• Element Envelope, który identyfikuje dokument XML jako komunikat SOAP – Jest to część zawierająca komunikat SOAP i służy do enkapsulacji wszystkich szczegółów w komunikacie SOAP. Jest to element główny w komunikacie SOAP.
• Element nagłówka zawierający informacje nagłówka – Element nagłówka może zawierać informacje, takie jak poświadczenia uwierzytelniania, które mogą być używane przez wywołującą aplikację. Może również zawierać definicję złożonych typów, które mogą być używane w wiadomości SOAP. Domyślnie wiadomość SOAP może zawierać parametry, które mogą być prostych typów, takich jak ciągi znaków i liczby, ale mogą być również złożonym typem obiektu.

Poniżej przedstawiono prosty przykład usługi SOAP typu złożonego.

Załóżmy, że chcemy wysłać ustrukturyzowany typ danych, który zawiera kombinację „Nazwy samouczka” i „Samouczka Descriptjon”, wówczas zdefiniujemy 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 ich odpowiednimi 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>

• Element Body zawierający informacje o wywołaniu i odpowiedzi – Ten element zawiera rzeczywiste dane, które muszą zostać wysłane między usługą internetową a aplikacją wywołującą. Poniżej znajduje się przykład usługi internetowej SOAP dla ciała SOAP, który faktycznie działa na złożonym typie zdefiniowanym w sekcji nagłówka. Oto odpowiedź Tutorial Name i Tutorial 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 SOAP, prosta wiadomość SOAP ma następujące elementy –

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

Przyjrzyjmy się poniższemu przykładowi prostego komunikatu SOAP i zobaczmy, co faktycznie robi 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 „Guru99WebService”.
4. Usługa „Guru99Webservice” akceptuje parametr typu „int” i ma nazwę TutorialID.

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

Możesz zobaczyć jak przydatne są powyższe informacje dla aplikacji klienckiej. Komunikat SOAP informuje aplikację kliencką, jaka jest nazwa usługi internetowej, a także jakich parametrów oczekuje, a także jakiego typu jest każdy parametr pobierany 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żdy komunikat SOAP musi mieć główny element Envelope. Absolutnie obowiązkowe jest, aby wiadomość SOAP zawierała element koperty.
• 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 SOAP API 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

Kiedy żądanie jest kierowane do usługi internetowej SOAP, zwrócona odpowiedź może mieć dwie formy: odpowiedź pomyślna lub odpowiedź na błąd. Gdy zostanie wygenerowany sukces, odpowiedzią z serwera będzie zawsze komunikat SOAP. Jeśli jednak zostaną wygenerowane błędy protokołu SOAP, zostaną one zwrócone jako błędy „HTTP 2”.

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

1. – Jest to kod oznaczający kod błędu. Kod błędu może mieć dowolną 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. (Opcjonalny) – 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 przypadku scenariusza, w którym klient próbuje użyć metody o nazwie TutorialID w klasie GetTutorial.

Poniższy komunikat o błędzie zostanie wygenerowany 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 wyświetli się błąd „Nie udało się zlokalizować 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 protokołu 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, takie jak

• Pobierz pracownika – To spowoduje pobranie wszystkich danych pracownika
• 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 poniższe poważne ograniczenia

1. Niezależny od języka – Serwer hostujący metody będzie w określonym języku programowania i zwykle wywołania serwera będą prowadzone tylko 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 pokonać wszystkie ograniczenia wymienione powyżej, SOAP użyłby poniższego modelu komunikacji

1. Klient sformatuje informacje dotyczące wywołania procedury i wszelkich argumentów w komunikat SOAP i wyśle ​​​​go do serwera jako część żądania HTTP. Ten proces enkapsulacji danych w komunikacie SOAP był znany jako Przetaczanie.
2. Następnie serwer rozpakuje wiadomość wysłaną przez klienta, sprawdzi, o co prosił klient, a następnie odeśle odpowiednią odpowiedź do klienta w postaci wiadomości SOAP. Praktyka rozpakowywania żądania wysłanego przez klienta jest znana jako Demarshalling.

Praktyczny przykład SOAP

Teraz w tym samouczku SoapUI zobaczmy praktyczny przykład SOAP,

Prawdopodobnie jednym z najlepszych sposobów sprawdzenia, w jaki sposób generowane są komunikaty SOAP, jest faktyczne zobaczenie usługi internetowej 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 stworzymy prostą usługę WWW, która posłuży do zwrócenia ciągu znaków do aplikacji wywołującej usługę WWW.

Ta usługa internetowa będzie hostowana w formacie Asp.Net Aplikacja internetowa. Następnie wywołamy usługę internetową i zobaczymy wynik zwrócony przez usługę internetową.

Program Visual Studio pokaże nam również treść komunikatu SOAP przesyłanego pomiędzy usługą internetową a wywołującą aplikacją.

Pierwszym warunkiem wstępnym jest skonfigurowanie naszej aplikacji usługi sieciowej, co można zrobić, wykonując poniższe kroki.

Na potrzeby tego przykładu upewnij się, że 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 ASP.NET Web. Projekt musi być tego typu, aby utworzyć projekt usług SOAP. Wybierając tę ​​opcję, Visual Studio wykona niezbędne kroki, aby dodać wymagane pliki, które są wymagane przez dowolną aplikację internetową.
2. Nadaj swojemu projektowi nazwę, która w naszym przypadku została podana jako webservice.asmx. Następnie pamiętaj o podaniu lokalizacji, 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 etapie,

Zamierzamy dodać plik usługi internetowej do naszego projektu

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

2. Po kliknięciu prawym przyciskiem myszy pliku projektu masz możliwość wybrania opcji „Dodaj->Web Service (ASMX), aby dodać plik usługi internetowej. Wystarczy podać nazwę usługi samouczka dla pliku nazwy usługi internetowej.

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

Wyjaśnienie kodu:

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 dodanie tego kroku dodania atrybutu [WebMethod] gwarantuje, że metoda ta będzie mogła zostać wywołana przez aplikację kliencką. Jeśli ten atrybut nie jest obecny, metoda nie może zostać wywołana przez aplikację kliencką.
4. Tutaj definiujemy funkcję o nazwie „Guru99WebService”, która będzie używana do zwracania ciągu znaków do wywołującej aplikacji klienckiej. Funkcja ta jest usługą sieciową, którą można wywołać z dowolnej aplikacji klienckiej.
5. Używamy instrukcji return, aby zwrócić do aplikacji klienckiej ciąg „To jest usługa sieciowa Guru99”.

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

Wyjście:

• Dane wyjściowe wyraźnie pokazują, że nazwa naszego serwisu internetowego to „Guru99 Web Service”, co jest wynikiem nadania nazwy naszemu serwisowi internetowemu.
• Widzimy również, że możemy wywołać usługę internetową. Jeżeli klikniemy przycisk Wywołaj, w przeglądarce internetowej otrzymamy poniższą odpowiedź.

Powyższe wyjście,

• Wyraźnie widać, że po wywołaniu metody internetowej zwracany jest ciąg „To jest usługa sieciowa Guru99”.
• 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.

Wyjaśnienie kodu:

1. Pierwszą częścią komunikatu SOAP jest element koperty, co zostało omówione w poprzednich rozdziałach. Jest to element hermetyzujący, który jest 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 „Guru99WebService”.

<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>

Wyjaśnienie kodu:

1. Pierwszą częścią komunikatu SOAP jest element koperty, co zostało omówione w poprzednich rozdziałach. Jest to element hermetyzujący, który jest 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ż aplikacja kliencka, która w przeciwnym razie nie wiedziałaby, co zwraca usługa sieciowa.

Podsumowanie

• SOAP to protokół służący do wymiany danych pomiędzy aplikacjami zbudowanymi na różnych platformach języki programowania.
• SOAP jest zbudowany w oparciu o specyfikację XML i współpracuje z protokołem HTTP. Dzięki temu idealnie nadaje się do stosowania w aplikacjach internetowych.
• Elementy składowe SOAP składają się z komunikatu SOAP. Każdy komunikat SOAP składa się z elementu koperty, nagłówka i elementu treści.
• Element koperty jest obowiązkowym elementem komunikatu SOAP i służy do hermetyzacji wszystkich danych w komunikacie SOAP.
• Element nagłówka może służyć do przechowywania informacji, takich jak dane uwierzytelniające lub definicja złożonych typów danych.
• Element body jest głównym elementem, który zawiera definicję metod sieciowych wraz z wszelkimi informacjami o parametrach, jeśli są wymagane.