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, который будет лучшим вариантом.

Спасибо