docZastosowanie technologii Web Service do tworzenia
download 
Reklamacja Transkrypt
Zastosowanie technologii Web Service do tworzenia
Zastosowanie technologii Web Service do tworzenia
wieloplatformowych rozproszonych aplikacji typu klient-serwer
Paweł Krakowiak, Karol Kempa, Krzysztof Nieszporek
Wydział Inżynierii Mechanicznej i Informatyki
Kierunek informatyka, Rok II
{[email protected]}
{[email protected]}
{[email protected]}
Streszczenie
Celem pracy jest zaprezentowanie możliwości technologii Web Service na przykładzie
wieloplatformowej gry karcianej Black Jack. W pierwszym rozdziale omówimy
najważniejsze cechy technologii. W kolejnym implementacje gry z jej wykorzystaniem a
na koniec wady i zalety Web Services. W niniejszej pracy chcemy podkreślić
uniwersalność technologii Web Service oraz możliwość wykorzystania jej na różnych
platformach.
1) Wstęp
1.1 Definicja Web Service [3]
Web Service to zwarty, samodokumentujący się komponent programowy niezależny od
platformy i implementacji dostarczający określoną funkcjonalność w sieci.
Organizacjami odpowiedzialnymi za rozwój tej architektury są:
W3C (ang. World Wide Web Consortium) [1]
OASIS-WS-I (ang. OASIS Web Services Interoperability) [2]
Web Service wykorzystuje szereg standardów informatycznych m.in.:
XML (ang. Extensible Markup Language) [4],
WSDL (ang. Web Service Description Language) [5],
SOAP (ang. Simple Object Access Protocol) [6],
UDDI (ang. Universal Description, Discovery and Integration) [7].
1.2 Architektura Web Services (Rys. 1)
Każda usługa (ang. Service Provider) posiada reguły określające sposób komunikacji, opisane
w dokumencie WSDL. Klienci usługi (ang. Service Requester) współpracują z jej dostawcą
na zasadach określonych w dokumencie WSDL. Żądanie wywołania zdalnej metody jak i
zwracany rezultat przekazywane są za pomocą komunikatów SOAP. Komunikaty są
przeważnie przekazywane z wykorzystaniem protokołu HTTP (ang. Hypertext Transfer
Protocol). Usługa sieciowa może być upubliczniona do uniwersalnego rejestru usług
sieciowych UDDI, będącego pośrednikiem (ang. Service Broker) między dostawcą a klientem
usługi. Dzięki temu oprogramowanie może automatycznie wykrywać i integrować usługi
sieciowe w sieci Internet.
Rys. 1 Architektura Web Services [13]
1.2.1 WSDL
WSDL jest językiem służącym do opisu publicznego interfejsu usługi sieciowej, używającym
składni XML. Zawiera informacje o (Rys. 2 ):
udostępnionych metodach wraz z argumentami i zwracanymi typami,
adresie pod którym dostępna jest usługa,
protokole komunikacyjnym jaki został użyty do komunikacji.
Klient może dokonać automatycznej transformacji tego opisu do kodu źródłowego
obsługującego komunikację sieciową z dostawcą usługi.
Rys. 2 Struktura dokumentu WSDL w wersji 1.1 i 2.0 [14]
1.2.2 SOAP
SOAP
jest
protokołem
wywoływania
zdalnego
dostępu
do
obiektów,
wykorzystujący XML do kodowania wywołań i najczęściej HTTP jako protokół transmisyjny
(możliwe również HTTPS, FTP, SMTP, BEEP). Niezależny od platformy sprzętowej, czy
języka programowania.
Wywołanie metody jest konwertowane do dokumentu XML i podlega serializacji. Tak
powstały komunikat SOAP przekazywany jest protokołem transmisyjnym do dostawcy
usługi. Ten natomiast deserializuje komunikat, wywołuje odpowiednią metodę i w
analogiczny sposób zwraca rezultat do klienta (Rys. 3).
Rys. 3 Diagram obrazujący komunikację za pomocą protokołu SOAP [15]
Komunikat SOAP składa się z następujących elementów: (Rys. 4)
Koperty <envelope> (element obowiązkowy) - oznaczający, iż dokument jest
komunikatem SOAP
Nagłówka <header>(element opcjonalny) - zawiera informacje nagłówkowe
Ciała <body> (element obowiązkowy) – zawiera reguły kodujące typy danych
(również złożone typy) zdefiniowanych wewnątrz aplikacji oraz reguły dotyczące
sposobu wywoływania zdalnych metod i odczytu odpowiedzi.
<fault> (element opcjonalny) – zawiera opis błędów, jakie mogą wystąpić podczas
przetwarzania komunikatu.
Rys. 4 Struktura komunikatu SOAP
2) Wykorzystanie Web Services do stworzenia wieloplatformowe j gry karciane j
W ramach pracy stworzono architekturę aplikacji opartą o Web Services.
Na rysunku (Rys. 5)
przedstawiono diagram obrazujący najważniejsze
elementy systemu, w którego skład wchodzą dwie usługi Web Services oraz klient z nich
korzystający. Komunikacja jest jednostronna. To klient żąda wywołania zdalnej metody i w
wyniku otrzymuje odpowiedź. Należy zwrócić uwagę, że usługa GameServer jest
jednocześnie klientem usługi MainServer.
Rys 5. Architektura gry opartej o Web Services
2.1 MainServer – Główny serwer
Głównym celem MainServer’a jest weryfikacja logujących się użytkowników oraz ich
tokenów. Usługa ta posiada połączenie z bazą danych, gdzie przechowywane są informacje o
zarejestrowanych użytkownikach. Jeżeli klient po wywołaniu metody login ze swoją nazwą
konta oraz hasłem dostępu do niego przejdzie weryfikację, otrzymuje wówczas token
dostępny jedynie podczas trwania bieżącej sesji.
W momencie gdy jeden z serwerów gry otrzyma od klienta żądanie wykonania akcji,
następuje sprawdzenie poprawności tokenu z głównym serwerem, jeśli przejdzie weryfikację
następuje przedłużenie czasu trwania sesji dla użytkownika. Gdyby okazało się że sesja
wygasła użytkownik musi ponownie zalogować się na głównym serwerze, by móc
kontynuować grę.
MainServer jest modułem, który może być wykorzystywany przez kolejne serwery innych
gier, udostępniając im swoją funkcjonalność. Ponadto wszelkie zmiany w implementacji
serwera, jak sposób łączenia się z bazą danych i jego mechanika nie wymagają zmian po
stronie klienta.
2.2 GameServer – Serwer gry
Serwer gry jest usługą sieciową umożliwiającą podłączenie się do gry, a cała rozgrywka
umożliwia zmierzenie się w blackjack z krupierem [12] lub innym graczem. Serwer
udostępnia wszystkie konieczne metody klientowi, które pozwolają graczowi podjąć decyzję
o właściwym sposobie w jaki będzie kontynuował rozgrywkę. W naszym przykładzie serwer
posiada następujące metody:
login – umożliwia utworzenie nowej sesji dla gracza na podstawie tokenu przekazanego
jako argument wywołania funkcji, zwraca informacje o poprawności logowania lub kod
błędu
startGame – rozpoczyna nowa rozgrywkę, informacja zwrotna jest podobna do tej z
metody login
hit – pozwala na dobranie karty przez gracza, w informacji zwrotnej dla klienta jest
przekazywana aktualnie wyciągnięta karta, oraz suma punktów gracza.
pass – gracz decyduje się na nie dobieranie kolejnych kart, zwracana jest informacja
zwrotna z sumą punktów krupiera i wyniku całej partii
Serwer gry jest równocześnie klientem głównego serwera na rzecz którego wywoływana jest
metoda isValid. Jest to spowodowane tym, iż warunkiem koniecznym wykonania akcji
związanych z wywołaniem metody przez klienta jest weryfikac ja aktualności sesji na
głównym
serwerze.
Jeżeli
serwer
nie
potwierdzi ważności sesji gracza,
zwracana jest informacja do
klienta,
że gracz powinien najpierw zalogować się na serwerze.
2.3 Klient gry
Aplikacja kliencka posiada zestaw klas wygenerowanych na podstawie dokumentu WSDL i w
zależności od platformy może być napisany w różnych językach programowania. Nic nie stoi
także na przeszkodzie, aby obsługiwał wiele Web serwisów. Klient stworzony na potrzeby
naszej gry obecnie obsługuje dwie usługi – serwer gry (Rys. 6) oraz serwer główny (Rys. 7).
Implementuje metodę, którą wymaga serwer główny do zalogowania, oraz metody serwera
gry umożliwiające wykonywanie akcji w grze. Po odebraniu odpowiednich komunikatów
zwrotnych z serwera następuje prezentacja wyników lub zgłoszenie błędów.
Rys. 6 Klient
GameServer’a:
rozgrywka z
krupierem
Rys. 7 Klient MainServer’a: proces logowania
2.4
Środowisko pracy
W trakcie realizacji projektu pracowaliśmy w środowisku NetBeans v6.9.1 [10]
wykorzystując serwer Axis2 v1.5.4 [8] i serwer Tomcat v6.0 [9]. Umożliwiło to stworzenie
projektu przystosowanego do wymogów Web Services, szybką kompilację programu oraz
spakowanie plików klas do archiwum *.aar i automatyczne umieszczenie pliku w
odpowiednim katalogu serwera Tomcat. Środowisko NetBeans umożliwia na bieżąco
testować nowe funkcjonalności serwerów w z poziomu SDK (Rys. 8). Pozwoliło nam
zaoszczędzić czas potrzebny na poprawną ręczną kompilację plików i umieszczanie
archiwum za każdym razem w odpowiednim katalogu serwera zewnętrzne go.
Rys. 8 Testowanie Web Servis’u z poziomu Netbeans IDE: publikacja Web Servis’u,
wywołanie zdalnej metody i rezultat
3) Podsumowanie
W pracy przedstawiono technologie Web Services pozwalającą na tworzenie usług
sieciowych, z których można korzystać niezależnie od platformy, czy języka programowania.
Dzieląc system na osobne, niezależne moduły, uzyskaliśmy większą kontrolę nad błędami
oraz jasno określiliśmy podział zadań w teamie. Każda usługa Web Service dostarcza jasno
określonej funkcjonalności, tworząc tym samym komponent wielokrotnego użytku. Logikę
gry dostarczają usługi sieciowe, natomiast klient
jest odpowiedzialny za interfejs
użytkownika. Cała architektura zapewnia możliwość dalszej rozbudowy systemu.
Istniały już podobne mechanizmy typu middleware (oprogramowanie pośredniczące)
tj. DCE, COBRA, DCOM, RMI, jednak rozwiązania te nie były na tyle uniwersalne by
zapewnić kompatybilność w heterogenicznym środowisku jakim jest Internet. Poprzednie
rozwiązania ponadto, korzystały z pewnego rodzaju binarnego protokołu do komunikacji.
Web Services używają XML-a i protokołu HTTP, dzięki temu nie występują żadne problemy
z zaporą firewall. Istnieją dostępne publicznie Web Serwis’y [11], które możemy wykorzystać
w naszych aplikacjach, zmniejszając koszty wytwarzania oprogramowania.
Zalety Web Services
niezależny od platformy i języka programowania,
„samo-opisujący się”, dostępny publicznie interfejs,
redukuje złożoności systemów informatycznych przez zamykanie pewnej funkcjonalności
w komponenty wielokrotnego użytku,
możliwość natychmiastowej integracji z innymi systemami ze względu na niskie związki
między modułami ,
ukrycie szczegółów implementacyjnych,
zmiany w implementacji usługi nie wymagają zmian w aplikacji klienckiej,
wykorzystuje ugruntowane standardy internetowe,
możliwość przyrostowej implementacji.
Wady Web Services
Duży rozmiar komunikatów SOAP, ponieważ są one transportowane w postaci tekstu.
Powstały jednak metody takie jak MTOM(ang. Message Transmission Optimization
Mechanism) i XOP (ang. XML-binary Optimized Packaging), które po części rozwiązują
ten problem.
Poprzez wykorzystanie protokołu HTTP i obejściu większości zapór sieciowych pojawiają
się problemy z właściwym zabezpieczeniem aplikacji.
4) Bibliografia
1)
2)
3)
4)
5)
6)
World Wide Web Consortium,
http://www.w3.org
The OASIS Web Services Interoperability,
http://www.oasis-ws- i.org/
W3C Web service definition,
http://www.w3.org/TR/ws-arch/#whatis
W3C XML Specification,
http://www.w3.org/TR/REC-xml
W3C WSDL Specification,
http://www.w3.org/TR/WSDL
W3C SOAP Specification,
http://www.w3.org/TR/SOAP
7) UDDI Specifications,
http://www.uddi.org/specifications
8) Serwer Axis2,
http://axis.apache.org/axis2/java/core/index.html
9) Serwer Tomcat,
http://tomcat.apache.org/download-60.cgi
10) NetBeans IDE,
http://netbeans.org/
11) Web Services Search Engine,
http://webservices.seekda.com/
12) Definicja krupiera,
http://pl.wikipedia.org/wiki/Krupier
13) http://en.wikipedia.org/wiki/File:Webservices.png
14) http://en.wikipedia.org/wiki/File:WSDL_11vs20.png
15) http://secangkirkopipanas.com/2010/09/integrasi- net- xml- web-services-dan-java- memenggunakan-ksoap2/
