Асинхронный потоковый веб-сервис - PullRequest
3 голосов
/ 20 апреля 2009

Мне нужен какой-то фреймворк, который поможет мне выполнять асинхронную потоковую передачу по http. Это может выглядеть как SOAP WS или что-то еще. Я не знаю, правильно ли я его назову, вот что мне нужно:

Сервер A хочет сделать запрос к удаленному Серверу B через http. Запрос содержит произвольную информацию. Результат для него будет содержать несколько записей одного типа. Некоторые из них доступны сразу, другие доступны позже. ServerA хочет получить доступные результаты как можно скорее, не дожидаясь, пока все результаты станут доступны. В реальном мире ServerB будет выполнять поиск в разных источниках данных, некоторые из которых более отзывчивы, чем другие.

Я могу придумать 3 вида решения. Сначала ServerA генерирует случайный идентификатор запроса, выполняет запрос SOAP

void ServerB.startSearch(id, request); 

, который немедленно вернется, а затем A периодически вызывает

Result[] ServerB.areThereAnyNewResults(id);

Итак, ServerA опрашивает ServerB на предмет новых результатов. Я называю этот метод опросом. Он включает в себя несколько соединений, установленных от A до B. Другое решение заключается в предоставлении службы приема на стороне ServerA, например

ServerA.acceptResults(String id, Result[] newResults); 

и звоните

ServerB.startSearch(id, request, serverAReceivingServiceEndpoindAddress);

Таким образом, ServerB отправляет новые результаты в ServerA.acceptResults (), когда новые результаты становятся доступными. Я называю это толчком. Он включает в себя 1 соединение, установленное от A до B, и множество соединений, установленных от B до A.

Другим вариантом является потоковая передача результатов по одному и тому же каналу http в пределах одного ответа.

A выполняет вызов http (я не знаю, может ли это быть SOAP или должно быть что-то еще), B начинает поиск и, когда новые результаты становятся доступными, отправляет их через поток http и сбрасывает их, чтобы они могли быть доступны на стороне A немедленно. Он не закрывает http-соединение, пока не будут доступны все результаты. Он включает только одно соединение от А до Б, поэтому я бы предпочел использовать его. Я называю это потоковым Я понимаю, что это может не сработать, если какой-то прокси находится на пути, который буферизует содержимое ответа.

Итак, мой вопрос, есть ли какое-нибудь решение, которое сделает большую часть работы за меня. То, что я хотел бы сделать, это назвать такой код на стороне

Service s = new RemoteAsyncService("http://serverb.com/serviceEndpoint", RemoteAsyncService.STREAMING); 
// or RemoteAsyncService.POLLING, or RemoteAsyncService.PUSHING
Request r = new Request(...);
Callback callback = new Callback(){
 void newResults(Result[] result){...}
 // e should be null if finished correctly
 void requestFinished(RemoteException e){...}
}
s.search(request, callback);

И реализовать его на стороне ServerB

public ServiceImpl implements Service{
  void search(Request r, Callback c){
   // perform search, call c.newResult() when new results are available
  }
}

А остальное обрабатывается фреймворком, включая восстановление соединения, когда оно сбрасывается, переход к опросу / отправке, если потоковая передача не может быть выполнена из-за буферизации прокси, вызывая callback.requestFinished (), когда ServerB завершает работу или выдает исключение, и т.д. Вероятно, он также должен обрабатывать аутентификацию каким-то стандартным способом.

Итак, есть ли какое-нибудь решение, которое абстрагирует способ связи, и является ли способ потоковым, когда это возможно?

Если нет, как вы думаете, было бы полезно реализовать его как открытый исходный код? :)

1 Ответ

1 голос
/ 21 апреля 2009

То, о чем вы говорите, звучит как сервис COMET. Вы можете прочитать запись в Википедии здесь:

Комета (программирование)

Не уверен, как вы реализовали бы что-то подобное в Java, но в .NET вы можете использовать дуплексный контракт для службы WCF. Вы можете прочитать больше о том, как получить доступ и общаться с этим стилем обслуживания здесь:

Как: получить доступ к сервисам по дуплексному контракту

...