JMS vs WebServices

Witam,
Wiem, że JMS to technologia do asynchronicznego przesyłania komunikatów (czyli nie czekam na odpowiedź, co może być użyteczne jak operacja może długo trwać). Mam jednak problem z wyobrażeniem sobie kiedy JMS jest jednoznacznie lepszym rozwiązaniem od WebServices? Znam odpowiedź kiedy nie jest: w przypadku gdy integrujemy zupełnie różne technologie np. PHP i Jave.

Chciałbym uzyskać na pytanie jakie dane w szczególności wygodnie wysyłać za pomocą JMS (aby zbudować własny przypadek użycia i się tego nauczyć). Super byłoby usłyszeć o przypadkach z prawdziwych projektów.

Dzięki za podzielenie się.

Ale sam już powiedziałeś kiedy ->

1. Kiedy chcesz komunikować sie asynchronicznie, czasem nawet kiedy klient wcale nie "słucha" (odbierze sobie później)
2. Kiedy nie wiesz ilu jest odbiorców, gdzie i kim są. Odbiorcy mogą sie rejestrować i ciągnąć dane z kolejki czy odbierać powiadomienia z tematu, a ty wcale nie musisz o nich niczego wiedzieć.

Zastanawia mnie czy sensowne może być stosowanie JMS w przypadku synchronicznej komunikacji zamiast WebServices.

Jeżeli szukam transakcyjnej alternatywy dla synchronicznej komunikacji (bo często opłaca się czekać to co wybrać): czy zdalne EJB to potencjalnie dobra ścieżka?

EJB ogranicza cię w kwestii technologii, bo to rozwiązanie Java-Only. Poza tym EJB to raczej rozwiązanie stosowane do wewnętrznej komunikacji między modułami systemu (obiekty zdalne jeśli system jest jakoś rozproszony). Pytanie więc do czego ci to jest właściwie potrzebne? WebServices dają większe możliwości jeśli chodzi o korzystanie z tego samego API. Może będziesz chciał napisać wersję mobilną? Może ktoś będzie chciał napisać moduł komunikujący się z tymi serwisami, ale niekoniecznie w Javie EE? Może za kilka lat jeden z modułów będzie przepisywany na inną/nową technologię? EJB mimo wszystko bardzo mocno spina cię z jedną technologią. Jeśli to jest komunikacja między kawałkami tego samego systemu i raczej nie ma mozliwości żeby ktoś inny chciał z tej komunikacji korzystać, to czemu nie? ;)

Prawdę mówiąc jest to projekt edukacyjny (ma być podobnie skomplikowany integracyjnie jak rzeczywiste systemy, ale dużo prostszy biznesowo), który ma mnie nauczyć integracji usług i udawać projekty podobne do tych, które widzę w pracy: (pogodzenie pracy i uczelni oraz przy okazji uczenie się nowych rzeczy, możliwość wytestowania pewnych rzeczy jakie w przyszłości może chciałbym zastosować, ale jeszcze się nie odważyłbym przy obecnej wiedzy).

Wydaje mi się, że ze zdalnym EJB w rzeczywistym systemie nie ma wielkiego problemu, ponieważ bardzo łatwo zrobić z tego SOAPowy endpoint w razie potrzeby integracji np. z .NETem.

Chcę poznać EJB Remote, ponieważ poszukuje metody komunikacji między Java SE oraz dwoma serwerami aplikacyjnymi. Czyli w dużym skrócie Java <-> Java. Zależy mi na wydajności: chcę to zbadać. Ponadto chcę porównać zastosowanie różnych rodzajów usług, porobić benchmarki (w tym wypróbować websockets), powyciągać wnioski itp.

To w takim razie napisz sobie po prostu kilka różnych kanałów komunikacji. Jak dobrze oddzielisz warstwę "biznesową" to sam kanał komunikacji będzie miał niewiele kodu. Wtedy będziesz mógł sobie porównać ;)