Комментарии к записи: Сторонний инструментарий для BPMS https://mainthing.ru/ru/item/310/ BPM-блог Анатолия Белайчука Tue, 21 Apr 2026 08:31:58 +0000 http://wordpress.org/?v=2.6.5 Автор: Александр https://mainthing.ru/ru/item/310/#comment-758 Александр Thu, 02 Sep 2010 06:12:56 +0000 http://mainthing.ru/?p=310#comment-758 Анатолий Вам так же спасибо за приятную дискусию и интересный блог. Анатолий
Вам так же спасибо за приятную дискусию и интересный блог.

]]> Автор: Anatoly Belychook https://mainthing.ru/ru/item/310/#comment-757 Anatoly Belychook Wed, 01 Sep 2010 15:39:37 +0000 http://mainthing.ru/?p=310#comment-757 Александр Спасибо за высказанное мнение, но Ваши оценки роли, назначения, состояния и перспектив BPMS и BPMN настолько сильно расходятся с моими, что продолжать дискуссию нет смысла. Я тут не знаю как управиться со всеми потенциальными заказчиками на проекты BPMS; на тренинг по BPMN, который я анонсировал пока что в очень узком кругу, народ ломится, а Вы говорите - все замерзло ;) Александр

Спасибо за высказанное мнение, но Ваши оценки роли, назначения, состояния и перспектив BPMS и BPMN настолько сильно расходятся с моими, что продолжать дискуссию нет смысла.

Я тут не знаю как управиться со всеми потенциальными заказчиками на проекты BPMS; на тренинг по BPMN, который я анонсировал пока что в очень узком кругу, народ ломится, а Вы говорите - все замерзло ;)

]]> Автор: Александр https://mainthing.ru/ru/item/310/#comment-756 Александр Wed, 01 Sep 2010 15:10:04 +0000 http://mainthing.ru/?p=310#comment-756 "Ваш выстрел просвистел мимо цели" :-) Не страшно! Я сторонник не причинения вреда живому :-) "Ваши аргументы в сослагательном наклонении работают против вас " - я не приводил аргументы, это примеры. Вы говорите "Преимущество, которое получал клиент: с таким инструментарием он мог безболезненно сменить СУБД." А я считаю, что это не правильно. Это значит купить за 100 долларов вещь, а использовать только на 10 долларов, ожидая, что в будущем ее придеться поменять. Про это чуть позже. Мне интересна тема BPMS, но, к сожалению, они замерзли несколько лет назад, заняли скромную нишу на рынке и слабо развиваются. "DBMS появились раньше, чем SQL" - да ради бога! Я же не отрицаю существование BPMS, хотя языка (аналогичного SQL) все равно нет. Навсякий случай я уточнил на http://ru.wikipedia.org/wiki/BPMN и вижу ничего не изменилось. "Нотация моделирования бизнес процессов (Business Process Modeling Notation, BPMN) — графическая нотация для моделирования бизнес процессов." Видел я еще XML диалекте этой нотации, но меня надо сильно прижать, чтобы я согласился писать на этом "языке". Туже гадость могу сказать про BPEL - язык еще тот.... (Пришлось использовать на проектах), если бы не мода, даже не притронулся... Вообщем, как я и говорил речь идет о "красочных технологиях" и XML подобных языках. Вы пробывали писать SQL запросы не руками, а мастером (с помощью визуального, красочного интерфейса)? Если Вы занимались программирование в больших масштабах, то поймете о чем я. Такой же пример могу привести с точки зрения администрирования систем (командная строка или визуальные мастера). Я не сторонник одновендороного подхода. Но считаю, что из инструмента надо вытягивать все возможное (бабки заплачены, имею право), а не ставить себе ограничение в виде "не использовать расширения, которые не соответствуют открытым стандартам, ибо...". Я делал проекты Oracle+ Delphi, Oracle + Forms, Oracle + Flex, Oracle + J2EE (интерфейс JSF). И каждое решение было, на мой взгляд, выбранно правильно. Кстати, нисколько не защищаю Oracle, просто я очень хорошо знаю базу данных этой фирмы, но некоторые проекты лучше делать на других БД. А пытаюсь я донести мысль, что нужен язык для BPMS, а его нет ;-( Все это имеет прямое отношение к Заметке, ибо Вы приводите некую типизацию-историзацию развития пользовательских интерфейсов к БД и пытаетесь провести аналогию с развитием BPMS. Наверное развитием доступа к BPMS? Так вот будет язык... Будет и BPMS, будет и доступ к нему. А пока все на уровне DBF файлов, хотя и с красивым интерфейсом. “Ваш выстрел просвистел мимо цели” :-) Не страшно! Я сторонник не причинения вреда живому :-)
“Ваши аргументы в сослагательном наклонении работают против вас ” - я не приводил аргументы, это примеры. Вы говорите “Преимущество, которое получал клиент: с таким инструментарием он мог безболезненно сменить СУБД.” А я считаю, что это не правильно. Это значит купить за 100 долларов вещь, а использовать только на 10 долларов, ожидая, что в будущем ее придеться поменять. Про это чуть позже.
Мне интересна тема BPMS, но, к сожалению, они замерзли несколько лет назад, заняли скромную нишу на рынке и слабо развиваются.
“DBMS появились раньше, чем SQL” - да ради бога! Я же не отрицаю существование BPMS, хотя языка (аналогичного SQL) все равно нет.
Навсякий случай я уточнил на http://ru.wikipedia.org/wiki/BPMN и вижу ничего не изменилось.
“Нотация моделирования бизнес процессов (Business Process Modeling Notation, BPMN) — графическая нотация для моделирования бизнес процессов.”
Видел я еще XML диалекте этой нотации, но меня надо сильно прижать, чтобы я согласился писать на этом “языке”. Туже гадость могу сказать про BPEL - язык еще тот…. (Пришлось использовать на проектах), если бы не мода, даже не притронулся…
Вообщем, как я и говорил речь идет о “красочных технологиях” и XML подобных языках.
Вы пробывали писать SQL запросы не руками, а мастером (с помощью визуального, красочного интерфейса)? Если Вы занимались программирование в больших масштабах, то поймете о чем я. Такой же пример могу привести с точки зрения администрирования систем (командная строка или визуальные мастера).
Я не сторонник одновендороного подхода. Но считаю, что из инструмента надо вытягивать все возможное (бабки заплачены, имею право), а не ставить себе ограничение в виде “не использовать расширения, которые не соответствуют открытым стандартам, ибо…”. Я делал проекты Oracle+ Delphi, Oracle + Forms, Oracle + Flex, Oracle + J2EE (интерфейс JSF). И каждое решение было, на мой взгляд, выбранно правильно. Кстати, нисколько не защищаю Oracle, просто я очень хорошо знаю базу данных этой фирмы, но некоторые проекты лучше делать на других БД.
А пытаюсь я донести мысль, что нужен язык для BPMS, а его нет ;-(
Все это имеет прямое отношение к Заметке, ибо Вы приводите некую типизацию-историзацию развития пользовательских интерфейсов к БД и пытаетесь провести аналогию с развитием BPMS. Наверное развитием доступа к BPMS? Так вот будет язык… Будет и BPMS, будет и доступ к нему. А пока все на уровне DBF файлов, хотя и с красивым интерфейсом.

]]> Автор: Anatoly Belychook https://mainthing.ru/ru/item/310/#comment-755 Anatoly Belychook Wed, 01 Sep 2010 10:46:45 +0000 http://mainthing.ru/?p=310#comment-755 Александр Ваш выстрел просвистел мимо цели. Во-первых, в BPM есть и стандартный язык BPMN, и математическая основа. В основе DBMS реляционная алгебра Кодда (а вовсе не теория множеств), в основе BPMS - процессная. Погуглите. Нормальные они или там НЕНОРМАЛЬНЫЕ - это уже эмоции. Во-вторых, DBMS появились раньше, чем SQL, и намного раньше, чем появился стандарт SQL. Или Adabas - это, по-вашему, не СУБД? Поинтересуйтесь, какого масштаба прикладные системы на нем построены. Если бы... посмотрел бы я... - это слабая аргументация. Ваши аргументы в сослагательном наклонении работают против вас - по факту, любители Java технологий прекрасно себя чувствуют. В любом случае, эти аргументы имеют мало отношение к теме заметки, и давайте не затевать религиозных войн в защиту Oracle. Я просто ратую за то, чтобы для BPMS, как и для DBMS, существовал спектр решений для пользовательского интерфейса - и от вендора, и от третьих сторон. Вы, как я понимаю, сторонник концепции "все из одних рук" (single vendor)? А.Б. Александр

Ваш выстрел просвистел мимо цели. Во-первых, в BPM есть и стандартный язык BPMN, и математическая основа. В основе DBMS реляционная алгебра Кодда (а вовсе не теория множеств), в основе BPMS - процессная. Погуглите. Нормальные они или там НЕНОРМАЛЬНЫЕ - это уже эмоции. Во-вторых, DBMS появились раньше, чем SQL, и намного раньше, чем появился стандарт SQL. Или Adabas - это, по-вашему, не СУБД? Поинтересуйтесь, какого масштаба прикладные системы на нем построены.

Если бы… посмотрел бы я… - это слабая аргументация. Ваши аргументы в сослагательном наклонении работают против вас - по факту, любители Java технологий прекрасно себя чувствуют.

В любом случае, эти аргументы имеют мало отношение к теме заметки, и давайте не затевать религиозных войн в защиту Oracle. Я просто ратую за то, чтобы для BPMS, как и для DBMS, существовал спектр решений для пользовательского интерфейса - и от вендора, и от третьих сторон. Вы, как я понимаю, сторонник концепции “все из одних рук” (single vendor)?

А.Б.

]]> Автор: Александр https://mainthing.ru/ru/item/310/#comment-754 Александр Wed, 01 Sep 2010 10:02:33 +0000 http://mainthing.ru/?p=310#comment-754 По отношению к DBMS, Вы сконцентрировались на технологиях доступа, а главное, что породило такие системы упущено. Главное - это SQL. Именно использование стандартного языка привело к развитию этой технологии. Если бы каждый начал использовать свой язык, то мы получили совсем другую историю. Преимущество DBMS в том, что есть некое ядро языка, которое поддерживается всеми и есть особенности, которые позволяют реализовывать крутые фишки. Сила Oracle DB не только в ее производительности, но и в ее возможностях, которые иначе представленны у других БД. Ну это отдельная тема... Вернусь к теме поста. Проблема в том, что, в то время как БД имеют под собой достаточно стройную теоретическую систему (теория множеств и язык програмирования SQL), BPMS никакого НОРМАЛЬНОГО языка и теоретической базы не имеют. Это всего лишь красочные технологии. Верно подмечено, что "у него может быть...нестандартный язык программирования". На мой взгляд, это и есть главная проблема. Нет теории, нет НОРМАЛЬНОГО языка. Эти системы будут продолжать коптить, пока не разгорятся :-). А это случится, только после появления стандартного языка (только вот не надо говорить о пародиях на язык програмирования в виде диалекта XML, если бы обращение к БД было бы на таком диалекте, то мы так бы на dbf и жили бы). И все таки еще... Если бы Unify закрыл (закроет) Accell, то проблемы действительно были бы (будут). Это странная аргументация. Если Вы заплатили за Oracle БД глупо не использовать те особенности, которые присущи этой базе (за которые заплачены немалые деньги) и ограничиватся стандартным SQL 92. Вы говорите про JDBC и ODBC, а что будет если от этих технологий (которые привязаны к конкретному вендору) решат отказаться? Кстати, если бы Oracle не подхватил бы SUN, посмотрел бы я на любителей Java технологий :-) с их мечтами отвязатся от вендора БД. Сила SQL в мобильности программистов между системами, а не в мобильности самих систем. Мобильность систем зависит от архитектора, проектировщика и качества кода программистов. Поэтому первое что должно произойти, это появление нормального языка, а потом будет и пункт 2 и пункт 3. А просто API не решает проблему, а только усложняет. По отношению к DBMS, Вы сконцентрировались на технологиях доступа, а главное, что породило такие системы упущено. Главное - это SQL. Именно использование стандартного языка привело к развитию этой технологии. Если бы каждый начал использовать свой язык, то мы получили совсем другую историю. Преимущество DBMS в том, что есть некое ядро языка, которое поддерживается всеми и есть особенности, которые позволяют реализовывать крутые фишки. Сила Oracle DB не только в ее производительности, но и в ее возможностях, которые иначе представленны у других БД. Ну это отдельная тема…
Вернусь к теме поста. Проблема в том, что, в то время как БД имеют под собой достаточно стройную теоретическую систему (теория множеств и язык програмирования SQL), BPMS никакого НОРМАЛЬНОГО языка и теоретической базы не имеют. Это всего лишь красочные технологии. Верно подмечено, что “у него может быть…нестандартный язык программирования”. На мой взгляд, это и есть главная проблема. Нет теории, нет НОРМАЛЬНОГО языка. Эти системы будут продолжать коптить, пока не разгорятся :-). А это случится, только после появления стандартного языка (только вот не надо говорить о пародиях на язык програмирования в виде диалекта XML, если бы обращение к БД было бы на таком диалекте, то мы так бы на dbf и жили бы).
И все таки еще… Если бы Unify закрыл (закроет) Accell, то проблемы действительно были бы (будут). Это странная аргументация.
Если Вы заплатили за Oracle БД глупо не использовать те особенности, которые присущи этой базе (за которые заплачены немалые деньги) и ограничиватся стандартным SQL 92. Вы говорите про JDBC и ODBC, а что будет если от этих технологий (которые привязаны к конкретному вендору) решат отказаться? Кстати, если бы Oracle не подхватил бы SUN, посмотрел бы я на любителей Java технологий :-) с их мечтами отвязатся от вендора БД. Сила SQL в мобильности программистов между системами, а не в мобильности самих систем. Мобильность систем зависит от архитектора, проектировщика и качества кода программистов.
Поэтому первое что должно произойти, это появление нормального языка, а потом будет и пункт 2 и пункт 3.
А просто API не решает проблему, а только усложняет.

]]>