Задачка не простая - выбираю платформу для серьезного проекта. Реально большие части три: система хранения данных, система управления произвоством, ну и интернет-часть. Все это увязать веб-сервисами.

Возникла мысль попробовать JAVA - нужен совет на сколько это реально. 

Это реально! Насколько я знаю для построения крупных проектов часто используют платформы от IBM. 

Вполне реально, только вам понадобятся грамотные разработчики для этого дела. Есть где их взять? 

Разработчиков пока нет - идея использовать JAVA связана с тем, что язык (по рассказам) очень мощный, технология J2EE продвинутая, и все такое. А самое приятное - технология вполне может быть бесплатной для разработчиков.

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

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

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

У меня 10 летний опыт разработки корпоративных систем на Java. Но я  ничего не могу дельного сказать тебе по теме. и никто не сможет. нужно в представлять ваш проект нужно видеть хотябы наметки технического задания. хотябы предварительные пожелания пользователей и т.п. 

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

Судя по тому что

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

Если сравнивать коммерческий софт и open-source-продукт (конкретнее, Websphere и JBoss), то в первом случае вы получите документацию лучшего качества и техническую поддержку. Судя по опыту знакомых (сам не пользовался) техническая поддержка - чистой воды фикция. Что касается эксплуатационных характеристик, то есть большие системы, эксплуатируемые и на JBoss и на IBM Websphere, с этой точки зрения особых преимуществ нет ни у кого. Похожая дискуссия еще здесь - http://forum.vingrad.ru/index.php?showtopic=85826&hl=. 

Хорошо, тогда - как мне корректно сформулировать вопрос? Предположим, я не хочу раскрывать суть проекта, но проект по масштабам сравним с ozon.ru - если не больше. И конечно, мнение экспертов интересно.

Самое интересное, что при грамотной архитектуре очень значительные нагрузки будет выдерживать и всем известный PHP, при этом стоимость разработки будет сравнима со стоимостью разработки на JAVA. И найти толковых специалистов будет так же сложно - реально много студентов, начинающих программеров. 

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

Добавлено @ 18:59 


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

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

 

Я могу сказать, почему PHP в данном случае не самый удачный выбор. Дело в том, что в больших системах веб-интерфейс - это только видимая часть айсберга. За этим фасадом, как правило, скрывается неслабый, так сказать, аппаратно-программный вычислительный комплекс, обеспечивающий работу различных подразделений, филиалов, партнеров, сторонних программ и пр. Я бы не стал никого пугать, но если ты говоришь о масштабах Озона, то это автоматически подразумевает немаленький штат, склады, логистику и прочие радости, откуда вытекают требования к информационной инфраструктуре.

Так вот, PHP для всего этого ну просто в принципе не годидзе. Тут речь не о масштабируемости и способности держать трафик - речь о возможностях платформы. PHP, даже в новом своем объектном обличии, никак не может вырваться за узкие рамки вебного программизма. В терминах приложения и его функциональности надо думать, а не в терминах скриптов, а среды-то для выполнения такого приложения и нету.

Вот так вота.
 

В общем согласен. Хорошо и правильно все делать на одной платформе. Хотя - фронэнд на пхп все же будет работать нормально. Ну а backoffice может работать на чем-то другом. Хоть на 1С.

Вопрос не в этом - вот если выбирать между юниксом и виндой? юникс вроде надежнее.

А между .net и java? Кроме этой пары вариантов особо нет. 

Хех, как бы не скатится к религиозным войнам 

На мой взгляд как enterprise платформа Java богаче чем .NET. Она дольше на этом рынке, под нее больше фрейворков и готовых систем.

Мы выбрали Java из-за кросплатформенности, под ту платформу что мы пишем есть только древний Qt или Java. Естественно мы предпочли Java, и тем более осталась возможность запуска под Windows.  

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

Мы сейчас имеем юникс-наследство, так что переход на винду был бы не очень логичен.

Вот с грамотными спецами по Java реально какая-то проблема. По ходу - либо никто не хочет поработать над новым проектом, либо реально Java - мертвая тема. 

В Москве их просто мало, уж и не знаю почему. 

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

LiveJournal это perl. Yahoo! - php. портал IBM - java. все три сайта имеют экстремальный трафик и работают вполне стабильно. 

а ещё я как то примиал участье в разработке системы где движок был на Java, web интерфейс Php и еще кое что на perl. крайне комерчески успешный проект доминирущая в германии система сейчас в своей нише.

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

в моей практике был проект где Java была выбранна абсолютно не верно и это дорого обошлось. (синхронизация данных. ERP система оказалась Navision 2 который не имел jdbc драйвера вооще а odbc драйвер был настолько кривой и примитивный что его еле удалось заставить работать через коммерческий JDBC-ODBC мост и работал он ужастно при том этот Navision имел добротный не реляционный pure C интерфейс, вот только С в команде не знал никто да и сам Navision тоже)

а еще  я помню проект Novell 5, WebSphere3, Oracle 8i... для Intranet системы в 200 пользователей. нагрузки на систему были смешные но хапанули же софт... не говоря уж о том что через пару месяцев разработки выяснилось что ни WebSphere ни Oracle  больше не поддерживают Novell. как наши умельцы выдирали критически необходимые нам исправления в классах из патчей для  WebSphere на других платформах и заставляли это работать - это отдельный рассказ... 
это к вопросу абсолютно не правильного выбора серверного софта...


не возможно порекомендовать тебе какую любо платформу без представления о том что ты будеш делать. если жи ты скажем предоставиш такое "описание" то его разбор, анализ и конкретные 
рекоммендации это уже что-то за что ты должен платить деньги.  А на постановку вопроса в стиле "хочу писать ситему как ozon.ru на Java. что думаете?" можно только плечами пожать. 

Народ, а кто может что сказать про Cold Fusion?

Добавлено @ 22:14 
Народ, ALKS, честно, я ждал примерно такого ответа, сам не первый год в шоубизнесе )) В любом случае - разговор получается для меня очень полезным.

Сейчас мы на стадии разработки архитектуры системы, окончена эта работа будет примерно к концу мая. К этому моменту уже будет понятно на 100%, на чем мы будем все это писать. Есть набор историй успеха для любых платформ - от PHP до .NET.

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

По этой причине,  наследовать технологию PHP или взять JAVA для нас нет особой разницы - то, что сделано на PHP, не представляет накакой ценности, кроме того, что оно уже сделано. Точно останется UNIX, ну а выбирая между PHP и JAVA конечно хочется выбрать JAVA.

Хотел услышать что-то типа - "...на J2EE можно делать весчи редкой красоты, какой на PHP тебе не добиться".

Если не будет нормальных джаверов к концу месяца - то будем писать фронтэнд на PHP, только как положено. По этой причине приглашаю желающих поработать =)). 

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

Про озон - крупнейший в России книжный и т.д. магазин, сделан на дотнете + мелкософтовый сиквел (кластер на 4х серверах). Свой собственный бэкоффис и система логистики. Свой CRM-анализ - достаточно эффективный.

60000 посетителей в сутки, 500000 показов страниц в сутки. 

Просьба все что касается предложений работы писать в соответствующий форум: 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!  

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

Хм... а что такого монструозного в J2EE - Web Sphere та же в чистом виде саппортит эту платформу, и ничего. Это я про то, что J2EE или JSP (на чем-то типа TOMACAT`a) - с точки зрения производительности - не ужели будет разница? 

голословщина чистой воды, уж простите.

1. Вы полагаете, что для EjB over JNDI over Serialization и так далее не нужны дополнительные ресурсы? Вы мыслите категориями 10-летней давности когда библиотеки всевозмоного XML-related процессинга только появлялись и были естественно глюкавые и тормозные. Сейчас все иначе. c ~два месяца назад мы пронаблюдали как просто замена версии Xalan-а 3-х летней давности на последнию версию 2.7 увеличила производительность трансформации в 2.5 раза! да и уровень поддрежики стандартов уже совсем иной чем даже 3 года назад. К тому же вэбсервисы, это XML-binding, т.е. по определению максимально быстрый разбор. Например, родной сановский JAXB 2.0 это уже третье поколение это билиотеки, играл как раз с нею неделю назад - мощно. 

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

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

2.Axis ? Axis - отстой. мы написали единственный вэбсервис на Axis 1.1 и бросили его нафиг. у него были огромные пробемы с поддержкой W3C схем более сложной структуры, чем "примитивно". Да с тех пор вышло несколько версий, но в любом случае Axis однозначно не лучшая бибилиотека. просто по определенным причинам самая распространенная. И не нужна по одной не лучшей реализаия делать обобщающие выводы обо всей технологии. 

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

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


3. Нет. нету никаких специфических трудностей в разработке и отладке вэб-сервиса. это просто: нарисавал схему, автоматически сгенерил классы, вписал спицифическую бизнесс-логику в одном месте. погонял тесты( иногда со снифером). все.

Ну и от себя добавлю, почему вэб-сервисы то? в чем приимущество? да в том что кто угодно и где угодно может доступиться. любой язык программированя, любая ОS, если ваша "песочница" поддерживает HTTP, то вы сможете работать с вэб сервисом начем бы он не был написан и где бы он стоял(даже долбанный Navision с полу-тыка поднял вэбсервис - хватанули какой-то ActiveX по умолчанию имеющийся в винде и реализующий SOAP и влет подрубились к вэбсервису написанному на java, как заставить Navision рабоать с CORBA или с хи-хи  EjB я даже думать не хочу ) 
 

ALKS, рад почитать такой супер-текст. Я вообще за максимально разумное использование стандартов, это делает софт продаваемым и профессиональным.

Хорошо, что нашелся сторонник веб-сервисов. Честно - совместимость - одно из преимуществ, на которое хочу сделать ставку.

Есть еще комменты - но пока не успеваю дописать. 

Сервер приложений, реализующий весь стандарт J2EE, ресурсов будет однозначно потреблять больше ресурсов, чем простой веб-контейнер по той простой причине, что у него намного больше сервисов, количество которых, впрочем, в большинстве случаев можно и сократить. В конечном счете это может, конечно, сказаться на производительности одного и того же приложения. Однако, в основном производительность будет зависеть от используемых технологий. EJB в сравнении с использованием какого-нибудь облегченного контейнера (Spring, например) плюс веб-сервисов (если нужны удаленные вызовы объектов) проиграет в производительности при сомнительных для большинства приложений достоинствах. Кроме того, разработка EJB ничуть не проще чем веб-сервиса.

ALKS действительно дело говорит, но технологий веб-сервисов, реализованных на Java, много и если предполагается взаимодействие только Java-2-Java, можно и чего-то полегче использовать. Хотя в конечном счете в простоте разработки особо не выиграете.

Websphere почти не пользовался. Во-первых, нет возможности его купить (я в бюджетной организации работаю), а во-вторых, просто не купил бы. ИМХО, если сравнивать Websphere с JBoss то, имея реализацию одного стандарта, во втором случае мы получаем поддержку огромного комьюнити, открытый исходный код, что само по себе достоинство, правда при менее качественной документации. Кроме того, JBoss не такой тяжелый. Используем JBoss уже 4 года, особых нареканий нет, с другой стороны и нагрузки на него выпадают не супер, поэтому как он будет себя вести при больших нагрузках на собственном опыте не знаю, только по рассказам. Рассказы в целом положительные. 

Вообще если бы у нас не было двух систем, реализованных с использованием EJB, скорее всего переехали бы на что-то более легкое, но вряд ли Tomcat по причине нереализованности у него некоторых сервисов, например, JNDI.

А технологический крен опять переместился от PHP к Java?   

Это сообщение отредактировал(а) tux - 25.4.2006, 13:48

по совему опыту скажу так если реч идет о серьезном приложении, ну скажем в несколько тысяч классов, то абстрагируясь от языка программирования и платформы... уже все бутет упираться именно и только в собственный код и "дизаин" собственной архитектуры. дорогой  и крутой АppServer поможет вам тут только в роли хромированного стального костыля по сравнению с деревянным: сломаеться по сравнению с деревянным позже, но сломаеться всё равно  и по опыту скажу что проблеммы в собсвенном коде встречаються на порядок чаше и решение их дает на порядок больший эфект чем любые танцы с бубном вокруг выбора аппликэйшн сервера.

Золотое правило тут как и везде - выбирайте то что лучше знаете, то с чем уже сталкивались....
Вот мы сидим на JRun 4. Он по большому счету... [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме] (простите искренне). но мы его знаем как облупленный, мы умеем его в тоностях настраивать, мы знает как конфигурить для него оптимально java машину, мы знаем его баги и умеем их обходить, у нас уже и контакты в группе разработчиков JRun и официальные бета-тестеры мы и-и-и-и .... и работает он только в путь под экстремальными нагрузками у нас. И не будем мы его менять хотя деньги для нас это вопрос даже не третий и знаем мы что WebLogic потонцеально много лучше 

P.S.
Websphere после моего опыта с её третей версией - только через мой труп. да наверное это субъективно очень и наверняка последние версии на уровне но... первое впечатление самое сильное  

Блин, здесь все зависит от народа. Есть народ - есть Java, нет народа - нет Java. Вообще - на PHP мы быстро напишем приемлемый вариант сайта, который решит 1/3 проблем.

Потом есть еще back-office, воспрос с выделенной клиентской базой, сервером анализа статистики, системой хранения и просей лабудой. Мы сменим лицо, наведем марафет, подоткнем силикона - но проблемы прочего софта реально останутся. На PHP, конечно, много можно сделать, но...



Это верно на 100% - такой подход дает прогнозируемые сроки. А сроки - крайне важный момент для любого бизнеса, и даже не столько их абсолютный размер, сколько прогнозируемость.

Фактически, команда разработчиков определит, что именно будем использовать.

Готов писать здесь некоторую хронологию развития событий.  =)))

Добавлено @ 16:05 


Процитирую моего товарища: Web Sphere 6 + Rational Application Developer - сильно упрощают работу.  Такой коктель совместно работает сильно эффективнее, чем Web Logic.

Добавлено @ 16:09 
А еще - я лично с сильным респектом отношусь к Rational - даже зная все кривости этого софта. Правильная весчь. В итоге получаешь и приемлемую документацию на архитектуру, и шаблоны классов, а как следствие - совпадение первого и последнего. 

А что такое Rational Application Developer? Была такая штука Rational Suite кажется, пакет приятнейших CASE иструментов $30000 инсталяция на 1 (одну) машину.... Знаю контору одну (точнее знал) которая разорилась попытавшись внедрить Rational Development Process c использованием этого пакета для проекта... и честно говоря не знаю ни одного случая где использование высокуровневх средств (ну UML иже с ним) "сильно упрощало работу". поднимает качество - да. позволяет организовать работу над гиганскими проектами с очень большим количеством разработчиков - да. но "упрощет"... увольте - увольте  

Будем разбирать по пунктикам 


Нужны, как и веб-сервисам. Изначально речь шла об одном проекте, в который собраются запихнуть веб-сервисы. EJB тоже никуда запихивать не надо  Если кто не заметил - Сан после второй версии понял, что не туда пошел и сделал EJB3.0 больше похожую на hibernate. Короче все это для большинства проектов дополнительный оверхед, ну и способ разработчикам поучить "крутые" технологии.


Можете еще в 3 раза увеличать, перейдя на XT, или в 5 используя libxslt  сравнение производительности. Я вовсе не предалагаю с++ использовать, просто показываю сколько лишней работы (WS) делается. Она конечно нужна для интеграции всего со всем, но излишня в одном проекте, технологическим развитием которого можно управлять.


Ну уж не простим, медленне  и понятно почему. Да и в разработке corba проще - пишешь интерфейс и реализуешь сгенеренный интерфейс. Все. Еще пара ссылочек чтобы не быть голословным: 
сравнение производительности
цитата оттуда

И вторая ссылка на обсуждение. Очень понравилось название  Веб-сервисы? Что курит индустрия? 

Добавлено @ 22:38 

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

Это сообщение отредактировал(а) jimur - 25.4.2006, 22:36

Нет, не прощу  Конечно, я написал без цифр или ссылок, но это вовсе не значит, что написанное взято с потолка - сравнение конечно проводилось. И не 10 лет назад .  Тесты выполнялись в контексте конкретного проекта, сравнивались ws(axis), rmi(sun), corba(sun), jms(activemq & joram) и сокеты. Резалты получались такие - rmi был быстрее ws практически на порядок. Ну и понятно, что сокеты вне конкуренции абсолютно (по скорости). Детали - версии софта, сценарии тестов, конкретные цифры и сами тесты готов представить. Но не сразу - их нужно или найти, или написать заново. И не то, и на другое нужно время, а его, увы, как-то не очень много  Если есть реальный интерес, то готов к началу следующей недели найти/восстановить и опубликовать. 


Ясное дело, что ресурсы нужны  для всего. Говоря про доп. ресурсы, я естественно имел в виду дополнительные ресурсы, по сравнению с RMI и прочими.
Готов согласится с тем, что сейчас возможно xml парсеры работают быстрее, чем год назад, но как-то сильно сомневаюсь, что существенно. Насчет XML binding и быстрого разбора - по любому это разбор текста. Вы же не будете спорить, что это гораздо более ресурсоемко, нежели разбор бинарных пакетов? 



Не согласен с утверждением про скорость(см. выше). + про аппаратные акселераторы для разбора XML и для XSLT слышал. Но не слышал про аппаратные акселераторы для CORBA/COM/DCOM. Может плохо слушал? Утверждение про "в разработке проще" более чем спорно. Мой опыт говорит об обратном. Хотя допускаю, что он у меня неправильный. 


Мой опыт работы с веб сервисами в java ограничивается Axis. Очень и очень согласен со словами "про огромные проблемы" и не только с поддержкой схем. С диагностикой ошибок тоже не все здорово. И с отладкой - но это, имхо, касается вообще SOAP. К сожалению, "по определенным причинам" мы использовали именно axis. Одной из таких причин является то, что Axis в силу своей распространенности является де факто стандартом  - это про выводы  Есть такие люди, которые называются заказчиками. Так вот они, зачастую, навязывают использование тех или иных фреймворков или технологий по тем или иным причинам. У нас вначале с axis было именно так. А потом привыкли к нему, его ограничениям и к исправлению багов в нем. 


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

Для того, чтобы это был не мейн-стрим, нужно чтобы технология использовалась там, где это действительно необходимо, а не везде - по поводу и без. Пока это не так. То, что для многих задач веб сервисы штука очень полезная (даже и с axis) я не спорю. А про индустрию очень понравился заголовок топика, приведенный 
jimur, 
 )))


Снова почти согласен. Тока есть примеры, когда не все так уж и безоблачно. При взаимодействии с ws, написанными на java из Delphi были оченно существенные проблемы (предвидя заявления о голословности сразу скажу, что не помню но думаю, что гугл ту сможет прояснить ситуацию, по крайней мере мы в свое время натолкнулись на массу сообщений о проблемах, схожих с нашей - о5 же при передаче более-менее сложных типов данных). Повторюсь: использование ws, как и любой другой технологии, бывает оправдано, а бывает и нет. ws очень уж часто используются не к месту (имхо). Видел не один проект, где архитектор реализовал взаимодействие java - java (!) с помощью web services и все заканчивалось отказом от ws из-за глюков и проблем с производительностью. Знаю проект, где веб-сервисы были вроде и нужны - нужно было обеспечивать взаимодействие php-java. Закончился проект отказом от php и ws из-за многочисленных глюков. Все было переписано на jsp и java.   

ЗЫ Уважаемые админы, почините, плз мой старый логин pvo - пароль забыл, восстановление пароля не работает 

Добавлено @ 01:09 

Это вроде эклипс с набором айбиэмовских плагинов. По слухам довольно глючный. 

Это сообщение отредактировал(а) pvo1 - 26.4.2006, 01:07

Проблема с тем что люди не понимают что такое вэб сервисы и не рубят как их использовать есть. последний случая:
риск манаджмент система KQIS oт гиганской немецкой корпорации Karlstadt-Quelle это вэбсервис принимает xml из двух элементов: какой-то код и... xml c данными  - просто аут...

а вообще мы,  применяем активно вэбсервесы для ингерации разнородных систем. всевозможные синхронизации данных между чем попало, производительность не критична. будет он работать 0.5 секунд или 5 секунд для нас без разницы. 
Кроме того, как правило и грубо говоря, скоростью вызова метода и предачи параметров в компонент (буть то RMI, EjB, CORBA,вэб сервис или супер-сладно-кушистый-способ) можно смело пренебречь, собственно сама работа внутри занимает на порядки больше времени...

про CORBA я пожалуй спорить не буду, мой опыт ограничиваеться интеграцией LotusNotes 5 c чем-то там по CORBA. было трудно и дорого но было давно. 

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

Это сообщение отредактировал(а) ALKS - 26.4.2006, 12:00

Поддерживаю позицию pvo1, естественно, пользовать любую технологию (и не только) нужно по назначению.

Возвращаясь к топику, если мы принимаем решение для каждой части общего проекта писать софт на своих технологиях - например, сначала сайт на том, что есть - РНР, потом позже CRM - на более красивой платформе - Java, файловое хранилище - на C++.

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

А вот с этого места можно поподробнее? 
Делали тоже самое, тоже давно. Просто интересно как другие страдали тем же геморроем. Как в конце концов интегрировали, в паре предложений сам способ.


Не знаю, может быть XML-RPC? Протокол настолько простой, что там собственно и глючить-то не чему.  Хотя на практике Java-PHP не пробовал, только собирались как-то.

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

Про EJB с CORBA согласен полностью. Мы, по возможности, стараемся не использовать ни вебсервисы, ни EJB, ни CORBA. Только если без них в самом деле не обойтись, ну или заказчик очень хочет и не удается его разубедить.


Проблема не с самими веб сервисами, а некорректным их применением, а также и с недостаточной квалификацией программеров в ряде случаев.



Выше упоминал про неудачный опыт разработки связки php - webservices(java). Не самый удачный вариант при наличии jsp, servlets и множества фреймворков для построения веб приложений.

Согласен.  

  

Это сообщение отредактировал(а) pvo1 - 26.4.2006, 14:48

Суммируя общую мысль, получем: 

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

Иначе говоря, грамотная идея при сыроватой реализации.

All, объясните чайнику, как могут не работать совместно два приложения, в качестве протокола использующие стандартизованный XML-документ? Производители отклоняются от стандартов? 

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

Продукт, написанный на PHP, представляет меньшую технологическую ценность, чем софт, написанный на Java (субъективно - может у кого есть мнение на этот счет?).

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

jimur, спасибо за линк про курение, мысли там дельные есть  а что еще более ценно там есть другие линки 

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

deadrat, ты зриш в корень, насчет стандартов. первая проблема - не все одинаково хорошо поддерживают XML схемы, на которых основан WSDL(http://www.w3.org/TR/wsdl), так что далеко не всекий вебсервисный врейм-ворк способен сожрать достаточно сложную схему... с наследованием например и прочими "фишками."  во-вторых SOAP это отдельная история - вот тут любопытненькая статейка (http://webservices.xml.com/pub/a/ws/2001/04/04/soap.html) почитаёте может что-то проянит  

ok.

У меня есть вопрос - чем вы пользуетесь для имплементации вебсервисов? 

В итоге получаете кучу рисков по проекту, т.к. риск IT проекта есть функция от числа технологий. 

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

Кроме того, используя разныю технологии вы можете получить:
1. несколько групп полуспециалистов в каждой технологии
2. внутренние конфликты типа php рулит, jsp отстой

Использование единой платформы позволит:
1. использовать более эффективные технологии взаимодействия подсистем
2. получить меньше глюков при взаимодействии
3. создать команду профессионалов 

Все это конечно очевидно, только вот вся дискуссия как раз и началась из-за того, что последнее-то и не получается. Можно конечно взять вчерашних (или сегодняшних) студентов (как вариант переучить php-истов на Java, впрочем им-то от этого только лучше будет), они будут работать в процессе обучения и в конце концов вырастут в специалистов. Только вот проблема, это процесс длительный. Мне, впрочем, так и приходится поступать поскольку другого выхода нет - готовых специалистов по Java в Бурятии взять негде. Но у меня условия другие, сроки не жесткие. А у deadrat возможности ждать результата я думаю не будет. 

Кроме быстрого старта нужно еще и думать о будущем


Ага, вот и оставить потом такого менеджера наедине с "радостными" программистами, переписывающими чье-то детище c php на Java  
 

Не просек причину сарказма - согласен, что переписывать чужой код - задача просто из ряда вон. Но идея не в переписывании софта с одного языка на другой, а в разработку новой версии. То есть, дано: разработанная архитектура, написанный на PHP код, накопленный опыт. Задача: написать вторую версию, но на Java.




Thanx tux, именно в сроках одно из ограничений. 
 

http://java.sun.com/webservices/jwsdp/index.jsp

только мы пользуемся версией 1.3, версия 2 требует Java 5 на которую мы пока перевести наши приложения не можем.
хочется сказать что jwsdp 2 включает JAXB 2, который по моему мнению, просто прорыв и в области поддержки XML схем и не только. 

Объясняю. 
Я считаю этот подход: сейчас пришем на этом, а потом пишем на том неверным.
По следующим причинам:
1. Разработчики на PHP будут писать все в мусорную корзину
2. Разработчики на Java вместо создания нового, интересного проекта будут переделывать существующее барахло (а иначе зачем переделывать)
3. Будет неоправданное двойное расходование бюджета на изучение/освоение предметной области сначала php-, а потом и java- разработчиками

З.Ы. разработчики это не ресурс, а человеческий фактор  

Согласен с этим утверждением, но не согласен с причинами 1и 2. 

1. Разработчикам на PHP не обязательно знать, что они занимаются разработкой тупиковой ветви проекта. Кроме того есть небольшая вероятность того, что из этой связки получиться что-нибудь хорошее. Такое, что можно будет потом развивать, а не переписывать.
2. После эксплуатации того, что будет написано, возникнет куча предложений по усовершенствованию веб приложения. И очень вероятно, что java версия будет лучше php-ной. А когда люди понимают, что они сделали что-то, что лучше того, что было раньше, то это неплохо их стимулирует.

ну и по п. 3. Бывает, что если ты быстро делаешь макет/1 версию/... тебе выделяют бюджет. Если не делаешь - сидишь на бобах. Тут может быть именно такой случай. 

Подумал и решил что в такой ситуации это на самом деле правильно. В результате получите прототип, который можно обсуждать, вырабатывать дополнительнеые требования. Кроме того, будет набор шаблонов, которые (при грамотном подходе) пойдут в повторное использование в java-системе. А вообще если сразу учитывать, что система будет перерабатываться, многое можно повторно использовать.

ИМХО в любом случае лучше, чем ждать когда соберется команда java-программеров и уже вместе с ними начинать работу. Может быть до тех пор и кто-то с Винграда созреет для участия.  

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

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

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




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

В бюджетном проекте, возмможно, такой ход недопустим. А в проекте, который сам себя кормит - возможен, так как разработка новой версии приведет к экономии, новым фичам, новым доходам.

Добавлено @ 09:38 


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

Сейчас есть 3 PHP-программера, один PHP-монстр, и ждем еще одного PHP-технолога. В таком коллективе по части веба уложимся за 2 месяца.

Но вопрос возможностей платформы уже больно бьёт ключем: Workflow-сервер, к примеру, должен отправить запрос серверу обработки на асинхронную подготовку данных, а потом получить ответ, что данные готовы. По ходу, JMS (может, ошибаюсь - не спец пока). А у нас - PHP.... будем думать, как быть =)) 

Back to topic - по ходу, платформа - то, что придумали программеры. Определяет то, на сколько много усилий и мозгов нужно будет приложить для того, чтобы получить качественный продукт. Чем меньше усилий и мозгов, то есть чем навороченнее платформа - тем дороже специалисты. Чем банальнее платформа - тем дешевле специалисты, больше соплей, неколенных решений, изобретенных велосипедов и т.п. 

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

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

ALKS, полностью согласен. Посмотрим, что у нас получится - к сожалению, придется пользоваться тем, чем мы располагаем сейчас.