Хочу вот сделать проект на J2EE типа интернет магазина, но более навроченного, в смысле функционала, типа там управление заказами, складом еще. Вроде не PHP уже куча таких написано, но я задумался , если напистаь на j2ee технологиях, то наверняка выйдет гораздо эффективней, и можно будет с легкостью расширять. Может кто учавствовалв таких разработках,  посоветуйте, гиблое дело? Может кто хочет помочь чем? Или самим принять участие, попрогать в свободное(или не свободное=) ) от работы время. 
Не думайте что ламер, с j2ee опыт работы 2 года в крупной компании. Просто свободное время хочу чем то занять и подзаработать может немного=)
Забыл сказать, сделал небольшой сайтик, не ругайте сделал за пару дней. Особой инфы там нет, но почту мою можно найти, если что. 
на русском (почти)
http://wad.rt.mipt.ru/rus/
или на английском
http://wad.rt.mipt.ru/
 

Простите за оффтоп...

как меня злит что  интернет магазины считают простым и примитвным вэб приложением....
наверное потому что последние 5 лет я занимаюсь разработкой и поддрежкой движка для этого.
серьезный вэб магазин это крайне сложный проект господа... странички по которым вы бегает покупатель  это 1%. это вершина гиганского айзберга... там столько всего... интеграция с внешними сторроними сервесами (провайдеры кредитных карт различным различных типов, риск менеджмент системы, гибкая валидация почтовых адресов, валидация банковских счетов, онлаин кредитование, внутринние поисковые движки и хрен знает что еще). контент менеджмент система в 5 раз большая по размеру чем сам магазин, ERP система с которой вам нужно организовать oбмен данными, причем близкий к real-time, механизмы обмена данных с партнерами (у нас в день ~200 файлов различной структуры и формата  генереруются и распихиваеть всевозможными способами по пратнерам (SSH,FTP,mail)). краулеры конкурентов и прайс порталов(вы знаете что такое ценовые войны хи-хи? - ваша система должна драться и побеждать  ) маркетинг-тулс: всякие бандлы, хайлайты и т.п. репорты (количетсов репортов в 3 раза больше чем количесвто страниц на магазине).  а логи...  вы понимаете что вам хранить и анализировать каждый клик надо? это притом что у вас один средненький  магазин запросто может выдавать полмилона кликов в сутки. а оптимизация под поисковые движки? для того чтобы краулер гугла ходил по вашему магазину 10000 раз в день надо сделать столько что...
да только мониторг система которая следит за всеми этими процессами и в случае аврала рассылает по email и SMS warning-и месяцы разрабатывалась...

это я даже половины не перечислил всего.

по теме: да, черт побери, все это написано в рамках J2EE причем без EjB (полностью и сознательно). и  при этом системы не требуют никакого особого железа и кластеров у нас даже HTTP лоад балансера пока нету.
и да, хрен вам на PHP это написать всё. никаких шансов. некоторые задачи просто принципильно не реализовать - нету в языке нужных возможностей...


 

Дык никто и не говорит что легко=)
А без EJB будет сложно разделять модель системы и ее управление.  Тем более если это все так сложно так почему бы не использовать Ejb, Web services, что упростит и интеграцию и управление и хранение данными. А писать на tomcat+mysql(например) это гиблое дело, j2ee разрабатывалась не для этого и центром ее является ejb.
А пара страничек это и не проект, это хоумпага, типа того сайта че я сделал за пару часов.
А посмотрев несколько интернет магазинов я увидел что они все написаны на PHP , и никакой интеграции эти решения не предлагают, максимум с платежными системами. 

Выбросьте на помойку все что вы читали в рекламных обзорах про EjB. реальная жизнь она отличаеться от "пропихивающего" маркетинга. что вы понимаете под "разделять модель системы и ее управление", кстати? 
Кто сказал что паттерн MVC невозможно реализовать без технологий распределенного программирования, например???
Или что хорошее маштабирование системы нельзя достич без технологий распределенного программирования??? - простейший HTTP лоад балансиг по IP (именно по IP, даже не по сессии) даст тебе замечательные возмозношти маштабирования для вэб-сайта. Почему вы решили что использование распределнного программирования упрощает управление и хранение данных? 

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

А EjB не используеться потому что за это надо платить ресурсами железа и как следствие производительностью по-полной. (а в то время когда мы начинали надо было платить вдвойне, последний стардарт J2EE надо сказать лучше, а тогда о идеях Hibernate никто не слышал ещё.) и это не пустые слова. 5 лет назад мы за сумму с тремя нулями в вечно зеленых купили недельный трейнинг по-поводу EjB у широкоизвестной фирмы. мы знали EjB но нам нужны были цыфры. и нам их дали. нам расказли много интересных примеров и сказали на каком количестве entity бинов намертво умирют 4-Х процессорные саны и много чего еще. мы приняли решение - не использовать и до сих пор уверены что были правы.

J2EE фключает в себя множество стнандартов. мы не используем (или почти не используем - MDB и очереди сообщений используем) javax.ejb, но мы используем в полном объеме сервлеты, mail, xml. Так что нам теперь нельзя говорить что наши приложения на J2EE основаны?

Что касается вэбсервисов то мы их активно и много используем(и вообще я лично большой поклонник). Мы строим на их основе интерфейсы синхронизации данных например между разнородными системами, но только там где производительноcть не крична. и вэбсервесы отношения к распределенному программированию вообщем-то не имеют(это изначально технология обмена xml-документами, а не технология удаленного вызова объектов, методов и т.п.), хотя почему-то всегда смешивают.

но. возвращаясь к теме топика. на java/J2EE вы сможите построить распределеную систему любой сложности в рамках одного языка программирования. на PHP - нет. и когда ваша система расрастеться до десятка и более  совершенно различных программ работающих на разных серверах и далеко не все из них "web" тогда вы поймете что тот факт что абсолютно всё написано в рамках одного языка программирования и одной технолоиги вам жизнь просто спасает с точки зрения поддрежки.... 

Если ты не использовал то ты конечно можешь выкинуть на помойку все что читал=) Кроме MVC еще куча паттернов, каждый проект это свой отдельный гибрид из существующих паттернов и кучей мусора, и чем меньше мусора тем лучше все разложено по полочкам в проекте, тем легче его расширять и защитить(например), в больших случаях это быстрее. ejb позволяет забыть о таких вещах как управлением транзакциями, защищенностью. MDB позволяет сделать очень гибкие ассинхронные системы. Я знаю несколько проектов и организаций которые предпочитают использовать MDB. Я например не представляю как без них организовать отложенное выполнение(как например в workflow) причем чтобы все было в одной транзакции, а если еще в распределенной?
На счет разделения здесь очень четкая грань, ты конечно можешь сувать логику в entity beans , но ты сам быстро поймешь что это плохое решение. ejb стандарты позволяют почти на автомате писать бизнес логику и настраивать модель отдельно. 
И не надо путать распределенное программирование и разбиение MVC.  что я понимаю под разделением? мне даже сложно представить как это смотрелось бы всместе. Что будет когда в написанной системе тебе захочется добавить столбец в таблице, тебе придется перелопатить, исправить и оттестировать весь код заново. В ejb ты отделаешься только добавлением одного абстрактоного метода. Не говоря уже что будет если тебе придется менять какой нибудь relation. А если у тебя около 2000 типов данных? ты либо ляжешь в психушку либо обанкротишься. Ejb четко разделяет два слоя но и позволяет избавиться от рутины работы с базой, ты конечно можешь писать свои классы DAO или что-нибудь подобное, но зачем изобретать велосипед. А если тебе нужно будет для некоторых методов отдельная транзакция, а для других тебе надо будет чтобы обязательно уже было создана, и т д. А если еще надо будет ограничить доступ для отдельных ролей? Написав это все ты просто заново перепишешь реализацию ejb. А как организовать ассинхронную доставку сообщений причем в транзакциях. ejb позволяет еще много других вещей, я только упоминаю самые основные с которыми сталкиваюсь каждый день, и реализовывая большие бизес методы, всегда думаю а чтобы было если бы мы все делали голыми классами, наверное программисты бы уходили на пенсию лет на 10 раньше и зарплата была бы у них на порядок больше.
Конечно иногда приходится переносить бизнес логику из бинов в хранимые процы, но это только самые критические участки, где нужна огромная производительность. Но если бы все оптимизировалось под производительность все бы мы писали бы на асме.  

мы о чем говорим? мы о вэб магазине говорим. где у ваc там необходимость разграничения прав? где у вас там распределенные транзакции? где у вас там транзакции вообще - это преложение 99.5% запросов к которому это запросы на получения данных а не на их модификацию. причем получать данные вы должны экстремально быстро. потому что у вас на пике 10-ки запросов на получение данных в секунду. вам нужны эксремальные механизмы кэширования а не распределенные тарнзакции это я вам говорю с высоты многолетнего опыта в этой области. 

да мы писали собственный DAO слой. 3 дня.  у нас простой и очевидный механизм разделющий бизнес локигу и получение или модификацию данных и нету ничего сложного в том чтобы такой механиз написать. немножко рефлексии и немножко патернов типа абстрактой фабюрики и всё и не нужно тут EjB. да у нас все убрано в сторед проги. вообще всё. нету ни одного запроса к базе без сторед процедуры. правда там очень мало бизнес локики просто запросы зачастую весьма сложные зачастую с использованием специфики конкретного SQL servera. вы разумееться можете не использовать оптимизацию такого уровня на уровне SQL сервера, но это будет стоить вам 10-ки % производительности. вы конечно можете закрыть на это глаза и просто воткрунь железо по-мощнее но вам тогда никогда не удасться разместить 10 магазинов с суммарным траффиком в несколько милионов запросов динамических страниц (и несколько дестяков милионов запросов на HTTP сервер) на 2-x серверах (один из которых SQL) 

Есть фирма которая попыталась написать движок для магазинов на EjB. Intershop. гибко и приятно, а также дорого  и рксурсоемко. очень. мы испытывали.
 

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

Что касается модели и управления (видимо, бизнес-логики), то не понял в чем непосредственная связь их с EJB. Пишем обычный POJO-класс BlaBlaModel и опять-таки обычный класс BlaBlaAction. В первом организуем атрибуты модели, а второй будет этой моделью управлять. Вот оно, дерево, а вот мужик в пиджаке. Утрирую конечно, но правильная реализация программного кода скорее зависит от кривизны рук чем от EJB. Вот в общем-то и все что нужно. Ах да, забыл. Хорошо бы иметь того человека, который бы рассказал и показал как достигнуть простой поддержки системы, высокой производительности и т.д. и т.п.  Встречаются такие не часто, а группами вообще только у нас на форуме.  А если уж нужно компоненты организовать, возьми какой-нибудь lightweight container (Spring, PicoContainer), не обязательно для этого тяжелую артиллерию применять. 


Знаешь, wadissimo, каково бы ни было твое мнение на этот вопрос, но существует множество решений, работающих на Tomcat, Resin, Jetty, Weblogic и не использующих EJB. Об одном из них ALKS уже рассказал и поверь мне, это далеко не единственный пример. J2EE включает в себя не только EJB, это и JNDI и JMS и другие стандарты, которые реально нужны при разработке больших систем, но вот EJB я к этой категории не отнесу. Видишь ли, у меня немалый опыт разработки с использованием EJB, начинали еще в 2000 году. Но тогда не нашлось того самого человека, который бы подсказал как и что делать, да и где его было взять, живем-то в 5000 километрах от Москвы. В итоге имеем две системы с совершенно неоправданным использованием EJB и необходимость их поддержки. Я понимаю прекрасно что существуют ситуации, когда использование тяжелых технологий необходимо, но это должно быть взвешенное решение, принятое с пониманием того, какими издержками это все грозит.


Знаешь, решается просто, опять-таки грамотным построением кода, использованием паттернов. Сами Entity EJB можно заменить на какую-либо библиотеку объектно-реляционного отображения (Hibernate, iBatis и т.п.), которые гораздо легче в смысле нагрузки на железо и гибче в плане программирования.


wadissimo, не стоит допускать таких выражений в адрес своих коллег. У ALKS опыт разработки как минимум не меньше твоего и в любом случае нужно уважать его как человека.


Знаешь, ты ошибаешься по поводу сложности реализации всего этого другими средствами. Более того, в EJB это часто сложнее. Декларативное управление транзакциями есть в Spring и далеко не всегда оно необходимо. Система безопасности может быть реализована с использованием AcegiSecurity. Причем эти библиотеки предоставляют более гибкие средства для решения того же круга задач.

wadissimo, хотелось бы услышать от тебя более четкое обоснование использования EJB. Опиши, пожалуйста те системы, в разработке которых ты принимал участие, их архитектуру, и почему было принято решение остановится на EJB. Это очень интересно, я в своей практике ни разу еще не встречал систем, в которых использование EJB выло реально оправдано.   

Это сообщение отредактировал(а) tux - 28.4.2006, 15:21

мне хотелось бы получить концептуальное понимание тут. на примере.

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

вопрос первый если мои бины не выполняют куски бизнес-логики то где бизнес логика?  т.е. если я не могу прятать свою сложную и специфическую работу внутри компонента то все это изначально не имеет смысла - я прав?

усложняем. среди моих бинов есть один особенно тяжелый. и неделимый. т.е. я по каким-то причинам не могу разделить работу которую он делает еще на несколько кусков. ага. я хотел бы рассовать копии этого бина на три сервера я хотел бы что очередная транзакция не ждала пока отработает мой бин на сервере "A", работающий в данный момент для другой транзакции, а хватала не занятый в данный момент бин на сервере "B". возможно ли это в рамках EjB это мой вопрос. понятно что для бина "с состоянием" это не очень возможно... ну а для бина без? 

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

 

1

Session бины для того и нужны чтобы выполнять бизнес логику.
2
Если ты не хочешь ждать пока отработает твой бин, придется использовать MDB.
3
Нет не часто, но кластеры к ejb не относятся. И настраиваются они не сложно, если тебе это понадобится(при использовании ejb)

Да есть куча еще разных технологий, но чем же вам все таки ejb усложняет жизнь??
Написанием интерфесом(да куча средств типа xdoclet или тогда уж ejb 3.0) Написанием xml дескрипторов (тут все теже средства + еще куча всего).
Вообще разработка бинов идет на скорости мысли, да куда уж быстрей??
Или долго проектировать? Это все разрабатывается параллельно с архитектурой и не занимает никакого времени. Тем более вы программисты с опытом, вы замечаете что эта технология что-то замедляет в вашем процессе. Я оглядываясь назад не представляю как можно сделать все быстрее. А сколько еще потом будет преимуществ по расширяемости?
ALKS сказал(изначально) что магазин это очень сложная система , куча данных, куча страниц. А где бизнес логика ее нет?  А почему если у вас такая загруженная системы не использовать MDB? Если использовать технологии J2EE получается интернет магазин - это JSP + База данных?(ну забудем пока про mail)

to tux
JNDI это вообще не технология j2ee, да там вообще мало технологий, по пальцам можно пересчитать. Извини конечно, я не встречал неоправданного применения ejb, хотя когда то считал что в некоторых проектах оно неоправдано, но потом поучавствовав я понял, что народ продумал все не зря. 
Ну а насчет производительности, то если это так критично, то нафиг java?
я согласен что есть куча и других решений, и вообще есть куча всего другого и еще куча всяких мнений которые почти всегда с ними не пересекаются, и одно из них твое, на которое отображаются некоторые твои технологии которые ты поиспользовал и видел, тоже самое имеется в наличии и у меня.  а насчет выражений я на личности не переходил и ALKS уважаю, и большое ему спасибо что делится опытом и показывает один из возможных подходов решения. Я думаю если бы они начали заново, то не факт что они все писали бы также и использовали бы теже технологии.
И вообще не знаю в чем вы находите тяжелость ejb, при написании обычных бизнес приложений тут не нужно особых знаний. Многие мои знакомые осваивали и могли уже что-то дельное писать уже за неделю две. Конечно есть огрмные платформы(с которой я щас работаю) где нужно знать кучу тонкостей и не только с ejb а и с самим контейнером и jta и всего что связанно с j2ee, такие системы мне кажется невозможно вообще построить при помощи других средств,разве что все придумывать заново.
Вообще я сравниваю технологии с математическим аппаратом. Для каждой проблемы есть куча решений, и обычно самое первое решение получается не наилучшим методом. И не все методы универсальны, некоторые быстрее работают некоторые медленне, но чем искуснее математик тем производительней он применяет свой аппарат. Жаль вот что только в прогаммирование зачастую плохие решения считаются решениями, если они приводят к тому же результатом. Больше искусства надо=)
Буду благодарен за дальнейшие комментарии.

 

to tux 

сорри не увидел, сейчас я работаю в компании которая один из лидеров OSS для телеком операторов, это огромная система, сильно настраиваемая и гибкая, только одних типов данных здесь около 2000, а аттрибуты на типах меняются по "сто раз в день", здесь все на j2ee начиная с ядра, правда некоторая часть логики в базе есть, но это самое критичная часть кода, для которой производительность привыше всего. Ни разу не слышал про неоправданное использование ejb здесь.  

wadissimo  а можно подробности серверной архитектуры? сколько серверов? какие? какой апп сервер применяеться?  любопытно.


вспомните как появился стнадарт EjB все схватились и стали юзать. потому что по сравнению с DCOM илм CORBA, EjB действительно проще особенно для начинающих.  ура. потом опп .. медленно. очень хорошо помню статьи того времени... ага потом проснулся sun - а чего это народ скорость не устраивает? ах у вас все бины на той же машине? хмм... что появилось в следующем стандарте? правильно, локальные интерфесы. sun пошел на поводу у широкой общественности. и правильно сделал. своих пользователей надо слушать как бы они странно не использовали ваши идеи. (Всегда помнить надо историю Microsoft Excel и Lotus 1-2-3 в этом контексте... ) распределенные вычесления они там хороши когда задача во первых однозначно потребует больше одного сервера и второе когда невозможно применить лоадбалансиHг или кластеризацию. вот тогда да не вопрос. а в протиивном случае это все равно медленно. и не надо говорить о красоте архитектуры и легкости модификации. этого можно добиться и без EjB, причем без всяких особых усилий. и даже изабретать ничего не надо, как правмльно tux заметил, добротных фрейморков хватает более чем.

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

MDB... асинхронные механизмы они там хороши где применимы а применимы они далеко не всегда. точнее они применимы только иногда, к сожалению.

wadissimo вы правы. вы зрите в корень. вэбмагазин это фронт энд плюс база данных и не надо усложнять. и если бы не проклятые динамические каталоги мы генерилибы весь каталог магазина  в статичный HTML ночью раз в сутки и не было бы даже JSP на 70% страниц. плюс ваэбмагазин очень легко кластеризуется и это моя маштабируемость причем маштабируемоть такого уровня о которой мне вообще не надо думать и даже помнить при разработке и даже не нужно настраивать при инсталяции. да у нас очень много сложного но большая его часть не в магазине а впроцесах интеграции и сиехронизации чего попало но там EJB применить вообще не возможно. 

апп сервер Weblogic. честно говоря про сервера я не в курсе, знаю что у кастомеров обычно кластеры стоят, так как у них обрабатывается огромное количество объектов, но других вариантов у них нет. Создать такие системы другими технологиями практически не реально. А стоимость нескольких многопроцессорных машин на несколько порядков меньше. Я знаю только что на 4х процессорных серваках(6 Гб памяти) около 10ка аппликэйшен серверов запущено на каждом, базы данных на отдельных серваках.

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

Меня интересует не просто интернет магазин, а плюс к нему система управлениями ордерами и что-то на подобие инвентори. Есть несколько стандартных решений workflow и это можно запросто все с интегрировать используя всего несколько бинов, сколько логики правда будет я не оценивал.
Но вот волнует проблема, все это весит десятки мегов, например jboss:30-50, mysql:30, jre:15 цифры почти от балды, но суть в том, не будет ли напряжна установка такого решения в пару сотню мегабайт пользователю? Особенно с зарубежными. Не задолбает ли его столько качать или он предпочтет систему попроще но с меньшим размером и более быстрой установкой, тут у меня никакого опыта нет, поделитесь пожалуйста...

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

Пока рынок жирный производители софта буду осознанно использовать тяжелые технологии - так продается более дорогой софт и более дорогое железо.


А можно конкретнее? Что нереально создать другими технологиями? 

jimur, мы например софт не продаем, мы продем сервис, поэтому мы кровно заинтересованы в том чтобы 1 сервер тянул очень много запущеных магазинов. если под каждый магазин надо будет бокс втыкать мы в трубу вылетем, отсюда и требования быть очень не ресурсоемким по памияти и CPU-time. Что касаеться "тяжелых" технологий, то я не соглашусь что люди выбирают тяжелые технологии что бы сбить монету с конечного заказчика, это утверждение спорно весьма 

wadissimo, похоже, типичному заказчику вашей конторы собственно безразлично какое железо и сколько вашей системе нужно.  Даже тех деталей которые вы упоминули(Weblogin,  4х процессорные сервера )  говорит о крайне высокой стоимости "хостинга". Кроме того само по себе предожение явно серх-большое(сколько таблиц в базе,кстати?). Клиентам вашим важно, чтобы система работала и была кастомизируема по-максимуму, а все остальное - вторично. у них денег - мешками . Я знаю такие системы, сталкивался, и такой подход очень даже оправдан бывает. 

(Кстати сколько отрабатывает у клиентов объектов? хотябы порядок? 10000? 100000?)

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

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

"управлениями ордерами и что-то на подобие инвентори"
А что вы под управлением ордерами понимаете?
у нас это делает ERP система. Каталог приходит от туда, ордера из магазина уходят туда. И не советую пытаться делать это самомтоятельно. под этим лежит управление складом, а это слой такой толщины, который огромные конторы годами разрабатывают.