Witam serdeczenie, zarówno jax-ws oraz rmi pozwalają na zdalne wywoływanie metod, a więc jaka jest różnica ?
Wiem, że RMI powoduje problemy z firewallem za względu na używanie różnych portów, ale jeżeli weźmiemy alternatywe tj. Hessian lub Burlab, to ten problem znika. A więc zakładając naciąganą jednolitość ww. tj. rmi=hessian=burlab, to czym różnią się one względem jax-ws ?
Internety mi nie wytłumaczyły i proszę tutaj :)
Z tego co wiem interfejsy zdalne EJB sa abstrakcja nad RMI i lepiej z nich korzystac podczas komunikacji java <-> kontener EJB. WebServices sluza najczeciej do integracji roznych technologii, czesto w innych jezykach np. systemu ERP i aplikacji JEE. Sa mniej wydajne, ale czesto w zupelnosci wystarczajace.
Shalom napisał(a):
- RMI sie prawie w ogóle nie używa.
- WebServices (zarówno SOAP czyli JAX-WS jak i REST) pozwalają na korzystanie z serwisów w sposób ustandaryzowany niezależny od technologii - możesz wystawić serwisy pisane w Javie a korzystac z nich będą aplikacje w różnych językach. Z RMI takiej mozliwości nie ma.
Rybaa napisał(a):
Z tego co wiem interfejsy zdalne EJB sa abstrakcja nad RMI i lepiej z nich korzystac podczas komunikacji java <-> kontener EJB. WebServices sluza najczeciej do integracji roznych technologii, czesto w innych jezykach np. systemu ERP i aplikacji JEE. Sa mniej wydajne, ale czesto w zupelnosci wystarczajace.
Czyli podsumowywując:
RMI stosowane tylko, gdy korzysta się z interfejsu zdalnego Javy i tylko wtedy gdy klient i serwer są napisane w Javie. Ale co wtedy z Hessianem i Burlapem, które pozwalają na używanie różnych technologii i wysyłke odpowiednio binarną i xml?!
Dalej podsumowywując... JAX-WS oraz REST stosujemy, gdy chcemy serwer/klienta, który dostarcza/korzysta z technologii inna niż klient/serwer. No ale i w tym przypadku... kiedy stosować JAX-WS a kiedy REST ?
Czy dobrze zrozumiałem Wasze wypowiedzi ? ;)
Dzięki za pomoc.
Nie do końca cie rozumiem. Hessian i Burlap, tak samo jak JAX-WS i jego implementacje to są WebSerwisy.
RMI używa sie rzadko i faktycznie tylko wtedy kiedy chcesz komunikować javę z javą i w zasadzie tylko kiedy sam implementujesz oba kawałki ;]
WebSerwisów można używać gdzie i kiedy chcesz, możesz w ogóle wystawiać na świat serwisy których sam nie "konsumujesz" (Np. udostępniasz pogodę albo notowania giełdowe).
REST jest lżejszy od SOAPowych serwisów i można go konsumować dużo dużo łatwiej, np. przez zwykłe żądania http, przez ajaxowe wywołania z poziomu javascriptu etc. Ale z drugiej strony musisz dokładnie wiedzieć jak należy się do niego odwoływać i co ci zwraca. W przypadku SOAPa takie informacje są zawarte w wsdlu.
Trochę inaczej. RMI jest technologią komunikacji stricte javową. Wszystkie wywołania zdalne są z punktu widzenia klienta wywołaniami lokalnymi. Różnica leży tylko w sposobie tworzenia obiektów. Klient RMI nie wykorzystuje operatora new, ale wzorzec fabryki za pomocą registry.lookup. Po stronie serwera należy zarejestrować obiekt (implementujący interfejs Remote) w repozytorium. Komunikacja odbywa się przez serwer RMI za pomocą jego własnych protokołów. W efekcie wywołania zarówno po stronie klienta jak i serwera są "takie jak zwykła java". Ważną cechą jest umiejętność dociągnięcia przez klienta brakujących definicji klas z serwera.
W przypadku Webservices postawiono na interoperacyjność (trudne słowo) czyli możliwość współpracy różnych rozwiązań za pomocą wspólnego interfejsu. Wyróżnia się dwa główne rodzaje WSów. Pierwszy to SOAP, który oparty jest o przesyłanie komunikatów za pomocą http. Komunikaty, wywołania metod i ich wyniki, są opakowane w XMLa. XML ten jest dobrze zdefiniowany i posiada własną schemę. Dostępne operacje są zdefiniowane w ramach pliku WSDL, który jest definicją interfejsu WS i zawiera wszystko co potrzeba tzn. zarówno definicje metod (sygnatury - nazwa, parametry, co zwraca) jak i opis modelu (definicje typów własnych usługi zmapowane na podstawowe typy XML). Ten sposób komunikacji jest dość "ociężały" ze względu na narzut związany z formatem wiadomość. Z drugiej strony jest bardzo elastyczny i rozszerzalny. Posiada też własną implementację zabezpieczeń wiadomości (szyfrowanie, podpis elektroniczny itp). Drugim sposobem obsługi WS jest REST. W tym przypadku komunikacja oparta jest o właściwości protokołu http. Dostępne metody są takie same jak w tym protokole (GET, PUT, POST, DELETE, HEAD i inne), a sposób wywołania metod oparty jest o konstrukcję adresu URL i URI. Powoduje to znacznie większą elastyczność samego protokołu, ale jednocześnie czyni go "słabo typowanym". Choć dobrze napisana aplikacja potrafi określić swoje typy. To jednak inna inszość. Podobnie odpowiedzi serwera są oparte o protokół HTTP i jego kody. Sama treść odpowiedzi nie jest opakowana w żadne dodatkowe znaczniki. Zazwyczaj wykorzystuje się więc XMLa i JSONa. Zabezpieczenie w tym przypadku to ssl + to co sobie zaimplementujesz na poziomie aplikacji (tokeny, klucze, podpisy).
Podsumowując
Protokół:
RMI - własny domyślnie używa portu 1099, łączność po TCP/IP
SOAP - HTTP(s)
REST - HTTP(s)
Typizacja
RMI - jak w javie plus możliwość dociągnięcia brakującej definicji klasy
SOAP - statyczna, typy opisane w WSDLu i XSD
REST - brak
Bezpieczeństwo
RMI - brak, ale można skonfigurować VPN na potrzeby komunikacji.
SOAP - SSL, podpisy, szyfrowanie - specyfikacja WS-Security
REST - SSL, własna implementacja
Sposób udostępniania
RMI - przez rejestr w ramach JVM
SOAP - WSDL
REST - nie ma jako takiego, choć wywołanie usługi powinno zwracać informację o możliwych akcjach i ich adresach.