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.