Вышел JBoss 5.0.0

> Но когда речь идет про яву, томкат, джбос и т.п. рисков никаких нет ибо хуже уже некуда...

Авторитное заявление, без базару! Респект и уважуха! Ты четкий пацанчик, даешь краба братан!

>Но когда речь идет про яву, томкат, джбос и т.п. рисков никаких нет ибо хуже уже некуда...

По-моему, это к LAMP больше относится, чем к интегрированному и взаимоувязанному стэку JEE.

Я не спорю, я скорее цитирую. Я не люблю ни JEE, ни джаву. Но это всё с точки зрения программиста, а с точки зрения менеджера всё по-другому.

Чтож, придётся проверить насколько он, на самом деле, требователен к соблюдению стандартов.

>А для чего он нужен? Нет, ну серьезно, покажите задачи, которые без него сложно или невозможно решить? Зачем такой монстр нужен - непонятно.

Вот http://en.wikipedia.org/wiki/Blue_Gene, нет ну серьезно, покажите задачи, которые без Blue Gene сложно или невозможно решить на обычном пецуке? Зачем такой монстр нужен - непонятно

И, кстати, зачем такой монстр как Oracle нужен? Если все записи спокойно можно в sqlite хранить, что FireFox и делает

>Как например ютуб или гмайл, такие? :)

ютуб или гмайл с каких то пор стали вебсервисами? Troll harder, чувак.

>Впрочем, есть более легковесные и функциональные аналоги, из которых можно собрать что нужно.

Та ты шооооо? Ты .NET 4.0 & ASP.NET имеешь в виду?

Затрахаешься реализовывать!

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

Прикинь, Бивис, он не знает такого адреса как википедия!

На, изучай http://en.wikipedia.org/wiki/Webservice

>это технологические преимущества или просто это удобно продавать?

Продавать? Слушай, зачем линукс нужен? Это технологическое преимущество или линукс удобно продавать?

PHP это Personal Home Page. Спроси maxcom-a, почему он в свое время с PHP3 на Java спрыгнул?

Java никогда не разрабатывалась как язык для решения одной задачи: написания Personal Home Page штобы попроще. Java разрабатывалась как ЯП общего назначения. Поэтому JSP само по себе обычно не нужно, оне нужны как морда к оракулю и т.п. Соответственно для форумов достаточно PHP+MySQL, и JSP&Oracle в этой нише - оверхед

>Приведи пример известных сервисов, соответствующих этой спецификации.

amazon, ebay. Но дело не в них.

>Я вижу желательным применение таких продуктов как жбосс только в том случае, если необходимо произвести интеграцию разнообразных сервисов написанных на жабе

Если необходимо выставлять наружу сервис с которым будет интегрироваться кто-то еще.

>Всё это можно реализовать на PHP.

В смысле OASIS? Удачи вам в этом нелегком деле.

>А зачем там именно (soap) веб-сервисы?

С целью интеграции всяких разных клиентов - b2b и с2b

>Java для поддержки большого бизнеса ;).

За маленькие деньги ;). Без гарантий выплат. ;)

Это программа оказывающая услуги и использующая для своего функционирования систему гипертекста? ну это хотя бы программа?

http://www.oasis-open.org

>ютуб или гмайл с каких то пор стали вебсервисами? Troll harder, чувак.

Вообще то гугл предоставляют кучу (вчастности к гуглокалендарю и прочему) рестовых рервисов. Прозреваю что и к ютубу тоже.

>А для чего он нужен? Нет, ну серьезно, покажите задачи, которые без него сложно или невозможно решить? Зачем такой монстр нужен - непонятно.

Возьмем, к примеру, крупную компанию с ~40 тысячами сотрудников, которые должны работать с некоторым приложением. На вскидку возьмем некоторый документооборот. Компания работает по всему миру, приложение должно быть доступно 24x7. В компании туча подразделений, туча бизнес-процессов, туча разных документов, каждый с своим собственным путем в жизни :) Количество задач документооборота имеет тенденцию к постоянному росту в любой компании. Кроме того, пути согласования и жизнь каждого из документов имеют тенденцию меняться и разрастаться.

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

Что делать с 24x7 вообще непонятно: PHP как правило это один сервер (поправьте, если ошибаюсь, но кластерных решений на PHP не видел). В случае J2EE серверов может быть теоритически сколько угодно и все они будут работать как единый кластер с распараллеливанием нагрузки и единым управлением.

С масштабированием производительности в случае PHP пожалуйте наращивать или менять сервак, в случае J2EE просто ставим еще один узел кластера и вводим в эксплуатацию.

В случае всяких часто встречающихся в Enterprise задач автоматизации потока операций на PHP это придется все писать ручками со всеми вытекающими, на J2EE можно использовать workflow типа как этот (осторожно, трафик)

http://docs.jboss.com/jbpm/v3/demos/movies/jbpm-overview.htm

Опять же вернемся к всякого рода интерфейсам. В случае современного J2EE разработчикам можно забыть про HTML, JavaScript. Все делает сама J2EE система, разработчику можно сосредоточиться на логике и сути ПО. Это благотворно сказывается на качестве и скорости разработки.

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

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

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

>Прозреваю что и к ютубу тоже.

умеет в ответ плеваться xml

>Что делать с 24x7 вообще непонятно: PHP как правило это один сервер (поправьте, если ошибаюсь, но кластерных решений на PHP не видел). В случае J2EE серверов может быть теоритически сколько угодно и все они будут работать как единый кластер с распараллеливанием нагрузки и единым управлением.

кто-то мешает собрать кластер из апачей и mysqlей? в эффективное распараллеливание нагрузки не верю.

>в случае J2EE просто ставим еще один узел кластера и вводим в эксплуатацию.

прям какое-то волшебство

смотрел тут свободное groupware всё на PHP

>Вот http://en.wikipedia.org/wiki/Blue_Gene, нет ну серьезно, покажите задачи, которые без Blue Gene сложно или невозможно решить на обычном пецуке? Зачем такой монстр нужен - непонятно

если бы это было так, то вопросов про всякие jboss не было, jboss это пецук помощнее и с лампочками

>>Впрочем, есть более легковесные и функциональные аналоги, из которых можно собрать что нужно.

>Та ты шооооо? Ты .NET 4.0 & ASP.NET имеешь в виду?

наверное он имеет ввиду линукс + библиотеки на си + прямые руки

>кто-то мешает собрать кластер из апачей и mysqlей?
И что потом? Что с этим кластером делать то? Как поддерживать? Как программы писать? После каждого запроса пользователя в БД транзакцию коммитить? Или как-то пользователей по серверам распределять? А MySQL соответсвенно синхронизровать по таблицам? Ой-ой какая куча мала появится :)

>в эффективное распараллеливание нагрузки не верю.

А зря. Давно решенная задача. Причем не только в J2EE.

>>в случае J2EE просто ставим еще один узел кластера и вводим в эксплуатацию.
>прям какое-то волшебство

Тем не менее я делал это не раз :) И не только в J2EE, еще, например, SAP ABAP-системы очень неплохо масштабируются таким макаром.

>смотрел тут свободное groupware всё на PHP

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

Ой, да не доказывайте ему ничего. Он верит в глобальность и надежность PHP. Кесарю - кесарево. Что апач - это все же фронт-енд, и что кластер ему нужен на уровне PHP'шного рантайма он не поверит ;)

а мы и не знали что предоставляли (более десятка лет уже как - через CGI/Perl) и предоставляем (больше JSON, делимитед или фихед-ленгтх текст) веб-сервисы клиентам - в наиболее компактной для даты форме (никакого хмля). и большие объёмы, надо сказать. Ваш мерзкий виндузячий Soap загнётся 10 раз. И нечего кроме простых скриптов и сервлетов - не нужно. CGI параметры - более чем достаточны.
(только не надо пож., про сложность - EJB мы закопали давно как раз из-за того что сама технология привносит сложность, которая к задаче не относится, из-за локов, непредсказуыемости и плохого контроля за исполнением (неконтролируемый кеш, отложенные транзакции - зло которое ударит по вам потом, поверьте). Вебсферами/жбоссами в кремниевых долинах переболели году в 2002. Сейчас всё больше в почёте (по крайней мере у нас - простые решения, от томкатов с сервлетами, стратс, jsp за своими контроллерами до пхп)

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

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

пионеры, блин

Да, SOAP надо использовать с умом :)

А то видел раз решение, точнее попытку: прогружать в OLAP систему гигабайтные данные по SOAP ;)

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

>пионеры, блин

Поумничай давай тут. Иш ты чего удумал по РФЦ чтобы тебе протоколы писали, а не по рекламным даташитам.

Дружок, если хотя бы один этот РФЦ в голову загрузить - то больше ничего ты не осилишь. А кому хочеться быть узкоспециализированным специалистом и сидеть месяцами дожтдаясь подходящей задачи? А умничать тут на ЛОре много ума не надо.

Ну для магазинов, форумов и простых порталов использование J2EE действительно излишне. Тут я соглашаюсь.

Но под словом "портал" может крыться многое ;) Вот например видел я в одном банке "корпоративный портал" в котором собран весь функционал банка, начиная от операционного дня, кончая HR. Тут уже PHP мало.

> После каждого запроса пользователя в БД транзакцию коммитить? Или как-то пользователей по серверам распределять?

А Вы у гугля (именно эффективное распараллеливание), у ебея и других подобных учитесь. Благо материалов полно.

>Тут уже PHP мало.

Неужели?

Про ебей не скажу, а у гугля собственная платформа по сути написана. Кроме того, у гугля и сервисов то нету таких, какие встречаются на Ынтерпрайзе :)

>>Тут уже PHP мало. >Неужели?

Вот с огромным удовольствием хотел бы посмотреть на подобное решение и на тех, кто его развивает/поддерживает.

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

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

> Потому что дополнительный клиент-сервер уровень - выгодент только продавцам лицензий (апп-серверов пер проц/коре) или девелоперам которые сидят на проектах типа йбосса

Да разуй ты глаза, у джбосса свободная лицензия. LGPL уже тоже продают? Не знал-с.

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

я просто начинаю понимать - почему всё в ИТ валится, когда так-называемые эксперты которых ко мне присылают - обосновывают применение SOAPа: "а как-же иначе - весь нам надо клиенту через веб - данные отдать" или "в сессии? значит Session Bean". Это уже EJB-поколение. И называют себя специалистами ведь. В крупных компаниях.

> На, изучай http://en.wikipedia.org/wiki/Webservice

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

и ни одного примера

нет бы просто написать, вышла 5 версия веб фреймворка JBoss и всё

Бедный JBoss :) Теперь он уже просто веб-фреймворк :)

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

> Eugeny_Balakhonov ** (*) (07.12.2008 1:13:00)

вам бы преподавать где нить

> Знаю, не надо мне показывать - делал я проекты на джбоссе и делал то-же самое на томкатах.

Так а чего ты винишь джбосс в том, что для твоей задачи он был избыточен? Это не джбосс виноват, а тот кто принял решение об использовании джбосса) И не надо изворачивать, мы говорили о продаже джбосса самого как продукта, а не продуктов, построенных на джбоссе.

>> Между тем вопрос был вполне конкретный: решение каких задач без него или его аналогов неэффективно?

>Ну нарисуй вебсервисы на коленке.

Легко. Достаточно хибернейта, томката и хорошо сконфигурированного билда на втором мавене.

>Ну действительно, какая например система обслуживания - ссылку в студию.

>А то тут многие несут чуш, а просто пример показать не могут.

Да на тебе и забейся http://www.statravel.com/

> Что делать с 24x7 вообще непонятно: PHP как правило это один сервер (поправьте, если ошибаюсь, но кластерных решений на PHP не видел).

Wikipedia видел? думаешь они на одном серваке? :-)

Кластерные решения на PHP [+MySQL] строятся на ура...

> В случае J2EE серверов может быть теоритически сколько угодно и все они будут работать как единый кластер с распараллеливанием нагрузки и единым управлением.

покажите систему из 500 J2EE серверов, а? Теоретически их конечно может быть сколько угодно, да только выгода от добавления следующего сервера сойдет на ноль очень быстро...

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

> С масштабированием производительности в случае PHP пожалуйте наращивать или менять сервак, в случае J2EE просто ставим еще один узел кластера и вводим в эксплуатацию.

Давайте сравним самый большой проект на J2EE и на PHP?

почти во всех J2ее проектах, где я участвовал - люди вынуждены были отказаться от ентити-бинов и использовали сессион-бины из-за многих проблем. То-есть то-же самое на сервлетах/етс - было - бы несравнимо проще и быстрее делать (не надо ненужных референсов на хоме, получение бинов из JNDI). Ну подумайте - это-же полный идиотизм! (не говоря про проблему локов).
А люди платили мегабаксы за воздух (и архитекторы хорошо промыли мозги менагерам). Ну ладно - это было коллективное помутнение разума (как и с ХМЛ впрочем).
Базы и так делают распределённые транзакции, и намного ближе к железу и множествам, т.е. намного более еффективнее, чем наваляет через декларативные аттрибуты (с его-то знанием экз. планов, дб. схемы и пр.) - ж2ее-девелопер.
Вот поэтому и развиваыется ПХП. Потому-что нет лишних ненужных сущностей.
А жаль - на жаве можно тоже писать в стиле ПХП и даже чище (по-крайней мере - не сложнее)

> Опять же вернемся к всякого рода интерфейсам. В случае современного J2EE разработчикам можно забыть про HTML, JavaScript. Все делает сама J2EE система, разработчику можно сосредоточиться на логике и сути ПО. Это благотворно сказывается на качестве и скорости разработки.

И как это выглядит-то потом? Ограничившись набором встроенных HTML-элементов?

> Потом все эти EJB и прочее J2EE загоняет разработчика в некие стандартные рамки, что благотворно сказывается на унификации кода. Иногда как посмотришь иной Perl или PHP чужой - вешаться хочется сразу, а не ошибки искать. В Java все это проще в связи с вышеописанным.

Ой давно ли вы смотрели ? Не верю я в существование PHP-программиста, думающего что сайт на PHP - это обязательно "один сервер"...

> в случае J2EE просто ставим еще один узел кластера и вводим в эксплуатацию.

вам ж2ее-рекламки промыли мозги.

Все большие системы должны быть легко раширяемы вширь (как подключение дополнительных серваков или даже машин девелоперов на вечер - когда что-то экстремальное). ж2ее пытаыется делать всё. И делает это плохо.
Если сессии не умеете готовить в базах - то можно и стики использовать (поддерживаются всеми лод-балансерами и апаче-лод-беленс модулем).
Думаете в ж2ее что-то иное? (только над лод-балансером - у вас никакого контроля и оттого - ж2ее девелоперы выглядят обычно жалко, когда по ним жахнут реальной нагрузкой, и вся их теория из рекламмок - накрываыется медным тазом).
А нормальные люди - да хоть DNS раунд-робином всё разрулят - если надо. Или эвристику на группы айпишников. И пропустят миллионы запросов за час на обычных сервачках - порой чуть ли не PC-шками.

> Возьмем, к примеру, крупную компанию с ~40 тысячами сотрудников, которые должны работать с некоторым приложением.

web email сойдет? эдакий внутренний mail.ru? и когда посмотрим мы на публичные web mail сервисы, то почему то видим что на java их не пишут...

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

которого не потребуется на Java? Это с чем связано? PHP вообще более динамический язык чем java => можно обойтись меньшим объемом кода, но его может быть будет труднее поддерживать

> Это быстро приведет к появленю незаменимых людей в отдельно взятой компании :)

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

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

> Ну приходи, покажу на моем мониторе ;). Линк не дам, т.к. система пропиетарная, я связан NDAs. Кроме JBoss, кстати говоря, мы поддерживаем деплоймент и на куда более толстые вещицы: Weblogic и Websphere.

Вот поэтому вас и троллят. Вылезают вечно непойми откуда Ъ-энтерпрайзъ, учат жить, а ни одного примера своего Ъ-энтерпрайз аппликейшена показать не могут - все за фаерволами да за NDA.

Вы бы собрались вместе и одно общедоступное Ъ-энтерпрайз приложение написали бы для демонстрации? Или у вас вместе с NDA подписан договор о том что кроме метана мимо внутренней VCS ничего не выпускать?

ещё из моего опыта. ж2ее-девелоперы - никогда не могут сказать точно (или ошибаются в экстраполяции) - сколько нагрузки пропустит их так-называемый кластер при реальной нагрузке. Потому-что за них всё делают дяди, а когда потом начинаются проблемы с локами, нелинейным падением производительности (что дяди контролировать не могут, да и сами дяди - кто? - обычно такие-же ж2ее девелоперы, чаще не понимающие как работает ОС и не имеющие опыта администрирования), и в необходимости покупать новое и новое оборудование (а главное - платить и платить за лицензии). Ну, ИБМы как раз в этом и заинтересованы, поэтому и пиарят такие решения (налог на глупость - если у дурака есть деньги).
Можно-же делать 100-%-параллельный кластер как гугле и пр. И заранее знать - сколько тебе машинок надо еще на столько-то миллионов юзеров.
Выбор ваш - ж2ее или контроль.

К вопросу о применении: Банк-клиент у нас на JBoss (один из популярнейших кстати)

>ОС и не имеющие опыта администрирования

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

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

> К вопросу о применении: Банк-клиент у нас на JBoss (один из популярнейших кстати)

а что Вы там пользуете чего нет в томкате? Зачем JBoss?
(если конечно на замутили завязанную на JBoss кластеризацию)