Java: RMI против веб-сервисов

Question

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

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

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

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

Заранее спасибо.

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

В любом случае, это никогда не заканчивается спором. Вот мое скромное мнение:

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

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

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

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

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

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

Answer 6

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

Спасибо