Przystosowywanie aplikacji klienckiej do współpracy z usługą sieciową, której lokalizacja uległa zmianie

Modyfikacja wnętrza archiwum jar klienta usługi sieciowej może być szybkim sposobem na przystosowanie aplikacji do współpracy z usługą, której lokalizacja uległa zmianie. Klient stworzony w oparciu
o dokument WSDL usługi działającej w obrębie serwera aplikacji GlassFish, posłuży nam przy budowie swojego odpowiednika współpracującego z identyczną usługą, uruchomioną pod WebSphere Application Server 7.

1. Wcześniejsze wpisy bezpośrednio korespondujące z bieżącym

Tworzenie usługi sieciowej z wykorzystaniem JAX-WS i NetBeans IDE 6.8
Instalacja oraz uruchomienie usługi sieciowej pod WebSphere Application Server 7

2. Tworzenie aplikacji klienckiej

Rozpakowujemy archiwum MyWsClient.jar do folderu MyWsClient .

Pliki wewnątrz MyWsClient/myfirstws/ nie będą nam dłużej potrzebne - usuwamy wszystkie.

W celu wygenerowania nowej zawartości folderu myfirstws wykorzystamy narzędzie wsimport. Jeżeli dokument WSDL usługi jest aktualnie dostępny pod adresem http://localhost:9080/mywebapp/MyFirstWsService/MyFirstWsService.wsdl możemy przejść dalej,
w przeciwnym wypadku powinniśmy najpierw uruchomić usługę.

Domyślna lokalizacja wsimport.sh to /opt/IBM/WebSphere/AppServer/bin/ . Znajdując się wewnątrz MyWsClient wykonujemy polecenie /opt/IBM/WebSphere/AppServer/bin/wsimport.sh -verbose http://localhost:9080/mywebapp/MyFirstWsService/MyFirstWsService.wsdl .
Pliki wygenerowane w oparciu o dokument WSDL umożliwią nam komunikację pomiędzy klientem a dostawcą usługi.

Kolejnym krokiem jest modyfikacja zawartości folderu MyWsClient/meta-inf/. Plik jax-ws-catalog.xml
edytujemy do postaci:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">

    <system systemId="http://localhost:9080/mywebapp/MyFirstWsService/MyFirstWsService?WSDL" uri="wsdl/localhost_9080/mywebapp/MyFirstWsService/MyFirstWsService.wsdl"/>

    <system systemId="http://localhost:9080/mywebapp/MyFirstWsService/MyFirstWsService?xsd=1" uri="wsdl/localhost_9080/mywebapp/MyFirstWsService/MyFirstWsService.xsd_1.xsd"/>

</catalog>

Następnie nadpisujemy plik MyFirstWsService.wsdl aktualną wersją dokumentu znajdującą się pod adresem http://localhost:9080/mywebapp/MyFirstWsService/MyFirstWsService.wsdl

Dokument WSDL wraz z pozostawionym bez zmian plikiem MyFirstWsService.xsd_1.xsd powinien znaleźć się w folderze MyWsClient/meta-inf/wsdl/localhost_9080/mywebapp/MyFirstWsService/. Po przeniesieniu dokumentów należy usunąć podfoldery localhost_30074/MyWebApplication/ .

Wymagana jest również zmiana nazwy folderu meta-inf oraz pliku manifest.mf na odpowiednio META-INF oraz MANIFEST.MF .

Pozostało nam jedynie podmienić w archiwum jar foldery meta-inf oraz myfirstws na ich, przygotowane przez nas odpowiedniki.

Stworzoną aplikację uruchamiamy poleceniem
java -jar MyWsClient.jar 15 3 . Otrzymany wynik świadczy
o przeprowadzeniu poprawnych modyfikacji.

Instalacja oraz uruchomienie usługi sieciowej pod WebSphere Application Server 7

Uruchomienie usługi sieciowej pod WAS'em nie jest rzeczą skomplikowaną, przekonałem się o tym, wykorzystując do tego celu stworzoną wcześniej przykładową usługę (Tworzenie usługi sieciowej z wykorzystaniem JAX-WS i NetBeans IDE 6.8). Poniżej znajduje się krótki opis z serii "Zrób to sam" :)

1. Instalacja aplikacji

Logujemy się do konsoli administracyjnej. Z menu wybieramy Applications -> New Application . Interesuje nas tylko jeden typ aplikacji do zainstalowania: New Enterprise Application.

Podajemy ścieżkę do archiwum war zawierającego usługę (Local file system -> Browse) . Następnie wciskamy przycisk "Next".

Opcja instalacji "na skróty" (Fast Path) w zupełności nas zadowala. Przechodzimy dalej wciskając "Next".

Przed nami pięć kroków umożliwiających skonfigurowanie instalacji.


W kroku pierwszym możemy określić m.in. miejsce docelowe instalowanej aplikacji, jej nazwę, prawa dostępu do plików oraz wersję (Build ID). Jeżeli chcemy pozostawić wartości domyślne, możemy śmiało przejść dalej.

Krok drugi i trzeci również możemy pominąć, domyślne wartości pozwolą nam uruchomić usługę na naszym serwerze aplikacji.

W kroku czwartym określamy context root dla aplikacji. Podając /mywebapp sprawimy, że wszystkie wywołania dla http://localhost:9080/mywebapp oraz http://localhost:9080/mywebapp/* będą kierowane do instalowanej usługi (o ile nie zdefiniujemy później bardziej szczegółowego context root dla innej usługi np. /mywebapp/service).

Ostatni krok to podsumowanie dokonanej konfiguracji, wciskamy przycisk "Finish". Jeżeli wszystko zrobiliśmy poprawnie, powinien pojawić się ekran potwierdzający pomyślną instalację. Nie zapominamy zapisać dokonanych zmian, "Save".



2. Uruchomienie usługi

W konsoli administracyjnej przechodzimy do Applications -> Application types -> WebSphere enterprise applications . Zaznaczamy naszą aplikację oraz wciskamy przycisk "Start".


Otrzymany komunikat świadczy o poprawnym uruchomieniu aplikacji.


Dokument WSDL usługi możemy znaleźć pod adresem http://localhost:9080/mywebapp/MyFirstWsService/MyFirstWsService.wsdl . Plik ten wykorzystamy podczas tworzenia aplikacji klienckiej, bazującej na tej stworzonej wcześniej przy pomocy środowiska NetBeans 6.8 . Archiwum jar klienta będziemy modyfikować własnoręcznie (bez wykorzystania IDE), ale o tym już następnym razem.

Tworzenie usługi sieciowej z wykorzystaniem JAX-WS i NetBeans IDE 6.8

Jak już wcześniej napisałem, czytanie wszelkiej maści dokumentacji dotyczących technologii Web Services umilało mi wolny czas przez ostatni tydzień. Biorąc pod uwagę, że nie samą teorią człowiek żyje, postanowiłem przejść do praktyki. Stworzenie przy pomocy JAX-WS przykładowej usługi sieciowej oraz jej klienta okazało się być bardzo proste. Wykorzystując środowisko programistyczne NetBeans 6.8 możemy napisać nasz własny Web Service w szybki i przejrzysty sposób.

1. Tworzenie przykładowej usługi

Pierwszym krokiem jest stworzenie nowego projektu: File -> New Project . Wybieramy kategorię Java Web oraz typ projektu Web Application. Przechodzimy dalej wciskając "Next". Jako Project Name podajemy MyWebApplication oraz klikamy myszką "Next", "Next" i "Finish".

Do stworzonego projektu dodajemy nowy plik: File -> New File . Wybieramy kategorię Web Services oraz typ pliku Web Service. Zatwierdzamy poprzez "Next". Jako Web Service Name podajemy MyFirstWs, w pole Package wpisujemy myfirstws. "Finish".

Edytujemy kod powstałego pliku MyFirstWs.java :

package myfirstws;

import javax.jws.WebService;

@WebService()
public class MyFirstWs {
    public int func(int a, int b) {
        return a * b;
    }
}

Stworzoną usługę uruchamiamy poprzez Run -> Run Main Project . Jeżeli zrobiliśmy wszystko jak należy powinniśmy otrzymać komunikat:
"(...)
Personal GlassFish v3 Domain is running.
In-place deployment at D:\MyWebApplication\build\web
Initializing...
run-deploy:
Browsing: http://localhost:30074/MyWebApplication/
run-display-browser:
run:
BUILD SUCCESSFUL (total time: 34 seconds)"

2. Tworzenie aplikacji klienckiej

Ponownie rozpoczynamy od stworzenia nowego projektu, tym razem jednak wybieramy kategorię Java oraz typ projektu Java Application. Jako Project Name podajemy MyWsClient oraz odznaczamy pole Create Main Class.

Do stworzonego projektu dodajemy nowy plik wybierając kategorię Web Services oraz typ Web Service Client. Następnie wskazujemy ścieżkę do pliku WSDL uruchomionej usługi (WSDL URL): http://localhost:30074/MyWebApplication/MyFirstWsService?WSDL oraz wpisujemy w pole Package: myfirstws (tak jak poprzednio).

Jeżeli ukazał się nam komunikat "(...) BUILD SUCCESSFUL (total time: 2 seconds)" możemy przejść dalej. Wygenerowane pliki umożliwią nam połączenie się z usługą poprzez aplikację kliencką.

Do projektu dodajemy nową klasę (kategoria Java, typ Java Class) nadając jej nazwę MyFirstWsClient oraz wpisując w pole Package: mywsclient . Edytujemy kod powstałego pliku MyFirstWsClient.java :

package mywsclient;

import myfirstws.MyFirstWs;
import myfirstws.MyFirstWsService;

public class MyFirstWsClient {
    public static void main(String[] args) {
        try {
            MyFirstWsService service = new MyFirstWsService();
            MyFirstWs myws = service.getMyFirstWsPort();
            if(args.length >= 2) {
                int a = Integer.parseInt(args[0]);
                int b = Integer.parseInt(args[1]);
                System.out.println(a + " * " + b + " = " + myws.func(a, b));
            }
            else {
                System.out.println("java -jar MyWsClient.jar integer1 integer2");
            }
        }
        catch(Exception e) {
            e.printStackTrace();
        }
    }
}

Archiwum jar z aplikacją tworzymy poprzez Run -> Clean and Build Main Project (jeżeli jest głównym projektem) lub Clean and Build wybrane na projekcie. Jeżeli zobaczyliśmy komunikat "(...) BUILD SUCCESSFUL (...)", w podfolderze dist projektu znajdziemy plik jar z gotową do uruchomienia aplikacją kliencką.

Kolejny wpis będzie dotyczył uruchamiania usługi sieciowej pod IBM WebSphere Application Server 7.

Integracja systemu Kerberos z WebSphere Application Server 7

Poznawanie technologii Web Services zapewniało mi niemałą rozrywkę przez ostatnich kilka dni, a to dopiero początek mojej przygody z SOAP, WSDL i JAX-WS. Temat pochłonął mnie tak bardzo, że zupełnie zapomniałem opisać w jaki sposób dokonałem integracji poprawnie skonfigurowanego systemu Kerberos z WAS'em. Jak wspomniałem konfigurację Kerberos'a mam już za sobą, stąd wykonanie poniższych czynności było jedynie formalnością, dopełnieniem wykonanej wcześniej pracy.

Po zalogowaniu się do konsoli administracyjnej WAS'a przechodzimy do Security -> Global Security -> Kerberos configuration.


Biorąc pod uwagę, że w bazie danych systemu Kerberos istnieje principal WAS/linux-fi5z.site@SITE, który został dodatkowo wyeksportowany do pliku kt.keytab, nasz realm nosi nazwę SITE
a plik konfiguracyjny Kerberos'a znajduje się w /etc pod nazwą krb5.conf, konfiguracja w konsoli administracyjnej powinna wyglądać następująco:


Klikamy myszką "OK" oraz zapisujemy wprowadzone dane "Save".
Od tej chwili domyślnym mechanizmem autoryzacji dla WAS'a jest Kerberos. Należy o tym pamiętać przy kolejnej próbie zalogowania się do konsoli administracyjnej. Komunikat "Login failed. Check the user ID and password and try again." z pewnością pojawi się jeżeli zapomnieliśmy dodać do kerberosowej bazy danych odpowiedniego wpisu.

Dla konta administratora o nazwie admin wymagany principal wprowadzamy następująco:


Podane hasło należy zapamiętać, będziemy używać go podczas logowania się do konsoli administracyjnej.

Troubleshooting - ciąg dalszy

Błędne było przyjęte założenie, że źródłem problemów podczas prób wykorzystania systemu Kerberos jako mechanizmu autoryzacji jest WAS. Pomysły jak rozwiązać zagadkę kończyły się wraz z upływem czasu - może dlatego coś mnie podkusiło aby jeszcze raz zainteresować się plikami Kerberos'a.

Po chwili zastanowienia wpadłem na pomysł aby jeszcze raz wyeksportować principal "WAS/linux-fi5z.site@SITE" do pliku keytab, który miał posłużyć WAS'owi. Użyłem w tym celu kadmin.local wydając za jego pomocą polecenie
ktadd -k /usr/local/var/krb5kdc/kt.keytab WAS/linux-fi5z.site@SITE.
Chcąc sprawdzić czy faktycznie plik kt.keytab zawiera pożądane pola posłużyłem się narzędziem klist.


Jak można zauważyć powyżej, wszystko się zgadza. Użyłem więc tego pliku przy konfiguracji - tym razem obyło się bez problemu.

Jak się okazało kością niezgody był tutaj plik keytab, do którego ścieżkę podawałem w konsoli administracyjnej WAS'a. Niedopatrzenie kosztowało mnie sporo czasu, lekcja nie poszła jednak na marne - teraz z pewnością będę zwracać większą uwagę na zawartość plików, których używam korzystając z zewnętrznych aplikacji.

WAS7 Troubleshooting: Tracing CreateKrbAuthMechanism

Od kilku dni próbuję wykorzystać system Kerberos jako mechanizm autoryzacji w IBM WebSphere Application Server 7 . Wszelkie próby skonfigurowania WAS'a tak aby współpracował z Kerberosem kończą się niepowodzeniem. Za każdym razem pojawia się komunikat:

"org.ietf.jgss.GSSException, major code: 13, minor code: 0 major string: Invalid credentials minor string: Cannot get credential from JAAS Subject for principal: WAS/linux-fi5z.site@SITE".

Zakładam, że konfiguracja systemu Kerberos jest poprawna i "wina" leży w tym przypadku po stronie WAS'a. Podążając dalej tym tropem postanowiłem sprawdzić dokładniej jak przebiega proces tworzenia konfiguracji. Opis jak to zrobić zamieściłem poniżej.

1. Logujemy się do konsoli administracyjnej, w menu wybieramy Troubleshooting -> Logs and trace. Następnie wybieramy server1.


2. Wybieramy Diagnostic Trace.


3. W tym miejscu możemy dokładnie określić plik wyjściowy dla danych. Przechodzimy do Change Log Detail Levels.


4. Następnie mamy możliwość sprecyzowania, które komponenty lub grupy komponentów nas interesują. CreateKrbAuthMechanism odnajdziemy w Groups. Klikamy myszką na znak "+" przy nazwie listy "All Groups" w celu jej rozwinięcia.


5. Klikamy myszką na odnaleziony na liście CreateKrbAuthMechanism. Z menu wybieramy Message and Trace Levels -> finest.


6. Klikamy myszką na przycisk "OK". Następnie potwierdzamy operację zapisu - "Save".


7. Domyślna lokalizacja pliku trace.log to /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/. Tam odnajdziemy uzyskane informacje.

Instalacja Robocode

Zaplanowane w ramach poniedziałkowych zajęć z PWiR zmagania czołgów zbliżają się wielkimi krokami. Czasu pozostało niewiele dlatego zabieram się do pracy już teraz. Poza "buszowaniem" na stronach RoboWiki i poznawaniem opracowanych strategi walki udało mi się zainstalować najnowszą wersję Robocode oraz przeprowadzić kilka walk pomiędzy przykładowymi robotami.

Chcąc rozpocząć przygodę z Robocode warto upewnić się, że system posiada zainstalowany Java Development Kit.

Wymagane jest również dodanie do zmiennej środowiskowej Path pełnej ścieżki do java.exe. W moim przypadku pod win7 polecenie realizujące daną czynność wyglądało następująco:
set Path=%Path%;C:\Program Files (x86)\Java\jdk1.6.0_16\bin\ . Należy jednak pamiętać, że użycie narzędzia set nie spowoduje trwałego dodania ścieżki do zmiennej Path.
W celu zaktualizowania zmiennej na stałe możemy posłużyć się narzędziem setx, wydając polecenie:
setx Path "%Path%;C:\Program Files (x86)\Java\jdk1.6.0_16\bin\" .

Pobrane archiwum jar robocode-1.7.2.0-Beta-2-setup.jar instalujemy w systemie poprzez wydanie polecenia java -jar robocode-1.7.2.0-Beta-2-setup.jar . Na pulpicie powinien znaleźć się skrót do aplikacji Robocode.

Ciekawostką jest fakt, iż wykonanie powyższych czynności zmieniło
u mnie domyślny rozmiar okna i czcionki dla konsoli, o czym przekonałem się uruchamiając cmd przy okazji ponownego zalogowania do systemu.

IBM Update Installer for WebSphere Software

Ponieważ podstawowa instalacja IBM WebSphere Application Server 7 nie wspiera systemu Kerberos jako mechanizmu autoryzacji ("This function is currently disabled") postanowiłem uaktualnić oprogramowanie do nowszej wersji. Wykorzystałem do tego celu narzędzie IBM Update Installer for WebSphere Software. Poniżej znajduje się opis czynności wykonanych przy realizacji tego zadania.

1. Pliki do pobrania

IBM Update Installer V7.0.0.9 for WebSphere Software for Linux: link
WebSphere Application Server V7.0 Fix Pack 7 for Linux: link
Java SDK 1.6 SR6 Cumulative Fix for WebSphere Application Server: link

2. Instalacja

Znajdując się wewnątrz rozpakowanego archwium narzędzia IBM Update Installer ( w moim przypadku wewnątrz 7.0.0.9-WS-UPDI-LinuxIA32/UpdateInstaller/ ) wydajemy polecenie install.
Po przeprowadzonej pomyślnie instalacji, automatycznie uruchomione zostanie narzędzie umożliwiające wskazanie ścieżki do plików WAS Fix Pack 7 oraz Java SDK 1.6 SR6 Cumulative Fix . Jak widać poniżej oba pliki umieściłem w /root.

Jeżeli wskazana ścieżka do plików jest poprawna program automatycznie odszuka gotowe do instalacji uaktualnienia.

Ostatnim krokiem jest uruchomienie procesu aktualizacji, którego poprawne ukończenie zaowocuje w pełni działającym WAS'em w wersji 7.0.0.7 .