Osobiście rekomendowałbym wykorzystanie mechanizmu Handlerów oferowanego przez JAX-WS. Handlery to klasy, które możemy stworzyć i zarejestrować w aplikacji, zawierające dodatkową logikę wykonywaną dla każdego komunikatu. W przypadku zapytań - zanim zapytanie trafi do właściwej metody biznesowej. Handler ma dostęp do treści wiadomości i ma prawo ją odrzucić. Walidację względem XML Schema można wykonać za pomocą klasy Validator. Trzeba posiadać definicję XML Schema, ale ona i tak jest częścią WSDL. Jeśli trzeba, można także zaimplementować własny mechanizm walidacji danych XML, np. w oparciu o XPath.
JX-WS bottom-up, czyli tworzenie usługi sieciowej (i WSDL) na podstawie klas Javy, jest z pewnością wygodniejsze dla programistów Javy oraz w sytuacjach, gdy aplikacja (w szczególności model danych) już istnieje w Javie. akże wtedy, gdy zdecydowaliśmy się projektować aplikację "od strony Javy". Istnieją jednak sytuacje, kiedy na początku chcemy skupić się na web-serwisowym interfejsie naszej aplikacji (czyli WSDL), kiedy już wcześniej zostały opracowane pewne struktury XML-owe, które będą używane w komunikacji (częsta sytuacja gdy implementujemy istniejący standard lub realizujemy wytyczne narzucone przez prawo) - wówczas lepszym pomysłem może być top-down, czyli generowanie klas na podstawie WSDL (i XML Schema). Generalnie - do wyboru.
WebSocket to (pokrótce) rozszerzenie protokołu HTTP umożliwiające utrzymywanie stałego połączenia między klientem a serwerem i synchroniczne przesyłanie komunikatów, także z serwera do klienta. JAX-RS jest oparty o technologię serwletów, a cała koncepcja REST o bezstanowy protokół HTTP. Nie ma bezpośredniego sposobu na wykorzystanie websocketów w JAX-RS, choć oczywiście aplikacja jako całość może łączyć wiele sposobów komunikacji (na różnych URL-ach).
