Народ вопрос кто работал с этими технологиями. Пожалуйста, приведите преимущество одного перед другим абстрагируясь от конкретной задачи.

Хороший вопрос ( я по ошибке нажал на минус, а хотел нажать плюс :(  )
Ответ на него тянет на статью или главу книги. И наверняка они есть.

Например, в книге "Java Performance Tuning" автор пишет, что предпочитает использовать RMI, и только в исключительных случаях сокеты.

Я много лет использую сокеты и постоянно ищу оправдания, почему не применяю RMI. Одна из причин - сокеты проще для понимания (на мой взгляд), с них было проще начать сетевое программирование.  Звучит очень субьективно, потому что RMI как раз и придуман для упрощения программирования. RMI - это сокеты + уже сделанная часть работы, которую обычно выполняет программирующий на сокетах. И эта часть работы сделана универсально. Универсальность снижает эффективность, но это окупается быстротой разработки. И во многих случаях это выгодный копромисс.

Более детально можно рассматривать только в привязке к конкретным ситуациям.

1. Сериализация

RMI пересылает по сети сериализованные обьекты. Аналогично можно сделать и на сокетах, но придется повозиться с Object..Stream. Обнаружить, что он кеширует пересылаемые обьекты, что надо применять метод reset и т.д.

Передача сериализованных обьектов удобна, когда обьекты сложные или их ассортимент велик, а интенсивность пересылки относительно низка. Возможно, это типичная ситуация.

Если же обьекты простые (всего несколько полей примитивных типов) , а их поток интенсивен (хрестоматийный пример - биржевые данные - символ(4-5 байтов), цена(float) и количество(int) - сотни сообщений в секунду), то для уменьшения сетевого трафика выгоднее посылать сырые данные.  

Сетевой трафик некритичен, когда он локальный, между серверами. А если данные рассылаются клиентам через интернет, то это надо учитывать. Или предьявить к клиентам требование иметь хороший интернет и отсечь тем самым не имеющих.

Сокеты позволяют использовать свой формат данных, т.е. передавать сырые данные и сэкономить на сетевом трафике.

2. Синхронность.

RMI имитирует вызов метода обьекта. Непринципиально, что этот обьект находится на удаленном компьютере (от нас это скрыто). Предположим, что метод возвращает коллекцию. Например, это выборка из таблицы базы данных. Очевидно, что RMI сначала сформирует коллекцию на удаленном компьютере, т.е. разместит в памяти. Потом перешлет всю коллекцию на клиента, что тоже потребует памяти под всю коллекцию уже на клиенте. И только после того, как вся коллекция переслана по сети, метод вернет ссылку на нее. 

Более эффективно устроен JDBC - там ResultSet возвращает строки (те же элементы коллекции) по мере их пересылки на клиента, т.е. нет необходимости ждать, когда коллекция сформируется полностью и нет необходимости выделять память под всю коллекцию. Ни на приемной стороне, ни на передающей (хотя наличие буфера и не помешает). 

На сокетах проще организовать взаимодействие а ля JDBC. На RMI  тоже можно, но клиент всякий раз будет вынужден слать на удаленный компьютер запрос "дай мне следующий обьект" - аналог метода next() в ResultSet.

3. HTTP tunnelling

RMI сам выбирает протокол соединения с удаленным компьютером из нескольких возможных. Если клиент защищен файерволом, то RMI пытается обернуть запрос в HTTP и послать на свой законный порт. Если и это не позволено, то самый последний шанс - соединение по HTTP на 80 порт. Однако на серверной стороне необходимы дополнительные усилия по поддержке такого режима работы, потому что 80 порт может использоваться внешним веб-сервером для совершенно других задач. И все запросы RMI на 80 порт должны пересылаться серверному компоненту RMI. Для этого можно использовать специальный сервлет.

На сокетах это все нужно делать самому.  

Применения
Как следует из названия (Method Invocation) RMI наиболее удобен для обеспечения взаимодействия по схеме запрос - ответ. RMI, очевидно, малоэффективен для реализации обмена в виде непрерывного потока сообщений - всякого рода messaging systems.  


Это сообщение отредактировал(а) COVD - 25.2.2008, 22:55

Где то я такой ответ уже слышал, эта тема подымалась между мной и w1nd.

Добавлено через 4 минуты и 21 секунду
Вот и ссылочка http://forum.vingrad.ru/forum/topic-184515.html

Да, было дело. Ну не стирать же теперь эту "нетленку"   

Здорово COVD, спасибо, не ожидал что ответ будет столь объемным и интересным, отражаю соответствующим образом.

Тянет на факу. Я бы с выводом не был так категоричен.
можно сказать что на производстве, где много компов фирмы объединены в локальную сеть и скорость разработки имеет наибольшее значение, RMI - хорошее подспорье. Для сетевых игрушек, IM клиентов, и прочих персональных программ, бесспорно выбор в сторону сокетов!

Кстати, это стандартный вопрос который встает на SCJD проекте. Есть выбор писать как на RMI так и на сокетах. Соответственно, очень хорошо написаны недостатки и достоинства в специализированных книгах. Например, немного из Sierra - SCJP & SCJD Java 5 Study Guide

■ Sockets are low-level, RMI is high-level.
■ RMI uses Sockets to do its work.
■ To move an object from one JVM to another, you need to serialize it.
■ Serialization flattens an object by packaging up the object’s state.
■ An object’s serializable state consists of all nontransient instance variables.
■ Sockets are the end-points of a connection between two networked devices.
■ You can send a stream of bytes between Socket connections, but you’ll need
an agreed-upon protocol to know what those bytes mean.
■ RMI uses serialization as the protocol, so you don’t need to read and
manipulate the bytes in your code.
■ RMI is simpler to implement than using plain Sockets.
■ Sockets offer more flexibility in protocol than does RMI.
■ Ask yourself all the questions on the “Ask Yourself” list.
(могу прислать файл 12Mb, стучитесь в личку)

Не буду спорить. Да и вывод в форме "эффективен/неэффективен в большинстве случаев" не имеет практической пользы. Возможно, было бы правильнее перечислить категории софтвера (как вы и сделали), где уже сложилось определенное отношение к RMI. Поэтому вывод заменил. Типа, отреагировал на критику  .


Это сообщение отредактировал(а) COVD - 25.2.2008, 23:21