Вышел JBoss 5.0.0

>CGI параметры - более чем достаточны.

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

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

пионер блин.

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

Серьезно? И кто у тебя будет по соапу отдавать все что нужно в этом списке? Кто будет деплоить сервисы и строить wsdl?

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

statless, transactionless, сервис со смешным функционалом. Нашел что приводить в пример.

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

ibm.com. Сравнивай.

А unix-way утилита для делания таких вызовов есть? Для cgi - wget и curl, а soap-вызов чем сделать? ( я понимаю что curl'ом вообще-то можно, но хотелось бы что-то более заточенное... мы же не пользуемся одним nс для всех нужд..)

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

Боюсь мы о разном. Характер сервисов Wikipedia ни в коей мере не соответствует Ынтерпрайзу. Это все лишь разновидность новостного сайта или даже морды к базе данных. Из основного функционала - поиск да показ/редактирование статей. Вещи подобного рода не нуждаются в кластеризации на уровне сервера приложений. Достаточно иметь хааааарошую СУБД, а веб-морд можно поставить сотни.

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

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

В догонку, расскажите как мне на PHP штатными средствами сделать распределенную транзакцию сразу на несколько СУБД (бывает разнотипных) и на несколько серверов приложений? Такие вещи не нужны веб-проектам, но нужны корпоративным приложениям. Даже если вы создадите такое на PHP, то что будет с транзакцией если сервер на котором началась транзакция внезапно умрет? Гуглю, википедии и иже с ними на такое наплевать ибо просто нет таких задач.

> Давайте сравним самый большой проект на J2EE и на PHP? По количеству серваков меряться бесполезно: как я выше писал для простых задач уровня новостного сайта можно поставить хоть миллион PHP/Apache/MySQL, особенно если 99% запросов на чтение данных.

Возьмем задачи другого рода - назовите мне банковскую систему, писанную на PHP, ERP-систему и т.д.?

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

>web email сойдет?

еще один statless, tranactionless сервис со смешным функционалом - масштабируется линейно dns rr.

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

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

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

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

Ну о разных мы вещах говорим, о разных.

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

http://aws.amazon.com/

http://highscalability.com/amazon-architecture

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

>statless, transactionless, сервис со смешным функционалом. Нашел что приводить в пример.

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

> ibm.com. Сравнивай.

ужосна#.

мне приходилось плотно им пользоваться - он глючит нечеловечески, stateful настолько, что запомнить где ты был невозможно - URL'ки любители состояний сделали бесполезными, разным людям оно показывает разное. И глючил он довольно часто.

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

>Для cgi - wget и curl, а soap-вызов чем сделать?

wget или curl

>я понимаю что curl'ом вообще-то можно, но хотелось бы что-то более заточенное... мы же не пользуемся одним nс для всех нужд..)

Обычно сервер деплоящий вебсервисы предоставляет вебинтерфейс где можно совершить тестовый вызов. Есть еще тулзы типа mindreefовской хрени которая строит формочки по WSDL и позволяет делать вызовы.

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

Модуль "похерили" потому, что тот же TomCat прикручивается к апачу без проблем. При этом апач занимается тем чем ему положено - HTTP запросами, а TomCat уже просто Servlet Container

>web email сойдет?

> еще один statless, tranactionless сервис со смешным функционалом - масштабируется линейно dns rr.

дык а есть/нужны ли вообще stateful если все вокруг stateless?

>мне приходилось плотно им пользоваться - он глючит нечеловечески,

Ты поищи портал сравнимый с ibm.com по размерам.

>Даешь полустатические вебсайты с небольшими вкраплениями функционала там где он собственно нужен - где что-то продают и тд

Угу- предложи бимерам свои услуги - все ж просто ты их глобал сервисес как два пальца об асфальт переделаешь и упростишь.

> соап вызов который делается за 30 секунд кликом мыши или компиляцией WSDL

этим всё сказано.
Сколько не говорил с фанатами СОАП, WSDL, Й2ЕЕ - виндузоиды поголовно.

> что такое промышненный стандарт

ну ни надо мне - про такие "промышленные" стандарты! Я в промышленности давно, до появления жабы. Это вы хотите их такими видеть. RFC1945, RFC2616, RFC2045, RFC821 - это стандарты, да. А выкидыши М$, Сана и ИБМ (которые сиречь заинтересованные лица) - отомрут сами, поверьте. (посмотрим, ок?)

про ХМЛ я Вам уже говорил в недавнем треде.

>дык а есть/нужны ли вообще stateful если все вокруг stateless?

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

Ну сходи на http://www.sdn.sap.com Это пример J2EE для веба, весьма большая и сложная штука.

Опять же повторю, для J2EE Веб - всего лишь одно из возможных применений.

>этим всё сказано.

Этим сказано что ты вообще не видел больших систем.

>отомрут сами, поверьте. (посмотрим, ок?)

Смотри смотри. Пока ты смотришь и ждешь когда ж оно умрет - на этих стандартах делаются огромные деньги. Если из линукса выкинуть жабу с ее ж2ее - линуксу на серваках придет звездец полный. Будет ниша такая же как у бсд - былохостинги пхп.

>про ХМЛ я Вам уже говорил в недавнем треде.

~475 тысяч британских фунтов за ноябрь. Это ненужный тебе XML настрогал. Посредством передачи данных и соап вызовов. Так что жди дальше.

>>мне приходилось плотно им пользоваться - он глючит нечеловечески,

> Ты поищи портал сравнимый с ibm.com по размерам.

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

>>Даешь полустатические вебсайты с небольшими вкраплениями функционала там где он собственно нужен - где что-то продают и тд

> Угу- предложи бимерам свои услуги - все ж просто ты их глобал сервисес как два пальца об асфальт переделаешь и упростишь.

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

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

один из крупнейших ретейлеров сев. америки использует жбосс. Настолько крупный - что вы его знаете. Я просто имя не могу назвать из-за НДА. Я знаю начинку и могу ответственно заявить - что жбосс там не нужен, и я бы сам портировал всё на томкат.
ПХП не знаю, но подозреваю - что можно было-бы тоже самое написать и на ПХП.

> Re: Вышел JBoss 5.0.0 >Вы бы собрались вместе и одно общедоступное Ъ-энтерпрайз приложение написали бы для демонстрации?

http://aws.amazon.com/

http://highscalability.com/amazon-architecture

это морды.. а исходник, чего там врутри можно скачать? можа там на PHP все :-))

>>про ХМЛ я Вам уже говорил в недавнем треде.

>~475 тысяч британских фунтов за ноябрь. Это ненужный тебе XML настрогал. Посредством передачи данных и соап вызовов. Так что жди дальше.

у нас взяток на таможне больше набирают... без всякого xml...

> это морды.. а исходник, чего там врутри можно скачать? можа там на PHP все :-))

Ага, исходник тебе. Седину в бороду, бес в ребро. Ты, судя по всему, не знаешь даже расшифровки аббревиатуры NDA. А раз так, значит никогда и не подписывао такие документы. А раз так, с чем таким же ты работал, что с тебя этого не потребовали? Кофе разносил?

Пионер, ёптв.

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

Если тебе там что-то не надо - это не значит что никому это не надо.

>развал портала - дело времени...

Я смотрю вы все на это молитесь - что со временем все исчезнет что вам не нравиться. Намек - жизнь она движеться постоянно а не идет к конкретной точке где все будет так как вам хочется. Суть жизни в процессе. Если через 20 лет XML исчезнет - это не отменит того факта что целая индустрия в процессе жала на этом. Цель XML обеспечить жизнь в это время - а не приблихзинтся к некой абьстрактной точке доказав некий идеал. На идеал насрать - через 20 лет уже не будет не таких языков ни технологий. И цель j2ee не доказать через 15 лет что она идеальна - а работать сейчас.

>это морды.. а исходник, чего там врутри можно скачать?

А ты кроме картинок - еще на буквы посмотри - особенно по второй ссылке.

> В догонку, расскажите как мне на PHP штатными средствами сделать распределенную транзакцию сразу на несколько СУБД (бывает разнотипных) и на несколько серверов приложений? Такие вещи не нужны веб-проектам, но нужны корпоративным приложениям. Даже если вы создадите такое на PHP, то что будет с транзакцией если сервер на котором началась транзакция внезапно умрет? Гуглю, википедии и иже с ними на такое наплевать ибо просто нет таких задач.

это да. в PHP такого нет.

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

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

нету ее, неограниченной калабилити-то, при общей транзакционности...

> Ага, исходник тебе. Седину в бороду, бес в ребро. Ты, судя по всему, не знаешь даже расшифровки аббревиатуры NDA. А раз так, значит никогда и не подписывао такие документы. А раз так, с чем таким же ты работал, что с тебя этого не потребовали? Кофе разносил?

расшифровку знаю, от подписания уклонялся. Работал над теми частями системы, которыю было не стыдно внешнему миру предъявить, посему NDA не требовалось :-P

Ага, еще расскажи как ты за идею работал и что тебе денег совсем пе надо.

>С транзакциями в распределенной системе-то это - либо приходится иметь некий центр

либо ты покуришь доки что такое X/Open Distributed Transaction Processing Model и зачем этот совершенно не нужный функционал наличествует даже в mysql - насовали ынтырпрайз-бреда в любимую базу пыхеров.

> Если через 20 лет XML исчезнет - это не отменит того факта что целая индустрия в процессе жала на этом.

А при чем здесь вообще XML? XML-формат обмена, а мы вроде про stateful сервисы и транзакции разговариваем?

> Угу- предложи бимерам свои услуги - все ж просто ты их глобал сервисес как два пальца об асфальт переделаешь и упростишь.

да что Вы у вас ИБМ - такой авторитет?
(я частенько там бываю, и пару друзей работает). Это-же мега-контора, где на местах могут быть профаны почище частных контор (из-за размеров). А цели у них - как у всех коммерсантов - побольше завязать на себя и стричь потом.
Никто о наиболее эффективном расхoдовании средств клиентов не заботится ;)
И пиарить у себя они тоже будут те технологии, где надо больше ресурсов, процессоров и пр (чтобы больше были лицензионные сборы на ту-же вебсферу).
Снаружи пользоваться легко, а нужен шаг в сторону - ыды суда, покупай консультантов за полторы сотни в час или ждите, ждите годик, когда мы выпустим очередное баговое-тормозилово за ваши следующие честно заработанные баксы.

> либо ты покуришь доки что такое X/Open Distributed Transaction Processing Model и зачем этот совершенно не нужный функционал наличествует даже в mysql - насовали ынтырпрайз-бреда в любимую базу пыхеров.

model - это хорошо. я только одного не могу понять - если ваш распределенный транзактор так хорош, зачем кто-то покупает Oracle RAC а не пользуется вашей штуковиной? Зачем покупают дорогие сервера а не ставят кучу дешевых машин?

>да что Вы у вас ИБМ - такой авторитет?

Нет - у нас это пример реализации сложного портала ахрененных размеров.

> model - это хорошо. я только одного не могу понять - если ваш распределенный транзактор так хорош, зачем кто-то покупает Oracle RAC а не пользуется вашей штуковиной?

Дядя, да ты вообще профан. Лучше помолчи и не позорься. Ты сказал что-то вроде "зачем люди ездят на машинах если есть способы передвижения".

> А при чем здесь вообще XML? XML-формат обмена, а мы вроде про stateful сервисы и транзакции разговариваем?

это у нас с r давняя дискуссия - он знает.

> либо ты покуришь доки что такое X/Open Distributed Transaction Processing Model и зачем этот совершенно не нужный функционал наличествует даже в mysql - насовали ынтырпрайз-бреда в любимую базу пыхеров.

открыл картинку, увидел transaction manager. Он в системе один? если да, то как достигается масштабируемость?

>если ваш распределенный транзактор так хорош, зачем кто-то покупает Oracle RAC а не пользуется вашей штуковино

послушай - даю тебе совет - ты полез в область в которой не имеешь даже поверхносного представления. X/Open DTPM, так называемые XA-транзакции - это промышненный стандарт - это поддерживают все базы (вот и мускуль недавно научился). так что завязывай высказываться о чем-то таком не прочитав хотя бы в википедии что это такое. RAC - Это кластер - как он по твоему осуществляет контроль транзакции на разных физических инстансах? Да вот через этот XA и осуществляет. И если я захочу например на жабе сделать запись в какой-то файл подчиняющийся общей транзакции - я реализую его как JTA-ресурс и он включится в одну распределенную транзакцию которую можно запустить через оракл рак, стоящий в стороне мускуль и по файловой системе - и это будет одна транзакция.

> Дядя, да ты вообще профан. Лучше помолчи и не позорься. Ты сказал что-то вроде "зачем люди ездят на машинах если есть способы передвижения".

То есть RAC (имеющий пределы масштабирования) лучше чем ваш транзактор (по вашим словам их не имеющий) ?

> model - это хорошо. я только одного не могу понять - если ваш распределенный транзактор так хорош, зачем кто-то покупает Oracle RAC а не пользуется вашей штуковиной? Зачем покупают дорогие сервера а не ставят кучу дешевых машин?

он как раз - порождение ИБМ, сана с ихней жабой и прочих. Тех, кто недавно корбу впаривал.
А базовики знают, что джойны надо делать "чем ниже тем лучше", не надо качать данные через сеть туда-сюда.
Вива мейнфреймы! ;) (я пошутил: дб-кластеры)

>открыл картинку, увидел transaction manager. Он в системе один? если да, то как достигается масштабируемость?

Ты понимаешь в чем разница между масштабируемостью и распределенностью?

>Нет - у нас это пример реализации сложного портала ахрененных размеров.

в наше тяжёлое время - более экономичные модели будут намного лучшим примером. (опять повторюсь: как кластеры ebay, гугла etc)

спасибо, я эту схему себе вполне представляю.

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

>более экономичные модели будут намного лучшим примером. (опять повторюсь: как кластеры ebay, гугла etc)

Ох ну е-мое теоретики:

http://highscalability.com/ebay-architecture

# Java
# Oracle
# WebSphere, servlets
# Horizontal Scaling
# Sharding
# Mix of Windows and Unix

>Возьмите несколько ораклов и начните их координировать, будете лучше чем RAC?

Ты вообще не понимаешь что спрашиваешь. Повторю вопрос - ты понимаешь разницу между терминами scalable и distributed?

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


А проще - писать в табличку-лог (states) и потом вначале проверять - завершилась ли предыдущая транзакция.
О том и разговор - что для джавистов - распределённые транзакции - это их JTA-классы. А профессионалы это делали и до жавы и 15 и 25 лет назад и очень просто и надёжно - путём логов (то как это базы реализуют).
И по времени профессионал это пишет быстрее - чем некоторые разбираются с жаба-библиотеками, включая более эффективные языки, как-то Ц или ассембли (если T. координатор один - он же должен быть быстрым ;)

Ох ну е-мое теоретики:

http://highscalability.com/ebay-architecture

ВОТ. там прямо на странице и написано "Avoid distributed transactions" :-))

> Ты вообще не понимаешь что спрашиваешь. Повторю вопрос - ты понимаешь разницу между терминами scalable и distributed?

понимаю

(ушел спать, завтра сюда загляну)

>А проще - писать в табличку-лог (states) и потом вначале проверять - завершилась ли предыдущая транзакция.

Предидущая транзакция завершилась - файл не записался - дальше что? Аблом? Откатывать нечего? Это тебе намек номер раз. Намек номер 2 - ролбек может вызвать совсем не твой код - а он должен произойти.

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


>И по времени профессионал это пишет быстрее

А потом оно нихрена не работает - потому что по ходу професисионал даже не представляет что такое транзакция.

>ВОТ. там прямо на странице и написано "Avoid distributed transactions" :-))

Ага. Теми люлдьми которые понимают что это такое. И тем не менее - не вижу пыха в списке победителей. Почему то вижу жабу/ee.

>http://highscalability.com/ebay-architecture

No client-side transactions. no distributed transactions

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