AKADEMIA GÓRNICZO-HUTNICZA

Transkrypt

1 AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI Mobilny klient Web Serwisów dla urządzeń ipaq Kierunek, rok studiów: Wersja z dnia Informatyka, IV rok Przedmiot: Środowiska Implementacji Usług Sieciowych Grupa (projekt): Prowadzący zajęcia: Rok akad: 2007/2008 Dr inŝ. Piotr Nawrocki Semestr: letni Zespół autorski: Monika Nawrot Tomasz Jadczyk Tomasz Sadura nawrot@student.agh.edu.pl jadczyk@student.agh.edu.pl borysb@student.agh.edu.pl Kraków, maj 2008

2 Niniejsze opracowanie powstało w trakcie i jako rezultat zajęć dydaktycznych z przedmiotu wymienionego na stronie tytułowej, prowadzonych w Akademii Górniczo-Hutniczej w Krakowie (AGH) przez osobę (osoby) wymienioną (wymienione) po słowach "Prowadzący zajęcia" i nie moŝe być wykorzystywane w jakikolwiek sposób i do jakichkolwiek celów, w całości lub części, w szczególności publikowane w jakikolwiek sposób i w jakiejkolwiek formie, bez uzyskania uprzedniej, pisemnej zgody tej osoby (tych osób) lub odpowiednich władz AGH. (AGH) w Krakowie Spis treści 1. Temat 4 2. ipaq HP H HP H Środowisko Windows Mobile JavaFX Mobile Co to jest JavaFX JavaFX Script JavaFX Mobile UŜycie JavaFX w przypadku WebServiców JavaME Konfiguracja CLDC Konfiguracja CDC Xlety i Midlety Web Serwisy WSDL JSR Cechy JSR Ograniczenia JSR Cechy JAXP JBoss Instalacja i konfiguracja środowiska Środowisko Developerskie WebSphere Studio Device Developer Micro Environment Toolkit System kontroli wersji Web Serwis Przykładowy Web Serwis z aplikacją kliencką Wykonanie projektu Klient statyczny Opis UŜyte oprogramowanie oraz przydatne linki Problemy i sposoby rozwiązania 29 Plik: Dokumentacja.doc Wersja: z dnia Stron: 2 Długość: 307 kb 2

3 6.2. Klient dynamiczny Opis Serwer usług Web Serwis wysyłający i odbierający maile Klient ipaq korzystający z Web Serwisu Słownik skrótów Bibliografia 48 Plik: Dokumentacja.doc Wersja: z dnia Stron: 3 Długość: 307 kb 3

4 1. Temat Tematem projektu jest stworzenie mobilnego klienta dla urządzeń typu ipaq z systemem Windows Mobile umoŝliwiającego dostęp do zlokalizowanych na serwerze web serwisów. Plan prac obejmuje zarówno stworzenie przykładowego serwisu o określonej funkcjonalności jak i przetestowanie opracowanego rozwiązania na fizycznym urządzeniu. W drugiej części projektu zostanie rozwaŝone umieszczenie serwisu na palmtopie z zewnętrznym klientem. Analiza problemu powinna prowadzić do decyzji dotyczącej implementacji oraz ewentualnym wdroŝeniu takiego rozwiązania. Plik: Dokumentacja.doc Wersja: z dnia Stron: 4 Długość: 307 kb 4

5 2. ipaq W ramach projektu będą dostępne dwa urządzenia typu ipaq. Na nich testowany będzie tworzony klient Web Serwisów na urządzenia mobilne oraz posłuŝą one jako urządzenia do sprawdzenia moŝliwości świadczenia usług web serwisowych w roli serwerów. PoniŜej zebrano informacje na temat palmtopów, które będą pomocne w ocenie moŝliwości i jakości działania rozwaŝanego projektu HP H6300 Pamięć SDRAM 64-MB (55-MB dostępne dla uŝytkownika) ROM 64-MB Procesor Texas Instruments OMAP 1510 (203 MHz) Processor WLAN IEEE 802 Part 11b (802.11b) Interfejsy IrDa USB GSM/GPRS Quad-band GSM/GPRS Bluetooth Bluetooth 1.1 compliant, High-speed UART processor interface System Operacyjny Windows Mobile 2003 software for Pocket PC Phone EditionPocket Całość specyfikacji dostępna [1] HP H5450 Pamięć 64-MB SDRAM; 48-MB Flash ROM Memory Procesor 400 MHz Intel PXA250 Application Processor WLAN IEEE 802 Part 11b (802.11b) Interfejsy IrDa USB Bluetooth Bluetooth 1.1 compliant, High-speed UART processor interface System Operacyjny Microsoft Windows for Pocket PC 2002 Całość specyfikacji dostępna [2]. Plik: Dokumentacja.doc Wersja: z dnia Stron: 5 Długość: 307 kb 5

6 3. Środowisko PoniŜej zawarto podstawowe informacje o technologiach, które zostaną uŝyte w projekcie. Zostały równieŝ przedstawione moŝliwości uŝycia JavaFX Mobile Windows Mobile System Windows Mobile jest przeznaczony do tworzenia aplikacji przy wykorzystaniu framework u.net. Firma SUN oficjalnie nie wspiera tej platformy w swoich rozwiązaniach J2ME, dlatego chcąc uŝywać aplikacji Javy naleŝy korzystać z rozwiązań innych producentów. Przykładami takich rozwiązań są: - IBM MIDP Emulator - Risidoro Intent MIDlet Manager [15] Oba te środowiska implementują wersję MicroEdition. - phoneme i phoneme Advanced [34] są zgodne odpowiednio z konfiguracją CLDC (i profilem MIDP) oraz w wersji Advanced z konfiguracją CDC oraz wszystkimi profilami w wersji 1.1. Istnieją juŝ utworzone pakiety binarne phoneme Advanced dla róznych systemów [35]. Pod adresem [36] znajduje się opis instalacji dla systemów z rodziny Windows Mobile. - IBM WebSphere Everyplace Micro Environment [40] maszyna wirtualna dostępna w wielu wersjach, została wykorzystana w naszym projekcie uŝyliśmy wersji 6.1 spełniającej specyfikację CDC 1.1 z PersonalProfile 1.1, duŝą zaletą jest łatwość rozszerzenia funkcjonalności o dodatkowe pakiety, pozwalające np na korzystanie z WebSerwisów. Istnieje takŝe projekt maszyny wirtualnej spełniającej specyfikację StandardEdition (Mysaifu JVM [14] ) JavaFX Mobile Co to jest JavaFX. JavaFX jest rodziną produktów firmy Sun, mających na celu ułatwienie tworzenia i dostępu do aplikacji typu RIA zarówno na komputerach typu PC jak i urządzeniach PDA oraz telefonach komórkowych. Na konferencji JavaOne w maju 2007 roku ([3]) zostały zaprezentowane język skryptowy JavaFX Script, pozwalający w łatwy sposób tworzyć aplikacje z bogatym interfejsem graficznym i uŝywające multimediów oraz JavaFX Mobile, który będzie pozwalał na uruchamianie aplikacji JavaFX Script na urządzeniach przenośnych. Więcej informacji o JavaFX znajduje się pod adresem: ([4]). Plik: Dokumentacja.doc Wersja: z dnia Stron: 6 Długość: 307 kb 6

7 JavaFX Script Jest to język skryptowy w którym w prosty i szybki sposób moŝna produkować aplikacje wyposaŝone w bogaty interfejs graficzny. Aplikacje napisane w tym języku mają być w łatwy sposób uruchamiane na wielu platformach sprzętowych jak i pod róŝnymi systemami operacyjnymi. Specyfikacja języka jest zgodna JSR 223, co pozwala na uŝywanie klas Javy oraz na wywoływanie kodu JavaFX Script z poziomu aplikacji Java. Do uruchomienia potrzebny jest interpreter (opis uŝywania dostępny pod adresem [5]), moŝliwe jest takŝe uruchamianie kodu skryptu z poziomu klas javy (wymaga JDK 1.6). Język umoŝliwia strukturyzację kodu, ponowne uŝycie oraz enkapsulację. Jest językiem statycznie typowanym. Głównym załoŝeniem dla aplikacji napisanych w tym języku jest znana zasada: Write once, run everywhere. Więcej informacji moŝna znaleźć pod adresami ([6]) i ([7]). Powstaje projekt stworzenia kompilatora ([8]), który tworzyłby plik klas języka Java na podstawie skryptów JavaFX, ale jak na razie projekt ten jest w bardzo wczesnej fazie rozwoju. Do uruchamiania aplikacji skryptowych JavaFX na urządzeniach przenośnych została zaprojektowana platforma JavaFX Mobile JavaFX Mobile JavaFX Mobile to system oprogramowania dla urządzeń mobilnych. Bazą dla tej platformy jest system Linux. System ma być dostępny na licencji OEM dla dystrybutorów urządzeń przenośnych. System ma umoŝliwiać uruchamianie aplikacji Javy ME i Javy SE. System ten powstaje w oparciu o SavajeOS. Niestety poza pokazem na konferencji JavaOne ([3]) o systemie JavaFX Mobile nie ma zbyt wiele informacji. TakŜe nie udało nam się znaleźć Ŝadnej wersji systemu, która moŝliwa byłaby do pobrania i zainstalowania na dostępnych urządzeniach. Na stronach opisujących JavaFX Mobile takŝe nie ma informacji o Ŝadnych wydaniach ani dostępności ([9], [10] oraz FAQ dostępne pod [11] brak odpowiedzi kiedy technologia będzie dostępna dla uŝytkowników. Firma SUN nie odpowiada takŝe na maile w sprawie moŝliwości uzyskania systemu JavaFX Mobile oraz zainstalowania go na urządzeniu typu ipaq UŜycie JavaFX w przypadku WebServiców Korzystanie z WebService ów w przypadku JavaFX jest bardzo proste. Potrzebne jest wygenerowanie Stub ów pozwalających na dostęp do WebService u (moŝe się tym zająć narzędzie typu NetBeans lub moŝna zrobić to ręcznie przy uŝyciu wscompile). Do zakodowania pozostaje jedna klasa w Javie (Helper pozwalający uzyskać dostęp do klasy Stub a), oraz kod klienta w JavaFX. Plik: Dokumentacja.doc Wersja: z dnia Stron: 7 Długość: 307 kb 7

8 package ws; public class ConnectionHelper { public static ws.exampleservice getwsconnection() { try { ws.exampleserviceservice service = new ws.exampleserviceservice(); return service.getexampleserviceport(); } catch (Exception ex) { // TODO handle custom exceptions here } } return null; } Kod 1. Przyład klasy Helper a pozwalającej uzyskać Stub do WebService u. Klasy ExampleService i ExampleServiceService zostały wygenerowane automatycznie na podstawie pliku WSDL. Kod klienta napisany w Java FX wygląda następująco: do { // Do statements are executed off the EDT try { var remoteserver:exampleservice = ConnectionHelper.getWSConnection(); var results = remoteserver.ping("test"); System.out.println("response: {results}"); model.numclicks++; } } catch (e:exception) { System.out.println("exception: {e}"); } Kod 2. Fragment kodu JavaFX obrazującego dostęp do obiektu Web Service u (przy uŝyciu klasy Helpera) i wywołanie metody (ping). Przykład został pobrany ze strony [13]. Plik: Dokumentacja.doc Wersja: z dnia Stron: 8 Długość: 307 kb 8

9 3.3. JavaME Platforma J2ME to ograniczony w porównaniu z J2SE zbiór klas, pozwalający na uruchamianie aplikacji Javy na urządzeniach o ograniczonych zasobach. Zbiór klas podstawowych nazywany jest konfiguracją. Konfiguracja uzupełniana jest przez Profile (dodatkowe API specyfikujące usługi), Profile mogą zostać rozszerzone przez Pakiety Opcjonalne. Rysunek 1. Stos klas J2ME Konfiguracja CLDC Konfiguracja CLDC jest przeznaczona dla urządzeń z mocno ograniczonymi zasobami sprzętowymi (16 bitowy procesor z zegarem 16MHz, kB pamięci dostępnej dla platformy Java). Konfiguracja ta jest przeznaczona szczególnie dla telefonów i starszych typów urządzeń PDA. Pakiety rozszerzające standardowe specyfikacje profili pozwalają na uŝywanie m.in mulitmediów, pakietu Wireless Messaging (usługi SMS), Bluetooth czy Web Serwisów. Aplikacje tworzone dla tej konfiguracji noszą nazwę Midletów. Aktualną specyfikacją jest profil MIDP2.0 [25]. KaŜda klasa startowa tworzonej aplikacji (dla profilu MIDP) musi rozszerzać abstrakcyjną klasę MIDlet i definiować jej metody: startapp(), pauseapp() i destroyapp(). Stworzone pliki java muszą zostać skompilowane przy uŝyciu klas zgodnych z wybraną konfiguracją i profilem. Do zdeployowania aplikacji na urządzeniu wymagany jest takŝe plik opisu (Java Application Descriptor jad). Wewnątrz tego pliku znajdują się wpisy mówiące o nazwie Midletu, klasie głównej, dostawcy Midletu, wersji programu, miejscu gdzie znajduje się plik.jar ze skompilowanymi klasami oraz o rozmiarze tego pliku, a takŝe o profilu i konfiguracji której wymaga program do uruchomienia, a takŝe wiele innych dodatkowych informacji. Przykładowy tutorial opisujący technologię J2ME oraz sposób tworzenia aplikacji (takŝe jej przygotowania do deployowania) znajduje się pod adresem [16]. Testowanie i uruchamianie programów napisanych dla urządzeń mobilnych jest moŝliwe na komputerze typu PC przy uŝyciu narzędzi takich jak Sun Wireless Toolkit ([17]), które pozwala na tworzenie spakowanych archiwów na podstawie wcześniej utworzonych plików javy (zajmuje się kompilowaniem klas Plik: Dokumentacja.doc Wersja: z dnia Stron: 9 Długość: 307 kb 9

10 na podstawie wybranej konfiguracji/profilu, pakowaniem ich do archiwum oraz tworzeniem pliku opisu) oraz na uruchamianie i testowanie w emulowanym środowisku. Więcej informacji o konfiguracji CLDC znajduje się na stronie firmy Sun [26] Konfiguracja CDC W porównaniu z CLDC wymaga dostępności większych zasobów (2MB pamięci RAM, 2,5 MB pamięci ROM, procesory 32 bitowe np. ARM) dostępnych dla platformy Java. Konfiguracja CDC kładzie nacisk na zgodność API z platformą J2SE w wersji CDC 1.1 oparte jest na specyfikacji J2SE Główne róŝnice są w pakiecie odpowiedzialnym za interfejs uŝytkownika java.awt oraz braku cięŝkich pakietów, takich jak javax.swing. CDC jest nadzbiorem klas w porównaniu z CLDC, więc migracja aplikacji z CLDC do CDC nie stanowi problemu, natomiast nie jest w pełni zgodne z MIDP (inne klasy odpowiedzialne za interfejs uŝytkownika). W ramach konfiguracji CDC zostały zdefiniowane następujące profile: - Foundation Profile najbardziej podstawowy profil dla konfiguracji CDC, dostarcza klas wspierających aplikację, np do korzystania z sieci czy urządzeń We/Wy. Nie dostarcza Ŝadnego wsparcia dla grafiki i interfejsów uŝytkownika, przykładami zastosowań są: drukarki sieciowe, routery, serwery aplikacji. Szczegółowy opis pod adresem [29]. - Personal Basis Profile wsparcie dla lekkich interfejsów uŝytkownika, uŝywania JavaBeans i modelu programowania xlet. Zawiera w sobie takŝe cały profil Foundation. Przykłady zastosowań to: telewizja interaktywna, motoryzacja, kamery wideo Szczegółowy opis pod adresem [30]. - Personal Profile pełne wsparcie aplikacji AWT oraz apletów, zawiera cały profil Personal Basis. Przykłady zastosowań to zaawansowane urządzenia PDA, przeglądarki internetowe przeznaczone na urządzenia przenośne. Szczegółowy opis pod adresem [31]. Przykładowe pakiety dodatkowe: - RMI JSR 66 - JDBC JSR Advanced Graphics and User Interface JSR 209, dostarcza klas z pakietu Swing, Java2D - pakiety rozszerzające bezpieczeństwo Java Secure Socket Extension (JSR 219), Java Cryptography Extension (JSR 219), Java Authentication and Authorization Service (JSR 219). Więcej informacji moŝna znaleźć na stronach firmy Sun [27], [28] Plik: Dokumentacja.doc Wersja: z dnia Stron: 10 Długość: 307 kb 10

11 Rysunek 2 Dostępność pakietów dla poszczególnych profili w konfiguracji CDC. Plik: Dokumentacja.doc Wersja: z dnia Stron: 11 Długość: 307 kb 11

12 Xlety i Midlety Konfiguracje CDC i CLDC pozwalają na tworzenie aplikacji, które same zarządzają swoim cyklem Ŝycia i potrzebnymi zasobami. Profile (odpowiednio Personal Basis dla CDC i MIDP dla CLDC) umoŝliwiają tworzenie aplikacji, które są zarządzane przez zewnętrzny zasób (np. Application Manager a). Aplikacja taka moŝe znajdować sie w 4 stanach: - zainicjalizowany - aktywny - zatrzymany - zniszczony Rysunek 3, Cykl Ŝycia Xletu Xlet moŝe być porównany z appletem przy czym udostępnia więcej metod umoŝliwiających zarządzanie cyklem Ŝycia. Poza start i stop moŝliwe jest równieŝ wstrzymanie i ponowne uruchomienie pracy Xletu Web Serwisy Web serwis jest usługą sieciową realizującą określoną funkcjonalność zazwyczaj realizowaną przez pewien komponent programowy niezaleŝny od platformy i implementacji. Jego cechami są: - Definicja za pomocą zestandaryzowanego języka WSDL (Web Services Description Language). - Dostęp do opisu serwisu odbywa się za pomocą rejestru usług np. UDDI (Universal Description Discovery and Integration). - Dostęp do funkcjonalności odbywa się poprzez dobrze zdefiniowany interfejs. - Usługa moŝe być niezaleŝna bądź moŝe być częścią innych usług sieciowych. Na bazie usług sieciowych konstruowane są luźno powiązane rozproszone systemy i aplikacje. Komunikacja z usługami sieciowymi z wykorzystaniem otwartych i zestandaryzowanych internetowych protokołów i formatów danych. Protokołem najczęściej stosowanym do komunikacji z usługami sieciowymi jest SOAP. Plik: Dokumentacja.doc Wersja: z dnia Stron: 12 Długość: 307 kb 12

13 Typowy przykład architektury wykorzystującej web serwisy znajduje się poniŝej: Rysunek 4, Architektura web serwisów Web serwisy rejestrowane są w brokerze usług, skąd klient moŝe pobrać opisy usług zdefiniowane w WSDL. Następnie odbiorca usług moŝe się bezpośrednio kontaktować z ich dostarczycielem WSDL Web Services Description Language jest językiem bazującym na XMLu, który stanowi model opisu web serwisów. Specyfikacja WSDL dostarcza format dokumentów powalający na opis serwisów jako kolekcji portów sieciowych. Ta abstrakcyjna definicja portów i wiadomości jest odseparowana od konkretnego uŝycia i instancji serwisów pozwalając na wielokrotne uŝycie tych samych definicji. Port jest zdefiniowany poprzez adres sieciowy i binding. Natomiast zbiór portów definiuje serwis. Wiadomości są abstrakcyjnymi opisami danych wymienianych w procesie komunikacji z serwisem. Koncepcyjne przedstawienie budowy web serwisu zostało zobrazowane na następującym rysunku: Plik: Dokumentacja.doc Wersja: z dnia Stron: 13 Długość: 307 kb 13

14 Rysunek 5, Wiązania i interfejsy web serwisu WSDL zapewnia grupowanie komunikatów w operacje, a te w interfejsy. Zapewnia sposób definiowania wiązań interfejsów do protokołów oraz przypisanie im adresów punktów końcowych a takŝe definiuje wszystkie te informacje, które są potrzebne do nawiązania i prowadzenia dialogu z serwisem. Dokładny opis składni WSDL znajduje się w [38]. PoniŜej został przedstawiony fragment pliku.wsdl opisujący przykładowy WebSerwis zrealizowany w ramach projektu. Zostały przedstawione fragmenty opisujące dostępne porty, wiązanie do protokołu http oraz ich połączenie w udostępnianą usługę wraz z przypisaniem adresu punktu końcowego. Serwis ten został wykorzystany do zrealizowania statycznego klienta usług na urządzeniu IPAQ (opis w punkcie 6.1). Plik: Dokumentacja.doc Wersja: z dnia Stron: 14 Długość: 307 kb 14

15 <wsdl:porttype name="samplewsporttype"> <wsdl:operation name="getsamplestring"> <wsdl:input name="getsamplestringrequest" message="tns:getsamplestringrequest"> </wsdl:input> <wsdl:output name="getsamplestringresponse" message="tns:getsamplestringresponse"> </wsdl:output> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="samplewshttpbinding" type="tns:samplewsporttype"> <wsdlsoap:binding style="document" transport=" <wsdl:operation name="getsamplestring"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="getsamplestringrequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="getsamplestringresponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="samplews"> <wsdl:port name="samplewshttpport" binding="tns:samplewshttpbinding"> <wsdlsoap:address location=" </wsdl:port> </wsdl:service> Kod 3. Fragment pliku.wsdl opisującego serwis SampleWS, z udostępnianą metodą getsamplestring() 3.5. JSR 172 JSR172 to rozszerzenie specyfikacji J2ME pozwalające na korzystanie z usług typu Web Service. Standaryzuje dwa obszary uŝywania WS zdalne wywołanie metod i analizę plików XML. WSA (Web Services API) przeznaczone jest do współpracy z konfiguracjami dla urządzeń CDC jak i CLDC. Zdalne wywołanie metod oparte jest na podzbiorze klas JAX-RPC 1.1 dostępnych w J2SE, analiza plików XML została zbudowana na podzbiorze klas SAX w wersji 2. Plik: Dokumentacja.doc Wersja: z dnia Stron: 15 Długość: 307 kb 15

16 Rysunek 6 Sposób organizacji typowej aplikacji J2ME wykorzystującej WS. Aplikacja do obsługi dokumentów XML uŝywa JAXP; do uŝycia Web Service u JAX-RPC z wykorzystaniem dostarczonych Stub ów. Rysunek 7 Serce specyfikacji JSR172. SPI (Service Provider Interface) pozwala Stub om na wykonywania zadań związanych ze zdalnym wywołaniem metod, takich jak: - ustawienie specyficznych właściwości - opis parametrów wejściowych i wyjściowych dla danego wywołania - kodowanie parametrów wejściowych - wywołanie metody - dekodowanie i zwrócenie do aplikacji wyników. Plik: Dokumentacja.doc Wersja: z dnia Stron: 16 Długość: 307 kb 16

17 JSR172 Runtime ukrywa całą złoŝoność zarządzania połączeniami i kodowania danych, natomiast SPI oddziela interfejs od implementacji co upraszcza generowanie klas Stubów. Aplikacja kliencka nie korzysta z interfejsu SPI uŝywa klas Stub, które muszą zostać wygenerowane na podstawie plików opisu usług WSDL. Generowanie Stubów musi zostać wykonane narzędziem wspierającym specyfikację JSR172. Taki generator znajduje się np. w pakiecie Sun Wireless Toolkit. Skompilowane klasy Stub muszą zostać dołączone do pakietu z tworzoną aplikacją. UŜycie metod udostępnianych przez Web Service polega na stworzeniu w kodzie aplikacji obiektu Stub, a następnie wywołaniu na nim Ŝądanych metod. Nazwy dostępnych metod są zgodne z nazwami zawartymi w pliku WSDL. Rysunek 8 Sposób realizacji wywołania zdalnie dostępnej metody (wywołanie synchroniczne) Cechy JSR zgodne z WS-I Basic Profile - wspiera protokół SOAP w wersji dowolny protokół transportowy (np. HTTP 1.1) który pozwala na transportowanie wiadomości SOAP wspiera pełny zestaw typów danych: boolean, byte, short, int, long, float, double, String, tablice, typy złoŝone (dla konfiguracji CLDC 1.0 nie są obsługiwane typy float i double są mapowane do String). - obsługuje tylko znakową reprezentację wiadomości SOAP uŝywanych przy wywołaniach zdalnych metod (tylko operacje WSDL w trybie Document/Literal) Plik: Dokumentacja.doc Wersja: z dnia Stron: 17 Długość: 307 kb 17

18 Ograniczenia JSR nie wspiera wiadomości SOAP z załącznikami (brak moŝliwości wysyłania jako parametrów i odbierania wyników ze zdalnych wywołań jako np plików graficznych czy dokumentów xml), SOAP handlers, (brak moŝliwości zaawansowanego przetwarzania odpowiedzi SOAP), kodowanej reprezentacji wiadomości SOAP - określa tylko specyfikację klienta WS, nie umoŝliwia stworzenia na urządzeniu mobilnym serwera WS - brak wsparcia dla wyszukiwania usług (UDDI) - pozwala na uŝywanie tylko statycznie wygenerowanych Stub ów (specyfikacja JAX-RPC 1.1 pozwala takŝe na uŝywanie Dynamicznego Proxy oraz DII (Dynamic Invocation Interface) ). Developer jest zmuszony do wygenerowania Stubów przy pomocy narzędzia WSDL-to-Java (np. wscompile). - dostępne jest tylko synchroniczne wywoływanie metod, model Ŝądanie odpowiedź (pełna specyfikacja JAX-RPC 1.1 określa ponadto asynchroniczne (nieblokujące) wywołanie, oraz wywołanie metody bez odpowiedzi tylko Ŝądanie) - błędy w wywołaniach metod nie są mapowane do SOAPFaultException, tylko do RemoteException Cechy JAXP - oparte na podzbiorze SAX 2 (SAX 1.0 nie jest wspierany) - przestrzeń nazw XML - moŝliwe kodowanie UTF-8 i UTF-16 - nie jest wspierany DOM (Document Object Model) zarówno poziom 1.0 jak i 2.0 (został uznany za zbyt cięŝki) - brak wsparcia dla XSLT - wspiera DTD Więcej informacji o Web Service ach dla J2ME dostępnych jest pod adresami: [19], [20] i [21]. Pełna specyfikacjia JSR172 [22] JBoss JBoss jest serwerem aplikacji, dostępnym na licencji LGPL. W wersji 4.0 i wyŝszych implementuje pełen zestaw usług J2EE 1.4 (EJB, JCA, JSP, JMX, HTTP, itd.). Jego niewątpliwą zaletą jest niezaleŝność od platformy, osiągana między innymi dzięki implementacji serwera w języku Java. Serwer JBoss moŝna uruchomić na kaŝdej konfiguracji z działającą maszyną wirtualną Java. Postawienie serwera sprowadza się do ściągnięcia archiwum, rozpakownia go i uruchomienia pliku run.sh lub run.bat, znajdującego się wśród Plik: Dokumentacja.doc Wersja: z dnia Stron: 18 Długość: 307 kb 18

19 plików aplikacji. W poprzednich wersjach JBoss posiadał zmodyfikowany engine AXIS o nazwie JBoss.net, pozwalający na obsługę web serwisów. Od wersji 4.0 posiada własny natywny serwer web serwisów. Zdeployowanie web serwisu sprowadza się do skopiowania modułu z web serwisem do odpowiedniego katalogu deploy na serwerze JBoss. NaleŜy zadbać o odpowiednią konfigurację serwletu udostępniającego web serwis, zaleŝną od uŝywanego enginu web serwisów. Plik: Dokumentacja.doc Wersja: z dnia Stron: 19 Długość: 307 kb 19

20 4. Instalacja i konfiguracja środowiska 4.1. Środowisko Developerskie WebSphere Studio Device Developer WebSphere Studio Device Developer dostarcza środowiska programistycznego do budowy, testowania i wdraŝania aplikacji J2ME, które pracują na przenośnych urządzeniach takich jak telefony komórkowe, PDA czy komputery kieszonkowe. W połączeniu z WebSphere Everyplace Micro Environment dostarczają środowiska wykonania aplikacji na najpopularniejszych urządzeniach mobilnych i systemach operacyjnych jak Linux, Palm OS, Pocket PC. WebSphere Studio Device Developer umoŝliwia: - Rozwój aplikacji e-biznesowych na telefonach komórkowych i PDA. - Budowę aplikacji w środowisku J2ME w wielu profilach i konfiguracjach. - Budowę aplikacji czasu rzeczywistego na inne urządzenia funkcjonujące w systemach zamkniętych. - Zawiera mechanizmy pozwalające na optymalizację zuŝycia pamięci przez aplikację na urządzeniach przenośnych. - Wspiera technologie kompilacji JIT (Just-In-Time) i AOT (Ahead-Of-Time). - UmoŜliwia XIP (Execute-in-Place) deployment. Więcej informacji o środowisku oraz instrukcje uŝywania znajdują się w materiałach firmy IBM (Redbook: Using WebSphere Studio Device Developer to Build Embedded Java Applications [41]). Instalacja i uruchomienie wersji Trial tego środowiska sprawia drobne problemy przed instalacją naleŝy zmienić datę systemową na datę przed w przeciwnym wypadku nie utworzą się poprawne pliki z licencjami. Środowisko WSDD umoŝliwia rozszerzenie moŝliwości standardowych profili maszyny wirtualnej w konfiguracji CDC o dodatkowe funkcje. Do nich naleŝą m.in SWT słuŝące do tworzenia rozbudowanych interfejsów uŝytkownika czy teŝ wsparcie dla technologii Web Serwisów. Po zainstalowaniu tego ostatniego narzędzia (dostępnego w pakiecie Microplace Environment Toolkit) WSDD pozwala na generowanie Stubów na podstawie plików opisu usług wsdl dostępnych zdalnie. Generowanie stubów wewnątrz WSDD zapewnia Ŝe będą one kompatybilne z klasami dostępnymi w pliku WebServicesMe.jar, który jest wymagany do uruchomienia WebSerwisów na maszynie J9, na urządzeniu mobilnym (próby uŝywania klas Stubów wygenerowanych przez narzędzia firmy Sun powodowały błędy typu NoSuchMethodException lub NoClassDefFoundException). Plik: Dokumentacja.doc Wersja: z dnia Stron: 20 Długość: 307 kb 20

21 Rysunek 9 Program WebSphere Studio Device Developer Rysunek 10. MoŜliwe rozszerzenia dla standardowej konfiguracji progamu WSDD. Plik: Dokumentacja.doc Wersja: z dnia Stron: 21 Długość: 307 kb 21

22 Micro Environment Toolkit Micro Environment Toolkit jest dodatkiem do WebSphere Studio, który dostarcza zbioru narzędzi i środowisko wykonania wspierające budowę, testowanie i deployment aplikacji na urządzeniach przenośnych. Kluczowe komponenty tego narzędzia zostały przedstawione na poniŝszym obrazku: Rysunek 11, Micro Environment Toolkit Wszystkie powyŝsze technologie pozwalają aplikacjom znajdującym się na urządzeniach przenośnych na interakcję z innymi aplikacjami, serwisami i danymi udostępnianymi przez dostawców serwisów, dostarczając kompletne rozwiązania programowe. Cechami Micro Environment Toolkit są: - Oparcie na platformie Eclipse umoŝliwia łatwe rozszerzanie oraz dołączenie do WebSphere Studio Device Developer. - Dostarczenie rozwiązań do budowy aplikacji klasy enterprise przez wsparcie dla niektórych modeli programistycznych wprowadzonych przez J2EE Servlety, JSP, web serwisy. - Wsparcie dla modelu programistycznego OSGi. - Rozszerzenie dla modelu programistycznego MIDP przez umoŝliwienie aplikacjom MIDP na współpracę z web serwisami System kontroli wersji W celu umoŝliwienia pracy grupowej został utworzony projekt dostępny pod adresem: Pod dostępnym tam adresem SVN znajdują się źródła i zasoby utworzone w ramach prac nad projektem. W chwili obecnej jest to niniejsza dokumentacja oraz przykładowy web serwis opisany w punkcie 5.1. Plik: Dokumentacja.doc Wersja: z dnia Stron: 22 Długość: 307 kb 22

23 5. Web Serwis 5.1. Przykładowy Web Serwis z aplikacją kliencką. W ramach nauki i poznawania narzędzi został opracowany bardzo prosty Web Serwis, dostarczający metody getrandomnumber() -losuje liczbę z zakresu 0 99 getsamplestring(string text) łączy tekst z parametru z domyślnym prefiksem oraz aplikacja j2me wykorzystująca metody udostępniane zdalnie. Kod public class public String getsamplestring(@webparam(name="wstextparam") String text) { return "Sample string from WS: " + text; public long getrandomnumber() { return Math.round(Math.random()) % 100; } Kod 4. Serwis SampleWS udostępniający dwie metody: getsamplestring() i getrandomnumber() Do przetwarzania wiadomości SOAP został uŝyty framework XFire w wersji Web Service został umieszczony w kontenerze aplikacji Tomcat. Kod aplikacji: Przy uŝyciu narzędzia wscompile dostarczonego z Sun Wireless Toolkit, na podstawie pliku wsdl opisującego przykładowy Web Service został wygenereowany zestaw klas Stub, pozwalający na dostęp do zdalnych metod. Składnia polecenia: C:\WTK2.5.2\bin\wscompile gen:client configuration.xml Plik: Dokumentacja.doc Wersja: z dnia Stron: 23 Długość: 307 kb 23

24 Zawartość pliku z konfiguracją (określa połoŝenie pliku wsdl): <configuration xmlns=" <wsdl location=" packagename="pl.edu.agh.sius.learning.wsclient.stubs"/> </configuration> Kod 5. Plik opisujący lokalizację wsdl-a oraz pakiet do jakiego mają zostać dodane klasy stubów. Fragment kodu przykładowego klienta: public class MainMidlet extends MIDlet { protected void startapp() throws MIDletStateChangeException { SampleWSPortType_Stub service = new SampleWSPortType_Stub(); String retvalue = ""; try { mainform.append("call getsamplestring()" ); retvalue = service.getsamplestring("testing midlet"); mainform.append(retvalue); System.out.println("WS: " + retvalue); retvalue = "" + service.getrandomnumber(); mainform.append("random number from WS:"); mainform.append(retvalue); System.out.println("WS random number: " + retvalue); } Display.getDisplay(this).setCurrent(mainForm); } catch (RemoteException e) { Display.getDisplay(this).setCurrent(new Alert("Error")); } } Kod 6. Kod klient-a WebSerwisu aplikacja typu MIDlet W powyŝszym przykładzie nie są ustawiane parametry dla Stub a (np. Endpoint). Domyślnie plik Stub został wygenerowany z wartością określającą Endpoint z adresu skąd był pobierany plik WSDL. Obie lokacje w tym przypadku się pokrywają. Prosty przykład tworzenia aplikacji typu Xlet (dla konfiguracji CDC) znajduje się pod adresem [32]. Plik: Dokumentacja.doc Wersja: z dnia Stron: 24 Długość: 307 kb 24

25 Sposób uruchomienia: 1. Stworzenie nowego projektu w Sun WirelessToolkit, platforma docelowa MDA (zawiera konfigurację CLDC 1.1 i profil MIDP 2.0, co pozwala na korzystanie z klas określonych w specyfikacji JSR172) jako nazwa klasy musi zostać podana nazwa utworzonego Midletu wraz z pełną ścieŝką pakietów (pl.edu.agh.sius.learning.wsclient.mainmidlet) 2. Skopiowanie klas do katalogu jaki został utworzony (instrukcje na konsoli programu WirelessToolkit) 3. Zbudowanie i uruchomienie aplikacji. Plik: Dokumentacja.doc Wersja: z dnia Stron: 25 Długość: 307 kb 25

26 6. Wykonanie projektu PoniŜej znajduje się opis aplikacji tworzonych w ramach projektu wraz z dokładnym opisem ich działania oraz napotkanych problemów Klient statyczny Pierwszym etapem projektu było utworzenie statycznego klienta pracującego na urządzeniu ipaq odwołującego się do web serwisu znajdującego się na zdalnym serwerze Opis Program klienta wykorzystuje usługi uruchomione na komputerze stacjonarnym, przy uŝyciu wcześniej wygenerowanych Stub-ów, których kod został dołączony do programu klienta. Rysunek 12. Architektura programu uŝywającego statycznych Stubów Uruchomiony web serwis posiada prostą funkcjonalność: Plik: Dokumentacja.doc Wersja: z dnia Stron: 26 Długość: 307 kb 26

27 public String getsamplestring() { System.err.println("Call setsamplestring()"); return "Sample string from public long getrandomnumber() { System.err.println("Call getrandomnumber()"); return Math.round(Math.random() * 100); } Kod 7. Funkcjonalność udostępniana przez Web Serwis Klient jest prostym programem z interfejsem graficznym, w którym po kliknięciu przycisku tworzony jest obiekt Stub i na nim wywoływana metoda getrandomnumber(), której wywołanie przekazywane jest do WebSerwisu. Wynik wyświetlany jest na ekranie, w przypadku błędu jego treść takŝe jest wyświetlana na ekranie. Dodatkowo strumień wyjściowy i strumień błędów zostały przekierowane do plików, w celu analizy zachowania programu oraz pojawiających się błędów. public void actionperformed(actionevent arg0) { number++; System.out.println("Action performed, current nr: " + number); dl.settext("action nr: " + number); SampleWSHttp_Stub ws = new SampleWSHttp_Stub(); System.out.println("Stub created"); try { lb.settext("num: " + ws.getrandomnumber()); System.out.println("Method called"); } catch (Throwable e) { lb.settext(e.getmessage()); System.err.println("Error: " + e.getmessage()); e.printstacktrace(); } } Kod 8. Wywołanie metody udostępnianej przez Web Serwis w programie klienta W celu uruchomienia całości konieczne było: 1. Utworzenie WebSerwisu oraz umieszczenie go w kontenerze - w naszym przypadku był to kontener aplikacji Tomcat, do obsługi WebSerwisu został wykorzystany Xfire. 2. Uruchomienie aplikacji WebSphere Studio Device Developer (naleŝy pamiętać o zmianie daty na rok 2005). Plik: Dokumentacja.doc Wersja: z dnia Stron: 27 Długość: 307 kb 27

28 3. Pobraniu dodatkowego narzędzia: Micro Environment Toolkit jest to rozszerzenie WebSphere Studio Device Developer (instalacja przez Help -> Software Updates -> Update Manager), narzędzie to umoŝliwia tworzenie nowych projektów, korzystających z Web Serwisów oraz dostarcza bibliotekę WebServicesME.jar i rmip.jar, które są konieczne do uruchomienia klienta Web Serwisu na urządzeniu przenośnym. 4. Utworzenie nowego projektu J2ME z wybraną odpowiednią wersją maszyny wirtualnej (personal profile). 5. Utworzenie Stubów z dostępnego pliku wsdl: poprzez dodanie do projektu New -> Other ->Mobile Web Services Client -> Mobile Web Services Client for Extension Services podanie adresu pliku wsdl na podstawie którego mają zostać wygenerowane Stub-y (w naszym przypadku: wymaga to uruchomionego kontenera aplikacji oraz zdeployowanej w nim usługi 6. Utworzeniu klas klienta z wykorzystaniem wygenerowanych stubów 7. Spakowanie wszystkich wymaganych klas do archiwum.jar. 8. Umieszczenie pliku jar na urządzeniu przenośnym 9. Utworzenie pliku.lnk który będzie uruchamiał aplikację. W naszym przykładzie wykorzystaliśmy statyczną metodę main istnieje takŝe moŝliwość uruchomienia aplikacji jako zarządzanego Xlet-a. Plik.lnk ma postać: 255#"\J9\PPRO11\bin\j9w.exe" "-jcl:ppro11" "- Xbootclasspath/a:\ext\webservicesme.jar;\ext\rmip.jar" "-cp" "\My Documents\Personal\j2meTest.jar" "samplepkg.test" Kod 9. Plik.lnk uruchamiający przykład na urządzeniu IPAQ Składa się kolejno z: - nazwa (wraz z pełną ścieŝką) pliku z maszyną wirtualną javy - nazwa profilu jaki ma zostać uruchomiony (Personal Profile 1.1) - dodatkowych bibliotek potrzebnych do wykonania programu (w tym przypadku są to WebServicesMe.jar (zapewnia obsługę WebSerwisów) oraz rmip.jar (RMI dla j2me), obie umieszczone w katalogu \ext. - nazwa wraz ze ścieŝką do pliku jar zawierającego uruchamiany kod - nazwa klasy z metodą main UŜyte oprogramowanie oraz przydatne linki 1. IBM WebSphere Studio Device Developer Plik: Dokumentacja.doc Wersja: z dnia Stron: 28 Długość: 307 kb 28

29 2. IBM Workplace Client Technology, Micro Edition V IBM WebSphere Everyplace Micro Environment - jest to maszyna wirtualna Javy, korzystaliśmy z wersji 6.1.1, implementującej Personal Profile Problemy i sposoby rozwiązania 1. Instalacja maszyny wirtualnej Podczas uruchamiania programu natknęliśmy się na kilka problemów związanych z maszyną wirtualną: - brak niektórych klas (np. RemoteException) został dodany plik rmip.jar, zawierający klasy RMI, Ŝeby plik ten był ładowany przy kaŝdym uruchomieniu maszyny wirtualnej musi zostać umieszczony w katalogu ext maszyny j9. Pełna ścieŝka zaleŝy od miejsca instalacji i wersji maszyny, w naszym przypadku: \J9\PPRO11\lib\jclFoundation11\ext 2. Kodowanie znaków Wywoływanie metod na Stubie powodowało wyjątek: javax.xml.rpc.jaxrpcexception: java.io.unsupportedencodingexception: UTF-8. Przyczyna nie została zdiagnozowana problem rozwiązany przez ponowną instalację maszyny wirtualnej (w celach testowych została przeprowadzona instalacja takŝe wersji implementującej Personal Profile 1.0) 3. Tworzenie archiwów.jar Pliki wygenerowane w WebSphere Device Developer (.jar) nie chciały się uruchamiać, pomimo poprawnie zdefiniowanych linków. Rozwiązanie: Kod klienta został stworzony i spakowany do archiwum przy uŝyciu Eclipse a. W programie WSDD generowane były tylko Stuby Web Serwisu. 4. Generowanie Stubów Stuby generowane przy uŝyciu generatora firmy Sun (dostarczanego z Sun Wireless Toolkit) tworzyły kod, który nie chciał się uruchamiać na maszynie J9 (korzystanie z klas których na tej maszynie brakowało, pomimo dodania plików rmip.jar oraz WebServicesMe.jar). Plik: Dokumentacja.doc Wersja: z dnia Stron: 29 Długość: 307 kb 29

30 Rozwiązanie: Tworzenie Stubów przy uŝyciu programu WSDD, które jest prostsze (wymaga tylko uruchomionego kontenera aplikacji ze zdeployowaną usługą WebSerwisu, nie jest konieczne tworzenie dodatkowych deskryptorów pozwalających wygenerować Stub y jak przy uŝyciu narzędzia firmy Sun). 5. Pliki uruchomieniowe.lnk W systemie Windows Mobile pliki te mogą mieć rozmiar nie przekraczający 255 znaków. MoŜe to stanowić problem w przypadku duŝej ilości dodatkowych plików.jar potrzebnych do uruchomienia programu (podawanych jako Xbootclasspath), rozwiązaniem jest dodanie wymaganych plików do katalogu ext maszyny wirtualnej (jak podano w punkcie 1.) wtedy nie muszą one być uwzględniane w pliku lnk. 6. ŚcieŜki relatywne System Windows Mobile nie wspiera ścieŝek relatywnych w dostępie do plików / zasobów. Wymagana jest pełna ścieŝka dostępu. Plik: Dokumentacja.doc Wersja: z dnia Stron: 30 Długość: 307 kb 30

31 6.2. Klient dynamiczny Opis Rysunek 13, Architektura programu uŝywającego dynamicznego ładowania Stubów Klient pobiera z ustalonego adresu http plik wslist.txt, który zawiera nazwy dostępnych web serwisów wraz z pełną ścieŝką pakietów. ws.samplewshttp_stub samplepkg.ws2.anothersamplewshttp_stub Kod 10. Zawartość pliku opisującego udostępniane Web Serwisy wslist.txt Na tym samym serwerze muszą znajdować się klasy Stubów (takie jak podane w pliku opisu wslist.txt) oraz wszystkie inne niestandardowe klasy, potrzebne do wywoływania metod na Stub ach (w przypadku wygenerowanego przez program WSDD SampleWSHttp_Stub.class jest to klasa SampleWSPortType.class). Plik: Dokumentacja.doc Wersja: z dnia Stron: 31 Długość: 307 kb 31

32 Program klienta na podstawie pliku wslist.txt tworzy listę dostępnych WebSerwisów. Po wybraniu serwisu wszystkie wymagane klasy są ładowane z serwera http (tego samego na którym znajduje się plik wslist.txt), z klasy Stub a pobierane są dostępne do wywołania metody i tymi metodami wypełniana jest druga lista wyboru. Po wybraniu nazwy metody jest ona wywoływana na obiekcie Stub a a wynik jej działania wypisywany na ekranie programu klienta. ZałoŜenia: W celu uproszczenia nasza implementacja zakłada istnienie jednego, ustalonego punktu skąd pobierany jest opis WebSerwisów (nazwy klas Stubów) oraz ładowane są klasy Stub ów. Wywoływane metody udostępniane przez serwisy muszą być bezparametrowe. MoŜliwości rozwoju: PoniewaŜ udało nam się uruchomić serwer http wraz z Axis-em na urządzeniu przenośnym (opis w następnym punkcie) istnieje moŝliwość stworzenia klienta w pełni dynamicznie korzystającego z WebSerwisów, przy uŝyciu właśnie Axis-a. Plik: Dokumentacja.doc Wersja: z dnia Stron: 32 Długość: 307 kb 32

33 final ClassLoader classloader = new URLClassLoader( new URL[] { new URL( BASE_URL ) } ); stubslist = new List(); stubslist.addactionlistener(new ActionListener() { public void actionperformed(actionevent arg0) { try { final Class clazz = Class.forName( stubslist.getselecteditem(), true, classloader ); object = clazz.newinstance(); Class[] interfaces = clazz.getinterfaces(); for(int j = 0; j < interfaces.length; j++ ) { final Method classmethods[] = clazz.getdeclaredmethods(); methodslist.removeall(); methods = new Method[classMethods.length]; } }); for (int i = 0; i < classmethods.length; i++) { methodslist.add( classmethods[i].getname() ); methods[i] = classmethods[i]; } } } catch (Exception e) { throw new RuntimeException(e); } methodslist = new List(); methodslist.addactionlistener( new ActionListener() { public void actionperformed(actionevent e) { try { Method method = methods[methodslist.getselectedindex()]; Object result = method.invoke(object, new Object[0]); output.settext(result.tostring()); } catch(exception ex) { throw new RuntimeException(ex); } }); } Kod 11. Pobieranie klas Stubów z serwera, wypełnianie listy dostępnych do wywołania metod oraz wywołanie wybranej przez uŝytkownika metody (listener na obiekcie methodslist). Plik: Dokumentacja.doc Wersja: z dnia Stron: 33 Długość: 307 kb 33

34 6.3. Serwer usług UmoŜliwienie udostępniania usług przez urządzenie IPAQ wymagało uruchomienia serwera http wraz z obsługą serwletów. Zdecydowaliśmy się na serwer Jetty w wersji który w całości jest stworzony w Javie, do obsługi WebSerwisów uŝyliśmy Axis-a Rysunek 14. Architektura wykorzystująca serwer WebSerwisów na urządzeniu IPAQ oraz klienta korzystającego ze statycznych Stubów. Przebieg uruchamiania serwera http z kontenerem serwletów: 1. Odchudzenie serwera jetty: Brak obsługi jsp-2.1 Usunięcie zbędnych dodatków (katalogi examples, extras, javadoc) 2. Przygotowanie klasy uruchamiającej serwer Jetty Wybraną konfiguracją jest klasa org.mortbay.jetty.example.likejettyxml Zamiana ścieŝek względnych na bezwzględne (dotyczy katalogów z aplikacjami webapps, domyślnego pliku opisującego webdefault.xml oraz plików logów Zamiana obiektu Connectora, z zalecanego SelectChannelConnector na standardowy, który nie wymaga obecności klas nio: SocketConnector Plik: Dokumentacja.doc Wersja: z dnia Stron: 34 Długość: 307 kb 34

35 Server server = new Server(); BoundedThreadPool threadpool = new BoundedThreadPool(); threadpool.setmaxthreads(5); server.setthreadpool(threadpool); Connector connector = new SocketConnector(); connector.setport(8080); server.setconnectors(new Connector[]{connector}); HandlerCollection handlers = new HandlerCollection(); ContextHandlerCollection contexts = new ContextHandlerCollection(); RequestLogHandler requestloghandler = new RequestLogHandler(); handlers.sethandlers(new Handler[]{contexts, new DefaultHandler(),requestLogHandler}); server.sethandler(handlers); WebAppContext.addWebApplications(server, "\\httpserv\\jetty \\webapps", "\\httpserv\\jetty-6.1.3\\webdefault.xml", true, false); NCSARequestLog requestlog = new NCSARequestLog("\\httpServ\\jetty \\logs\\jetty log"); requestlog.setextended(false); requestloghandler.setrequestlog(requestlog); server.setstopatshutdown(true); server.setsendserverversion(true); server.start(); server.join(); Kod 12. Klasa uruchamiająca serwer Jetty na urządzeniu IPAQ 3. Rozwiązanie problemów z ClassLoaderem W klasach org.mortbay.jetty.handler.defaulthandler oraz org.mortbay.xml.xmlconfiguration wywołanie metody getclassloader() zwracało pustą referencję, co powodowało powstanie wyjątku podczas działania. Rozwiązaniem tego problemu okazało się podmienienie wywołań metod getresource() na stałe ścieŝki dostępu do zasobów, wadą takiego podejścia jest uzaleŝnienie poprawności działania serweru od jednej, ściśle określonej lokalizacji umiejscowienia wymaganych bibliotek Plik: Dokumentacja.doc Wersja: z dnia Stron: 35 Długość: 307 kb 35

36 //URL configurl = XmlConfiguration.class.getClassLoader().getResource("org/mortbay/xml/config ure_6_0.dtd"); URL configurl = new URL("jar:file:/ext/jetty jar!/org/mortbay/xml/configure_6_0.dtd") ; //URL fav = this.getclass().getclassloader(). getresource("org/mortbay/jetty/favicon.ico"); URL fav = new URL("jar:file:/ext/jetty jar!/org/mortbay/jetty/favicon.ico"); Kod 13. Zmiany w kodzie klas serwera Jetty org.mortbay.jetty.handler.defaulthandler oraz org.mortbay.xml.xmlconfiguration Oryginalne klasy dostarczone do serwera jetty zostały skompilowane przy uŝyciu maszyny IBM J9 (specyfikacja j2se 1.4) oraz podmienione w bibliotekach serwera jetty (bibliotekea jetty jar) 4. Dostarczenie potrzebnych klas Do pełnego działania jetty wymagał kilku klas (np. java.util.regex) których brakowało w implementacji maszyny wirtualnej, zostały one pobrane z implementacji j2se, spakowane oraz dodane jako archiwum do katalogu ext w katalogu z profilem Foundation1.1 maszyny wirtualnej na urzadzeniu PDA. Część klas potrzebnych do działania (np parsery Xml) była juŝ na ścieŝce klas, ale znajdowały sie tam niezgodne wersje (np biblioteka WebServicesMe.jar posiada okrojoną wersję klas (Fabryki parserów). Problem został rozwiązany przez usunięcie WebServicesMe.jar z listy Xbootclasspath w linku oraz dodanie bibliotek Xerces dostarczonych do jetty-ego do katalogu ext maszyny wirtualnej Taka konfiguracja uruchomieniowa pozwala na automatyczne dodawanie aplikacji z katalogu webapps (nie jest to hot deploy, aplikacje dodają się tylko przy starcie serwera, ale nie wymaga zmian w kodzie przy kaŝdym dodanym serwlecie). Problemy: Maszyna wirtualna zainstalowana na urządzeniu PDA i maszyna wirtualna, która instaluje się na komputerze stacjonarnym to dwie róŝne maszyny. Na komputerze stacjonarnym znajduje się pełna implementacja j2se w wersji 1.4 natomiast na PDA jest konfiguracja j2me CDC PersonalProfile 1.1, która jest podzbiorem klas j2se 1.4, z czego mogą się rodzić problemy typu: NoClassDefFound, czy NoSuchMethodException Plik: Dokumentacja.doc Wersja: z dnia Stron: 36 Długość: 307 kb 36

37 Maszyna implementująca PersonalProfile1.0 jest niewystarczająca, część klas (a szczególnie metod w klasach) jest dostępnych dopiero od wersji PersonalProfile1.1 W bibliotece WebServicesMe.jar są dostępne klasy zajmujące się parsowaniem Xml-a, zbiór tych klas pokrywa się z klasami potrzebnymi do uruchomienia serwera Jetty (nazwy, pakiety), natomiast implementacja jest niewystarczająca (brak odpowiednich metod), naleŝy tak ustawić ścieŝki Ŝeby klasy z tej biblioteki znalazły się później niŝ klasy parsera Xerces, który zawiera pełną potrzebną implementację xml-a. Instalacja Axis-a Instalacja polegała na skopiowaniu folderu z Axis-em do katalogu WebApps serwera Jetty (potrzebne są tylko pliki z katalogu AXIS_DIR/webapps/axis) oraz na dodaniu wymaganych klas potrzebnych do uruchomienia Axis-a, takich jak java.sql.date, java.util.logging.*. Wszystkie wymagane klasy których domyślnie nie ma w implementacji PersonalProfile 1.1 w maszynie IBM J9 dodaliśmy do pliku core.zip. Serwer Jetty współpracuje z Axis-em bez potrzebnych dodatkowych konfiguracji. Korzystanie z Axis-a udostępnianie WebSerwisów W celu udostępnienia web serwisów przez Axisa naleŝy klasę javy implementującą usługi skopiować do katalogu <your-webapp-root>/axis/ zmieniając jej rozszerzenie na jws. W tym momencie powinien być moŝliwy dostęp do niej poprzez URL. Przy załoŝeniu, Ŝe Axis został uruchomiony na porcie 8080 będzie to Axis automatycznie lokalizuje plik, kompiluje go do pliku *.class i konwertuje wiadomości SOAP na wywołania w języku Java. PowyŜszy sposób cechuje się prostotą, ale i ograniczeniami wymaga posiadania źródeł serwisu oraz zarządzania sposobem dostępu (mapowanie typów, kontrola wywołań). Stąd do deploymentu moŝliwe jest uŝycie WSDD (Web Service Deployment Descriptor) formatu bazującego na XMLu, który umoŝliwia pozbycie się wszystkich ograniczeń związanych z automatycznym udostępnianiem serwisów. Dokładny opis uŝycia web serwisów pod Axis em znajduje się w [39]. W celach sprawdzenia poprawności konfiguracji skorzystaliśmy z prostej klasy Calculator, posiadającej dwie metody dodawania i odejmowania dwóch liczb. Plik: Dokumentacja.doc Wersja: z dnia Stron: 37 Długość: 307 kb 37

38 public class Calculator implements CalculatorWS{ public int add(int i1, int i2) { return i1 + i2; } } public int subtract(int i1, int i2) { return i1 - i2; } Kod 14. Kod udostępnianej na urządzeniu IPAQ usługi Web Serwis Plik opisu WSDD (Web Service Deployment Descriptor) wygląda następująco: <deployment xmlns=" xmlns:java=" <service name="calculator" provider="java:rpc"> <parameter name="classname" value="calculator"/> <parameter name="allowedmethods" value="*"/> </service> </deployment> Kod 15. Plik opisu uŝywany do zdeployowania usługi Calculator Wygenerowanie potrzebnych klas oraz interfejsów jest wykonywane poleceniem: java org.apache.axis.client.adminclient deploy.wsdd Kod 16. Wywołanie klasy dostarczanej z Axis-em, powoduje zdeployowanie usługi w kontenerze oraz wygenerowanie Stubów Przykładowy kod klienta wygląda następująco: CalculatorServiceLocator locator = new CalculatorServiceLocator(); locator.setendpointaddress("calculator", " localhost.axis.services.calculator.calculator calc = locator.getcalculator(); int res = calc.add(5, 9); System.out.println("Result: " + res); Kod 17. Klient korzystający z usługi przy uŝyciu wygenerowanych Stubów. Plik: Dokumentacja.doc Wersja: z dnia Stron: 38 Długość: 307 kb 38

39 7. Web Serwis wysyłający i odbierający maile Rysunek 15, Schemat działania web serwisowego mailera Serwis udostępnia metody pozwalające na zalogowanie się do serwera pocztowego, odebranie wszystkich wiadomości z danego konta (uŝywany protokół: POP3) oraz wysłanie wiadomości wykorzystując protokół SMTP. Wysyłanie i odbieranie wiadomości jest moŝliwe poprzez uŝycie obiektu typu ConnectionHandler, który takŝe jest pobierany z serwisu wywołanie metody getconnectionhandler() z podanymi parametrami: Plik: Dokumentacja.doc Wersja: z dnia Stron: 39 Długość: 307 kb 39

40 - adresem serwera pop3 - adresem serwera smtp - nazwą uŝytkownika - hasłem dostępu Do odbierania poczty udostępnione są następujące metody: getmessages(connectionhandler) : MessageData[] - zwraca opisy wiadomości dla danego konta Klasa MessageData przechowuje informacje o wiadomości (nagłówek): - nadawcę - listę odbiorców - listę odbiorców typu CC - temat wiadomości Na podstawie nagłówka wiadomości moŝna pobrać z serwisu jej treść, wywołujące metodę: getmessage(connectionhandler, MessageData) Wysyłanie wiadomości jest udostępnione poprzez metodę send, która przyjmuje w parametrach ConnectionHandler, dane jak w MessageData oraz treść wiadomości. Web Serwis został uruchomiony na komputerze stacjonarnym, w kontenerze aplikacji Tomcat Klient ipaq korzystający z Web Serwisu Klient jest interfejsem graficznym, korzystającym z udostępnionego Web Serwisu przy uŝyciu wcześniej wygenerowanych, statycznych Stub ów. Zostały one utworzone przez generator znajdujący się w środowisku WebShpere Studio Device Developer - Microplace Environment Toolkit z zainstalowanymi dodatkowo Extension Services. Klient pozwala na konfigurację parametrów konta uŝytkownika (nazwa uŝytkownika, adresy serwera POP3, adres serwera SMTP, nazwa konta uŝywanego do wysyłania poczty, hasło dostępu) oraz konfigurację adresu Web Serwisu ( Endpoint ). Plik: Dokumentacja.doc Wersja: z dnia Stron: 40 Długość: 307 kb 40

41 Rysunek 16, Okno konfiguracji Domyślnie skonfigurowane jest testowe konto uŝytkownika: Serwer POP3: poczta.o2.pl Serwer SMTP: poczta.o2.pl Nazwa: tester_ws_mail_client Hasło: tester Adres do wysyłania: Oraz domyślny serwer Web Serwisu: Uruchomienie klienta powoduje utworzenie obiektu Stub, ustawienie adresu Web Serwisu oraz pobranie obiektu ConnectionHandler dla aktualnej konfiguracji (Rysunek 21). KaŜda zmiana konfiguracji powoduje utworzenie nowego obiektu Stub oraz pobranie nowego Handler a. Obiekty Stub i ConnectionHandler są dostępne z obiektu Configuration, który jest singletonem i są z niego pobierane przy odbieraniu i tworzeniu nowych maili. Główne okno programu umoŝliwia pobranie listy maili z serwera ( Receive ) oraz utworzenie nowej wiadomości (przycisk Create mail ). Plik: Dokumentacja.doc Wersja: z dnia Stron: 41 Długość: 307 kb 41

42 Rysunek 17, Główne okno programu W tym drugim przypadku wyświetlane jest okno z odpowiednimi polami do uzupełnienia - Adresat, Adresaci CC, Temat, treść wiadomości (Rysunek 22). Pole nadawca jest wypełniane automatycznie na podstawie konfiguracji. Rysunek 18, Okno nowej wiadomości Odbieranie wiadomości powoduje wyświetlenie listy wiadomości znajdujących się na serwerze (Rysunek 23). Lista zawiera nadawcę i Temat kaŝdej wiadomości. Plik: Dokumentacja.doc Wersja: z dnia Stron: 42 Długość: 307 kb 42