Java web framework

щас тебе посоветуют спринг, собстно удивительно будто ты про него сам не знаешь?

В смысле spring-mvc? Или полный стек с заменой ejb3 spring-ioc? Второе не особо подходит, для бизнес-логики нужны всякие ынтырпрайзные фишки а-ля двухфазовые коммиты и XADataSource под них, JMS и MessageDriven бины, кластеризация всей этой хрени (с которой надо еще постараться взлететь) итд.

А хто его знает, мы решили не лезть в это дерьмо и обойтись JEE, ибо разобраться в этой каше тухнологий сможет не всякий, так чтобы уметь их адекватно применять, а остальные из этих кирпичиков выстроят монстра.

>и на ~1000 посетителей не надо было-бы ставить кластер из кучи крутых серверов

1000 посетителей в секунду?

Да я сам-бы с удовольствием взял какой-нить jsf и не парил бы себе моск, только вот одна проблема - оно сцукко с шаблонами сделанными веб-дизигнерами хреново коррелирует. И все реализации что я видел на тонких каналах хреново живут. А на сервис будут лазить часто через тот-же жопорез, где скорость передачи данных примерно равна скорости перемещения моей давно покойной прабабушки из комнаты в сортир.

В смысле ~1000 кликов в секунду?

>Да я сам-бы с удовольствием взял какой-нить jsf

jsp + ajax + прямые руки. А толстые технологии в любом случае будут жрать трафик.

>1000 посетителей в секунду?

Хм, я имел ввиду примерно 1к одновременно работающих пользователей (по факту их должно быть больше, но система изначально будет работать на кластере). В среднем от пользователя будет примерно по http-запросу раз в 10 секунд. Поэтому хотелось-бы чтоб одна нода кластера позволяла хотя-бы 100 запросов в секунду обрабатывать.

>jsp + ajax + прямые руки. А толстые технологии в любом случае будут жрать трафик.

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

> хотя-бы 100 запросов в секунду

Там какая-то сложная бизнес-логика? числодробилка на каждый запрос? Или я чего-то в этом мире не понимаю?

>Nagwal ** (*) (18.08.2009 23:08:10)

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

>Там какая-то сложная бизнес-логика? числодробилка на каждый запрос? Или я чего-то в этом мире не понимаю?

Да, много запросов будут числодробильными. Фактически любой запрос на изменение данных (а их будет дохрена) будет причиной перестроения 5-10 взешенных ориентированных графов по 700-1000 элементов в каждом.

>По моему скромному опыту, эти самые копатели наломают дров даже с самым защищенным от индусов фреймворком и рзгребать придется вам двоим.

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

JSF

> Да я сам-бы с удовольствием взял какой-нить jsf и не парил бы себе моск, только вот одна проблема - оно сцукко с шаблонами сделанными веб-дизигнерами хреново коррелирует

А как вообще шаблоны дизайна могут коррелировать с jsf?

> И все реализации что я видел на тонких каналах хреново живут.

А какое отношение между jsf и толщиной канала?

Чего-то я, видимо, не понимаю в jsf.

>А как вообще шаблоны дизайна могут коррелировать с jsf?

Элементарно. Дизайнер отдает мне сверстанный макет страницы с тестовыми данными. Моя задача состоит в том, чтобы с наименьшими потерями заставить framework выдавать аналогичный код на реальных данных.

>А какое отношение между jsf и толщиной канала?

Ну между спекой и каналом связи действительно нет, но представь себе все приятности пользования теме-же IceFaces при 14400bod ;)

>Хм, я имел ввиду примерно 1к одновременно работающих пользователей

ejb и производительность вещи совершенно несовместимые

> Моя задача состоит в том ...

Это я догадываюсь. Но это не ответ на мой вопрос. Я не понимаю, как они вообще _могут быть_ связаны?

А на 14400 bod умные люди заходят на wap.* или ищут "для печати". Или ты планируешь использовать ajax и там?

Я бы взял Tapestry 5. Приятное в нём то, что во-первых шаблоны из xhtml делаются легко, а во-вторых, он, в принципе может жить практически без сессий (а значит, stateless со всеми вытекающими плюсами дл производительности). Хотя для этого надо хорошо понимать как он работает, чтобы знать, что отключать.

JEE вообще выкинул бы нафиг.

Кластеры, JMS, и.т.д делается не хуже и на альтернативных технологиях (те же Spring/Apache ActiveMQ и Apache Camel для связей между бинами). Для обработки больших объёмов данных можно всякие Hadoop/GridGain/и.т.д без проблем заиспользовать (если, конечно, алгоритмы позволяют).

Единственное, что отдельный JTA — это проблема. Есть http://www.atomikos.com/Main/TransactionsEssentials, но я его не вкручивал. С другой стороны, двухфазные транзакции могут быть и не нужны (например, вот http://activemq.apache.org/should-i-use-xa.html). То есть важно понимать, что это никакая не магия и жить можно и без них (осознавая возникающие при этом проблемы).

А в кластеры JEE серверов никогда не верил. Оно, конечно, красиво на бумаге, но как-то больно тяжеловесно получается.

>Я бы взял Tapestry 5. Приятное в нём то, что во-первых шаблоны из xhtml делаются легко, а во-вторых, он, в принципе может жить практически без сессий (а значит, stateless со всеми вытекающими плюсами дл производительности). Хотя для этого надо хорошо понимать как он работает, чтобы знать, что отключать.

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

>JEE вообще выкинул бы нафиг. Кластеры, JMS, и.т.д делается не хуже и на альтернативных технологиях ...

Судя по моей практике оно однофигственно тяжело получается, что j2ee, что на томкат накрутить кучу сторонних библиотек. В свое время я рботал со связкой tomcat(аки основной сервак)+spring(как ioc)+tapestry(как веб морда)+terracotta(для кластеризации)+куча самописных костылей и мелких библиотек. Оно точно так-же медленно и печально работало.

>двухфазные транзакции могут быть и не нужны

Ну в моем случае они все-таки нужны. По бизнес-логике постоянно случаются задачи коммита в базу и отсылки сообщения сторонней системе. Или коммита в две базы одновременно.

>А в кластеры JEE серверов никогда не верил

Да я вообще не верил в свое время в кластеры чисто на джаве, потом поработал с ним и понял что оно работает ;)

>А на 14400 bod умные люди заходят на wap.* или ищут "для печати". Или ты планируешь использовать ajax и там?

Нет, там я аякс использовать не собираюсь, да и вообще желательно его поменьше юзать. Банально хочется чтоб не очень умные люди, зашедшие на сайт с жопорезным инетом, да еще и при плохой связи хоть как-то но могли работать.

>ejb и производительность вещи совершенно несовместимые

почему?

>Судя по моей практике оно однофигственно тяжело получается, что j2ee, что на томкат накрутить кучу сторонних библиотек. В свое время я рботал со связкой tomcat(аки основной сервак)+spring(как ioc)+tapestry(как веб морда)+terracotta(для кластеризации)+куча самописных костылей и мелких библиотек. Оно точно так-же медленно и печально работало.

Думать-то, конечно, в любом случае надо :)

Terracotta — не очень хороший вариант, т.к там есть такое понятние, как сервер, который может стать узким местом.

Лучше уж share nothing approach, тогда ничего синхронизировать и не надо будет.

Там любой пук идет через corba и тп.

>Там любой пук идет через corba и тп.

Не через CORBA, а протокол RMI.
RMI-IIOP, действительно, для CORBA-совместимых вызовов в EJB.
А, вот, RMI-JRMP является более быстрым протоколом обмена.

JBoss Seam

>Там любой пук идет через corba и тп.

Насколько я помню, при использовании local бинов никакой сериализации-десериализации не происходит, как и при дергании спринговых бинов.

>Лучше уж share nothing approach, тогда ничего синхронизировать и не надо будет.

Ну сессии точно придется шарить, поскольку там довольно много всего храниться будет (всякой промежуточной инфы, которую в базу пихать не надо, ибо не нужна она там).

>JBoss Seam

Насколько я понимаю seam это скорее controller, меня же больше view интересует.

http://tiles.apache.org/framework/index.html

Ага, пасиб, посмотрю.

Seam как таковой служит для оркестрации компонентов и облегчает увязывания слоя EJB с view. Вообще, это view+controller. Что касается view, то исходно сим использует JSF (из коробки + RichFaces c Ajax4JSF) + Facelets (кстати, Facelets куда удобнее Tiles). Что это дает? Вместо тэгов JSF можно пользовать почти чистый xhtml. Удобный темплейтинг, настоящее повторное использование элементов страниц, хороший механизм расширения, плюс симовская навигация, которая тоже куда как приятнее стандарной JSF. В принципе же JSF там вовсе не обязателен - можно использовать, например, Wicket, который тоже все это умеет, а по расширяемости и удобству повторного использования кода даже лучше, чем Facelets.

Если очень хочется терять время. Tiles уж очень архаичен. Если только не захочешь писать на Struts 1 - там выбора мало - либо Tiles, либо Sitemesh.

>Seam как таковой служит для оркестрации компонентов и облегчает увязывания слоя EJB с view. Вообще, это view+controller. Что касается view, то исходно сим использует JSF (из коробки + RichFaces c Ajax4JSF) + Facelets (кстати, Facelets куда удобнее Tiles). Что это дает? Вместо тэгов JSF можно пользовать почти чистый xhtml. Удобный темплейтинг, настоящее повторное использование элементов страниц, хороший механизм расширения, плюс симовская навигация, которая тоже куда как приятнее стандарной JSF. В принципе же JSF там вовсе не обязателен - можно использовать, например, Wicket, который тоже все это умеет, а по расширяемости и удобству повторного использования кода даже лучше, чем Facelets.

Ок, пасиб, на seam посмотрю. Руки на практике до него как-то не доходили, я вообще для веба не так много писал (на джаве либо на голом jsp+servlets что было года четыре назад либо на пятом tapestry) По работе гораздо больше сталкивался с ejb+webservices которые дергались толстыми клиентами на eclipse platform, swing а в основном вообще .net. Хотел сначала не париться выбором фреймворка, а ту-же тапестрю взять, но больно у нее все печально с документацией было, когда я ее юзал (а в проекте будет народ, который ни с вебом, ни с джавой не работал). С гловой и программингом у народа все хорошо, но вот с джавовскими технологиями не ахти, поэтому и хочется совета насчет наиболее безболезненной технологии.

На facelets тож посмотрю, спасибо за совет. Поскольку насколько я jsf понимаю - там свой набор тегов, отличный от (x)html, а дизайн будет вообще заказываться у сторонней конторы, которая отдаст набор html+css страниц с гарантией того, что они нормально под ie, firefox, opera и safari отображаются. И хотелось бы наименьшего геммороя программерам с попытками сгенерить аналогичную разметку.

> Если очень хочется терять время. Tiles уж очень архаичен. Если только не захочешь писать на Struts 1 - там выбора мало - либо Tiles, либо Sitemesh.

Ну уж нет, спасибо, смотрел я на первый стратс. Такого ужаса не надо, я из проекта сбербанковского, использовавшего его меньше чем черз месяц сбежал (там правда еще и ejb 2.1 был, и Rational app Developer for WebSphere), до сих пор с содроганием вспоминаю.

JSF + Facelets позволяют (почти) не использовать теги jsf, точнее так - эти теги уползают в дополнительные атрибуты.

Например, вместо

<h:outputText value="#{myBean.prop}"/> 

можно просто

<span>#{myBean.prop}</span>

а вместо

<h:inputText value="#{myBean.input}"/>

будет

<input type="text" jsfc="h:inputText" value="#{myBean.input}"/>

Одно большое но. Если знания JSF нет, а для проекта сроки более или менее жесткие, лучше взять что-то другое - тот же Wicket. В плане дружелюбия к разметке он ничем не хуже, а осваивается быстрее. Достаточно одной книги - Wicket in Action для Wicket 1.3, а она даже не очень толстая.
У викета тоже куча вкусного - разумный подход к деградации аяксовых компонентов, размер сессий значительно меньше, чем у jsf, хорошая компонентная модель и т.д. 

Помню, мы для POC конвертировали jsf в викет - просто сохраняли страницу из браузера, вычищали грязь,
добавляли wicket:id куда надо, ну и писали явовский код, разумеется.

У Tapestry до сих пор все печально с документацией - по пятерке одна что ли книга, причем по 
бета-версии, несовместимой с релизом.

>Если знания JSF нет, а для проекта сроки более или менее жесткие, лучше взять что-то другое - тот же Wicket.

хм, смотрел я на wicket году где-то в 2006-м, тогда он мне не особо понравился, не помню уже чем... Сейчас еще разок гляну, может и получше пойдет, практики с тех лет все-таки побольше стало.

>У Tapestry до сих пор все печально с документацией - по пятерке одна что ли книга, причем по бета-версии, несовместимой с релизом.

А вот это жалко, сам то по себе фреймворк не самый плохой.

>У Tapestry до сих пор все печально с документацией - по пятерке одна что ли книга, причем по бета-версии, несовместимой с релизом.

Я бы так не сказал. Книг нет, но на сайте документация, на мой взгляд, отличная. Плюс исходники легко читабтся.

Нет. Локальные вызовы корбу не используют со времен появления локальных интерфейсов. До этого аппсервера оптимизировали вызовы, не используя RMI, если вызывающий и вызываемый работали в одном инстансе аппсервера. Да, и аппсерверы поддерживают (но не обязаны использовать) реализацию RMI поверх IIOP, но IIOP - это еще далеко не вся корба.

Мне вот интересно что это за бизнес логика у тебя такая, что обязательно тебе так нужен ejb.

>Мне вот интересно что это за бизнес логика у тебя такая, что обязательно тебе так нужен ejb.

Ну не то что бизнес-логика, просто JTA, Web-services, jms и clustering из коробки очень уж привлекательно смотрятся.