Przygotowywanie (się do) projektu z JAX-WS i Apache Maven - modularyzacja wychodzi sama

Po tych moich certyfikacyjnych wojażach i bojach z recenzjami (jeszcze jedna czeka w kolejce do napisania) wracam (na blogu) do tematu mojego obecnego projektu, którego pierwsze rezultaty można było "podziwiać" w Każdemu będzie w końcu dane - wreszcie Java EE 5 w projektach!.

Komentarzy posypało się co nie miara, za co wszystkim dziękuję, bo chciałbym móc powiedzieć, że to nie moje, albo że miałem jedynie 5-10 minut na poprawki przed publikacją, aby wybronić się z kilku, ale nic z tego. Wszystko, co opublikowałem było moje na bazie tego, co nie było moje :] Migracja miała na celu wypuszczenie działającego rozwiązania możliwie niewielkim nakładem pracy. Udało się. Jakkolwiek nie oznacza to zakończenia prac nad tym "dziwolągiem", ale przyświecał mi jeden cel - dzisiaj testuję prototyp, aby zweryfikować mój punkt widzenia, aby jutro i w kolejnych dniach wyciosać coś rzeczywiście przyzwoitego. Od niewielkiego tworu, ale działającego, do większego, bardziej naładowanego wzorcami i dobrymi praktykami, i wciąż działającego. Takie iteracyjne programowanie. Prace trwają.

Dzisiaj postanowiłem wprowadzić zmiany w obszarze zarządzania projektem, w którym można wyróżnić część serwerową (uruchomioną w centrali) oraz część kliencką. Ich zależność polega na interfejsie, z którego korzystają. W tym przypadku nie tylko interfejs programistyczny (w sensie programowania w Javie), ale również technologiczny (w sensie wykorzystania technologii/szkieletu aplikacyjnego w Javie) łączy oba moduły. Skorzystałem z technologii Web Services (JAX-WS), więc moduł centralny wystawia usługę sieciową, którą konsumuje moduł kliencki. Logiczne, co?

I tutaj natrafiłem na problem zdefiniowania zależności między modułami. Gdyby założyć, że część serwerowa jest aplikacją webową, to w jaki sposób określić zależność w module klienckim? Nie ma jak, bo war to podział technologiczny, a nie programistyczny i nie tędy droga. Potrzebuję zdefiniować SEI (ang. Service Endpoint Interfejs), abym na nim oparł technologiczny moduł serwerowy i programistyczny, kliencki. Moduł serwerowy to war, który zanurzy moduł SEI, z którego będzie mógł skorzystać moduł kliencki.

Teraz jest dla mnie jasny komentarz Artura Karazniewicza (aczkolwiek jego pierwszy "wyjazd" był do kosza, co się ostatecznie stało :)):

"Po drugie uniezależnienie samego WebService od implementacji endpointu w java (zastosowanie SEI oraz nazwanie poszczególnych elementów WSDL w adnotacjach WebService, WebMethod itd.)."

Początkowo pomyślałem "Kto by się tym przejmował?!", ale teraz samo rozczłonkowanie projektu na moduły wymusiło na mnie poćwiartowanie modułu serwerowego z wydzieleniem modułu z SEI. Inaczej po prostu nie dałoby rady. Do mnie przemawiają przykłady, co daje mi dane podejście i w tym przypadku samo stwierdzenie "Bo tak się robi. Bo to dobra praktyka." to zdecydowanie za mało. Potrzebuję konkretów, a nie kiwania głowami, że tak się robi, a kiedy zapytać "Dlaczego?", nikt nie jest skłonny wytłumaczyć.

Bardzo ucieszyłem się, kiedy pojawiły się komentarze wskazujące konkretne błędy z chociażby skromną, ale zawsze, próbą wytłumaczenia "Dlaczego nie". Niestety pojawiły się też takie ogólnikowe, zrób to, zrób tamto, bez jakiegokolwiek wyjaśnienia "Dlaczego". A szkoda, bo jestem w stanie wyobrazić sobie niedoświadczonych programistów, którzy postawieni w tej roli, w jakiej ja byłem przed chwilą - wystawienia ich kodu na publiczną krytykę - dostają multum dobrych rad, które są dobre jedynie z ich nazwy. Co mi po dobrej radzie, jeśli nie dostaję racjonalnego ich wytłumaczenia? Są dla mnie równie wartościowe, jak wskazanie palcem, co mam zrobić...milcząco.

Zestawiam projekt z pomocą Apache Maven, bo nie tylko wymusiło to na mnie poćwiartowanie (aka zmodularyzowanie) aplikacji, ale również uniezależni mnie od zależności środowiska programistycznego (IDE). Do tej pory w zespole królował Eclipse/RAD. Teraz, z wprowadzeniem mnie do zespołu, wszedł NetBeans IDE (bo jakoś łatwiej mi było stworzyć i przetestować Web Service), a ostateczny cel to uruchomienie narzędzia budowania aplikacji bez udziału ludków z zespołu. Bez wykorzystania Apache Maven, czy jemu podobnego rozwiązania, nie byłoby to możliwe.

Zastanawiam się, jak testować działanie usługi sieciowej? Czy w ogóle warto, skoro mogę przetestować implementację bez narzutu infrastruktury JAX-WS? To w końcu "oznakowane" POJO? A co z klientem? On jest zależny od wygenerowanego przez wsgen. Jak sobie z tym tematem poradzić? Może po prostu zaniechać testowania komunikacji usługa-klienta, bo to ma działać (jest poza moją kontrolą i jestem tego klientem), a przetestować metody, które otrzymają wynik wywołania przesłoniętego zaślepką (ang. mock object)? Rady mile widziane (zlitujcie się jednak nade mną i dodajcie słów kilka dlaczego, albo chociaż odnośniki do dokumentacji).

Sun Certified Developer for Java Web Services 5 (SCDJWS) zdany!

Okazuje się, że w przeciwieństwie do mojego wczorajszego pesymizmu o mojej znajomości tematu usług sieciowych (patrz: Zabieram się za JAX-WS), dzisiaj, ku mojemu zdumieniu, otrzymałem następującą wiadomość:

Dear Jacek (Certification ID#: SUN295099)

Congratulations on completing all the requirements for the
Sun Certified Developer for Java Web Services 5 certification. You were certified on 12/10/2008.

Congratulations!

Certification Department

W ten sposób stałem się posiadaczem certyfikatu Sun Certified Developer for Java Web Services 5 (SCDJWS5). Do pełni szczęścia brakuje mi jeszcze informacji o wynikach z poszczególnych obszarów tematycznych, bo pakiet certyfikacyjny jeszcze w drodze.

Jeśli ktoś zapyta, jak się przygotowywałem, z jakich książek korzystałem, to niestety nie będę miał satysfakcjonującej odpowiedzi - po prostu podszedłem do egzaminu "z biegu" i okazuje się, że najwięcej wiedzy dało mi wcześniejsze rozpoznawanie tematu EJB3 z jego @WebService i próby uruchomienia usług sieciowych na bazie EJB3 z Apache Geronimo. Zapomniałem nawet, że udało mi się opublikować kilka artykułów na ten temat - Tworzenie usługi sieciowej z JAX-WS, Tworzenie usługi sieciowej z JAX-WS, Apache Geronimo 2 i NetBeans 6 czy SCAlanie z JAX-WS.

Chciałbym podziękować Grzegorzowi Dudzie za jego wpis SCDJWS za darmo, który był początkiem całej historii (patrz: Sun Certified Developer for Java Web Services (SCDJWS) bezpłatnie do 10 grudnia!). Wielkie dzięki Grześ!

Czy ktoś jeszcze podchodził do tego certyfikatu? Jak poszło?

Wracam do lektury Service Oriented Architecture with Java autorstwa Vincenzo Caselli, Binildas A. Christudas, Malhar Barai (Packt, June 2008). Już się naczekała na swoje "5 minut" na półce Biblioteczki Warszawskiego JUGa. Pierwszy rozdział to porażka - masło maślane, literówki, nuda, ale rozdział 2. czyta się przyjemnie(j). I jest ciekawy przykład z uruchomieniem usługi sieciowej JAX-WS z Endpoint.publish(String address, Object implementor). Takie ciekawostki sprawiają, że czytanie książek, nawet tych początkowo nudnych, może mile zaskoczyć.

Zabieram się za JAX-WS

Nowe książki o Groovy i Grails jeszcze nie dotarły, więc pomyślałem, aby zabrać się za rozpoznanie tematu Java API for XML-Based Web Services (JAX-WS) 2.0. Do tej pory tematyka usług sieciowych (ang. web services) była przeze mnie traktowana po macoszemu, a na mojej liście do rozpoznania leżała od miesięcy i nie ma co więcej czekać. Uzbrojony w wiedzę o Groovy (po lekturze książki Book review: Beginning Groovy and Grails: From Novice to Professional) wydaje mi się, że teraz każdy temat pójdzie gładko, więc dlaczego nie zająć się JAX-WS i przyjrzeć mu się bliżej, może nawet z Groovy w tle?

Zacząłem od pobrania materiałów - specyfikacji JAX-WS 2.0 oraz referencyjnej implementacji JAX-WS RI ze strony domowej specyfikacji, dokumentacji Java Web Services Tutorial 2.0 oraz ostatniego wydania rozwojowego NetBeans IDE 7.0 (ten niestety mnie zaskoczył brakiem pliku uruchomieniowego dla Windows w dzisiejszej wersji rozwojowej, więc będę musiał poczekać na kolejną!). Jest jeszcze do nauki (Free) Web Services and SOA Programming (with Passion!) Hands-on Online Course.

Instalacja JAX-WS RI to uruchomienie instalatora i można próbować się z tematem.

 jlaskowski@work /cygdrive/c/apps
 $ java -jar JAXWS2.1.1_20070501.jar
 jaxws-ri
 ...
 installation complete

Poza tym gotowe środowisko jest dystrybuowane w Java SE 6, więc nawet ten krok nie jest konieczny.

Nie potrafię wytłumaczyć dlaczego, ale zawsze wspominając o JAX-WS na myśl przychodził mi projekt Apache CXF. Zacząłem przeszukiwać jego dokumentację i o dziwo trafiłem na powiązanie CXF z...OSGi - Distributed OSGi. Jeśli jeszcze dostanę się do informacji, że można połączyć Groovy z CXF (dlaczego by nie, skoro Groovy to Java?), a w tle będzie OSGi, może i Grails, byłbym w ogóle szczęśliwy. Na razie wezmę się za lekturę specyfikacji JAX-WS i podłubię po trochu w NetBeans. Później wrócę do CXF, a w międzyczasie przyjdą kolejne książki o Groovy i Grails, i wrócę do nich. Wszystko ustawione. Skoro wszystko mam, wracam do czytania i (potencjalnie) relacji na blogu. Kto by pomyślał, że tak mi przypadnie to czytanie do gustu?!

Tworzenie usługi sieciowej z JAX-WS, Apache Geronimo 2 i NetBeans 6

Aby otrząsnąć się z wrażeń związanych z minionymi warsztatami javowymi WarsJava, które odbyły się w zeszłą sobotę, 17.11, na Wydziale MIMUW w Warszawie postanowiłem opisać sposób tworzenia usługi sieciowej JAX-WS z wykorzystaniem wersji rozwojowej Apache Geronimo 2.1 oraz NetBeans IDE 6. Tytuł artykułu Tworzenie usługi sieciowej z JAX-WS, Apache Geronimo 2 i NetBeans 6 mówi sam za siebie. Ciekawostką Geronimo jest możliwość uruchomienia usługi w ramach aplikacji internetowej bez deskryptora web.xml. Poza wykorzystaniem adnotacji @WebService oraz @WebMethod użyłem dwóch kolejnych @PostCreate oraz @PreDestroy znanych z EJB3. Na zakończenie prezentuję tworzenie klienta usługi jako samodzielną aplikację.
Artykuł można traktować jako moje rozpoczęcie lektury specyfikacji JAX-WS, do której przymierzałem się od dobrych kilku miesięcy.

SCAlanie z JAX-WS

Podczas ostatniej konferencji Integracja Systemów Informatycznych (ISI) organizowanej przez Software-Konferencje miałem okazję prezentować technologię Service Component Architecture (SCA). W poprzednich artykułach - SCAlenie (kompozyt) z Apache Tuscany i Apache Maven oraz SCA z językami skryptowymi w wykonaniu Apache Tuscany, Jetty i Maven 2 - korzystałem z języka silnie-typowanego Java i języka skryptowego Groovy do integrowania usług w postaci SCAleń. Tematem mojej prezentacji na ISI było przedstawienie SCA do tworzenia SCAleń w oparciu o usługę zdalną zbudowaną za pomocą JAX-WS. Prezentacja przyczyniła się do napisania kolejnego artykułu o SCA z JAX-WS - SCAlanie z JAX-WS.

Poprzednie artykuły o SCA dotyczyły łączenia usług, które działały w ramach pojedyńczej wirtualnej maszyny Java (JVM). Rozproszenie usług było pozorne i często spotykałem się z uwagami, że nie prezentują niczego nowatorskiego, czego nie możnaby osiągnąć korzystając z tradycyjnych metod integracji. Artykuły skupiały się raczej na prostocie tworzenia usług korzystając z SCA oraz języków skryptowych niż na prostocie integracji usług rozproszonych.

W kolejnym artykule o SCA wychodzę poza ramy pojedyńczej wirtualnej maszyny i prezentuję integrację usług rozproszonych. Zestawiłem środowisko z dwoma serwerami aplikacyjnymi Jetty oraz GlassFish, w którym uruchamiam SCAlenie na jednym serwerze, składające się z usługi będącej usługą sieciową (ang. web service) uruchomioną na drugim. Istotą artykułu będzie zaprezentowanie deklaratywnego konstruowania SCAlenia poprzez definiowanie elementów składowych w deskryptorze XML w celu udostępnienia kolejnej, bardziej specjalizowanej funkcjonalności.

Na uwagę zasługuje prostota integracji zdalnej usługi podczas konstruowania SCAlenia. Jakby tego było mało - wciąż nie wyczerpałem możliwości oferowanych przez specyfikację SCA, a realizowanej przez Apache Tuscany. Szykuję się do skorzystania z EJB3, Spring Framework i JMS, a mówi się, że SCA to inne JBI, więc niedługo i tam trzeba będzie zajrzeć. Zastanawiam się, kiedy przyjdzie pora na Service Data Objects (SDO) - partnera technologicznego SCA.

Tworzenie usługi sieciowej z JAX-WS

W zasadzie tyle rzeczy przyczyniło się do utworzenia kolejnego artykułu nt. JAX-WS - Tworzenie usługi sieciowej z JAX-WS, że nie wiem od czego zacząć. Może niech będzie od najważniejszej - zaproszenie na prezentację podczas konferencji Integracja systemów informatycznych GigaCon 19 czerwca 2007.

Było to jeszcze w maju, kiedy pani Maria Bombała z Software-Konferencje napisała do mnie z propozycją wystąpienia na konferencji, a kiedy ja po raz pierwszy zabrałem się za specyfikację Service Component Architecture (SCA) i projekt Apache Tuscany. W wyniku ewaluacji udało mi się napisać 2 artykuły o SCA - SCAlenie (kompozyt) z Apache Tuscany i Apache Maven oraz SCA z językami skryptowymi w wykonaniu Apache Tuscany, Jetty i Maven 2 i jako niespodzianka wystąpiłem na zajęciach Jacka Sroki na MIMUW, więc miałem wszystko na prezentację o SCA (slajdy, aplikację, wystarczającą ilość wiedzy). Bez wahania przyjąłem zaproszenie. Trochę mnie zmroziło, kiedy zobaczyłem do kogo adresowana jest konferencja - szefów działów IT, kierowników projektów wdrożeniowych, analityków i inżynierów systemowych, projektantów systemów i programistów, ale nie ma to jak próbować się z technologią i przedstawiać ją osobom, które mogą odpowiadać za jej wdrożenie w projektach, więc jeśli ma być więcej SCA w projektach, to właśnie ich należy przekonać do jej stosowania. Zaproszenie zostało przyjęte i przygotowania trwają. Temat prezentacji - SCAlanie w SOA, czyli integracja według Service Component Architecure (SCA). Wszystkich serdecznie zapraszam do udziału i przygotowania zestawu pytań, które wystawią moją wiedzę na próbę. W zanadrzu mam odpowiedzi w stylu Nie wiem, Chyba tak, itp., więc się nie lękam ;-)

Od kilku tygodni zabierałem się za ewaluację Apache CXF i właśnie wczoraj, a może i przedwczoraj, natrafiłem na odnośnik do dokumentacji CXF - Developing a Service using JAX-WS, a tam na uwagę For new development the preferred path is to design your services in WSDL and then generate the code to implement them, czyli nowicjusze zaczynają od WSDL, a to dokładnie o mnie. Hmm, pomyślałem, potrzebuję edytora do WSDL i najlepiej, aby był dostępny w Eclipse IDE (o NetBeans IDE nie myślałem wtedy). Nic nie znalazłem dostępnego jako projekt otwarty, jednakże w trakcie szukania natrafiłem na informacje o specyfikacji The Java API for XML-Based Web Services (JAX-WS). Jako, że specyfikacja była również na mojej liście do poznania i wiedziałem, że sprowadza się do kilku adnotacji, więc pomyślałem, że WSDL mogę stworzyć innym sposobem - utworzę usługę za pomocą JAX-WS. Trochę na około, ale wiedziałem, że zabierze mi to chwilę, więc wcale się nie zmartwiłem, a wręcz przeciwnie. Przypomniałem sobie o konferencji i o potrzebie integracji różnych usług w SCAleniu, które mam tymczasowo oparte o referencje w Javie i skrypt Groovy, więc z zapałem zabrałem się za utworzenie przykładu. Prostota tworzenia usługi z JAX-WS tak mi się spodobała, że napisałem artykuł Tworzenie usługi sieciowej z JAX-WS. Mam teraz i WSDL i usługę do uatrakcyjnienia SCAlenia. Najpierw skończę lekturę wprowadzenia do Apache CXF, a później skończę przykład na prezentację SCA na konferencję Integracja systemów informatycznych GigaCon.