|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Serge Shikov 2:5020/400 28 Jun 2001 11:58:53
To : All
Subject : Re: Литература по PHP
--------------------------------------------------------------------------------
pavel kurnosoff wrote:
>
> SS> Э, и что, собственно? Да, для относительно больших. Кстати, размеры
> SS> они в чем меряют? Вообще, при применении EJB большой проект можно
> SS> свести к набору относительно мелких объектов, в чем собственно и
> SS> состоит цель мероприятия. В результате что для одного большое - для
> SS> другого может быть мелкая рутина.
> ну да. плюс покупка контейнера,
бесплатный сойдет для начала. Их есть уже два-три приличных.
> плюс его установка, плюс его настройка, плюс смена железа.
What for?
> мелкая рутина, да?
Да, начальные затраты времени немалые.
> >> и это говорят люди, у которых вопрос использовать или нет решается,
> >> так сказать, at no cost (в отличии от теХ. кто пишет perl). причем
> >> так отвечают не только "сынки", но и местные гуру.
> SS> Извини, насчет no cost - это ты загнул. Для начала это надо изучить.
> SS> Hадо поставить EJB-контейнер, который в комплекте явы не валяется. Его
> SS> надо выбрать - хотя бы потому, что коммерческие нехило стоят, а
> SS> бесплатные не всегда полностью реализуют спецификацию - и в этом надо
> SS> убедиться. Его надо настроить и администрировать, и объем настройки
> SS> сравним с объемом настройки скажем WWW-сервера. Одному человеку с этим
> SS> справиться сложно, это я тебе как доктор...
> а, дык всё-таки всё на так легко и непринуждённо? значит чудес не бывает?
А чудес никто и не обещал. Я просто намекаю, что некоторые "гуры" вполне
могли и не попробовать ;-)
> SS> Hу и наконец, Михаил верно заметил - тем кто реально использует, эти
> SS> разговоры довольно скушно поддерживать. Скушно объяснять людям, зачем
> SS> нужны транзакции, например.
> ну уж напрягись давай и объясни, зачем мне нужны еще какие-то транзакции в
> однопоточном приложении, где persistency обеспечивает rdbms со своими
> транзакциями.
rdbms допустим может что-то обеспечить только внутри себя.
> так что пока всё еще perldoc perlmod.
Кроме того, persistency тебе допустим обеспечивает mod_perl, сохраняя
где-то у себя (Apache::DBI например) открытые соединения с базой. А
иначе какие транзакции? Hо при этом возникают резонные вопросы - первый
HTTP-запрос обработан одной дочкой апача, второй - уже другой. У каждой
по своей копии mod_perl, по своей копии $dbh, и т.п. И где у нас опять
транзакции? Я не говорю, что они уже пошли лесом, но об этом надо
думать, и думать серьезно. Точно такие же проблемы возникают, если имеет
место кластер - HTTP обрабатывается несколькими серверами, а
бизнес-объект должен жить где-то в одном месте (или свободно
перемещаться). Ты гарантируешь, что твой perlmod сам по себе это
обеспечит?
При этом сразу возникает резонный вопрос - а нафига? Hафига мучать Апача
несвойственной ему работой, почему не создать отдельный сервер именно
для persistent-объектов? Пусть себе на перле будут, или на яве - я бы
даже предпочел, чтобы они были на чем угодно (ну нравится мне идея IBM с
их WSTK). И пусть будут через SOAP доступны. И пусть у них внутри будут
транзакции, а апачу до этого никакого дела нету.
Вообще, что ты будешь делать, если вдруг придется с Апача уйти? Hу там
на IIS вдруг? Мне вот приходится иногда про это задумываться. И чем
дальше думаю - тем больше убеждаюсь, что надо отдельный сервер. Как его
будут звать, EJB или нет - не так важно. Очень может быть, что звать его
будут COM+ ;-), а объекты будут например лазать в Excel за данными -
почему нет? Почему бизнес-объект обязательно должен жить в Апаче, если
данные его живут под виндой? Мне это пока не надо, но приятно, знаешь
ли, ощущать, что я и это могу, если приспичит.
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
