Java: RMI vs Web Services

Мне нужно создать распределенное приложение, состоящее из нескольких клиентов, которые отправляют файлы (а также информацию о файлах) на один сервер, также запрашивают этот сервер.

Клиенты должны получить доступ к этому веб-серверу изнутри компании для отправки файлов. Но иногда некоторые конкретные запросы должны запускаться за пределами компании.

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

Что вы думаете об этом? Хороший подход или у вас есть некоторые альтернативы, которые необходимо учитывать.

Спасибо заранее.

Ответ 1

RMI может быть туннелирован через HTTP (см. здесь), поэтому не позволяйте так сильно влиять на ваше решение.

Если оба конца могут разговаривать с RMI, значит, RMI - это то, что вы должны использовать; гораздо легче работать, чем веб-сервис.

Ответ 2

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

Я уверен, что RMI даст вам лучшую производительность по сравнению с веб-сервисами; но веб-службы, вероятно, будут более удобными и гибкими для будущих потребностей.

Ответ 3

Почему вы думаете, что RMI быстрее? По моему опыту, он может быть медленным, сложным в настройке, сложным для обеспечения безопасности и, как правило, неприятным для работы.

Так как веб-службы, как правило, просто XML через HTTP, вы можете, как правило, создать решение, которое будет лучше масштабироваться.

Ответ 4

Если API, который вы хотите поддерживать с помощью службы, не очень хорошо сопоставляется с HTTP, я бы выбрал для RMI (но остерегайтесь ненужных обращений в оба конца).

Если он действительно отображает на HTTP, я бы выбрал REST, который по сути является HTTP-сервлетами, реализующими ваш API в качестве действий. Если большая часть трафика - это загрузка/загрузка файлов, которые вы упомянули, в сочетании с несколькими вызовами API, это, вероятно, путь.

Кстати, ваш опыт в том, что RMI быстрее, чем веб-сервисы, совпадает с моим. (Оба варианта могут быть реализованы с низкой производительностью в результате, в основном, для двусторонних переходов в плохо разработанном API.)

Ответ 5

Это никогда не заканчивается. Вот мое скромное мнение:

Веб-службы позволяют свободно сочетать архитектуру. С RMI вам нужно скомпилировать все, даже если произошли самые незначительные изменения (из-за серийных UUID классов и т.д.).
WS позволяет упростить совместное использование с другими корпоративными компонентами (ESB, SSO, Identity Management, балансировка нагрузки, фильтры безопасности, сертификаты безопасности), поскольку HTTP является основным сетевым протоколом.
Отражение в RMI (и в EJB) кажется более дорогим, чем сам протокол HTTP.

Если вы думаете о том, что EJB больше подходит для среды сервера приложений и проще сравнивать с WS и CORBA в соответствии с вашей статьей (EJB поддерживает управление транзакциями, управление bean, WS имеет расширения WS + (безопасность, транзакции)):

EJB медленнее, чем WS согласно статье: Удаленный EJB в 3 раза медленнее, чем WebService в 7.1
при компиляции/создании EJB нам приходилось использовать точно такую же версию сервера приложений, включая патчи на dev и production, чтобы избежать сомнительных ошибок времени выполнения (это выглядит просто: команда разработчиков (датацентр) не всегда говорит, какой патч они имеют, когда мы делаем исправления для приложения, нам всегда нужно заново спросить точную версию сервера).
Частичные исправления приложения не так просты, если EJB перестроен из-за небольшого исправления, клиентские банки необходимо перестроить, поэтому приложениям, использующим клиентские банки, требуется перераспределение.

(Это были проблемы из моего опыта, возможно, другим людям повезло больше)

Я бы сделал вывод, что WebServices более гибкие, используют меньше рефлексии и, надеюсь, быстрее, если они будут тщательно разработаны. Если RESTful используется в MVC-контроллере в качестве результата, ESB может помочь как с предлагаемыми преобразованиями (меньше кода, просто преобразуется), так и с безопасностью непосредственно в заголовки HTTP (например, ivheader, ivgroup - при использовании веб-печати ibm, диспетчера доступа Tivoli). Использование SAML XACML возможно только при использовании WS, поскольку утверждения работают с XML. Поэтому для распределенных и дислоцированных корпоративных приложений WS более гибки из-за вышеупомянутого.

В статье, на которую вы ссылаетесь, говорится, что WS не имеет транзакций, а только предложения. Статья неправильная или слишком старая. См. OASIS WSAT 1.0 и WSAT 2.0. Microsoft, JBoss, Oracle и некоторые другие поддерживают технологию на своих серверах приложений. Кажется, что Apache Metro поддерживает его (пожалуйста, проверьте).

Ответ 6

RMI в основном используется для небольших приложений. Да, это быстрее, но с течением времени вы почувствуете, что для повышения эффективности вашего приложения при увеличении трафика webservice более удобен в обслуживании, чем RMI, и если вы выбрали веб-сервис REStFull, который будет лучшим вариантом.

Спасибо