значение java RMI, пожалуйста?

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

В некоторых случаях (погружение в устаревшие или «корпоративные» приложения) у вас просто нет выбора.

Однако, если вы начинаете новый проект, есть и другие варианты:

REST + JSON через HTTP

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

Теоретически это должно потребовать больше работы, чем RMI, потому что вам нужно вручную создавать доступные URL-адреса, допустимые глаголы в каждом URL-адресе и т. д. На практике я бы сказал, что шаблон RMI на самом деле никому не помогает.

Опираясь на Java, Jersey – это великолепная библиотека для написания собственных веб-сервисов RESTful.

Если вам нужно решение с включенными батареями для веб-служб RESTful с Java, Dropwizard от хороших ребят из Yammer даст вам полноценный сервер и инфраструктура, готовые просто подключить вашу бизнес-логику и обеспечивающие ведение журнала, подключение к базе данных, сериализацию, маршрутизацию запросов и даже сбор метрик из коробки.

МЫЛО

Предыдущий стандарт для связи с удаленными службами. Если у вас нет причин использовать его, я бы придерживался REST.

Бережливость

Thrift создаст клиента и заглушку сервера, выполняя большую часть работы. Связь осуществляется в эффективном бинарном протоколе. Он набирает популярность в мире Java, поскольку используется во многих проектах с открытым исходным кодом в области «больших данных». Примеры, Cassandra, HBase (переход на Avro). Scrooge — это твиттер-проект по созданию идиоматических заготовок для scala.

Акка актеры

Akka — это фреймворк, который реализует Акторная модель для Scala и Java. Включает средства для межсервисной связи и заботится о многих деталях под капотом. я

В зависимости от ваших потребностей, некоторые из них будут более подходящими, чем другие.

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

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

Вот заявленные цели RMI из документация

Целями поддержки распределенных объектов в языке программирования Java являются:

• Поддержка беспрепятственного удаленного вызова объектов на разных виртуальных машинах.
• Поддержка обратных вызовов с серверов на апплеты
• Интегрировать распределенную объектную модель в язык программирования Java естественным образом, сохраняя при этом большую часть объектной семантики языка программирования Java.
• Сделайте очевидными различия между распределенной объектной моделью и объектной моделью локальной платформы Java.
• Максимально упростите написание надежных распределенных приложений
• Сохраняйте безопасность типов, обеспечиваемую средой выполнения платформы Java.
• Поддержка различной семантики ссылок для удаленных объектов; например живые (непостоянные) ссылки, постоянные ссылки и отложенная активация
• Поддерживать безопасную среду платформы Java, обеспечиваемую менеджерами безопасности и загрузчиками классов. В основе всех этих целей лежит общее требование, чтобы модель RMI была как простой (легкой в ​​использовании), так и естественной (хорошо вписывалась в язык).

Вы правы, RMI является примером слишком тесной связи между поставщиком услуг и потребителем услуг. И это еще хуже, чем кажется на первый взгляд: вы никогда не знаете, какое исключение вы можете получить на стороне клиента, что приведет к ClassNotFoundException, которое маскирует реальную возникшую ошибку. RMI, а также EJB — это технологии прошлого, прошлого, верившего в иллюзию «прозрачно распределенных объектов».

Современные удаленные сервисы основаны на полной противоположности подходу RMI: REST и JSON.

RMI предназначен для прямо противоположного случая, когда вы хотите жесткое связывание, настолько жесткое, чтобы оно выглядело как вызов локального метода. Если вы этого не хотите, не используйте его. Вся парадигма RPC не для всех, включая меня, хотя я и написал книгу по RMI, но у каждого инструмента есть свое применение. Например, Java EE построена на модели RMI.