ответ, как и много вещей, зависит.
Если и ваш клиент, и ваш сервер являются только Java, и не будут ничем иным, и вы сможете одновременно развертывать новые версии баннеров как для клиента, так и для сервера (например, вы можете перезагружайте как клиент, так и сервер всякий раз, когда происходит изменение в классах Java), а затем рассмотрите поддержку RPC Spring. Поддержка удаленного доступа в основном работает, беря интерфейс объекта и взаимодействуя с ним с другой машины. Он тесно связан с этим интерфейсом. Но этот подход имеет преимущество в удобстве использования, и он требует очень мало, чтобы взять существующее POJO и экспортировать его как услугу. Кроме того, механизмы RPC, как правило, не полагаются на протокол HTTP, поэтому, если вы серьезно относитесь к скорости, и вы чувствуете, что не можете позволить даже обмен hTTP на провод в ваших вызовах, тогда рассмотрите один из «удаленных» " опции. Spring core поддерживает RMI, HTTP-Invoker, Burlap и Hessian. I've implemented поддержка множества других экспортеров, которые используют более современные технологии RPC, такие как Thrift, MessagePack, JBoss Remoting и Avro. Все эти технологии предлагают свою собственную технологию «сериализации», которая, в свою очередь, имеет свои преимущества и недостатки, как это делают RMI, Hessian и Burlap.
Все, что сказано, поддержка «удаленного доступа», вероятно, не самая безопасная опция, поскольку клиент и сервер тесно связаны: если вы измените класс java, используемый на сервере, вам нужно будет изменить класс Java, используемый на клиент.
Вместо этого предпочитайте подход, ориентированный на документ, такой как REST или первые веб-службы Spring. В этих технологиях у вас есть два шага для минимальной веб-службы: вы определяете свои службы Java с их ассоциированными возвращаемые типы и объекты, а затем вы определяете интерфейс с точки зрения конечных точек HTTP и связанных с ними документов, которые вы готовы обрабатывать на этих конечных точках. «Документы», которые вы отправляете, например, над REST, могут быть документами XML, или они могут быть документами JSON или любым из нескольких типов кодирования. Дело в том, что они передаются с использованием HTTP, и для получения этих документов и их преобразования в объекты, имеющие значение для вашего приложения, должна быть установлена техника, например Spring MVC. Хорошая роль в том, что вы делаете так, заключается в том, что вы можете развивать фактический Java-сервис, а клиенты, которые потребляют конечные точки HTTP, а не интерфейс Java, не являются более мудрыми.
Поддержка REST весной MVC 3 очень, очень мощная и простая в использовании.Spring использует SPI-интерфейс HttpMessageConverter для преобразования HTTP-запросов из JSON или XML в объекты Java, с которыми вы можете взаимодействовать в своем коде, и для преобразования объектов из вашего кода в документы, которые могут быть отправлены как ответы HTTP. Spring MVC автоматически регистрирует HttpMessageConverter, если у вас есть библиотека Jackson JSON на пути к классам, и она регистрирует поддержку JAXB, если у вас есть JAXB на пути к классам. Например, использование JAXB, безусловно, выходит за рамки этого вопроса, но вы можете найти его довольно легко. Spring автоматически ответит на HTTP-запрос, основываясь на типе заголовка «Принять» HTTP-запроса. Если вы укажете «Accept = application/xml», тогда он будет искать соответствующий HttpMessageConverter, чтобы преобразовать результат в XML. Он делает то же самое для других значений «Accept».
Веб-службы RESTful, основанные на SOAP, конечно же, зависят от скорости базового обмена HTTP. Кроме того, XML-документы SOAP или REST или даже документы JSOn могут быть раздуты и неэффективны по всему кабелю. Таким образом, вы можете реализовать более эффективные HttpMessageConverters. Я предоставил HttpMessageConverter, который позволяет делать обмены RESTful. using Avro, Thrift, Snappy (a compression library), Google Protocol Buffers, and MessagePack. Теперь, конечно, даже с этим вы по-прежнему подвержены задержке, присущей HTTP, но, по крайней мере, сами полезные нагрузки могут быть настолько эффективными, насколько это возможно. Конвертеры сообщений являются фактически различными способами сериализации или кодирования полезных нагрузок. Вместо JSON или XML вы просто используете один из них. Например, проконсультируйтесь с тестами в этом пакете. На самом деле, примеры начинаются. Hte Весна MVC showcase
См. Также [Веб-службы против Spring remoting] (http://stackoverflow.com/q/5298286/418439) & [Весенние удаленные/веб-сервисные технологии] (http: /stackoverflow.com/questions/9774686/spring-remoting-webservice-technologies) –