Вышел JBoss 5.0.0

>понимаю

В чем? Потому что из вопросов этого не видно.

Угу, банк-клиент, это хороший пример.

Все, что я видел, это были быдлоклиенты к говнобанкам.

Если бы так весь интернет работал - не было бы никакого интернета.

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


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

>Предидущая транзакция завершилась - файл не записался - дальше что? Аблом?

А где я говорил что пишется один раз?? ;)
я понимаю как раз. не надо переворачивать.

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

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


примеры были приведены - к дискуссии о правильной маштабируемости (к тому - как надо просто скейлить вширь, а не строить кластеры на вебсферах)

> А где я говорил что пишется один раз?? ;)

Вообще ниче не понял.

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


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

Изобретай.

>примеры были приведены - к дискуссии о правильной маштабируемости (к тому - как надо просто скейлить вширь, а не строить кластеры на вебсферах)

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

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

для ихней архитектуры - нет разницы - что применять (сервлетаы или ПХП)
j2ее не нужно там

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

Есть разница. Ты видать думаешь что ебей - это такой большой вебсайт и ходят туда исключительно бровзером? ТАк вот там есть огромная куча вебсервисов по туче протоколов. С тем самым оазисом в том числе.

> Изобретай.

не надо изобретать. state-machine.
До первого действия - пишешь состояние 1 - начало (Каждая транзакция имеет таймаут - пишем start timestamp).
Следующий процесс (или мусоросборщик типа pump в посгрес) - просто проверяет - нет ли оставленных не-консистентных состояний (проще - чтобы конечно каждый за собой сам убирал, согласно его ID). В результате - никогда не будем иметь неконсистентных состояний (это как 2-phase-commit, только таких состояний может быть больше).

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

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

да не вебсфера его маштабирует! (Она там не нужна) а load-balancer и распаралеленная архитектура. работал бы и томкат

>Есть разница. Ты видать думаешь что ебей - это такой большой вебсайт и ходят туда исключительно бровзером? ТАк вот там есть огромная куча вебсервисов по туче протоколов. С тем самым оазисом в том числе.


опять двадц^Щвебсервисы.

вебсервисы - это HTTP. Ихние сервлеты - веб-морда к базе.

> До первого действия - пишешь состояние 1 - начало (Каждая транзакция имеет таймаут - пишем start timestamp).

Куда пишешь? Оно relayable? Туда записывается 100%?

> Следующий процесс (или мусоросборщик типа pump в посгрес) - просто проверяет - нет ли оставленных не-консистентных состояний

Это каких? Там где бабло уже ушло а файл на диск не записался?

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

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

>работал бы и томкат

Томкэт не умеет вебсервисов. Торкэт+Аксис - заменил бы.

Но ПХП - вообще не вариант.

>вебсервисы - это HTTP.

Это немножко сильно больше чем HTTP.

>Походу изобретаешь. Теперь вопрос господа знатоки - что было выиграно наколеночным изобретением двухфазного коммита кроме времени которое отправилось в страну прое#*:х вещей как говорят военные?

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


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

>Куда пишешь? Оно relayable? Туда записывается 100%?

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

>простота и отсутствие узкого места.

У тебя нет транзакций - стоит слететь тому месту где ты ставишь отметки и торба.


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

>Томкэт не умеет вебсервисов. Торкэт+Аксис - заменил бы.
>Но ПХП - вообще не вариант.


какая глупость!
почему мой CGI скрипт на перле, скажем, не веб-сервис? Почему тогда тот-же результат, возвращаемый сервлетом - не веб-сервис? ПХП?
Не B2B? не C2B?

Перестаньте читать рекламки!
Вы спаму в мейлах или рекламкам по моментальному снятию порчи/сглаза - тоже так верите?
Ведь вам же точно также втюхивают

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

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

>Почему такая вера в реализацию JTA (и в жабу)? подумай, что реально жаба процесс делает.

JTA вообще только айдишники гоняет.

ТЫ так и не ответил на вопрос - чего ты добился сделав свой велосипед.

>почему мой CGI скрипт на перле, скажем, не веб-сервис?

Во мля. Да веб сервис - купи себе пирожок. Ты видать думаешь что вебсервис - это любая хрень через веб отдаваемая вроде наклейки на жопе - ярлык. Если я твой мегаскрипт на перле спрошу ?wsdl - он мне отдаст схему как с ним работать? Не отдаст? Вот ты клиенту будешь объяснять почему он за пять минут и три рубля не может склепать клиента к твоему "вебсервису" с помощью вагона и маленькой тележки тулзовин а вместо этого должен подстраиваться под твой велосипед и писать свой велосипед только потому что ты слова "стандарт" не признаешь. Вот к амазону может. К ебею может. Возмет какой нить wsimport, wscompile, wsdlc или мышей в быдлостудии или эклипсе поводит - и готово - все сгенерилось. А к твоему поделию которое ты гордо называешь вебсервис - не может. Ахрененный у тя бизнесплан по продаже сервисов - называется трахайтесь все с моим нестандартным конем - вам http достаточно.

> У тебя нет транзакций - стоит слететь тому месту где ты ставишь отметки и торба.

транзакций (я тормознул - где сравнил логи оракла и козявку ЙТА.) нет и у JTA (они - в базах в любом случае)

JTA всего лишь (насколько я понимаю) - 2-phase-commit. А уж логи поддерживаются базами и сами роллбеки проходят там.

Чтобы ты понял хоть чуть чуть о чем я говорю:

зайди сюда: http://sdb.amazonaws.com/doc/2007-11-07/AmazonSimpleDB.wsdl

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

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

>Не сильно, но отличается - ты пишешь в базу а потом пишешль в базу что записал в базу. У тебя нет понятия грязных данных. Если эта вторая запись в базу не пройдет - ты попал.


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


> ТЫ так и не ответил на вопрос - чего ты добился сделав свой велосипед.

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

Чего добиваемся не-введением ещё одного узкого места?
надёжности вестимо, и отсутствия необходимости обслуживания.

это напоминает спор про очереди в базе и жава-очереди ;)

> Чего добиваемся не-введением ещё одного узкого места?

Кто тебе сказал что там будет узкое место? Ты уже научилдся определять узкие места безконтекстно задачи?

> wsdl - он мне отдаст схему как с ним работать? Не отдаст? Вот ты клиенту будешь объяснять почему он за пять минут и

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

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

apriori
если вводим дополнительную машину и от процесса на ней - зависит всё (слетает мамка на твоём JТА-сервере) - да, это узкое место. Во всех случаях -будет критична база (там надо failover по-любому). Но в твоём случае - надо ещё фаиловер и дорогое железо - на JTA сервер, и за ним пригладывать. А там начнёте и JMS и другие сервисы - то там, то здесь запускать. Вот по-этому всё так не надёжно у вас.
У меня - одна база (и масса - no-state машин).
Ну?

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

То есть не можешь - так и скажи.

Веб сервис это грбо говоря связка

Код который должен описать программист:

@WebService
some webmethod(other)
=>
_Контейнер_ в который этот код деплоиться - он _генерирует_ схему описывающую сервис и _валидирует_ запросы относительно нее
=>
схема
=>
клиент который генерируется из схемы.

У тебя ничего этого - банально нет.

Все твои слова про неоднозначиности - никакого отношения вообще к теме не имеют. Важно то что програмист пишет каплю кода, и за пять минут и три рубля все развернуто и работает и клиент генерируется еще за минуту минут - его вообще писать не надо. У тебя ничего этого - просто нет. И XML тут не при чем. При чем тут - стандарт и работающая схема.

>JSON - чистая дата, да ещё и намного компактней.

Экпериментально установлено в другом топике - хрена с два. Опять переваривать это не будем.

>apriori

Большевопросов не имею.

>. Вот по-этому всё так не надёжно у вас.

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

>Ну?

У тебя фантазия разигралась - там где у тебя 1 база - везде 1 база.

>Веб сервис это грбо говоря связка

всё это лажа, полная. очень специфичная и надуманная. маст дай.


короче, я - программист старой формации (жава-велосипеды меня раздражают, хоть я и знаю жаву очень хорошо: с 96 года),
и заявы типа хмл или соап или ж2ее - стандартны - бесят больше, потому что они ещё не успели прийти (когда успели стать стандартом? С ними ещё пионерия мудохается, а всё никак не может заменить старые работающие системы, а обещали ведь златые горы в конце 90-х), таки уже начинают дохнуть :)

выпью чайку на ночь - за простые протоколы, Ц, победу линукса во всём мире, возвращение мейнфреймов.. (шутка, - за кластеры баз данных, желательно иерархических), и пошёл я спать... :)

>всё это лажа, полная. очень специфичная и надуманная.

Можешь закрыть глаза - будет полное ощущение что реальности не существует.

>когда успели стать стандартом?

Когда были приняты стандартизирующей организацией. Скажи привет w3c и OASIS Open.

>а всё никак не может заменить старые работающие системы

Зачем их замещать? Шоб было?

ладно, напоследок (после чайка)

П.С.
как это сама откатывается?

это у вас плохой дизайн - если "много транзакций". Транзакция одна - либо она есть (_мы_ её коммитнули), либо - нет (_мы_ её роллбекнули).
если надо интегрировать много баз - лучше написать SP или триггер, т.е. свести всё как у меня - к одной базе.
А что делаете вы - это изобретаете велос^Щтранзакцию в яве. Ну хорошо, напишите SP на жаве - если очень хочется, и транзакционные границы будут опять внутри базы (SP будет апдейтить/инсертить в другие базы).

мои состояния - они для многих операций типа база,файл,база,файл и пр., т.е. чтобы навести порядок и иметь консистентное состояние базы с файлом.
Но до меня дошло сейчас: ты же локаешь всё и вся (и файловые операции у тебя внутри транзакции???) Вот это - атас. Сколько одновременно юзеров вы обслуживаете - 10 максимум?
Ну нельзя так злоупотреблять локами - даже таблицу надо думать - как не локать, а сделать дизайн так, чтобы локать на уровне рядов.
Я представляю - какие тормозные аппликации появляются при таком подходе...

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

Дизайн IMHO должен быть не со стороны жавы а со стороны базы. И дба идеально должен отдать SP API - уже готовых атомарных вызовов.

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

так понятно?

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

А любой т.н. "stateful" не превращается в "stateless", если state отправить тоже в БД? Заодно оно будет переживать выключение питания и нет проблем с балансировкой на приложение (вместо этого появляются проблемы с БД). Кто-нибудь рассматривал этот вопрос?

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

Разница между двумя buzzword во многом зависит от места их употребления. Для многих людей scalable -- необходимое условие для distributed.

> Если я твой мегаскрипт на перле спрошу ?wsdl - он мне отдаст схему как с ним работать?

А что случилось с SOAP::Transport::HTTP::Apache всякими? Совсем не работают?

> или мышей в быдлостудии или эклипсе поводит

Наблюдал студентов, меняющих ip адрес веб-сервиса при "диплое" учебного проекта через remove web-reference / add web-reference. Горько плакал.

> зайди сюда: http://sdb.amazonaws.com/doc/2007-11-07/AmazonSimpleDB.wsdl

Кстати год назад говорили, что потроха SimpleDB -- на Erlang.

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

А почему распределенную транзакцию должен делать *комбайн* типа JBoss?

Почему нельзя иметь SQL сервер, интергрирующий доступ к несколькми СУБД и умеющий распределенные транзакции?

А уж какие морды к этому серверу писать -- на яве или на РНР -- это личное дело девелоперов.

> А почему распределенную транзакцию должен делать *комбайн* типа JBoss?

Чтоб исключения в коде её обламывали? А ещё DT может участвовать и JMS, например.

> если надо интегрировать много баз - лучше написать SP или триггер, т.е. свести всё как у меня - к одной базе.

Я тоже придерживаюсь этой идеологии.

Если надо решать задачу предложенную r (файл и биллинг-где-то-там как транзакция), то

1. Проще всего предоставить морде унифицированны бэкенд в виде базы, а в базе сделать:

А. триггер, пишущий на диск переданное триггеру (якобы для блоба) содержимое файла

Б. триггер, опрашивающий биллинг, и все это будет в рамках транзакции базы.

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

(Более правильно было бы иметь БД, хранящую блобы как файлы, доступные на чтение и принимающую путь к файлу как контент для блоба.)

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

Далее морду можно написать на любом языке. Причем тут ява? Это сановский пиар. (РНР кстати не лучше явы, но там хоть такого истошного пиара нет)

_______________________________________________

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

Жаль что ты анонимус. У тебя жаббер есть?

>> А почему распределенную транзакцию должен делать *комбайн* типа JBoss?

> Чтоб исключения в коде её обламывали? А ещё DT может участвовать и JMS, например.

Я тебя не понял, выскажись поподробней.

> К примеру, почему не популярны хостинги простых JSP-приложений, по функциональности сопоставимых с LAMP? Ведь для JSP не нужен весь стэк JEE-библиотек и разворачивается оно легко и непринуждённо (кстати, без Apache можно обойтись — одним лишь Tomcat); опять же, заявлена кластеризация и балансировка нагрузки.

Ты меня спрашиваешь? Понятия не имею.

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

Серверная часть, я надеюсь? ;)

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

Прямые руки это от €5000/мес и выше? От к.т.н. и 10 лет ковыряния в исходниках ядра и выше? И где же ты столько прямых рук найдешь для автоматизации каждого бизнеса? Лукойлу надо прямые руки? Надо. Газпрому надо прямые руки? Надо. ВТБ надо прямые руки? Надо. Где ж их столько взять? И потом, у каждых прямых рук свое вИдение правильного линукса, у кого-то это Debian, у кого-то RedHat, у когото Kubuntu, у кого-то Мандрива. А Java всего одна, если не брать Websphere конечно, но это сразу вендор локин.

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

Смешной. На ASP делают. Открой http://www.techhome.ru для примера. Потому что на PHP такое в жизни не успеть сделать. http://www.longlivers.ru/portfolio.htm

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

Приходи к нам. Нам как раз такие люди стали очень нужны. Зарплату в 15000 руб гарантируем. Адрес: Житная, 6, МВД

У Гугля? Транзакции? Да еще и распределенные? Tell me moar, я хочу об знать!

И конечно же у гугля все пишет один Василий Пупкин на PHP в лаптях, за килоевро в месяц, да?

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

Да, в крупных компаниях. Пока ты будешь месяц писать прогу на C/PHP, которая из базы данных по телнету отдавать данные, люди десятком кликов мышкой в VisualStudio за 20 минут сделают то же самое. Зайди хотя бы сюда rsdn.ru/Forum/group/dotnet.web.aspx и сюда http://www.gotdotnet.ru/Forums/Web/default.aspx и посмотри, что там в отличие от LOR обсуждают. И сравни функциональность techhome.ru написанного на ASP, и linux.org.ru в котором, при всем моем уважении к минимализму и дизайну, CSS & XML уже 5 лет как прикрутить не могут. И почему я не могу постранично читать ветку с удаленными комментариями? А должен грузить добрый мегабайт, если ветка больше чем на 15 страниц? Поэтому пока вы на C месяцами реализуете по RFC стандарты, люди уже пользуются готовыми, сделанными на жабе ли, на дотнете ли, но УЖЕ сделанными

Давай, доставай свой самый большой сайт на PHP. Вот сайт на Java Spring http://www.nfl.com/

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

gmail?

c:smokers

> И сравни функциональность techhome.ru написанного на ASP, и linux.org.ru в котором, при всем моем уважении к минимализму и дизайну, CSS & XML уже 5 лет как прикрутить не могут.

А еще можно сравнить ЛОР и РСДН, например, у которого постоянно не работает то поиск, то форум, то и то и другое (я уже не говорю об удобстве использования). А ЛОР вот простенький, убогий, где-то не очень удобный, и смотри ка подлец, работает и не жужжит :)