Czym są usługi internetowe? Architecture, typy, przykład

Co to jest usługa internetowa?

Serwis internetowy to ustandaryzowane medium propagujące komunikację pomiędzy aplikacjami klienckimi i serwerowymi w sieci WWW (World Wide Web). Usługa internetowa to moduł oprogramowania zaprojektowany do wykonywania określonego zestawu zadań.

• Usługi internetowe w chmurze obliczeniowej można wyszukiwać w sieci i można je również wywoływać.
• Po wywołaniu usługa sieciowa będzie w stanie zapewnić funkcjonalność klientowi, który wywołuje tę usługę sieciową.

Jak działają usługi sieciowe?

Powyższy diagram przedstawia bardzo uproszczony pogląd na to, jak faktycznie działałaby usługa internetowa. Klient wywoływałby serię wywołań usług sieciowych za pośrednictwem żądań kierowanych do serwera, na którym znajdowała się rzeczywista usługa sieciowa.

Żądania te są realizowane za pośrednictwem tzw. zdalnych wywołań procedur. Zdalne wywołania procedur (RPC) to wywołania metod hostowanych przez odpowiednią usługę sieciową.

Jako przykład, Amazon zapewnia usługę internetową, która zapewnia ceny produktów sprzedawanych online za pośrednictwem amazon.com. Front-end lub warstwa prezentacji może być w .Net lub Javaale oba języki programowania miałyby możliwość komunikowania się z usługą sieciową.

Głównym elementem projektu usługi internetowej są dane przesyłane pomiędzy klientem a serwerem, czyli XML. XML (rozszerzalny język znaczników) jest odpowiednikiem HTML i łatwym do zrozumienia językiem pośrednim, rozumianym przez wiele języków programowania.

Dzięki temu, gdy aplikacje komunikują się ze sobą, w rzeczywistości komunikują się w języku XML. Zapewnia to wspólną platformę dla aplikacji opracowanych w różnych językach programowania, umożliwiającą im wzajemną komunikację.

Usługi internetowe korzystają z protokołu SOAP (Simple Object Access Protocol) do przesyłania danych XML między aplikacjami. Dane są przesyłane zwykłym protokołem HTTP. Dane wysyłane z usługi internetowej do aplikacji nazywane są komunikatami SOAP. Komunikat SOAP to nic innego jak dokument XML. Ponieważ dokument jest napisany w formacie XML, aplikacja kliencka wywołująca usługę sieciową może zostać napisana w dowolnym języku programowania.

Dlaczego potrzebujesz usługi internetowej?

Współczesne aplikacje biznesowe wykorzystują różnorodne platformy programistyczne do tworzenia aplikacji internetowych. Niektóre aplikacje mogą być tworzone w Java, inni w .Net, a jeszcze inni w Angular JS, Node.js, itd.

Najczęściej te heterogeniczne aplikacje wymagają jakiejś formy komunikacji między sobą. Ponieważ są one tworzone w różnych językach programowania, zapewnienie precyzyjnej komunikacji między nimi staje się naprawdę trudne.

Tutaj właśnie pojawiają się usługi sieciowe. Usługi sieciowe zapewniają wspólną platformę, która umożliwia tworzenie wielu aplikacji zbudowanych na różnych platformach języki programowania mieć możliwość komunikowania się ze sobą.

Rodzaje usług sieciowych

Istnieją dwa główne typy usług sieciowych:

1. Usługi sieciowe SOAP.
2. RESTful usługi sieciowe.

Aby usługa sieciowa była w pełni funkcjonalna, konieczne jest wdrożenie pewnych komponentów. Komponenty te muszą być obecne niezależnie od języka programowania używanego do programowania usługi sieciowej. Przyjrzyjmy się tym komponentom bardziej szczegółowo.

SOAP (prosty protokół dostępu do obiektów)

SOAP jest znany jako protokół przesyłania komunikatów niezależny od transportu. Opiera się on na przesyłaniu danych XML w postaci komunikatów SOAP. Każdy komunikat zawiera dokument XML. Tylko struktura dokumentu XML jest zgodna z określonym wzorcem, ale nie jego treść. Największą zaletą usług sieciowych i SOAP jest to, że wszystkie dane są przesyłane za pośrednictwem protokołu HTTP, który jest standardowym protokołem sieciowym.

Oto, z czego składa się komunikat SOAP:

• Każdy dokument SOAP musi mieć element główny znany jako element. Element główny jest pierwszym elementem dokumentu XML.
• „Koperta” jest z kolei podzielona na 2 części. Pierwszy to nagłówek, drugi to treść.
• Nagłówek zawiera dane routingu, czyli informacje, które informują dokument XML, do którego klienta należy go wysłać.
• Treść będzie zawierać rzeczywistą wiadomość.

Poniższy diagram przedstawia prosty przykład komunikacji poprzez SOAP.

Omówimy szczegółowo SOAP w tym artykule Tutorial.

WSDL (usługi internetowe DescriptJęzyk jonowy)

Nie można korzystać z usługi sieciowej, jeśli nie można jej znaleźć. Klient wywołujący usługę internetową powinien wiedzieć, gdzie tak naprawdę znajduje się usługa internetowa.

Po drugie, aplikacja kliencka musi wiedzieć, co dokładnie robi usługa sieciowa, aby móc ją wywołać. Odbywa się to za pomocą języka WSDL, znanego jako usługi sieciowe. DescriptJęzyk jonowy. Plik WSDL to plik oparty na XML, który zasadniczo informuje aplikację kliencką o działaniu usługi sieciowej. Korzystając z dokumentu WSDL, aplikacja kliencka będzie w stanie zrozumieć, gdzie znajduje się usługa sieciowa i jak można z niej korzystać.

Przykład usługi internetowej

Poniżej podano przykład usług internetowych w postaci pliku WSDL.

<definitions>
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>

   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>

         <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

Ważne aspekty, na które należy zwrócić uwagę w przypadku powyższych przykładów usług sieciowych w deklaracji WSDL, są następujące:

1. – Parametr message w definicji WSDL służy do definiowania różnych elementów danych dla każdej operacji wykonywanej przez usługę sieciową. Zatem w powyższym przykładzie usług sieciowych mamy 2 komunikaty, które mogą być wymieniane między usługą sieciową a aplikacją kliencką: jeden to operacja „TutorialRequest”, a drugi to operacja „TutorialResponse”. Operacja TutorialRequest zawiera element o nazwie „TutorialID”, który jest typu string. Podobnie operacja TutorialResponse zawiera element o nazwie „TutorialName”, który również jest typu string.
2. – To w rzeczywistości opisuje operację, którą może wykonać usługa sieciowa, w naszym przypadku nazywana Tutorialem. Operacja ta może przyjmować 2 komunikaty: jeden to komunikat wejściowy, a drugi to komunikat wyjściowy.
3. – Ten element zawiera używany protokół. W naszym przypadku definiujemy go do użycia protokołu HTTP (http://schemas.xmlsoap.org/soap/http). Określamy również inne szczegóły dotyczące treści operacji, takie jak przestrzeń nazw i to, czy wiadomość ma być zakodowana.

W tym artykule omówimy szczegółowo „WSDL”. Tutorial.

uniwersalny Descriptjonizacja, odkrycie i integracja (UDDI)

UDDI to standard opisu, publikowania i odkrywania usług internetowych świadczonych przez określonego dostawcę usług. Zawiera specyfikację, która pomaga w hostingu informacji w usługach internetowych.

Teraz omówiliśmy w poprzednim temacie WSDL i jak zawiera informacje o tym, co usługa sieciowa faktycznie robi. Ale w jaki sposób aplikacja kliencka może zlokalizować plik WSDL, aby zrozumieć różne operacje oferowane przez usługę sieciową? UDDI jest więc odpowiedzią na to pytanie i zapewnia repozytorium, w którym można hostować pliki WSDL. Aplikacja kliencka będzie więc miała pełny dostęp do UDDI, który działa jak baza danych zawierająca wszystkie pliki WSDL.

Tak jak książka telefoniczna zawiera imię, nazwisko, adres i numer telefonu konkretnej osoby, tak samo rejestr UDDI będzie zawierał istotne informacje dotyczące usługi internetowej, aby aplikacja kliencka wiedziała, gdzie można go znaleźć.

Zalety usług sieciowych

Już wiemy, dlaczego usługi sieciowe w ogóle powstały – miały one na celu stworzenie platformy umożliwiającej różnym aplikacjom komunikację między sobą. Przyjrzyjmy się jednak liście zalet usług sieciowych, które pokazują, dlaczego warto z nich korzystać.

1. Udostępnianie funkcjonalności biznesowych w sieci – Usługa sieciowa to jednostka zarządzanego kodu, która zapewnia pewien rodzaj funkcjonalności aplikacjom klienckim lub użytkownikom końcowym. Funkcjonalność ta może być wywoływana za pośrednictwem protokołu HTTP, co oznacza, że ​​można ją również wywołać przez internet. Obecnie wszystkie aplikacje znajdują się w internecie, co sprawia, że ​​cel usług sieciowych jest bardziej użyteczny. Oznacza to, że usługa sieciowa może być dostępna w dowolnym miejscu w internecie i zapewniać niezbędną funkcjonalność w razie potrzeby.
2. Interoperacyjność między aplikacjami – Usługi sieciowe umożliwiają różnym aplikacjom komunikację między sobą oraz udostępnianie danych i usług. Wszystkie typy aplikacji mogą się ze sobą komunikować. Zamiast pisać specyficzny kod, zrozumiały tylko dla określonych aplikacji, można teraz pisać kod ogólny, zrozumiały dla wszystkich aplikacji.
3. Standardowy protokół, który każdy rozumie – Usługi sieciowe wykorzystują standardowy protokół branżowy do komunikacji. Wszystkie cztery warstwy (transport usług, komunikaty XML, usługi) DescriptWarstwy jonowa i Service Discovery korzystają ze ściśle zdefiniowanych protokołów w stosie protokołów usług sieciowych.
4. Obniżenie kosztów komunikacji – Usługi internetowe korzystają z protokołu SOAP poprzez protokół HTTP, dzięki czemu możesz wykorzystać istniejący, tani Internet do wdrażania usług internetowych.

Web Services Architektura

Każdy framework potrzebuje pewnego rodzaju architektury, aby zapewnić, że cały framework działa zgodnie z oczekiwaniami. Podobnie w usługach sieciowych Web Services Architektura składa się z trzech odrębnych ról, jak podano poniżej:

1. Provider – Dostawca tworzy usługę internetową i udostępnia ją aplikacjom klienckim, które chcą z niej korzystać.
2. Zleceniodawca – Osoba żądająca to nic innego jak aplikacja kliencka, która musi skontaktować się z usługą internetową. Aplikacja kliencka może być platformą .Net, Javalub jakiejkolwiek innej aplikacji opartej na języku, która poszukuje pewnego rodzaju funkcjonalności za pośrednictwem usługi sieciowej.
3. Broker – Broker to nic innego jak aplikacja zapewniająca dostęp do UDDI. UDDI, jak omówiono we wcześniejszym temacie, umożliwia aplikacji klienckiej zlokalizowanie usługi sieciowej.

Poniższy diagram przedstawia interakcje pomiędzy dostawcą usługi, wnioskodawcą usługi oraz rejestrem usług.

1. Publikować – Dostawca informuje brokera (rejestr usług) o istnieniu usługi sieciowej, korzystając z interfejsu publikacji brokera, aby udostępnić usługę klientom.
2. Znajdź – Wnioskodawca konsultuje się z brokerem w celu zlokalizowania opublikowanej usługi sieciowej.
3. Bind – Korzystając z informacji uzyskanych od brokera (rejestru usług) na temat usługi sieciowej, wnioskodawca jest w stanie powiązać usługę sieciową lub ją wywołać.

Charakterystyka usług sieciowych

Usługi sieciowe charakteryzują się następującymi szczególnymi cechami zachowania:

1. Są oparte na formacie XML – Usługi sieciowe wykorzystują XML do reprezentacji danych na poziomie reprezentacji i transportu danych. Użycie XML eliminuje wszelkie zależności od sieci, systemu operacyjnego czy platformy, ponieważ XML jest wspólnym językiem zrozumiałym dla wszystkich.
2. Luźno powiązane – Luźno powiązane oznacza, że ​​klient i usługa sieciowa nie są ze sobą powiązane, co oznacza, że ​​nawet jeśli usługa sieciowa zmienia się w czasie, nie powinna zmieniać sposobu, w jaki klient wywołuje usługę sieciową. Przyjęcie luźno powiązanej architektury sprawia, że ​​systemy oprogramowania są bardziej zarządzalne i umożliwia prostszą integrację między różnymi systemami.
3. Syncfunkcjonalność chroniczna lub asynchroniczna - Synchronicity odnosi się do powiązania klienta z wykonywaniem usługi. W operacjach synchronicznych klient faktycznie czeka, aż usługa sieciowa zakończy operację. Przykładem tego jest prawdopodobnie scenariusz, w którym wykonywana jest operacja odczytu i zapisu bazy danych. Jeśli dane są odczytywane z jednej bazy danych, a następnie zapisywane do innej, operacje muszą być wykonywane sekwencyjnie. Operacje asynchroniczne pozwalają klientowi wywołać usługę, a następnie wykonać inne funkcje równolegle. Jest to jedna z powszechnych i prawdopodobnie najbardziej preferowanych technik zapewniających, że inne usługi nie zostaną zatrzymane podczas wykonywania określonej operacji.
4. Możliwość obsługi zdalnych wywołań procedur (RPC) – Usługi sieciowe umożliwiają klientom wywoływanie procedur, funkcji i metod na obiektach zdalnych przy użyciu protokołu opartego na XML. Zdalne procedury udostępniają parametry wejściowe i wyjściowe, które musi obsługiwać usługa internetowa.
5. Obsługuje wymianę dokumentów – Jedną z kluczowych zalet XML jest jego ogólny sposób przedstawiania nie tylko danych, ale także złożonych dokumentów. Dokumenty te mogą być tak proste, jak przedstawienie bieżącego adresu, lub tak złożone, jak przedstawienie całej książki.

FAQ