Well said!

Anatoly, that’s what I meant by having an abstract relationship to storage. XML is just a way of package data, SOAP is how we wrap it in, and a web service is how we deliver it between parts in a SOA eco-system. Data needs a durable storage, by all means, and I believe we all can agree that a business process implementation isn’t a good choice - even though a BPMS is secure in terms of reliability. That said, I think that some data (such as an Order instance) should be accessed from a predictable business process (Order Process) since it’s valuable to have centralized control over data from a process perspective. That doesn’t necessarily mean a BPMS should be the place of storage for the Order data, but more of an event handler. The Order data shouldn’t be accessed without knowing why it’s being accessed. This approach is possible for most business processes, but for the rest I guess we have things like Adoptive Case Management, plain collaboration, and such.

Cheers!

That is the key point: “I as a service developer”, “I as a BPEL developer”, “I as a CRM developer” is one type of thinking and “I as an enterprise architect” or “I as a database administrator” is another.

Many application developers tend to believe that implementing a client part - the ability to call external webservices or to access external relational data means being “open”. In too many cases the services API is incomplete and/or data access is not available. They can “call” but hardly can be “called” - this is the way to the “information zoo”.

XML and XML-based services are great: abstract, platform-independent. But even the greatest things have a domain where they are effective; we can’t afford storing all enterprise data in XML or abandoning integration at data level.

My concerns regarding process data is most related to how service developers tends to think in terms of object-orientation instead of process-orientation. The message types gets over designed and focus is set on reuse instead of having that particular service request supported. This is also common for process developers with a OO background.

Thanks for an interesting topic.

Тут мы серьезно расходимся во взглядах.

Как это предложение реализовать практически - после завершения процесса сбрасывать данные в реляционную БД? А схему этой БД делать так, чтобы она была эквивалентна объектной? А до того, как процесс завершится, в эту базу лезть нельзя? И зачем тогда весь этот зоопарк: двойная разработка, дублирование данных… Вот я и прихожу к выводу: сразу нормализовать в реляционную БД и не мучиться.

>> Во-вторых, промежуточные, временные данные, которые хранятся в “черном ящике” так же могут быть доступны из вне. Про современные ИТ-системы с огромным кол-вом адаптеров, я умолчу. Скажу только, что для универсальной взаимосвязи приложений есть XML, есть Web Service, наконец есть ESB, если у какой-то ИТ-системы есть проблемы подключения с выходом в большой свет….

Хорошо. Представим себе корпоративную систему OLAP/BI/MDM. 100% у нее не будет проблем с извлечением процессных данных из реляционной БД. Несколько кликов мыши - и готово, данные всосали. А вебсервисы (любые) - это изучение API и программирование с заранее неизвестным результатом.

>> И, кстати, учитывая SOA, хранение данных в XML формате наиболее обосновано, чем SQL.

Стоп! А что, хранение данных в реляционной БД как-то отменяет представление ее в виде вебсервиса? Да не боже мой. Хоть WS-*, хоть REST-ом отдадим, без проблем.

Из реляционной БД сделать сервисы - элементарно. Представить вебсервисы или объектный “черный ящик” в виде реляционной модели - проблематично.

>> Действительно, если надо быстро и на коленке, то прочитать SQL из внешней ИТ-системы это самый простой и удобный вариант. Но где гарантия, что вас туда пустят? Да и тем более, любая БД (как например та, которая стоит 1C) имее закрытый формат, где все таблицы надо расшифровывать…

“та, которая стоит в 1С” - это совсем не “любая”. Это извращение, если называть вещи своими именами. Именно за него 1С так страстно “любят” все, кому приходится с ней интегрироваться. Более корректно выражаясь, это еще одна вариация на тему “СУБД поверх СУБД”. “Прямое использование реляционной СУБД”, о которой я говорю в статье, этого не допускает.

>> 4. … Просто в какой-то момент сохраните нужный атрибут в внешнюю структуру данных. В чем проблема?

Проблема в дублировании разработки и хранения.

>> По сути в Bizagi происходит тоже самое, насколько я понимаю.

Нет, у Bizagi нет другого хранения кроме реляционных таблиц.

>> 5. Вы показывали, как вы обращаетесь к данным, типа var1.client.avto.number…Это ведь сугубо объектный подход.

Эх, молодежь Вообще-то это называется навигацией. Которая появилась она в СУБД намного раньше, чем появилась реляционная алгебра и реляционные СУБД, не говоря уже об ООП.

>> BPMN разработан на основе объектно-ориентированных технологий

Впервые слышу.

>> Правильно ли я понимаю значение диаграммы классов в BPMN 2.0?

Диаграммы классов в стандарте описывают не атрибуты процесса, о которых мы сейчас говорим, а атрибуты модели процесса.

2. Тут Анатолий, я полностью с Вами согласен. Сожалею, что Вы меня не верно поняли. В своем комментарии у говорил, что “Я считаю, что тут эффективнее всего выглядят объектно-ориентированные технологии. Но пользоваться ими нужно аккуратно”. Другими словами, заставь дурака молится, он себе лоб расшибет. Это одинаково справедливо как для SQL, так и для ОТ. Кстати, в защиту ОТ нашел несколько хороших слов (http://intersystems.ru/cache/technology/techguide/cache_tech-guide_01.html): Объектная технология - это опыт отражения того, как в действительности человек думает об информации и использует ее. Преимущества ОТ:
* Объектная технология прекрасно сочетается с графическими пользовательскими интерфейсами (GUI). (!!!!) -> пример UML CD
* Объекты упрощают взаимодействие с различными технологиями и приложениями.
* Принцип “черного ящика” (или инкапсуляция) позволяет программистам совершенствовать внутреннее устройство объекта, не нарушая работу других частей приложения.
* Структура данных объекта более емкая, за счет чего можно естественным образом описывать данные реального мира.
* Версии классов, настроенные под определенного клиента, могут легко заменить стандартные версии. Это облегчает индивидуальную настройку приложения и гарантирует ее сохранение в следующих версиях.

3. Анатолий, мне кажется этот пункт - повтор 1 Вашего комментария. Соответственно я ответил на него в своем 1 тезисе. Еще раз повторю - интегрировать на уровне SQL мне кажется не верным подходом. Кину ложку дегтя. Как быть при реализации supply chain management (SCM), реализации B2B? Кстати, BPMN, насколько я понимаю это отлично поддерживает. А вот как это реализовать на уровне данных??Неужели через единую SQL БД???

4. Это самое интересное. Действительно, требования к СУБП постоянно меняются. Меняется и состав атрибутов, которые нужно хранить после завершения выполнения процесса. Но данный факт никак не противоречит использованию ОТ для моделирования данных в СУБП. Просто в какой-то момент сохраните нужный атрибут в внешнюю структуру данных. В чем проблема? По сути в Bizagi происходит тоже самое, насколько я понимаю. Другой вопрос, куда сохранить данный атрибут. В отдельную СУБД, созданную для того, чтобы закрыть провал, который появился после того, как была реализована СУБП и выяснилось, что существующие функциональные IT-системы не хранят в себе половину важной информации??? Или все же в внешнюю ИТ-систему?

5. Очень рад за Bizagi…надеюсь, что у остальных BPMS это так же хорошо реализовано. Кстати, Анатолий, немного в сторону вопрос. Я помню, что Вы показывали, как вы обращаетесь к данным, типа var1.client.avto.number…Это ведь сугубо объектный подход. Не понимаю, как это может быть реализовано на табличном уровне? Получается, что все параметры в запросы подставляются автоматически? Не кажется ли Вам, что это попытка Bizagi все же реализовать элементы ОТ?

6. Понятно. Спасибо. Посмотрел. Хотел добавить, что в Oracle BPM это же реализуется так:
var1 as Object = Object() //перменная процесса, которая ссылается на произвольный объект в модели представления данных в BPMS
copy = clone(this) // создаем клон нашего процесса (с всем необходимыми переменными)
copy.var1 = …. //совершаем действия уже над отклонированной переменной var1
….//при слиянии потоков
if var1 copy.var1 then ….//если копия переменной в каком-то конкретном потоке была изменена по отношению к главной переменной процесса var1, то производим необходимые действия.

Спасибо за содержательный и развернутый ответ. Никакой жесткости в аргументации не увидел.

Некоторые комментарии к комментарию:

1. Объектная модель - это замечательно, по сравнению с ней реляционная модель - это такой “наименьший общий делитель”. Другими словами, полное убожество. Но у реляционной модели есть одно достоинство, которое перевешивает все недостатки - открытость. Для объектной модели нет стандартных механизмов доступа - получаем “черный ящик”. С точки зрения BPMS это проблемой не является, так как мы сидим внутри этого черного ящика. С точки же зрения корпоративной архитектуры это проблема, и большая.

2. Реляционную модель проектировать сложно, для этого нужен профессионал, а объектную - легко, это может делать кто попало (вольное цитирование). Извини, но это караул. Легкость проектирования - это ловушка, позволяющая одному ламеру наворотить такого, что потом десять профессионалов не разгребут. Проектирование любой модели данных - хоть объектной, хоть реляционной - требует профессионализма. В обязательном порядке. Иначе катастрофа гарантирована. Это даже ответственнее, чем проектирование схемы процесса.

3. Про единую базу данных организации. Это недоразумение - я за нее не агитировал. Мой выбор - честная реляционная БД в противовес “черному ящику” любого сорта, будь то объектному, будь то какому другому. Но наличие нескольких баз внутри любой организации - это еще один аргумент в мою пользу: современные СУБД научились обращаться к “чужим” базам данных, как к своим. Можно в MS-SQL сказать: мол, есть у меня таблица, только физически она находится в Oracle, там-то и там-то. И после этого премилым образом строить join-ы. Bizagi поддерживает два механизма: реплиацию и виртуализацию. Аналитик работает как бы с локальной таблицей, а на уровне “физики” она смапирована на внешнюю БД. По-моему очень изящное решение. А вот со своеобычной объектной базой (а они все своеобычны, так как стандарта наподобие SQL там нет) этот номер не пройдет.

4. По поводу комбинированного хранения. Да, на первый взгляд, какие могут быть возражения против того, чтобы взять лучшее из двух миров? Но дело в том, что ни один атрибут “не даст честного слова”, что он не превратится из процессного короткоживущего в персистентный. Поэтому - нафиг!

5. Версионность схему данных. Если я и умолчал, то не специально. Bizagi встроил в свой инструмент полноценный моделер БД наподобие PowerDesigner. Это очень удачное решение, так как система отслеживает все зависимости между разными частями проекта - процессом, моделью данных и пользовательскими интерфейсами. В том числе он совершенно “прозрачно” переносит изменения схемы данных из разработки в эксплуатацию.

6. Распараллеливание процесса на несколько потоков. Насколько я понимаю, имеется в виду цикл по объектам? Если есть цикл по объектам, значит должно быть какое-то конкретное множество объектов, по которым мы в цикле будем запускать подпроцесс. У нас есть запись в таблице, соответствующая текущему экземпляру процесса верхнего уровня, и некая другая таблица, связанная с ней соотношением М:1. Опционально фильтруем какие именно записи, ссылающиеся на текущую, надо обработать, и запускаем по ним подпроцесс. Во втором мастер-классе по Bizagi я это демонстрировал, в числе прочего: http://www.youtube.com/watch?v=ikV3VUAqbK4