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

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 poprzez tak zwane zdalne wywołania procedur. Zdalne wywołania procedur (RPC) to wywołania metod hostowanych przez odpowiednią usługę internetową.
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 Java ale każdy język programowania miałby możliwość komunikowania się z usługą internetową.
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 w zrozumieniu językiem pośrednim, rozumianym przez wiele języków programowania.
Kiedy więc aplikacje komunikują się ze sobą, w rzeczywistości komunikują się w formacie XML. Zapewnia to wspólną platformę dla aplikacji opracowanych w różnych językach programowania, aby mogły ze sobą rozmawiać.
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, inne w .Net, inne w Angular JS, Node.js itp.
Najczęściej te heterogeniczne aplikacje potrzebują pewnego rodzaju komunikacji, aby mogły się między sobą odbywać. Ponieważ są tworzone przy użyciu różnych języków programowania, staje się naprawdę trudno zapewnić dokładną komunikację między aplikacjami.
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ą.
Rodzaj usługi internetowej
Istnieją głównie dwa rodzaje usług internetowych.
- Usługi sieciowe SOAP.
- RESTful usługi sieciowe.
Aby usługa internetowa była w pełni funkcjonalna, muszą istnieć pewne elementy, które muszą być na swoim miejscu. Komponenty te muszą być obecne niezależnie od języka programowania używanego do programowania usługi internetowej.
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. SOAP opiera się na przesyłaniu danych XML jako komunikatów SOAP. Każda wiadomość zawiera coś, co nazywa się dokumentem XML. Tylko struktura dokumentu XML jest zgodna z określonym wzorcem, ale nie treść. Najlepszą częścią usług internetowych i SOAP jest to, że wszystko jest wysyłane za pośrednictwem protokołu HTTP, który jest standardowym protokołem internetowym.
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 routingowe, czyli w zasadzie informację, która mówi dokumentowi 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 (język opisu usług internetowych)
Nie można korzystać z usługi internetowej, jeśli nie można jej znaleźć. Klient wywołujący usługę internetową powinien wiedzieć, gdzie faktycznie znajduje się ta usługa internetowa.
Po drugie, aplikacja kliencka musi wiedzieć, co faktycznie robi usługa sieciowa, aby mogła wywołać odpowiednią usługę sieciową. Odbywa się to za pomocą języka WSDL, znanego jako język opisu usług sieciowych. Plik WSDL jest ponownie plikiem opartym na języku XML, który w zasadzie informuje aplikację kliencką, co robi usługa internetowa. Używając 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:
- – Parametr message w definicji WSDL służy do definiowania różnych elementów danych dla każdej operacji wykonywanej przez usługę internetową. Tak więc w powyższych przykładach usług internetowych mamy 2 wiadomości, które mogą być wymieniane między usługą internetową a aplikacją kliencką, jedną z nich jest „TutorialRequest”, a drugą operacja „TutorialResponse”. TutorialRequest zawiera element o nazwie „TutorialID”, który jest typu string. Podobnie operacja TutorialResponse zawiera element o nazwie „TutorialName”, który jest również typu string.
- – To w rzeczywistości opisuje operację, którą może wykonać usługa internetowa, która w naszym przypadku nazywa się Tutorial. Ta operacja może przyjąć 2 wiadomości; jedna jest wiadomością wejściową, a druga jest wiadomością wyjściową.
- – Ten element zawiera używany protokół. Zatem w naszym przypadku definiujemy go tak, aby używał http (http://schemas.xmlsoap.org/soap/http). Określamy również inne szczegóły dotyczące treści operacji, takie jak przestrzeń nazw i czy wiadomość powinna być zakodowana.
Omówimy szczegółowo „WDSL” w tym artykule 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 nazwisko, adres i numer telefonu konkretnej osoby, w ten sam sposób rejestr UDDI będzie zawierał istotne informacje dotyczące usługi internetowej. Aby aplikacja kliencka wiedziała, gdzie ją znaleźć.
Zalety usług sieciowych
Rozumiemy już, dlaczego w ogóle powstały usługi sieciowe, a mianowicie zapewnienie platformy umożliwiającej komunikację między różnymi aplikacjami.
Ale spójrzmy na listę zalet usług internetowych, aby dowiedzieć się, dlaczego korzystanie z usług internetowych jest ważne.
- Udostępnianie funkcjonalności biznesowych w sieci – Usługa internetowa to jednostka kodu zarządzanego, która zapewnia pewien rodzaj funkcjonalności aplikacjom klienckim lub użytkownikom końcowym. Funkcjonalność tę można wywołać za pośrednictwem protokołu HTTP, co oznacza, że można ją wywołać także przez Internet. Obecnie wszystkie aplikacje znajdują się w Internecie, co czyni usługi internetowe bardziej użytecznymi. Oznacza to, że usługa internetowa może znajdować się w dowolnym miejscu Internetu i zapewniać niezbędną funkcjonalność zgodnie z wymaganiami.
- Interoperacyjność między aplikacjami – Usługi sieciowe pozwalają różnym aplikacjom komunikować się ze sobą oraz udostępniać między sobą dane i usługi. Wszystkie typy aplikacji mogą ze sobą rozmawiać. Zamiast więc pisać konkretny kod, który będzie zrozumiały tylko dla określonych aplikacji, możesz teraz napisać ogólny kod, który będzie zrozumiały dla wszystkich aplikacji
- Standardowy protokół, który każdy rozumie – Usługi internetowe wykorzystują do komunikacji ustandaryzowany protokół branżowy. Wszystkie cztery warstwy (Transport usług, Przesyłanie wiadomości XML, Usługa Description i warstwy Service Discovery) wykorzystuje dobrze zdefiniowane protokoły w stosie protokołów usług sieciowych.
- 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 mieć pewność, że cały framework działa zgodnie z oczekiwaniami, podobnie jak w przypadku usług sieciowych. Web Services Architektura składa się z trzech odrębnych ról, jak podano poniżej:
- Provider – Dostawca tworzy usługę internetową i udostępnia ją aplikacji klienckiej, która chce z niej skorzystać.
- 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 dowolną inną aplikację językową, która szuka jakiejś funkcjonalności za pośrednictwem usługi internetowej.
- Broker – Broker to nic innego jak aplikacja zapewniająca dostęp do UDDI. Jak omówiono we wcześniejszym temacie, identyfikator UDDI umożliwia aplikacji klienckiej zlokalizowanie usługi internetowej.
Poniższy diagram przedstawia wzajemne oddziaływanie dostawcy usług, podmiotu żądającego usługi i rejestru usług.
- Publikować – Dostawca informuje brokera (rejestr usług) o istnieniu usługi internetowej za pomocą interfejsu publikowania brokera w celu udostępnienia usługi klientom
- Znajdź – Osoba żądająca konsultuje się z brokerem, aby zlokalizować opublikowaną usługę internetową
- Bind – Dzięki informacjom uzyskanym od brokera (rejestru usług) na temat usługi sieciowej osoba żądająca może powiązać lub wywołać usługę sieciową.
Charakterystyka serwisu internetowego
Usługi sieciowe charakteryzują się następującymi szczególnymi cechami zachowania:
- Są oparte na formacie XML – Usługi sieciowe wykorzystują XML do reprezentowania danych na warstwach reprezentacji i transportu danych. Użycie XML eliminuje wszelkie zależności sieciowe, systemowe lub platformowe, ponieważ XML jest wspólnym językiem zrozumiałym dla wszystkich.
- 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.
- 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.
- 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.
- 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.