Ну, и ТЗ у вас в лесу.

silvanЗАДАЧА: необходимо дергать web-сервисы и полученные ответы отображать в веб-приложении

ОК.

silvanотчет будет браться несколько тысяч раз в сутки.maxheap=1.5Г. данных может быть много.

Как слово "отчет" связано с ЗАДАЧА, не понятно.
Нет такой оценки количества как "много".
Несколько тысяч раз в сутки это, ну 5000 максимум. Итого 17 секунд на каждый запрос. Так? Это же дофигища времени. Или может таки подумаем о пиковых нагрузках, а не о количестве в сутки?

silvanподдержка IE обязательна.

IE это несколько разных движков. Обычно говорят о поддержке IE6 и крутят пальцем у виска. Проблем поддерживать версии IE посвежее нет. Как HTML верстка связана с размером кучи и web сервисом мне не понять.

silvan1) SpringWS-jaxb-classes-jsp (имеется некоторый опыт, боюсь сервер поляжет от OOM)
2) получить xml-ответ, преобразовывать при помощи xsl в html на сервере и гнать клиенту
3) получить xml-ответ, добавить ссылку на xsl и гнать клиенту, пускай браузер преобразует

Я бы начал с обычного JAX-WS, реализация которого уже есть как в JSE, так и в любом JEE контейнере. И в случае чего перешел на CXF.
XSLT - зло, которое нужно давить в зародыше. Что такое "много данных" вопрос открытый. XML нормально стримится и потребление памяти упирается в объекты, которые вы вычитали. Опять же не обязательно читать весь XML, можно лишь только нужную часть. Хотя, возможно, и не средствами JAXB.

Без знания предметной области, сложно советовать куда воткнуть кеш. Но он тут явно просится. И может даже не один.

вадявозьми websocket и можешь расчитывать на десятки тысяч в сутки.
для ie10- есть эмуляторы на флэш.
Поддерживаешь имидж?

вадяесли делает с нуля - почему не предложить?
Нет, ну вариант, конечно. Только браузер умрет рендерить, если данных много. Срендерить жирный статический HTML на сервере проще.
Ну, и SOAP к web-socket вообще отношения не имеет.

silvanотчет - это обработанный ответ сервиса, выданный на экран пользователя посредством интернет обозревателя в виде ХТМЛ (в дальнейшем возможно Excel) таблицы.
С этого и надо было начать.


silvan АГА...УГУ...
"Неопределенно" много для нас значит, что значение стремиться к бесконечности. А значит единственное решение это обрабатывать данные потоком. На входе поток XML, на выходе HTML. Тогда желание использовать XSLT понятно. Некоторые реализации умеют стримить.

silvanориентир 16000 в сутки. потенциально все могут прийти к началу отчетного часа и запросить в течении получаса.процент попадания в 1 минуту не известен, пусть будут ваши 5000.
время отклика для пользователя 3 сек.
Сколько удивительных подробностей всплывает. Это, ведь, уже предметный разговор. Несколько уже превратилось в 16, а много в 400Мб. Чего было скрывать?

silvanпарсим хмл - загоняем в память докумет для чтения, создаем объекты в которые складываем результат парсинга.
пока jsp/сервлет не сфлушила результат документ где храниться? отчеты формируются динамически,наработка htm-файлов заранее не возможна.
Документ читать в память не нужно. Его можно читать и парсить порциями. Но все реализации сериализации, которые я знаю вычитывают сразу все объекты (кроме Apache Commons Digester). И сколько памяти нужно под ваши объекты, это вопрос к вам. Если много даже в объектах, то сериализацию надо выкидывать нафиг и парсить SOAP Response самостоятельно.

silvanCXF - в свое время не удалось подружить с некоторыми версиями Websphere Application Server. на нем все будет крутиться (версии от 6.1 до 8.5.5)
Вот и я о том же. А мы много лет назад набодались пытаясь запустить Spring WS на WAS CE. С таким сервером проще смириться и взять его реализацию.

silvanа мне тоже никто не скажет. есть вот респонс на 400Мб чистого текста.нужно ли это выплевывать все разом пока не известно

SOAP Response в 400Мб? Какой чудесный сервис. А он вообще как нагрузки держит?

silvanгде почитать?
Google -> Java SAX parser и Java StAX parser. Второй, вроде как, удобнее.

silvanа какие есть варианты?
Вычитывать данные периодически и складировать локально на HDD. В фоновом режиме конвертировать их в HTML и держать на том же HDD. Отдавать клиентам уже готовый файл. Это если клиенты (запросы) могут пере-использовать данные друг-друга, то эти самые данные имеет смысл и хранить в подготовленном состоянии локально, а не читать и обрабатывать на каждый запрос.

Если же каждый из 16К запросов требует абсолютно уникальных данных, то стриминг - единственный вариант. Либо XSLT надо взять, который умеет, либо самому SAX парсером в HTML загонять, используя минимальное количество памяти под буферы.

silvanЖирный html + IE:
когда процесс IE на клиенте дойдет до 2гб , запуститься новый процесс IE который пошлет новый запрос... и так будет до тех пор пока не умрет клиент и/или сервер.

проверено.
вес ХТМЛ не мерял, процесс в хрома сожрал 600МБ.
отправлял простую хтмл-таблицу без ЦСС и Яваскрипта

Вы нас тут запутать решили? Вы хотите клиенту отдать в браузер гигабайты оперативных данных? И он их глазами будет смотреть?

silvanинстаграм,фейсбук, гугл поиск....все гонит данные на клиент пока ему не надоест.количество пользователей этих приложений говорит о том, что вы не правы.
Объем текстовой информации в указанных сервисах не дотягивает и до десятка мегабайт на запрос. Изображения и видео отдельная тема, ведь у вас их нет?

silvanсохранять на диск

респонс или хтмл?
В идеале и то и другое. Я же не знаю вашей предметной области и не могу за вас это решить.

silvanвозможно единичный случай и остальные респонсы будут много меньше.
Опять неопределенность.

silvanок.теперь мне нужно понять как.
Ключевое слово Streaming

silvanавторНо все реализации сериализации, которые я знаю вычитывают сразу все объекты
Это о чем? как относится к парсингу?
Вы указали JAXB как вариант решения. JAXB не грузит документ в память. XML он парсит потоком (streaming).
А вот объекты, которые он из этого XML формирует, они уже будут в памяти целиком.
Если 400Мб XML это единичные случаи, то подобный SOAP в объектах может занимать на порядок меньше места, что вполне нормально. А вот если у вас сотни запросов в секунду и многие парсят 400-метровые ответы, то с памятью уже будет не так всё гладко.

silvanя, нет.
размер ХТМЛ документа не равен размеру ОП выделенному процессу интернет обозревателя под обработку и отображение этого документа
Так-то верно, но если у вас текстовые данные, то пользователь не способен проанализировать такой объем информации. Так почему бы не отдавать ему её лишь частями?

silvanавторИ он их глазами будет смотреть?
и печатать, и сводить с другими данными.искать расхождения и прочее.
400Мб текстовых данных в один экран и потом сводить?

silvanна реквест передаются параметры, если послать аля select * ,то возможно будет кирдык.
там где сервис дергает автомат, респонс маленький, т.к. параметры точные. Но у меня будет человек который будет смотреть в формате "а что там было с - по"
Дык может в фоновом режиме читать SOAP сервис и хранить данные в удобном для анализа варианте? OLAP?

silvanа в результате бесконечный документ!
Рукалицо. Гугл тебя временно забанит за несколько запросов, которые выдадут достаточно длинный документ. Это раз.
Клиент не получает весь документ за раз. Только порциями. Сформированный и подготовленный выхлоп лежит на сервере. Это два.