Просьба все что касается предложений работы писать в соответствующий форум: http://forum.vingrad.ru/index.php?showforum=146. 

Ок, желающие поработать - читаем http://forum.vingrad.ru/index.php?act=ST&a...58&unread=1 

Ха а вот про  ColdFusion я имею много чего по-рассказать 

Была такая контора Allair. Они создали две культовые программы ColdFusion и HomeSite. ColdFusion был и есть просто расширением HTML - для гинерации динамических страниц. да да все тоже самое как PHP или JSP но только он появился и развился до серьезного состояния гораздо раньше. На самом деле когда он появился у него не было серьезных альтернатив. JSP и ASP тогда просто не существовало. был момент в штатах когда примерно 40% всех комерческих динамический сайтов средне мелкого размера было сделана на ColdFusion. Allair быстро поняла потонцеал J2EE и в какото момент они перегнали весь ColdFusion в вид библиотеки JSP кастом тагов со всеми вытикающими последствиями, а чтобы не от кого не зависить забомбили собственный Application Server - JRun. (на этом самом JRun цветет и пахнет моя контора последние 5 лет, откуда я про все и знаю). ColdFusion был все еще крайне коммерчески успешным продуктом просто JRun шел в комплекте при покупке . как сервер для ColdFusion  (люди которые пользовались и пользуются ColdFusion в нюансах J2EE как правило не рубят  ). JRun кстати во времена Allair был весьма на слуху и на то время был весьма достойной вещью.  Но тут на сцену выходит Macromedia которая очень хотела убить упомянутый ранее HomeSite. HomeSite - был в то время абсолютно лучшим HTML редактором а у Macromedia как все мы знаем был и есть собственный аналогичный продукт. поэтому Macromedia купила Allair на корню. для того и только для того чтобы убить HomeSite (с чем успешно и справилась после приобретения вышло только пару версий HomeSite которые фактически ничего нового не привнесли . в основном багфиксы и не более. HomeSite забыли, какой тулс доминирует сейчас на этом рынке все мы знаем  Хотя в среде не дезайнеров а именно програмистов динамических страниц HomeSite весьма популярен до сих пор ).  Но  ColdFusion все еще был очень популярным товаром поэтому Macromedia продолжала его поддерживать и делала неплохие деньги на нем ну и JRun Они тоже по энерции занимались но надо сказать вяло. совсем вяло. И думали мы что конеч этому всему но тут Macromedia была куплена Adobe. и скажу я вам поддержка скакнула резко вверх. вышли сервеспаки (включая ужасающий JRun Updater 6, но это уже оффтоп)неожиданно вынырнула бета новой версии JRun. вообщем ситуация изменилась  Adobe явно проинвестировал это направление.

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

Это сообщение отредактировал(а) ALKS - 21.4.2006, 23:42

И зачем, если все разрабатывается с нуля, заранее закладывать дополнительные тяжести типа веб-сервисов? Если только ради инвестиций... ;)
Java много чем хороша (дешевая переносимость + куча готовых, проверенных продкутов/технологий/библиотек), но хороших разработчиков в Москве сейчас найти очень сложно   
J2EE из-за излишней тяжеловесности и стоимости разработчиков опять же не рекомендую, все зависит от задачи, но в большинстве случаев можно обойтись более легкими решениями (DBMS + Spring + Web Framework).


Реально и коробочные решения, такие как Jira(http://www.atlassian.com/software/jira/) доказывают это. Остается вопрос ресурсов (талантливых разработчиков и денег на них ).

  

Это сообщение отредактировал(а) jimur - 22.4.2006, 00:40

Хм, а ты уверен в этих цифрах? 

У меня один мелко-средний магазин выдает : 
~200000 динамических страниц в сутки. 
~10000000 запросов на HTTP сервер(IIS 6) - в каждой странице у нас много графики, стилей и т.п.
~600000 запросов к базе данных(MS SQL 2000) - не подумайте что у нас мало работы с базой. у нас ее очень много, но просто реализован давольно хитрый кэш объектов, который здорово уменьшает количество обращений к базе.

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

Все это щастье запущено на 2 серверах:
на первом ISS + ApplicationServer + собственно магазин(на этом же сервере работают еще 3 магазина. один примерно такой же по нагрузке и еще 2 раза в два по-меньше.), 

на втором - SQL сервер(на саом деле наш БД сервер обслуживает 3 таких "web"-сервера и кроме-то еще держит несколько баз для всяких левых не магазинных процессов и кроме-того, по-мимо нагрузки с "web"-серверов, он участвует в процессах синхронизации с ERP-системой.)

сервера связаны по гигабит эзернет и не представляют из себя ничего особенного - 2х процессорные пентиумы с 4Gb памяти. т.е. ничего необычного. Ну надо отметить правда что БД сервер имеет достаточно грамотную и быструю локальную дисковую подсистему - RAID на основе дисков предпоследнего стадарта SCSI.

Т.е. я хочу сказать что, либо цифры твои полная лажа. либо озон написан и работает исключительно криво потому что для таких не больших нагрузок требует 4x серверный кластер! 

ALKS, наверное с цифрами меня проглючило. Взял я их банально со счетчика рамблера, а это - сам понимаешь, не фонтан. 

Ну короче у них там реально все с нагрузкой. Мой проект сейчас генерит не очень много проблем - примерно 20000 уникальных IP в месяц, около 100000 просмотренных страниц. При этом реально все делает одна железка на базе оптиронов и немеренного коичества SCSI-дисков в четырех рейдах.

При пике нагрузки сервер ест 30% собственной мощности. Тем не менее, есть желание навоять еще не 3 тонны тусовочных интернет-ресурсов, так что будем делать более серьезную архитектуру.

Добавлено @ 09:54 
jimur, соглашусь с тобой. После безуспешных попыток найти JAVA-программеров, пришли к решению писать все на банальном PHP (исторически расположены к такому решению). Cлава Богу, есть история успеха от Yahoo.

Добавлено @ 09:59 
ALKS, про Cold Fusion - боюсь, здесь мы сталкнемся с той же проблемой - разработчиками. 

Хотя, имхо, J2EE есть возможность использовать и для GUI-приложений, для бэкофиса и т.п., а вот ColdFusion тут не прокатит. Ну а в остальном - в словах ColdFusion меньше программерского лоска, чем J2EE.

Порадовал твой рассказ про JRun. Еще у них, помню, была какая-то глючная CMS-cистемка?

Добавлено @ 10:02 


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

  А что в Москве реально так печально с java-программерами? Просто интересно. 

Веб-сервисы веб-сервисам рознь. Что касается Java, то использование Axis - это действительно дополнительные тяжести и все достоинства нивелируются сложностью реализации чего-то серьезного. Но есть и гораздо более простые альтернативы - XML-RPC, Hessian, Burlap, но они гораздо менее популярны. Как дело в PHP обстоит не знаю, но представляя примерно принципы, по которым создается библиотека PHP думаю, что все, что в ней есть должно быть очень просто. 

Да что такого сложного в вэб-сервисах??? ресуеш схему, генереш по ней классы, имплементируеш фактически только бизнес-логику. SOAP over HTTP работает везде. Люди, это просто! Я не знаю более простого и универсального способа интеграции разнородных систем. И чем вас не устраивают "родные" сановские бибилиотекм WSDP?  

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

Можно мне объяснить какую задачу они будут решать?
 

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

P.S. на http://www.alexa.com статистика ozon меня тоже совершенно не впечатлила, но тут можно конечно спорить о том насколько хорошо alexa собирает статистику в рунете  хреново скорее всего. 

Это сообщение отредактировал(а) ALKS - 24.4.2006, 13:36

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

Или другая задача: построить абстрактную клиентскую базу, с которой могли бы общаться многие системы - разные сайты, производство, логистика. Задачи: авторизовать клиента Z, запросить баланс клиента Х, запросить разрешение на услуги для клиента Y.

Добавлено @ 15:21 
 
Народ, еще - было бы здорово использовать результаты общения в работе. По этому если не влом - пишите так не пойдет, потому, что мы делали и получилась ж...па. Или потому, что так и так. То есть вот к примеру:



Почему веб-сервисы - это дополнительные тормоза? И почему - проблемы при разработке? 

Получаем команду через веб-сервер, заносим ее в базу. На втором сервере, используя Quartz, периодически ходим в базу за новыми задачами, при получении выполняем. Связь только на уровне данных. Ничего лишнего.



Любая СУБД + JDBC. Если нужны транзакции, то используем промышленную СУБД типа оракла. Другие системы через JDBC оперируют базой(ами). СУБД лучше иметь одинаковые и держать рядом, чтобы не парится с запросами по нескольким базам. Ну и технологии быстрого восстановления базы обязательны, т.к. это ядро.



старался быть кратким...
Дополнительные тормоза, т.к. надо совершать дополнительные операции по сериализации объектов в xml и их десериализации.
Проблемы при разработке, т.к. чем больше операций/технологий в системе, тем больше вероятность ошибки. Для реализации веб-сервисов используются готовые почти универсальные решения, приводящие к костылям при выходе за рамки универсальности. Со всем вышеперечисленным столкнулся в одном из моих проектов. 

Тут я бы использовал JMS. Удобнее + есть поддержка кластеризации и отказоустойчивость повыше будет.



А в этом случае, ИМХО, лучше использовать EJB или RMI. Или CORBA в крайнем случае. А напрямую с базой лучше не позволять другим приложениям работать - чревато проблемами.


Согласен с jimur
1. Для разбора XML требуются дополнительные ресурсы.
2. Средства для разработки web services, такие как axis, не идеальны - в них есть и свои ограничения, и баги.
3. Старый добрый POJO проще в разработке и отладке.

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


  

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


А что нам даст здесь EJB?


Ага, даешь POJO!  

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