Смотрю я на эту ветку и думаю, когда же, наконец, начнут обсуждение реализации stateful-модели в J2EE/EJB-сервере(рах) приложений. Видимо, не дождусь... ;(
MS напирает на stateless-модель из-за сложности реализации другого в COM+ (механизм моникёров требует прямоты рук) — это понятно. И здесь, видимо, собрались практики и знатоки именно технологий от MS (BizTalk, например, упоминается очень часто), а альтернативы нету.
Что скажете? Интересно было бы послушать альтернативщиков платформы MS, прежде всего из стана Java.
Hello, "Геннадий Васильев" > > Новое обобщение. Это ещё откуда? Знаешь, мне подобные обобщения иногда напоминает что-то вроде: "Ну как мы все знаем, американцы никогда на самом деле не были на Луне..." и дальше длинные ругательные рассуждения, на основании этой "посылки". Извини, не обижайся. Просто постарайся повнимательнее обходиться с таими эпитетами. Знаешь, SQL-сервер тоже всего лишь тупо хранит данные на диске. >
Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью). Вобщем — хотелось-бы видеть конкретные продукты и приимеры реализации. Может тогда и вопросы сами собой отпадут?
Вот например сервер без GC. Замечательно — давайте рассмотрим stateless vs COM+ и реализация бизнес объектов на С++?
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Merle, Вы писали:
AVK>>Вот только когда в пределах одной транзакции у тебя несколько обращений к серверу для модификации это уже как бы не совсем стейтлес . M>А зачем несколько?
Затем что надо
M>Можно прогнать всю транзакцию и за одно обращение.
Здравствуйте, TK, Вы писали:
TK>Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью).
Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят? Да собственно и СОМ+ отнюдь не ограничивает разработчика определенной моделью.
Здравствуйте, IT, Вы писали:
AVK>>А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП.
IT>Вот что и требовалось доказать
Да я собственно изначально об этом говорил.
AVK>>Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?
IT>Дать ему уникальный guid при создании.
Это уже решение проблемы средствами бизнес-логики, о чем я и говорил.
IT>Откуда сделан такой вывод?
А вот предложения ТК и твои лучшим образом это подтвердили. И он и ты постоянно предлагаете мне править прикладной код для решения задачи управления.
IT> Пока я вижу, что ты не теми средствами решаешь поставленную перед тобой задачу.
Я? Я пока что ничего не решаю. Я собственно и решения то не предлагал никакого.
IT>Возьми BizTalk и не мучайся (правда он стоит зараза),
Отож.
IT> переписывать бизнес-правила тебе не придётся. Только перерисовывать
Это уже детали. Впрочем в данном конкретном случае может оно и прокатит. Не зальешь дистрибутив на сервер?
AVK>>А про отдел автоматизации ни я, ни, насколько понимаю, ГВ и не говорят. Если ты ведешь речь об отделе автоматизации то безусловно в большинстве случаев единственный способ применить трехзвенку это либо использовать готовое решение, либо писать чисто стейтлес приложения с минимумов внутренних взаимосвязей.
IT>Ты делаешь свою систему как коробочный продукт или на заказ/для своей конторы?
Черт его знает. Пока точно не известно. Вероятность того что это будет коробка не нулевая. Даже если это будет внутренний продукт совершенно точно его будут пользовать внедрюки в различных филиалах.
IT>Твоя задача не изобрести ещё один BizTalk, а максимально быстро и с наименьшими затратами решить поставленную задачу.
Спасибо что разъяснил . А бизтолк не катит, его стоимость для конечного решения будет дороже того за что можно наш продукт продать .
AVK>>Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.
IT>Это тут при чём? Или у стэйтфул программистов есть секретарши, которым они надиктовывают свой код?
Нет, у них есть сервер приложений.
IT>Код то всё равно писать
Код управления состояниями?
AVK>>Разумеется. Только у стейтлес эту осведомленность проявить куда меньше возможностей. Сам же призаешь что в стейтлес модели основная тяжесть разруливания состояний ложится на sql сервер. С одной стороны это очень хорошо, особенно в малобюджетных проектах. Но с другой стороны это же ограничивает простор для оптимизации на основе метаданных бизнес-логики. Как всегда надо выбирать золотую середину.
IT>Ничего оно не ограничивает. А совсем наоборот. Благодаря простоте реализации stateless оставляет больше времени, чтобы бегать по этим просторам.
Ну да, вроде хранения состояния в БД всегда, даже если его хранить то надо десяток секунд.
AVK>>Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.
IT>Ну и как это противоречит stateless модели?
У ней состояния нет, оптимизировать нечего .
IT>>> Да, действительно, в stateless БД является центральным звеном, но все усилия сервера как раз и направлены на снятие нагрузки с сервера базы данных.
AVK>>Хороши усилия — после каждого запроса скидывать состояние в БД
IT>Подожди, подожди. А разве у тебя состояние объектов может не соответствовать их состоянию в БД?
В незакрытой транзакции? Может конечно, иначе ради чего огород городить?
IT>>>Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию , давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.
AVK>>Зря.
IT>Зря что не отличаются?
Зря что давно не был
Зря сомневаешься конечно.
AVK>>Разница в размерах предприятий и количестве изменений законов и порядков начислений в единицу времени.
IT>Порядки начисления — это бизнес логика.
А кто спорит. Просто необходимость непрерывно переписывать бизнес-логику начисления приводит к возрастанию фактора простоты написания этой бизнес-логики. Ты думаешь почему у 1С предприятия практичеси полное доминирование на рынках малых и средних предприятий? А вот в Америке почему то подобных решений не замечено.
IT>>>Слова мужа Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.
AVK>>Слова Стива Шварца помнишь?
IT>Какие именно
Те самые, которые я процитировал в самом начале.
IT>>>Возможно. Насочинять можно много чего.
AVK>>Ну он вроде как говорил где именно та или иная схемка реализована на практике.
IT>На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.
Напиши ему.
AVK>>Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе.
IT>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок
Так идея то в том чтобы это реализовать один раз, а не каждый раз когда нужна новая бизнес-логика.
AVK>> Кроме того не следует пытаться надуть муху до размеров слона. Если начинали с решения для малых предприятий пытаться потом получить из этого кластерного монстра неразумно.
IT>Ты так думаешь потому что тебе это просто пока не приходилось делать
И, надеюсь, не придется. В технических авантюрах, вызванных бредом воспаленного разума технически безграмотных менеджеров участвовать не собираюсь.
AVK>>Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.
IT>Что-то я тут опять мало что понял. Закладвать в архитектуру расширяемость можно и нужно всегда.
Разумеется. Но не до бесконечности же. Вот ты например закладываешь в архитектуру возможность работы не только с CLR, но и с JVM?
Здравствуйте, IT, Вы писали:
IT>Это само собой. Просто stateful это хорошая питательная среда для выращивания крупномасштабных глюков. Так что кривые руки + stateful... просто страшно подумать что может получиться.
Кто бы спорил. Создание серверов приложений было и пока что есть одна из самых сложных задач.
Здравствуйте, IT, Вы писали:
IT>Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы. Так вот для написание и оптимизацию SQL запроса у меня уйдёт на порядок меньше времени чем у тебя на реализацию запроса к ОО модели.
А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.
ГВ>>С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?
IT>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению.
Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.
Здравствуйте, Merle, Вы писали:
M>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.
С чего бы это? Вместе с промежуточными состояниями при отключении электричества навернутся и все незакоммиченые изменения. Это sql сервер, поскольку вносит изменения сразу на диск, вынужден поддерживать персистентный же лог транзакций.
Здравствуйте, Merle, Вы писали:
M>Что значит "типа"? одно из свойств ACID, а именно D, подразумевает, что если транзакция зафиксировалась, то откатить ее уже нельзя никаким образом. Вообще. Как ты ее собираешься в памяти фиксировать?
А какой смысл фиксировать транзакцию в памяти?
M>Ок, эксепшена не произошло, сказали commit, чего делаем?
Пишем в БД разумеется.
M>А она у тебя по прежнему в оперативке, как я понял.
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>самое забавное, что если ты двадцать раз изменяешь один и тот же объект — в лог пишется 20 записей (почему-то)
Наверное потому что сжатие лога, если этот лог на диске, очень дорогая операция.
H_D>+1 плюс к тому же, можно в памяти хранить часть особо часто используемых индексов — это даст возможность еще больше разгрузить компьютер, так как на текущий момент самое узкое место всех AppServer'ов да и вообще серверов — это дисковая система.
Я бы сказал немножко более обще — подсистема хранения и доступа к данным.
Здравствуйте, AndrewVK, Вы писали:
TK>>Что, если мы пишем метод который в рамках одной транзакции пишет => читает => обновляет то это уже не stateless метод?
AVK>Если транзакция распространяется на несколько методов то уже не стейтлес, ибо транзакция суть состояние.
Это уже не состояние, а демагогия. С тем-же успехом можно сказать, что транзакция это процесс перехода из одного устойчивого состояния в другое устойчивое состояние. А учитывая, что две разных транзакции изолированы друг от друга — можно сказать, внутрее состояние транзакции является неопределенной величиной для стороннего наблюдателя. Так что-же это за состояние, которое нельзя ни измерить, ни увидеть?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>100%-ная выполнимость обещания durability может быть обеспечена только при корректной эксплуатации, что справедливо и для SQL-серверов, и для App-серверов. И вообще для любых систем с промежуточным хранением данных.
СУБД обеспечивает 100% durability при сколь угодно не корректной работе, если при этом носитель физически в порядке. Причем он делает это автоматически при любых сбоях.
А если еще и DBA с прямыми руками, то даже физическая порча диска не страшна. И вместо того, чтобы добиваться такого эффекта в рукопашную, можно направить кипучую энергию в каком-нибудь более полезном направлении..
AVK>А какой смысл фиксировать транзакцию в памяти?
А это не я придумал..
M>>А она у тебя по прежнему в оперативке, как я понял. AVK>Неправильно ты понял.
Ну почитай сообщение ГВ с которого все началось. Он-то как раз пропагандирует отложенную запись в БД, то есть фактически фиксацию в памяти..
Здравствуйте, IT, Вы писали:
H_D>>Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
IT>Что значит залезть внутрь? Речь о хаках или о преднамеренном обходе программистом ограничений модели?
Речь идет о потенциальной ненадежности выполнения кода на клиенте. Причем необязательно это чей то умысел. Может просто взглюкнуть комп.
H_D>>Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.
IT>Первичная валидация данных, например. Зачем гонять на сервер строчку "bla-bla-bla", если известно, что она должна содержать маску ###-###-####?
Но при этом проверку обязательно нужно повторить на сервере.
IT>For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces.
Вот говорю же я что ты от российских реалий слишком отдалился. Проблема обновления софта по всему миру в тысячах офисов перед большинством российских компаний пока не стоит. Честно говоря лично меня мало волнует необходимости работы разнообразнейших версий софта с одним сервером, достаточно обеспечить гарантию работы только нужной версии и легкость обновления до этой версии. Проверить и скачать при необходимости версии интерфейсных сборок не сложно.
IT>Don Box
Это тот самый, который хочет коммуникацию между доменами через soap делать?
IT>Это лишь одно из мест где Дон Бокс пока осторожно упоминает, что на ООП мир клином не сошёлся.
Нифига себе осторожно! Если читать не тех. документацию, а маркетинговые реляции так МС уже вовсю провозгласил отказ от ООП. Тока провозглашать можно еще долго, но пока .NET еще не стал просто средством написания веб сервисов.
По словам моего начальника, когда он у вышеупомянутого товарища попытался узнать, а как же все таки быть с транзакциями, он получил ответ что мол вот есть же в индиге ремоутинг, им и пользуйтесь.
Вобщем опять сплошное определение погоды по почтовому индексу. Может в штатах это и актуально, а вот в России пока нет, и подобные технологии вряд ли станут особо востребованными.
IT> Тем не менее основаная мысль вполне ясна — share schema and contracts, not class. Под это в основном и заточен Indigo.
Поправочка — Indigo Application Services, но не Indigo Remote Objects.
IT>Так что IT>Кто там год назад с упорством защищал C++? Пришла пора встать на защиту ООП! Вперёд!
Это H_D то С++ защищал? Текс, H_D, признавайся, это под каким же ты ником мог позволить себе подобные безобразия?
IT>Хана твоему ООП. Сегодня рулят схемы и контракты
Пока что только на бумаге.
IT>Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят.
Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.
IT>Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества
Здравствуйте, iZEN, Вы писали:
ZEN>MS напирает на stateless-модель из-за сложности реализации другого в COM+ (механизм моникёров требует прямоты рук) — это понятно.
Если ты еще не в курсе то СОМ+ МС уже вобщем то похоронил
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, iZEN, Вы писали:
ZEN>>MS напирает на stateless-модель из-за сложности реализации другого в COM+ (механизм моникёров требует прямоты рук) — это понятно.
AVK>Если ты еще не в курсе то СОМ+ МС уже вобщем то похоронил
Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом
Здравствуйте, AndrewVK, Вы писали:
M>>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.
AVK>С чего бы это? Вместе с промежуточными состояниями при отключении электричества навернутся и все незакоммиченые изменения.
Правильно. Но по сценарию ГВ, с отложенной записью в БД, и закоммиченые тоже, поэтому durability и идет лесом.
AVK>Это sql сервер, поскольку вносит изменения сразу на диск, вынужден поддерживать персистентный же лог транзакций.
Вот здесь есть нюансы.
Систем журналирования может быть несколько, а именно UNDO, REDO, UNDO/REDO, NO UNDO/NO REDO.
Самыми эффективными, в большинстве случаев, как показывает практика, являются системы с undo/redo журналированием, то, что ты называешь "вынужден поддерживать персистентный же лог транзакций".
Если же применяется UNDO схема — все не зафиксированные изменения держатся в памяти, то в силу того, что незафиксированых изменений, при большой нагрузке, может быть довольно много, будет происходить перерасход памяти.
То есть сервер вносит изменения на диск, потому что в большинстве случаев так выгоднее.
Если нам не помогут, то мы тоже никого не пощадим.
. А бизтолк не катит, его стоимость для конечного решения будет дороже того за что можно наш продукт продать 
, давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.
Мы уже победили, просто это еще не так заметно...
