Нужно реализовать сервис который генерит и возвращает огромный массив строк. Если сделать что-то вроде этого:

То на сколько я понимаю клиент вынужден будет ждать пока не закончится формирование всех строк и только потом получит их все махом. Как сделать так, что бы можно было бы кидать сгенерированные данные в поток не дожидаясь завершения генерации?

Через обычный servlet.
Берете response.getOutputStream и бросаете в него свои данные. 
А они будут уходить юзеру на лету, по мере наполнения OutputStream.
Когда данныеч закончатся, тогда поток закроется (то есть вы его закроете)

PS: а через вебсервис (вроде как) не получится. Потому что при формировании ответа jax или jaxb или кто у вас там будет проверять формат ответа на валидность, а пока он не будет полностью закрыт, он не будет полностью форматирован, т.е будет невалидным. Такая фигня. 

Это сообщение отредактировал(а) afon - 10.2.2010, 13:04

С такой проблемой сталкивался. Идейно было несколько решений.
1. Сервис А, который возвращает одну строчку из этого массива, а само собирание массива происходит в Bpel через Foreach для сервиса А. Bpel соответственно будет являться искомым результатом.
2. Возвращаем сервисом нечто

где <Array> - наш собственный complex type тег, а item соответственно String.
3. Возвратить этот массив в виде одной строчки с каким-то разделителем, а потом где надо разобрать и собрать.

   Моим решением, как ни странно стало 3ее, т.к. существующие сервисы работали до этого с файлами и имели встроенные парсеры, потому необходимо было лишь дать им на вход массив запакованный по знакомым им правилам.
   На мой взгляд, хорошим решением является 2ое, но терзают смутные сомнения, что подходящим полностью под SOA принципы будет 1ое решение.
   В общем, жду продолжения дискуссии, а то она тут какая-то неоживленная, хотя проблема очень частая.

Принцип формирования целиком ответа и отправление его клиенту как единое целое имеет основания. Так проще контролировать процесс пересылки. Если при передаче ответа случился сбой (соединение разорвалось, например), то клиент должен выкинуть уже полученную часть данных и повторить опять запрос. Запрашивать только недополученные данные нельзя если данные динамические. По этой причине клиент не может  обрабатывать или отображать данные, т.е. применять по назначению, пока они не получены полностью. Иначе "откатывать" назад будет сложно. Поэтому клиент тоже копит данные, пока не получит их все.

Если ответ большой, а сетевое соединение ненадежное, то пересылка ответа может никогда не закончиться. Поэтому при проектировании системы, работающей через интернет, желательно стремиться к тому, чтобы ответ на запрос был не большой и не маленький.  Не маленький по сравнению с размером пакета tcp. И не большой настолько, чтобы у всех клиентов хватало памяти их буферизировать и чтобы свести к минимуму повторные запросы. 

Не надо передавать "огромный массив" совсем. 



Это сообщение отредактировал(а) COVD - 25.2.2010, 22:17