Думаю, что умер он исключительно по маркетинговым соображениям - переориентацией сайбеса на яву.

Денежек это действительно стоит Хотя и немного. Мы енто покупали :) PHP было бы супер, но сайбес с ним не работает. А так как ягуар для WEB DW все равно нужно покупать - заменять JSP на PHP пока не вижу смысла

Я не предлагаю смотреть Динаму - она уже умерла. Веб ДВ делается на JSP-ASP + JAVA-Билдерные компоненты. Сами выбирайте

Зоопарк только на первый взгляд. Посмотрите их портал и все поймете (надеюсь). В этом и вся фишка, что сайбесовский портал позволяет интегрировать практически любые технологии в себя. Посему, вы куски можете делать на чем угодно, что очень удобно для больших компаний. У них в штате спецов - вот уж точно зоопарк... Что сайбез на своем портале и демонстрирует. У них же портал свой - судя по всему полигон по обкатке новых технологий :) Это же позволяет интегрировать старые сайты их не переписывая... эволюция корпоративного сайта в действии... :)

"...упоминание statefull компонентов и актуальности вопроса масштабируемости нагрузки в одном абзаце есть оксюморон... "
в корне не согласен. EAS легко мастабируется в программный кластер достаточно большого размера без потери в функциональности, чего нельзя пока говорить про большинство СУБД. Может ситуация с Оракл 10g что изменится. Да и СП появились в основном в задачах снижения нагрузки на СУБД.

Ох Филипп... ну и любите же вы спорить. Никто не сравнивает СУБД и СП... у них разные задачи, о чем и пытаюсь Вам сказать, если Вам нравиться "тонкий" EAF и терпеть не можете слово statefull - Ваше право, давайте не засорять топик.

А для интересующихся приведу пример использования пресловутых statefull компонент с Ягуаром. Более точно, обстоятельно и подробно Вам его опишут в российском представительстве сайбес. Это был проект со сбербанком. У них была система (клиент-сервер), написанная на билдере + MS SQL сервер. Нагрузка на систему была приличная. Насколько помню, сервер начинал валится при 400 активных коннектов (точные цифры к сайбесу). СУБД менять было нельзя (ни железку ни MS SQL) - такие условия. Надо было держать уверенно 1200-1300 коннектов на том же сервере. Вот они это и сделали из кластера машин в 10 под Ягуаром. Насколько знаю и тестовые испытания и само внедрение прошло успешно.
Для снижения числа коннектов, либо нагрузки на сервер как раз и можно пользоваться компонентами на ягуаре, иногда именно statefull компоненты помогают значительно снизить нагрузку, так как хранят часть(все) требуемые данные на СП и не требуется обращаться к СУБД для получения результата. Stateless компоненты также позволяют в некоторых случаях снизить нагрузку на СУБД. Больше мне по этому поводу сказать нечего. Если будут вопросы по этой теме - обращайтесь плиз по почте.

Вот и я этот вопрос задавал Филиппу, а он вместо ответа изголяется в литературном жанре. По его словам, это реализовано в EAF. Так как доки по нему нет (а то что есть нельзя считать норамльной документацией для разработчика системы на базе EAF), посему разбираюсь с их сорсами в свободное время.

Для себя выделил только 1 способ работы DW со stateless компонентой - сохранение образа DS в базе данных. Попытки же хранить информацию в hidden полях без сохранения последнего retrieve DS считаю неверными, так как context содержит изменения буферов с привязкой к номеру строки. Соответственно легко строится пример, когда модификация БД может привести к ошибке. Так только можно строить, если знаешь уникальный ключ записи и привязываешь изменения к нему. У сайбеса это не реализовано.

Лично мне этот способ пока не очень импонирует по сравеннию с использованием statefull компонент, так как сильно нагружает работой СУБД да еще работой с блобами.

Резюмируя: известно 2 способа работы с DS удаленно, если кто знает еще какие, прошу их описать на пальцах. Да и так как это интересует не только меня, прошу Филиппа и других участников не засорять топик словоблудием, а отвечать по существу. А ежели нечего кроме зубоскальства сказать - предлагаю просто промолчать, как в том известном анекдоте :)

С Уважением....

Имеет место быть, только размер его будет всеж таки не маленьким. Посему все равно в блобах храниться будет. А выбор варианта блоба - это уж будет зависеть от выбранной СУБД.

Тут дело не в чем хранить и как представлять DW в БД. Вариантов много... Основное, что не нравиться, что массив данных будет некислым, а посему и трафик будет приличной и нагрузка на сервер. Правда, для этих целей можно ставить отдельный сервер-СУБД-БД. Тогда нагрузка к информационной СУБД и СУБД поддержки сессии практически не будут коррелировать. Надо подумать.