Асинхронный вызов из веб-службы Java в приложение .net

1

Сценарий:

Существует Java-библиотека, которая помогает асинхронно прослушивать некоторые системные события. Я планирую использовать уже реализованную асинхронную функциональность из проекта vb.net. Я планировал рассмотреть его следующим образом:

  1. Создание веб-службы вокруг java-библиотеки

  2. Добавьте ссылку на эту службу в приложение.net.

  3. Веб-служба будет запускаться локально на tomcat в качестве приложения.net. Проблема, с которой я столкнулся, заключается в том, как сделать веб-сервис для асинхронного общения с.net-приложением? Должно ли приложение.net блокировать и ждать на веб-службе, и если да, то как?

  • 0
    Спасибо, я был потерян с разметкой.
  • 0
    Давайте узнаем, какой из них является потребителем, а какой - поставщиком услуг. Вы хотите написать веб-сервис в библиотеке Java, это означает, что Java API будет предоставлять сервис для приложения .Net. И в этой ситуации .net api станет потребительским, это то, что вы хотите ??
Показать ещё 1 комментарий
Теги:
asynchronous
web-services

2 ответа

3
Лучший ответ

Я считаю, что, во-первых, вам нужен шаблон проектирования для обмена асинхронными службами. T лучше решать ваши системные требования.

1 - Обработчик асинхронного ответа

Приложение создает отдельный поток для обработки ответа сервера, оставляя основной поток свободным для других задач. Когда ответ приходит, основной поток уведомляется о получении ответа. Существуют две стратегии реализации: объединение и обратный вызов. При объединении основной поток проверяет ответ во втором потоке, пока не будет доступен ответ. При обратном вызове второй поток уведомляет основной поток с помощью метода обратного вызова.

2 - Запрос/Подтверждение

Эти шаблоны основаны на участии сервера для достижения асинхронной связи. Вместо разделения процесса на два клиентских потока процесс делится на две разные транзакции между клиентом и сервером. Эти шаблоны требуют определенной корреляционной идентификации для связывания транзакций запроса и ответа. Подсистема обмена сообщениями используется для достижения большей масштабируемости и доступности.

Простое решение может быть реализовано с использованием стратегии асинхронного реагирования/обратного вызова. Для этого поставщик услуг (java) может быть простым веб-сервисом jax-ws. Реализация потребителя (.net) службы может использовать делегат AsyncCallback. Существует пример здесь.

Рекомендации:

http://www.servicedesignpatterns.com/WebServiceInfrastructures/AsyncResponseHandler http://www.servicedesignpatterns.com/ClientServiceInteractions/RequestAcknowledge http://msdn.microsoft.com/pt-br/library/system.asynccallback(v=vs. 110).aspx (делегат AsyncCallback) http://msdn.microsoft.com/en-us/library/wyd0d1e5(v=vs.100).aspx (потребитель службы) http://java.dzone.com/articles/jax-ws-hello-world (производитель услуг)

1

Вы планируете построить долговременный процесс, подумайте о том, чтобы использовать какой-то механизм рабочего процесса, например JBPM или Activiti. Поскольку ваши вызовы будут веб-службами, которые не имеют статуса, и вы намерены лучше использовать обратные вызовы, это будет возможность создавать постоянные длительные рабочие процессы, поскольку они позаботятся о большей части проблем дизайна и архитектуры, иначе вы в конечном итоге справитесь с этим. например, проблем -Corelation между запросом-ответом -Loss данных о перезагрузке системы -Application, переполненной синхронизацией данных.

Опрос и опрос - это всего лишь механизмы для взаимодействия между процессами, но вам необходимо обрабатывать корреляцию req-resp, а также обеспечивать надежность связи.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню