kasikРассматриваются высоко и среднепроизводительные решения, не на пять пользователей, поэтому EPG не подойдет, тк возможно не справится с нагрузкой на БД.

А возможно, что и справится. С десятью пользователями.

Давайте от сферических коней в вакууме перейдём к чему-то конкретному. Например, озвучим, что EPG не умеет сжимать файлы. И в нём нет встроенной поддержки expiry headers,

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

kasikПо поводу активного использования БД при работе с апекс - это даже не вызывает сомнения, тк все страницы и айтемы и еще куча всего находятся в таблица, и как же при этом не увеличиваются операции чтения/записи. В JSF БД используется только по назначению, то есть для получение выборок и других транзитивных операций, а в случае с апексом еще добавляются хранение метаданных как статичных(описание страниц) и динамических(текущая сессия). Что на это скажете?
Скажу, что проверку условий для отображения той или иной части страницы, авторизацию, зависящую от данных, вычисления, валидацию и прочее JSF, наверно, выполняет при помощи Божественной Силы, не обращаясь к БД. А APEX делает всё это за один PL/SQL-вызов.

Я не пойму, почему Вы решили, что хранение описания приложений в БД -- это аргумент не в пользу APEX. Используя JSF, я могу хранить приложение в воображении? Раскройте, пожалуйста, подробно недостатки хранения приложения и данных вместе.

kasikХорошо, Вы можете утверждать обратное?
Обратное чему ? "Некоторые статьи говорят, что GlassFish не подходит для продакшена с неизвестной, но большой нагрузкой," -- этому? Могу.
Возможности кластеризации .
Простой тест на 16000 пользователей .
Вот некоторые статьи говорят, что GlassFish надо уметь готовить, и тогда он вполне производителен.

kasikJSF ображается к БД только когда необходимо прочитать данные из нее, а APEX и еще когда формирует страницу.
Всё правильно, если не считать, что APEX обращается к пользовательским данным, когда формирует страницу. Не в дополнение, а в одном вызове. Попутно проверяя, нужно ли вообще обращаться к пользовательским данным, исходя из результата авторизации, выполнения условий и т.д.

Стоит задача: вывести три элемента страницы с информацией, если соответствующие каждому из них запросы вернули данные. Вопрос: сколько обращений к БД сделает JSF? APEX сделает одно.

Стоит задача: вывести информацию, которая вообще не связана с БД и пользовательскими данными. Вопрос: сколько обращений к БД сделает JSF? APEX всё равно сделает одно, и в этом минус.

Стоит задача: реализовать Long Polling в приложении. Вопрос: какие ресурсы потребуются в JSF? В APEX придётся пожертвовать одним серверным процессом на одну открытую страницу, что довольно дорого.

Вывод: Технологии надо рассматривать применительно к конкретным задачам, а не сами по себе. Сравнивать бензопилу и отбойный молоток без цели их применения -- весёлая, но бессмысленная трата времени.

kasikКакой-то халивар начинается!
Название темы это подразумевало.

kasikно хотелось в целом увидеть + и - обеих технологий, не касательно конкретной задачи
Для этого есть статьи евангелистов обоих технологий. Они любят писать захватывающие описания в отрыве от реальности. :)

kasikВы одинаково хорошо владеете обеими технологиями?
Нет. И поэтому я предлагаю вернуться с горних высей абстракции к насущным задачам и чётким критериям. Чтобы я мог сравнивать реализацию проекта на JSF с тем, что могу сделать сам. Например: http://habrahabr.ru/post/133980/ . 120 часов работы (15 дней) на 12 тяжёлых форм у джависта с 12 годами опыта в разработке браузерных GUI. Мне кажется, что-то чересчур ресурсоёмкая технология. Но это только один пример.

kasikПо вашему JSF вообще зло...
Нет. По-моему, нет добра в рассуждении о сферических конях в вакууме.

kasikкак допустим на апексе реализовать server push?(просто интересено)

Как насчёт отдельной темы? Чтобы не убавлять накала в здешнем холиваре.