Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/30/19545.aspx
Транзакции, описываемые свойствами ACID по настоящему креативных людей уже давно не удовлетворяют. Сначала возникли "долгоиграющие" транзакции, которые растянули понятие до предела, но еще сохраняли представление о транзакции, как он некоторой целостностной операции. А теперь, похоже, новый этап эволюции термина. Вот такие достижения предлагает нам новейшая концепция BPM 2.0, согласно одному из блогов:
<<Такой подход позволил правительству Нидерландов производить постоянные изменения в процессах, которые могут выполняться до их завершения 5 лет. Если у кого либо есть любые сомнения что BPM может быть использован для поддержки таких долгоиграющих транзакций, то сечас такие сомнения должны быть отброшены.>>
Конечно можно попутно задуматься -- не поменять что-то в «консерватории» ? Какая эффективность от workflow в процессе, длящемся 5 лет и постоянно меняющемся? Учет шагов, конечно важен, но формализация такого процесса выглядит как overkill.
Но меня поразило больше то, что это теперь уже называют транзакцией. Правила выполнения «транзакции» кроятся в ходе ее же исполнения. Куда ушли старые добрые транзакционные принципы? Вероятно, настоящий творец должен делать транзакцию руками, меняя все на ходу -- включая код. :))
Published 30 июля 2007 г. 13:23 by Vlad Borkus
Filed under: Брюзжание
nvoynov said:такие системы не обходятся без инноваций
... The Dutch Government did just that for a process that has a quarter of a million activities, so if it worked for them at such a scale, it should work for many other organizations...
... If your process has hundreds or thousands of steps (or 250,000 like the one Intalio built for the Dutch Government), ...
... For it to work at a large scale— the aforementioned Dutch Government is running 250 million concurrent process instances that take up to five years to complete on a 4-CPU box—BPM 2.0 ...
... Such an approach allows the Dutch government to make regular changes to processes that can take up to five years to complete. If anyone had any doubt that BPM could be used to support long-running transactions, such doubts should be put to rest by now...июля 30, 2007 14:29
Tolik said:
Вообще-то - транзакция - это то, что ACID
Что не ACID - можно называть как угодно (бизнес-процесс, workflow, операция), но зачем это транзакцией-то обзывать?
Использование для перевозки пассажиров очень легко бронированых колесных танков без вооружения (автомобилей) позволяет существенно повысить эффективность использования танковой техники. ;-)
июля 30, 2007 14:40
Vlad Borkus said:
На "такие системы не обходятся без инноваций"
Инноваций особенно никаких нет. Иерархическое согласование вещь известная давно и внедряетс бог знает сколько, версии процессов -- тоже. Только вот ждать 5 лет до окончания согласования -- это реально круто. Собственно говорит о том, что с процессами что-то неладно.
июля 30, 2007 15:01
Vlad Borkus said:
2 Tolik
Вспоминается "Да, господин министр!". Если в колбасе нет мяса, то ее можно назвать "английской колбасой". Ведь главное -- не обманывать потребителя :))
июля 30, 2007 15:02
Vlad Borkus said:
Не удержусь, еще добавлю. Сейчас на самом деле "гуляют" два термина -- долгоиграющие процессы и "долгоиграющие транзакции/транзакционные процессы". Долгоиграющие транзакции -- имеют нечто общее с нормальными транзакциями. Хотя, как правило, они и представляют собой процессы, которые охватывают/интегрируют несколько систем. Стандартный ACID ввиду длительности каждого этапа использовать нельзя -- невозможно надолго захватить данные в "чужой" системе. Потому данные в системах просто меняют "окончательно", а в случае сбоев делают всякие "восстановительные" шаги. Нередко эти копенсации делает администратор "руками" по логам. Но важно, что такая штука ориентирована на сохранение целостности данных, в отличе от обычного делового процесса. Часто она в e-commerce актуальна, в банках и т.п. Транзакционныый процесс может быть длительным, но ИМХО есть все же разумные пределы его длительности ....
июля 30, 2007 15:23
Tolik said:
Тут надо смотреть, видимо, с точки зрения разумности операции отката. Что-то мне подсказывает, что откатить 5-летний процесс и вернуть систему в исходное состояние навряд ли удастся.
Такде есть смысл задуматься об изоляции. Тоже, наверно, скрывать от остальных процессов 5-летнюю операцию глупо и незачем.
июля 30, 2007 15:28
nvoynov said:
В этом случае наверно разумные придела затянулись :) ну да со временем они так растягиваются это в клиент-сервер короткие они были
Вообще таких долгих операций наверное можно много найти ... удачных примеров сходу конечно не набрать, но допустим тоже погашение десятилетнего кредита ...
> "Легкие танки для перевозки пассажиров"
Интересно было бы узнать про этот конкретный проект побольше. Вполне можно ожидать и такого варианта когда тут именно этим танком была сама BPMS
> На "такие системы не обходятся без инноваций"
смайл забыл поставить, и имел ввиду то что очень даже вероятно немного сойти с ума в процессе таких проектов.
И в конце концов вы же знаете этих американцев - эволюционирует язык :)
июля 30, 2007 15:43
ИТ блокнот said:
Выложил свой вольный перевод отдельных постов блога с intalio.org Собственно обсуждение отдельных моментов
июля 30, 2007 16:29
Mikhail Elashkin said:
Влад, Толя, вы "относитесь к себе слишком серьезно". СУБДэшная транзакция это только одна из возможных и не самая популярная. Читаем:
http://en.wikipedia.org/wiki/Transaction
Скажем:
A financial transaction involves a change in the status of the finances of two or more businesses or individuals.
Purchase
The most common type of financial transaction. An item or good is exchanged for money. This transaction results in a decrease in the finances of the purchaser and an increase in the finances of the seller.
...
Так что не не в танках дела. Это в русском языке транзакция компьютерный термин, а в аглицком это финансовый, процессовый и только потом компьютерный )
июля 30, 2007 17:11
Vlad Borkus said:
>СУБДэшная транзакция это только одна из возможных и не самая популярная.
Миша, еще есть транзакционный анализ Берна :)) Просто термин эволюционирует даже в рамках компьютерной области.
Смысл термина по другим областям известен (сделка или экономическая операция, как правило). Но даже во вне компьютерных вещах словом обозначают операцию, имеющую четкие границы.
июля 30, 2007 17:30
Vlad Borkus said:
>Такде есть смысл задуматься об изоляции. Тоже, наверно, скрывать от остальных процессов 5-летнюю операцию глупо и незачем.
От изоляции в "долгоиграющей транзакции" отказались. Не обязательный элемент.
июля 30, 2007 17:32
Vlad Borkus said:
>смайл забыл поставить, и имел ввиду то что очень даже вероятно немного сойти с ума в процессе таких проектов.
Не, их обычно устойчивые люди делают. Живут своей работой -- во всех смыслах :)))
июля 30, 2007 17:33
Yo! said:
на самом деле (во всяком случае на бумаге) еще существуют некие Epsilon и компенсационные транзакции субд, с извратами на тему их изолированости.
июля 30, 2007 18:07
Транзакции, описываемые свойствами ACID по настоящему креативных людей уже давно не удовлетворяют. Сначала возникли "долгоиграющие" транзакции, которые растянули понятие до предела, но еще сохраняли представление о транзакции, как он некоторой целостностной операции. А теперь, похоже, новый этап эволюции термина. Вот такие достижения предлагает нам новейшая концепция BPM 2.0, согласно одному из блогов:
<<Такой подход позволил правительству Нидерландов производить постоянные изменения в процессах, которые могут выполняться до их завершения 5 лет. Если у кого либо есть любые сомнения что BPM может быть использован для поддержки таких долгоиграющих транзакций, то сечас такие сомнения должны быть отброшены.>>
Конечно можно попутно задуматься -- не поменять что-то в «консерватории» ? Какая эффективность от workflow в процессе, длящемся 5 лет и постоянно меняющемся? Учет шагов, конечно важен, но формализация такого процесса выглядит как overkill.
Но меня поразило больше то, что это теперь уже называют транзакцией. Правила выполнения «транзакции» кроятся в ходе ее же исполнения. Куда ушли старые добрые транзакционные принципы? Вероятно, настоящий творец должен делать транзакцию руками, меняя все на ходу -- включая код. :))
Published 30 июля 2007 г. 13:23 by Vlad Borkus
Filed under: Брюзжание
Comments
nvoynov said:такие системы не обходятся без инноваций
... The Dutch Government did just that for a process that has a quarter of a million activities, so if it worked for them at such a scale, it should work for many other organizations...
... If your process has hundreds or thousands of steps (or 250,000 like the one Intalio built for the Dutch Government), ...
... For it to work at a large scale— the aforementioned Dutch Government is running 250 million concurrent process instances that take up to five years to complete on a 4-CPU box—BPM 2.0 ...
... Such an approach allows the Dutch government to make regular changes to processes that can take up to five years to complete. If anyone had any doubt that BPM could be used to support long-running transactions, such doubts should be put to rest by now...июля 30, 2007 14:29
Tolik said:
Вообще-то - транзакция - это то, что ACID
Что не ACID - можно называть как угодно (бизнес-процесс, workflow, операция), но зачем это транзакцией-то обзывать?
Использование для перевозки пассажиров очень легко бронированых колесных танков без вооружения (автомобилей) позволяет существенно повысить эффективность использования танковой техники. ;-)
июля 30, 2007 14:40
Vlad Borkus said:
На "такие системы не обходятся без инноваций"
Инноваций особенно никаких нет. Иерархическое согласование вещь известная давно и внедряетс бог знает сколько, версии процессов -- тоже. Только вот ждать 5 лет до окончания согласования -- это реально круто. Собственно говорит о том, что с процессами что-то неладно.
июля 30, 2007 15:01
Vlad Borkus said:
2 Tolik
Вспоминается "Да, господин министр!". Если в колбасе нет мяса, то ее можно назвать "английской колбасой". Ведь главное -- не обманывать потребителя :))
июля 30, 2007 15:02
Vlad Borkus said:
Не удержусь, еще добавлю. Сейчас на самом деле "гуляют" два термина -- долгоиграющие процессы и "долгоиграющие транзакции/транзакционные процессы". Долгоиграющие транзакции -- имеют нечто общее с нормальными транзакциями. Хотя, как правило, они и представляют собой процессы, которые охватывают/интегрируют несколько систем. Стандартный ACID ввиду длительности каждого этапа использовать нельзя -- невозможно надолго захватить данные в "чужой" системе. Потому данные в системах просто меняют "окончательно", а в случае сбоев делают всякие "восстановительные" шаги. Нередко эти копенсации делает администратор "руками" по логам. Но важно, что такая штука ориентирована на сохранение целостности данных, в отличе от обычного делового процесса. Часто она в e-commerce актуальна, в банках и т.п. Транзакционныый процесс может быть длительным, но ИМХО есть все же разумные пределы его длительности ....
июля 30, 2007 15:23
Tolik said:
Тут надо смотреть, видимо, с точки зрения разумности операции отката. Что-то мне подсказывает, что откатить 5-летний процесс и вернуть систему в исходное состояние навряд ли удастся.
Такде есть смысл задуматься об изоляции. Тоже, наверно, скрывать от остальных процессов 5-летнюю операцию глупо и незачем.
июля 30, 2007 15:28
nvoynov said:
В этом случае наверно разумные придела затянулись :) ну да со временем они так растягиваются это в клиент-сервер короткие они были
Вообще таких долгих операций наверное можно много найти ... удачных примеров сходу конечно не набрать, но допустим тоже погашение десятилетнего кредита ...
> "Легкие танки для перевозки пассажиров"
Интересно было бы узнать про этот конкретный проект побольше. Вполне можно ожидать и такого варианта когда тут именно этим танком была сама BPMS
> На "такие системы не обходятся без инноваций"
смайл забыл поставить, и имел ввиду то что очень даже вероятно немного сойти с ума в процессе таких проектов.
И в конце концов вы же знаете этих американцев - эволюционирует язык :)
июля 30, 2007 15:43
ИТ блокнот said:
Выложил свой вольный перевод отдельных постов блога с intalio.org Собственно обсуждение отдельных моментов
июля 30, 2007 16:29
Mikhail Elashkin said:
Влад, Толя, вы "относитесь к себе слишком серьезно". СУБДэшная транзакция это только одна из возможных и не самая популярная. Читаем:
http://en.wikipedia.org/wiki/Transaction
Скажем:
A financial transaction involves a change in the status of the finances of two or more businesses or individuals.
Purchase
The most common type of financial transaction. An item or good is exchanged for money. This transaction results in a decrease in the finances of the purchaser and an increase in the finances of the seller.
...
Так что не не в танках дела. Это в русском языке транзакция компьютерный термин, а в аглицком это финансовый, процессовый и только потом компьютерный )
июля 30, 2007 17:11
Vlad Borkus said:
>СУБДэшная транзакция это только одна из возможных и не самая популярная.
Миша, еще есть транзакционный анализ Берна :)) Просто термин эволюционирует даже в рамках компьютерной области.
Смысл термина по другим областям известен (сделка или экономическая операция, как правило). Но даже во вне компьютерных вещах словом обозначают операцию, имеющую четкие границы.
июля 30, 2007 17:30
Vlad Borkus said:
>Такде есть смысл задуматься об изоляции. Тоже, наверно, скрывать от остальных процессов 5-летнюю операцию глупо и незачем.
От изоляции в "долгоиграющей транзакции" отказались. Не обязательный элемент.
июля 30, 2007 17:32
Vlad Borkus said:
>смайл забыл поставить, и имел ввиду то что очень даже вероятно немного сойти с ума в процессе таких проектов.
Не, их обычно устойчивые люди делают. Живут своей работой -- во всех смыслах :)))
июля 30, 2007 17:33
Yo! said:
на самом деле (во всяком случае на бумаге) еще существуют некие Epsilon и компенсационные транзакции субд, с извратами на тему их изолированости.
июля 30, 2007 18:07
Комментариев нет:
Отправить комментарий