W dzisiejszych czasach nie ma aplikacji, która działaby w kompletnej izolacji. Różne organizacje posiadają już programy, które wykonują różne operacje biznesowe X i chcą aby stare programy doskonale łączyły się z nowymi aplikacjami niezależnie od platformy, czy języka programowania.
Jednym słowem w dzisiejszych czasach programy wykonujące różne operacje powinny komunikować się ze sobą bez względu na to, w czym są napisane.
W erze internetu korporacje często wybierają rozwiązania pochodzące od osób trzecich. Na zasadzie po co mam pisać program, który już ktoś zrobił. Musimy tylko wykupić taką usługę i w ten sposób zaoszczędzimy “X” czasu.
Wyzywanie polega na tym, jak połączyć te elementy w taki sposób aby komunikowały się ze sobą oraz współpracowały.
Usługa sieciowa jest jednym ze sposobów na rozwiązanie takiego problemu. Używając usługi sieciowej można zbudować system z elementów, które są porozrzucane po całym świecie internetu. Komponenty i usługi są hostowane na serwerze, który otrzymuje zapytania z aplikacji klienckiej. Serwer filtruje zapytania i wysyła odpowiednie polecenie do komponentów lub usług. Potem jest wysłana odpowiedź z serwera do aplikacji klienckiej.
Celem tego krótkiego kursu jest pokazanie jak zaprojektować, zbudować i przetestować usługę sieciową, do której można uzyskać dostęp poprzez internet. Pokażę też jak napisać aplikacje kliencką, która używa metod z usługi sieciowej.
Dwa miesiące temu napisałem o tym, jak zaimplementować usługę typu SOAP w Silverlight. Postanowiłem jednak na chwile zrezygnować z tego cyklu, ponieważ chciałem być pewny tego, co piszę. Wtedy postawiłem sobie wysoko poprzeczkę. A usługi sieciowe są dla mnie nowością. Z drugiej strony brakowało na blogu ogólnego objaśnienia, co to jest usługa sieciowa i jak ona działa?
Co to jest usługa sieci
Usługa sieciowa jest to biznesowy komponent, który oferuje zbiór użytecznych i wielokrotnego użytku funkcjonalności dla klientów.
Usługi sieciowe mogą być uznane za ogólnie dostępne – jeśli masz odpowiednie prawa możesz ich użyć w jakimkolwiek miejscu na ziemi, oczywiście, dopóki jesteś podłączony do internetu.
Usługi sieciowe używają standardów, które są zaakceptowane. Stosują też znane i rozumiane protokoły jak np. HyperText Transfer Protocol (HTTP) . Do przesyłania danych w przenośny sposób format wiadomość jest bazowany na XML.
HTTP i XML są to dwie technologię, które zostały ogólnie zaakceptowane i są używane w innych środowiskach niż .NET.
Używając Visual Studio możesz utworzyć usługę sieciową używając C# i nawet C++. Dla klienta jednak nie ma znaczenia, w jakim języku jest napisana usługa sieciowa, nawet nie jest ważne jakusługa wykonuje swoje zadania. Aplikacje klienckie mogą działać na zupełnym innym środowisku jak np. Java.
Działa to też w obie strony usługa sieciowa napisana w Javie może być odebrana przez aplikacje kliencką napisaną w C#.
Bohater usług sieciowych w .NET - WCF
Windows Communication Foundation albo WCF stał się częścią .NET wraz z wersją 3.0. Visual Studio oferuje zbiór szablonów do zbudowania usługi sieciowej za pomocą WCF-a.
Celem WCF jest zjednoczenie programistycznego modelu, który powstał przy użyciu wielu technologii w taki sposób, aby były komponenty tego modelu były niezależne od siebie.
Jest to bardzo trudne, jak i być może niemożliwe. Oddzielenie programistyczne struktury aplikacji czy usługi poprzez infrastrukturę komunikacji. WCF pozwala zbliżyć się programiście do tego celu przy niewielkim czasie.
Podsumowując, jeśli chcesz budować aplikację i usługi pod system Windows WCF jest dla ciebie.
Architektura usługi sieciowej
Istnieją dwie popularne architektury, które organizują i implementują usługi sieciowe.
- Simple Object Access Protocol (SOAP)
- Representational State Transfer (REST)
Obie architektury polegają na wszechobecnym protokole HTTP (ten protokół jest używany w sieci do przesyłania i odbierania stron HTML) i adresują się do używanego schematu w internecie ,ale mogą być używane na wiele sposobów.
Usługa SOAP
Usługa SOAP eksponuje funkcjonalności poprzez użycie modelu proceduralnego. Te procedury są wykonywane zdalnie na serwerze. Z punktu widzenia aplikacji klienckiej usługa sieciowa jest interfejsem, który eksponuje liczbę zdefiniowanych metod znanych jako metody sieciowe. Aplikacja kliencka wysyła zapytanie przez te metody sieciowe. Zapytanie używa standardowych protokołów internetowych i wysyła odpowiednie parametry w postaci pliku XML i później otrzymuje odpowiedź też w formacie XML. Metody SOAP mogą wysyłać zapytania do danych, jak i je modyfikować.
Rola SOAP
SOAP jest protokołem używanym przez klienta do wysłania zapytań oraz do otrzymywania odpowiedzi z usługi sieciowej. SOAP jest zbudowany na HTTP. SOAP definiuje styl plik XML. Ustala więc on np. definicje parametrów, wartości zwracanych, jak i ich typów.
Kiedy klient wywołuje usługę sieciową musi najpierw określić metodę jak i parametry używając stylu XML.
SOAP jest standardem. Jego funkcją jest ulepszenie połączeń pomiędzy platformami. Siła SOAP polega na prostocie, jak i na tym ,że używa on standardów (HTTP,XML).
Specyfikacja SOAP definiuje kilka rzeczy. Najważniejsze z nich to:
- Forma wiadomości SOAP
- Jak dane są kodowane
- Jak dane są wysłane
- Jak proces odpowiada
Opis działania SOAP w detalach, jak i formatu jego wewnętrznej wiadomości jest poza tym wpisem. Nie planuje tworzyć wiadomości SOAP manualnie, po to są przecież narzędzia jak Visual Studio.
Jaki język opisuje usługę sieciową
Ciało wiadomości SOAP to dokument XML. Kiedy klient wywołuje metodę sieciową, serwer oczekuje od klienta użycia określonego zbioru tagów, które są zakodowane w parametrach metody.
Teraz jak klient ma wiedzieć, które tagi mają być użyte (a raczej który schemat dokumentu XML). Odpowiedź jest taka.
Od zapytanej usługi sieciowej oczekuje się dodatkowego opisu jej działania. Usługa wtedy odpowiada kolejnym dokumentem XML, który zawiera opis jej działania. Ten dokument znany jest jako Web Service Description Language (WSDL). W tym opisie zawarte są informacje potrzebne do konstrukcji zapytania SOAP dla aplikacji klienckiej w takim formacie ,aby serwer zrozumiał czego ona chce.
Ponownie WSDL jest poza tym wpisem. Visual Studio zawiera narzędzia, które potrafią zrozumieć dokument WSDL w usłudze sieciowej w mechaniczny sposób. Visual Studio wtedy używa tych informacji do utworzenia klasy proxy, która w aplikacji klienckiej jest używana do wywoływania metod. Później to wywołanie jest konwertowane na zapytania SOAP, które właśnie przez te proxy jest wysyłane przez sieć.
Później zastosuję to podejście w praktyce.
Wymagania co do usług sieciowych
Jak w każdej technologii i w usługach sieciowych są pewne wytyczne, które trzeba spełnić aby usługa była w pełni funkcjonalna, jeśli chodzi o wysłanie zapytań. Niedługo po tym, jak usługi sieciowe stały się popularne niektórzy od razu odnaleźli problemy, do których SOAP i HTTP nie mógł się zaadresować. Problemy głównie koncentrowały się na niefunkcjonalnymi wymaganiami, które są ważne ,a w przypadku internetu najważniejsze.
- Bezpieczeństwo – Czy istnieje pewność ,że wiadomości SOAP, które są wysłane pomiędzy klientem a serwerem nie zostaną prześwietlone, bądź zmienione przez osoby trzecie. Skąd możemy być pewni, że wiadomości SOAP zostały faktycznie wysłane przez serwer, a nie przez stronę (Spoofing attack*), która próbuje wyłudzić informacje. Jak możemy określić odpowiedni dostęp dla określonych użytkowników. To są istotne kwestie: spójność, poufność i autentykacja.Bez nich budowanie aplikacji, która ma korzystać z internetu nie ma sensu.
- Do tych problemów odniosła się specjalna organizacja o bardzo długiej nazwie:“Organization for the advancement of structured information standards”* w skrócie OASIS. W wielkim skrócie organizacja stworzyła odpowiednie standardy znane dzisiaj jako specyfikacja WS-Security. Specyfikacja WS-Security opisuje jak chronić wiadomości, które są wysłane przez usługi sieciowe. Dostawcy WS-Security mają własne implementacje zgodne z tą specyfikacją. Zazwyczaj używa się tutaj technologii do szyfrowania danych jak ich certyfikowania.
- Policy –Specyfikacja WS-Security definiuje jak zabezpieczyć, jednak wciąż programiści muszą wiedzieć jak napisać kod spełniający ten cel. Usługa sieciowa stworzona przez różnych programistów może mieć różne mechanizmy zabezpieczające o różnym poziomy efektowności. Przykładowo, jeśli usługa używa słabego szyfrowania cele bezpieczeństwa nie są wciąż spełnione. Odbiorca, który wysłałby poufne dane chciałby mieć 100% pewności, że dane są bezpieczne, czyli musiałby być one szyfrowane starannie. Właśnie wykazałem tutaj jedną z zasad polityki. Inne zasady mówią o jakości usługi sieciowej, jak i o jej niezawodności. Aplikacja kliencka powinna być w stanie,, w zależności od potrzeb ustawić odpowiedni poziom szyfrowania i tak dalej. Jednakże to wymaga od klienta, jak i od usługi sieciowej znajomości podstawowych zasad polityki. Specyfikacja WS-Policy określa model głównych celów, jak i ich składnię, która jest potrzebna do opisania polityki, którą usługa implementuje.
- Adresowanie i Przekierowanie –Usługa sieciowa jest użyteczna, gdy jest w stanie operować i wysłać dalej zapytanie do jednego z wielu komputerów hostujących instancje tej usługi. Jeden serwer nie da sobie rady z operowaniem na wielu zapytaniach od wielu komputerów. Dlatego w systemach istnieją specjalne algorytmy, które sprawdzają, który serwer jest najmniej obciążony i do niego wysyłają to zapytanie. Istotną rzeczą tutaj jest fakt, że klient nie powinien być świadomy tego procesu. Przekierowanie służy też administratorom, gdy trzeba jeden z serwerów tymczasowo zamknąć, bądź naprawić. Specyfikacja WS-Addresing opisuje jak zapytania powinny być przekierowywane.
Usługa REST
W przeciwieństwie do SOAP model REST używa schematu nawigacji do reprezentacji obiektów biznesowych, jak i zasobów sieciowych. Na przykład powiedzmy, że pewna firma chce pokazać informacje o swoich pracownikach w postaci REST. Pracownicy mają swoje identyfikatory w postaci liczbowej. Aby uzyskać informacje na temat pracownika nr 3 zastosowalibyśmy schemat poniżej. Zapytanie wygląda jak adres URL , zaraz to jest adres URL.
http://FIRMA.com/pracownicy/3
Wywołanie tego adresu URL uruchomi usługę sieciową, która uzyska informacje na temat pracownika numer 3. Dane mogą być zwracane w postaci wielu formatów, ale głównymi formatami są:
- XML (“Plain Old XML” albo POX)
- JavaScript Object Notation (JSON)
- ODATA (produkt Microsoftu)
Jeśli usługa zwracałaby dane w postaci dokumentu POX , wyglądałoby to mniej więcej tak:
<Pracownik>
<PracownikID> 3</PracownikID>
<Nazwisko> Walenciuk</Nazwisko>
<Imie> Cezary</Imie>
<Tytul> Inżynier Programista .NET</Tytul>
</Pracownik>Kluczem w projektowaniu rozwiązań typu REST jest podzielenie modelu biznesowego na zbiory zasobów. W tym wypadku “pracownicy” nie sprawili żadnych problemów jednak w innych sytuacjach może to wymagać sporych przemyśleń.
Model REST podlega na aplikacji, która uzyskuje dostęp do danych poprzez metody HTTP (verbs HTTP), które są częścią zapytania. Przykładowo proste zapytanie, które ma wyciągnąć informacje zastosowałoby metodę GET.
HTTP wspiera oczywiście inne metody jak: POST, PUT, DELETE, które potrafią tworzyć, modyfikować i usuwać zasoby. Warto zaznaczyć , że zwykła przeglądarka internetowa obsługuje tylko GET i POST.
Używając modelu REST możesz użyć tych metod HTTP do zbudowania usługi, która będzie edytować dane.
W przeciwieństwie do SOAP wiadomości wysłane, jak i te otrzymywane są w REST bardziej kompaktowe. Wynika to z tego, że REST nie wykonuje przekierowań, ani nie zabezpiecza usługi zgodnie z specyfikacjami WS. Co oznacza, że jeśli chodzi o chronienie usługi sieciowej typu REST musisz polegać na swoich bazowych zabezpieczeniach.
Czy to źle?
Oczywiście , że nie. Podejście REST polega na minimalizacji i w niektórych przypadkach jest on bardziej efektywny niż SOAP. Przykładowo usługa REST może być używana do wyświetlania danych, które nie są w żadne sposób poufne.
W następnym wpisie opiszę krok po kroku utworzenie usługi SOAP.
