Как обеспечить кроссплатформенный, асинхронный сервисный интерфейс

Question

Каков наилучший способ предоставления асинхронного сервисного интерфейса многоплатформенным (прежде всего, java и .net) клиентам?Бэкэнд-сервис реализован в Java.

Мы смотрим на асинхронный веб-сервис и очереди сообщений, но, очевидно, кроссплатформенный асинхронный веб-сервис * пока не поддерживается в Java (насколько я знаю), и для очередей сообщений я не был уверен, какой кодек /протокол будет лучше.

*: Межплатформенные асинхронные веб-службы могут быть описаны в WSDL 2.0, но не в WSDL 1.1 (насколько я понимаю).Теперь JAX-WS 2.x поддерживает асинхронный веб-сервис, но не WSDL 2.x.Поэтому я предполагаю, что клиенты асинхронного веб-сервиса JAX-WS должны быть клиентами JAX-WS, и мы не можем их использовать.

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

РЕДАКТИРОВАТЬ: Трудность здесьчто сервис асинхронный, и мы предпочитаем интерфейс на основе обратного вызова для эффективности (поэтому мы не хотим использовать 2 вызова на синхронном интерфейсе WS и т. д.)

Answer 1

Если это сообщение, чем использовать систему Messagequeue. как ZeroMQ. все они кроссплатформенные.

в противном случае мы делаем это с .net WCF и используем JaxWS из java для проверки совместимости интерфейса.

Answer 2

Не знаю, что лучше , но SOAP - хороший выбор для бэкэнда Java.Сообщения основаны на xml (например, не ограничиваются платформами Java), и они широко используются, так что вы получаете много поддержки, инструментов и библиотек в сети.XMPP.

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