Raport z przebiegu prac czwartej grupy problemowej

Transkrypt

1 Raport z przebiegu prac czwartej grupy problemowej Temat: Opracowanie metody udostępnienia systemu rejestracji domen internetowych aplikacjom kooperantów przy pomocy interfejsu partnerskiego Raport opracował: dr inż. Paweł Fałat Katedra Informatyki Stosowanej Akademia Techniczno Humanistyczna ul Willowa 2, Bielsko Biała mail: falat@ath.bielsko.pl

2 Spis treści 1. Wstęp Definicja zadania Istniejący system Potrzeba integracji z systemami kooperantów Podstawowa specyfikacja wymagań tworzonego systemu Wybór technologii Propozycja technologii realizacji w postaci Web Serwisu XML Technologie wykorzystywane do tworzenia Web Sewisu XML Protokół HTTP XML Protokół SOAP WSDL Bezpieczeństwo Wydajność Implementacja aplikacji klienckiej Prototyp Systemu Prototyp w APS.NET Prototyp w PHP z wykorzystaniem biblioteki NuSoft Podsumowanie i Wnioski Literatura

3 1. Wstęp Wraz z rozwojem informatycznych systemów funkcjonujących w postaci aplikacji webowych coraz częściej następuje konieczność integracji takich rozwiązań. Często tego typu aplikacje są tworzone z wykorzystaniem różnych technologii (JAVA, PHP ASP.NET itp.) Często również są instalowane na różnych systemach operacyjnych (Linux, Unix, Windows). Pojawia się więc szereg problemów utrudniającą integrację takich rozwiązań. Z pomocą mogą tu przyjść webowe usługi XML (XML Web Services), które zostały stworzone z myślą o rozwiązaniu tego typu problemów. Stworzona usługa udostępnienia zaimplementowanej funkcjonalności aplikacjom klienckim tworzonym w dowolnej technologii i pod dowolnym systemem operacyjnym. Praca IV grupy problemowej projektu NTHills, której temat został sformułowany: Opracowanie metody udostępnienia systemu rejestracji domen internetowych aplikacjom kooperantów przy pomocy interfejsu partnerskiego dotyczyła tego typu zagadnień. 3

4 2. Definicja zadania Firma Commonet oferuje swoim klientom system obsługi i konfiguracji dns domen internetowych umieszczanych w domenie bielsko.pl, której jest operatorem. Aplikacja została wykonana w postaci witryny internetowej i umożliwia rejestrację i obsługę domen zarówno przez użytkowników indywidualnych jak i firmy kooperujące. Ponieważ kooperanci, chcieliby mieć możliwość oferowania funkcjonalności systemu w swoich rozwiązaniach należy zaprojektować usługę, która to umożliwi Istniejący system System obsługujący rejestracje domen to typowa aplikacja webowa (Rys 1) [DNS Commonet]. Wykorzystuje standardowe techniki tworzenia tego typu rozwiązań pisanych w technologii PHP [PHP Spec]: logowanie, korzystanie z systemu bazodanowego itp. Oczywiście zintegrowana jest również z systemem obsługi DNS dokonując w nim odpowiednich wpisów [DNS]. Podstawowa funkcjonalność sprowadza się do obsługi profilu użytkownika, sprawdzania dostępności domen, rezerwowania ich a następnie obsługi transakcji związanych z płatnościami. Firma Commonet oferuje firmom kooperującym zniżki definiowane przez przyznanie odpowiedniego vouchera. Należy również nadmienić, że istnieje możliwość realizacji płatności w formie elektronicznej z wykorzystaniem systemu dotpay [dotpay]. Bezpieczeństwo systemu jest zapewniane przez zabezpieczenie mechanizmu logowania i odpowiednią konstrukcję kodu filtrującego niebezpieczne dane. 4

5 Rys 1. System obsługi domen 2.2. Potrzeba integracji z systemami kooperantów W wyniki współpracy z kooperantami pojawiła się potrzeba udostępnienia istniejącej już funkcjonalności bezpośrednio w systemach informatycznych firm współpracujących. Chcą oni bowiem udostępniać możliwości istniejącego systemu obsługi domeny bielsko.pl swoim klientom bez zmuszania ich do rejestracji w aplikacji firmy Commonet. Taka bezpośrednia integracja ułatwia też prace samym kooperantom, których pracownicy poruszają się w tedy w obrębie jednego systemu informatycznego co wpływa na wydajność i kosztochłonność pracy. 5

6 2.3. Podstawowa specyfikacja wymagań tworzonego systemu Założono, że nowotworzony system powinien duplikować funkcjonalność istniejącej witryny jednak powinien być wykonany taką techniką by mógł być łatwo wykorzystywany w systemach informatycznych kooperantów. Nie będzie zatem projektowany wizualny interfejs użytkownika lecz zbiór funkcji, które będą mogły być uruchamiane przez sieć Internet i wykonywać będą przypisane operacje na istniejącej już bazie danych i systemie obsługi DNS. 3. Wybór technologii Jednym z pierwszych etapów w realizacji projektów informatycznych jest wybór technologii w jakim dane rozwiązanie będzie wykonane. W omawianym przypadku przyjęto, że podstawowe technologie realizacji powinny wykorzystywać narzędzia już funkcjonujące na serwerze, na którym działa aplikacja webowa, głownie PHP. Specyficznym problemem w omawianym zadaniu są systemy informatyczne kooperantów, których struktura i technologia realizacji jest niedostępna, a w przypadku firm które dopiero rozpoczną współpracę z firmą Commonet nawet nie znana. Należy więc zapewnić możliwość korzystania z projektowanego rozwiązania dla aplikacji wykonanych w dowolnej technologii i pracujących pod dowolnym systemie operacyjnym. Dodatkowym zaleceniem jest ułatwienie integracji z serwisem dla programistów pracujących nad systemami firm współpracujących. Takie możliwości daje wykonanie aplikacji w postaci Web Serwisu XML, który wykorzystując podstawowe techniki webowe umożliwia realizację wszystkich postawionych celów. 6

7 4. Propozycja technologii realizacji w postaci Web Serwisu XML W omawianym przypadku proponuje się wykonanie systemu współpracy z kooperantami w postaci usługi webowej tzn. Web Serwisu XML. Poniżej zostaną przedstawione cechy, które decydują o takiej propozycji. Przykłady przedstawione w niniejszym rozdziale są realizowane z wykorzystaniem technologii firmy Microsoft, która obecnie oferuje jeden z najlepszych zestawów narzędzi realizacji tego typu aplikacji. Należy sobie na początku wyjaśnić co to jest usługa XML. Web Serwis XML można traktować jako swoistego rodzaju bibliotekę udostępniającą programiście metody w niej zdefiniowane. W odróżnieniu od tradycyjnych pakietów nie jest ona wykorzystywana lokalnie, jak klasyczne biblioteki dll lecz funkcjonuje w sieci. Komunikacja z nią, czyli wywoływanie funkcji i odbiór wyników ich działania odbywa się właśnie przez sieć. Jest to więc jeden ze sposobów tworzenia aplikacji rozproszonych. Jednak w odróżnieniu od innych tego typu technologii (CORBA, DCOM) umożliwia pełną integrację różnych platform systemowych, narzędzi i technologii programistycznych (PHP, JAVA,.NET). Oczywiście do tworzenie tego typu rozwiązań wymaga poznania kilku dodatkowych aspektów. 7

8 Rys 2. Schemat działania typowego Web Serwisu. Użytkownik musi się najpierw połączyć z serwerem, na których uruchomiona jest usługa (Rys 2). Kolejnym krokiem jest ustalenie jaką funkcjonalność oferuje usługa. Dokonuje się tego za pomocą dokumentu WSDL (Web Services Description Language), który ją prezentuje w postaci odpowiednich znaczników kodowanych w standardzie XML (Rys 3). 8

9 Rys 3. Przykładowy fragment dokumentu WSDL Dokument WSDL, który szerzej będzie opisany w dalszej części opisuje usługę dostarczając informacji o jej funkcjonalności. Jest on przeznaczony głownie dla narzędzi generujących kod tzw. klasę proxy. Dla użytkownika bardziej przejrzyste są informacje dostarczane przez system generujący prosty system pomocy, który daje przejrzystą informację o funkcjach udostępnianych przez Web Serwis (Rys 4. ) i sposobie wywoływania metod udostępnianych przez usługę (Rys 5). 9

10 Rys 4. Lista funkcji udostępnianych przez Web Serwis (realizacja na platformie.net) 10

11 Rys 5. Prezentacja sposobu wywołania metody usługi XML (realizacja na platformie.net) Na podstawie tego opisu możliwe jest po stronie klienta generowanie odpowiednich komunikatów wysyłanych następnie do serwera z działającą aplikacją Web Serwisu, które powodują uruchomienie odpowiednich metod. Osobnym zadanie może być samo znalezienie usługi. Web Serwisów oferujących podobną funkcjonalność może być całe mnóstwo. W takim przypadku można wykorzystać pośrednika (serwis UDDI - Universal Description Discovery and Integration), który zbiera informacje o usługach, firmach je oferujących i dodatkowych informacjach związanych z tymi usługami np. cenę za wykorzystanie. Serwis UDDI przesyła użytkownikowi informacje o lokalizacji Web Serwisu w tym w szczególności o adres dokumentu WSDL. 11

12 4.1. Technologie wykorzystywane do tworzenia Web Sewisu XML Webowe usługi XML tworzone są w oparciu o typowe technologie stosowane w aplikacjach webowych, wykorzystując i rozszerzając ich możliwości Protokół HTTP HTTP dla usług XML stanowi warstwę transportową. Wprawdzie systemy te nie są ściśle skojarzone z konkretnym protokołem jednak stosowanie tego protokołu ułatwia rozwiązanie szeregu zagadnień (np. rozwiązuje problem stosowania firewalli). Ze stosowaniem protokołu HTTP łączy się wykorzystanie metod GET i POST. Metody te umożliwiają uruchamianie metod udostępnianych przez Web Serwis (Przykład 1,2) [MS2524]. GET /PATH/GetStockPrice.aspx?Symbol=MSFT HTTP/1.1 Host: localhost Przykład 1. Wykorzystanie metody GET do uruchomienia funkcji Web Serwisu POST /PATH/ GetStockPrice.aspx HTTP/1.1 Host: localhost Content-Type: appliaction/x-www-from-urlencoded Content-Length: 11 Symbol=MSFT Przykład 2. Wykorzystanie metody POST do uruchomienia funkcji Web Serwisu Odpowiedź Web-Serwisu może być również odesłana klientowi z wykorzystaniem protokołu HTTP (Przykład 3) 12

13 HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: 75 <?xml versionn= 1.0 encoding= utf-8?> <stock symbol= MSFT Price= /> Przykład 3. Odpowiedź Web Serwisu Jednak możliwości przesyłania danych tymi metodami ograniczają się do typów prostych (double, string itd.) W przypadku gdy konieczne przesyłanie jest bardziej złożonych struktur konieczne jest stosowanie jest protokołu SOAP zbudowanego w oparciu o technologię XML XML XML (Extensible Markup Language) w przypadku omawianych usług jest wykorzystywana w wielu elementach. Dla Web Serwisów to przede wszystkim technologia umożliwiające budowanie i przesyłanie złożonych typów danych. Wykorzystuje się schematy XSD (XML Schema Definition), które dają możliwość definicji własnych typów. Definicje te następnie są udostępniane w dokumencie WSDL programistom tworzącym oprogramowanie klienckie. Za pomocą bazującego na technologii XML protokołu SOAP przesyłane są złożone struktury danych do i z Web Serwisu Protokół SOAP SOAP (Simple Object Access Protocol). W początkowych zamiarach miał to być protokół umożliwiający dostęp do obiektów w sieci w omawianych zastosowaniach umożliwia on przesyłanie złożonych struktur do metod udostępnianych przez usługę XML. Jako warstwę transportującą komunikat SOAP wykorzystuje się metodę POST protokołu HTTP (Przykład 4, 5) Należy jednak zauważyć, że komunikat SOAP może być również przesylany z wykorzystaniem innych technologii transportowych. Podstawowy komunikat składa się z tzw. koperty identyfikowanej przez znacznik <Envelope></Envelope>. W nim mogą pojawić się kolejne elementy: 13

14 <Header></Header> Zawiera nagłówki wiadomości SOAP zawierajace dodatkowe informacje opisujące komunikat. Często przesyła się w ten sposób dane identyfikujące użytkownika (Przykład 4). <Body></Body> W tym miejscu znajduje się główna treść komunikatu: definicje obiektów przesyłanych do metod, identyfikatory wywoływanych funkcji a w przypadku odpowiedzi web serwisu (Przykład 5) wyniki działania tych funkcji. <Fault></Fault> Element Fualt jest używany do przesłania aplikacji klienckiej informacji o wystąpieniu błędu w działaniu Web Serwisu. <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi= > <soap:header> <WoodgroveAuthInfo xmlns=" <Username>string</Username> <Password>string</Password> </WoodgroveAuthInfo> </soap:header> <soap:body> <GetAccount xmlns=" <acctid>int</acctid> </GetAccount> </soap:body> </soap:envelope> Przykład 4 Struktura koperty SOAP <soap:envelope xmlns:soap=" > <soap:body> <soap:fault> <faultcode>123xyz</faultcode> <faultstring>server Error</faultstring> <detail> <bank:faultdetails xmlns:bank="urn:onlinebank"> <message> Your account is overdrawn </message> <errorcode>1234</errorcode> </bank:faultdetails> </detail> </soap:fault> </soap:body> </soap:envelope> Przykład 5 Obsługa błędu w protokole SOAP 14

15 Oczywiście zestaw znaczników możliwych do wykorzystania w protokole SOAP jest znacznie szerszy [SOAP Spec]. Warto zaznaczyć, że specyfikacja protokołu przewiduje przesyłanie parametrów do Usługi Webowej przez referencję, Routing komunikatów, który może być stosowany w przypadku rozdziału obciążenia aplikacji na wiele bliźniaczych usług. Również programista tworzący Web Serwis ma możliwość tworzenia elementów rozszerzających ten protokół. W każdym przypadku informacje dotyczące sposobu przesyłania komunikatów do Web Serwisu i struktura odpowiedzi usługi są zapisywane w pliku WSDL WSDL Dokument WSDL (Web Services Description Language) to istotny element Usługi XML. Dokładnie opisuje Web Serwis. Zawiera definicję typów wykorzystywanych w systemie i komunikatów, które obsługiwane będą na serwerze. Plik ten jest wykorzystywany przez programistów piszących aplikacje klienckie do wygenerowania tzw. klasy proxy. Proces ten wykonywany przez dodatkowe narzędzia, które generują kod w zadanym języku programowania. Np. program wsdl.exe dostarczany wraz z platformą.net umożliwia utworzenie kodu w jednym z języków wpieranych przez firmę Microsoft. Podobne rozwiązanie funkcjonuje na platformie JAVA. Proces generowania klasy proxy (i klas udostępnianych przez Web Serwis) ułatwia pracę programiście zdejmując z niego obowiązek ręcznego generowania komunikatów SOAP czy wywołań metodą POST. Postać pliku WSDL może być różna w zależności od sposobu kodowania wywołań funkcji (rpc lub document) jednak podstawowe elementy struktury są stałe. Struktura pliku bazuje oczywiście na standardzie xml. Podstawowe znaczniki zawarte w głównym elemencie definitions to: <types></types> <message></message> Element ten zawiera definicję typów wykorzystywanych przez web serwis. Zapisywane są w tym miejscu zarówno definicje struktur stworzonych przez programistę, jak również definicje typów wykorzystywanych do wywołań odpowiednich metod Web Serwisu. (Przykład 6) Elementy message stanowią podstawę do definicji komunikatów przesyłanych na web serwis. Definiują łącze 15

16 pomiędzy typami zdefiniowanymi w sekcji types (Przykład. 7) <porttype></porttype> Element porttype definiuje które z elementów message są wykorzystywane do obsługi komunikatów przychodzących a które wychodzących. Jego szczególne znaczenie jest odczuwane w momencie gdy usługa obsługuje wiele protokołów, w których szczegóły wywołania funkcji web serwisu mogą się istotnie różnić. Element porttype umożliwia implementację takich rozwiązań. (Przykład 8) <binding></binding> Element binding służy do powiązania operacji z konkretnym protokołem i definicję elementów specyficznych dla danego protokołu (Przykład 9) <service></service> Element service definiuje punkty przyłączeń dla każdego protokołu obsługiwanego przez Web Serwis. (Przykład 10) Przykłady implementacji poszczególnych elementów pliku WSDL na podstawie [MS2524]. <types>... <s:complextype name="acct"> <s:sequence> <s:element minoccurs="1" maxoccurs="1" name="description" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="number" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="type" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="balance" type="s:decimal" /> </s:sequence> <s:attribute name="status" type="s:string" /> </s:complextype>... </types> <?xml version="1.0" encoding="utf-8"?> <account status="active"> <description>adam's savings acct</description> <number>1234-xx</number> <type>sv</type> <balance>10000</balance> </account> Przykład 6 Definicja typu w dokumencie wsdl i jego reprezentacja w kodzie xml. 16

17 <message name="getaccountin"> <part name="parameters" element="s0:getaccount" /> </message> <message name="getaccountout"> <part name="parameters" element="s0:getaccountresponse" /> </message> Przykład 7. Element message <porttype name="bankservice"> <operation name="getaccount"> <input message="s0:getaccountin" /> <output message="s0:getaccountout" /> </operation> </porttype> Przykład 8 Element porttype <binding name="bankservice" type="s0:bankservice"> <soap:binding transport =! " style="document" /> <operation name="getaccount"> <soap:operation soapaction = " style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> Przykład 9 Element binding <service name="bankservice"> <port name="bankservice" binding="s0:bankservice"> <soap:address location = " /> </port> </service> Przykład 10 Element service 17

18 By klient podłączający się do serwera mógł określić jakie Web Serwisy są na nim uruchomione można wykorzystać standardowe technologie DISCO (Web Services Discovery) [MSDN-Disco] lub WS-Inspection [WS-I]. Obie dostarczają informacji o lokalizacji dokumentu WSDL co jest wystarczające do rozpoczęcia tworzenia aplikacji klienckiej Bezpieczeństwo Aspekty związane z bezpieczeństwem korzystania są również bardzo istotne przy tworzeniu usług webowych. Poczynając do bezpiecznego kanału danych po standardowe zabezpieczenia przy pracy np. z bazą danych. Istotna przy tym jest identyfikacja użytkownika korzystającego z usługi. Można oczywiści używać standardowych mechanizmów identyfikujących zaimplementowanych np. w protokole HTTP. Jednak jeśli planujemy by Web Serwis mógł funkcjonować wykorzystując inne protokoły to należy zaimplementować własny mechanizm rozpoznawania użytkownika. Zalecaną metodą jest wykorzystywanie tzw. nagłówków SOAP, czyli dodatkowych danych dołączanych do komunikatu SOAP (Przykład 4). Ponieważ są one również definiowane w dokumencie WSDL to programista tworzący aplikację kliencką może w łatwy sposób ten mechanizm oprogramować. Taki też mechanizm został zaproponowany w prezentowanym dalej prototypie aplikacji. Inne zagadnienia związane z bezpieczeństwem usług webowych są prezentowane w standardzie WS-Security [WS-S]. 4.3 Wydajność W przypadku omawianego systemy problemy wydajnościowe nie mają w tym momencie istotnego znaczenia. Analiza działania istniejącej aplikacji (statystyki wykorzystania) wyraźnie na to wskazują. Jednak należy wspomnieć, że technologie związane z sieciowymi usługami XML uwzględniają również i takie scenariusze gdy usługa jest rozpraszana i obsługiwana przez wiele serwerów [MSDN WS-Routing]. W przypadku technologii.net by implementować te zaawansowane technologie współpracy z usługą można wykorzystać dodatek rozszerzający możliwości Web Serwisów [MSDN WSE]. 18

19 4.4. Implementacja aplikacji klienckiej Tworzenie aplikacji klienckiej w przypadku gdy dysponujemy dokumentem WSDL jest zazwyczaj bardzo proste. Jak wspomniano Programista może wygenerować plik z klasą proxy. Dokładniej rzecz ujmując plik ten zawiera lokalną kopię wszystkich typów danych publikowanych przez Web Serwis. Osoba pisząca aplikację kliencką może więc deklarować zmienne i pracować z nimi tak jak by były tworzone lokalnie na komputerze gdzie uruchomiony jest program. Klasa proxy zajmuje się tłumaczeniem lokalnych wywołań funkcji na odpowiednie komunikaty protokołu SOAP czyli uruchamianiem metod Web Serwisu i odbiorem wyników ich działania (Przykład 11). private void button1_click(object sender, EventArgs e) { WebServiceInPHP.DNSWebServiceTest wsphp = new NTHillsWindowsFormsApplication.WebServiceInPHP.DNSWebServiceTest(); } label1.text = wsphp.isdomainavailable("falat.bielsko.pl").tostring(); Przykład 11 Aplikacja kliencka w technologii.net (ASP.NET, WinForms) Należy od razu wspomnieć, że metody Web Serwisu mogą być wywoływane synchronicznie bądź asynchronicznie. W pierwszym przypadku program czeka na zakończenie wywołania funkcji (odbiór wyników). W drugim wywołanie procedury jest obsługiwane przez osobny wątek. Przydatne jest to w momencie gdy wywołanie procedury jest długotrwałe (np z powodu ilości danych przez nią generowanych. Niektóre technologie (np. Silverlight) wręcz wymuszają stosowanie wywołań asynchronicznych generując klasę proxy tylko w postaci dopuszczającej ten typ uruchamiania procedur (Przykład 12). 19

20 public partial class MainPage : UserControl { DNSWebServiceNamespace.DNSWebServiceSoapClient dnsws= new DNSWebServiceNamespace.DNSWebServiceSoapClient(); NTHillsWSNamespace.NTHillsWSSoapClient nthillsws = new NTHillsSilverlightApplication.NTHillsWSNamespace.NTHillsWSSoapClient(); public MainPage() { InitializeComponent(); dnsws.isdomainavailablecompleted += new EventHandler<NTHillsSilverlightApplication.DNSWebServiceNamespace.IsDomainAvailabl ecompletedeventargs>(isdomainavaileblecompleted); } private void IsDomainAvailebleCompleted(object sender, NTHillsSilverlightApplication.DNSWebServiceNamespace.IsDomainAvailableCompletedEve ntargs e) { } label2.text = e.result.tostring(); private void isdomainavaileblebtn_click(object sender, RoutedEventArgs e) { dnsws.isdomainavailableasync("falat.bielsko.pl"); } } nthillsws.helloworldasync(); Przykład 12 Asynchroniczne wywołanie metod usługi XML w technologii Silverlight. Takie same techniki wykorzystywane są również i w innych technologiach np. Java (Przykład 13.), PHP itd. try { // Call Web Service Operation org.tempuri.nthillsws service = new org.tempuri.nthillsws(); org.tempuri.nthillswssoap port = service.getnthillswssoap(); // TODO process result here java.lang.string result = port.helloworld(); System.out.println("Result = "+result); } catch (Exception ex) { // TODO handle custom exceptions here } Przykład 13 Fragment aplikacji klienckiej w języku JAVA 20

21 5. Prototyp Systemu W ramach prac grupy problemowej postanowiono wykonać dwie prototypowe usługi webowe. By zdefiniować potrzebną funkcjonalność wykonano Web Serwis w wykorzystanie platformy ASP.NET, która wspiera tworzenie tego typu rozwiązać w tak zaawansowany sposób, że jest niewątpliwie technologią umożliwiającą ich najszybsze i najłatwiejsze tworzenie. Wykorzystanie ASP.NET dało możliwość przeanalizowania zestawu metod jakie należy zaimplementować i definicji obiektów, które Web Serwis powinien udostępniać aplikacjom klienckim. Druga usługa prototypowa miała na celu sprawdzenie możliwości tworzenia usług webowych z wykorzystaniem technologii PHP i opracowanie strategii oraz wybór narzędzi, które ułatwią faktyczne wdrożenie usługi na serwerze, na którym pracuje istniejący system. 5.1 Prototyp w APS.NET Jednym z pierwszych elementów jakie należy zdefiniować przy tworzeniu usługi XML są typy danych przez nią wykorzystywane. W omawianym przypadku proponuje się utworzyć zestaw typów wyliczeniowych (Przykład 14) i zestaw klas definiujących obiekty wykorzystywane do obsługi Profilu użytkownika, Transakcje, Domeny (Przykład 15) public enum UserType { Firma, OsobaFizyczna }; public enum ClientType { Normal, Brown, Silver, Gold }; public enum TransactionStatus {InProgres, Closed, Canceled} Przykład 14. Typy wyliczeniowe 21

22 public class DomainInfo { public String DomainID { get; set; } public String Name { get; set; } public String Owner { get; set; } public DateTime RejestrationDate { get; set; } public DateTime EndDate { get; set; } public String Operator { get; set; } } public class VoucherInfo { public String Kod { get; set; } public int IleRazyDoWykorzystania { get; set; } public DateTime DataWaznosci { get; set; } public int Okres { get; set; } public bool TylkoDlaNowejDomeny { get; set; } public String Opis { get; set; } } public class TransactionInfo { public String TransactionID { get; set; } public DateTime CreationDate { get; set; } public double Kwota { get; set; } public TransactionStatus Status { get; set; } public String FakturaNr { get; set; } public String Uwagi { get; set; } public String DotPayID { get; set; } public DateTime TerminPlatnosci { get; set; } } public class UserInfo { public String UserId { get; set; } public String NazwaKonta { get; set; } public String Imie { get; set; } public String Nazwisko { get; set; } public UserType KimJest { get; set; } public ClientType KlientTyp { get; set; } public String Firma { get; set; } public String NIP { get; set; } public String { get; set; } public String ulicainrdomu { get; set; } public String KodPocztowy { get; set; } public String Miasto { get; set; } public DateTime DataRejestracji { get; set; } public DateTime DataUsuniecia { get; set; } } Przykład 15. Klasy udostępniane przez Web Serwis 22

23 Definicja Web Serwisu w przypadku technologii.net wymaga utworzenia klasy pochodzącej od klasy WebSerwice (Przykład 16.). Dodatkowo proponuje się by mechanizm autoryzacji wykorzystywał nagłówki protokołu SOAP, które w przypadku usługi tworzonej na platformie.net są bardzo proste w implementacji (Przykład 16) [MS 2524]. Taki model autoryzacji użytkownika uniezależnia w dużej mierze usługę od technologii transportowej. Można wprawdzie wykorzystywać mechanizmy specyficzne dla serwera na których pracuje usługa jednak w przypadku zmiany systemu mogą nastąpić problemy z autoryzacją użytkowników. Własna implementacja identyfikacji klienta będzie w tym momencie rozwiązaniem, które będzie najbardziej elastyczne zwłaszcza dla Programisty tworzącego aplikację kliencką (Przykład 17.). public class DNSWebService:System.Web.Services.WebService {... public Authentication AuthenticationHeader; } public class Authentication : SoapHeader { public string User; public string Password; } Przykład 16. Głowna klasa Usługi wraz z mechanizmem definiowania nagłówka SOAP DNSWSNamespace.DNSWebService dnsws = new NTHillsWebApplication.DNSWSNamespace.DNSWebService(); DNSWSNamespace.Authentication authenticationinfo = new NTHillsWebApplication.DNSWSNamespace.Authentication(); protected void Button2_Click(object sender, EventArgs e) { ///* authenticationinfo.user = userinp.text; authenticationinfo.password = passwordinp.text; dnsws.authenticationvalue= authenticationinfo; DNSWSNamespace.DomainInfo[] domainsmy = dnsws.getmydomainslist(); ListBox1.Items.Clear(); foreach (PHPWebService.DomainInfo d in domainsmy) { ListBox1.Items.Add(new ListItem(d.DomainName)); }//*/ } Label1.Text = ws.isdomainavailable("falat1.bielsko.pl").tostring(); Przykład 17. Wykorzystanie nagłówka SOAP do identyfikacji użytkownika aplikacja kliencka 23

24 Metody udostępniane przez usługę proponuje się podzielić zostały na 3 grupy. 1. Metody obsługi domen (Przykład 18) 2. Metody obsługi transakcji (Przykład 19) 3. Metody obsługi profilu użytkownika (Przykład 20) O udostępnieniu metody aplikacjom klienckim decyduje przypisanie jej atrybutu [WebMethod], który może definiować również inne parametry charakteryzujące działanie takiej funkcji np. buforowanie wyniku, [MS 2524]. Zastosowanie atrybutu [SoapHeader] skutkuje tym, że podczas wywołania takiej procedury będzie wymagane przesłanie odpowiedniego nagłówka. W tym przypadku będzie on służył do identyfikacji i autoryzacji użytkownika korzystającego z Web Serwisu. [WebMethod] public bool IsDomainAvailable(string domainname) [WebMethod] [SoapHeader("AuthenticationHeader")] public DomainInfo[] GetMyDomains() [WebMethod] [SoapHeader("AuthenticationHeader")] public DomainInfo[] GetDomainsForUser(string userid) [WebMethod] [SoapHeader("AuthenticationHeader")] public DomainInfo[] GetAllDomains() Przykład 18 Podstawowe metody obsługi domen [WebMethod] [SoapHeader("AuthenticationHeader")] public TransactionInfo DomainReservation(String domainname,string Voucher ) [WebMethod] [SoapHeader("AuthenticationHeader")] public TransactionInfo DomainProlongation(String domainname, DateTime DataDoPrzedluzenia, String VoucherID) [WebMethod] [SoapHeader("AuthenticationHeader")] public TransactionInfo[] GetMyTransactionsList(String type)// [all, closed, open, przedplacone]) [WebMethod] [SoapHeader("AuthenticationHeader")] public TransactionInfo CancelTransaction(String TransactionIDToCancel) [WebMethod] [SoapHeader("AuthenticationHeader")] public String GetDotPayLink(String TransactionID) Przykład 19. Metody do obsługi transakcji 24

25 [WebMethod] [SoapHeader("AuthenticationHeader")] public UserInfo GetMyProfile() [WebMethod] [SoapHeader("AuthenticationHeader")] public String ChangeProfile ( UserInfo newprofile) [WebMethod] [SoapHeader("AuthenticationHeader")] public String ChangePasword(String oldpassword, String newpassword) Przykład 20. Podstawowe funkcje obsługi profilu użytkownika Tworząc Web Serwis należy pamiętać często o specyfice technologii w jakich mogą być tworzone aplikacje klienckie. I tak na przykład platforma Silverlight (również Flash) domyślnie zawiera pewne ograniczenia w wywołaniach funkcji leżących poza zakresem witryny na której jest uruchomiona. Oznacza to, że nie wykona, żadnej procedury udostępnionej przez Web Serwisie jeśli on sam jej na to nie pozwoli przez odpowiednio napisany plik clientaccesspolicy.xml (Przykład 21.) <?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from http-request-headers="*"> <domain uri="*"/> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy> Przykład 21. Plik clientaccesspolicy.xml 5.2 Prototyp w PHP z wykorzystaniem biblioteki NuSoft. Ponieważ założono, że system docelowo powinien funkcjonować na serwerze na którym działa już stworzona aplikacja (1.1) należało sprawdzić możliwość wykonania usługi w oparciu o technologie wykorzystywane w istniejącym systemie. Ponieważ istniejący serwer 25

26 WWW działa z wykorzystaniem technologii PHP podjęto próbę stworzenia prototypu aplikacji z wykorzystaniem właśnie tej platformy. Tworzenie usługi typu Web Serwis XML w PHP jest zadaniem znacznie trudniejszym niż w przypadku technologii alternatywnych (Java, ASP.NET). Widać tu ogromne wsparcie producentów oprogramowania komercyjnego dla tego typu aplikacji. Oczywiście PHP oferuje możliwości obsługi protokołu SOAP [PHP SOAP] w swoim standardzie. Jednak brak jest narzędzi dodatkowych pozwalających zautomatyzować i uprościć proces tworzenia Web Serwisu. Problemem np. jest generowanie dokumentu WSDL, który praktycznie trzeba stworzyć ręcznie. Oczywiście istnieją również narzędzia edycji takich dokumentów [XMLSpy] [Zend] jednak są to coraz częściej programy płatne. W omawianym przypadku można by wykorzystać z powodzeniem dokument wygenerowany w prototypie napisanym w technologii ASP.NET jednak zmiany w kodzie mogą powodować, że konieczna będzie ręczna edycja tego pliku. Większość tych problemów rozwiązuje wykorzystanie biblioteki NuSOAP napisanej całkowicie w PHP i umożliwiającej generowanie dynamicznie dokumentu WSDL [NuSOAP], [NuSOAP Sample]. Bibliotekę tą w prosty sposób dołącza się do własnych projektów funkcją require_once z parametrem określającym ścieżkę dostępu do biblioteki NuSOAP. Jednak stosowanie tej biblioteki również wymaga większej pracy niż w technologiach alternatywnych. Napisanie usługi rozpoczyna się od utworzenia obiektu reprezentującego serwer i konfiguracji jego systemu generującego plik WSDL (zdefiniowania przestrzeni nazw używanych w tym pliku), gdyż Web Serwis napisany w PHP może pracować również w trybie bez dokumentu WSDL. Jednak wykorzystanie go przez aplikacje klienckie może być znacznie utrudnione w tym przypadku i raczej ograniczone jest w tedy do klientów tworzonych również w technologii PHP. Uruchomienie Web Serwisu następuje przy wywołaniu metody service (Przykład 22). Wcześniej jednak należy zdefiniować za pomocą odpowiednich funkcji z biblioteki NuSOAP strukturę pliku WSDL i zarejestrować metody udostępnione przez usługę. 26

27 require_once('./lib/nusoap.php'); $ns=' $server = new soap_server(); $server->configurewsdl('dnstestwebservice',$ns);... $HTTP_RAW_POST_DATA = isset($http_raw_post_data)? $HTTP_RAW_POST_DATA : ''; $server->service($http_raw_post_data); Przykład 22. Podstawowa konfiguracji i uruchomienie Web Serwisu w bibliotece NuSOAP Generowanie pliku WSDL wymaga napisania instrukcji tworzących odpowiednie wpisy w dynamicznie generowanym dokumencie WSDL. I tak typy wyliczeniowe reprezentowane są przez definicje typów prostych (Przykład 23.) // definicja typów wyliczeniowych $server->wsdl->addsimpletype( 'UserType', 'xsd:string', 'simpletype', 'scalar', array( Firma, OsobaFizyczna ) ); $server->wsdl->addsimpletype( 'ClientType', 'xsd:string', 'simpletype', 'scalar', array( Normal,Brown, Silver, Gold ) ); $server->wsdl->addsimpletype( 'TransactionStatus', 'xsd:string', 'simpletype', 'scalar', array( InProgres, Closed, Canceled ) ); Przykład 23. Definicje typów wyliczeniowych Definicje klas i struktur reprezentowane są w dokumencie WSKD (w sekcji types) jako typy złożone (Przykład 24, 25,26, 27) reprezentujące struktury danych. 27

28 $server->wsdl->addcomplextype( 'DomainInfo', 'complextype', 'struct', 'all', '', array( 'DomainID' => array('name' => 'DomainID', 'type' => 'xsd:string'), 'DomainName' => array('name' => 'DomainName', 'type' => 'xsd:string'), 'DomainOwner' => array('name' => 'DomainOwner', 'type' => 'xsd:string'), 'DomainRejestrationDate' => array('name' => 'DomainRejestrationDate', 'type' => 'xsd:datetime'), 'DomainExpirationDate' => array('name' => 'DomainExpirationDate', 'type' => 'xsd:datetime'), 'DomainOperator' => array('name' => 'DomainOperator', 'type' => 'xsd:string') ) ); Przykład 24. Definicja Typu DomainInfo $$server->wsdl->addcomplextype( 'UserInfo', 'complextype', 'struct', 'all', '', array( 'UserID' => array('name' => 'UserID', 'type' => 'xsd:decimal'), 'AccountName' => array('name' => 'AccountName', 'type' => 'xsd:string'), 'Imie' => array('name' => 'Imie', 'type' => 'xsd:string'), 'Nazwisko' => array('name' => 'Nazwisko', 'type' => 'xsd:string'), 'KimJest' => array('name' => 'KimJest', 'type' => 'tns:usertype'), 'NIP' => array('name' => 'NIP', 'type' => 'xsd:string'), ' ' => array('name' => ' ', 'type' => 'xsd:string'), 'UlicaNrDomu' => array('name' => 'UlicaNrDomu', 'type' => 'xsd:string'), 'KodPocztowy' => array('name' => 'KodPocztowy', 'type' => 'xsd:string'), 'Miasto' => array('name' => 'Miasto', 'type' => 'xsd:string'), 'UserRejestrationDate' => array('name' => 'UserRejestrationDate', 'type' => 'xsd:datetime'), 'ClosingAccountDate' => array('name' => 'ClosingAccountDate', 'type' => 'xsd:datetime'), ); ) Przykład 25. Definicja typu UserInfo 28

29 $server->wsdl->addcomplextype( 'TransactionInfo', 'complextype', 'struct', 'all', '', array( 'TransactionID' => array('name' => 'TransactionID', 'type' => 'xsd:string'), 'Kwota' => array('name' => 'Kwota', 'type' => 'xsd:decimal'), 'Status' => array('name' => 'Status', 'type' => 'tns:transactionstatus'), 'FakturaNr' => array('name' => 'FakturaNr', 'type' => 'xsd:string'), 'Uwagi' => array('name' => 'Uwagi', 'type' => 'xsd:string'), 'DotPayID' => array('name' => 'DotPayID', 'type' => 'xsd:string'), 'TransactionCreationnDate' => array('name' => 'TransactionCreationnDate', 'type' => 'xsd:datetime'), 'PaymentDeadLineDate' => array('name' => 'PaymentDeadLineDate', 'type' => 'xsd:datetime'), ) ); Przykład 26. Definicja typu TransactionInfo $server->wsdl->addcomplextype( 'VoucherInfo', 'complextype', 'struct', 'all', '', array( 'VoucherID' => array('name' => 'VoucherID', 'type' => 'xsd:string'), 'IleRazy' => array('name' => 'IleRazy', 'type' => 'xsd:decimal'), 'Okres' => array('name' => 'Okres', 'type' => 'xsd:decimal'), 'TylkoNowaDomena' => array('name' => 'TylkoNowaDomena', 'type' => 'xsd:boolean'), 'Uwagi' => array('name' => 'Uwagi', 'type' => 'xsd:string'), 'DataWaznosci' => array('name' => 'DataWaznosci', 'type' => 'xsd:datetime'), ) ); Przykład 27. Definicja typu VoucherInfo Definicja typów reprezentujących tablice jest prezentowana na przykładzie

30 // definicje typów tablicowych $server->wsdl->addcomplextype( 'ArrayOfDomainInfo', 'complextype', 'array', '', 'SOAP-ENC:Array', array(), array( array('ref'=>'soap-enc:arraytype','wsdl:arraytype'=>'tns:domaininfo[]') ), 'tns:domaininfo' ); Przykład 28. Definicja Typu reprezentującego tablicę obiektów DomainInfo Po definicji typów potrzebnych do działania usługi XML można przystąpić do rejestracji funkcji udostępnianej przez Web Serwis. To co w przypadku technologii ASP.NET realizowano przez zastosowanie znacznika [WebMethod] w przypadku PHP wykonuje się za pomocą funkcji register wywoływanej na rzecz obiektu reprezentującego Web Serwis. Podaje się, w postaci parametrów będących tablicami asocjacyjnymi, zestawy i typy argumentów przesyłanych do funkcji i typ wyniku zwracanego przez metodę. Dodatkowe parametry mogą zmieniać sposób zapisywania definicji funkcji w pliku WSDL (rpc / document) lub dodawać dodatkowe informacje opisowe. Oczywiście osobo musi zostać zdefiniowana sama funkcja w prawidłowy sposób obsługująca przesłane parametry i generująca w prawidłowo wyniki. (Przykład 29.) $server->register('isdomainavailable', array('$domainname' => 'xsd:string'), array('return' => 'xsd:boolean'), $ns);//,false,'document','literal','testowy opis metody web serwisu');//); function IsDomainAvailable( $domainname) { if( $domainname == "falat.bielsko.pl") return true; } return false; Przykład 29. Rejestracja metody udostępnianej przez Usługę XML W przypadku gdy metoda zwraca typ złożony należy zadbać o właściwe przygotowanie definicji obiektu, który zostanie zwrócony (Przykład 30.). 30

31 $server->register('getmydomainslist',array(), array('return' => 'tns:arrayofdomaininfo'), $ns);//,false,document,literal,'testowy opis metody web serwisu'); //*/ function GetMyDomainsList() {... for ($i = 0; $i < 7; $i++) { $retval[$i] = array ('DomainID' => 'username'.$i, 'DomainName' => 'Domain'.$i, 'DomainOwner' => $username, 'DomainRejestrationDate' => ' ', 'DomainExpirationDate' => ' ', 'DomainOperator' => $username); } return $retval; } Przykład 30. Rejestrowanie i definiowanie wyniki działania funkcji Stworzony Web Serwis może zostać następnie zainstalowany na serwerze. W przypadku wykorzystania biblioteki NuSOAP przez przeglądarkę dostępny jest spis funkcji obsługiwanych przez Web Serwis (Rys 6.). Podając jako dodatkowy parametr żądania opcję...?wsdl otrzymujemy wygenerowany dokument WSDL opisujący stworzoną usługę (Przykład 31). Rys 6. Strona Web Serwisu tworzonego w oparciu o bibliotekę NuSOAP 31

32 <?xml version="1.0" encoding="iso "?> <definitions xmlns:soap-env=" xmlns:xsd=" xmlns:xsi=" xmlns:soap- ENC=" xmlns:tns=" xmlns:soap=" xmlns:wsdl=" xmlns=" targetnamespace=" <types> <xsd:schema targetnamespace=" <xsd:import namespace=" /> <xsd:import namespace=" /> <xsd:complextype name="domaininfo"> <xsd:all> <xsd:element name="domainid" type="xsd:string" /> <xsd:element name="domainname" type="xsd:string" /> <xsd:element name="domainowner" type="xsd:string" /> <xsd:element name="domainrejestrationdate" type="xsd:datetime" /> <xsd:element name="domainexpirationdate" type="xsd:datetime" /> <xsd:element name="domainoperator" type="xsd:string" /> </xsd:all> </xsd:complextype> <xsd:complextype name="userinfo"> Przykład 31. Plik WSDL Generowany przez bibliotekę NuSOAP 5. Podsumowanie Podczas prac czwartej grupy problemowej skupiono się na prezentacji zagadnień związanych z tworzeniem Sieciowych Usług W XML (tzw. Web Serwisów XML). Omawiano mechanizmy i tworzenia i wykorzystania przez aplikacje klienckie. Uczestnicy mieli okazję obserwować tworzenia zarówno samej Usługi Webowej jak i aplikacji klienckich w różnych technologiach (.NET, JAVA, PHP). Oczywiście jednym z etapów było również zapoznanie się aspektami rejestracji i obsługi domen internetowych, która to wiedza jest niezbędna do prawidłowego zaimplementowania usługi. Wymiernym efektem jest opracowanie projektu systemu i wykonanie aplikacji prototypowych, które mogą zostać wykorzystane podczas realizacji końcowej wersji planowanego rozwiązania informatycznego. 32

33 7. Literatura Literatura w większości bazuje na zasobach internetowych, które obecnie są najbardziej aktualnym źródłem dla ciągle zmieniających się technologii i zagadnień związanych z tworzeniem Usług XML. [DNS Commonet] [DNS] [dotpay] [MS 2524] [MSDN WSE] [MSDN WS-Routing] [MSDN-Disco] [NuSOAP Sample] [NuSOAP] [PHP SOAP] [PHP Spec] [SOAP Spec] [WS-I] [WS-S] [XMLSpy] [Zend] Developing XML Web Services Using Microsoft ASP.NET, Kurs MS