Сравните Java RPC по сравнению с WebServices
Подход, который я проявляю, должен использовать многоуровневый продукт (когда-то простой статический метод), который заботится о распределении ресурсов. Вы не хотите этот вид распределения ресурсов, замусорившего Вашу программу.
существует много библиотек, которые делают это. Это не что-то Вам придется волноваться о в большинстве случаев.
3 ответа
Как говорит Дафф, Java RMI на самом деле имеет отношение только к связи Java-to_Java. С точки зрения простоты разработки в наши дни степень кодирования с точки зрения поставщика услуг довольно схожа.
Однако, помимо проблем с производительностью, разрыв между WebServices и RMI весьма разнообразен (для некоторых размеров сообщений может быть незначительным разницу) есть еще один аспект, который следует учитывать: устойчивость.
Как правило, RMI легко настроить, когда один клиент разговаривает с одним сервером, и вы не возражаете, если клиент подключен к одному серверу. Сервер не работает, клиент не работает - такова жизнь.
В случае веб-службы вы можете довольно легко развернуть свою службу на кластере серверов и, учитывая, что вы вызываете веб-службу через HTTP, вы можете легко использовать все обычные методы сетевой маршрутизации и распыления, используемые на крупных веб-сайтах. Никакого специального кодирования на сервере или клиенте не требуется.
Теперь вы можете получить тот же уровень устойчивости с помощью RMI, но для этого требуется немного лучшая инфраструктура предоставления услуг, и именно здесь модель программирования Java EE EJB (или такие фреймворки) как Весна) войдите в игру. EJB использует RMI поверх IIOP, протокол, который обеспечивает отказоустойчивый вызов экземпляров сервера, прозрачно справляясь с сбоями сервера. [Он делает гораздо больше, например, безопасность и транзакции, но также и веб-службы. Интересно, но не является частью этого обсуждения.]
Итог: Для предоставления услуг производственного качества я обычно начинаю с создания объекта услуги. Я использую Java EE EJB 3, другие используют Spring. Вы можете предоставить этот объект службы как веб-службу или как RMI / IIOP с очень простой конфигурацией / аннотацией. Очень мало усилий, чтобы выбрать одно или оба. В моем мире много проблем с взаимодействием, поэтому я стараюсь раскрывать веб-службы. Если вам нужно рассмотреть только Java, использование RMI / IIOP может дать некоторое улучшение производительности, но это не гарантируется, вам нужно будет измерить производительность, чтобы быть уверенным.
Я предполагаю, что вы имеете в виду RMI с Java RPC. Вызов удаленного метода очень специфичен для Java, поэтому его довольно легко обрабатывать в собственных программах Java (Java с обеих сторон). Он использует двоичный формат для передачи данных и не работает через HTTP, поэтому он, вероятно, быстрее, чем решение веб-службы.
Веб-службы, с другой стороны, используют (как правило) общий формат, такой как XML или JSON, который можно запросить и читается любым другим удаленным приложением. Накладные расходы больше (выполнение HTTP-запроса и сериализация / десериализация данных), но клиент, использующий веб-сервис, не заботится о том, как веб-сервис генерирует эти данные, и не полагается на определенный язык программирования, пока он находится в указанный формат.
Если вы смотрите на веб-сервисы RPC и Document, этот вопрос и ответы могут быть тем, что вы ищете.
Я мог бы это объяснить, но когда кто-то обсуждает с примерами кода, на который можно посмотреть, мой ответ будет бледным по сравнению с
. , Я не уверен, о чем вы спрашиваете, я думаю, здесь может возникнуть проблема с терминологией.