Category Archives: WebService

Działający przykład JEE w akcji

Jakoś tak się złożyło, że poza servletami i JPA niespecjalnie miałem w życiu pobawić się w EJB i insze wynalazki. Fakt, że pojawił się kiedyś dawno Spring skutecznie zniechęcał do posiłkowania się JEE w codziennym developmencie. Jednakże sytuacja zmieniła się wraz z wydaniem wersji 6 Javy EE.

Szukając w sieci materiałów dla przygotowań do certyfikatu Java Persistence API Developer Certified Expert (tak tak, pierwsze wpisy z przygotowań już niedługo) znalazłem dość ciekawy tutorial, który umożliwia postawienie w pełni funkcjonalnej aplikacji, na której możnaby przećwiczyć mniej i bardziej zaawansowane tematy związane z tą certyfikacją.

JBoss to nazwa budząca respekt. Jako firma oferuje szeroki wachlarz produktów – począwszy od serwera aplikacyjnego skończywszy na IDE. Oferuje również strasznie fajny tutorial znajdujący się  dokładnie pod tym adresem. Obejmuje on instalację dedykowanego IDE oraz przedstawia JEE w akcji – mamy i usługi sieciowe, mamy JSF, mamy też podpięte Hibernate jako ORM. Nic tylko brać i działać. Jeśli ktoś potrzebuje zobaczyć jak może wyglądać sensowna appka bez miliona zależności w POMie to powyższy adres jest świetnym punktem wyjścia.

AXIS i dziwne zachowanie webserwisów

Obecnie jestem w trakcie tworzenia aplikacji, która musi integrować usługi dostarczane przez dwóch różnych dostawców. Niestety – wystawiane WSDLki zmuszają mnie do używania dość antycznej wersji biblioteki AXIS (nie by nowsze wersje były jakoś lepsze). Dziwnym trafem przy strzałach do dostawców za pomocą SoapUI wszystko działało pięknie. Przy wygenerowanym kliencie kodowym – już niekoniecznie.

Co się okazało? AXIS (nie wiem, możliwe, że klienci generowani przez CXF lub  Metro i w specyfikacji zgodnej z JAX-WS robią inaczej) tworzył request w taki sposób, że do adresata wysyłany był request, który zawierał wszystkie elementy XMLa zadeklarowane w WSDLu. Co prawda nie zawierały one wartości, ale i tak właśnie ten fakt był przyczyną dziwnego zachowania usługi. Wystarczyło poprawić ręcznie dostarczonego WSDLa, usuwając z niego niepotrzebne mi elementy (wiem, że delikatnie mówiąc to średnie rozwiązanie). Niestety nie jestem w stanie stwierdzić czy to wina samego dostawcy webserwisu, czy dziwnego zachowania AXISa. Nie wiem i nie chcę wiedzieć.

Asynchroniczne WebServisy czyli jak przyspieszyć SOAP

Ostatnio w zakładzie dostałem do rozpoznania wolne działanie webserwisu. Problem leżał w tym, iż aplikacje klienckie były w stanie szybciej strzelać pod webserwis niż ten nadążał z procesowaniem. I zasadniczo możnaby rozpocząć szukanie winnego w kodzie gdyby nie prosty fakt, że klasy odpowiadające za webserwis walidowały tylko żądanie po czym pchały obiekt do JMS. Co tutaj można przyspieszyć?

Odpaliłem SoapUIPro i z konkretną dawką testów obciążeniowych udałem się na poszukiwanie winnego. Co się okazało – webserwis był oparty o SOAPa. To jeszcze może nie jest samo w sobie tragiczne – tragicznym natomiast okazało się to, iż pod spodem nasz request potrafił zawierać naprawdę sporą ilość XMLa. Standardowe dane dla każdego requestu to dobre 5 elementów XMLa,  zaś szóstym była lista łańcuchów tekstowych. W 90% ta lista zawierała raptem jeden element – problemem było pozostałe 10%. Wówczas lista rozrastała się do dość solidnych rozmiarów i proces przesyłania tych danych, ich marshallingu, procesowania i takich tam troszkę trwał.  Trzeba było coś z tym fantem zrobić. Przepisanie na RESTa pozostawało w dalszych planach, zaś na szybko udało mi się zorganizować jedną rzecz – wbudowaną w JAX-WS adnotację @Oneway.

 The @Oneway annotation denotes a method as a Web service one-way operation that only has an input message and no output message. Apply this annotation to methods on a client or server Service Endpoint Interface (SEI) or a server endpoint implementation class for a JavaBeans endpoint.

Dodam jeszcze tylko, że adnotowane w ten sposób metody muszą spełniać następujące kryteria:

  • muszą zwracać void
  • nie mogą rzucać wyjątków

Może to być dość ograniczające, np. kiedy rzucony wyjątek w jakiś sposób służy nam do kontroli przepływu po stronie klienta. Jednakże jeśli przy strzelaniu do usługi sieciowej stosujemy metodę fire&forget wówczas jesteśmy w domu. Brak oczekiwania na odpowiedź ze strony serwera – w przypadku przeze mnie opisywanym wstępny przyrost wydajności to około 400%. Myślę zatem, że gra jest warta świeczki.