Как структурировать клиент-серверное приложение с помощью push-уведомлений - PullRequest
Новая
       17

Как структурировать клиент-серверное приложение с помощью push-уведомлений

1 голос
/ 18 октября 2010

РЕДАКТИРОВАТЬ : Я забыл указать основного кандидата для веб-приложений: JSON over HTTP / REST + Comet. Он сочетает в себе лучшие черты других (ниже)

  • Persevere в основном объединяет все, что мне нужно на сервере
  • Фокус для Java и тому подобного определенно делается на Comet серверах , но не может быть слишком сложно использовать / написать клиент.

Я запускаю приложение с сервером, на котором хранятся данные, и клиентами, выполняющими операции, которые влияют на эти данные и, следовательно, требуют какого-то уведомления для всех заинтересованных / подписанных клиентов.

Первый клиент, вероятно, будет написан на WPF, но нам, вероятно, потребуется добавить клиентов, написанных на других языках, например клиент Java (Swing?) и, возможно, веб-клиент.

Фактический вопрос (s): Какой протокол мне следует использовать для реализации этого? Насколько легко будет интегрироваться с клиентами JS, Java и .NET (точнее, C #)?

Я мог бы использовать несколько интерфейсов / протоколов, но в целом было бы проще использовать тот, который совместим. Учитывая важность взаимодействия, я исследовал несколько вариантов:

  1. JSON-RPC
    • легкий
    • поддерживает уведомления
      • Единственная библиотека .NET, которую я смог найти, Jayrock не поддерживает уведомления
    • хорошо работает с JS
      • также верно для XML-материалов (и, возможно, даже для двоичных протоколов), НО это, вероятно, будет более эффективным благодаря встроенной поддержке
  2. Protobuf / Бережливость
    • IDL позволяет легко выкладывать модельные классы на каждом языке
    • не поддерживает уведомления
    • Thrift поставляется с RPC из коробки, но protobufs не
    • не уверен насчет JS
  3. XML-RPC
    • достаточно просто, но не поддерживает уведомления
  4. SOAP: Я даже не уверен в этом; Я еще не прогнал это.
    • кажется довольно сложным
  5. Message Queues / PubSub: не совсем протокол, но может подойти
    • Я почти ничего о них не знаю, и затерялся среди модных слов`-- JMS? ** MQ?
    • Возможно, в сочетании с некоторым механизмом RPC, описанным выше, хотя это не является обязательным требованием и, возможно, излишним.

Другие варианты, конечно, приветствуются.

Ответы [ 5 ]

1 голос
/ 03 ноября 2010

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

1 голос
/ 02 ноября 2010

Если вы хотите легко публиковать события для клиентов в разных сетях, вы можете обратиться к стандарту XMPP . (Используется, среди прочего, Jabber и Google Talk.)

См. Расширение для публикации-подписки функциональности.

Существует несколько библиотек на разных языках, включая C #, Java и Javascript .

1 голос
/ 02 ноября 2010

Как упоминалось в XMPP, SIP обладает аналогичной функциональностью. Этот может быть более доступным для вас.

1 голос
/ 27 октября 2010

Я неравнодушен к предложенному вами дизайну паба / саба.Я бы посмотрел на ZeroMQ.У него есть привязки к C #, Java и многим другим платформам.

Список привязок: http://www.zeromq.org/bindings:clr

Я также нашел этот разговор в списке разработчиков ZeroMQ, который может ответить на некоторые ваши вопросы о несколькихклиенты и ZeroMQ: http://lists.zeromq.org/pipermail/zeromq-dev/2010-February/002146.html

0 голосов
/ 02 ноября 2010

Вы можете использовать SOAP через HTTP для изменения данных на сервере и SOAP через SMTP для уведомления подписанных клиентов.

OR

Сервер ничего не знает о подписке, и клиенты обращаются к серверу по тайм-ауту для отслеживания интересующих их обновлений, используя XML-RPC, SOAP (сгенерированный с использованием WSDL) или просто HTTP GET, если в этом нет необходимости. передать сложные данные об отслеживании.

...